| Internet-Draft | MIMI Hub-Retracted Messages | July 2026 |
| Mahy | Expires 3 January 2027 | [Page] |
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.¶
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.¶
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 3 January 2027.¶
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.¶
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.¶
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.¶
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.¶
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).¶
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;
¶
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 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;
¶
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).¶
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].¶