MIMI stands for More Instant Messaging Interoperability. The working group was chartered in 2023, shortly after the DMA's interoperability mandate made the question urgent: if WhatsApp must accept messages from third-party apps, what protocol do those messages travel over? The DMA's answer so far has been bilateral. Meta published a reference offer, and each willing provider signs an agreement and integrates against Meta's specific APIs, using the Signal protocol for the encryption layer. That works, but it scales as a series of one-off contracts. Every new pairing is a new negotiation and a new integration.
MIMI is the attempt to replace those one-off contracts with a standard. One protocol for how servers exchange messages, one encryption layer, one format for message content, so that a provider integrates once and can then talk to anyone else who implements the same documents.
One Encryption Layer: MLS
The first decision the working group made was to build on MLS, the Messaging Layer Security protocol, published as RFC 9420 in 2023. This solves the hardest cross-provider problem before it starts. In an interoperable group chat, the members hold accounts at different companies. No single server can be trusted to hold the group's keys, because every server in the picture is a potential adversary from some member's point of view.
MLS was designed for exactly this situation. Group members maintain a shared cryptographic state (the ratchet tree) that updates as people join and leave, and the servers in the middle only ever handle ciphertext and public keying material. A provider that relays a MIMI room's traffic can see that the room exists and who is in it. It cannot read the messages, because the endpoints, the apps on people's phones, hold the keys.
Rooms With a Hub
The second decision is about topology, and it is where MIMI departs from older federation designs. In XMPP, and in Matrix, servers federate as peers: each participating server holds a copy of the conversation state and they reconcile with each other. Matrix in particular spends enormous engineering effort on state resolution, the algorithm that decides what the room's membership and settings are when servers disagree.
MIMI's room model avoids that reconciliation problem by declaring one server the authority. Every room has a hub provider, typically the provider of the person who created the room. The hub sequences the messages, enforces the room's policy, and fans traffic out to the other providers, called followers, whose users are in the room. There is exactly one order of events because exactly one server produces it.
The hub orders messages and enforces membership policy, but it operates on MLS ciphertext. A hub can refuse to deliver a message or eject a participant. It cannot read the message it refuses to deliver. Authority over the room and access to its contents are separated by construction.
The trade is deliberate. A hub is a single point of failure for a given room, and it learns the room's metadata: membership, timing, message sizes. In exchange, the protocol drops the most failure-prone machinery in federated messaging. Whether that trade is right is a live argument, but it is at least an argument the working group had on purpose.
A Common Format for the Messages Themselves
Encryption and transport are not enough. If one app sends a reply with a quoted message and a thumbs-up reaction, the receiving app needs to know what those things are, or the conversation degrades into unformatted text. MIMI's content format draft defines a common structure for the message body that travels inside the MLS payload: text with markup, replies that reference the message they answer, reactions, edits, deletions, and attachments referenced by hash rather than embedded.
This layer is easy to underestimate. It is where user experience across providers is decided. Two messengers can share perfect cryptography and still mangle each other's messages if one of them treats an edit as a new message or drops the reply reference. The content format is the difference between interoperability on paper and a conversation that actually reads as a conversation.
Consent Before Contact
Email is the cautionary tale here. It is the most successful interoperable messaging system ever deployed, and its openness is why a large fraction of all email is spam. Any server can send to any address, so every mailbox on Earth is reachable by every spammer on Earth.
MIMI builds consent into the protocol instead of bolting filtering on afterward. Before messages flow between users at different providers, there is a connection step: a request that the recipient's side must accept before the sender can deliver anything further. A provider can enforce that policy at the server, dropping traffic from senders its user never agreed to hear from. Cross-provider reachability becomes opt-in per relationship rather than a permanent open door.
Where It Stands
| Piece | Status |
|---|---|
| MLS encryption layer | Published standard (RFC 9420), multiple interoperating implementations |
| Architecture and room protocol | Working group drafts, still changing between revisions |
| Content format | Working group draft with running implementations |
| Adoption by large platforms | None committed. DMA interoperability so far runs on bilateral agreements, not MIMI |
That last row is the sober part. A standard for interoperable messaging only matters if messengers implement it, and the platforms with the largest user bases are under no obligation to pick MIMI over their own reference offers. The DMA created the legal pressure; MIMI is a bet that when more providers need to interconnect, a standard beats a pile of contracts. Smaller providers have the most to gain, since they are the ones who cannot afford a bespoke integration per peer. Haven maintains an open, Apache-licensed interop library implementing the MIMI content format and room primitives, and the drafts have held up well in code: most of what we found ambiguous was at the edges, and the working group process exists precisely to grind those edges down.
If you want the deeper background on the group-encryption machinery MIMI inherits, start with our MLS explainer and the comparison of secure group chat protocols. For the regulatory side, the DMA interoperability post covers what the law requires and what it left open.