Replies: 2 comments
-
We have implemented this proposal in an official content type located here and published on the NPM registry here. This implementation contains 2 additional fields from the proposal:
|
Beta Was this translation helpful? Give feedback.
-
Please continue this discussion in Discourse, the new home for XMTP Community Forums: https://community.xmtp.org/t/proposal-for-emoji-reactions-content-type/499 |
Beta Was this translation helpful? Give feedback.
-
This improvement proposal idea imagines a way to add emoji reactions in clients that support XMTP. This proposal relies heavily on knowledge of this reply content type improvement proposal idea, specifically the ideas around using
referencing_message_id
.Background
Emoji reactions in messaging apps are useful because they provide a quick and easy way for users to express their emotions, thoughts, hot takes, etc. to a message without having to type out a response. This can help to facilitate more efficient, effective, and even evocative communication, as well as add an element of fun and personality to the conversation. Additionally, emoji reactions can be a useful tool for group chats, as they allow multiple users to react to a message at once, providing a more comprehensive understanding of the group’s overall response. 😁
This proposal introduces a means to support emoji-as-reactions.
Note the use of the name
emojiReaction
. This is to focus specifically on the use of emoji as the reaction medium.The encoded content MUST have the following parameters:
Additional context
As emoji are characters in the UTF-8 (unicode) character set, support for encoding and decoding UTF-8 is required by supporting clients.
referencing_message_id
See this proposal for definition.
emoji
In the above specification, the emoji character is added directly to the property, such as
🫠
.contentFallback
In the above example, the fallback text includes all or a portion of the message being replied to, so that the context can be understood in clients that do not yet support reactions. This is similar to how iMessage handles reactions in SMS conversations.
As mentioned in the reply content type proposal, it may be desirable to truncate
${message.content}
to ~140 characters so as to not make for an overwhelming experience.Presentation
The presentation of emoji reactions is intentionally left out of this proposal, as those are decisions to be made by client applications. The official proposal may include some examples of possible UI.
Additional considerations
Clients SHOULD account for situations when an emoji character is sent that isn’t yet supported by the client or OS. This may happen when an OS update includes new emoji characters, which are then made available to a sender, but may not be supported on the recipient’s client, OS, or device.
Beta Was this translation helpful? Give feedback.
All reactions