Private Messages on Nostr with MLS

What is MLS (Message Layer Security)? How is it different from what we had in Nostr? Read on!

Jul 14, 2025

With 0xChat Lite and White Noise appearing in the Nostr Ecosystem, some wonder, What is the difference? What is the novelty?

The answer is the implementation of the MLS NIP (NIP-EE, as proposed in Pull Request #1427), which introduces a new approach to private messaging on Nostr using the Messaging Layer Security (MLS) protocol, differing significantly from older NIPs like the obsolete NIP-04 (which leaks metadata) and NIP-17 (a quite decent and safe option, currently in 0xChat and Amethyst), which were designed for private direct messages (DMs) and small group chats.

Below is a detailed comparison of MLS NIP (NIP-EE) and the older NIPs (NIP-04 and NIP-17) in terms of their approach to private messaging on Nostr:

1. Protocol Foundation

MLS NIP (NIP-EE):
- Utilizes the MLS protocol, a standardized, modern cryptographic protocol designed for secure group messaging with support for end-to-end encryption (E2EE), forward secrecy (FS), and post-compromise security (PCS). MLS is optimized for efficient group communication, including pairwise DMs as a special case of group messaging (a group of two).
- Employs a tree-based key management system where each device/client pair is represented as a LeafNode in the MLS tree. This allows for scalable group messaging, where keys are rotated after each group operation (e.g., adding/removing members or sending messages) to ensure FS and PCS.
- Uses KeyPackage Events to authenticate users and distribute cryptographic material asynchronously. These are single-use to prevent replay attacks, and clients must manage key rotation carefully.
Old NIPs:
- NIP-04: Uses AES-256-CBC encryption with a shared secret derived from the sender’s private key and the receiver’s public key via ECDH (Elliptic Curve Diffie-Hellman). The shared secret is not hashed, and the encryption lacks message authentication, making it vulnerable to undetected tampering. It’s primarily designed for one-to-one DMs and does not support group messaging.
- NIP-17: Builds on NIP-04 by incorporating NIP-44 encryption (ChaCha20 with HKDF-derived keys) and NIP-59 gift-wrapping to enhance privacy. It uses unsigned kind:14 (chat messages) and kind:15 (group chat messages) events, sealed (kind:13) and gift-wrapped (kind:1059) to hide metadata. It supports small group chats (up to ~100 participants) but scales poorly for larger groups due to the need to send separate encrypted events to each receiver. Key Difference: MLS NIP leverages a robust, standardized protocol (MLS) designed for scalable group messaging with advanced security features, while NIP-04 and NIP-17 rely on simpler encryption schemes (AES-256-CBC and ChaCha20) tailored for one-to-one or small group DMs, with less focus on scalability or advanced security properties like FS and PCS.

2. Security Features

MLS NIP (NIP-EE):
- Forward Secrecy (FS): Achieved by rotating keys after each group epoch (e.g., after each message or group membership change). Old keys are discarded, ensuring that compromised keys cannot decrypt past messages
- Post-Compromise Security (PCS): If a key is compromised, MLS allows the group to recover security through key rotation in subsequent epochs.
- Group Messaging: Designed for both direct and group messaging, with efficient key management for groups of arbitrary size. Each member’s state is independent, and multiple devices per user are treated as separate members.
- Replay Attack Prevention: KeyPackage Events are single-use, and clients must carefully select relays that support event deletion to mitigate replay risks.
- Metadata Privacy: While MLS itself focuses on content encryption, it integrates with Nostr’s relay system, requiring careful relay selection to avoid metadata leakage. Clients can enforce freshness checks on KeyPackage Events to enhance security.
Old NIPs:
- NIP-04:
  - No Forward Secrecy: The shared secret (conversation key) is static, derived from the sender’s private key and receiver’s public key. If either key is compromised, all past and future messages can be decrypted.
  - No Post-Compromise Security: No mechanism exists to recover security after a key compromise.
  - Metadata Leakage: The recipient’s public key is included in the event’s tags, potentially revealing who is communicating.
  - Vulnerability to Tampering: Lacks message authentication, allowing relays to alter messages undetected.
- NIP-17:
  - Optional Forward Secrecy: Supports “disappearing messages” via expiration tags, but FS is not inherent to the encryption scheme. If the user’s private key or conversation key is compromised, all messages are at risk.
  - Improved Metadata Privacy: Uses NIP-59 gift-wrapping to hide participant identities, event kinds, and timestamps, making it harder to link senders and receivers. Randomizing created_at timestamps further reduces metadata leakage.
  - No PCS: Like NIP-04, it lacks mechanisms to recover security post-compromise.
  - Group Messaging Limitation: Scales poorly for large groups, as each message requires a separate encrypted event per receiver, leading to O(participants * messages) overhead.

Key Difference: MLS NIP provides robust FS and PCS through key rotation and MLS’s tree-based key management, making it far more secure for both direct and group messaging. NIP-04 lacks FS, PCS, and message authentication, while NIP-17 improves metadata privacy but still lacks inherent FS and PCS and is inefficient for large groups.

3. Group Messaging Support

MLS NIP (NIP-EE):
- Designed for scalable group messaging, supporting both small and large groups efficiently. MLS’s tree-based structure allows for logarithmic scaling of key updates, making it suitable for groups of any size.
- Each device/client pair is a separate LeafNode, meaning users joining from multiple devices are treated as distinct group members, simplifying state management but requiring separate additions for each device.
- Supports dynamic group operations (adding/removing members) with key rotation to maintain security.
Old NIPs:
- NIP-04: Does not support group messaging; it is strictly for one-to-one DMs.
- NIP-17: Supports small group chats (up to ~100 participants) by sending separate encrypted events to each receiver. This approach is inefficient for large groups due to the linear increase in data with the number of participants and messages. There are no group admins or invitations, which simplifies the model but limits control.

Key Difference: MLS NIP is optimized for group messaging with efficient key management and scalability, while NIP-04 is limited to one-to-one DMs, and NIP-17’s group messaging is inefficient and not scalable for large groups.

4. Metadata Privacy

MLS NIP (NIP-EE):
- Metadata privacy depends on Nostr’s relay-based architecture. MLS NIP recommends selecting relays that support event deletion and using freshness checks for KeyPackage Events to reduce the risk of metadata leakage. However, it does not inherently hide participant identities or message metadata as robustly as NIP-17.
- Focuses primarily on content encryption, leaving metadata privacy to client and relay implementation choices.
Old NIPs:
- NIP-04: Leaks metadata by including the recipient’s public key in event tags, making it possible to infer who is communicating.
- NIP-17: Significantly improves metadata privacy by using NIP-59 gift-wrapping to hide participant identities, event kinds, and timestamps. It randomizes created_at timestamps (up to two days in the past) and uses kind:1059 gift-wraps to obscure who is talking to whom. Clients can use alias keys for receiving DMs to further protect identity.

Key Difference: NIP-17 offers stronger metadata privacy through gift-wrapping and timestamp randomization, while MLS NIP relies on careful relay selection and client-side mitigations, as MLS focuses more on content encryption than metadata hiding.

5. Encryption Mechanism

MLS NIP (NIP-EE):
- Uses MLS’s encryption, which involves symmetric ratchet trees for key derivation and rotation. Messages are encrypted within MLSMessage objects, and content fields may use NIP-44 encryption with a group-specific key derived from the MLS exporter_secret (rotated per epoch).
- KeyPackage Events use distinct signing keys (not the user’s Nostr identity key) to authenticate group members, reducing the risk of identity key compromise.
- Integrates with libraries like nostr-openmls, which handle epoch tracking and key rotation.
Old NIPs:
- NIP-04: Uses AES-256-CBC with a static shared secret derived via ECDH (unhashed X coordinate of the shared point). The initialization vector (IV) is appended to the encrypted content. Lacks message authentication, making it vulnerable to tampering.
- NIP-17: Uses NIP-44 encryption, which employs ChaCha20 with a conversation key derived via HKDF (using SHA256) from the ECDH shared secret. Includes a custom padding scheme and base64 encoding for compatibility. Supports metadata hiding via NIP-59 gift-wrapping but still uses a static conversation key, limiting FS.

Key Difference: MLS NIP uses a dynamic, tree-based encryption system with key rotation for FS and PCS, while NIP-04 and NIP-17 use simpler, static key-based encryption (AES-256-CBC and ChaCha20, respectively), with NIP-17 adding metadata protections but no inherent key rotation.

6. Implementation Complexity

MLS NIP (NIP-EE):
- More complex to implement due to the MLS protocol’s tree-based key management and epoch tracking. Requires integration with MLS libraries (e.g., OpenMLS) and careful management of KeyPackage Events and group states.
- Clients must handle key rotation, epoch synchronization, and relay selection, increasing development effort but enabling advanced security and scalability.
Old NIPs:
- NIP-04: Simple to implement, requiring only ECDH key derivation and AES-256-CBC encryption. However, its simplicity comes at the cost of weaker security.
- NIP-17: Moderately complex due to the combination of NIP-44 encryption and NIP-59 gift-wrapping. Requires clients to handle unsigned events, seals, and gift-wraps, but is simpler than MLS for small-scale DMs.

Key Difference: MLS NIP is more complex due to its advanced cryptographic framework and group messaging support, while NIP-04 and NIP-17 are simpler but less secure and scalable.

7. Use Case Suitability

MLS NIP (NIP-EE):
- Ideal for secure, scalable group messaging and direct messaging where FS and PCS are critical (e.g., high-security applications). Suitable for both small and large groups, including professional or sensitive contexts.
- Less focused on metadata privacy, requiring additional client-side measures for high-risk scenarios.
Old NIPs:
- NIP-04: Suitable for basic one-to-one DMs in low-risk scenarios but outdated due to its lack of FS, PCS, and metadata privacy. Not recommended for modern use.
- NIP-17: Suitable for private DMs and small group chats (up to ~100 participants) with a focus on metadata privacy. Ideal for casual or moderately sensitive conversations but not for large groups or high-security needs.

Key Difference: MLS NIP is better for scalable, high-security group messaging, while NIP-04 is limited to basic one-to-one DMs, and NIP-17 balances metadata privacy with small group support but lacks scalability and advanced security.

Conclusion

The MLS NIP (NIP-EE) is a significant advancement over NIP-04 and NIP-17, offering scalable group messaging, forward secrecy, and post-compromise security through the MLS protocol. It is better suited for modern, secure, and scalable private messaging, particularly for larger groups or high-security scenarios. However, it is more complex to implement and relies on careful relay selection for metadata privacy. NIP-04 is outdated due to its lack of FS, PCS, and metadata protections, while NIP-17 improves on NIP-04 with better metadata privacy and small group support but remains inefficient for large groups and lacks inherent FS and PCS. For high-risk use cases, MLS NIP is the preferred choice, but NIP-17 may suffice for smaller, less sensitive conversations where metadata privacy is a priority.

You liked the article? Make my day brighter!

Like, subscribe and share!

Last but not least, the following link is an unstoppable domain, it will open a page in which you can perform an anonymous contribution to support my work:

https://rodswallet.unstoppable/

The link didn’t open?

To open the link you need to use a best in class browser that supports web3, two are recommended: Brave Browser and Opera Browser

Are you a member of the decentralized social network #Nostr ecosystem? If so, consider zapping me anonymously using an eCash or BTC LN wallet supporting BOLT11 at the following address:
- rod@npub.cash
If you are not part of #Nostr, consider joining a vibrant decentralized and uncensorable social network (it is like twitter or telegram), consider the app Amethyst if on Android (best in class with excellent operational security from the get go) and Damus if on iOS

Rod’s Substack