Internet-Draft MIMI Terminology October 2023
Ralston Expires 25 April 2024 [Page]
Workgroup:
More Instant Messaging Interoperability
Internet-Draft:
draft-ralston-mimi-terminology-latest
Published:
Intended Status:
Informational
Expires:
Author:
T. Ralston
The Matrix.org Foundation C.I.C.

MIMI Terminology

Abstract

This document introduces a set of terminology to use when discussing or describing concepts within MIMI.

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://turt2live.github.io/ietf-mimi-terminology/draft-ralston-mimi-terminology.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ralston-mimi-terminology/.

Discussion of this document takes place on the More Instant Messaging Interoperability Working Group mailing list (mailto:mimi@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/mimi/. Subscribe at https://www.ietf.org/mailman/listinfo/mimi/.

Source for this draft and an issue tracker can be found at https://github.com/turt2live/ietf-mimi-terminology.

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 25 April 2024.

Table of Contents

1. Introduction

The More Instant Messaging Interoperability (MIMI) working group is chartered to specify the minimal set of mechanisms to make modern instant messaging applications interoperable. Through prior discussions and upcoming documents, it's become important to have a shared understanding for what is being discussed specifically.

This document expands upon MLS's [I-D.ietf-mls-protocol] [I-D.ietf-mls-architecture] terminology by defining terms specific to MIMI's purpose. Document authors SHOULD prefix terms from MLS with "MLS" to denote where the term is specifically coming from. For example, "MLS Group" versus "Group". This document defines terms which are non-conflicting to help ensure clarity when the MLS prefix is missing, however.

Documents within the MIMI working group may introduce their own terminology to explain concepts within their context. Those documents SHOULD NOT override or change the terminology described in this document or from MLS.

2. Terminology

TODO(TR): How much of this is replaced by [I-D.barnes-mimi-arch]?

MIMI defines:

Messaging Provider or Provider: A service offering instant messaging to users. Each provider has a server to route events between users (or clients, specifically).

User: A (normally) human operator of a client. Users have a User ID to identify them canonically within the system.

User Identity: A mapping of User ID to external identifier, such as a phone number. In some cases, the user identity can be synonymous with the user ID, however the default assumption if not clarified is that they are different concepts.

Client: A user interface for messaging, performing encryption as needed. Presents rooms to the user to interact with. Synonymous with MLS Client. Clients have a Client ID to canonically identify them among a user's other clients. Clients can additionally be called Devices to differentiate them from a named application.

Room: The place where users communicate. This is semantically distinct from an MLS Group: an MLS Group is responsible for handling client keys while a room is simply the user-facing construct for communication, however systems can declare a Room to be the same as an MLS Group depending on their design. Rooms have a Room ID to canonically identify them within the system. Rooms can additionally be called Chats, Conversations, and Channels.

A room can have any one of many different characterizations/behaviours, called Room Types:

Depending on the system, a room's type can be mutable. For example, a user may be permitted to introduce new users to a group DM to implicitly convert it to a group room, or they simply may be unable to implicitly or explicity change the room type.

Room Name: The title or human-focused textually distinguishing factor for the room. It may be automatically generated based on the room participants.

Room Avatar: A picture or graphic associated with the room, usually in combination with a room name. Room avatars can be automatically generated based on the room participants.

Room Participant: A joined user in the room. Note that this may have implications on the associated MLS Members in the MLS Group for the user's devices.

Event: The container for an encrypted MLS Message, sent over the wire between servers and clients (through their local servers). Events have an Event ID to canonically identify them at least within the room.

Room Property: Information stored in the room, such as the name, topic, avatar, room participants, etc. This may be in the shape of an event. Note that room properties are different from what is needed to construct an MLS Group Context.

Message: Synonymous with an MLS Message. Messages have a Message ID to canonically identify them at least within the group. These are essentially what a user would call a "message", though specifically the unencrypted portion. When encrypted, they are called events.

Server: Responsible for routing events to other servers and local clients. The collection of servers and clients in a room form the MLS Delivery Service (DS).

Hub Server: The specific server responsible for routing events to other servers in the context of a room. Sometimes this is shortened to Hub.

Owning Server: If applicable, the server specifically responsible for applying access control to a room. Typically, this will also be the hub server for the room. This should not be shortened to "owner" to avoid confusion with other related concepts.

Client-Server API: The interface between a client and server. This may be nothing more than a function call if the client and server are the same logical entity.

Server-Server API: The interface between a server and another server.

Transport: The method and format for moving information between entities. For example, a Client-Server API might describe HTTPS and JSON as its transport. For added clarity, documents should clarify which API surface they are defining a transport for ("Server-Server Transport", for example). MIMI is not chartered to define the Client-Server Transport.

Message Format: The specific format that clients use within the encrypted body of an MLS Message. Sometimes this will also be called the Content Format.

Access Control: The set of algorithms which determine whether an event or MLS Message is permitted in the room/group. For instance, this may define whether an MLS Proposal is accepted or whether the user is able to become a room participant.

Admin Permissions: Typically at least the user who created the room, these permissions grant the associated users an ability to change the permissions of other users in the room. The set of users with these permissions in a room are called Admins. Admin permissions typically inherit moderator permissions.

Moderator Permissions: These permissions grant the associated users an ability to kick, ban, or otherwise restrict another user's ability to use the room. For example, deleting a spammer's events. The set of users with these permissions in a room are called Moderators.

Note that with both moderator permissions and admin permissions a system may have finer granularity, such as a set of users being able to kick but not ban. Documents with these semantics should clarify this case.

Invite: An action taken by a user in a room to encourage another user to become a room participant (or joined to the room). This can be explicit through the server-server API, or implicit with an join link/join code.

Join Link: A machine-readable mechanism for a user to join the room, represented as a URL or QR code.

Join Code or Join Password: A text-based string a user may enter to join a room. The string may be shared with the user verbatim or encoded with a QR code, for example.

Direct Invite: An invite to a DM or Group DM. These invites might appear in a different section of the client's UI to denote their semantic difference from a non-DM invite.

Kick: An action taken by a user to remove another user from a room, assuming the sender has moderator permissions. The affected user can re-join the room with either another invite or by simply joining, depending on the room type.

Ban: Similar to kicking, a user is kicked from the room and not allowed to re-join until unbanned by a moderator. If a user is banned, they are typically not able to knock to get back into the room either.

Knock: A request from a user (who is not currently a room participant) to join the room. Upon acceptance, the requesting user may receive an invite or be directly joined to the room. Upon rejection, the requesting user can be banned or otherwise declined.

Status: Temporarily displayed text or images associated with a user's profile. Instagram Stories are an example of a user's status.

2.1. Diagram Reference

In the simplest possible form, interoperable messaging between two end users looks as such:

A B C Client 1 Provider 1 Provider 2 Client 2 D
Figure 1: Typical, simplified, architecture for interoperability

In this figure, Client 1 is directly connected to Provider 1 over A. A is a provider-specific Client-Server API and transport. Similarly, Client 2 is directly connected to Provider 2 over C. C is also a provider-specific Client-Server API and transport.

Provider 1 and 2 talk to each other with a Server-Server API over a transport. This is B in the figure.

Clients additionally have an implicit method of communication (D in the figure) where they use a shared Message Format. There is no transport for D in this figure: the figure is denoting that servers/providers are unable to assist with a format conversion due to the event's content (an MLS message) being encrypted.

3. IANA Considerations

This document has no IANA actions.

4. References

4.1. Normative References

[I-D.ietf-mls-architecture]
Beurdouche, B., Rescorla, E., Omara, E., Inguva, S., and A. Duric, "The Messaging Layer Security (MLS) Architecture", Work in Progress, Internet-Draft, draft-ietf-mls-architecture-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-mls-architecture-11>.
[I-D.ietf-mls-protocol]
Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", Work in Progress, Internet-Draft, draft-ietf-mls-protocol-20, , <https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol-20>.

4.2. Informative References

[I-D.barnes-mimi-arch]
Barnes, R., "An Architecture for More Instant Messaging Interoperability (MIMI)", Work in Progress, Internet-Draft, draft-barnes-mimi-arch-01, , <https://datatracker.ietf.org/doc/html/draft-barnes-mimi-arch-01>.

Author's Address

Travis Ralston
The Matrix.org Foundation C.I.C.