Introduction
What This Protocol Solves
Section titled “What This Protocol Solves”Current secure messaging systems face a fundamental trilemma. They can achieve at most two of the following three properties:
-
Strong Security (end-to-end encryption, forward secrecy)
-
True Decentralization (no single points of failure)
-
Practical Usability (easy contact addition, reliable delivery)
Examples of Existing Trade-offs:
-
Signal: Strong security + usability, but centralized infrastructure.
-
Matrix: Decentralization + usability, but allows unencrypted messages.
-
SimpleX: Security + decentralization, but poor usability for groups.
Cryptid breaks this trilemma by introducing three foundational principles:
-
Device-Centric Cryptographic Identity: Every device generates its own cryptographic identity without external dependencies.
-
Layered Trust Model: Combines MLS group authenticity with optional direct contact verification.
-
Minimal-State Federation with Traffic Shaping: Servers function as encrypted message relays (“dumb pipes”) that route MLS ciphertext without understanding content or relationships. Servers maintain minimal behavioral metadata (account age, message volume) for spam prevention through progressive trust rate limiting, while never being aware of message content or social graphs.
Protocol Focus
Section titled “Protocol Focus”This protocol focuses primarily on providing a secure, private, and decentralized framework for real-time messaging with strong cryptographic guarantees.
Its main goals are:
-
Device-Centric Identity: Users authenticate using cryptographic device keys instead of traditional accounts or personal identifiers.
-
End-to-End Encryption: All communication is encrypted using the Messaging Layer Security (MLS) protocol, ensuring confidentiality, authenticity, forward secrecy, and post-compromise security.
-
Minimal Server Trust with Traffic Shaping: Servers act as encrypted message relays storing only temporary routing data and minimal behavioral metadata for spam prevention, never accessing message content or social graphs.
-
Federated Architecture: Supporting multiple independent servers that interoperate, enabling decentralized communication without centralized control.
-
Layered Trust Model: Allows immediate group participation authenticated by MLS, with optional enhanced trust through out-of-band verification.
-
Moderation and Abuse Prevention: Server-level federation control, group-level community moderation with power levels, and device-level personal blocking, all while preserving end-to-end encryption.
Out of Scope (for now)
Section titled “Out of Scope (for now)”While striving for strong security and privacy, this protocol deliberately excludes or leaves for future work the following aspects:
-
Full Network-Level Anonymity: The protocol does not provide strong resistance to traffic analysis or sender/receiver anonymity against network observers or server operators.
-
Metadata Protection Beyond Minimal Routing: Exact relationships between participants or message timing remain partially observable by servers temporarily.
-
Device Identity Hiding: Devices are identified by cryptographic addresses rooted in their home servers. Obfuscation through relay networks or onion routing is not part of the specification. (It should be mentioned that this is something I want to implement as soon as I have a very minimal working server implementation.)
-
Rich User Profiles and Presence: Features such as detailed contact lists, status indicators, or social graphs are outside design scope to maintain privacy.
Architecture
Section titled “Architecture”┌───────────────────────┐ ┌───────────────────────┐│ │ │ ││ Device A (Alice) │ │ Device B (Bob) ││ │ │ ││ ┌───────────────────┐ │ │ ┌───────────────────┐ ││ │ │ │ │ │ │ ││ │ Ed25519 Identity │ │ │ │ Ed25519 Identity │ ││ │ MLS Keys │ │ │ │ MLS Keys │ ││ │ Contacts │ │ │ │ Contacts │ ││ │ Groups │ │ │ │ Groups │ ││ │ │ │ │ │ │ ││ └───────────────────┘ │ │ └───────────────────┘ ││ │ │ │└───────────┬───────────┘ └───────────┬───────────┘ │ │ │ Encrypted Messages │ │ (MLS Ciphertext) │ │ │ │ │ │ │ ▼ ▼┌───────────────────────┐ ┌───────────────────────┐│ │ │ ││ Server A │ │ Server B ││ chat.alice.com │ │ chat.bob.com ││ │ │ ││ │ │ ││ ┌─────────────────┐ │ Federation │ ┌─────────────────┐ ││ │ Temp Mappings │ │ ◄────────────────────────────────► │ │ Temp Mappings │ ││ │ Message Queue │ │ (Encrypted Relay) │ │ Message Queue │ ││ │ Traffic Shaping │ │ (Server Blocklists) │ │ Traffic Shaping │ ││ │ │ │ │ │ │ ││ │ (Expires 24h) │ │ │ │ (Expires 24h) │ ││ │ │ │ │ │ │ ││ └─────────────────┘ │ │ └─────────────────┘ │└───────────────────────┘ └───────────────────────┘What the Server Knows
Section titled “What the Server Knows”-
Device Addresses (required for delivery mapping)
-
Message Volume (how many messages a device is sending and receiving, required for anti-spam)
-
Account Age (when the device initially registered on the server, required for anti-spam)
-
Spam Reports Against Devices (amount of times the device was reported, required for anti-abuse)
What the Server NEVER Knows
Section titled “What the Server NEVER Knows”-
Message Content
-
Message Senders
-
Social Graphs
-
Group Memberships
Key Terminology
Section titled “Key Terminology”Here are some phrases we’ll be using throughout this document:
-
Device Identity: A cryptographic identity consisting of a random 32-byte device ID and Ed25519 keypair. This replaces traditional usernames/accounts.
-
MLS (Messaging Layer Security): RFC 9420 standard providing group key agreement, forward secrecy, and post-compromise security. You can sort of think of this as “TLS for group messaging”.
-
Out-of-Band Trust: Establishing cryptographic trust through a separate channel (QR codes, invite links) rather than relying on servers.
-
Minimal Server State: Servers store only temporary routing information, encrypted message queues, and minimal behavioral metadata for abuse prevention. Never user accounts or cryptographic material.
-
Federated: Multiple independent servers can interoperate, like email servers, but without requiring trust between servers.
-
Power Levels: Numeric values (0-100) assigned to group members indicating their moderation privileges within MLS groups. Used for community self-governance without server involvement.
-
Progressive Trust: A traffic shaping mechanism where new devices start with restrictive rate limits that increase over 24 hours based on behavior, preventing spam while minimizing onboarding friction.
-
Traffic Shaping: Server-side rate limiting based on observable behavioral patterns (account age, message volume) rather than content analysis, enabling spam prevention while preserving message privacy.
License
Section titled “License”The Cryptid specification is licensed under CC-BY-SA 4.0.
