simplex-chat/simplex-chat

1. The_Messaging_Network_That_Cannot_Count_Its_Users

The Messaging Network That Cannot Count Its Users

Most privacy messengers hide what you said. SimpleX hides the fact that you exist.

Key Takeaways

• SimpleX is the only mainstream messaging platform with no user identifiers of any kind — no phone numbers, usernames, emails, or random IDs.
• The platform's own operators cannot count how many people use it — a property no other major messenger shares.
• The architectural choice is not "better encryption." It is the elimination of identity as a stored artifact. Every other privacy messenger protects a user; SimpleX refuses to construct one in the first place.
• The series traces what this single design decision forces — in queues, in cryptography, in governance, and in the price the user pays.
• The payoff, measured behaviorally: 12 law-enforcement requests received in 2025; 0 records produced. That is not a marketing claim. It is the architectural residue.

---

"You were born without an account."

The line opens docs/WHY.md, the shortest file in the entire SimpleX repository — twenty lines, no code, no diagrams. It is also the most quoted line, because the rest of the project is the slow, technical vindication of it. I want to spend this series showing why that sentence is not rhetoric, why it produces a network with a measurable behavioral signature, and why every other "private messenger" you have used stops one architectural step short of where SimpleX begins.

A 100-million-user market with a population count of zero

When a company says "we have X million users," the number usually comes from a database column — a counter incremented on signup. Signal has phone numbers. Matrix has account IDs. Session has identity keys. Telegram has phone numbers or usernames. Even the privacy-first systems that reject *real* identities still hand out *pseudonymous* ones: a random number, a public key, a hash. The system needs the identifier to deliver the message. The identifier becomes the graph.

SimpleX has none of these. The README states the fact flatly:

"Unlike any other existing messaging platform, SimpleX has no identifiers assigned to the users — we do not even know how many people use SimpleX." (README.md, lines 195)

I want to sit with that sentence for a moment. The platform's own founders do not know the size of their user base. No other major messenger in the public market today can say this — not Proton Mail, not Threema, not Signal, not Wickr. The first architectural claim of this series, therefore, is a numerical one: the user-count column is empty, by design, and the absence is the product.

The mechanism is brutal and simple. To send Alice a message, Bob's client does not look up "Alice." It looks up a *queue* — a temporary, disposable, single-use container held on a relay server. Different conversations live in different queues, hosted on different servers, addressed by different opaque strings. There is no Alice-record anywhere. There is no address-book. The relay cannot answer the question "who do you know?" because the question literally has no referent in its data.

Why "encrypted but identified" still loses

The distinction matters because most privacy discussions conflate two different problems. *Content protection* is the property that an adversary cannot read your messages even if they intercept them. *Graph protection* is the property that an adversary cannot tell who you communicate with even if they monitor all the traffic. The two are independent. The first is solved by good end-to-end encryption — Signal, WhatsApp, iMessage, and SimpleX all do it competently. The second is the unsolved problem of the privacy-messenger industry, because every existing platform except SimpleX still ties content delivery to a persistent identifier.

This is why a privacy advocate who recommends "Signal with disappearing messages enabled and phone-number visibility turned off" has not actually solved the second problem. Th

7m / Article + audio

2. Why_Pairwise_Queues_Replace_Phone_Numbers

Why Pairwise Queues Replace Phone Numbers

The thing standing between your contacts and the server is not a user record. It is a disposable envelope — and the server throws it away the moment it's used.

Key Takeaways

• SimpleX has no user account on the server. The unit of addressing is the message queue, not the person.
• Every contact you have lives in a *different* unidirectional queue pair, with a different server and a different opaque address. The architecture explicitly breaks the social graph.
• Servers only hold messages in memory until delivery. They do not talk to each other. There is no global directory of users, queues, or servers.
• A 2022 security audit by Trail of Bits (October 2022) confirmed the implementation matches this design. The 2024 cryptographic review confirmed the design itself is sound.
• This structure has a behavioral consequence: 12 law-enforcement requests received in 2025, zero records produced (docs/TRANSPARENCY.md, Feb 2026 revision). The architecture is what makes the number possible.

---

Mohamedou Ould Salahi spent fifteen years in Guantánamo Bay without trial. His crime: a phone call to a relative in Afghanistan after he had lived in Germany for a decade. The connection graph — who called whom, when — was enough.

I open with this not to dramatize but to fix the threat model. End-to-end encryption protects the *content* of messages. It does nothing for the *graph*. If the server knows you and your contacts are connected, that knowledge is enough to render content protection academic. The README makes this point by citing Salahi explicitly, and the rest of the design is the architectural answer.

The thing that is not there

Most messaging systems model the world as:

User account ↔ Server ↔ User account

The account is the persistent object. It survives across conversations, across devices (in the well-designed systems), across handovers, across years. Even when the account is "anonymous," it is the unit the server uses to find you.

SimpleX replaces that with a different model:

Queue pair ↔ Server ↔ Queue pair

There is no account. The only persistent objects are *queues* — unidirectional, single-purpose message containers. Each connection between two users gets two queues, one in each direction, addressed by a different opaque string. Different contacts of the same user live in *different* queue pairs, often on *different* servers. The README states this directly:

"SimpleX uses pairwise per-queue identifiers (2 addresses for each unidirectional message queue, with an optional 3rd address for push notifications on iOS, 2 queues in each connection between the users). It makes observing the network graph on the application level more difficult, as for n users there can be up to n * (n-1) message queues." (README.md lines 283)

Let that quantity settle. n × (n−1) is the combinatorial explosion. A 100-user network has up to 9,900 queue pairs; a 1,000-user network has up to 999,000. None of those queues are interchangeable. None carry the same address twice. Even the *server* cannot tell that two queues belong to the same person — they look like two independent relay conversations to anyone observing at the transport layer.

This is the architectural claim. The rest of this chapter is the operational consequence.

The consequence: unlinkability by construction

The property most readers miss on first contact is *unlinkability*. When Alice talks to Bob through queue pair Q_AB and to Carol through queue pair Q_AC, the two queue pairs share no identifier — not on the wire, not in the relay, not in TLS metadata, not in any header visible to a passive observer. From Bob's perspective, the queue address he sees is the only such address Alice has ever used to talk to him. From Carol's perspective, the same. There is no shared identifier Bob and Carol can compare to confirm or deny that they both know Alice.

This is a stronger property than anonymity. Anonymity protects Alice's *real-world identity* — her name, her phone number. Unlinkability protects Alice's *social graph* — whether two of her contacts can confirm she is in common. Every messenger with a persistent user identifier (phone number, account ID, public key) fails the unlinkability test by construction: Bob and Carol can both look up Alice's identifier, and the answer is the same. SimpleX's pairwise queues make the lookup return a different address for each contact, so the answer is *never* the same.

This is why the README's FAQ entry on Signal is so pointed:

"Signal is a centralized platform that uses phone numbers to identify its users and their contacts. It means that while the content of your messages on Signal is protected with robust end

8m / Article + audio

3. Nine_Layers_Of_Denial

Nine Layers of Denial

You want your recipient to be able to forge your messages. That sentence is the entire cryptographic argument of this chapter, and most readers will fight it before they accept it.

Key Takeaways

• SimpleX implements nine distinct cryptographic and protocol defense layers in series — redundancy, not paranoia.
• Repudiation (deniability) is the design's signature property: the recipient can forge messages, so neither party can prove to a third party who said what.
• Post-quantum key exchange is added on every ratchet step as of v5.6 (March 2024) — Streamlined NTRU Prime hybridized with the Signal double ratchet.
• Private message routing (v5.8, June 2024) introduces 2-hop onion routing with four nested encryption layers that hide sender IP from recipient's relay and vice versa.
• Message padding to a fixed block size — only SimpleX, Cwtch, and the now-defunct Pond do this. Defeats size-based traffic analysis, the most powerful remaining side channel.

---

Here is the unfashionable claim I want to defend in this chapter: the cryptographic centerpiece of SimpleX is not the encryption itself. It is the *deniability* of the encryption. A reader who comes to this material expecting "unbreakable math protects you" will miss what is actually load-bearing. The math is good — but the math protects the *content*. The architecture protects the *fact that you communicated at all*. And the property that closes the loop is that a third party cannot prove, from the cryptography alone, who said what.

To a layperson that sounds like a bug. To the cypherpunk tradition that produced Signal, OTR, and now SimpleX, it is the point. The reason matters, and I will spend most of this chapter on it.

The nine layers, enumerated

The GLOSSARY (docs/GLOSSARY.md) lists the defense-in-depth explicitly. I reproduce and compress:

1. Double ratchet E2EE (Signal algorithm) per conversation — forward secrecy + post-compromise security. 2. Additional NaCl cryptobox E2EE layer per queue — redundancy against future multi-server routing and TLS compromise. 3. Inner server-to-recipient NaCl layer — no shared ciphertext between send and receive paths. 4. TLS 1.2/1.3 only with restricted ciphers (CHACHA20POLY1305_SHA256, Ed25519/Ed448, Curve25519/Curve448). 5. Out-of-band TLS certificate verification — MITM mitigation on the relay. 6. TLS-unique channel binding signed per-queue ephemeral key — replay defense. 7. Multi-layer message padding to fixed block size — size-based traffic analysis defeated. 8. Out-of-band key exchange via one-time invitation links/QR — MITM mitigation on client-client. 9. Manual and planned automatic queue rotation — long-term traffic-analysis defeat.

I want to flag layer 7 because it is the most under-discussed and the most consequential for ordinary users. Fixed-block-size padding is what kills size correlation. If you and I exchange a 53-byte "yes" and the next message is 2 KB, a passive observer who can see message sizes learns something — they learn the second message is not a "yes." SimpleX pads every message to a fixed size regardless of payload. The v5.6 blog post (March 2024) notes that only SimpleX, Cwtch, and the now-defunct Pond do this among major messengers. Every other mainstream platform leaks message size as a free side channel.

Repudiation: the part that reads wrong

Open the v5.6 post (blog/20240314-simplex-chat-v5-6-quantum-resistance-signal-double-ratchet-algorithm.md) and look at how the authors describe repudiation:

"The solution to that is well known to cryptographers — it is the quality of the encryption algorithms called 'repudiation', sometimes also called 'deniability'. This is the ability of the senders to plausibly deny having sent any messages, because cryptographic algorithms used to encrypt allow recipients forging these messages on their devices, so while the encryption proves authenticity of the message to the recipient, it cannot be used as a proof to any third party."

Read that twice. The cryptographic construction is *intentionally* designed so the recipient can manufacture a message indistinguishable from one I sent. The recipient knows the message is real (their end of the protocol authenticated it). A court, a journalist, a stalker with a warrant — none of them can distinguish a real message from a forged one because the cry

7m / Article + audio