XIP-20: Reactions content type

mg · January 10, 2024, 10:26pm

xmtp/XIPs/blob/main/XIPs/xrc-20-reaction-content-type.md

---
xip: 20
title: Reactions content type
description: This XIP describes a way to add reactions in clients that support XMTP.
author: Matt Galligan (@galligan)
discussions-to: https://community.xmtp.org/t/reactions-content-type/524
status: Final
type: Standards
category: XRC
created: 2024-01-05
---

## Abstract

This XIP introduces the reaction content type for XMTP clients, enabling users to react to messages with emojis. It defines an action field (values: 'added', 'removed') for reaction management, and a schema field (value: 'unicode') for categorizing emoji types. This standardization aims to enhance communication efficiency and engagement across XMTP clients.

## Motivation

The goal of this content type is to bring a dynamic and expressive form of communication to the XMTP ecosystem. Reactions are integral in modern messaging, allowing for rapid, non-verbal responses in conversations. Implementing this standard promises to streamline communication, making it more effective and enjoyable as well as consistent with expectations of current messaging apps.

This file has been truncated. show original

nplasterer · January 10, 2024, 11:12pm

I’ve seen this successfully implemented in several apps now including xmtp.chat. This proposal looks good to me

My only comment would be on reaction removals being the same content type just sent again with the same content but flagged as a removal. It might be nice if reaction removals were a different content type or if there was a way to make certain aspects of contentTypes mutable.

nick · January 24, 2024, 1:49am

Before we finalize this content type I want to make sure: do we really need to support non-unicode schemas in the initial version?

Unicode seems to be the only schema currently used by applications. If someone were to send a shortcode-discord emoji it is unlikely that any client application other than their own would be able to read it and display it properly. This hurts interoperability, and raises the bar substantially for an integrator to fully support this content type.

rygine · January 25, 2024, 7:10pm

i’m OK with this suggestion. it definitely simplifies the implementation.