Background

How the Tox DHT works

Centralised messengers have an easy job: everyone connects to the same servers, so the server always knows where everyone is. Tox has no such server, which leaves it with a harder problem — how does your client find one specific person on a network with no directory?

The distributed hash table

A hash table maps keys to values. A distributed hash table does the same thing with the table spread across thousands of machines, none of which holds all of it. In Tox, the key is a public key and the value is the address currently answering for it.

Each participating node keeps a small portion of the table plus a list of other nodes it knows about, weighted towards keys close to its own. Asking the network to resolve a key means asking a node you already know; if it doesn't have the answer, it hands back nodes closer to the target. You repeat, and each hop narrows the distance. A handful of rounds gets you to whoever holds the record — without any single machine ever holding the whole directory.

This is what makes Tox hard to switch off. There is no address to seize and no company to serve an order on. It also means there is no operator who could hand over your message history, because no operator has one.

The chicken-and-egg problem, and why bootstrap nodes exist

To ask the DHT anything, you need to know at least one node already in it. A freshly installed client knows nobody. That is the bootstrapping problem, and it is solved the boring way: clients ship with a list of nodes that are reliably online.

A bootstrap node has to be predictable in four ways at once — always online, stable address, stable port, permanent public key. Ordinary clients fail all four. People close their laptops, home IP addresses rotate, and most clients generate a new DHT key on every launch. So the network relies on dedicated daemons that do nothing else. They run a stripped-down build with none of the messaging features: no chat, no calls, no file transfer, just enough networking to answer "who else do you know?"

Your client contacts several of them at once, collects a first batch of peers, and from that point navigates the DHT on its own. The bootstrap node has done its job within seconds of startup and is not involved in anything that follows.

From lookup to conversation

1. Bootstrap. Your client sends a query to the nodes on its list — including this one, if you added it — and gets back a set of live peers.
2. Search. It walks the DHT looking for the key belonging to each of your contacts, hopping towards nodes closer to that key until it finds who currently holds the record.
3. Locate. The record gives your contact's current address and port.
4. Handshake. Your client and theirs establish a shared secret from their two keypairs using Curve25519. Neither key ever crosses the wire, and no third party — including this node — can derive the result.
5. Talk. Messages, files and call audio travel directly between you, encrypted with XSalsa20 and authenticated with Poly1305. Every packet is checked for tampering as well as secrecy.

The important detail is what step 5 does not involve. Once the handshake is done, the DHT is out of the picture. Your traffic goes from your machine to theirs. No node in the middle sees plaintext, and no node in the middle is even asked.

Two identities, two lifetimes

Tox gives you two keys and confusing them causes most of the setup problems people run into.

TCP relays and hostile networks

All of the above assumes UDP works. Frequently it doesn't. University networks, hotel Wi-Fi, corporate firewalls and some mobile carriers block or mangle UDP, and a client that can only speak UDP is simply cut off.

TCP relays are the fallback. Your client opens an ordinary TCP connection to a relay, and the relay forwards encrypted packets between you and your peer. The relay is a postal service handling sealed envelopes: it knows an envelope moved from one address to another and how big it was, and it cannot open any of them. Encryption is established end to end during the handshake, before the relay is ever involved.

This node relays on ports 443, 3389 and 33445. The first two are chosen for exactly one reason — restrictive networks tend to leave them open, because blocking them breaks other things people need. Neither is running the service the port number suggests. On a network you don't administer, be aware that traffic on 3389 in particular tends to draw attention from monitoring tools.

Relaying costs latency and bandwidth compared to a direct connection, so clients prefer direct and fall back to relays. If you are on a network that blocks UDP entirely, forcing TCP-only mode in your client's settings will connect you faster than letting it discover the problem itself.

Where the design has limits

Being honest about this is more useful than a feature list. Direct peer-to-peer connections mean your contacts learn your IP address — that is not a bug, it is how the packets find you. With no server to hold messages, anything you send to an offline contact waits in your own client until they come back. And while the DHT is hard to take down, it is not invisible: an observer who can watch your traffic can see that you are speaking Tox, even if they cannot see a word of it. Deep packet inspection blocks Tox in several countries today.

None of that makes Tox a bad choice. It makes it a specific one, suited to some threat models and not others. The privacy and limits page goes through which is which.