Wen group chat?

XMTP Development Ideas & Improvements
, ,
1

Group chat is by far the most requested feature on XMTP. Almost every day, someone in the community asks, “Wen group chat?” So far, XMTP’s 1:1 chat has been the primary focus; ensuring that it has the reliability, performance, and usability to enable everyone from hackathon devs to public companies like Coinbase to add wallet-to-wallet messaging to their apps. But it’s finally time to tackle groups while improving the security and user privacy of the network.

When evaluating options, the potential solution had to have three key properties:

  • Forward secrecy: A compromise of the device’s key material will not give access to messages received before the compromise.

  • Post-compromise security: A compromise of the device’s key material will not give access to future messages, after the device’s key material has been rotated.

  • Efficiency: Common actions like sending a message, adding/removing members, or rotating your key material should consume the minimum network resources.

Which group chat?

Over the past year, the XMTP core dev team spent a lot of time surveying the field of existing group chat algorithms. There are two common approaches used in the most popular messaging apps worldwide:

  • Pairwise encryption

  • Sender keys

When coupled with a highly secure 1:1 chat protocol, both of these solutions are able to achieve forward secrecy and post-compromise security.

Pairwise encryption

Pairwise encryption is the simplest model. When you want to send a message to the group you simply encrypt a copy of the message for each device of each recipient (including your own devices). It inherits the security properties of your existing 1:1 encryption scheme (double ratchet, RSA, etc). This is the approach taken by iMessage and earlier versions of Signal.

While pairwise encryption is great for simplicity and security, it is not very efficient. If you imagine a chat with 20 members, each of whom has 3 devices, each message has to be encrypted 59 times (you don’t need to send a copy to yourself). 59 payloads have to be transmitted to the server and stored until they are read. This is why pairwise group chats typically have very low limits on the number of members allowed in a group.

Sender keys

Sender keys improve on the inefficiencies of pairwise encryption for at least the base case of sending a message to the group. It also requires a pre-existing secure 1:1 encryption channel. When each device joins the group, it generates a “sender key” and uses the existing 1:1 encrypted messaging channel to send an encrypted copy of that key to each member. They can use this key to send many messages to the group.

When new members join the group, they must follow the same process resulting in N-1 keys being distributed. Periodically, it is expected that each member updates their sender key and distributes the new key to the group resulting in a worst-case of N^2 messages sent for each key update. When a member is removed from the group, all remaining members must rotate their keys and send a copy to all the other remaining members (another worst-case N^2 operation).

Because of this inefficiency, making users regularly update their keys significantly increases the cost of using the protocol. But without regular key updates, the post-compromise security properties of sender keys are weakened.

Sender keys are used in Signal, WhatsApp, Messenger, and Instagram.

To learn more, see “What’s Up With Group Messaging?” by Computerphile:

Why focus on efficiency?

As the XMTP network decentralizes, each message sent or stored will have an economic cost associated with it (paid by either the application or the sender). Even if the cost per message is extremely low, once you start multiplying that number by N^2 it obviously changes the economics of the protocol.

Efficiency is more important to XMTP than it is for WhatsApp or Instagram who have limitless storage and bandwidth available thanks to Meta’s lucrative advertising and surveillance business.

A new kid on the block

A new group encryption protocol aims to solve the efficiency challenges of pairwise encryption and sender keys in a novel way.

Enter Messaging Layer Security (MLS)…

MLS is an emerging internet standard that was approved by the IETF in March of 2023. It is based on previous research projects Asynchronous Ratchet Trees, TreeSync, and TreeKEM, and uses a tree-based public key encryption system to efficiently derive encryption keys for large groups with changing membership. It offers forward secrecy and post-compromise security.

Sending a message only requires a single payload encrypted with the current group secret. Adding or removing members is also accomplished with a single payload, the size and complexity of which scales logarithmically with group size.

There are multiple open source implementations of MLS already available, it has been integrated into production applications, and the security properties have been formally verified. It is being adopted by companies like Wire, Google, AWS Wickr, Matrix, and WebEx.

Choosing MLS allows XMTP to join a growing community of developers working to bring this standard to the mainstream without having to reinvent the wheel.

How group chat?

XMTP group chat using MLS is scheduled to launch in Q1 2024. All group chat implementations will be based on a shared cryptographic backend written in Rust called libxmtp. Group chat will launch with support for iOS, Android, and React Native first, with Javascript and Flutter coming soon after.

libxmtp is written with a database-first architecture, which should significantly reduce complexity for both client applications and XMTP SDKs. Reading messages or listing conversations becomes nearly instantaneous with this architecture since only incremental changes are read from the network and most requests for messages can be served locally.

One of the challenges with the MLS specification is around ordering of messages. A standard implementation of MLS expects that messages are strictly ordered and that new messages may never appear before existing messages. To date, the XMTP network has only had a loose ordering of messages since, with upcoming decentralization of the network, total ordering will not be possible. In the short term, a temporary bridge service allows messages to be published with total ordering. This allows the launch of XMTP group chat before the difficult-but-solvable issue of handling out-of-order message delivery has been resolved. The Matrix project has been working on this exact same problem and is showing good progress, providing a positive signal that this approach will not lead to a dead end.

Once the XMTP community has validated that MLS is working for groups, we intend to use MLS for 1:1 conversations on XMTP as well. MLS provides significant improvements in security, privacy, and performance over the current 1:1 chat implementation. Moving to MLS will allow for per-device revocation of keys, protecting users from malicious applications. It offers forward secrecy and post-compromise security; a set of security features many developers have been demanding. And it gives developers the performance of a database-first client architecture without having to manage that database themselves.

Milestones

Milestone 1 (Early Q1 2024)

  • MLS group chat beta available in iOS, Android, and React Native SDKs

  • XMTP network nodes upgraded to support MLS messaging with total ordering

Milestone 2 (Q2 2024)

Milestone 3 (End of Q2 2024)

  • 1:1 conversations enabled using MLS and libxmtp. There will be a 6 month transition period where all 1:1 messages will be dual-sent over the existing V2 XMTP network and MLS to help ease the transition for apps that are slower to update.

  • Flutter support

Milestone 4 (Q3 2024)

  • Decentralized MLS rollout, removing the requirements for total ordering of messages

FAQ

What exactly do you mean by “group chat”? How big a group can I build?

There isn’t a hard limit set on group size yet, but it will likely start small. Maybe 100 members. MLS can handle quite large groups (10s of thousands of members) in theory. After benchmarking, the limits may increase over time.

MLS is not a great fit for very large public groups where anyone can join freely. A limitation of the protocol is the “malicious insider attack,” where a member of the group can deliberately perform a bad state update, mangling the encryption keys for a portion of the group’s members and breaking things for everyone. This attack is unlikely in small groups where everyone knows each other but is a real problem when emulating something like a large Telegram channel.

XMTP will need a different solution for very large groups.

What are the trust assumptions of the temporary bridge service?

The temporary bridge service will be responsible for

  1. Storing and distributing key packages on behalf of installations

  2. Tracking revocations

  3. Listing all installations for a wallet address

  4. Publishing messages with total ordering

All 4 of the use cases above result in messages that are able to be verified by the client. For example, if the service returned a key package that was not signed by the correct installation or wallet address, the client would detect this and ignore it.

The service is however capable of censoring otherwise valid installations, revocations, or messages and not showing them to the caller. One of the goals of network decentralization is to make this kind of censorship impossible.

6 Likes