Two released nodes can't key a pair room: peers stay ADVISORY, frames fail the transport-destination binding, the KeyPackage never replicates

[emooreatx]

What was measured

2026-09-28, CIRISClient's two-node test fixture (testing/gate/two_node.py, a Docker-free port of harness/mesh-repro/scenarios/chat.sh) on v0.5.217, the binary the client's five-platform live QA downloads. Two fresh nodes on one host (4242/4243 and 5242/5243), separate homes, unique key ids.

Everything up to the room succeeds: owner claim on both, announce, peering both ways (via the production self-key-record route), owner-key replication, and POST /v1/contacts on each side. The pair room then stays chat.state.awaiting_peer for 480 s:

• each node admits the other advisory, not conferred;
• inbound frames fail no hybrid-verified SignedTransportDestination binds this (peer, dest) pair (CIRISEdge#393 item 2);
• the joiner's KeyPackage never replicates.

harness/mesh-repro's chat ladder is green only on a test-anchor build with a test trust root (test-blessed-self-record / test-admit-peer are cfg(feature = "test-anchor")), so the server's own gate doesn't cover this path on a released binary.

Question

Is this expected for two unconferred released nodes? If so:

• how do two real people on their own released nodes key a pair room (what confers the peers), and
• could harnesses get a released knob for a test trust root, so client QA can exercise chat against the binary users run?

If it isn't expected, this is a repro.

Client impact

CIRISClient CSD-091's "a room with a real message" can't pass on the matrix; recorded in evidence/blocked_upstream.tsv, closes when the fixture reports message_arrived=true against a released binary.

Also noticed: scratch nodes on the released binary dial the public canonical by default, so CI fixture nodes contact the production mesh. Is there a supported way to run a node with no default bootstrap (tests, air-gapped setups)?

🤖 Generated with Claude Code

[emooreatx]

Measured today with a Docker-free two-node fixture under the synthetic trust root (harness/native on chore/adopt-edge-v33, the 0.5.218 + edge v33.1 tree; each run boots two claimed nodes plus a canonical in ~10 s, production peering routes only: self-key-record → /v1/federation/peering → /v1/contacts → /v1/chat). Seven runs, ~3 min each. Two separate effects, neither of them "unconferred peers":

1. The pair room keys without a shared root. Every run: peers admitted ADVISORY (that is attribution, not trust — CIRISEdge#659), rooted_with says no valid root in common the whole time, and the room still keys in ~7 s after both contacts exist. So conferral/rooting is not what gates the handshake on this tree. The SignedTransportDestination failures you measured on v0.5.217 did not appear here; 0.5.218 carries the replication-kind and transport-row fixes (Replication runs 6 of 17 envelope kinds: community member additions, households and device revocations never leave the node #646, Adopt CIRISEdge v25.0.0 (tagged, 60771b1) — UnopenedReason, RoomKey deleted, BlobPointer.epoch, the BlobPuller you must spawn, and send-by-room #602), so that half is likely release-bound. I can confirm by running this fixture against a test-anchor build of v0.5.217.

2. A race that produces a room whose messages never open. If POST /v1/contacts is made while the reply says reachable_nodes: 0 (the peer's owner→node binding has not yet reached this node at federation scope; ~12 s after peering here), the room keys anyway, the body crosses, and the recipient's transcript shows the row as unopened_reason: not_granted ("this viewer holds no key for ") — still after 5+ minutes. Re-adding the contact until reachable_nodes >= 1 before opening the room makes the same flow pass end to end in 33 s (row + body on the other person's node 2 s after send). The client's fixture waits for the peer's owner KEY to be known, which is earlier than the binding, so it sits exactly in this window. Server fix candidates: refuse /v1/contacts by name while reachable_nodes == 0 (the client retries), or re-issue the epoch's key grants when the binding lands. Filing separately.

3. Scoped content is one-hop. Two nodes that reach each other only through the canonical key the room but the body never crosses: scope-native send: derived destination did not establish … only a directly-attached neighbour answers (CC 5.4.6, CIRISEdge#499). With the peer also dialling the other node directly, it crosses. The client fixture already has the peer dial the leg's node directly, so it is not hit by this; two phones behind the canonical would be. That is a design question for edge, not a repro here.

On the last question: under a test anchor (CIRIS_TESTING_MODE + the anchor block, test-anchor build) a node dials only net.bootstrap_peers, so the fixture never touches production. A released binary has no such knob today.

🤖 Generated with Claude Code