Skip to main content

Module accept

Module accept 

Source
Expand description

The RESPONDER side of a relayed connection — run the server half of the mTLS handshake over an INTRODUCED relay circuit.

A relay circuit needs exactly one mTLS client and one mTLS server. The crate::dialer (MtlsDialer::dial) is the client: it opens a tunnel to the peer and runs PeerSession::client. This module is the missing counterpart: the reservation-HOLDER that RECEIVES an introduced circuit (RelayStatus::enable_accept surfaces it as a RelayTunnel) accepts it here and runs PeerSession::server behind a TlsAcceptor. Without this, both ends of a relay circuit acted as TLS client and the handshake deadlocked (got ClientHello when expecting ServerHello, #1536).

The accepted connection carries the IDENTICAL dig-tls mTLS as a direct one — the server verifies the client’s peer_id = SHA-256(SPKI DER) + rustls proof-of-possession + the #1204 BLS binding. A server does NOT pin a specific caller (it accepts any authenticated DIG peer); the caller’s verified identity is read from the handshake and reported on the returned PeerConnection.

Structs§

RelayAcceptor
Accepts INTRODUCED relay circuits: turns a server-role RelayTunnel (delivered by RelayStatus::enable_accept) into an authenticated PeerConnection by running the SERVER half of the dig-tls mTLS handshake over it.