Why OpenMLS

For the last decade, the consumer messaging world has had a clear answer to “what does end-to-end encryption look like for groups?”: the Signal Protocol, with its Double Ratchet and pairwise sender keys. It is excellent. It is also showing its age the moment a group gets larger than a small handful of devices, and it was never designed for the patterns of a workplace — where people join projects, leave teams, lose phones, and rotate hardware on a schedule that consumer messengers do not have to think about.

The new floor for group messaging is MLS, the Messaging Layer Security protocol, standardised in RFC 9420. It is the protocol that powers iMessage’s group chats, that AWS Wickr is migrating onto, and that Cisco, Mozilla, Wire, and others helped design at the IETF. New Journey’s chat slice is built on MLS, specifically the OpenMLS Rust implementation. This post is about why.

What MLS actually is

MLS is, at its core, a continuous group key agreement protocol. The members of a group cooperatively maintain a shared secret. Whenever the membership changes — someone joins, someone leaves, someone’s device is lost — the group performs a fresh key agreement, and a new “epoch” begins. Messages are encrypted with keys derived from the current epoch’s secret.

The trick that makes this scalable is a structure called the ratchet tree: a binary tree where members are leaves, and each internal node holds a key derived from its children. To rotate the group key, you only need to publish updates along a single path from your leaf to the root — O(log n) work, not O(n). A 200-person community can rotate keys without melting a phone.

That is the structural innovation. There are two security properties that fall out of it, and they are the ones that matter for a workplace.

Forward secrecy

If your laptop is stolen tomorrow and the attacker recovers your current keys, they should not be able to read messages you sent yesterday. That is “forward secrecy” — past communications are protected against future key compromise.

MLS gets this from epoch rotation. Each epoch has its own keys, derived from the previous epoch via a one-way function. Compromise the current state and you cannot run the function backwards to recover past epochs. Old messages stay protected because the keys that decrypted them no longer exist on any honest participant’s device.

In practice this means: even with full device compromise, an attacker’s reading window is limited to “what is in this epoch”, which in a healthy group is minutes to hours, not months.

Post-compromise security

Forward secrecy protects the past. Post-compromise security protects the future. If your device is briefly compromised — silent malware, a momentary lapse in custody — and then secured again, MLS guarantees that, after a key rotation event, the attacker is locked out again.

This is the property that consumer protocols struggle with for groups. In a pairwise-encrypted group with sender keys, a compromised member is hard to evict: you have to redistribute new sender keys, and the attacker is racing you. In MLS, the eviction is a primitive: the group performs an Update proposal, the ratchet tree is reshuffled, and the compromised key material no longer derives the new epoch.

For a workspace, this maps onto a real concern. A laptop is left on a train. A phone is sold without being wiped properly. A contractor’s session token is exfiltrated. In all of those cases, you want the consequence to be “we rotate, and the leak stops.” With MLS, that is a primitive operation, not a forensics project.

Why OpenMLS specifically

There are a handful of MLS implementations now. We chose OpenMLS for a few reasons that do not look exciting on a slide but matter when you are running the code:

• It is the reference implementation that several IETF drafts grew up alongside. When you implement to OpenMLS, you are implementing to the protocol the spec authors test against.
• It is written in Rust and works as a library, not a service. We can compile it for desktop, for iOS, for Android, and (importantly) for the same Rust crate the rest of journey_engine runs in. There is no “encryption microservice” boundary, and therefore no place for plaintext to leak across.
• The trust assumptions are auditable. OpenMLS is permissively licensed, has a clear cryptographic provider abstraction, and uses libraries that have themselves been audited. We can read it. So can you.
• It does not do networking. OpenMLS gives us an MLS state machine and a wire format. We are responsible for delivering ciphertext between members. That separation is a feature: our delivery layer (NATS-backed, with at-least-once semantics) does not need to be trusted with plaintext, ever.

The alternative we considered most seriously was rolling our own group ratchet on top of Signal-style primitives. We have written enough cryptographic code to know that the right answer for almost every team — including ours — is “use the implementation the cryptographers already wrote and reviewed.”

What this means if you are an admin

Here is the part that sometimes catches workspace administrators by surprise: we cannot read your messages. Not “we promise we will not.” We cannot. The keys do not exist on our infrastructure. If a court orders us to hand over the contents of a group chat, the contents we have are ciphertext, and the keys are on the members’ devices.

This has practical consequences:

• There is no centralised search of message bodies. Search runs on each member’s device, against the LSM index that holds their decrypted view. (We cover that index in another post.)
• There is no “admin override” to recover a private channel. If everyone in a channel leaves, the channel is unreadable. We cannot, and do not, retain a backdoor.
• Compliance integrations work via the member, not the server. An organisation that needs to retain communications for compliance reasons does so via a member device that has been authorised to export. The server never sees plaintext.

For most teams this is exactly what they want — they signed up for end-to-end encryption meaning something. For teams with regulatory constraints, it requires an honest conversation up front about what the boundary is.

Looking ahead

OpenMLS is the foundation, not the whole story. On top of it we are building tooling for safer key backup (so a lost device does not mean a lost history), federation between MLS groups across organisations, and admin observability that respects the encryption boundary (you can see that messages are flowing without seeing what is in them).

End-to-end encryption used to be a luxury feature. With MLS, it is just how a serious messaging product works. Your team’s conversations deserve the same floor that your personal ones now get by default — and we are not interested in building anything less.