]> 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 the Matrix event format for use over a delivery protocol like Linearized Matrix. 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 Interoperable instant messaging requires a common format for all participants to contribute to the conversation or state of the room. Matrix is an open protocol for interoperable, decentralized, secure communication, and includes a "linearized" API surface to abstract away the complexities of DAGs, described by . Matrix defines a rich taxonomy of arbitrarily extensible payloads of information called "events" to carry information between machines and users, which may in turn be layered over end-to-end encryption. Matrix events have been designed for interoperability from the outset between heterogenous messaging platforms, and define a real-world highest-common denominator set of message types, including:

• Instant messages (plain & rich text)
• End-to-end encrypted payloads
• File transfer
• Reactions (emoji, textual, image-based)
• Edits
• Replies
• Deletions
• Stickers
• Custom emoji
• Voice messages
• Polls
• Static location share
• Live location share (ephemeral)
• Live location share (persistent)
• Spoiler text
• Threaded messages
• Typing notifications
• Read receipts
• Read-up-to markers
• Presence
• 1:1 VoIP signalling
• Multiparty VoIP signalling

Matrix events are extensible, and proposals exist for additional event formats ranging from attaching 3D world geometry to conversations (for openly standardized metaverse communication) through to transferring healthcare data (FHIR).

Matrix Events TODO: Bring spec references into the I-D, like we did with Linearized Matrix. Events are JSON objects which by default follow the formal schemas defined in the Matrix Client Server API , also available as JSON Schema definitions . Events are extensible and may contain additional off-schema prefixed fields, or use prefixed event types not yet defined in the spec. Events then get augumented and signed by the server before being forwarded to other servers/users in the room. These JSON objects have a few key fields:

• type: A string the client can use to determine how to render the event. This is reverse-DNS namespaced, with m. as a privileged prefix for event types formally adopted and defined within the Matrix specification.
• sender: The user ID (@alice:example.org) which sent the event.
• room_id: The room ID (!room:example.org) for where the event was sent.
• content: Type-specific JSON object.
• Other fields (TODO: define these in detail when more relevant to the doc).

Under MSC1767 (a spec change proposal in the existing Matrix open standard ecosystem), callers can combine together multiple event types to provide fallback representations of an event, to provide backwards compatibility when rendering unknown event types. An example of a simple text message would be: fish" } } ]]> This can be made more complex if the sender chooses to mix in other mimetypes: fish" }, { "mimetype": "text/plain", "body": "i am a fish" }, { "mimetype": "application/vnd.exampleorg.message+html", "body": "i am a fish" } ] } } ]]> To demonstrate extensibility, a file upload might look like: (12 KB)", "m.file": { "url": "mxc://example.org/abcd1234", "name": "foo.pdf", "mimetype": "application/pdf", "size": 12345 } } } ]]> In this example, clients which do not understand m.file but do understand m.text (or m.message) would show just the plain text instead of a download button. The alternative to falling back would be to hide the unrenderable event, causing the conversation history to be fragmented: this has clear negative consequences on user experience. Instead, by defining a fallback mechanism the user is still able to participate in the conversation, though might need to ask for more information. It is expected that the "base types" (text messages, images, videos, and generic files) would be supported by all clients to ensure there are sufficient building blocks for future extensibility. A more complete use-case for extensible events is described by "MSC3381: Polls" - clients which do not yet have support for polls can present their users with text fallback for the question and the question asker can manually tally up "improper" responses (if those users simply sent text messages in response to the question). Clients which do support polls would simply show the poll and its question/options for the user to click on - their response would be sent to the room as a (deliberately) unrenderable event for other clients to tally up automatically.

Encryption Matrix has specified an encryption algorithm for events called Megolm, however for the purposes of MIMI it would be desirable to adopt MLS instead. Some bookkeeping changes are required to support MLS in a decentralized environment like Matrix: those are currently defined by .

Security Considerations TODO Security. Future drafts should consider the encryption aspects in particular.

References Normative 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. The Matrix.org Foundation C.I.C. 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. 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".

Acknowledgments TODO acknowledge.