What "peer-to-peer" actually means (and why most "private" messengers aren't).

There is a phrase that appears on roughly every privacy product's homepage: "peer-to-peer." We like the phrase. We use it ourselves, because our messenger genuinely is peer-to-peer. But the phrase does a lot of work it shouldn't have to, because many products using it are not peer-to-peer in any architecturally meaningful sense. They are using the phrase as a vibe — "not Big Tech" — rather than as a technical description.

This is an explainer. It's the post we wanted to exist when we started talking to people about what OpenDescent is, and we kept finding out they meant three different things by "P2P" depending on who they'd read last. Let's fix that.

There are, roughly, three patterns in which messaging apps can be built. We'll go through them with diagrams, then talk about where each pattern fails, and then about common misuses of the word "peer-to-peer."

§ 01Pattern 1: Centralised

This is the pattern you're used to. Your device talks to Discord's servers. Discord's servers talk to your friend's device. The server is the router, the record-keeper, the moderator, the authority. Without the server, none of you can message each other.

End-to-end encryption is orthogonal to this pattern. Signal, WhatsApp, and iMessage all encrypt message content such that the server can't read it. That's good! It means the server being compromised doesn't spill your message text. But the server still sees who is talking to whom, still has a database of accounts, still requires you to trust that it is running the software it says it is. This is the "privacy as policy" pattern — the encryption guarantees are real, right up until the policy changes. Instagram on May 8, 2026 is the canonical example of the policy changing.

§ 02Pattern 2: Federated

Federation is the model email uses. You have an address at gmail.com; I have one at fastmail.com; we can email each other because Gmail and Fastmail both speak the same protocol (SMTP). Matrix and Element do this for real-time messaging. Mastodon does it for microblogging. XMPP did it for instant messaging back when the word "instant messaging" was novel.

Federation is a real privacy improvement over pure centralisation. You can choose your server based on who you trust, you can run your own, and no single company has full visibility. But each server still has a view of its own users. If you're on a Matrix server run by Element, Element's server still sees which rooms you're in, when you're online, who you message. Federation splits the trust problem into smaller pieces; it doesn't eliminate it.

Matrix deserves specific credit for one thing: end-to-end encryption across servers. When two users on different Matrix servers chat, the message is E2E encrypted between their devices — neither server can read it. That's a meaningful architectural achievement. It still means each server sees the fact of the conversation — who talked to whom, when — but the content is protected.

§ 03Pattern 3: True peer-to-peer

In a true peer-to-peer messenger, your device talks to your friend's device directly. There is no intermediary server that either of you connects to first. When you want to send a message, your device finds your friend's device through a distributed peer-discovery mechanism (usually a Kademlia DHT or similar), opens an encrypted connection, and sends the message. The message goes from your device to theirs — possibly through other peers acting as forwarders if direct connection isn't possible, but never through a company-operated server.

This is what we built OpenDescent on. The underlying stack is libp2p, the same peer-to-peer networking library that powers IPFS, Filecoin, Ethereum, and Polkadot. Peer discovery uses KadDHT and mDNS. NAT traversal uses DCUtR hole-punching with circuit relay fallback. Every connection is Noise-encrypted at the transport layer. Messages are additionally E2E encrypted inside that tunnel. When we say "peer-to-peer," we mean the architecture described in the diagram above: no server exists, and if you were to attempt to compromise "OpenDescent," you would have to find the company first and it is not there.

§ 04Common misuses of "peer-to-peer"

Here are some phrases you'll see on product pages that are not peer-to-peer, at least not in the architectural sense:

• "We use the Signal Protocol, so your messages are peer-to-peer."
  No. The Signal Protocol is an end-to-end encryption protocol. It can run over centralised or federated or P2P infrastructure. Using the Signal Protocol tells you that messages are encrypted between endpoints. It does not tell you there isn't a server in the middle.
• "Messages are never stored on our servers, so it's peer-to-peer."
  No. "Not stored" and "not routed through" are different. A server that routes messages without storing them still sees who is talking to whom, when, from which IP. It's an improvement over a server that stores forever, but it is not peer-to-peer.
• "Our app connects directly between users, so it's peer-to-peer."
  Depends on the handshake. Many voice/video apps (including traditional WebRTC ones) advertise "direct" connections while routing signalling through a central server. If the signalling server is down, the "direct" connection can't start. That's not the same as true P2P.
• "We're decentralised — you can self-host."
  That's federation, which is good and we respect it, but it's not peer-to-peer. If self-hosting requires running a server, there are still servers — they're just not run by a single company.

We are not saying any of these products are bad, or that they're lying. In most cases, they are using "peer-to-peer" loosely because marketing copy has to fit in a hero section. But the distinction matters when you're trying to evaluate a product's privacy properties. "Peer-to-peer" should mean there is no server in the architectural path. If a product's claim breaks down when you ask "whose server is in the handshake?", it isn't P2P.

§ 05Why the distinction is load-bearing for privacy

All three patterns can be run with end-to-end encryption on message content. In terms of "can a random attacker read my messages in transit?", all three are fine. The distinction becomes important when you ask different questions:

• "Who sees metadata?" Centralised: the company. Federated: your server. P2P: direct peers you connected to, but no global view.
• "What happens if the company is compelled by a court?" Centralised: they produce what they have (account existence, timestamps, connection metadata). Federated: the relevant server's admin produces what they have. P2P: there is no entity to compel.
• "What happens if the encryption policy changes?" Centralised: the company can roll it back (Instagram, May 8). Federated: each server can, independently. P2P: there's no centralised policy to roll back.
• "What happens if the company goes bankrupt / gets acquired / pivots?" Centralised: your access depends on their survival. Federated: your access depends on your server's survival. P2P: the network exists as long as its users do.

These questions have different answers for each pattern, and the answers matter in different amounts depending on your threat model. For a casual user, centralised + E2E is probably fine most of the time. For a user who cares deeply about architectural guarantees — someone building something they want to outlive any company — the distinction is the whole game.

§ 06What this means for picking a messenger

We don't think there's one right answer. Different patterns suit different users. Here's how we'd think about it:

• Centralised + E2E (Signal, WhatsApp): Fine for most people most of the time. Good cryptography, battle-tested. The trade-off is that privacy is a policy commitment, not an architectural one.
• Federated + E2E (Matrix / Element): A good middle ground if you want to reduce single-company power without dealing with the complexity of pure P2P. You can self-host if you want to; you can pick a trusted server if you don't.
• Peer-to-peer (OpenDescent, Briar, SimpleX): The right choice when you specifically want architectural guarantees over policy guarantees. Accept that the tooling is newer and user bases are smaller. Benefit from the fact that there's no company in a position to change the deal.

§ 07One last note

The word "peer-to-peer" is having a moment, in the same way "decentralised" had a moment ten years ago and "open source" had a moment twenty years before that. The moment is deserved — these are real ideas with real architectural consequences. But the moment also means the words are about to be applied to every product regardless of whether the architecture actually matches.

The test is simple. When you're evaluating a product that calls itself peer-to-peer, ask: whose server is in the handshake? If the answer is "none," you're looking at the real thing. If the answer is some variant of "ours, but it doesn't store anything," you are looking at a centralised product using the word as vibe. That's fine, sometimes, but it isn't the same thing.

We built OpenDescent because we wanted a messenger where the answer to that question is "none." You can verify it by reading the code, or by unplugging our website and watching OpenDescent keep working. The network exists between users. Nobody else is in it.

Back to all posts