feat: add direct WebRTC browser support - #220
Draft
mickvandijke wants to merge 12 commits into
Draft
Conversation
This was referenced Sep 1, 2026
Draft
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a direct, gateway-free browser endpoint to ant-node.
Browser clients can cold-bootstrap from one self-contained WebRTC Direct multiaddress, authenticate the node's persistent ML-DSA identity, establish a fresh ML-KEM-derived application session, walk the DHT themselves, read immutable chunks, obtain signed storage quotes, and submit paid immutable writes directly to closest storage nodes.
The HTTP manifest used by the local demo carries bootstrap metadata only. It never proxies file bytes, performs lookup for the browser, or receives wallet secrets.
Companion browser client: ant-client#186
Architecture
Direct browser transport
Shared post-quantum application session
Browser protocol v4 removes the former plaintext v3 RPC channel and standalone ML-DSA HELLO challenge.
Before reading any RPC, the listener:
Every later request and response, including HELLO, FIND_NODE, GET_CHUNK, QUOTE_CHUNK, PUT_CHUNK, errors, headers, and raw chunk bytes, is protected with ordered ChaCha20-Poly1305 records. Per-direction 64-bit sequences reject replay and reordering. Malformed handshakes, wrong identities, modified ciphertext, unexpected sequences, and authentication failures close the association.
The client and node use the same ant-protocol handshake, key derivation, encrypted-record, framing, and bounds implementation. ant-node owns only the RPC adapter and request admission logic.
Security boundary
The multiaddress certificate fingerprint still authenticates the WebRTC DTLS connection. The application session independently authenticates the ANT peer ID and protects RPC plaintext with post-quantum-derived keys.
This means compromise of only the classical DTLS key is insufficient to impersonate the ANT node or decrypt captured application records. It does not make ICE, DTLS, SCTP, certificate handling, packet lengths, timing, availability, or the WebRTC stack itself post-quantum secure.
The session authenticates the node to the browser, not the browser user to the node. Client authority remains method-specific; paid storage still requires the normal wallet transaction and verifiable payment proof.
Browser RPC surface
The versioned browser protocol remains deliberately narrow:
The node reuses native quote, commitment, pricing, payment-proof, content-address verification, and PUT admission behavior. Browser sessions are not inserted into routing tables and cannot invoke arbitrary DHT operations.
Endpoint discovery and deployment
Coordinated draft stack
Draft dependencies are pinned by immutable Git SHA so this branch builds outside the sibling-worktree development setup.
Risk tier
Reason: this adds a public node transport/protocol and V2 DHT endpoint-discovery path. It intentionally reuses existing stored-data and payment formats.
Compatibility
Test evidence
Current-head protocol-v4 validation:
Earlier headless-Chromium and independently deployed public-testnet tests validated WebRTC connectivity, multi-node lookup, range streaming, and paid uploads under protocol v3. They remain useful transport evidence but do not validate v4. A matching v4 testnet must be deployed for the next real-browser run.
ADR
ADR-0009: Direct browser clients over WebRTC Direct now records:
The ADR remains Proposed pending human review.
New dependencies
Mitigation / rollback
Disable webrtc_direct.enabled or build without the default WebRTC feature. Native QUIC, existing ant-core/ant-cli clients, payment behavior, and stored data remain usable independently.
Remaining draft work