Two-layer identity
Each device holds its own cryptographic identity for MLS, while a persistent user identity ties a person’s devices together. Multi-device works without an account system or any external directory.
Welcome to Cryptid
Federated secure messaging where the server knows almost nothing. Built on MLS.
The Problem We’re Trying to Solve
Section titled “The Problem We’re Trying to Solve”Secure messengers get to pick two of three. Strong security, real decentralization, or usability that doesn’t drive people away.
| Security | Decentralized | Usable | |
|---|---|---|---|
| Signal | ✅ | ❌ | ✅ |
| Matrix | ⚠️ | ✅ | ✅ |
| SimpleX | ✅ | ✅ | ⚠️ |
Signal is centralized. Matrix permits unencrypted messages. SimpleX makes groups painful. Cryptid is an attempt at doing all three at once.
How We’re Doing It
Section titled “How We’re Doing It”Unlinkable authentication
Devices spend PrivacyPass tokens instead of presenting credentials. A server verifies a token is valid without learning who spent it, so rate limiting works without tracking.
Double-encrypted envelopes
Two layers of encryption. A server sees a delivery address and an opaque blob - never the content, the sender, the group, or even the message type.
Minimal-state federation
Servers are dumb pipes. They hold short-lived routing state that expires on its own, and they never learn a social graph. Anyone can run one.
Where We Are
Section titled “Where We Are”v0.12 Specification complete. Nothing is implemented yet.
At the time of writing this, the reference specification is internally consistent and covers the wire format, identity, mailboxes, authentication, federation, moderation, and media. The server API has been rewritten and work is pending on implementations.
Settled
- Wire format and canonical serialization
- Per-group mailbox keypairs
- PrivacyPass issuance and redemption
- Blind KeyPackage distribution
- Opaque envelope relay between servers
- Encrypted blob storage
Also Settled (as of 0.12)
- The server API: 14 pages of abstract operations with HTTP bindings
- Error model with retry classes and failover eligibility
- Authorization model: six mechanisms, only one of which identifies a device
Deliberately Out of Scope for v1
- Network-level anonymity against traffic analysis
- Onion routing and relay networks
- Community-scale groups: fan-out bounds converations at around 200-250 users
Not yet started
A server implementation, and any client. The pseudocode throughout this spec is illustrative, not runnable.
Start Reading
Section titled “Start Reading”IntroductionThe problem, the principles, and the architecture in one page.
Identity SystemHow devices, users, and groups are named.
Wire FormatThe double-encrypted envelope and what servers actually see.
PrivacyPassSpending tokens instead of proving who you are.
Our Values
Section titled “Our Values”
Cryptid is proudly antifascist.
Strong encryption and federation matter most to the people fascists target first: organizers, journalists, migrants, queer and trans people. A protocol built for them is not politically neutral and pretending otherwise would be its own kind of position.
If this is a problem for you, you are not welcome in our spaces. Our Code of Conduct spells out the rest.
Questions and Discussion
Section titled “Questions and Discussion”ForumDesign discussion, questions, and rationale for decisions that aren't obvious from the spec.
SourceThe specification source, and where to file corrections.
The Cryptid specification is being developed in the open under CC-BY-SA 4.0.
