is there a way to identify whethere the conversation is read or not

[MallRoy]

is there a way to identify whether the conversation is read or not

[richbustos]

Hi @MallRoy,

We currently don't support read-receipts natively but can be done through customized contentTypes.

To learn more about content types, see Different types of content.

To learn how to use content types when developing a client app, see Use content types.

Feel free to let me know if you have additional questions! Thanks!

[MallRoy]

can you please suggest me how to achieve this through customized contentTypes

[yash-luna]

A contentType for read receipts could be a payload sent by a frontend that contains a timestamp of when a message was read. A frontend would infer that this payload should be rendered as a read receipt rather than a regular tex message based on the contentType

For read receipts to work across different apps, the community would have to adopt a standard. You could propose a standard via an XRC

[MallRoy]

xmtp doesn't provide a way to update the timestamp or payload once it is delivered. On reading the message, the app should trigger another message with a custom content type, and based on that the frontend app should process the read receipts.

This is my understanding. Please correct me if am wrong

[yash-luna]

On point @MallRoy!

You could also use a conversationID scoped to read receipts to make your app more performant. The conversationID would allow you to fetch just the read receipts separately from other messages.

[tg44]

So, based on the current thread, there is a possibility that we will implement this.

Codec example with content types;

import {ContentTypeId, EncodedContent} from "@xmtp/xmtp-js";
import {ContentCodec} from "@xmtp/xmtp-js";


export interface ReadReceiptContent {
    conversationId?: string
    messageId: string
}

export const ContentTypeReadReceipt = new ContentTypeId({
    authorityId: 'xmtp.org',
    typeId: 'read-receipt',
    versionMajor: 1,
    versionMinor: 0,
});

export function isReadReceipt(arg: any): arg is ReadReceiptContent {
    return arg &&
        arg.messageId &&
        typeof arg.messageId === "string" &&
        ((arg.conversationId &&
            typeof arg.conversationId === "string") || arg.conversationId === undefined || arg.conversationId === null)
}

export const ReadReceiptCodec = (): ContentCodec<ReadReceiptContent> => {
    return {
        contentType: ContentTypeReadReceipt,
        encode: (content: ReadReceiptContent): EncodedContent => {
            if(!isReadReceipt(content)) {
                throw new Error(`Type error, the content we get is not a valid ReadReceiptContent!`);
            }
            return {
                type: ContentTypeReadReceipt,
                parameters: {},
                fallback: `I read ${content.messageId} in the ${content.conversationId} conversation`,
                content: new TextEncoder().encode(JSON.stringify(content)),
            };
        },
        decode: (content: EncodedContent): ReadReceiptContent => {
            const encoding = content.parameters.encoding;
            if (encoding && encoding !== "UTF-8") {
                throw new Error(`unrecognized encoding ${encoding}`);
            }
            const contentString = new TextDecoder().decode(content.content);
            const obj = JSON.parse(contentString)
            if(isReadReceipt(content)) {
                return obj
            } else {
                throw new Error(`Content is malformed! ${JSON.stringify(obj)}`);
            }
        }
    }
}

We would send it to a custom conversation topic/id I would be happy to get name ideas for that.

[yash-luna]

This is awesome @tg44! Couple follow-ups:

• What do you plan to use as messageId?
• How will users be able to opt-in & opt-out?
• What trigger should a front-end use to send a read receipt?

Once the first implementation is complete, it'd be great to collaborate on an XIP to create a shared standard for read receipts across apps.

[tg44]

What do you plan to use as messageId?

Now that you asked, we don't really need it bcs of the dates? I think it is less error prone, and also removes network speed glitches. (I would store the last seen (peer) message on it.)

How will users be able to opt-in & opt-out?
What trigger should a front-end use to send a read receipt?

We would probably send it only from the robot first, so the user opt-in/out is not really a concern right now, but we already have a method to "store" user settings across browsers, so we can "save" the opt in/out data there.