Proposal for "Delete Message" functionality

XMTP Development Ideas & Improvements
1

By Babak-gh on Dec 15, 2023

Introduction

I propose the addition of a dedicated XMTP Improvement Proposal (XIP) for implementing a "Delete Message" functionality in XMTP. This proposal will cover development challenges, different types of "delete message" implementations, and a brief exploration of current web2 delete functionalities in messaging applications.

"Delete Message" Implementation Challenges in XMTP

  1. "Seen Message" Functionality: Prior to a user deleting a message, it is crucial to confirm that the recipient has not viewed it. Since XMTP does not include a native "seen message" feature, implementing this could be challenging. Notably, both Telegram and WhatsApp permit users to delete messages even after they have been viewed by the other party.

  2. XMTP Interoperable Inbox: XMTP's interoperable inbox may lead to a deleted message appearing in another inbox that hasn't implemented the "delete message" functionality. This issue arises particularly in soft delete implementations; hard delete, however, doesn't face this challenge as messages are deleted at the server (node) level.

Different "Delete Message" implementations in concept

Soft Delete

Soft delete doesn't involve removing messages from servers; instead, it provides a mechanism to hide soft-deleted messages in clients.
My proposal is about implementing it with a "content type". Obviously, every client developer can implement "delete message" with a "custom content type". Also, creating a "standards-track" content type is an advantageous approach as it formalizes the content type within the protocol, making it a recognized and standardized element. See a simple implementation in the XMTP Android example app.

Hard Delete

Messages are permanently deleted from the node. Hard delete cannot be implemented with a content type, as payloads are not observable by nodes. Questions arise about user privacy, implementation at the envelope level, and challenges from a database and big data perspective.
Here are a few challenges associated with "hard delete":

  1. Does it violate user privacy, as provided by XMTP?
  2. It cannot be implemented at the message level. Does it make sense at the envelope level?
  3. Is it feasible from a database and big data perspective? Old messages may not be indexed in nodes. In most web2 messaging applications, there was a time limit for deleting a message, if I'm not mistaken, due to this issue.

Current delete functionalities in web2 messaging applications

I will explore WhatsApp and Telegram to showcase how they have implemented the delete message feature in their end-to-end encrypted messaging.

  • WhatsApp : WhatsApp allows users to delete sent messages for both themselves and the recipient. The deleted message is replaced with "This message was deleted" in the chat. However, WhatsApp follows a policy of not allowing messages to be deleted after a certain time period.

  • Telegram : Telegram's "Delete for All" feature lets users delete messages not only for themselves but also for everyone in the chat. The deleted message is replaced with a note saying "This message was deleted" (in secret chat there is no replaced text). Telegram does not impose a time limit for deleting messages, offering more flexibility compared to some other messaging platforms.

Proposed content type for soft delete functionality in XMTP:

{
  authorityId: "xmtp.org"
  typeId: "delete"
  versionMajor: 0
  versionMinor: 1
}

The encoded content MUST have the following parameters:

{
  // The message ID for the message being deleted
  referencing_message_id: string,
}

The referencing_message_id is used for the message ID. I assume that previous discussions about a more specific content_type for referring to another message are pending, so I adopted the logic discussed here. Check out a simple implementation with a custom content type in this commit developed for the XMTP Android example app.

Feedback

I invite the community's feedback on the "soft delete" content type and am curious about the technical feasibility of implementing "hard delete."
Feel free to share your thoughts and suggestions on this proposal. Thank you!

↑ 4
2

Comments

Comment by nplasterer on Dec 21, 2023

Thanks so much for this incredibly detailed and thoughtful proposal @Babak-gh as well as Android implementation. We briefly discussed this proposal today as a team and had a few things to add.

As per the android implementation I would actually suggest that the fallback should be null or undefined. For clients that do not support message deletion there should be no action seen on the receivers end.
Instead of calling this a soft delete I would actually call it a removal. As it is possible to still read these messages on the network it more just removing them from the current view and not guaranteed to be removed for the receiver as the app they are using could not support this content type.
This also posses issues when the message list becomes large and crosses pagination bounds for a deletion. Making it very important that consumers of this content type like reactions use a local database to thread the messages and display them correctly.

This brought up a few other points. Should content types have some mutable fields like a isRemoved that can be updated? Should non readable messages like this be sent to a different topic?

As for hard deletion because a user would need to expose there identity to be able to delete a message and the privacy concerns around that we do not have plans to implement a hard deletion at this point.

↑ 2   👍 1

Reply by nplasterer

Dec 21, 2023

Also wanted to call out that we recently add an experimental folder to our js content types repo so you can open PRs with experimental content types for others to consume as well.

https://github.com/xmtp/xmtp-js-content-types/tree/main/experimental
👍 1