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.
nostr:nevent1qvzqqqqqqypzpwleyw4fy3sxt7yvgrran0mpenxqlululur94r9jlax0hd3q3rc7qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqypvwqh84uq76vdjhaa9ekn4tt0trwuw2kkc5htsxz2jasezmmcht60p280p
Keychat
npub1h0…srwx8
2025-06-21 05:15:18 UTC
Author Public Key
npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8Published at
2025-06-21 05:15:18 UTCEvent JSON
{
"id": "e76ead1e7f100e62cd09ccfac87c6eac585e5967c466954e995d58063a43a391",
"pubkey": "bbf923aa9246065f88c40c7d9bf61cccc0ff3fcff065a8cb2ff4cfbb62088f1e",
"created_at": 1750482918,
"kind": 1,
"tags": [
[
"q",
"58e05cf5e03da63657ef4b9b4eab5bd63771cab5b14bae0612a5d8645bde2ebd",
"wss://nos.lol/"
],
[
"client",
"jumble"
]
],
"content": "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:\n\n1 · Peer-discovery exchange\n\nEach endpoint relies on HyperDHT ( Distributed Hash Table) to locate the other party:\n\nThe caller joins the network with the callee’s 32-byte Ed25519 public key.\n\nNearby DHT nodes return the latest announce record published by that key—essentially “I’m online at 203.0.113.7:54567”.\n\nA short-lived, signed invitation token proves the request really comes from the owner of the calling key, preventing spam.\n\nNo central signaling server is involved; the DHT itself is the rendez-vous layer.\n\n2 · Distributed hole-punch — DHP → direct connection\n\nThe two devices attempt to break through their NATs with DHP (Distributed Hole Punching) and then talk over UDX (Ultra-Datagram eXchange):\n\nEach 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.\n\nBoth endpoints fire simultaneous UDX probes at every candidate (IP:port) they learn.\n\nAs 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.\n\nIn 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.\n\n3 · Volunteer relay fallback\n\nIf symmetric NAT (Network Address Translation), CGNAT (Carrier-Grade NAT), or a strict firewall blocks every hole-punch attempt:\nKeet asks nearby peers whether any is willing to act as a relay for this call.\n\nIf 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.\n\nWhen 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.\n\nnostr:nevent1qvzqqqqqqypzpwleyw4fy3sxt7yvgrran0mpenxqlululur94r9jlax0hd3q3rc7qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqypvwqh84uq76vdjhaa9ekn4tt0trwuw2kkc5htsxz2jasezmmcht60p280p",
"sig": "4b851f15f9bb321aa72210860dec01d3a8f62211b60390d691f1d4b4f33dccfcec2381ace6c5a76283359a2a78aa632b6907aff154ade867168c29581e9808d0"
}