General comparison¶
18 architectures, without an absolute ranking. Follow property definitions and references for evidence.
| Messenger | E2EE | Account identifier | Metadata exposure | IP exposure to peer | Main weakness |
|---|---|---|---|---|---|
| Signal | E2EEMature E2EE for messages and calls; endpoint security remains crucial. [1] [2] | Account identifierRegistration phone number; optional username. [1] [2] | Metadata exposureService knows the number; some account dates were publicly disclosed. [1] [2] | IP exposure to peerCalls can be relayed; check the setting and actual network path. [1] [2] | Main weaknessMandatory number known to the provider and telecom layer. [1] [2] |
| SimpleX | E2EEDouble Ratchet E2EE; message padding is declared. [1] [2] | Account identifierLocal profile; relationship-specific invitations. [1] [2] | Metadata exposureNo global account; relays, queues, timing and iOS push remain exposure surfaces. [1] [2] | IP exposure to peerDefault TURN hides IP from the peer; P2P can reveal it. [1] [2] | Main weaknessMore multi-device friction; relays and notifications require care. [1] [2] |
| Olvid | E2EEFormally studied protocol under limited assumptions; not an audit of the entire 2026 system. [1] [2] | Account identifierCryptographic identity; no mandatory phone or email. [1] [2] | Metadata exposureRouting keys, sizes and timing visible in the formal model. [1] [2] | IP exposure to peerDocumented TURN-only calls: IP hidden from the peer, visible to the relay. [1] [2] | Main weaknessNo network anonymity; calls and multi-device require a licence. [1] [2] |
| Session | E2EEProtocol V1: WOOT 2026 findings; current fixes and retests not established. [1] [2] | Account identifierRandom ID without a phone number; onion routing for messages. [1] [2] | Metadata exposureNodes and relays see their portion of traffic; calls expose IP. [1] [2] | IP exposure to peerBeta P2P calls: IP exposed to peer and managed STUN/TURN. [1] [2] | Main weaknessProtocol V1 attacks and unknown fix / retest status; calls expose IP. [1] [2] |
| Threema | E2EEE2EE; properties depend on the client, particularly desktop beta. [1] [2] | Account identifierRandom Threema ID; optional phone and email. [1] [2] | Metadata exposureID, connection data and optional identifiers; store purchase may link identities. [1] [2] | IP exposure to peerCheck calling mode and relay per client and configuration. [1] [2] | Main weaknessDesktop beta limits, account data and linkable purchases. [1] [2] |
| Cwtch | E2EEE2EE through onion services according to published design. [1] [2] | Account identifierLocal / onion profile; no phone or email required. [1] [2] | Metadata exposureReduced central concentration; presence and traffic correlation remain possible. [1] [2] | IP exposure to peerMessages through onion; no established calls; Tor does not defeat a global observer. [1] [2] | Main weaknessNo iOS; niche ecosystem and more limited assurance. [1] [2] |
| Briar | E2EEE2EE; Tor and local Android transports. [1] [2] | Account identifierLocal identity; contacts in person or through invitation. [1] [2] | Metadata exposureLess centralisation; local / Tor network and endpoints remain observable. [1] [2] | IP exposure to peerTor or local transports; no calls; global correlation remains unresolved. [1] [2] | Main weaknessNo iOS or calls; essential maintenance since July 2026. [1] [2] |
| Jami | E2EEEncryption depends on client protocols and features. [1] [2] | Account identifierKey / DHT-P2P identity. [1] [2] | Metadata exposureDHT, bootstrap, NAT and peers see their portion of the network. [1] [2] | IP exposure to peerP2P can reveal IP; check calling paths. [1] [2] | Main weaknessIP, availability, DHT and uneven version-specific assurance. [1] [2] |
| Tox / qTox | E2EETox E2EE; operational guarantees depend on each client. [1] [2] | Account identifierPublic key / Tox ID; protocol and clients are distinct. [1] [2] | Metadata exposureDHT and peers; persistent ID linkable through reuse. [1] [2] | IP exposure to peerP2P connections and calls can reveal IP. [1] [2] | Main weaknessMobile clients, forks and maintenance are not interchangeable. [1] [2] |
| Matrix / Element | E2EEE2EE per room / client; not automatic everywhere. [1] [2] | Account identifierMXID @name:server; chosen homeserver. [1] [2] | Metadata exposureHomeserver sees account, devices, membership, events and IP. [1] [2] | IP exposure to peerDirect WebRTC or TURN/SFU; SFU operator sees IP and metadata. [1] [2] | Main weaknessSelf-hosting does not remove metadata, push or unencrypted-room risks. [1] [2] |
| XMPP / OMEMO | E2EEOMEMO when enabled, compatible and keys verified. [1] [2] | Account identifierJID on a domain / server; selected clients. [1] [2] | Metadata exposureServer sees JID, presence, connections and roster depending on extensions. [1] [2] | IP exposure to peerJingle/ICE may be direct; TURN hides IP from the peer. [1] [2] | Main weaknessNo universal conclusion without specific client, version and server. [1] [2] |
| Telegram | E2EECloud Chats / groups are not E2EE; separate device-bound Secret Chats. [1] [2] | Account identifierRequired phone number; optional username. [1] [2] | Metadata exposureProvider can process cloud messages and metadata. [1] [2] | IP exposure to peerDirect or relayed calls depending on setting / network. [1] [2] | Main weaknessDoes not protect cloud text from the provider. [1] [2] |
| E2EEDefault E2EE for personal messages and calls; backups need consideration. [1] [2] | Account identifierPhone number, address book and Meta ecosystem. [1] [2] | Metadata exposureNumber, usage graph, IP and service information remain exposure surfaces. [1] [2] | IP exposure to peerCalls can use a relay; Meta remains the central operator. [1] [2] | Main weaknessStrong linkage to phone number, accounts and metadata. [1] [2] | |
| Discord | E2EEText and DMs are not E2EE; DAVE covers eligible media only. [1] [2] | Account identifierAccount / username; email and sometimes phone. [1] [2] | Metadata exposureMessages, accounts, servers and membership visible to the platform. [1] [2] | IP exposure to peerCalls generally relayed; IP visible to the voice service. [1] [2] | Main weaknessPlatform can read text; moving apps does not erase the initial meeting. [1] [2] |
| Wire | E2EEE2EE in the product; audits and partially public code. [1] [2] | Account identifierAccount, email / phone depending on offering and registration. [1] [2] | Metadata exposureAccount, IP and service data remain. [1] [2] | IP exposure to peerDirect or relayed calls depending on service and configuration. [1] [2] | Main weaknessLinkable account email; product audit is not backend / binary verification. [1] [2] |
| Delta Chat | E2EEAutocrypt; E2EE depends on contact and conversation. [1] [2] | Account identifierEmail / chatmail address and local profile. [1] [2] | Metadata exposureEmail operator sees addresses, headers, timing and volumes. [1] [2] | IP exposure to peerWebRTC calls may be P2P and disclose IP. [1] [2] | Main weaknessEmail metadata; conversation-dependent E2EE assurance. [1] [2] |
| Ricochet Refresh | E2EETor onion channel; insufficient current ratchet assurance. [1] [2] | Account identifierOnion-service identity; no phone or email required. [1] [2] | Metadata exposureNo single account provider; Tor and endpoints remain. [1] [2] | IP exposure to peerOnion hides IP on the normal path; no established calls. [1] [2] | Main weaknessLow maturity / activity; historical Ricochet audit cannot be transferred. [1] [2] |
| Status / Waku | E2EEDeclared E2EE; assurance depends on protocol and version. [1] [2] | Account identifierWallet / key profile, depending on features. [1] [2] | Metadata exposureManaged nodes can see IP, topics and activity. [1] [2] | IP exposure to peerCurrent calls and network exposure not established as an advantage. [1] [2] | Main weaknessPersistent identity; actual operators, builds and clients need verification. [1] [2] |
The detailed evidence is maintained in the French Phase 2 register. The translation is a restatement, not new evidence.