Keet uses the Holepunch stack—not WebRTC—for its real-time voice calls. In a one-to-one call the connection likewise falls into three logical stages:
1 · Peer-discovery exchange
Each endpoint relies on HyperDHT ( Distributed Hash Table) to locate the other party:
The caller joins the network with the callee’s 32-byte Ed25519 public key.
Nearby DHT nodes return the latest announce record published by that key—essentially “I’m online at 203.0.113.7:54567”.
A short-lived, signed invitation token proves the request really comes from the owner of the calling key, preventing spam.
No central signaling server is involved; the DHT itself is the rendez-vous layer.
2 · Distributed hole-punch — DHP → direct connection
The two devices attempt to break through their NATs with DHP (Distributed Hole Punching) and then talk over UDX (Ultra-Datagram eXchange):
Each side enlists several random DHT peers as hole-punch helpers—they play the same role that STUN servers do in WebRTC but are fully decentralized.
Both endpoints fire simultaneous UDX probes at every candidate (IP:port) they learn.
As soon as one path succeeds, a one-round-trip Noise_XX handshake derives a session key, and encrypted audio frames start flowing directly between devices.
In residential or mobile networks this succeeds ~70 %–80 % of the time, giving a pure P2P (peer-to-peer) path with minimal latency—no relay, no bandwidth fees.
3 · Volunteer relay fallback
If symmetric NAT (Network Address Translation), CGNAT (Carrier-Grade NAT), or a strict firewall blocks every hole-punch attempt:
Keet asks nearby peers whether any is willing to act as a relay for this call.
If at least one agrees, the audio stream is tunneled through that peer—still encrypted end-to-end by Noise—so neither relay nor network can eavesdrop.
When no volunteer relay is available, the call fails; Keet has no equivalent to TURN (Traversal Using Relays around NAT) hosted in a central data-center.
