Dashboard: Worker Inspect page — read/edit each miner's XMRig config over its API, with versioned config history + per-config hashrate stats

[VijitSingh97]

Summary

A dedicated Worker Inspect page that, for any worker exposing the XMRig HTTP API (with write access granted), lets the operator view and edit that miner's config from the dashboard — while Pithead keeps a versioned history of every worker's config in its DB and correlates measured hashrate to each config version.

Marked v1.1 / future feature — sizable, and not needed for the v1.0 showcase.

Motivation

• Today, changing a rig's config means SSHing into each miner / hand-editing RigForge configs. On a multi-rig setup that's the main operational pain.
• Tuning (threads, huge pages, RandomX flags, donate level, pool/algo) is iterative — you want to change a knob and immediately see the hashrate effect, and be able to roll back to whichever config performed best.
• Centrally-stored config copies mean a rig that dies can be reprovisioned from Pithead's last-known-good config.

Proposed capabilities

1. Read — pull the live config from each worker's XMRig API (GET /1/config; requires http.restricted: false + an access token on the rig) and show it on the Worker Inspect page.
2. Edit / push back — edit in the dashboard and PUT the updated config to the worker (XMRig reloads it). Gated on write access + auth.
3. Persist — store every worker's config in Pithead's DB (the dashboard's SQLite), keyed by worker.
4. Version + history — on every observed or applied change, snapshot the config as a new version with a timestamp and a diff; keep the full per-worker config history, and log the source of each change (dashboard edit vs. changed externally on the rig).
5. Per-config hashrate stats — tie the hashrate time-series to the active config version, so each config carries its measured hashrate (avg / peak): "config Add support for querying workers using avahi #3 did 5.1 kH/s, config XVB Support and Improved Dashboard #4 did 4.8 kH/s." Lets the operator pick the best config empirically.
6. Worker Inspect page — a per-worker detail view hosting all of the above: current config, history with diffs, hashrate-per-config, and edit / apply / rollback controls.

Technical considerations

• XMRig API: read/write needs http.restricted: false + an access token per worker — the same token/addressing plumbing as Dashboard: config to read workers that use a custom XMRig API token #171 / Configurable worker ports & endpoints: non-standard stratum/API ports + per-worker host/port/token overrides (later) #172. The default XMRig API is read-only, so this feature requires operators to explicitly opt each rig into write access.
• Security (gating concern): writing back to a miner-supplied host is an outbound request to a host the dashboard otherwise treats as untrusted data — the exact SSRF surface in SSRF: miner-controlled worker name/IP becomes an outbound request host from the host-networked dashboard #122. The write path must (a) validate target host/port against the configured worker registry, not arbitrary miner-reported IPs, (b) require an explicit per-worker token, and (c) fail closed. Editing a remote miner's config is a high-trust action, so it must sit behind dashboard authentication (Secure Dashboard: authentication/login + safe public exposure (re-evaluate Caddy/TLS) #8).
• Reachability: depends on per-worker host/port/token, i.e. Configurable worker ports & endpoints: non-standard stratum/API ports + per-worker host/port/token overrides (later) #172's per-worker overrides — this feature builds on that.
• Storage / history: extends the dashboard's SQLite layer — config snapshots + diffs, plus a config_id foreign key on the hashrate time-series (relates to Store share stats as time-series for reject-rate trends/charting #116's time-series storage).
• Cross-repo (RigForge): worker configs are RigForge's domain (the miner kit). The config schema / validation should align with RigForge so a pushed config is valid for the rig.

Relationship to existing issues

• Stack config editor: change any setting from the dashboard, applied via pithead (incl. P2Pool mode hot-swap) #33 — Stack config editor (change stack settings from the dashboard via pithead): this is the worker-side counterpart. Stack config editor: change any setting from the dashboard, applied via pithead (incl. P2Pool mode hot-swap) #33 edits the orchestrator/stack config; this edits each miner's config. Same "edit config from the dashboard" UX, different target — worth designing the two together.
• Dashboard: config to read workers that use a custom XMRig API token #171 / Configurable worker ports & endpoints: non-standard stratum/API ports + per-worker host/port/token overrides (later) #172 — read workers via a custom XMRig API token / per-worker host/port/token overrides. Prerequisites: you can't read or write a worker's config without addressing + authenticating to its API.
• SSRF: miner-controlled worker name/IP becomes an outbound request host from the host-networked dashboard #122 — SSRF via miner-controlled host/IP. The security model for the write path must resolve this.
• Store share stats as time-series for reject-rate trends/charting #116 — store share stats as time-series. The per-config hashrate stats ride on time-series storage; a config_id ties samples to the config that produced them.
• Secure Dashboard: authentication/login + safe public exposure (re-evaluate Caddy/TLS) #8 — dashboard auth: editing remote rigs is high-trust; gate behind it.

Scope / phasing

A natural phased build:

1. Read-only config view on a Worker Inspect page.
2. DB persistence + versioned history with diffs.
3. Per-config hashrate stats (config_id on the time-series).
4. Edit / apply / rollback (the write path + its security model).

Acceptance criteria (when built)

• Worker Inspect page shows each worker's current XMRig config (for rigs exposing the API + token).
• Operator can edit and push a config back to a worker; the worker reloads it; failures are surfaced clearly.
• Every config change is snapshotted to the DB with a timestamp + diff; the full per-worker history is browsable.
• Hashrate stats are attributable to a specific config version, so configs can be compared by measured hashrate.
• The write path validates targets against the worker registry, requires per-worker auth, and fails closed (no SSRF — addresses SSRF: miner-controlled worker name/IP becomes an outbound request host from the host-networked dashboard #122).
• Config editing is gated behind dashboard authentication (Secure Dashboard: authentication/login + safe public exposure (re-evaluate Caddy/TLS) #8).