NIP-EE: E2EE Messaging using MLS
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 cannot 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 needs to 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.
Read NIP-EE in the wild
NIP-EE explores end-to-end encrypted messaging using MLS. It points toward group messaging with stronger cryptographic structure than simple pairwise encryption.
MLS adds real protocol weight. Membership changes, key updates, device state and recovery are harder than a normal chat bubble suggests. A product needs to make that complexity understandable without making it scary.
What changes when you actually use it
For you, NIP-EE: E2EE Messaging using MLS Protocol is felt inside the room: who can read, who can reply, what remains visible and what the interface makes private by implication. Messaging standards are risky because familiar chat design can smuggle in promises the protocol never made. Read NIP-04, NIP-44, NIP-17, NIP-59, NIP-70 as the surrounding map before trusting the room label.
What changes for builders and operators
For builders, NIP-EE: E2EE Messaging using MLS Protocol is expectation control. Test the same conversation across relays, devices and clients. Make audience, persistence, encryption and moderation visible. A chat-shaped interface can feel private even when the event is public, and that mismatch is a product bug.
What the official file makes concrete
The official file is organized around Context, Why is this important?, Goals of this NIP, Why MLS?, Core MLS Concepts, Groups, Clients, Messages. Inspect kind 445, kind 10051, kind 444, kind 9, kind 7, unrecommended, Commit, LeafNode because these are the pieces most likely to surface as product behavior. Read it beside NIP-04, NIP-44, NIP-17, NIP-59, NIP-70 before treating it as isolated.
NIP-EE: E2EE Messaging using MLS Protocol needs honest audience language. Public, private, group, encrypted, temporary and moderated are different promises.
Where it breaks
The failure mode in NIP-EE: E2EE Messaging using MLS Protocol is false intimacy. The room feels like a messenger, but storage, audience, reply context or metadata tell a more public story. This is where copywriting, UI labels and protocol behavior need to match exactly.
Where this appears outside the markdown
In the ecosystem, NIP-EE: E2EE Messaging using MLS Protocol touches the most emotionally familiar interface: a conversation. That makes it easy for products to borrow the comfort of chat, groups or DMs while the actual protocol object has different privacy and delivery properties. The page has to slow that moment down before the interface creates a false expectation.
The nearby-standard trap
The nearby-standard trap in NIP-EE: E2EE Messaging using MLS Protocol is using one room word for several protocols. Chat, public chat, private DM, group, forum thread, comment and encrypted envelope are different. Read NIP-04, NIP-44, NIP-17, NIP-59, NIP-70 and keep the interface honest about which promise is actually present.
Language that keeps the feature honest
Good product copy for NIP-EE: E2EE Messaging using MLS Protocol names the room. It says public, encrypted, relay-scoped, group-controlled, archived, temporary or moderation-aware when those things are true. It avoids borrowing private-message comfort for data that travels more openly.
What this page does not promise
NIP-EE: E2EE Messaging using MLS Protocol does not turn every conversation into a private room. A chat-like screen can hide public relays, visible metadata, partial delivery, missing devices or moderation rules that only live on one server. The safe reading is concrete: who can read, where does the event live, what does encryption cover, and what happens when one client leaves?
Read it as a field test
Start NIP-EE: E2EE Messaging using MLS Protocol with the audience. A message-like interface earns trust only when public, private, encrypted, group-scoped and relay-scoped behavior are not blurred. Read NIP-04, NIP-44, NIP-17, NIP-59, NIP-70 before drawing product conclusions, because most messaging mistakes come from using the wrong room model for the event in front of you.
Where the standard earns trust
The source links give you places to test the interpretation in public: Marmot Protocol, White Noise, RFC 9420 MLS, OpenMLS. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-EE source is the anchor for exact wording, and NIP-EE commit history shows how that wording moved over time. The strongest secondary clues here are Marmot Protocol, White Noise, RFC 9420 MLS. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-EE: E2EE Messaging using MLS Protocol: first the human promise, then kind 445, kind 10051, kind 444, kind 9, kind 7, unrecommended, then the implementation record, then the real-world failure case. That order keeps NIP-EE useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who can read the event, and does the screen say that before you type?
- What metadata remains visible even when content is encrypted or wrapped?
- Can another client recover the thread, room or message history without pretending delivery is guaranteed?
What to verify before you rely on it
- Find
kind 445,kind 10051,kind 444,kind 9,kind 7in the official file and check where the UI exposes the same concept. - Read NIP-04, NIP-44, NIP-17, NIP-59, NIP-70 as context before treating NIP-EE as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-EE: E2EE Messaging using MLS Protocol in that order: Official NIP-EE source for the current wording; NIP-EE commit history for the change record; Marmot Protocol, White Noise, RFC 9420 MLS for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
