MIMI Signaling Protocol

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 26 March 2024.¶

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The More Instant Messaging Interoperability (MIMI) working group is responsible for specifying a protocol to achieve interoperability among modern messaging providers. Most providers do not currently support Messaging Layer Security (MLS) [RFC9420], a chartered requirement of MIMI, but do support other forms of encryption alongside their existing signaling.¶

Within the MIMI stack of protocols, signaling is responsible for coordinating user-level actions and participation. This document describes such a protocol, encompassing a framework for control protocols to operate on top of.¶

An overview of the architecture is described by [I-D.barnes-mimi-arch]. Specific implementations of policy, participation, and security control protocols are not described by this document.¶

MIMI has a chartered requirement to use MLS in the encryption/security protocol, however most existing messaging providers do not currently use MLS in their encryption. This document describes an approach for enabling a given encryption/security protocol without concerning itself with the specifics of such a protocol. This allows existing messaging providers to insert their own encryption/security protocols external to the MIMI working group.¶

As described by [I-D.barnes-mimi-arch], events are sent in rooms to accomplish state changes and messaging. This document defines how events are copied between servers, and where control protocols become involved.¶

This document describes an extensible approach to room policy, similar to how different encryption/security layers can be used within a room. The policy cannot change once set, though it can be configured using state events.¶

A create state event is used to set the policy and encryption/security protocol. This create event is the very first event in the room - all other events are linearly placed after it.¶

Abstract concepts are used for transport and persistence of rooms/events. For example, events can be persisted within an MLS group or serialized in a different format than described in this document.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Terms from [I-D.barnes-mimi-arch] and [I-D.ralston-mimi-terminology] are used throughout this document. [I-D.barnes-mimi-arch] takes precedence where there's conflict.¶

Other terms include:¶

Unpadded Base64: Serialization as described by Section 4 of [RFC4648] with padding (= characters) removed.¶

URL-Safe Base64: As described by Section 5 of [RFC4648]. May also be unpadded, as above.¶

Redaction: An algorithm to remove fields irrelevant to the overall protocol's operation. This should not be confused with message deletion/removal, where a user wishes to delete content they previously sent in the room. Redaction is reserved for protocol operation exclusively. See Section 4.3.¶

Content Hash: A SHA256 [RFC6234] hash covering the unredacted event. See Section 4.2.¶

Reference Hash: A SHA256 [RFC6234] hash covering the essential fields of an event, including the content hash. See Section 4.1.¶

3. Room Structure

Rooms consist of an identifier and linear linked-list of events. The first event MUST be a create event (Section 6.1) to establish the policy and encryption/security protocol the room uses. The second event MUST be the user participation event (Section 6.2) for the creator. All other events follow, and are sequenced into the linked-list by the hub server.¶

The linked-list represents the set of accepted events in the room. Rejected or illegal events are excluded. The hub server MUST enforce the room's policy upon the room. Follower servers SHOULD additionally enforce the policy, preventing the hub from accepting illegal events.¶

Events point to their parent event, as sequenced by the hub, and the policy-configuring state events which prove the event is allowed in the room (the event's "auth events"). The create event MUST be included in the auth events, unless the event is the create event itself. Other examples of auth events include the sender's participation event and current permissions event.¶

This structure allows a server to discard events it no longer needs, but can easily be found later. For example, a follower server might only persist the create event and a dozen most recent events. If the server then has a need to "backfill" then it can simply use the prevEvent pointer off the oldest (non-create) event it has until eventually hitting the intended mark or create event.¶

A hub server, however, MUST persist the auth events chain for the room. This is to guarantee the room is portable in the event of a hub transfer.¶

OPEN QUESTION: Hub transfers as a whole are not concretely specified.¶

TODO(TR): Hash chaining discussion outcomes (GH issue)¶

In diagram form, a room looks as such:¶

The m.room.encrypted event (not specified in this document) has the m.room.user event as its only previous event, but points at both the m.room.user and m.room.create events as auth events. In practice, a room would likely have more m.room.user events to represent other users in the room, rather than this example user conversing with themselves.¶

TODO(TR): Should we replace room IDs with the create event's ID? (GH issue)¶

4. Events

The concept of events is described by Section 5.1 of [I-D.barnes-mimi-arch]. An event is authenticated against its TLS presentation language format (Section 3 of [RFC8446]):¶

// Consists of a server's signatures using their signing key. The transport
// specification defines which specific signing key algorithm is used. This
// document describes *what* a signature covers.
opaque Signatures;
struct {
  // where the event is sent to
  opaque roomId;

  // the type of event. Defines format for content
  // See "Event Types" IANA registry.
  opaque type;

  // if present, the event is a state event
  opaque [[stateKey]];

  // who or what sent this event
  opaque sender;

  // binary type-specific event content (TODO(TR): type??)
  opaque content;

  // the event IDs of the auth events
  opaque authEvents[];

  // the parent event ID
  opaque prevEvent;

  // the origin server's content hash of the event
  uint8 originContentHash[32];

  Signatures hubSignature;
  Signatures originSignature;
} Event;

TODO(TR): Should we bring over origin_server_ts? (GH issue)¶

TODO(TR): Maximum lengths? (or is this a transport/not-us problem?) (GH issue)¶

Note that 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 (Section 4.1) of the event.¶

The "origin server" of an event is the server denoted/implied by the sender.¶

TODO(TR): Do we need to describe how events are extensible? ie: being able to add things to the m.room.create event content. (GH issue)¶

5. Room Metadata

Information about the room such as its name, topic (description), avatar, etc is described by state events. State events are also used for policy control configuration, as specified elsewhere in this document.¶

This document describes the following event types for room metadata purposes.¶

struct {
  // human-readable name for the room. May be empty or missing to denote
  // no name.
  opaque name;
} MRoomNameEventContent;

struct {
  // human-usable image to differentiate the room visually.
  // TODO(TR): Do we know how images are being sent in MIMI?
  opaque mediaUri;
} MRoomAvatarEventContent;

struct {
  // human-readable description for the room.
  opaque topic;
} MRoomTopicEventContent;

6. Protocol Events

struct {
  // The policy envelope the room is using.
  // See the "Policy IDs" IANA registry.
  opaque policyId;

  // The encryption/security algorithm name in use for the room.
  // TODO(TR): Does this also need an IANA registry? Currently we expect
  // this to be `m.mls` or something, maybe with ciphersuite encoded or
  // defined adjacent?
  opaque encryptionAlgorithm;
} MRoomCreateEventContent;

opaque ParticipationState; // see policy envelope document
struct {
  // The participation state the user is in. Legal values are described by
  // the policy envelope for the room.
  ParticipationState participation;
} MRoomUserEventContent;

7. Transport

TODO(TR): Link to I-D.kohbrok-mimi-transport describes a series of REST endpoints for communicating between servers. The following transaction types are defined with respect to signaling.¶

8. IANA Considerations

IANA creates the following registries:¶

• Event Types¶
• Policy IDs¶

Authors' Addresses