diff --git a/proposals/4027-custom-images-in-reactions.md b/proposals/4027-custom-images-in-reactions.md new file mode 100644 index 00000000000..79983085fd2 --- /dev/null +++ b/proposals/4027-custom-images-in-reactions.md @@ -0,0 +1,138 @@ +# MSC4027 Custom Images in Reactions + +One of the most desired features within the Matrix ecosystem is the ability to +react to messages with custom images. This feature is especially requested by +users who come from Slack and Discord where this functionality is one of the +main ways that the culture of a chat rooms develops. + +There is an existing proposal to +[render image data in reactions (MSC3746)](https://github.com/matrix-org/matrix-spec-proposals/pull/3746/), +but it has had little attention recently and has the flaw of not being conducive +to deduplication (either on the client or server). Sorunome proposed a +modification to that MSC to +[use the MXC URI as the key](https://github.com/matrix-org/matrix-spec-proposals/pull/3746/files#r866285147) +which this proposal adopts. + +This proposal is meant to replace +[MSC3746](https://github.com/matrix-org/matrix-spec-proposals/pull/3746/) and is +additionally intended to document the behaviour of existing clients and bridges. + +Like +[MSC3746](https://github.com/matrix-org/matrix-spec-proposals/pull/3746/), this +MSC does not propose a mechanism for providing a list of available images. + +## Proposal + +This proposal suggests two changes to events with the `m.annotation` relation. + +1. If the `key` of an `m.annotation` relation is an MXC URI of an image, clients + should render the referenced image instead of the key text. + +2. When the annotation's key is an MXC URI, a new (optional) `shortcode` key can + be added to the content of the event with a textual name for the image. This + field must be a string and should start and end with the `:` (colon) + character. + + This shortcode should be shown by clients in situations such as hovering over + the annotation, as alt-text, or if the client does not support rendering + images. + + The `shortcode` must have a length of less than or equal to 100 bytes + (including the colons at the beginning and end of the string). This + restriction must be enforced by servers when sending reactions, but servers + should not reject events coming across federation due to having too many + bytes in the `shortcode` field. Servers may still opt to locally redact + events having too many bytes in the `shortcode` field. + +Example custom image reaction event content + +```json +"content": { + "m.relates_to": { + "rel_type": "m.annotation", + "event_id": "$abcdefg", + "key": "mxc://matrix.org/VOczFYqjdGaUKNwkKsTjDwUa" + }, + "shortcode": ":partyparrot:" +} +``` + +## Potential issues + +### Clients rendering the MXC URI as text + +The biggest disadvantage is that clients that do not support rendering custom +reactions will render the MXC URI as text. However, this is already problematic +because many bridges and clients already support this MSC, and users likely +already encounter this. + +### Un-renderable image referenced in the `key` + +The MXC URI could specify an asset that either does not exist, or is not a +renderable image. Clients can opt to render the `shortcode` in these situations, +or some placeholder/error image, or just opt to render the full key. + +### Multiple MXC URIs can refer to identical files + +Consider two distinct MXC URIs which both refer to a file with identical +contents. If the URIs are used as reaction keys on a given message, +deduplication will not happen as the keys are different. This could cause +confusion as the two reactions would be visually identical despite the keys +being different. + +A similar problem exists already in some clients with Unicode emojis because +there is significant inconsistency as to whether skin tone indicators and other +un-renderable characters should be included in the reaction keys generated by +clients. As such, this proposal does not materially worsen the current +situation. + +Clients can opt to compare the file contents of the images, but this should not +be required as it would complicate rendering significantly. + +Future MSCs may provide a way to share a set of custom reaction images available +in a room/space. This will make it so that users can share custom reaction +images reducing the likelihood of two users uploading the same image under two +different MXC URIs and reacting with them. + +## Alternatives + +### Use the shortcode as the `key` + +This is what was proposed by +[MSC3746](https://github.com/matrix-org/matrix-spec-proposals/pull/3746/). The +problem with this is that there could possibly be multiple distinct images with +the same shortcode. Reactions are only deduplicated based on `key`, so clients +and servers would group these distinct reactions together which is undesirable. + +### Put the `shortcode` as a key within `m.relates_to` + +Instead of being at the root of the `content` dictionary, the `shortcode` value +could be included within `m.relates_to`. This is the wrong place to put this +value because `m.relates_to` is meant to only contain information pertaining to +the relationship between events, not information about the reaction event +itself. + +## Security considerations + +### Image is unencrypted + +Reaction events are not encrypted, and so the MXC URI referenced by the key +would have to be an unencrypted image. However, this is probably not a problem +for the following reasons: + +- Custom reactions are most likely not sensitive information. + +- Users are already able to upload unencrypted content into encrypted rooms, so + this does not introduce any leakage that was not previously possible. + +- Clients can add UX to indicate to users that the reaction images are not + encrypted. + +## Unstable prefix + +Until this proposal is merged into the spec, the `shortcode` unstable field name +should be `com.beeper.reaction.shortcode`. + +An unstable prefix for the `key` in `m.relates_to` is not necessary as the spec +already allows arbitrary data to be used as the `key`. This MSC merely adds +extra meaning to a specific class of key.