More Instance Messaging Interoperability (MIMI): Retracting MIMI Content Messages by the Hub Provider
draft-mahy-mimi-hub-retracted-messages-00

More Instant Messaging Interoperability                          R. Mahy
Internet-Draft                                               2 July 2026
Intended status: Informational                                          
Expires: 3 January 2027

More Instance Messaging Interoperability (MIMI): Retracting MIMI Content
                      Messages by the Hub Provider
               draft-mahy-mimi-hub-retracted-messages-00

Abstract

   The More Instant Messaging Interoperability (MIMI) Protocol defines a
   way to signal potentially abusive messages to a provider, but
   provides no way for the provider to signal that an abusive message
   sent in a room should be retracted.  This document defines mechanisms
   for providers to signal this to in-room participants.

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://rohanmahy.github.io/mimi-hub-deleted-messages/draft-mahy-
   mimi-hub-retracted-messages.html.  Status information for this
   document may be found at https://datatracker.ietf.org/doc/draft-mahy-
   mimi-hub-retracted-messages/.

   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/rohanmahy/mimi-hub-deleted-messages.

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/.

Mahy                     Expires 3 January 2027                 [Page 1]
Internet-Draft         MIMI Hub-Retracted Messages             July 2026

   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 3 January 2027.

Copyright Notice

   Copyright (c) 2026 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.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Removing specific messages by message ID  . . . . . . . .   4
     3.2.  Removing ranges of messages sent by a specific
           participant . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  hub_retracted_messages app component  . . . . . . . . . .   6
     5.2.  hub_retracted_range app component . . . . . . . . . . . .   6
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The MIMI Protocol [I-D.ietf-mimi-protocol] includes a mechanism to
   report allegedly abusive messages (defined in Section 5.9 of
   [I-D.ietf-mimi-protocol]).  The plaintext of allegedly abusive
   messages is forwarded to the reporting service of the Hub provider
   for human and/or automated analysis.  This mechanism takes advantage
   of the franking mechanism (defined in Section 3.4.1 of
   [I-D.ietf-mimi-protocol]) to verify that any allegedly abusive
   messages were actually sent by the indicated party.

Mahy                     Expires 3 January 2027                 [Page 2]
Internet-Draft         MIMI Hub-Retracted Messages             July 2026

   If a reported message is found to be abusive, the reporting service
   could potentially take advantage of several remedies.  For example,
   the provider could ban or remove the sender from a specific room or
   rooms by sending external proposals.  The provider could send an out-
   of-band message (ex: an email, or an instant message in a dedicated
   room that purpose) to the administrators or moderators of the room in
   which the abuse was sent, and expect them to react in an appropriate
   manner.  In some cases, the abusive content may be illegal and/or
   sufficiently disturbing or disruptive (ex: hate speech, severe
   harassment, non-consensual sexual material, or sexual material
   involving children), that the content needs to be automatically
   retracted and removed from view by the participants in the room.  In
   many such cases, the provider even has a legal duty to act.

   A hub provider may also discover that a specific participant has
   violated its terms of service generally, in a manner that causes
   their content to be a danger to other participants.  For example, an
   account which is fraudulently impersonating another user can be
   removed using an external remove proposal, but removing their content
   messages requires another mechanism.

   This specification describes two new application components to signal
   messages to be retracted.

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.

3.  Mechanism

   After an AbuseReport is sent (see Section 5.9 of
   [I-D.ietf-mimi-protocol]), the hub provider determines if allegedly
   abusive messages are abusive or not according to the plaintext
   contents of the message, possibly the context, and the room policy
   (which is within the hub's policy envelope).

   If the abusive message(s) were MIMI content [I-D.ietf-mimi-content],
   the hub can inform clients in the room to mark the abusive or other
   unauthorized messages as retracted.  The hub could also retract
   messages for other reasons, such as upon discovering that messages
   were sent while an account was compromised, or that the sender of the
   messages opened an account under false pretenses (ex: impersonating
   the identity of another).

Mahy                     Expires 3 January 2027                 [Page 3]
Internet-Draft         MIMI Hub-Retracted Messages             July 2026

3.1.  Removing specific messages by message ID

   The hub signals that individual, specific messages should be
   retracted by sending one or more AppEphemeral proposals, each
   containing a hub_retracted_messages component with a list of MIMI
   Content message IDs to retract/delete.  Each proposal contains
   messages with the same retracted timestamp and (optional) reason
   code.  More than one AppEphemeral proposal with the
   hub_retracted_messages component type can be present in the same
   Commit (for example to delete different messages with different
   reason_codes).

   Members of the MLS group receiving this proposal, verify that the
   proposal signature is valid, and the proposal sender corresponds to a
   user in the participant list with a role containing the
   canDeleteOtherMessage for any type of message, or the
   canDeleteOtherReaction if the messages within
   hub_retracted_messages.retracted_messages are all reactions.

   uint8[32] MessageId;

   struct {
       uint64 hub_retracted_timestamp;
       IdentityUri remover_uri;
       optional<AbuseType> reason_code;
       MessageId retracted_messages<V>;
   } HubRetractedMessagesComponent;

   HubRetractedMessagesComponent hub_retracted_messages;

3.2.  Removing ranges of messages sent by a specific participant

   In the case where the provider discovers a client trying to commit
   fraud or deception, the provider may wish to take immediate action
   without waiting for every message sent to be reported.  For example,
   a user who is impersonating a government economy or health
   spokesperson, or a recruiter at a well-known firm could send messages
   causing panic or phishing, but ordinary viewers may have no reason to
   report the messages, believing them to be from a legitimate source.

   Instead it is useful to label all messages from the fraudulent source
   as suspect and retract them, possibly starting at a specific time
   (for example, if an account was compromised).

   The hub signals that a range of messages sent by a particular sender
   should be retracted by sending an AppEphemeral proposal with a
   hub_retracted_range component.  Each of these components contains a
   reason_code, an abusive_sender_uri, and optionally a

Mahy                     Expires 3 January 2027                 [Page 4]
Internet-Draft         MIMI Hub-Retracted Messages             July 2026

   starting_timestamp indicating when the sender began to be
   untrustworthy.  More than one AppEphemeral proposal with the
   hub_retracted_range component type can be present in the same Commit.
   A single Commit MUST NOT contain AppEphemeral proposals with
   hub_retracted_range components for the same abusive_sender_uri.

   Members of the MLS group receiving this proposal, verify that the
   proposal signature is valid, and the proposal sender corresponds to a
   user in the participant list with a role containing the
   canDeleteOtherMessage capability.  Then they retract all messages
   (including reactions, edits, deletes, and replies) sent by the
   abusive_sender_uri, starting from and including the
   starting_timestamp if present, or since the receiver's earliest
   messages in the room if starting_timestamp is absent.

   struct {
       uint64 hub_retracted_timestamp;
       IdentityUri remover_uri;
       optional<AbuseType> reason_code;
       IdentityUri abusive_sender_uri;
       optional<uint64> starting_timestamp;
   } HubRetractedRangeComponent;

   HubRetractedRangeComponent hub_retracted_range;

4.  Security Considerations

   The security of this system depends on including only systems
   authorized to send external proposals in the external_senders MLS
   extension in the GroupContext; and correctly setting the roles and
   capabilities in [I-D.ietf-mimi-room-policy] for the entity and role
   that sends external proposals with the components described in this
   specification.

   In the case of hub_retracted_messages, the security of retraction
   also relies on the security of the franking system in MIMI protocol.
   It also assumes that the hub provider can come up with the correct
   message ID (which is straightforward when it has the plaintext
   content of a message in the MIMI content format).

5.  IANA Considerations

   RFC EDITOR: Please replace XXXX throughout with the RFC number
   assigned to this document.

   This document registers the following two MLS application components
   per Section 7.6 of [I-D.ietf-mls-extensions].

Mahy                     Expires 3 January 2027                 [Page 5]
Internet-Draft         MIMI Hub-Retracted Messages             July 2026

5.1.  hub_retracted_messages app component

   *  Value: TBD1 (suggested value 0x0050)

   *  Name: hub_retracted_messages

   *  Where: AE

   *  Recommended: Y

   *  Reference: RFCXXXX

5.2.  hub_retracted_range app component

   *  Value: TBD2 (suggested value 0x0051)

   *  Name: hub_retracted_range

   *  Where: AE

   *  Recommended: Y

   *  Reference: RFCXXXX

6.  Normative References

   [I-D.ietf-mimi-content]
              Mahy, R., "More Instant Messaging Interoperability (MIMI)
              message content", Work in Progress, Internet-Draft, draft-
              ietf-mimi-content-08, 2 March 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mimi-
              content-08>.

   [I-D.ietf-mimi-protocol]
              Barnes, R., Hodgson, M., Kohbrok, K., Mahy, R., Ralston,
              T., and R. Robert, "More Instant Messaging
              Interoperability (MIMI) using HTTPS and MLS", Work in
              Progress, Internet-Draft, draft-ietf-mimi-protocol-06, 25
              April 2026, <https://datatracker.ietf.org/doc/html/draft-
              ietf-mimi-protocol-06>.

   [I-D.ietf-mimi-room-policy]
              Mahy, R., "Room Policy for the More Instant Messaging
              Interoperability (MIMI) Protocol", Work in Progress,
              Internet-Draft, draft-ietf-mimi-room-policy-03, 18
              December 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-mimi-room-policy-03>.

Mahy                     Expires 3 January 2027                 [Page 6]
Internet-Draft         MIMI Hub-Retracted Messages             July 2026

   [I-D.ietf-mls-extensions]
              Robert, R., "The Messaging Layer Security (MLS)
              Extensions", Work in Progress, Internet-Draft, draft-ietf-
              mls-extensions-09, 2 March 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mls-
              extensions-09>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Author's Address

   Rohan Mahy
   Email: rohan.ietf@gmail.com

Mahy                     Expires 3 January 2027                 [Page 7]