How OpenDescent protects your messages, what cryptographic primitives we use, what the threat model actually covers — and, crucially, what it doesn't. If you're a developer, a journalist doing due diligence, or just a careful person, this is the page that shows you our work.
All of these are standard, peer-reviewed, widely-deployed primitives. They are the same primitives used by TLS 1.3, SSH, WhatsApp (Signal Protocol), Age, Wireguard, and the browser you're reading this page in. The innovation in OpenDescent isn't in the primitives — it's in the architecture that removes the server entirely. The primitives themselves are chosen specifically because they aren't novel: novel crypto is dangerous crypto.
When you send "I love you", your device runs through these steps before the message leaves the machine. There's no point at which plaintext is available to anyone other than you and the recipient.
The amber steps are what happens on your device before the message is sent. The teal steps are what happens on the recipient's device after it arrives. The peers in between see ciphertext only.
Most messengers — including Signal, the good one — solve privacy with encryption on a central server. The server can't read messages, but it still knows who's talking to whom, when, from where. A compromise of that server, a subpoena, or a policy change can reshape what users can expect.
OpenDescent removes the server entirely. Your messages travel peer-to-peer through libp2p. There is no OpenDescent-operated machine between your device and your recipient's device. There's no DB to leak, no admin account to phish, no IP address log in a data centre.
Encryption plus centralisation means you trust a company to keep running its servers honestly. Encryption plus peer-to-peer removes the company from the equation. The guarantees become architectural — they can't be rolled back by a privacy-policy update, because there's no policy surface to update.
Credibility on a security page comes from admitting what the system doesn't do. Here's ours.
End-to-end encryption protects the path, not the endpoint. If your device is compromised — malware, a malicious browser extension, a shoulder-surfer — the attacker sees plaintext before it's encrypted. The same applies to the recipient's device. This is true of every E2E messenger, including Signal, WhatsApp, and iMessage. It's a fundamental limit of the model, not a specific OpenDescent weakness.
A state-level adversary watching raw internet traffic can see that your device is running OpenDescent (libp2p has distinctive traffic patterns) and identify which other peers you connect to. We don't hide that you're communicating, only what you're communicating. If hiding the existence of communication is part of your threat model, route OpenDescent over Tor or a trusted VPN.
Unlike some protocols (OTR, for historical reasons), OpenDescent signs messages with your long-term Ed25519 key. This is good for integrity and spam resistance, but it means messages are cryptographically attributable — you signed them, and the signature is verifiable forever. If you need deniability for your threat model, consider combining OpenDescent with other tools.
A peer you directly connect to can record that you connected, your IP at the time, and packet sizes. This is local metadata, not global — nobody has the whole network graph. But it's not literally zero. If this matters for your threat model, onion-routed Dead Drops are designed for exactly this case.
X25519 and Ed25519 are safe against classical adversaries. A future large-scale quantum computer could theoretically break them. When post-quantum primitives become standardised and practical (CRYSTALS-Kyber, CRYSTALS-Dilithium, etc.), we plan to adopt them alongside the current stack. For now, "record now, decrypt later" is a real risk against nation-state-class threat models.
See the next section.
OpenDescent is open source under the MIT license and uses standard, peer-reviewed cryptographic primitives. The code is available for anyone to read on GitHub. But we have not yet commissioned a professional cryptographic audit — the kind that firms like Trail of Bits, NCC Group, or Cure53 perform on Signal, SimpleX, and Proton.
A proper audit costs in the tens of thousands of GBP. It's on the roadmap and is one of the specific things the Founder's Edition subscription helps fund. We will not claim "audited" until we are.
npm install && npm run build
Every cryptographic claim on this page is verifiable by reading src/crypto/ in the repository. The specific files:
If you find a vulnerability or a cryptographic weakness, please disclose responsibly via GitHub Security Advisories. We take reports seriously and respond quickly.
Noise(libp2p(AES(plaintext))) — two independent layers of encryption.Open source under MIT. Standard, peer-reviewed primitives. No proprietary crypto. No "trust us" — just "read us."