Relay protocol fidelity: reuse iroh's relay wire protocol or define a component-iroh flavor

[lann]

The endpoint keeps a secure WebSocket open to its home relay (via lann:websocket) and uses relays for QAD-style address discovery, fallback data, and — new in component-iroh — WebRTC signaling for browser legs.

To determine:

• How much of iroh's relay wire protocol (the relay handshake, framing, QAD probes per draft-ietf-quic-address-discovery) is reusable verbatim over a WebSocket the component drives itself. Interop target: a stock number-0-style relay serving component-iroh clients unmodified.
• Whether QAD probes even apply on non-UDP targets (a browser has no public UDP address to discover) — the browser leg may need only the relay's forwarding + signaling roles.
• Where WebRTC signaling rides: an ALPN/protocol on the relay connection, a sidecar protocol between the two peers through the relay, or a relay extension. Prefer whatever keeps stock relays usable, even if signaling then needs the peers to gossip through the relay's existing forwarding path.
• Whether self-hosted relay requirements (if any) are worth a relay component of our own — a relay is itself a natural Wasmtime-hosted component.

Outcome: a recorded compatibility matrix (stock relay vs. component-iroh relay features) and the signaling transport ruling.

[lann]

The spike now exercises the relay leg end to end via lann:websocket (the sibling reached testable state at 7b99e72; the spike pins it in scripts/setup.sh). What exists, and what it does and does not answer here:

What landed (relayd/ + the guest's signaling rework, then the transport enum):

• Each peer opens one WebSocket to iroh-spike-relayd, a room-pairing frame forwarder (bounded buffering while the peer is absent, text and binary forwarded blindly).
• Signaling rides that connection — identities, SDP, trickled ICE as JSON text frames, with a done sentinel replacing the old HTTP mailbox's done state. The host-implemented rendezvous import is gone; signaling is guest code over the standard websocket surface, which answers this issue's third bullet for the spike's scope: signaling is a sidecar protocol between the two peers through the relay's existing forwarding path — nothing relay-specific, so any frame-forwarding relay serves it.
• QUIC runs over the relay itself (--transport relay): datagrams as binary frames on the same connection, the relay never holding connection keys. All four wasmtime/jco client/server pairings pass on both wires.

What this deliberately is not: iroh's relay wire protocol. No relay handshake, no framing compatibility, no QAD, no per-peer authentication, one shared relay rather than a home relay per peer. relayd is the component-iroh-flavor strawman, not the ruling — the stock-number-0-interop question (first bullet) is untouched and stays open.

Two observations feeding the eventual ruling:

• The relay-wire QUIC handshake completes in ~1 ms wasmtime↔wasmtime on loopback (details in Measure handshake latency through the WIT crypto boundary #4) — the double-encryption cost of QUIC-over-WSS-over-the-relay is not visible at this scale; a real budget needs the bench harness.
• The relay wire is reliable and ordered, which QUIC tolerates but which reintroduces the TCP-over-TCP head-of-line concern in a form the data-channel wire was configured to avoid; whatever the relay framing ruling is, it inherits issue QUIC-over-data-channel mechanics: MTU, SCTP configuration, congestion interaction #1's congestion-stacking question in WebSocket form.

Also relevant to the fourth bullet: relayd is currently a native tokio binary, but nothing in it needs to be — it speaks only WebSocket and would compose as a wasm component once a server-side accept surface exists (lann:websocket is client-only today).

[lann]

The first bullet is now answered empirically: a stock number-0-style relay serves component-iroh clients unmodified. The spike's relayd strawman is retired (b247395); the guest speaks iroh's actual relay wire protocol to an untouched iroh-relay --dev (upstream v1.0.3, pinned in scripts/setup.sh), over lann:websocket:

• Connection: ws://…/relay with the iroh-relay-v2/-v1 subprotocol offer — the relay protocol is WebSocket-framed on every path upstream (native tokio-websockets, browser ws_stream_wasm), so the browser-shaped lann:websocket surface carries it without loss.
• Authentication: the challenge-response path (ServerChallenge → ClientAuth with an Ed25519 signature over blake3::derive_key("iroh-relay handshake v1 challenge signature", challenge)). This is the path upstream keeps because browsers cannot do the TLS-exporter shortcut (RFC 5705 keying-material extraction) — and lann:websocket deliberately exposes nothing below the browser API, so the constraint is identical and the maintained path is the one we need. The challenge signature comes straight from the webcrypto identity handle; the relay authenticates the same key that is our endpoint ID.
• Framing: client-to-relay-datagram / relay-to-client-datagram(-batch) frames, ping/pong answered, status/restarting tolerated. Encodings are pinned by known-answer tests in guest/src/relay_frames.rs mirroring upstream's own snapshot vectors (iroh-relay/src/protos/relay.rs tests).
• Addressing: pairing by endpoint ID replaces the demo's room+hello model. A server learns its peer from the relay-authenticated datagram source and cross-checks it against the TLS-authenticated handshake key; the client pins both to the --peer argument. The identity story collapses to iroh's own.
• Both wires: the relay wire carries raw QUIC packets in datagram frames (upstream's own use of the relay — nothing component-iroh-specific on that path); the WebRTC wire's SDP/ICE signaling rides as zero-prefixed signal datagrams between the two peers (a valid QUIC first byte always has the fixed bit set, so the discrimination is unambiguous, and an upstream client would simply drop them as non-QUIC). All four wasmtime/jco client/server pairings pass on both wires.

Still open in this issue, now sharper:

• QAD (second bullet): untouched, and the dev-mode server doesn't serve the QUIC endpoint anyway. The browser-leg question (no public UDP address to discover) stands.
• Home relays and relay racing: the demo uses one shared relay both peers dial; per-peer home relays and the connection-establishment choreography around them are endpoint-layer work, not relay-protocol work.
• Signaling transport ruling (third bullet): the spike's answer — a sidecar datagram protocol between the peers through the relay's existing forwarding — keeps stock relays usable with zero extension, at the cost of the prefix byte convention. Whether that convention should instead be an ALPN-style envelope is a design decision for the endpoint surface (Design the exported endpoint WIT surface #3), but nothing about it requires relay cooperation.
• wss against a production relay: the spike runs --dev (plain ws). The wss path exercises lann:websocket's TLS posture and any proxy behavior; worth one run against a hosted relay before calling the compatibility matrix done.

[lann]

Ruling recorded (the third bullet): WebRTC signaling rides the relay's existing forwarding path as a sidecar convention between the peers — one JSON signal (offer/answer/candidate/end-of-candidates/done) per relay datagram, marked by a leading 0x00 byte, which is never a valid first byte of a QUIC packet (fixed bit). Stock relays forward it unmodified; nothing relay-side changes. Landed behind the endpoint surface in adb8caf (endpoint/src/webrtc.rs documents the convention; the spike proved it first). The identity story: signals carry no identities — the relay authenticates each datagram's source, and connections accepted over a signaled channel must TLS-authenticate as that source. Still open here: relay handshake/framing fidelity questions, wss, QAD applicability, and the stock-vs-component relay compatibility matrix.