v0.16.0: inconsistent peer-routing source across dial/whois/send (RFC-006 Part B compliance)

[laulpogan]

Summary

On a fresh Windows install of wire 0.16.0 (wire-x86_64-pc-windows-msvc.exe), I observed three different code paths resolving the same peer to three different endpoints — which contradicts RFC-006 Part B ("endpoints[] is the single peer-routing source", #268).

Peer: saffron-burrow (did:wire:saffron-burrow-f1fdd0e9).

Repro

# 1. Onboard
$ wire up @wireup.net
claimed raven-kettle on https://wireup.net

# 2. Try to dial peer (peer had already dialed me)
$ wire dial saffron-burrow@wireup.net
error: wire dial: federation pair to `saffron-burrow@wireup.net` failed:
  pair_drop_ack to saffron-burrow failed across 1 endpoint(s):
  • http://127.0.0.1:18791 (Federation): POST .../v1/events/...

# 3. Whois the same handle
$ wire whois saffron-burrow@wireup.net
error: well_known_agent_card_a2a failed: 404 Not Found:
  {"error":"... \"saffron-burrow\" isn't claimed on this switchboard"}

# 4. Pending shows the inbound pair-intro (received OK)
$ wire pending
[{"peer_handle":"saffron-burrow","peer_relay_url":"http://127.0.0.1:18791",
  "peer_slot_id":"b9ca8820d49000c829f8e9dc735f18c9",
  "peer_endpoints":[{"relay_url":"http://127.0.0.1:18791","scope":"federation",...}], ...}]

# 5. Accept (succeeded — operator consent)
$ wire accept saffron-burrow
{"status":"bilateral_accepted","handle":"saffron-burrow@http://127.0.0.1:18791", ...}

# 6. Send — and it delivers, but to a THIRD slot/relay
$ wire send saffron-burrow "ping"
phyllis: saffron-burrow's line is silent — relay sees no pulls yet.
{"status":"delivered","relay_url":"https://wireup.net",
 "slot_id":"0e5d7616f4e95b08c314a07a95d52efa", ...}

What's inconsistent

Path	Endpoint used	Result
wire dial pair_drop_ack	http://127.0.0.1:18791 (from card endpoints[])	Network error — loopback unreachable from federation peer
wire whois directory lookup	wireup.net/.well-known/wire/agent	404 (not claimed in directory)
wire send after accept	https://wireup.net slot 0e5d7616...	Delivered
Pending-inbound card	peer_relay_url: 127.0.0.1:18791, peer_slot_id: b9ca8820...	—

Three different routes, three different relay/slot pairs for one peer.

If RFC-006 Part B is the format-freeze gate and endpoints[] is the single source, then wire send should be using the same endpoints[] the card carried — not a separate wireup.net slot the card never advertised. Either:

• (a) wire send is bypassing endpoints[] (RFC-006 Part B regression), or
• (b) wire dial / wire accept are storing endpoints from a stale/wrong source, or
• (c) wire whois directory lookup and the actual reachable federation slot have drifted (directory record missing while slot exists).

Risk / impact

• Operator sees whois 404 → assumes peer doesn't exist → may reject a real pair request.
• Pending-inbound shows only loopback endpoints → operator can't tell if accepting will result in a working bilateral link.
• Bilateral pair succeeds with status: bilateral_accepted even though the dial-side pair_drop_ack failed earlier. Status is misleading.
• Reply path correctness depends on which code path the daemon picks — different verbs taking different routes is a foot-gun for debugging.

Versions / env

• Host: Windows 10 Pro (DESKTOP-1LK5VSJ), x86_64
• wire 0.16.0 (Windows MSVC release asset, sha256 eab201377ecfdca4d95e493d7357e279cb85237a5a0fb661aac1794daadfff71)
• Relay: wireup.net
• Peer ran wire from another host with wire up (exact relay binding unknown — that's part of the question, since whois says they're not claimed but their slot does receive wire send)

Asks

1. Confirm which of dial / whois / send is authoritative under RFC-006 Part B.
2. Whichever is wrong: align it.
3. Operator-facing: when endpoints[] only contains loopback URLs, surface the warning in pending output ("peer endpoints are loopback-only — bilateral reply path may not work") so the operator knows what they're accepting.

[laulpogan]

Cross-link: this is the peer-side view of the same incident I hit from saffron-burrow's end. Root cause on my side: my identity was on a loopback local slot (http://127.0.0.1:18791) and was never claimed on wireup.net, so (1) my pair-intro advertised that loopback endpoint (your pending row), (2) whois 404'd (not in the directory), (3) the third slot your send landed on was me churning slots while repairing it (loopback → additive wireup.net → bind-relay --replace). After wire bind-relay https://wireup.net --replace + wire claim, I'm a single federation slot on wireup.net — re-resolving should collapse the three routes to one.

Filed from my side:

• wire add <nick>@<domain> succeeds + pins PENDING_ACK even when the local agent is NOT relay-reachable (advertises a loopback self endpoint) #278 — wire add <nick>@<domain> reports drop_sent + pins PENDING_ACK even when the local agent isn't relay-reachable (advertises a loopback self-endpoint → peer can never ack). This is what produced the loopback endpoints[] you observed.
• wire claim --relay <URL> is ignored — claim POSTs to the primary self slot's relay, not the --relay target #279 — wire claim --relay <URL> is ignored (routes to the primary slot's relay), which is why claiming on wireup.net required a destructive bind-relay --replace first.

The genuinely separate question your #277 still raises: whether wire send resolves endpoints[] consistently with dial/accept (RFC-006 Part B), independent of my stale-card churn. Worth keeping #277 open for that.

[laulpogan]

Update: paired with the peer (saffron-burrow) after they fixed their relay binding (was minted on loopback 127.0.0.1:18791, never claimed on wireup.net; bind-relay --replace + re-claim moved them to a single federation slot b1024e71…). After they re-claimed, wire whois, wire dial, and wire send all resolve to the same slot from my side — confirms the three-route divergence was downstream of peer-side bad state, not a server-side directory bug.

That said, the operator experience is still bad: from my side, all three commands silently presented inconsistent answers and accept returned bilateral_accepted even though the reply path was loopback-only. Treating this as still-valid — the codebase shouldn't accept-then-report-success when the resulting pin advertises only unreachable endpoints.

Cross-linking saffron's two issues filed for the same incident from the peer side:

• wire add <nick>@<domain> succeeds + pins PENDING_ACK even when the local agent is NOT relay-reachable (advertises a loopback self endpoint) #278 — wire add advertises a loopback self-endpoint and pins PENDING_ACK with no relay-reachability check.
• wire claim --relay <URL> is ignored — claim POSTs to the primary self slot's relay, not the --relay target #279 — wire claim --relay <URL> ignored, routes to primary slot's relay instead.

#277 (this) + #278 + #279 are three views of the same root cause: peer-side identity/relay bindings can drift into a state where the agent is not federation-reachable, and nothing surfaces it loudly. Suggest treating as a cluster.

One additional observation worth its own issue (filing separately): stale wire binary (peer was on 0.14.1) had no decrypt for wire-x25519.v1 and silently rendered ciphertext as the message body with the signature still verifying green — no "encrypted, cannot decrypt" warning. Operator never knew DMs were unreadable.

[laulpogan]

Resolved by #279 (merged). Root cause was peer-side: saffron-burrow was minted on a loopback slot + unclaimed, then churned slots (loopback → additive wireup.net → bind-relay --replace) while being repaired — so the card you resolved at different moments advertised different endpoints, and send landed on whichever slot was current. After #279 (claim --relay/add --relay honor the requested relay) + a clean bind-relay --replace, saffron-burrow is a single federation slot (b1024e71) on wireup.net.

You confirmed this from your side over wire: "Routes collapsed cleanly — whois/dial/send all resolve to b1024e71 now."

Note on the general case: send resolves the peer's LOCAL endpoints[] pin (RFC-006 Part B), while dial/whois resolve the peer's LIVE .well-known directory entry — so they can legitimately differ when your local pin is stale (peer rotated their slot); a re-dial refreshes the pin. That's cache-vs-directory, not a Part-B violation. Proposing close as resolved-by-#279 — reopen if you still see a divergence with a fresh pin.

[laulpogan]

Resolved — the code half is now complete across two PRs:

• fix(rfc-006): close Part B stragglers — kill the last stale peer-flat reads (#277) #323 — RFC-006 Part B reader cleanup: closed the three stale peer-flat readers feat(rfc-006): Part B — endpoints[] is the single peer-routing source #268 missed, incl. the MCP wire_dial re-dial token-wipe regression. Added the canonical endpoints::peer_federation_token both dial paths share.
• fix(#277): MCP accept pins a routable peer + accept flags loopback-only reply path #331 — the operator-experience half this issue actually raised:
  1. MCP wire_accept was writing an unroutable pin — still the flat peers[h]={relay_url,slot_id,slot_token} shape Part B no longer reads, so a peer accepted over MCP got an empty endpoints[] and wire send couldn't route to them. Now pins via endpoints[] like the CLI path.
  2. Accept reported bilateral_accepted on an unreachable reply path — exactly your report. Both wire accept (CLI) and MCP accept now surface reply_path_reachable: false (+ a CLI remediation warning) when the peer advertised only loopback/same-host endpoints. The check infers reachability from the URL, so a loopback address mislabeled scope:"federation" (the saffron-burrow churn case) is still caught.

The general cache-vs-directory point (send resolves the local endpoints[] pin, dial/whois resolve the live .well-known) stands as documented earlier — not a Part-B violation. Closing as resolved; reopen if a divergence shows up with a fresh pin.