Protocol Status

Specification Status

Version: 0.12
Status: Specification complete. Nothing is implemented yet.
Last Updated: September 15th, 2026

The reference documentation and the server API are both written and internally consistent. What remains before a freeze is implementation, plus a once-over to cut pseudocode back to what a specification actually needs.

Breaking Changes in 0.11

Rewritten in 0.11, not backwards compatible with 0.10:

Authentication: JWT -> PrivacyPass (unlinkable authentication) Specified
Wire Format: Single envelope -> Double-encrypted envelopes Specified
Delivery Addresses: Server-assigned -> Per-group mailbox keypairs Specified
KeyPackage Distribution: device_id indexed -> Blind derived handles Specified
Federation: Relayed MLS ciphertext -> Opaque envelope relay Specified
ContactRequest: Unauthenticated -> Signed with replay rejection Specified

Breaking Changes in 0.12

Writing the server API against the 0.11 model surfaced some contradictions the reference pages did not cover. Most of these reverse some earlier decisions.

API surface: Rewritten as abstract operations with per-transport bindings, rather than HTTP endpoints Specified
Tokens are fungible: TokenScope removed. challenge_digest now binds the issuing server, not an action class Specified
Issuance is blinded: TokenRequest and TokenResponse added; announcement no longer returns tokens Specified
Mailbox retrieval: Specified for the first time, authorized by ownership proof rather than a token Specified
KeyPackage fetch: Unmetered, authorized by the derived handle. Tokens are server-local, so metering a foreign server was never implementable Specified
InfoPackages: Encrypted client-side. The server previously generated the key and encrypted content it could read Specified
Revocation: Capability-token based for InfoPackages and blobs, replacing identity-bound revocation Specified
Message size: 10 MB -> 256 KB. Bulk data now has exactly one path Specified
Blob size: Server-configured and published, replacing a protocol-wide constant Specified
Federation auth: server_signing_key published at /.well-known/cryptid. Signature verification previously had no key to verify against Specified
Device reports: Removed. They left the only per-device behavioural record in the design and asked operators to judge conduct they cannot observe Specified

What Remains Stable

MLS as the E2EE foundation
The two-layer identity architecture: device identities for MLS, a user identity across a person’s devices
The three-layer moderation model: server, group, device
The contact exchange model: a QR or link carries a reference and a key; the package is fetched and decrypted client-side

Known Ceilings

During the 0.12 write, two limits were surfaced which are being documented here because solving them is not straightforward and requires careful consideration.

Group size is bounded at roughly 200-250 users by fan-out economics. One message costs one token per recipient device, so cost scales with membership. Large low-traffic groups are fine; large conversations are not. Community scale groups are reserved under cryptid_community_ext_v1 and deliberately outside the base protocol because they will most likely require a server component to deliver.
Blocking binds to one server. A device announced at several servers keeps its budget at each, and nothing propagates this decision. This is mostly a non-issue because “actual” blocking is supposed to happen client side, but it’s worth mentioning here to document it.

Target

Hard freeze after authentication and envelope changes are fully specified and implemented.

These are now fully specified. Implementation has not yet started, and that’s basically all that’s left.