What this section is about
Encrypted messaging makes sure only the intended recipients can read your communications. Not the platform, not your ISP, not anyone intercepting traffic. Modern E2EE goes beyond TLS to provide forward secrecy (compromise of a long-term key does not expose past session keys), post-compromise security (a compromised session heals after subsequent rounds), and varying degrees of metadata protection.
This section covers:
- Signal Protocol — the reference asynchronous E2EE design (X3DH/PQXDH + Double Ratchet + Sesame).
- Matrix — federated chat with Olm/Megolm; MLS profile in development.
- Nostr — public-key-rooted broadcast protocol; encrypted DMs via NIP-44, gift-wrapped DMs via NIP-17, group E2EE via Marmot Protocol (MLS over Nostr).
- Metadata-resistant designs — SimpleX, Session, Cwtch, Briar.
"Every company or individual is one court order away from needing to decide how long they are willing to spend behind bars for not sharing the data with the government." — Ungovernable.tech
The metadata problem
Encryption protects content. Metadata often reveals more:
| Data type | Example | Risk |
|---|---|---|
| Who | Alice → Bob | Social graph |
| When | Timestamp | Pattern of life |
| Where | IP address | Location |
| How | Device, client | Fingerprinting |
| Size | Message length | Traffic analysis |
Truly private systems address metadata, not just content.
Key technologies
Signal Protocol
The reference for asynchronous E2EE messaging. Deployed by Signal, WhatsApp (default since April 2016), Google Messages RCS (since 2020), and Meta's Messenger and Instagram DMs (rolled out 2023-2024 using a Signal-Protocol-derived design).
Core components:
- Double Ratchet — per-message key evolution; forward secrecy plus post-compromise security.
- X3DH (Extended Triple DH) — asynchronous initial key agreement. Replaced in Signal by PQXDH (initially X25519 + CRYSTALS-Kyber-1024) in 2023.
- Sesame — session management for multi-device.
How it works:
- Alice and Bob exchange long-term and one-time prekeys via the server.
- PQXDH/X3DH derives an initial shared secret asynchronously.
- Double Ratchet evolves a fresh key per message; deleted message keys protect past traffic; recovery after compromise requires fresh ratchet contributions that the attacker no longer observes.
Limitations:
- Signal app itself requires a phone number (metadata).
- Centralized servers (Signal, WhatsApp).
- Sealed sender hides the sender identity inside the envelope; the service still sees the recipient.
Matrix
A federated chat protocol with E2EE via Olm (1:1) and Megolm (groups).
Architecture:
- Homeservers store message history; users pick or self-host one.
- Bridges connect to IRC, Slack, Discord, XMPP, etc.
- Element’s predecessor Riot enabled E2EE by default for new private rooms in May 2020. Public rooms remain unencrypted by design.
- MLS profile (RFC 9420) in development to replace Megolm for groups.
Trade-offs:
- Pros: federated, open-source, rich room model, bridging.
- Cons: large per-user state, history-visibility trade-offs, server learns metadata (room membership, timing, device list).
Nostr
"Notes and Other Stuff Transmitted by Relays" — a public-key-rooted protocol where the user is their secp256k1 keypair (npub/nsec, BIP-340 Schnorr). Public events (kind 1 notes, profile metadata, reactions) are signed but unencrypted by design — they're meant to be public posts. Encrypted communication uses dedicated event kinds.
Architecture:
- Keys: npub (public) / nsec (private), Schnorr over secp256k1.
- Relays: simple WebSocket message brokers; anyone can run one.
- Clients: any app that knows the protocol; clients verify signatures themselves.
Encryption layers:
| Use case | Mechanism | Notes |
|---|---|---|
| Public posts | Signed only | Public broadcast is the design goal |
| Direct messages (legacy) | NIP-04 — ECDH + AES-256-CBC | Deprecated; metadata leaks recipient |
| Direct messages (current) | NIP-44 v2 — secp256k1 ECDH → ChaCha20 + HMAC-SHA-256 | Versioned format with padding |
| Metadata-protected DMs | NIP-17 + NIP-59 gift-wrap | Wraps NIP-44 content in a randomly-keyed envelope; relays cannot link sender |
| Group messaging | Marmot Protocol — MLS (RFC 9420) over Nostr | Forward secrecy + post-compromise security; KeyPackages kind 30443, gift-wrapped Welcomes kind 1059, encrypted group events kind 445 |
Trade-offs:
- Pros: censorship-resistant by relay redundancy; key-rooted identity (no phone, no server account); client and relay diversity; composes with Lightning zaps and other key-bound protocols.
- Cons: legacy DMs (NIP-04) leak who-talks-to-whom to relays; NIP-17 hides the sender inside a gift wrap but still exposes its recipient tag; no built-in spam control; relay discovery is application-defined.
Resources:
- NIPs — protocol specs (active list)
- awesome-nostr — curated client/relay list
- Marmot Protocol — MLS group E2EE over Nostr
- Nostr Deep Dive — protocol internals
SimpleX
A messaging protocol designed for metadata resistance. Detailed in SimpleX.
Features:
- No global user identifiers — addressable by per-conversation queue addresses on relay servers.
- Onion-routed connections to relays (with optional Tor).
- No address-book correlation; the recipient's invite link is delivered out of band.
Trade-offs:
- Pros: relays cannot link conversations to a single user; no social graph centralized anywhere.
- Cons: still requires out-of-band invite delivery; smaller ecosystem; UX cost of no contact discovery.
Session
Session uses public-key identifiers and onion-routed delivery without phone-number registration. Its threat model and protocol differ from Signal’s; consult the metadata-resistance comparison for transport trade-offs.
Cwtch
Tor v3 onion services as messaging substrate (Cwtch). Each user runs an onion service; conversations are direct hidden-service-to-hidden-service. Group servers are untrusted relays — they see encrypted blobs, not content or membership. Built by Open Privacy Research Society with explicit metadata-resistance research grounding.
Wire (MLS)
Wire is a Swiss / German enterprise messenger and the canonical production reference deployment of MLS (RFC 9420), alongside Cisco Webex (Wire MLS). A different group protocol from Signal — Wire's earlier Proteus protocol ran in parallel for a decade before the MLS migration in 2022.
Network comparison
| Protocol | Metadata | Decentralized | E2EE | Open source |
|---|---|---|---|---|
| Signal | Poor (phone number) | No | Yes (PQXDH + Double Ratchet) | Yes (clients + server) |
| Poor (phone number) | No | Yes (Signal Protocol since 2016) | Closed-source clients; protocol documented | |
| Matrix | Moderate (server learns metadata) | Yes (federated) | Default-on for private rooms (Olm/Megolm) | Yes |
| Nostr | Mixed — public posts are public; DMs depend on NIP used | Yes (relay-based) | Public posts: no (by design). DMs: NIP-44 / NIP-17. Groups: Marmot Protocol (MLS) | Yes |
| SimpleX | Good (no user IDs) | Partial (relays + clients) | Yes (Double Ratchet) | Yes |
| Session | Good (no phone, onion-routed) | Yes (distributed service nodes) | Yes; protocol differs from Signal | Yes |
| Briar | Good (Tor + LAN + BLE + USB transports) | Yes (peer-to-peer) | Yes (BTP, Bramble) | Yes |
| Cwtch | Good (Tor v3 hidden services) | Yes (peer-to-peer) | Yes | Yes |
Clients
Centralized E2EE
| Client | Platform | Protocol | Notes |
|---|---|---|---|
| Signal | All | Signal Protocol | Reference implementation |
| All | Signal Protocol | Default-on E2EE since 2016 |
Federated / decentralized
| Client | Platform | Protocol | Notes |
|---|---|---|---|
| Element / Element X | All | Matrix | Reference Matrix client; Element X is the current rewrite |
| Damus | iOS, macOS | Nostr | Largest iOS Nostr client |
| Primal | iOS, Android, web | Nostr | Reads + DMs + zaps; Primal cache server optional |
| Amethyst | Android | Nostr | Most full-featured Android client |
| Nostur | iOS | Nostr | Long-running iOS Nostr client |
| Coracle | Web | Nostr | Web-first; experimental NIPs |
Metadata-resistant
| Client | Platform | Protocol | Notes |
|---|---|---|---|
| SimpleX Chat | All | SimpleX | No user IDs; per-queue routing |
| Session | All | Session / Oxen | Onion-routed; X25519 identity |
| Cwtch | All | Tor v3 hidden services | Peer-to-peer over Tor |
| Briar | Android, desktop (alpha) | Bramble (BTP/BSP/BQP) | Tor + Bluetooth + Wi-Fi LAN + USB |
Trade-offs
Strengths
- Content privacy — only sender and receiver can read.
- Forward secrecy and post-compromise security in Signal-family designs.
- Censorship resistance via relay redundancy (Nostr) or transport diversity (Briar).
- Self-sovereign identity (Nostr, Pubky, did:key).
Limitations
- Metadata leaks — most platforms still expose who and when to the server or relay.
- Endpoint compromise — E2EE does not help if the device is malware.
- Identity binding — verifying that a key belongs to the intended human is out-of-band work.
- Jurisdiction — app-store and provider availability varies.
Primary sources
- Signal: protocol specifications
- RFC 9420: Messaging Layer Security
- Matrix: end-to-end encryption implementation guide
- SimpleX Messaging Protocol
- Nostr NIP-17: private direct messages
- Nostr NIP-59: gift wrap
- Briar: transport and privacy
- Signal: initial PQXDH deployment
- Signal: sealed sender
- Matrix: encryption by default in May 2020
- Session cryptographic design
- The Double Ratchet Algorithm
Two newer MLS-based projects on Nostr identities: White Noise, a relay-native messenger built on Marmot, and Cordn, group messaging through a coordinator you can run yourself.
For a current comparison of identifiers, metadata, encryption defaults and readiness, see Choosing a private messenger. Additional entries cover Delta Chat, XMPP with OMEMO, Jami, Tox, Quiet and Veilid.
Page history
- Updated
- 2026-10-25
- Origin
- Compiled from the ungovernable.tech research notes.
- Improve this page
- Suggest an edit — issues and pull requests are welcome.