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§
- Relay
Acceptor - Accepts INTRODUCED relay circuits: turns a server-role
RelayTunnel(delivered byRelayStatus::enable_accept) into an authenticatedPeerConnectionby running the SERVER half of the dig-tls mTLS handshake over it.