HIP: Handshake P2P Rendezvous and Authenticated Service Relay

[denuoweb]

Purpose

This HIP defines an optional Handshake rendezvous and authenticated relay system for peers that cannot accept direct inbound connections. The broad design covers several layers, but they are not one merge unit:

1. unnamed full-node rendezvous and relayed ordinary Handshake peer sessions (HNS_NODE_V1);
2. HNS-authorized named-service rendezvous;
3. the HNS_WEB_V1 transport and browser-origin rules; and
4. public-network routing, replication, abuse controls, and operator policy.

The node-rendezvous layer has the clearest network-level value and is the only layer currently submitted for upstream implementation review.

Current review scope

• Node-rendezvous hsd draft: net: add experimental HNS node rendezvous and relay hsd#960
• Exact node-rendezvous commit: https://github.com/denuoweb/hsd/tree/2fc40f1c61ff16a2f39d9514cd950d1560430ced
• Retained named-service/web checkpoint, not submitted upstream: hnsr: retain named-service and web checkpoint denuoweb/hsd#2
• Retained full Phase 2 research stack, not submitted upstream: hnsr: retain Phase 2 routing hardening checkpoint denuoweb/hsd#3
• Native Android diagnostic checkpoint: https://github.com/Denuo-Web/hns-dane-browser/tree/30137230e67f944861833ee5d6a7ac6783cf46d4

hsd #960 now stops before the named-service implementation. Named-service authorization and browser/web transport should receive separate proposals and threat-model review after the node layer is evaluated.

Evidence boundary

The node-only branch has 65 passing focused HNSR, Brontide, and network tests. Its eight-FullNode regtest exercises iterative discovery, four-copy route publication, reservation renewal and withdrawal, rendezvous loss, first-relay failover, bounded admission and queues, an inner Brontide session, 1,000 ordinary pings, and a mined block delivered only over the inner peer.

The retained research branches additionally exercise named services, bounded web transport, persistent routing, twelve local processes, saturation, and an Android protocol diagnostic. Those are engineering results from controlled environments, not evidence of independent operators or public-network readiness.

Deployment gates

Before any public-network proposal, the work still needs:

• independent multi-operator testnet trials and sustained churn/load measurements;
• Sybil, route-suppression, reservation-exhaustion, signature-exhaustion, and traffic-correlation review;
• relay incentive, reputation, payment, and abuse policy;
• RPC, address-manager, wallet/SPV, and production mobile lifecycle integration; and
• separate browser-origin, cookies, storage, permissions, and service-worker analysis for any web profile.

No permanent service-bit or packet-type assignments are requested by this draft. The implementation uses private experimental values and rejects mainnet.

Program relationship

See the canonical program architecture and review order. HNSR is independent of Native Recursive Name Coins and is a separate optional rendezvous track from the DNS relay/ODoH stack.

Requested review focus: @pinheadmz for protocol scope and @nodech for the node-rendezvous implementation.

[denuoweb]

@pinheadmz — requesting scope and protocol review of the node-rendezvous layer first. The implementation in handshake-org/hsd#960 has now been reduced to unnamed HNS_NODE_V1; named services and web transport are held out of that review.