Secure and decentralized communication stacks

Secure and decentralized communication stacks

synthesisStableUpdated 3372 wordsReview after

Communication systems optimize different things. Signal is a private messenger with centralized delivery; Matrix and XMPP are federated communication substrates; ActivityPub, AT Protocol, and Nostr are primarily social-publishing systems. Putting them on one “decentralized” ladder hides the important decisions.

The central finding is that decentralization is not a proxy for privacy. Federation can reduce dependence on one operator while increasing the number of servers that observe or retain metadata. Cryptographic identity can make publishing portable while making authorship durable and messages non-deniable. Replication can resist censorship while making deletion unreliable.

Comparison dimensions

“Security” and “decentralization” need to be decomposed. The useful questions are:

  • Is E2EE mandatory, optional, or outside the protocol’s purpose?
  • Does compromise of a long-term key expose old messages, and can a session recover after a temporary compromise?
  • Who sees addresses, IP addresses, timing, room membership, contact graphs, and message sizes?
  • Is identity controlled by a phone number, a server domain, a portable cryptographic identifier, or no global identifier at all?
  • Can users move hosts without changing identity or losing their graph?
  • Which servers receive and retain a copy of content or metadata?
  • Can an operator exclude an account, block delivery, or silently substitute keys?
  • Are deletion and moderation authoritative, cooperative, or impossible to guarantee after replication?
  • How mature are the specifications, implementations, independent analyses, recovery flows, and user-verification ceremonies?

These dimensions interact. For example, a public key can remove an account provider from the identity path, but loss or compromise of that key may become catastrophic. A homeserver can make multi-device recovery easy, but becomes a metadata and availability authority.

Comparison matrix

The table describes protocol and architecture defaults, not every client or deployment.

Stack Primary job Content security Metadata and identity Distribution and control Main fit and tradeoff
Signal Private calls and messaging E2EE by default; PQXDH and Double Ratchet provide strong asynchronous key establishment, forward secrecy, and recovery after compromise Phone number still required for registration; usernames can hide it from contacts; sealed sender and private groups reduce service-visible metadata but do not defeat traffic analysis One service and directory, with open clients and published cryptographic specifications Best general default when mature usability and contact availability matter more than operator plurality
Session Pseudonymous private messaging E2EE, but the current protocol deliberately lacks PFS; V2 plans to restore PFS and add post-quantum protection No phone or email; onion requests hide IP information from destination swarms; stable account IDs remain correlatable at the protocol edge Staked Session Nodes store messages in replicated swarms; network incentives and governance add blockchain dependencies Strong account and routing privacy, but a weaker current compromise story and a more complex network trust model
SimpleX Metadata-minimizing private messaging E2EE over pairwise queues; invitation-based contact establishment No global user identifier; each relationship uses separate unidirectional queue addresses; relays still observe their own connections, timing, and volume Open relay protocol; contacts may use different self-hosted or public servers Strongest design here for reducing linkable account and contact metadata, with a smaller ecosystem and more demanding recovery and availability choices
Matrix Federated rooms, messaging, and collaboration Olm/Megolm E2EE is available but room encryption is a configuration and client concern rather than a universal property of Matrix traffic User IDs are homeserver-scoped; homeservers learn room participation and federation traffic even when event payloads are encrypted Room events and state are replicated among participating homeservers; no single server controls the whole federation Good for open organizational collaboration and bridges; poor choice when minimizing membership and social-graph metadata is the first requirement
XMPP Federated presence and messaging Transport security is standard; OMEMO adds E2EE but remains an optional, experimental extension with uneven client support Domain-based JIDs and both endpoint servers expose routing metadata; OMEMO explicitly does not protect traffic analysis Mature domain federation with many servers, clients, and extensions Good for standards-based interoperability and self-hosting when a tested client profile can be mandated; compatibility variance is the security risk
Delta Chat Private chat over email infrastructure E2EE is the default in current Delta Chat; current production cryptography does not yet provide PFS, with Autocrypt v2 planned to add it Chatmail uses random addresses; relays see sender and receiver addresses and size; no sealed-sender equivalent yet Reuses federated email and can use ordinary mail servers, though security properties differ from managed chatmail relays Excellent deployability and federation reuse; inherits email routing metadata and a slower cryptographic upgrade path
Briar High-risk and disruption-resilient messaging Direct E2EE connections and locally stored contact graphs Tor protects long-range relationship metadata; Bluetooth, Wi-Fi, and removable media support local synchronization No central message server; Briar Mailbox can bridge asynchronous delivery Best fit for blackouts, censorship, and small trusted groups; availability and network effects are narrower than mainstream messengers
ActivityPub Federated social publishing No general E2EE layer; audience restrictions are enforced by sending and receiving servers Account identity is normally tied to an instance domain; servers see addressed content and social interactions Servers deliver activities to other servers and apply local moderation; copied or forwarded objects weaken deletion control Best for plural social communities and interoperable publishing, not confidential conversation
AT Protocol Portable social identity, repositories, and application indexing Signed repositories authenticate public data; E2EE is not a base-protocol property DIDs separate canonical identity from handles and PDS hosting; PDS operators and downstream indexers observe public activity PDS hosts, relays, AppViews, and labelers split storage, reach, and moderation; migration is a core design goal Strong account portability and replaceable reach services, but current large relays and AppViews remain concentration points
Nostr Relay-based signed public events Public events are signed, not secret; NIP-17 direct messages add encryption and metadata wrappers, but NIP-44 alone has no PFS or PCS A long-lived public key is the identity; relays can see client IP addresses unless hidden; key compromise and recovery are difficult Clients publish to chosen relays; there is no canonical host, and deletion is only a request that copies may ignore Strong resistance to account-level deplatforming and simple relay substitution; weak deletion, moderation, and high-risk private-messaging ergonomics
Jami Integrated P2P messaging, group chat, and calls Authenticated direct transport; signed swarm history is replicated among participants Certificate-based Jami identities and DHT discovery avoid a canonical account host Swarm conversations synchronize signed Git histories directly and can split and merge after partitions Strong server independence and outage behavior; participants depend on Jami’s integrated protocol suite
Tox Encrypted P2P messaging and calls Encryption and data exchange are supplied by toxcore; supported core traffic crosses clients Long-lived Tox identities and distributed discovery avoid hosted accounts Multiple clients use a common core protocol, but group, history, media, and offline features vary Genuine multi-client interoperability for common features, with uneven support beyond the core

Private messaging families

Signal optimizes mature cryptographic messaging

Signal’s strongest property is not decentralization. It is the integration of a well-studied protocol, default E2EE, multi-device behavior, verification, abuse controls, and mainstream usability. PQXDH protects initial key agreement against passive “harvest now, decrypt later” attacks, while the Double Ratchet supplies forward secrecy and PCS. The service remains an availability and account-registration authority.

Signal has reduced the practical exposure of phone numbers: users can connect through optional usernames and restrict phone-number discovery. A phone number is nevertheless still required to register. Sealed sender hides the sender from the delivery envelope when applicable, but Signal’s own description identifies timing and IP correlation as residual problems.1

Session and SimpleX optimize metadata differently

Session replaces a centralized delivery service with replicated swarms of staked nodes and routes requests through multiple nodes. This removes phone-number registration and makes simple server seizure or blocking less decisive. The current Session Protocol uses stateless message encryption, however, and does not provide PFS. Session Protocol V2 is described as work in progress that will restore PFS and add post-quantum protection.2

That is a material security tradeoff, not a minor checklist omission. An independent 2025 analysis also found practical group-insider replay and reordering attacks in the analyzed Session design, plus attacks involving exposed signing keys.3 The result does not mean that Session is generally “broken”; it means its group protocol has narrower guarantees than an E2EE label suggests.

SimpleX removes the stable account identifier itself. Contacts exchange invitation material, then communicate through separate unidirectional server queues. This makes it harder for one relay database to reconstruct a user’s contact graph. It does not make network observation disappear: relays and network paths still expose local connection, timing, size, and availability signals, and compromised endpoints still expose plaintext and relationships.

Briar optimizes disruption resistance

Briar is structurally different from store-and-forward cloud messengers. Devices synchronize directly, using Tor over the Internet or Bluetooth and Wi-Fi during an outage. This sharply reduces server coercion and blocking surfaces. It also makes peer availability, device storage, and contact bootstrapping more important. Briar is the clearest choice in this set when an Internet blackout is part of the threat model, not when maximum everyday reach is the objective.

Delta Chat reuses an existing federation

Delta Chat demonstrates that decentralization can come from reuse. It layers chat conventions, automatic OpenPGP encryption, and SecureJoin verification over email delivery. Current chatmail profiles use random addresses and protect most message and group headers, but relays still see the transport sender, recipient, and message size. The current implementation also lacks PFS; Autocrypt v2 is scheduled to add forward secrecy and post-quantum protection.4

Federated collaboration is not metadata-private messaging

Matrix and XMPP let organizations choose servers, operate their own domains, and interoperate across administrative boundaries. That is valuable resilience and governance pluralism. It also creates more than one trusted operational party.

In Matrix, homeservers exchange persistent room events, historic events, state, device lists, presence, and other federation data. Encrypted rooms hide supported event payloads, but not the fact that users and servers participate in a room. Room encryption also depends on compatible clients, device verification, key backup, and correct recovery behavior.

In XMPP, OMEMO applies Signal-derived ratchets across multiple devices. Its own specification says it does not protect metadata or traffic analysis and currently labels the extension experimental. Because XMPP is an extensible family rather than one product, “supports OMEMO” does not prove that every message type, attachment, archive, bridge, or client transition has the same protection.

For a managed organization, either stack can be reasonable when administrators can mandate a tested client set, E2EE defaults, verification behavior, retention, and bridge policy. For an open federation of arbitrary clients and servers, interoperability becomes part of the threat model.

Public social protocol families

ActivityPub federates servers and communities

ActivityPub specifies client-to-server publishing and server-to-server delivery. It supports addressed and non-public objects, but privacy is enforced by participating servers, not by a general E2EE scheme. Both origin and recipient servers can process restricted content. Deletion and audience controls therefore depend on remote compliance and cannot revoke screenshots, exports, or non-compliant copies.

Its strength is community-level plurality: instances can choose moderation, membership, and federation policy. Its weakness for individual portability is that the common user@domain identity is host-bound. Migration can redirect followers in implementations, but it is not equivalent to carrying an unchanged cryptographic identity between providers.

AT Protocol separates hosting, identity, reach, and moderation

AT Protocol gives each account a stable DID, a human-readable domain handle, and a signed repository hosted on a PDS. Relays aggregate repositories; AppViews build feeds and search; labelers supply moderation signals. This separation makes host migration and competing reach or moderation services architectural goals.

The privacy consequence is straightforward: the base network is designed to distribute and index public records. Cryptographic signatures authenticate those records; they do not make them confidential. Downstream copies may also outlive an origin deletion when services do not follow the protocol lifecycle.5 AT Protocol is therefore a strong social-data portability design, not a private-chat design.

Nostr makes relays replaceable and keys primary

Nostr events are signed by a user’s long-lived key and published to one or more chosen relays. This removes the canonical home server: a client can change relays without changing the public key. The same structure makes authorship durable, key custody central to account security, and global deletion impossible to guarantee. NIP-09 explicitly says deletion is a request and warns that it cannot remove all relay and client copies.6

NIP-17 improves private direct messages by using NIP-44 encryption and NIP-59 gift wrapping to obscure sender, message type, and exact time from public observers. The specification remains optional, requires recipient relay discovery, and scales by sending a separate encrypted event to each receiver. NIP-44 itself warns that it lacks forward secrecy, PCS, post-quantum security, and IP protection, and recommends specialized E2EE software for high-risk chat.7

Nostr messenger compatibility has three layers

A shared Nostr identity and relay layer does not make two chat applications interchangeable. Compatibility requires agreement at three successive layers:

  1. Both applications must find and fetch the same events from relays.
  2. Both must understand the same encryption, wrapping, message-kind, and attachment conventions.
  3. Both must reconstruct the same membership, history, moderation, and recovery state.

NIP-17 standardizes gift-wrapped direct messages and small ad hoc rooms. It has no administrators, invitations, or bans, and recommends a different scheme for groups above ten participants. NIP-29 instead defines relay-scoped groups whose relay enforces membership and moderation and signs the current group metadata. The two are different conversation models, not interchangeable views of one room.8

Marmot Protocol is a third model: an explicit protocol combining Nostr transport with MLS group state. Its required implementation proposals aim to let independent clients participate in the same secure groups. That is a real interoperability project, but its own specification remains experimental and says cross-client compatibility is not fully tested.9

The practical rule is therefore profile-by-profile compatibility. Some Nostr messengers implement shared NIPs; some define additional higher-layer specifications such as Marmot; and others use application-specific event kinds or conventions. They share an event network, but only the first two cases create a portable conversation protocol.

Cryptographic substrates are not complete products

Messaging Layer Security is an important adjacent standard. MLS specifies asynchronous group key agreement with forward secrecy and PCS for groups from two to thousands. It deliberately does not specify the whole application: identity, authentication services, delivery, metadata protection, abuse handling, backups, and user verification remain system decisions.

The 2025 Jaeger and Kumar analysis is a useful warning against treating even modern group cryptography as a badge. It identifies construction-specific attacks across MLS, Session, Signal, and Matrix, while also explaining when surrounding protocol mechanisms prevent practical exploitation. The security unit is the complete deployed system, not the name of its ratchet or cipher.

White Noise illustrates that distinction directly. Its Marmot Protocol foundation uses MLS and therefore starts with strong group forward-secrecy and post-compromise-security machinery. The 2025–2026 White Noise and Marmot security reviews, however, found consequential identity-binding, authorization, storage, state-convergence, and metadata-boundary issues in the surrounding protocol and implementation. Most critical findings were verified as fixed, but the stack remains young and lacks Signal’s post-quantum ratchets and deployment history.

Jami and Tox illustrate two other interoperability boundaries. Jami is an integrated P2P stack whose swarm conversations replicate signed Git histories; its platform clients share the Jami daemon and protocol suite. Tox is a common core protocol with several independent clients, so supported one-to-one and group traffic can cross client boundaries. The Tox feature matrix nevertheless shows uneven support for moderated groups, history, media, and offline behavior.10

Secure Scuttlebutt remains another distinct branch that deserves evaluation around peer discovery, offline delivery, multi-device state, key recovery, audits, and active maintenance.

Threat-model recommendations

No stack dominates every threat model.

Need Starting point Why Verify before relying
Everyday private messaging for mixed-skill contacts Signal Strong protocol analysis, default E2EE, usable verification, large network Phone-number exposure settings, safety numbers, linked devices, backups, endpoint security
Minimize stable identifiers and server-visible contact graphs SimpleX Pairwise queues and no global user identifier Invitation authenticity, server diversity, Tor or network route, backup and device-loss plan
Pseudonymous messaging with decentralized offline delivery Session No phone/email and onion-routed replicated swarms Current lack of PFS, group-protocol limits, recovery phrase custody, V2 deployment status
Communication during blocking or Internet outages Briar Direct synchronization over Tor, Bluetooth, or Wi-Fi Contact bootstrapping, peer availability, Mailbox setup, device compromise
Self-hosted team rooms and integrations Matrix Rich rooms, federation, clients, and bridges Encrypted-room policy, verified devices, key backup, metadata exposure, bridge downgrade
Standards-based federated chat with controlled clients XMPP plus OMEMO Mature federation and deployable self-hosting Exact OMEMO version, client interoperability, archives, attachments, gateways
Chat that interoperates with email infrastructure Delta Chat Reuses email federation with chat-oriented E2EE Chatmail versus classic email mode, no current PFS, relay metadata, SecureJoin verification
Federated community publishing ActivityPub Broad implementation ecosystem and instance autonomy Remote-server trust, moderation policy, follower migration, deletion limits
Portable social accounts and competing feeds AT Protocol DID identity, PDS migration, signed repositories, separable AppViews Rotation-key custody, actual migration support, relay/AppView concentration, deletion behavior
Censorship-resistant signed public publishing Nostr Replaceable relays and key-based identity Key custody, IP hiding, relay policy, irreversibility, private-message limitations

Decision rules

  1. Use a dedicated private messenger for confidential conversation. Do not promote a social protocol’s encrypted-message extension into a high-risk recommendation without a separate protocol review.
  2. Treat metadata resistance as an explicit property. E2EE alone does not hide who participates, when they communicate, or which server routes the exchange.
  3. Treat federation as governance distribution, not automatic confidentiality. Every participating server may add observation, retention, compromise, and legal-request surfaces.
  4. Treat cryptographic identity as a custody problem. Portability is valuable only if users can rotate, recover, and protect the keys that control it.
  5. Treat deletion and censorship resistance as opposing pressures. Systems that maximize uncontrolled replication cannot promise reliable revocation.
  6. Specify one tested deployment profile. “Matrix,” “XMPP,” or “Nostr” names a family of choices, not a reproducible security posture.
  7. Verify contacts and devices. Research on authentication ceremonies repeatedly shows that opportunistic E2EE does not defeat an active key-substitution attack unless users or systems authenticate the keys.

Commercial implication

This comparison does not reveal an empty messenger market. It reveals a difficult combination gap: no phone-number registration, low linkable metadata, mainstream multi-device recovery, reliable asynchronous delivery, calls, groups, and mature abuse resistance.

Metadata-minimizing communication product gap turns that finding into bounded commercial wedges. Managed deployments, relay operations, recovery tooling, and privacy-preserving anti-abuse infrastructure can be tested before asking users to move a social graph to a new protocol.

  1. Signal’s sealed sender design explains both the metadata reduction and the remaining timing and IP-correlation problem. ↩

  2. Session Protocol documentation states that V2 is in development and plans to re-implement PFS. ↩

  3. Jaeger and Kumar group chat encryption analysis summarizes the independent cryptographic analysis and its scope. ↩

  4. Delta Chat’s current security documentation distinguishes its present guarantees from planned Autocrypt v2 properties. ↩

  5. AT Protocol account-lifecycle guidance notes that records requested for deletion may persist in downstream systems that do not follow the protocol. ↩

  6. NIP-09 defines a cooperative deletion request, not guaranteed erasure from all relays and clients. ↩

  7. NIP-44 lists its own private-messaging limitations, while NIP-17 adds gift-wrapped direct-message conventions. ↩

  8. NIP-17 defines private direct messages and small ad hoc rooms, while NIP-29 defines relay-based group authority and state. ↩

  9. Marmot Protocol defines required group-messaging proposals and states its present experimental and interoperability limits. ↩

  10. The Tox client matrix distinguishes common toxcore interoperability from uneven application-feature support. ↩

Sources

  1. signal.org
  2. signal.org
  3. docs.getsession.org
  4. simplex.chat
  5. spec.matrix.org
  6. xmpp.org
  7. w3.org
  8. atproto.com
  9. github.com
  10. github.com
  11. github.com
  12. github.com
  13. docs.jami.net
  14. wiki.tox.chat
  15. briarproject.org
  16. delta.chat
  17. rfc-editor.org
  18. eprint.iacr.org