feat: WebSocket / Secure WebSocket / WebRTC transports

[ch4r10t33r]

Why

Browser peers (js-libp2p in the browser, the bulk of consumer wallets) cannot use raw TCP or QUIC because browsers don't expose those APIs to JS. Every libp2p-in-browser peer reaches the network through one of three transports: WebSocket (/ws, /wss), WebTransport (/quic-v1/webtransport), or WebRTC (/webrtc-direct and /webrtc via signalling).

Tracking: #80

Sub-features

WebSocket / Secure WebSocket (/ws, /wss)

• RFC 6455 framing on top of TCP / TLS
• Multiaddr: /ip4/N/tcp/N/ws or /ip4/N/tcp/N/tls/sni/<host>/ws
• HTTP/1.1 upgrade handshake (GET / HTTP/1.1\r\nUpgrade: websocket\r\n…)
• Then carries multistream + Noise + muxer like raw TCP
• Server side: HTTP server that accepts upgrade requests and hands off the upgraded stream

WebRTC (/webrtc-direct)

• Spec: https://github.com/libp2p/specs/blob/master/webrtc/
• Browser-friendly (no signalling server, certificate verification via SDP fingerprint matching the libp2p peer key)
• Pure-Zig implementation is a multi-month effort — DTLS 1.2 + SCTP + ICE; vendoring a Zig WebRTC stack (if one exists) is the realistic path. Otherwise gate behind libc + a C lib (regresses feat: Noise XX security upgrade #36 purity claim — discuss before pursuing).

WebTransport (/quic-v1/webtransport)

• Builds on the QUIC stack already in zquic
• Extension on top of HTTP/3 — needs HTTP/3 server framing
• Pure-Zig viable; smaller than WebRTC

Recommended order

1. WebSocket + WSS first — straightforward HTTP upgrade, reuses existing TCP+TLS+Noise+muxer chain. Unblocks js-libp2p browser interop for many testnets.
2. WebTransport second — extends QUIC stack already in place.
3. WebRTC last — biggest implementation cost, partially overlaps with browser-only use cases.

Acceptance

• WebSocket round-trip with js-libp2p in a browser tab.
• WSS round-trip behind nginx terminating TLS.

[ch4r10t33r]

Status update from the 2026-06-11 spec-compliance audit. Splitting this umbrella by sub-transport:

• /ws (plain WebSocket) — landed in feat(transport/ws): WebSocket (/ws, RFC 6455) — first slice of #94 #190 (v0.1.17) + hardened in fix(transport/ws): close timing + injection + overflow holes #191 (v0.1.18, security audit follow-ups). RFC 6455 codec + handshake + framed Stream, masking, control frames, max-frame cap. Cross-impl tests against rust-libp2p / go-libp2p still TODO at the integration level but the codec is interop-ready.
• /wss (WebSocket over TLS) — still open. Per ws.zig:17 tcp_tls already lives in tree; this is a thin compose step (tcp_tls upgrade → wrap the secure stream with the existing ws.Stream). Tracked here.
• WebTransport (HTTP/3 over QUIC) — open, no code yet. Probably blocked on the generic Transport trait refactor in [S2] Generic Transport trait + Host.openStream public API #211.
• WebRTC / WebRTC-direct — open, no code yet. Requires DTLS+SCTP+ICE; non-trivial.

Suggest narrowing this issue to /wss specifically and filing separate issues for WebTransport and WebRTC if/when they become priorities. Happy to do that split if you confirm.