Tox started in 2013 as a reaction to the Snowden disclosures. The goal was a messenger with no central operator that could be subpoenaed, no metadata warehouse, and no place where a single court order could turn the lights on. The protocol is implemented mainly in a C library called c-toxcore, and a handful of clients sit on top of it: qTox and Toxic on the desktop, aTox and Antox on Android. There is no company behind it and no funded security team, which matters later.
No server means your identity is a key
When you first launch a Tox client it generates a long-term key pair on your device. Your public identity is a Tox ID: the 32-byte public key, a 4-byte "nospam" value, and a 2-byte checksum, written out as 76 hexadecimal characters. You hand that string to someone out of band and they add you as a contact. There is nothing to register and nothing to recover, because there is no account stored anywhere but on your own disk.
The nospam bytes exist to limit friend-request spam. Because anyone who has your Tox ID can send a request, you can rotate the nospam portion to invalidate an ID you posted publicly, without changing your underlying key. Your contacts already hold your real public key, so they are unaffected.
With no account and no server-side recovery, losing your local key file means losing your identity. There is no "forgot password" path. This is the same self-custody trade-off seen in account recovery design: removing the operator removes the operator's ability to help you.
The cryptography: NaCl, end to end
Tox builds on the NaCl primitives, the same family used through libsodium. Key agreement uses Curve25519, symmetric encryption uses the XSalsa20 stream cipher, and integrity uses the Poly1305 authenticator. This is a conservative, well-studied stack, and it is the strongest part of the system. For the building blocks involved, see our pieces on elliptic-curve cryptography and authenticated encryption.
Each connection between two peers negotiates a temporary session key pair rather than encrypting directly under the long-term identity keys. That gives a degree of forward secrecy within a session: compromising the long-term key later does not by itself decrypt traffic captured under a past session key. It is weaker than the per-message ratcheting in the Double Ratchet, and you should not assume Tox gives you the same fine-grained post-compromise recovery that Signal-style protocols do.
Finding each other without a directory
A serverless network still has to solve the hard problem of two devices locating each other across the internet. Tox does this with a distributed hash table, a Kademlia-style structure where participating nodes store routing information for one another. To join, a client contacts one or more community-run bootstrap nodes, which are entry points into the DHT rather than message relays. Once you are in, the DHT helps you find the network address of a contact who is online.
The DHT introduces a privacy problem. If your client announced its identity key directly in the DHT, anyone observing it could map your key to your IP address. To blunt this, Tox routes friend-finding and friend requests through an onion-style path of intermediate nodes, so the lookup does not trivially reveal who is asking for whom. It is a meaningful mitigation, not a full anonymity system on the order of Tor.
What the design leaves exposed
Removing the server removes a metadata honeypot, but it does not remove metadata. Some of it simply moves to the edges.
| Property | Where Tox lands |
|---|---|
| Message contents | Strong. End-to-end encrypted with NaCl primitives. |
| IP exposure to contacts | Weak. Direct peer connections mean the people you talk to can generally see your IP address. |
| Offline messaging | Not supported. With no server to hold mail, a message generally requires both parties online. |
| Multi-device | Not supported. The identity key lives on one device; there is no native sync. |
| Formal audit | Limited. No comprehensive independent security audit of the kind larger projects have funded. |
The IP-exposure point is the one people underestimate. In a client-server messenger, the server sees your address and your contact sees a username. In Tox, because you connect peer to peer, a contact, or someone who has tricked you into a connection, can learn your network location. For a threat model that includes hiding your location from the people you message, that is a serious gap, and it is inherent to peer-to-peer design rather than a bug.
The lack of offline delivery is the usability cliff. Email works because a server holds your message until you connect. Tox has no such inbox, so a note sent while your contact is offline waits on your side until you are both online at once. Group chat has also been a long-running weak spot; older group implementations were limited, and newer group code has been added over time but does not carry the maturity of the one-to-one path.
Who Tox is actually for
Tox proves that a usable, fully decentralized encrypted messenger can exist. It does not prove that decentralization is free. Every property the server used to provide has to be rebuilt or given up.
Tox is a reasonable fit for a small group of technically comfortable people who want direct, no-account messaging and who are not trying to hide their location from each other. It is a poor fit if you need reliable delivery to offline contacts, multi-device sync, large audited group chats, or protection of your IP address from the parties you talk to. Compare it against the trade-offs in SimpleX, Briar, and Cwtch, each of which makes a different bet about where the metadata should go.
The honest summary is that Tox optimizes hard for one property, the absence of a central operator, and accepts the costs that follow from it. Knowing which costs you are accepting is the whole point of choosing a tool by its threat model rather than its slogan.