More Instant Messaging Interoperability T. Ralston Internet-Draft The Matrix.org Foundation C.I.C. Intended status: Informational 9 June 2023 Expires: 11 December 2023 MIMI Terminology draft-ralston-mimi-terminology-01 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 11 December 2023. Ralston Expires 11 December 2023 [Page 1] Internet-Draft MIMI Terminology June 2023 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Diagram Reference . . . . . . . . . . . . . . . . . . . . 6 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. Normative References . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 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 the MLS specification with "MLS" to denote that the term is specifically coming from the MLS specification. 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 MIMI defines: Ralston Expires 11 December 2023 [Page 2] Internet-Draft MIMI Terminology June 2023 *Messaging Provider* or *Provider*: A service offering instant messaging to _users_. Typically a _provider_ will have 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 _chats_ 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. *Chat*: The place where _users_ communicate. This is semantically distinct from an _MLS Group_: an _MLS Group_ is responsible for handling _client_ keys while a _chat_ is simply the user-facing construct for communication, however systems can declare a _chat_ to be the same as an _MLS Group_ depending on their design. _Chats_ have a *Chat ID* to canonically identify them within the system. _Chats_ can additionally be called *Rooms*, *Conversations*, and *Channels*. A _chat_ can have any one of many different characterizations/ behaviours, called *Chat Types*: * *DM*: A _direct message_ _chat_ between exactly two _users_. _DMs_ are typically created when a _user_ searches for another _user_ to message, rather than creating a _group chat_. All _users_ in the _chat_ have the same permission capabilities under the _access control_ semantics. The _chat name_ is that of the opponent _user_ in the _DM_. _DMs_ are typically canonical: exactly one _chat_ with the opponent exists at a time. * *Group DM*: A subtype of _DMs_ where there are more than two _users_. The _chat name_ consists of the opponent _users_ in the _DM_. Inherited from _DMs_, _Group DMs_ are also canonical: creating a new _Group DM_ with the exact same _users_ ultimately redirects to the existing _chat_ instead of creating a new one. These may also be called *Ad-hoc Chats* in some scenarios. * *Group Chat*: A _chat_ which requires an _invite_ to be able to participate, and can have zero or more _users_. A _user_-provided _chat name_ is defined for the _chat_. Typically, the creator has Ralston Expires 11 December 2023 [Page 3] Internet-Draft MIMI Terminology June 2023 _admin permissions_ while other designated _users_ have either _admin permissions_ or _moderator permissions_. Most _users_ have default permissions which allow them to send _events_ to the _chat_. Unlike _(Group) DMs_, multiple _chats_ with the same set of _users_ can exist at the same time, even with the same _chat name_. * *Public Chat*: A _group chat_ which does not require an _invite_ to participate. Usually these types of _chats_ are discovered through a directory or website. _Chats_ which require a request to join, or _knock_, are considered _public chats_. Sometimes these will be referred to as *Public Chatrooms*. * *Auditorium Chat*: Either a _group chat_ or _public chat_ where most _users_ are unable to send _events_ and cannot be seen as _chat members_ by other _users_. When an _event_ is sent, it may appear to be sent by the _chat_ itself rather than the specific _user_ who sent it. Sometimes these are called *Auditorium Rooms*. Depending on the system, a _chat'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 chat_, or they simply may be unable to implicitly or explicity change the _chat type_. *Chat Name*: The title or human-focused textually distinguishing factor for the _chat_. It may be automatically generated based on the _chat members_. *Chat Avatar*: A picture or graphic associated with the _chat_, usually in combination with a _chat name_. _Chat avatars_ can be automatically generated based on the _chat members_. *Chat Member*: A joined _user_ in the _chat_. 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 _chat_. *Chat Property*: Information stored in the _chat_, such as the name, topic, avatar, _chat members_, etc. This may be in the shape of an _event_. Note that _chat properties_ are different from what is needed to construct an _MLS Group Context_. Ralston Expires 11 December 2023 [Page 4] Internet-Draft MIMI Terminology June 2023 *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*: Synonymous with an _MLS Delivery Service (DS)_. Responsible for routing _events_ to other _servers_ and local _clients_. Note that the role of a _server_ can be accomplished in the same logical place as a _client_ (i.e.: in peer-to-peer environments), however the default assumption if not clarified is that the _client_ and _server_ are two different entities. *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). *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 _chat_/_group_. For instance, this may define whether an _MLS Proposal_ is accepted or whether the _user_ is able to become a _chat member_. *Admin Permissions*: Typically at least the _user_ who created the _chat_, these permissions grant the associated _users_ an ability to change the permissions of other _users_ in the _chat_. The set of _users_ with these permissions in a _chat_ are called *Admins*. _Admin permissions_ 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 _chat_. For example, deleting a spammer's _events_. The set of _users_ with these permissions in a _chat_ are called *Moderators*. Ralston Expires 11 December 2023 [Page 5] Internet-Draft MIMI Terminology June 2023 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 _chat_ to encourage another _user_ to become a _chat member_ (or joined to the _chat_). This can be explicit through the _server-server API_, or implicit with an _invite code_. *Invite Code*: An out-of-band _invite_ for a _user_ to join the _chat_, such as a text string shared with the target _user_. The sharing mechanism can additionally be a URL or QR code. *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_ in a _chat_ to remove another _user_, assuming the sender has _moderator permissions_. The affected _user_ can re-join the _chat_ with either another _invite_ or by simply joining, depending on the _chat 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 _chat_ either. *Knock*: A request from a _user_ (who is not currently a _chat member_) to participate in the _chat_. Upon acceptance, the requesting _user_ may receive an _invite_ or be directly joined to the _chat_. 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: Ralston Expires 11 December 2023 [Page 6] Internet-Draft MIMI Terminology June 2023 +----------+ +------------+ +------------+ +----------+ | | 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. 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-10, 16 December 2022, . [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, 27 March 2023, . Ralston Expires 11 December 2023 [Page 7] Internet-Draft MIMI Terminology June 2023 Author's Address Travis Ralston The Matrix.org Foundation C.I.C. Email: travisr@matrix.org Ralston Expires 11 December 2023 [Page 8]