Proposal for Reply content type

[galligan]

After researching what's possible in XMTP today, I wanted to elevate some of the ideas around a reply content type to try and reach a consensus around it, by setting up a basic proposal.

What started as a deeper exploration, and a more extensive set of parameters, ended up boiling back down to essentially what this improvement proposal from @Im-Kunal-13 says. Therefore the goal of this proposal is to elevate that idea, engage deeper in conversation and exploration, as well as provide some additional background that might bolster a draft proposal.

Background

Currently, the XMTP SDK calculates a message's identifier by combining its headerBytes and ciphertext. The protocol/network does not persist the same identifier right now, though that's something worth exploring in the future.

The XMTP developer docs defines this:

Identifier that is deterministically derived from the bytes of the message header and ciphertext, where all those bytes are authenticated. This can be used in determining the uniqueness of messages.

Only identical duplicates of messages with their header content intact would produce the same deterministic identifier. While the network does deduplicate messages, clients may still need to ensure that messages are deduped based on this identifier.

We will use “message ID” or “MID” for the purpose of this proposal. Replies would use referencing_message_id to refer to a specific message.

Message ID as an identifier for replies, reactions, more…

Because message IDs are unique, they can be used as a way to directly reference another message within a conversation. We can use this message reference to build replies, reactions, and other content types that might call back to a specific, separate message.

Specification

Proposed content type:

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

The encoded content MUST have the following parameters:

{
  // The message ID for the message that is being replied to
  referencing_message_id: string,
}

Additional context

referencing_message_id

In the above specification referencing_message_id is used for the message ID. This is a more generic label that could be reused for many different kinds of content types, such as reactions, or a fictional "edited text" type. In the past messagePointer, target, and relatedMessageId have been floated, but I'm just going for something generic here.

Note: It’s worth calling out this PR from @nakajima which seeks to elevate referencing_message_id to the EncodedContent of a message. This change can be treated as independent of this proposal, as including the referencing… within the reply type would work.

Content Fallback

To account for clients that do not yet support replies, the fallback could still do a sufficient job of providing the reply. This could be done in a manner similar to how iMessage degrades replies and reactions when sending over SMS. An example may look like:

const reply = {
  reference: message.id,
  content: "Here's my reply!"
}

await conversation.send(reply, {
  contentType: ContentTypeReply,
  contentFallback: `[Reply] ${client.address} replied to ${message.content} with:\n\n${reply.content}`
})

In the above example we use replied to ${message.content} in the fallback. It may be prudent for the client that’s tasked with sending the reply to truncate the ${message.content} so that receiving clients aren’t displaying an unreasonable amount of content associated with the reply.

As it’s not possible to set a hard requirement here, we would recommend setting an upper limit of 140 characters.

Presentation

The presentation of replies is intentionally left out of this proposal, as those are decisions to be made by client applications. It does seem worth it to call out some reply experiences that we use today that might map well to the above proposal. They are:

• Discord
  • Individual messages can get replied to, where the replies retain a link back to the originally referenced message
• Telegram
• Facebook Messenger

Note that iMessage and Slack are omitted, as they follow more of a “threaded” pattern, where messages are collected into a logical grouping. There may be a separate content type proposal to explore this as a pattern, so for now, we’ll hold off.

Feedback

Would love to get some feedback on this proposal! I for one can’t wait to start using replies in XMTP clients, so I’m hoping this sparks some more conversation to get moving.

Next steps

If the above proposal seems like a reasonable approach to a reply content type, I would recommend updating this specific content type proposal with the changes and push it forward in the process with some reference implementations.

[rygine]

We have implemented this proposal in an official content type located here and published on the NPM registry here.

There's only one deviation from the proposal above and that's the contentType of the reply. In order to process replies of any content type, we need to pass along that information so that client can render the reply correctly. The final payload for the reply content type can be found here.

An example implementation of this content type has been added to our official React Playground, which can be accessed live here. The PR that included this implementation can be found here.

Code sample

import { ContentTypeReply } from "@xmtp/content-type-reply";
import type { Reply } from "@xmtp/content-type-reply";

const reply: Reply = {
  reference: originalMessage.id,
  content: "This is a reply",
  contentType: ContentTypeText,
};

await conversation.send(reply, {
  contentType: ContentTypeReply,
  contentFallback: `${client.address} replied to "${originalMessage.content}" with {reply.content}`
})