The Marmot Protocol: Six Specifications for Private Group Messaging on Nostr

The Marmot Protocol is an open specification for encrypted group messaging built on Nostr and the MLS (Messaging Layer Security) cryptographic standard. It defines how a group of people can communicate privately over a decentralised network without trusting any single server or exposing the fact that they are communicating at all.

The protocol is documented across six Marmot Implementation Proposals, MIP-00 through MIP-05. Four are mandatory for any compatible implementation. Two are optional extensions. Together they form a layered system covering identity, group creation, member onboarding, messaging, encrypted media sharing, and push notifications.

Working implementations already exist in Rust (the Marmot Development Kit, or MDK) and TypeScript (marmot-ts). The reference client is White Noise, a cross-platform messaging application built by Jeff Gardner and Max Hillebrand that uses Nostr for identity and data transmission and MLS for message security.

This article walks through each specification and what it does.

MIP-00: Identity and key management

Every Marmot user starts with a Nostr keypair. MIP-00 links that identity to a separate MLS signing key used to authenticate messages within encrypted groups. The separation is deliberate. If someone compromises a group signing key, the Nostr identity remains untouched.

The specification introduces KeyPackages, published as Nostr events (kind 443), which function as public invitation cards. Each KeyPackage contains an ephemeral HPKE public key whose corresponding private key sits only on the user's device. Once that key is used to join a group, the specification requires the client to securely delete the private key material from memory and disk. This provides forward secrecy at the invitation layer. Even if an attacker later compromises the device, captured KeyPackages from the past cannot be decrypted to reveal which groups the user was invited to.

The specification also supports a "last resort" KeyPackage for handling race conditions when multiple invitations arrive simultaneously, and recommends periodic signing key rotation within groups to limit the damage from any single key compromise.

MIP-01: Group construction

MIP-01 defines how groups are created. Every MLS group gets a unique 32-byte identifier that is never published to relays. This matters because the identifier itself could reveal the existence and timing of group creation to anyone monitoring relay traffic.

Before creating a group, a client must verify that all intended members support compatible cryptographic parameters by checking their published KeyPackages. The group creator then establishes the initial MLS state and sets up the ratchet tree that manages cryptographic keys as members join and leave.

The central feature of MIP-01 is the Marmot Group Data Extension, a custom MLS extension that carries Nostr-specific metadata inside the cryptographically authenticated group state. This extension stores the group name and description, admin public keys, relay preferences for message distribution, and encryption parameters for the group avatar image. Because this data lives inside the MLS group context, any modification requires a valid MLS Commit signed by an authorised admin. An attacker who compromises a relay cannot forge a group name change or inject a fake admin key.

Group avatars are encrypted with ChaCha20-Poly1305 using keys derived through HKDF, then uploaded to Blossom storage servers as opaque encrypted blobs. The upload authentication uses a separate keypair derived from an independent seed, ensuring that the encryption key and the upload credential are cryptographically isolated.

MIP-02: Welcome events and member onboarding

MIP-02 defines Welcome Events (kind 444), the mechanism through which new members receive everything they need to participate: group secrets, current member state, the ratchet tree structure, and all active extensions including the group metadata from MIP-01.

Welcome Events are wrapped in NIP-59 gift wrapping, a Nostr privacy technique that hides both the sender and recipient from relay operators. The inner Welcome event is deliberately unsigned. If it somehow leaks, it cannot be published to a public relay because most relays reject unsigned events.

Timing is critical. The admin who adds a new member must wait for relay confirmation that the associated Commit message has been accepted before sending the Welcome. Without this sequencing, a state fork can occur: the new member activates at a group epoch that existing members have not reached yet, and messages become mutually un-decryptable. In a centralised system this ordering is trivial. In Nostr's distributed relay network, messages can arrive out of order across different relays. MIP-02 solves this by making the admin responsible for waiting.

After joining, new members should perform a self-update as soon as possible, generating fresh key material that was never published or observable on any relay. The specification recommends completing this update before sending any messages and requires it within 24 hours.

MIP-03: Messaging and group governance

MIP-03 is the core of the protocol. It defines Group Events (kind 445) that carry all group communication: control messages for managing the group and application messages for conversations.

Every Group Event is encrypted with ChaCha20-Poly1305 using a key derived from the MLS exporter secret for the current epoch. The encryption key remains stable for an entire epoch, so nonce uniqueness becomes the sole protection against keystream reuse. The specification requires cryptographically random 12-byte nonces for every event and mandates that if the random number generator fails, the encryption operation must abort entirely. There is no fallback.

Each Group Event is published using an ephemeral Nostr keypair generated fresh for that single event. An observer watching relay traffic cannot link two messages to the same sender. The only visible identifier is the group's Nostr group ID in the h tag, which tells relays where to route the message but reveals nothing about who sent it.

Group governance operates through a proposal and commit system. Any member can propose changes. Only admins can commit those proposals into the group state, with one exception: any member can perform a self-update Commit that rotates their own key material, regardless of admin status. This prevents a situation where a non-admin user cannot maintain their own forward secrecy.

When competing Commits arrive for the same epoch, the specification resolves the conflict deterministically: pick the Commit with the earliest timestamp and break ties by choosing the lexicographically smallest event ID.

Inside the encrypted envelope, application messages use standard Nostr event formats: kind 9 for chat messages and kind 7 for reactions. These inner events carry the sender's real Nostr pubkey for identity verification but remain unsigned to prevent leakage.

MIP-04: Encrypted media

MIP-04 extends the protocol to handle files. The approach is to encrypt the file, store the encrypted blob on a content-addressed storage system like Blossom, then share the metadata through the group's encrypted channel.

The encryption key for each file is derived deterministically from the MLS exporter secret combined with the file's SHA-256 hash and its MIME type plus filename. The key is unique to both the file and the current MLS epoch, providing forward secrecy for media. The nonce is generated randomly for each encryption operation and stored in the imeta tag alongside the file URL and the original file hash.

The specification explicitly notes a correction from an earlier version. Version 1 used deterministic nonce derivation, which created a vulnerability when the same file was encrypted multiple times with the same metadata. Version 2 fixed this by switching to random nonces, and the specification now requires clients to reject version 1 tags entirely.

Content-addressed storage provides an additional privacy layer. The storage address is the SHA-256 hash of the encrypted content, which appears random to anyone without the decryption key. A storage server cannot correlate encrypted blobs with their original files and cannot tell whether two different blobs contain the same original content, because different epochs produce different encryption keys.

MIP-05: Push notifications without metadata leakage

Push notifications are the privacy hole that most encrypted messengers leave open. The messages may be cryptographically secure, but the push notification that wakes a phone still travels through Apple or Google's infrastructure, logging the fact that a message was received from a particular app at a particular time.

MIP-05 accepts that Apple and Google's push services are unavoidable on mobile devices but removes the need to trust the notification server with anything meaningful. The user's device token is encrypted with the notification server's public key using an ephemeral keypair generated specifically for that encryption. The server can decrypt the token and forward the notification, but it cannot link the token to a Nostr identity or correlate tokens across groups.

Payload padding ensures that all encrypted tokens are exactly 280 bytes regardless of platform, preventing anyone from inferring whether a user runs iOS or Android based on token size. Decoy tokens from other groups are mixed in with real ones when triggering notifications, obscuring group sizes and preventing the server from building social graphs.

The notification trigger itself uses NIP-59 gift wrapping with layered ephemeral keys. The notification server sees a stream of identically structured encrypted events and can extract device tokens from them, but cannot determine who sent them, which group they came from, or how many real recipients exist among the decoys.

Token distribution among group members uses a gossip protocol carried inside the encrypted MLS channel. When a user joins a group, they broadcast their encrypted token along with a request for other members' tokens. Members respond with their complete token lists, and passive observation lets everyone converge on a consistent view without central coordination.

The specification includes a specific prohibition against using Firebase Cloud Messaging as a proxy for iOS devices. If all platforms routed through FCM, Google could correlate users across iOS and Android and across groups, defeating the design that prevents cross-group tracking.

Current status

MLS is an IETF standard (RFC 9420) with years of academic scrutiny. The Marmot Development Kit (MDK) in Rust and the marmot-ts library in TypeScript provide working implementations of the protocol. White Noise, the reference client built by Jeff Gardner and Max Hillebrand, is available on Android and iOS with desktop platform support in development. White Noise describes itself as a non-profit, community-driven project not funded by any corporation.

The protocol requires no phone number and no email address. Identity is a Nostr keypair. Participation in any group is invisible to everyone outside that group. Relay operators see encrypted blobs tagged with group identifiers but cannot read the content or identify the sender. Storage servers hold encrypted files they cannot decrypt. Notification servers forward push alerts they cannot attribute. Every layer is designed so that infrastructure operators learn the minimum information required to perform their function.

The specifications and source code are available on GitHub at github.com/marmot-protocol.

Source: "Inside Marmot: Six Specs That Make Private Group Messaging Work" published on the Towards Liberty blog (March 10, 2026). Additional context from the Marmot Protocol GitHub repository, the White Noise website (whitenoise.chat), and the Citadel Dispatch podcast episode CD166 (July 2025).