]> The Matrix.org Foundation C.I.C.

travisr@matrix.org

The Matrix.org Foundation C.I.C.

matthew@matrix.org

Applications and Real-Time More Instant Messaging Interoperability matrix mimi This document describes Linearized Matrix's transport considerations. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the More Instant Messaging Interoperability Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Linearized Matrix describes an API surface for accessing Matrix rooms in a simple, easy to implement, fashion. Normally a Matrix room would be a Directed Acyclic Graph, requiring servers to implement transport functions to fill gaps, however with Linearized Matrix's API surface the transport considerations are reduced to simply passing events (messages) between servers.

Transport Requirements TODO: This section needs a lot more words.

• HTTPS+JSON for ease of use (or similar)
• Should be reliable (not require constant connection, resilient to network faults where possible)
• Should be simple to understand (RESTful, for example)
• Exact details TBD.

Interoperability Matrix's split of Federation and Client-Server APIs allow homeservers to implement the API surface which is most relevant for its application. For interoperability, only the Federation API is relevant. The APIs have been designed to intrinsically support load balancing and active/active horizontal scaling - for instance, it's valid for different parts of a server to race together when sending a message in a room, avoiding the need for global locks within the server. TODO: Is this still true with Linearized Matrix? Can we really avoid locks, or are we going to need both active servers to behave the same? The steps needed for an existing system to be interoperable with another over Matrix would mean implementing portions of the Federation API. TODO: Define that minimized API surface (much of the Federation API is actually for DAGs, which we don't care about here).

Encryption End-to-end Encryption is deliberately layered on top of the Matrix transport (Client-Server or Federation APIs). Currently a combination of Double Ratchet (Olm) encryption and group ratchet encryption (Megolm) is specified in the End-to-End Encryption section of the Client-Server API , but Matrix over MLS (with minor bookkeeping to compensate for the lack of a centralised sequencing function in Matrix) is being specified as DMLS.

Security Considerations TODO Security. Matrix has its own threat model that needs to be described here to protect against malicious actors (at the transport level).

Informative References The Matrix.org Foundation C.I.C. The Matrix.org Foundation C.I.C. The Matrix.org Foundation C.I.C. The Matrix.org Foundation C.I.C. Matrix is an existing openly specified decentralized secure communications protocol able to provide a framework for instant messaging interoperability. Matrix rooms (aka conversations) currently use a Directed Acyclic Graph (DAG) for persisting events/ messages. Servers broadcast their changes to the DAG to every other server in order to create new events. This model provides excellent decentralization characteristics and conversation history replication, but proves complex when aiming to use Matrix strictly for interoperability between today's existing messaging service providers, which often do not persist chat history serverside, and do not seek to replicate it between servers. This document explores an API surface for Matrix which optimizes for ease of interoperability at the expense of decentralized conversation history at a per-room level. We call this API surface "Linearized Matrix". Cisco Inria & Mozilla Phoenix R&D Meta Platforms Google University of Oxford Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands.

Acknowledgments TODO acknowledge.