Introduction

Caution

This spec document is still very much a work in progress.

Caution

Throughout this document, you will find pseudocode snippets written in rust embedded to illustrate key protocol operations and concepts. These snippets serve purely explanatory purposes and are not guaranteed to be syntactically complete or executable without modification.

Readers should interpret them as conceptual guidance to better understand the protocol mechanics rather than production-ready implements.

Note

The current status of the protocol can be seen in the Protocol Status page.

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:

1. Two-Layer Identity Architecture: Every device generates its own cryptographic identity (MLS layer) while users maintain a persistent identity (Application layer) shared across their devices, enabling multi-device coordination without external dependencies.

2. Unlinkable Authentication: Using PrivacyPass tokens, devices can authenticate to servers without being tracked. Servers can verify token validity without linking actions to identities.

3. Double-Encrypted Envelopes: Messages use a two-layer encryption design where servers only see delivery addresses and opaque blobs, never message content, sender, or type.

4. Minimal-State Federation: Servers function as encrypted message relays (“dumb pipes”) that route MLS ciphertext without understanding content or relationships. Using PrivacyPass for authentication enables spam prevention without server knowledge of user activity, while never being aware of message content or social graphs.

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: Servers act as encrypted message relays storing only temporary routing data, never accessing message content, sender identity, or social graphs. Authentication via PrivacyPass enables spam prevention without server tracking of user activity.

• 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)

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. It is worth mentioning that PrivacyPass and double-encrypted envelopes significantly reduce server-visible metadata, but network-level observers remain out of scope for the moment.

• 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 yet. (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

┌───────────────────────┐                                    ┌───────────────────────┐
│                       │                                    │                       │
│  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

• Device Addresses (required for delivery mapping, derived from Mailbox Keypairs)

• Token Issuance (that a device received PrivacyPass tokens at some point, but not when/where they’re spent)

• Spam Reports Against Devices (amount of times the device was reported, required for anti-abuse)

What the Server NEVER Knows

• Message Content

• Message Senders

• Social Graphs

• Group Memberships

Two-Layer Identity Architecture

Cryptid separates identity concerns into two distinct layers:

MLS Layer (Device-Centric)

The MLS layer handles cryptographic group operations:

• Device Identity: Ed25519 keypair unique to each device

• MLS group membership and encryption

• KeyPackage generation and management

• Forward secrecy and post-compromise security

Application Layer (User-Centric)

The application layer manages user-facing concepts:

• User Identity: Ed25519 keypair shared across a user’s devices

• Multi-device coordination and linking

• Contact exchange (users share UserIdentity, not DeviceIdentity)

• User identities contain a list of that user’s device identities

• Group invitations (invite all of a user’s devices at once)

Comparison Between Layers

Responsibility	MLS Layer	Application Layer
Encryption	Device keypair	Not involved
Group membership	Device-level	User-level visibility
Contact sharing	Not involved	User Identity bundles
Multi-device	Independent devices	Coordinated devices
Invitations	KeyPackage per device	Fetch all the user’s devices

Key Terminology

Here are some phrases we’ll be using throughout this document:

• Device Identity: A cryptographic identity consisting of a random Uuidv4 device ID and Ed25519 keypair. This replaces traditional usernames/accounts.

• User Identity: A cryptographic identity (Ed25519 keypair) and random Uuidv4 user ID shared across all devices controlled by a single user, used for application-layer operations like contact exchange and multi-device coordination.

• 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.

• PrivacyPass: A cryptographic token protocol enabling unlinkable authentication. Servers can verify tokens are legitimate without being able to link redemption back to issuance, providing anonymity for user activity.

• Mailbox Keypairs: Dedicated keypairs per device for delivery address derivation. Enables cryptographic proof of mailbox ownership to servers without revealing device identity or linking addresses.

• Device Linking: The process of securely provisioning a User Identity to a new device via ephemeral key exchange.

• Multi-Device User: A user operating multiple devices, all sharing the same User Identity but with unique Device Identities.

License

The Cryptid specification is licensed under CC-BY-SA 4.0.