SimpleX
Official website (opens in a new tab)
The messaging app that takes data minimization the furthest — no global identifier, not even a persistent public key — at the expense of authentication and ease of use.
At a glance
• End-to-end encryption — ✅ Good
• End-to-end authentication — ❌ Poor
• End-to-end security — ❌ Poor
• No identity substitution — ✅ Good
• Open source client — ✅ Good
• End-to-end multi-device — ➖ Not applicable
• Minimal personal data — ✅ Good
• No contact discovery and spam — ✅ Good
• Post-quantum encryption — 🟠 Partial
SimpleX Chat takes data minimization particularly far: not only is no personal data requested, but the user has no global identifier, not even a persistent public keyarchived. Each conversation relies on identifiers dedicated to that relationship (what SimpleX calls “per-queue identifiers,” which work like anonymous inboxes), and they differ from one conversation to the next. As a result, two contacts of the same user cannot tell from network metadata that they are talking to the same person. The user can also choose the servers that relay their messages, and two-hop routing (the user’s device goes through intermediate relay servers and does not connect directly to the recipient’s server) hides their IP address from their contacts’ serversarchived.
This design has a direct consequence: without a stable identifier, there is nothing a user can authenticate once and for all about a contact. Connecting relies entirely on invitation links, and its security comes down to that of the channel the link travels through. It also strips introductions by a third party of any guarantee: the feature exists (a group’s host uses it to connect the members with one another), but with no identity to vouch for, a contact cannot vouch for anything. The entire security of a relationship is therefore decided when it is established, with no way to strengthen it afterwards other than through an optional manual verification.
Anonymity versus authentication
SimpleX’s stance is to favor anonymity by removing the very notion of a profile identifier. There is thus naturally no possible identity substitution (there is nothing to substitute), but there is also nothing another user could vouch for. Relationships are compartmentalized, which makes the social graph particularly hard for servers to establish. The philosophy is consistent, and it protects anonymity remarkably well. But the goal of a secure messaging app, as this benchmark defines it, is to know who you are talking to and to be sure no one else can listen in. A relationship established face to face, by scanning a QR code, is indeed authenticated once and for all. But that certainty belongs only to the two people involved: without a transferable identity, it can be neither passed on nor vouched for to a third party, and any remote connection is only worth as much as the channel carrying it. A trade-off between maximum anonymity and usable authentication is inevitable: SimpleX has chosen the former.
End-to-end encryption ✅ Good
Communications are end-to-end encrypted, in every chat, with no option to turn encryption off and with continuous key renewal (double ratchetarchived).
End-to-end authentication ❌ Poor
Adding a contact goes through an invitation link, which comes in two formsarchived. The contact address, which is long-lived, can be published: anyone can then request a connection, and there is no way of knowing who is behind the request. The one-time invitation link, on the other hand, is consumed by the first person who uses it: scanned as a QR code face to face, it provides proper authentication; sent through any other channel (email, SMS, another messaging app), it inherits that channel’s insecurity, and whoever intercepts it can take the place of the expected contact. No two-way verification is required: an optional after-the-fact security-code verification exists, as on Signal or WhatsApp. Authentication is therefore never guaranteed by construction: for each new connection, it depends on the user’s caution and on the channel chosen. The same holds for groups, which one typically joins through a shared link, without any member being authenticated.
End-to-end security ❌ Poor
End-to-end encryption is indeed provided, but authentication is not systematic: this criterion is therefore not met.
No identity substitution ✅ Good
SimpleX solves this problem by removing any global identifier. There is therefore no need for a directory, since there is no identifier to associate. Each relationship with a contact relies on its own queues and its own keys. The criterion is met through a radical approach. The flip side of SimpleX’s technological choices is described in the No identity substitution criterion: without a stable identity, an introduction by a mutual contact brings no guarantee, and the trust a user places in their contacts cannot be passed on to a third party. It is therefore not possible to build a real web of trust.
Open source client ✅ Good
The clients (and the servers) are published under an open source license (AGPLv3)archived, and the protocol is documented in detailarchived.
End-to-end multi-device ➖ Not applicable
The desktop application works in two modes, neither of which amounts to multi-device in the criterion’s sense. It can host its own profiles, independent of those on the phone: each of them a distinct identity, not a shared one. It can also act as a remote control for the mobile app, to which it links directly, which requires the two devices to be on the same local networkarchived: this mode places no trust in the server, which is consistent with the model, but the computer holds no identity of its own and depends entirely on the phone. The same identity therefore cannot live on several autonomous devices: by our definition, SimpleX offers no multi-device support, hence the ➖Not applicable “not applicable” rating.
Minimal personal data ✅ Good
No name, no email, no phone number; not even a global account identifier. The server sees only anonymous queues, which fragments the social graph a relay server can normally observe; the user can also spread their queues across different servers, including their own.
No contact discovery and spam ✅ Good
There is neither a directory nor an identifier through which to find someone: first contact requires a link created and passed on by the user themselves. However, if the user decides to publish a contact address (on a website, a social network), then solicitations from strangers become possible, with contact-request confirmation as the only barrier. That is an explicit choice by the user, though, which the criterion allows.
Post-quantum encryption 🟠 Partial
Since version 5.7 (April 2024), direct chats have benefited by default from a hybrid post-quantum double ratchetarchived, which adds the sntrup761 algorithm to the classical key exchange. Group chats do not benefit from it yet, hence the 🟠Partial: post-quantum encryption is indeed enabled by default, but not for all conversations.