Node metadata is only reachable through the mining inference, so most nodes are invisible #16

New Issue

grenade · 2026-09-13T16:12:50Z

grenade commented

2026-09-13 16:12:50 +00:00

Reported: baba-gorchitsa shows its hardware on telemetry.quantus.com and nothing on blackbeard.observer. It is not a decoding failure — we hold the data. It is that the only way to reach it is through a join that most nodes do not have.

What was measured

Same node, both chains, at the same moment:

	quantus (mainnet)	planck
attribution	`carried`, 0 votes	`telemetry`, 1 vote
blocks in window	33	2,969
on that chain's telemetry feed	yes — `QmUQ4o9kcQ…`, Intel Xeon E5-2620 v3	no, 0 matches

Exactly inverted. On mainnet we hold the metadata and have no join to it; on Planck we have the join and the node has left.

The mainnet name is carried — earned under the same reward preimage on Planck and standing in here — and Attribution::peer_id is deliberately None for anything that is not a Telemetry attribution, because there is no node behind a preimage or a carried name and hanging hardware off one would describe a machine we never matched. That reasoning is right and stays. The mistake is upstream of it.

The actual defect

Node metadata is only reachable through the mining inference. The feed hands us every node on first subscribe — 284 on mainnet — whether or not it has ever won a block. We decode and cache all of them, then expose them through exactly one door: a miner page, which requires blocks and enough telemetry votes to settle on a node.

So a node that is running, reporting, and visible on the official telemetry site is invisible here unless it has recently mined and the first-reporter voting resolved a clean lead. That is most nodes.

What to build

A nodes index and a node route — /:chain/nodes and /:chain/node/:peer — listing every node the feed reports, independent of mining entirely. The miner page then links to its node where the voting has settled, rather than being the only way in.

The index should merge the live feed with the cache, so a node the feed has not re-announced since our last restart still appears, marked by when it was last heard. With 284 rows it needs a filter, because "find my node" is the whole point.

Not in scope here, deliberately

A name fallback on the miner page — where the attribution is carried or by preimage, and exactly one node on this chain's feed has that name, show it as a weaker inference. That would cover the reported case directly, but it is a different and softer claim than a voted join: names collide, which is why the standings already disambiguate them one level up. If it lands it must carry a visibly different confidence label, or it launders a name match into something that looks like evidence. Worth its own issue and its own decision.

Reported: `baba-gorchitsa` shows its hardware on telemetry.quantus.com and nothing on blackbeard.observer. It is not a decoding failure — we hold the data. It is that the only way to reach it is through a join that most nodes do not have. ## What was measured Same node, both chains, at the same moment: | | quantus (mainnet) | planck | |---|---|---| | attribution | **`carried`**, 0 votes | `telemetry`, 1 vote | | blocks in window | 33 | 2,969 | | on that chain's telemetry feed | **yes** — `QmUQ4o9kcQ…`, Intel Xeon E5-2620 v3 | **no**, 0 matches | Exactly inverted. On mainnet we hold the metadata and have no join to it; on Planck we have the join and the node has left. The mainnet name is *carried* — earned under the same reward preimage on Planck and standing in here — and `Attribution::peer_id` is deliberately `None` for anything that is not a `Telemetry` attribution, because there is no node behind a preimage or a carried name and hanging hardware off one would describe a machine we never matched. That reasoning is right and stays. The mistake is upstream of it. ## The actual defect **Node metadata is only reachable through the mining inference.** The feed hands us every node on first subscribe — 284 on mainnet — whether or not it has ever won a block. We decode and cache all of them, then expose them through exactly one door: a miner page, which requires blocks *and* enough telemetry votes to settle on a node. So a node that is running, reporting, and visible on the official telemetry site is invisible here unless it has recently mined and the first-reporter voting resolved a clean lead. That is most nodes. ## What to build **A nodes index and a node route** — `/:chain/nodes` and `/:chain/node/:peer` — listing every node the feed reports, independent of mining entirely. The miner page then *links* to its node where the voting has settled, rather than being the only way in. The index should merge the live feed with the cache, so a node the feed has not re-announced since our last restart still appears, marked by when it was last heard. With 284 rows it needs a filter, because "find my node" is the whole point. ## Not in scope here, deliberately A **name fallback** on the miner page — where the attribution is carried or by preimage, and exactly one node on this chain's feed has that name, show it as a weaker inference. That would cover the reported case directly, but it is a different and softer claim than a voted join: names collide, which is why the standings already disambiguate them one level up. If it lands it must carry a visibly different confidence label, or it launders a name match into something that looks like evidence. Worth its own issue and its own decision.

grenade referenced this issue from a commit

2026-09-13 16:20:03 +00:00

feat: a nodes index, so a node need not have mined to be visible

grenade closed this issue

2026-09-13 16:20:03 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blackbeard/observer#16