A technical walkthrough of MLS ratchet trees, Nostr relay transport, key rotations, epoch transitions, and the encryption layers that make decentralised group messaging possible.
1
The Architecture Stack
Sloth is a messaging client. Marmot is the protocol layer that bridges two standards: MLS (RFC 9420) for group encryption, and Nostr for decentralised transport. Here's how they stack:
Sloth Client (UI)
Mobile/desktop app. Contact management, chat interface, group creation.
MLS Library (OpenMLS) | Nostr Client Library | Key Store
TreeKEM ratchet tree · WebSocket connections to relays · Encrypted local key storage
Key insight
MLS (RFC 9420) was designed assuming a central Delivery Service and central Authentication Service. Marmot replaces both with Nostr: relays handle delivery (with multiple relays for redundancy), and Nostr secp256k1 keypairs handle identity — no phone numbers, no emails, no PKI.
2
The MLS Ratchet Tree (TreeKEM)
The core data structure. Each leaf is a group member's public key. Intermediate nodes hold derived key pairs. The root derives the group's shared secret. When a member updates their key, only O(log n) nodes need updating — not O(n).
Ratchet Tree — 4-Member Group
Forward Secrecy
After each key update (Commit), old keys are deleted. Compromising current keys cannot decrypt past epochs.
Post-Compromise Security
If a member's key is stolen, the next key update by any member heals the tree. The attacker is locked out of future epochs.
3
Nostr Relay Network
Nostr relays are dumb pipes. They store and forward signed JSON events over WebSocket without understanding the content. Marmot publishes MLS messages as Nostr events to multiple relays simultaneously for redundancy.
Multi-Relay Message Delivery
A
Alice (sender)
B
Bob (receiver)
Why Multi-Relay Matters
Signal has one set of servers. Block them and you block Signal for an entire country. Marmot publishes to multiple independent relays. An attacker must block all relays in the group's relay set — and any member can add a new relay at any time.
4
Encryption Layers
Every Marmot message has three encryption layers. Even if one layer is broken, the others still protect the message.
Message Encryption Stack
Layer 3 TLS 1.3 Transport
Layer 2 Gift Wrap NIP-59
Layer 1 MLS Epoch Key TreeKEM derived
Plaintext Message "Hello group"
Layer 1: MLS Application Message
Content encrypted with the group's current epoch secret, derived from the ratchet tree. Only group members holding the epoch key can decrypt.
Layer 2: Nostr Gift Wrap (NIP-59)
The encrypted MLS payload is wrapped in a Nostr event signed by a random ephemeral key. Relays see a random pubkey — they can't identify the sender.
Layer 3: TLS 1.3
The WebSocket connection to each relay uses TLS. Network observers see only encrypted traffic to a relay, not the event content.
What Relays See
Nothing useful. A random pubkey, encrypted blob content, and a kind number. No sender identity, no message content, no group membership information.
5
Full Protocol Flow
Walk through a complete Marmot group lifecycle: from publishing key packages, to group creation, messaging, key rotation, and member removal. Each step advances the group's epoch.
Marmot Group Lifecycle
Epoch Timeline
Each epoch has a unique group secret. Old epoch keys are deleted → forward secrecy.
6
Key Rotation & Epoch Transitions
Key rotation is how MLS achieves forward secrecy and post-compromise security. Any member can trigger a rotation at any time by issuing an Update proposal and Commit.
Key Update Flow (TreeKEM)
Post-Compromise Security in Action
Imagine an attacker steals Bob's leaf private key during Epoch 3. They can decrypt messages in that epoch. But when any member (Alice, Carol, or even Bob himself) issues an Update Commit, the tree is re-keyed. The attacker's stolen key is now useless — they're locked out of Epoch 4 onward. This is dramatically better than Signal's group encryption (sender keys) which has no per-update tree healing.
7
Identity: Nostr Keys as MLS Credentials
Standard MLS uses X.509 certificates for identity. Marmot replaces this with Nostr secp256k1 keypairs. Your npub is your credential. Trust comes from the Nostr social graph (follows, NIP-05 verification), not a certificate authority.
Key Relationships
NOSTR IDENTITY KEY
secp256k1 keypair
nsec (private) → npub (public)
Long-term identity. Same key used for Nostr social posts, follows, etc. This is NOT your Bitcoin key (different derivation paths).
MLS SIGNING KEY
Linked to Nostr key
Signs MLS Proposals and Commits.
Proves group operations came from a specific Nostr identity. May be derived from or associated with the Nostr key.
MLS HPKE KEY (per epoch)
Ephemeral, rotated each epoch
Used in the ratchet tree for key encapsulation.
Updated during Commits → provides forward secrecy. Old HPKE keys are deleted after epoch transition.
KeyPackage = MLS signing key + HPKE init key + Nostr npub credential + capabilities → published to relays
Secp256k1 Alignment
Both Nostr and Bitcoin use secp256k1. While you should never use the same key for both (different threat models), the cryptographic alignment means the ecosystem of tools, libraries, and mental models transfers directly. If you understand Bitcoin key management, you understand Nostr/Sloth key management.