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

travisr@matrix.org

Applications and Real-Time More Instant Messaging Interoperability mimi interoperable messaging chat secure messaging The More Instant Messaging Interoperability (MIMI) working group is chartered to use Messaging Layer Security (MLS) for its encryption/security layers. This document implements the architecture described by , detailing the components required to achieve MLS-secured messaging interoperability. 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 The More Instant Messaging Interoperability (MIMI) working group is responsible for specifying the set of protocols required to achieve secure, modern, messaging interoperability using MLS . outlines an overall architecture for interoperable communications, and this document implements those components using MLS and HTTP for the security and specific transport details. Each MIMI room uses state events to track user-level participation and interaction with the room, and an accompanied MLS group for client-level membership and messaging. The MLS group's membership consists of the clients which belong to the participating users in the MIMI room. MLS describes an abstract concept of a "Delivery Service" (DS) that is specifically responsible for ordering handshake messages and more generally delivering messages to the intended recipients. Collectively, all of the servers in a MIMI room fulfill the Delivery Service role, with the hub server performing the ordering of handshake messages. The hub server is additionally responsible for tracking details about the room to assist clients in joining, validating events and handshake messages, and enforcing the required policy against the room and MLS group states. Servers communicate with each other using a mutually authenticated mode of TLS over HTTP . This document does not describe a protocol for clients to communicate with a server. Instead, clients use provider-specific APIs to accomplish "last mile" delivery of events and messages.

• TODO: Describe notion of consent, similar to "connection KeyPackages" in Section 6 of .

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Terms and definitions are inherited from .

Rooms and Events Rooms, described by , contain both state events and an associated MLS group for encryption operations. State events are used to frame information and operations which exist outside of the MLS group, such as the user participation list, room policy, and other metadata. Events are sent in context of a room, authenticated against the room's policy, and ordered by the hub server. Each event additionally contains an event type to differentiate its payload format from other events. A state event is an event with a state key. The combination of the event type and state key form a tuple to establish current state: the most recently sent state events with distinct type and state key pairs. The hub server MUST persist at least the current room state, and MAY discard user participation events for users who are in the leave state. The hub server SHOULD persist all other events for the benefit of other servers in the room.

• TODO: Check that this history requirement matches agreed semantics.

• TODO: Describe where room state is persisted. With this document's transport, it's stored adjacent to the MLS group. See for possible in-MLS persistence.

Event Schema Events are authenticated against their TLS presentation language format (): ; // The event IDs which authorize this event to be sent in the room, // as defined by the policy. // See the "[Event] Authentication" section for information. opaque authEventIds[]; // The event ID of the parent event. This will be an empty string if // the `type` is `m.room.create`. opaque prevEventId; // Additional fields may be present as dependent on event type. } Event; ]]> Note an "event ID" is not specified on the object. The event ID for an event is the sigil $ followed by the URL-Safe Unpadded Base64-encoded reference hash () of the event. The "origin server" of an event is the server implied by the sender field. Events are immutable once sent, but may be redacted () to remove non-critical information.

Authentication Events simultaneously carry information which is critical for the protocol to operate, and other information which is less essential. The less essential information is often user-supplied, and ideally can be removed without "breaking" the room. MIMI supports removing non-critical information from events through redaction. Redaction creates a consistent representation of an event suitable for signing. It is not an approach for "deleting" an event. Deletions are instead handled by the content format for application messages in MIMI. There are two scenarios where a redaction is applied:

1. When a mismatched content hash () for an event is received.
2. When an m.room.redaction () message event is received, targeting an event.

When applying a redaction, all fields described by MUST NOT be removed. Individual event types MAY describe additional fields to retain. All other fields MUST be removed. Events are authenticated against their redacted form. If an event fails authentication, it is rejected. Rejected events are dropped and not forwarded any further. For example, a hub rejecting an event would not send it to follower servers. A follower server rejecting an event sent by a hub would not forward it to local clients. The redacted event is signed () to verify that the event was sent by the referenced originating server. If the signature verification fails, the event is rejected. Each event references a set of "auth events" which permit the event to be sent. This field is populated by the hub server upon receipt of a partial event to send. The specific event types required to be referenced in this field are described by the room policy, but are typically the m.room.create (), and m.room.user () state events at a minimum. If an event is missing a required auth event, or contains a reference to an unknown/rejected event, the event is rejected. If the event's content hash does not match the calculated content hash, the event is redacted before being sent any further. Note that if an event is already manually redacted with a redaction event, it will in most cases fail a content hash check. Individual event types MAY specify additional authentication requirements, such as field validation or ordering requirements.

Reference Hash Events are referenced by ID in relation to each other, forming the room history and auth chain. If the event ID was a sender-generated value, any server along the send or receive path could "replace" that event with another perfectly legal event, both using the same ID. By using a calculated value, namely the reference hash, if a server does try to replace the event then it would result in a completely different event ID. That event ID becomes impossible to reference as it wouldn't be part of the proper room history. An event's reference hash is calculated by redacting it, removing the signature field if present, then serializing the resulting object. The serialized binary is then hashed using SHA256 . To further create an event ID, the resulting hash is encoded using URL-Safe Unpadded Base64 and prefixed with the $ sigil.

• TODO: Reference "URL-Safe Unpadded Base64" specification.

Content Hash An event's content hash prevents servers from modifying details of the event not covered by the reference hash itself. For example, a room name state event doesn't have the name itself covered by a reference hash because it's redacted, so it's instead covered by the content hash, which is in turn covered by the reference hash. This allows the event to later be redacted without affecting the event ID of that event. To calculate a content hash, the following fields are removed from the event first:

• contentHash
• signature
• authEventIds
• prevEventId

authEventIds and prevEventId are removed because they are populated by the hub server. The content hash is to preserve the origin server's event, not the hub server's. The resulting object is then serialized and hashed using SHA256 . Note that the event is not redacted in the calculation of a content hash. This is to ensure that all origin-provided fields are protected by a hash and trigger redaction if a field changed along the send path. The content hash is additionally covered by the reference hash and event signature.

Signatures An event's content hash covers the unredacted contents, and it's reference hash covers the redacted event contents (including the content hash). The hashes alone are not authenticated and require an additional verification mechanism. Signatures provide the needed authentication mechanism, and are applied by the event's origin server. Signatures are computed by first redacting the event, then removing the signature, authEventIds, and prevEventId fields if present. The resulting object is then serialized and signed using the server's key.

• TODO: Use mTLS keys? Source drafts use Ed25519 keys, but then we need to distribute keys all over the place.

Like content hashes (), authEventIds and prevEventId are removed from the event because they are populated by the hub server.

Creation Rooms (and therefore MLS groups) are first created within the provider, out of scope from MIMI. When the room is exposed to another server over the MIMI protocol, such as with an explicit invite to another user, the creating server MUST produce the following details:

• An m.room.create () state event describing the encryption and policy details for the room.
• A universally unique room ID (represented by the create event).
• An m.room.user () state event which points to the create event as a parent for the create event's sender.
• An MLS group with a group ID matching the room ID, and contains a device belonging to the create event's sender.

This is the minimum state required by a MIMI room. Room creators MAY wish to include additional details in the initial state, such as configuration of the room's policy, adding the creator's other clients to the MLS group state, etc.

m.room.create Event type: m.room.create State key: Zero byte length string. Additional event fields:

• TODO: Include fields for policy information (previously called a "policy ID" in ralston-mimi-signaling). Protect this new field from redaction.

• TODO: Include fields for encryption information. Possibly ciphersuite and similar so a server can check to ensure it supports the MLS dialect? Protect this new field from redaction.

Additional authentication rules:

• The event's prevEventId MUST be a zero byte length string.
• The event's authEventIds MUST be empty.
• The event MUST be the first event in the room.

Hub Server Selection The hub server for a room is the origin server of the m.room.create () event.

• TODO: More sophisticated selection, and possibly transfer of responsibility.

ReInitialization

• TODO: This topic requires further discussion around policy and lifecycle. See also: Section 3.11 and Section 10.15 of .

m.room.redaction Event type: m.room.redaction State key: Not present. Additional event fields: Additional authentication rules:

• The redactedEventId MUST be an event in the room.
• The affected redactedEventId is redacted () by the server upon receipt.

Redaction events are sent to the hub server for fanout with .

User Participation and Client Membership In a MIMI room, users are participants with an associated participation state whereas clients of those users are members of the MLS group. In most scenarios, the user's participation state is updated first or simultaneously with the MLS group membership to enforce membership more easily. Users will always exist in one of the following participation states: These states allow a user to remain logically "joined" to the conversation when they have zero MLS-capable clients available. The user will not be able to see messages sent while they had no clients, but can perform an external join at any time to get back into the MLS group. A user with zero clients in the MLS group is considered to be an inactive participant. Users with one or more clients in the MLS group are active participants. All servers with at least one user of theirs in the "joined" participation state are considered to be "in" or "participating" in the room. By default, all events sent to a room are distrubuted by the hub to participating servers. This is discussed further in .

Invites An invite is when a user (or more specifically, a user's client) is attempting to introduce all of another user's clients to the room and MLS group. This is first done by updating the target user's participation state through the hub server for the room. Updating the target user's participation state is done using the following steps, and is visualized in .

1. The inviter's server generates an m.room.user () state event to invite the target user. Typically this begins with a client-initiated request to the server using the provider-specific API.
2. The inviter's server sends () the m.room.user event to the hub server. If the inviter's server is the hub server, it does the steps described in to complete the event.
3. The hub server validates the event to ensure the following:
   • The target user of the invite MUST NOT already be in the banned or joined states.
   • The sender of the invite MUST already be in the joined state.
4. If the event is invalid, it is rejected. Otherwise, it is forwarded by the hub to the target user's server to give it the opportunity to reject the invite early in the process. This is described by .
5. If the target server rejected the event, the event is rejected by the hub as well. Otherwise, the event is fanned out () to all participating servers, plus the target server if not already participating.

At this stage, the user is now invited but their clients are not members of the MLS group. The invite is delivered to the target's clients through relevant provider-specific API where the user can then accept or decline the invite. If the user declines the invite, they are transitioned to the leave state described by . Accepting is done by joining () the room.

Invite happy path | | | | | | | Validate m.room.user event | | |--------------------------+ | | | | | | |<-------------------------+ | | | | | 200 OK to send event request | | |<--------------------------------| | | | | | | Check event request | | |----------------------------->| | | | | | 200 OK | | |<-----------------------------| | | | | Async fanout of event | Async fanout of event | |<--------------------------------|----------------------------->| | | | ]]>

Joins A user can join a room in two ways:

1. Using an external commit to Add themselves to the MLS group.
2. Receiving a Welcome message from a joined member of the MLS group.

In both cases, a join m.room.user () state event is also sent. Typically, a client will use the first option when joining a public room or responding to an invite because the hub server can assist them in the join. Option 2 is generally used as a form of invite, though skipping the explicit m.room.user invite described by . The hub server MUST allow proposals and commits to add a user's own clients if they're in the joined participation state. Similarly, the hub server MUST NOT allow proposals or commits to add clients which are not in the joined participation state. These conditions permit the user to add their own clients after joining without issue, which may involve an external commit.

External Commit Flow The joining user's server first updates the user's participation state (an m.room.user state event, ) and sends that to the hub () for validation. If the joining user's server is the hub server, it does the steps described in to complete the event. The join event is then validated by the hub as follows:

• The target and sending user of the event MUST be the same.
• The target user MUST NOT be banned from the room.

• TODO: Does requiring the sender and state key to be the same prohibit the Welcome flow from working? (I don't believe so because they still need to Add themselves?)

• TODO: Incorporate public and invite-only room conditions from policy.

If the event is valid, it is fanned out () to all participating servers in the room, which now includes the joining server (if not already).

• TODO: It would be helpful if in response to the send request the hub server provided information required to externally join, maybe.

The user's clients are then able to use external commits to join the MLS group. This is accomplished using .

Welcome Flow

• TODO: Is this better phrased as an invite rather than join?

This flow is more similar to an invite (), though provides the receiving user's clients with enough information to join without external commit. The inviting user's client first requests KeyPackages for all of the target user's client through . The inviting client then uses the KeyPackages to create Welcome MLS messages for the target user's clients. The Welcome messages are sent to the hub server alongside an m.room.user () invite event using . If the inviting user's server is the hub server for the room, it completes the event using the steps described by instead. The event is validated according to and fanned out () to all participating servers, plus the target user's server. The target user's server also receives the Welcome messages to deliver to the relevant clients. The user can then join the room by sending an m.room.user join event. The process and applied validation are the same as . The user's clients can then Add themselves to the MLS group using the Welcome messages they received earlier. If the Welcome messages are no longer valid, the clients can use external commits instead.

• TODO: Should we permit the join event to be accompanied by the client's Add commits?

• TODO: Is this Welcome flow correct, specifically the handling of Welcome MLS messages?

Leaves/Kicks Leaving a room can signal a user declining an invite, voluntarily leaving the room, or being kicked (removed) from the room. When the sender and target of an m.room.user () leave event are different, the target user is being kicked. Otherwise the event represents a voluntary leave or declined invite (if the previous participation state was "invited"). Like with other participation/membership operations, a user's leave is initiated by updating their participation state first. This is done by sending () the relevant m.room.user () state event to the hub, which validates it as follows:

• If the target and sender are the same, the user MUST be in the invited, joined, or knocking participation state.
• Otherwise:
  • The target user of the kick MUST be in the joined participation state.
  • The sender for a kick MUST be in the joined participation state.

• TODO: Include special case permissions constraints.

If the event is valid, it is fanned out () to all particpating servers, plus the target user's server. The next commit in the MLS group MUST remove all of the target user's clients. If there are multiple users in the leave participation state, all of their clients MUST be removed in the same commit. Other proposals MAY be committed alongside the removals, however the commit MUST at a minimum remove the affected clients.

• TODO: Describe how hub server generates proposals? Or do we just require some member in the group to do it? See also: Section 3.5 of .

Prior to a voluntary m.room.user leave event, the sender SHOULD send proposals to remove their own clients from the MLS group. Where possible, those clients SHOULD commit their removal prior to updating their participation state as well. Clients can propose to remove themselves from the MLS group at any time. The hub server MUST allow commits at any time to honor those proposals. The hub server MUST NOT allow a commit which contains an inline proposal to remove another client, unless that client belongs to a user in the leave participation state.

Bans Bans imply kick, and are operated the same way as , though with the m.room.user () state event using a ban participation state. An added exception on the validation is also applied to permit preemptive bans: the target user is not required to be in the joined state to allow the participation state change. Unbans can be performed by transitioning a user from the banned participation state to leave with .

Knocks In this state, the sender of a knock is requesting an invite () to the room. They do not have access to the MLS group.

• TODO: Discuss if this participation state is desirable, and figure out details for how it works. It'd likely just be an m.room.user state event with no MLS interaction, like invites are.

m.room.user Event type: m.room.user State key: ID of target user. Additional event fields: Additional authentication rules:

• The event's authEventIds MUST include a reference to the sender's most recent m.room.user event, if one exists, and the room's m.room.create event.
• Rules described by , , , , .

• TODO: Include auth rules for permissions.

• TODO: Somehow link the event to a client identity? (or several clients) See also: Section 3.8 of .

Application Messages Clients engage in messaging through use of a content format () and MLS Application Messages. The resulting PrivateMessage is carried in an m.room.encrypted () event. The client's server sends the event to the hub with . If the client's server is the room's hub server, it completes the events with the steps described by instead. The event is then fanned out () by the hub to all participating servers in the room, including the sender's. How the event goes from client to server, and server to client, is out of scope for this document.

m.room.encrypted Event type: m.room.encrypted State key: Not present. Additional event fields: Additional authentication rules:

• message MUST be an MLS PrivateMessage.

Transport Servers communicate with each other over HTTP . Endpoints have the protocol version embedded into the path for simplified routing between physical servers.

Authentication All endpoints, with the exception of .well-known endpoints use the mutually authenticated mode of TLS . This provides guarantees that each server is speaking to an expected party.

• TODO: More information specific to how TLS should be used, i.e. mandate best practices that make sense in a mutually authenticated scenario that involves two WebPKI based certificates.

Individual events may transit between multiple servers. TLS provides point-to-point security properties while provides event security guarantees when transiting over multiple servers.

Endpoint Discovery A messaging provider that wants to query the endpoint of another messaging provider first has to discover the fully qualified domain name it can use to communicate with that provider. It does so by performing a GET request to https://example.org/.well-known/mimi/domain. example.org could, for example, answer by providing the domain mimi.example.org (assuming that this is where it responds to the REST endpoints defined in ). The expected response format is simply a text/plain body containing the fully qualified domain name.

REST Endpoints The following REST endpoints can be used to communicate with a MIMI server. All operations rely on TLS-encoded structs and therefore requests and responses SHOULD use a Content-Type of application/octet-stream.

Send Event Asks the server to send an event (). Events can take two shapes over this endpoint, depending on whether a follower or hub server is doing the sending. When a follower server is sending an event, it MUST only be attempting to send to the hub server for the room. Follower servers receiving an event from another follower server MUST reject the request with a 400 HTTP status code. The hub server MUST populate the authEventIds and prevEventId fields of the event, validate the resulting event, then reply with a 200 HTTP status code and the resulting event ID (). The resulting event is then fanned out to relevant servers in the room. The hub server MUST validate events according to and any event type-specific validation rules. If the event is malformed in any way, or the room is unknown, the server MUST respond with a 400 HTTP status code. Follower servers SHOULD apply the same validation as hub servers upon receiving a send request to identify potentially malicious hub servers. Follower servers sending an event to the hub server will not include authEventIds or prevEventId because they are populated by the hub server. Hub servers MUST employ locking to ensure each event has exactly one child implied by prevEventId. This locking mechanism MAY cause another request to be rejected because the room state was mutated. For example, if the hub receives a ban event in one request and a message from the to-be-banned user in another, the message may be rejected if the ban is processed first. Hub servers SHOULD process requests in the order they were received. If an event is rejected during processing, the event MUST NOT be fanned out. Servers SHOULD retry this request with exponential backoff (to a limit) if they receive timeout/network errors.

Fanout A hub server fans an event out by using the send endpoint described above on all participating servers in the room. A server is considered "participating" if it has at least one user in the joined participation state, described by . Additional servers MAY have the event sent to them if required by the steps leading up to fanout.

Check Invite Event Used by the hub server to ensure a follower server can (and is willing to) process an incoming invite. The called server MAY use this opportunity to ensure the inviting user has general consent to invite the target user. For example, ensuring the invite does not appear spammy in nature and if the inviter already has a connection with the invitee. If the server does not recognize the event format of the m.room.create () event, or does not understand the policy/encryption configuration contained within, it MUST reject the request. The request MAY be rejected with a 400 HTTP status code. If everything looks OK to the server, it responds with a 200 HTTP status code. The hub server SHOULD consider a network error as a rejection. It is expected that the original sender will attempt to re-send the invite once the server is reachable again.

Retrieve Event

• TODO: What specific APIs does a follower server need to operate? Some options include:
  • GET /v1/event/:eventId
  • GET /v1/room/:roomId/state (current room state events)
  • GET /v1/room/:roomId/state/:eventType/:stateKey
  • GET /v1/event/:eventId/child

Retrieve KeyPackages Asks the server for KeyPackages belonging to a user's clients. Like with , if the requesting user does not have general consent to invite the target user, the request is rejected. To ensure requests do not fail while clients are offline or otherwise unreachable, KeyPackages SHOULD be uploaded by the generating client to their local server for later usage.

• TODO: Mark KeyPackages of last resort somehow.

This request is always sent to the hub server which then proxies the request directly to the relevant follower server. ; } GetKeyPackagesResponse; ]]>

• TODO: Do we need to sign or otherwise guarantee security on the requestingUserId? We do for invite events, so why not here?

External Group Join When a client wishes to perform an external join to the MLS group, it may require assistance from the hub server in order to be successful. This endpoint is used by a follower server on a client's behalf to complete the external join. The hub server is able to provide this service to the requester because it keeps track of the information required to generate a GroupInfo object. The requester is still required to supply a Signature and relevant GroupInfo extensions, which are required to complete the GroupInfo object. ; opaque Signature; } PartialGroupInfo; struct { MLSMessage commit; PartialGroupInfo partial_group_info; } MLSGroupUpdate; ]]> The MLSMessage MUST contain a PublicMessage which contains a commit with sender type NewMemberCommit.

Add, Remove, and Update MLS Group Clients As described by , users which are joined participants are able to add their clients at any time to the MLS group. Clients which do not belong to a joined user MUST be rejected from joining the group. Similarly, clients may elect to leave the MLS group at any time, as per . ; } AddClientsRequest; struct { // MUST NOT change the sending client's credential. MLSGroupUpdate group_update; } RemoveClientsRequest; struct { // MUST contain a PublicMessage which contains a commit with an UpdatePath, // but not other proposals by value. MLSGroupUpdate group_update; } UpdateClientRequest; enum { add, remove, update, } MLSOperation; struct { MLSOperation operation; select (GroupUpdateRequest.operation) { case add: AddClientsRequest request; case remove: RemoveClientsRequest request; case update: UpdateClientRequest request; } } GroupUpdateRequest; ]]> The group update contained within RemoveClientsRequest is additionally subject to the requirements of .

Security Considerations Overall, the user participation state leads any possible MLS group state to ensure malicious clients are not able to easily get access to messages.

• TODO: Other security guarantees? Consensus may be required here.

IANA Considerations IANA has created the following registries:

• MIMI Event Types

MIMI Event Types An event type denotes the nature of a payload contained in an event, in the context of the MIMI protocol. The event type is a string composed of substrings separated by dots. The first substring is "m", followed by the logical container being affected (typically just "room"), then a number of descriptor strings. Example: m.room.create

• TODO: Does IANA need any other information for legal event types?

References Normative References 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 (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. Cisco The More Instant Messaging Interoperability (MIMI) working group is defining a suite of protocols that allow messaging providers to interoperate with one another. This document lays out an overall architecture enumerating the MIMI protocols and how they work together to enable an overall messaging experience. This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Federal Information Processing Standard, FIPS Informative References This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Phoenix R&D Phoenix R&D This document describes the MIMI Delivery Service. Wire This document describes content semantics common in Instant Messaging (IM) systems and describes a profile suitable for instant messaging interoperability of messages end-to-end encrypted inside the MLS (Message Layer Security) Protocol. Phoenix R&D Phoenix R&D This document defines an HTTPS based transport layer for use with the MIMI Protocol. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the More Instant Messaging Interoperability Working Group mailing list (mimi@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/mimi/. Source for this draft and an issue tracker can be found at https://github.com/kkohbrok/mimi-transport. The Matrix.org Foundation C.I.C. The Matrix.org Foundation C.I.C. The MIMI signaling protocol describes a framework for user-level interactions in the overall MIMI protocol stack. The event structure can be used by control protocols described by [I-D.barnes-mimi-arch]. The Matrix.org Foundation C.I.C. The Matrix.org Foundation C.I.C. The MIMI Policy Envelope describes a _policy control protocol_ and _participation control protocol_ for use in a room, applied at the user participation level, as described by [I-D.barnes-mimi-arch].

Acknowledgments This document is the consolidation of the following documents:

• forms the majority of .
• describes details for , subsections of (per transport draft), , and considerations for .
• describes , , , details of , and subsections of .

Aspects of are additionally taken into consideration in this document through subsections of , but is largely unincorporated and may require updates to match this document's specifics. was additionally used throughout the writing of this document.