Marmot Protocol
Marmot Protocol is an experimental secure group-messaging profile that combines Messaging Layer Security group state and cryptography with Nostr identity and relay transport. Its required MIPs define credentials, group construction, welcome events, and group messages; optional proposals cover encrypted media and push notifications.
Interoperability claim
Marmot is a separate protocol specification layered on Nostr, not a property inherited from the Nostr base protocol. Clients implementing the required MIPs are intended to share groups and state, and the Marmot Development Kit includes a conformance simulator and Nostr transport adapter.
That makes Marmot the closest Nostr branch to a deliberately interoperable secure group-chat protocol. It does not make a Marmot room compatible with an ordinary NIP-17 direct-message room or a NIP-29 relay-governed group.
Encryption compared with Signal
Marmot and Signal both provide E2EE, forward secrecy, and a route to PCS, but their ratchets and deployment evidence differ.
| Dimension | Marmot and White Noise | Signal |
|---|---|---|
| Core construction | MLS tree-based group key agreement with epoch updates | PQXDH session establishment plus Double Ratchet; Signal is rolling out a combined post-quantum Triple Ratchet |
| Symmetric encryption | MLS default AES-128-GCM, plus a ChaCha20-Poly1305 outer group-event envelope | Authenticated per-session message encryption derived from ratcheting chain keys |
| Forward secrecy | Old epoch and message secrets are erased according to MLS processing | Old message keys are erased as pairwise ratchets advance |
| Recovery after compromise | A clean MLS Commit or self-update can move the group into a new secure epoch | Fresh ratchet contributions heal pairwise sessions as conversation continues |
| Post-quantum protection | None in the required default ciphersuite; X25519 and Ed25519 are classical | PQXDH protects session establishment against passive future-quantum decryption; the announced Triple Ratchet extends post-quantum refresh through a session |
| Authentication style | MLS credentials bind group-specific signing keys to Nostr public keys; authenticated group messages favor accountability | Pairwise identity keys, safety numbers, and deniable session authentication |
| Group design | Group membership and cryptographic state are native to MLS and scale through a ratchet tree | Signal uses its own private-group and pairwise or sender-key constructions rather than MLS |
| Evidence | Standardized MLS foundation, protocol review, and recent MDK and client audits; young profile and implementations | More than a decade of deployment, protocol analysis, multiple revisions, and a much larger adversarial surface tested in practice |
The primitive-level comparison is not a reason to call Marmot weak. X25519, AES-128-GCM, ChaCha20-Poly1305, SHA-256, and Ed25519 are strong classical choices. The material gaps are post-quantum protection, the frequency and reliability of MLS state updates, metadata at the Nostr transport boundary, and implementation maturity.
White Noise and Marmot security reviews documents why the integration layer matters: the audits found serious identity, authorization, storage, and state-convergence defects even though the underlying MLS cryptography was sound.
Secure and decentralized communication stacks places Marmot within the Nostr compatibility layers.