By daria-github (Maintainer) on Aug 10, 2023
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.
↑ 3 ❤️ 5