XMTP: Now with secure and private group chat—built with MLS

We’re thrilled to announce that XMTP now supports group chat! This highly requested feature has been a while in the making, and we’re excited to finally bring it to you. The team has worked tirelessly to ensure that group chats come with robust security guarantees, built with MLS, making conversations more secure than ever. We couldn’t have achieved this milestone without the dedication of the core team and the continuous support and feedback of the amazing XMTP developer community. Dive into this post by XMTP’s core cryptographer, Daniel Zhou, to learn about the features that make XMTP’s group chat experience uniquely secure and private.

— Naomi Plasterer, Senior Staff Software Engineer for XMTP

How XMTP x MLS delivers uniquely secure group chat

At its foundation, XMTP (Extensible Message Transport Protocol) is designed to ensure secure and private communication. Of course, designing and building group chat was no different. We leveraged the following resources to deliver uniquely secure group chat:

Specifically, XMTP group chat inherits the comprehensive security properties of the MLS standard listed below:

  • Message confidentiality

    Ensures that the contents of messages in transit cannot be read without the corresponding encryption keys.

  • Forward secrecy

    Ensures that past messages remain secure even if current encryption keys are compromised.

  • Post-compromise security

    Ensures that future messages remain secure even if current encryption keys are compromised.

  • Message authentication

    Validates the identity of the participants in the conversation, preventing impersonation.

  • Message integrity

    Ensures that messages cannot be tampered with during transit.

  • Group state and operation protection

    Protects the group state cryptographically and hides group operations from the server or infrastructure.

In addition to the security properties provided by MLS, XMTP also adds:

  • User anonymity

    Ensures that outsiders cannot deduce the participants of a group, users who have interacted with each other, or the sender or recipient of individual messages.

A deep dive into group chat security properties

Message confidentiality

Message confidentiality is achieved through symmetric encryption, ensuring that only intended recipients can read the message content. AEAD (Authenticated Encryption with Associated Data) **is used to encrypt the message content, providing robust protection against unauthorized access.

Forward secrecy

Forward secrecy ensures that even if current session keys are compromised, previous communications remain secure. MLS achieves this by using the ratcheting mechanism, where the keys used to encrypt application messages are ratcheted forward every time a message is sent. When the old key is deleted, old messages cannot be decrypted, even if the newer keys are known. This property is supported by using ephemeral keys during the key encapsulation process.

Post-compromise security

Post-compromise security ensures that future messages remain secure after a compromise. XMTP uses regular key rotation achieved through a commit mechanism with a specific update path in MLS, meaning a new group secret is encrypted to all other members. This essentially resets the key and an attacker with the old state cannot derive the new secret, as long as the private key from the leaf node in the ratchet tree construction has not been compromised. This ensures forward secrecy and protection against future compromises.

Message authentication

XMTP uses digital signatures to strongly guarantee message authenticity. These signatures ensure that each message is cryptographically signed by the sender, verifying the sender’s identity without revealing it to unauthorized parties. This prevents attackers from impersonating conversation participants.

Message integrity

Message integrity is crucial to ensure that messages are genuine and unaltered. XMTP achieves this through the use of MLS. The combination of digital signatures and AEAD enables XMTP to detect changes to message content.

User anonymity

User anonymity is achieved through a combination of the following functions:

  • MLS Welcome messages encrypt the sender metadata and group ID, protecting the social graph.
  • XMTP adds a layer of encryption to MLS Welcome messages using HPKE (Hybrid Public Key Encryption). This prevents multiple recipients of the same Welcome message from being correlated to the same group.
  • XMTP uses MLS PrivateMessage framing to hide the sender and content of group messages.
  • XMTP’s backend does not authenticate reads or writes and only implements per-IP rate limits. Aside from Welcome messages, all payloads for a given group are stored under a single group ID, and any client may anonymously query or write to any group ID. Only legitimate members possess the correct encryption keys for a given group.

It is technically possible for XMTP network node operators to analyze query patterns per IP address. However, clients may choose to obfuscate this information using proxying/onion routing.

XMTP currently hides the sender of Welcome messages (used to add users to a group) but does not hide the Welcome message recipients. This makes it possible to determine how many groups a user was invited to but not whether the user did anything about the invitations.

Cryptographic tools in use

XMTP group chat uses the ciphersuite MLS_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519.

Here is a summary of individual cryptographic tools used to collectively ensure that XMTP group chat communications are secure, authenticated, and tamper-proof:

  • HPKE

    Used to encrypt Welcome messages, protect the identities of group invitees, and maintain the confidentiality of group membership. The ciphersuite we use is HPKEX25519.

  • AEAD

    Used to ensure both confidentiality and integrity of messages. In particular, we use the ciphersuite CHACHA20POLY1305.

  • SHA3_256 and SHA2_256

    XMTP uses two cryptographic hash functions to ensure data integrity and provide strong cryptographic binding. SHA3_256 is used in the multi-wallet identity structure. SHA2_256 is used in MLS. The ciphersuite is SHA256.

  • Ed25519

    Used for digital signatures to provide secure, high-performance signing and verification of messages. The ciphersuite is Ed25519.

Stay secure, communicate freely, and trust in the strength of XMTP and MLS to protect your group chats,

— Daniel Zhou, Principal Cryptography Engineer for XMTP

Use it

You’ll benefit from these security guarantees and more when you use group chat in apps built with XMTP, including Converse, the simplest and fastest XMTP app—soon with group chat!

Join the waitlist

Build it

To learn how to build group chat in apps built with XMTP, see Build group chat with XMTP.


Such a major milestone in XMTP’s progression. Hats off to all the devs on this one—excited to start moving some group chats over into a space that’s private, open, and not run by big tech. :love_letter:

1 Like

I’ve been thinking about a similar system and I’m curious how you deal with concurrency. For example, according to the docs a “super admin” has the power to add and remove users, and the power to make other users “super admin”.

What happens if:

  1. Two super admins remove each other
  2. One super admin adds users, and then is removed
  3. One super admin is removed and then maliciously removes everyone, deletes messages, etc.

A related question is, can a group chat in XMTP become partitioned in the CAP-theorem sense and what happens in relation to access control if it does become partitioned?


Thanks for the questions @Holmes_Wilson ! I can field your questions about super admins.

For all your questions, it’s relevant to keep in mind the XMTP permissions rule that if a super admin removal results in there being less than 1 super admin, then that removal is treated as invalid. (i.e. there must always be one super admin). See specific responses below:

  1. [What happens if] Two super admins remove each other

For updating super admin lists, we utilize an MLS “commit” message that updates “group context data” (which includes a group’s list of super admins). MLS requires a strict ordering of commit messages. This ordering is enforced by the backend XMTP node so each group member can validate commit messages in the same order. So all members of the group will have consensus that one of the super admin removal actions happened first. If a super admin loses their super admin status because of a valid super admin removal action, or they are no longer a member of the group, then subsequent super admin removals initiated by that user would be treated as invalid by all members of the group and ignored.

  1. [What happens if] One super admin adds users, and then is removed

In this case, the other users added would still be part of the group after the super admin who added them is removed.

  1. [What happens if] One super admin is removed and then maliciously removes everyone, deletes messages, etc…

Once a super admin is removed from a group, they are unable to submit any messages to the group, including commit messages that alter the group state.

I’ll let someone else chime in on the question about CAP-theorem, but let me know if I answered your other questions above. Similar questions about permissions or anything else to help try and poke holes / identify edge cases are super welcomed!


Thank you!

Is there anywhere I can learn more about how XMTP nodes enforce ordering, or should I just look at the code?

Specifically I’m wondering if each group chat must pick an XMTP node and only use that one node forever, or if XMTP nodes are running a consensus algorithm to determine an ordering and then broadcasting that order only once it’s complete.

1 Like

Hi @Holmes_Wilson, the XMTP backend is currently centralized, so all group chats use the same node today. We are working on decentralizing by the end of the year - the current plan is to use an L3 blockchain for strictly ordered data (e.g. MLS commits), and a gossip network for loosely ordered data (e.g. MLS application messages).

The former is essentially a consensus algorithm as you mention. For the latter, SDK’s will default to a ‘preferred node’ per conversation, but there is no requirement for application developers or end users to use this node, they may select a different node or multiple nodes. I see you’re working in a similar space, would love any feedback you may have!

1 Like

This all sounds right to me!

The only feedback I’d have is that there are some interactions between access control and other content in the group chat where you might want consistency. For example, once you do implement deletion, perhaps a malicious removed super admin could broadcast a “I’m a super admin; delete all messages!” command if deletion was not required to be posted to the blockchain and ordered along with access control. So a solution would be to treat deletion, at least deletion of messages that were not your own, like an MLS commit.

1 Like

Great callout! We need to be very deliberate about what qualifies as strictly ordered vs loosely ordered data; we also need to be careful about ordering between loosely ordered and strictly ordered data. A similar scenario would be if a removed member continues sending messages on a previous epoch.