Proposal for read receipts content type

[daria-github]

Background

This proposal is for a read receipt content type, where apps built on top of XMTP can enhance their user experience by allowing senders to know when their messages have been read without requiring a manual response. In scenarios where a recipient may not frequently be checking their messages, read receipts can serve as a particularly valuable insight for the sender.

Overview

This proposal offers a method to integrate read receipts without duplicating messages in a conversation, which is the primary distinction from a prior XIP proposal.

The read receipt is essentially another message with its specific content type:

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

Implementation

Sending a Read Receipt

When a user opens a conversation and the last received message hasn't yet been acknowledged with a read receipt, one can be dispatched:

await conversation.send({}, {
  contentType: ContentTypeReadReceipt,
})

Receiving a read receipt

Applications can both send and recognize a read receipt:

// Assume `loadLastMessage` is a thing you have
const message: DecodedMessage = await loadLastMessage();

if (message.contentType.sameAs(ContentTypeReadReceipt)) {
  // We have a read receipt
  return;
}

contentFallback

To prevent frequent error notifications on clients, the fallback for read receipts is set to undefined. This configuration is made in the codec, eliminating the need for individual app adjustments.

Playground Implementation

A prototype is available in our official content type [here](https://github.com/xmtp/xmtp-js-content-types/tree/main/packages/content-type-read-receipt). The complete payload and an example application are showcased in our official React Playground, accessible [here](https://xmtp.github.io/xmtp-react-playground/). View the implementation details in this [PR.](xmtp/xmtp-react-playground#10)

Consistent with our DB-first strategy, read receipts this playground implementation are stored in IndexedDB, and are kept separate from messages. In our implementation, we only store the most recent read receipt to minimize the number of read receipts sent (e.g. we only display this on the last message, not on a per-message basis) — but this is a client decision. Our version also just renders "Read" for simplicity instead of "Read 8:25am”. However, the timestamp is available for clients that choose to present it.

Client Considerations

Clients must decide:

• Frequency of sending read receipts: after every message or only the latest in a conversation.
• Display preference: showing the timestamp or just "Read", along with its visual presentation.
• Providing a toggle for users to opt out of sending read receipts, though it's recommended.

Next Steps

After refining and finalizing this proposal, we can begin communicating this content type for messaging apps built on top of XMTP as ready for implementation.

[dmccartney]

Suggestion: cut timestamp from the encoded content and instead use the existing timestamp on the envelope.
This makes for less book-keeping, tinier payload, and it avoids introducing yet-another timestamp format (aside: for consistency we should everywhere encode timestamps as millis or nanos since epoch).

[nplasterer]

I updated the above proposal to reflect the new changes that remove the timestamp from the parameters in favor of the existing timestamp on the envelope.