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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Reported:
baba-gorchitsashows 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:
carried, 0 votestelemetry, 1 voteQmUQ4o9kcQ…, Intel Xeon E5-2620 v3Exactly 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_idis deliberatelyNonefor anything that is not aTelemetryattribution, 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/nodesand/: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.