fix(peers): a relay-reached peer renders as [::]:0 — an unspecified address shown where an endpoint goes

[MichaelTaylor3d]

Task

dign peers renders a relay-reached peer's address as [::]:0 — the IPv6 unspecified address on
port 0, which is not an endpoint at all. Emit no address for such a peer so the renderer's existing
honest fallback shows instead.

Discovered during the light-client end-to-end verification on
https://github.com/DIG-Network/dig_ecosystem/issues/2760 (the 2026-08-19 measurement comment).
That epic is the discovery CONTEXT, not this ticket's family parent — no open orchestrator epic covers
the DIG peer-display surface today, and per CLAUDE.md §1.3 a 1:1 super-repo shadow for a trivial
repo-scoped fix would re-create the double-bookkeeping the queue split removed. This closes with its
own PR.

(Corrected: the first version of this body cited #836 as its parent. #836 is CLOSED and cannot parent
anything.)

Measured on a real machine, 2026-08-19

dig-node 0.126.2 (b92de34), installed as the OS service:

$ dign peers
dig-node peer network: running · 1 connected peer(s)
  relay wss://relay.dig.net:443 — reservation held
  peers:
    • 62ecc368ecac7ccaa599e344e228355023fbe46d06759efe8a9e5223543f2a5c  relay/outbound  [::]:0

[::]:0 reads as an address. It is the absence of one.

Context — the honest fallback already exists and is unreachable

crates/dig-node-service/src/peers.rs:215 already handles this correctly:

let addr = p["address"].as_str().unwrap_or("(no address)");

That branch fires only when the field is absent. The producer never omits it —
crates/dig-node-core/src/peer.rs:328 stringifies unconditionally:

"address": addr.to_string(),

So for a peer reached over the relay, where connected_pool_peers() has no direct address to report,
the placeholder [::]:0 is emitted and the "(no address)" branch can never run. The renderer is
correct; the producer is what needs fixing. Guarding the display instead would leave the same
placeholder in control.peerStatus for every other consumer, including the extension.

Scope

At peer.rs:328, omit address when the socket address is unspecified or its port is 0, so the field
is genuinely absent rather than placeholder-filled. Keep the JSON shape otherwise identical — the key is
already read with .unwrap_or(..) downstream, so absence is the supported case, not a new one.

via already carries the useful truth for these peers (relay), and the relay line above prints the
reservation, so a person loses nothing by the address disappearing — they stop being told something
false.

Skill / reference of "good"

professional-ui's honesty rule and the ecosystem pattern of never implying a fact not held: a surface
must not present a placeholder that a person can mistake for real data. The same argument the dig-app
panes settled with BalanceReading's pending/known/unknown split — an unknown renders as unknown, not
as a plausible-looking zero.

§5.2 is not violated here and should not be cited: the IPv6-first ordering in peers.rs:199-200 is
correct, and is_ipv4() classifies [::]:0 as IPv6 which is technically right. The defect is
truthfulness, not address family.

Evidence

A test asserting a relay-reached peer with no direct address produces JSON without an address key,
and that the rendered line shows (no address). It must fail against today's code — which it will,
since today's code emits [::]:0.

Effort

Small. Two lines plus a test. No design fork.

[MichaelTaylor3d]

Re-parented off https://github.com/DIG-Network/dig_ecosystem/issues/2760.

This is the DIG peer display (dig-node-core/src/peer.rs:328 renders addr.to_string() unconditionally; dig-node-service/src/peers.rs:215's fallback is unreachable), not the Chia peer path. It touches nothing in Sage's capability set, and this ticket's own body already says #2760 is "the discovery CONTEXT, not this ticket's family parent."

The defect is real and unchanged — a relay-reached peer rendering as [::]:0 is a surface saying something false about who it is connected to. It just does not gate the light-client epic, and leaving it attached would have made that epic uncloseable for a reason unrelated to light-client behaviour.

Verified still live on origin/main before re-parenting rather than assuming.

[MichaelTaylor3d]

Verdict: STILL REAL — but the fix location has MOVED (read-only verification, 2026-08-24, origin/main = de75ecf8)

The renderer is NOT the source. The ticket names the honest fallback at
crates/dig-node-service/src/peers.rs:215 as unreachable. Measured: that fallback exists and is correct —

let addr = p["address"].as_str().unwrap_or("(no address)");   // peers.rs:215

— and the literal [::]:0 appears nowhere in peers.rs. The unwrap_or cannot fire because the
field is present; it just carries a wildcard string.

The producer is connected_peers_json.

• crates/dig-node-core/src/peer.rs:313 — pub(crate) fn connected_peers_json(...)
• crates/dig-node-core/src/peer.rs:328 — "address": addr.to_string(), — unconditional, straight
  from dig_gossip::GossipHandle::connected_pool_peers().

For a relay-accepted circuit with no configured relay endpoint, dig-nat reports the remote as [::]:0,
which flows through PoolEvent::PeerAdded into the connected pool — documented in-repo at
crates/dig-node-core/src/seams/dig_peer/net.rs:88-95.

The guard already exists in this crate and is simply not applied here.
net.rs:104 — pub fn is_usable_contact(addr: &SocketAddr) -> bool (rejects unspecified IP and port 0).
It is applied at three sites and not at the peerStatus producer:

applied	not applied
download.rs:1555	peer.rs:328 (control.peerStatus per-peer array)
peer.rs:133 (DHT contact)
seams/dig_peer/dht.rs:592

Recommended fix, in one place: in connected_peers_json (peer.rs:313-333), omit the address field
when !net::is_usable_contact(&addr). That makes peers.rs:215's "(no address)" fallback reachable and
correct as written — no renderer change needed — and re-uses the existing centralized predicate rather
than adding a fourth copy of the wildcard test.

Evidence commands (read-only): git grep -n 'is_usable_contact' origin/main,
git show origin/main:crates/dig-node-core/src/peer.rs | sed -n '313,333p'.

[MichaelTaylor3d]

Verified STILL REAL on origin/main (de75ecf, v0.149.0) — not obsoleted by the 5f9e4ac custody carve-out, which touches neither peer.rs nor peers.rs.

The ticket's stated fix location was wrong. crates/dig-node-service/src/peers.rs:215 (unwrap_or("(no address)")) is correct as written and simply unreachable: the field is present, holding the literal string "[::]:0". The producer is crates/dig-node-core/src/peer.rs:328 — connected_peers_json emitting "address": addr.to_string() unconditionally.

Fixed at the producer with the existing net::is_usable_contact predicate (already trusted by three other call sites, #1784) rather than a new one. Key omitted, not placeholdered.

PR: #347 (DRAFT, awaiting gate) · branch loop/253-relay-peer-address · 0.149.0 -> 0.150.0

Red -> green -> placement-revert proof (guard call dropped, helper intact, still compiles): 0 passed; 1 failed. Full suite 988 passed; 0 failed.

No consumer of the address field outside dig-node (ecosystem-wide peerStatus grep). SPEC.md now documents address as OPTIONAL.