Reaction content type proposal

[Im-Kunal-13]

• Create xip-reaction-content-type.md

[neekolas]

I'm not sure what value the senderAddress field is adding here. All XMTP messages have some indication of who the sender is (headers for V1 messages and a signature for V2 messages). Given that any party who is able to send messages into the conversation could create a reaction, it would be possible for Party A to send a reaction and put Party B's address as the senderAddress (or even some other random address).

Feels safer to just rely on the senderAddress from the XMTP wrapper. For V2 messages (the bulk of the messages on our network right now), this is cryptographically authenticated via signature.

[Im-Kunal-13]

Yes right. We can use the senderAddress from the XMTP message itself instead of relying on this. Should I remove it and commit ?

[nakajima]

Yes right. We can use the senderAddress from the XMTP message itself instead of relying on this. Should I remove it and commit ?

Ya you can remove this and commit.

[Im-Kunal-13]

Yes right. We can use the senderAddress from the XMTP message itself instead of relying on this. Should I remove it and commit ?

Ya you can remove this and commit.

Okay sure.

[neekolas]

Would this be the message.content from the message you are reacting to? Why do we need to duplicate that in the Reaction? Couldn't clients just read the original message?

[Im-Kunal-13]

yes messageContent is the message.content from the message we're replying to.

It's necessary to duplicate it for the following use cases :

1. We're loading the last messages of all the conversations of a user to show them in the chat previews. Whenever the last message is a Reaction, we need the messageContent and contentTypeId to display which message it has been reacted to. ( See the image)

2. There are cases where the message we reacted to is not loaded yet (due to the pagination) and so we won't have messageContent and contentTypeId info if we try to filter and find it from the message's state in the application through the Reaction's messageId.

[nakajima]

I think we should just pass IDs here, since duplication could lead to different content being passed in different places which would lead to inconsistency. It also doesn't account for non-text messages.

[Im-Kunal-13]

Yes we can remove the messageContent and contentTypeId and only keep the messageId and reaction for this to work.

Although as we won't have the the content of the message we reacted to, we can't show them in the preview. It will be just the reaction.

[neekolas]

If the reaction field is only ever expected to be a single UTF-8 emoji character, we can indicate and enforce that the maximum allowed length for this field is 4 bytes. Otherwise someone can dump a short novel into the field and it would be up to the receiving client to figure out what to do with that.

[Im-Kunal-13]

Yes exactly that's better. At what step do you recommend the validation should be done ?

[neekolas]

Both encode and decode should validate

[nakajima]

Just pushed some updates here to remove duplicate fields from the proposal as well as tweak where the reaction actually gets stored (the content rather than as a parameter).

I've also added a link to a reference implementation here.

[nplasterer]

I just wanted to note that we added reaction content types into the JS SDK here: xmtp/xmtp-js-content-types#13 & xmtp/xmtp-js-content-types#9 and we gave a reference implementation in our React playground here: xmtp/xmtp-react-playground#1
This should unblock any jsSDK or reactnativeSDK integrators.
We have tasks to add support to kotlin, swift, and flutter soon.

If you have questions, comments, feedback, or concerns please raise them here: https://github.com/orgs/xmtp/discussions/36

[jhaaaa]

After more than six months of inactivity on this XIP, we have set its status to Stagnant. We have merged the XIP to the repo for historical purposes and are closing this PR. Thank you very much for your contribution, @Im-Kunal-13!