NIP-EE: E2EE Messaging using MLS
NIP-EE adapted Messaging Layer Security to Nostr for private group messaging with forward secrecy and post-compromise security, but it is now marked unrecommended because the Marmot Protocol supersedes it.
Nostr DMs needed more than encrypted content
The early Nostr DM story was not enough. NIP-04 encrypted content but leaked metadata. NIP-44 improved encryption primitives. NIP-17 combined NIP-44 with gift wrapping to hide more metadata. Yet forward secrecy, post-compromise security and efficient group messaging remained difficult.
NIP-EE tried to adapt the Messaging Layer Security protocol to Nostr. MLS is designed for secure group messaging, with epochs, commits, proposals, ratchet trees and key packages. The goal was private and confidential DMs and group messages using decentralized relays.
The ambition was serious: a secure messenger that does not depend on one centralized delivery service.
Nostr as authentication and delivery around MLS
The NIP focuses on how Nostr can perform the authentication and delivery-service functions needed by MLS. MLS libraries such as OpenMLS handle the cryptographic group state, while Nostr events carry key packages, group evolution and encrypted application messages.
The file explains credentials, group events, key-package events, welcome flows, proposals, commits and exporter secrets. It also spends real space on security considerations, because group messaging is not a normal app-layer event.
The current official header changes the product conclusion: final but unrecommended, superseded by the Marmot Protocol.
Jeff Gardner added NIP-EE, then Marmot replaced it
Jeff Gardner added NIP-EE in August 2025 through PR #1427 and later clarified exporter-secret use with NIP-44. In December 2025, JeffG replaced NIP-EE with Marmot through PR #2154, adding the warning that the NIP is superseded.
White Noise and Marmot are the practical ecosystem signals. White Noise moved from an archived Flutter repo to active development under the Marmot/whitenoise codebase. The Marmot Protocol describes secure, decentralized group messaging that combines MLS with Nostr.
So the right page is not a victory lap for NIP-EE. It is a bridge: read it to understand the MLS-on-Nostr design path, then follow Marmot for current work.
Use Marmot for current product work
A secure messaging client should not build blindly on NIP-EE today. The official file points to Marmot, and White Noise describes itself as implementing Marmot-style MLS group messaging over Nostr.
The underlying lessons remain valuable: protect metadata, manage devices carefully, delete key material, handle out-of-order delivery and make group membership changes auditable.
Messaging UX should communicate security properties carefully. Forward secrecy and post-compromise security are not slogans; they depend on correct key lifecycle and implementation discipline.
Secure messaging fails at the edges
The cryptography can be sound while the product leaks metadata, device state or membership information. Relays, push notifications, backups and multi-device flows all need care.
Because the NIP is superseded, presenting it as the current path would be wrong. It belongs in the archive as context for why Marmot exists.
Direct sources
Use the official file first, then the commit history, implementation references and adjacent standards. NIPs move, and product guidance gets weaker when those source trails are hidden.
