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.