From b68fd0c6fcc4f0e5bada9cb8e48aab1b9607402c Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 28 Mar 2023 15:58:51 +0100 Subject: [PATCH] Spec annotations --- .../client_server/newsfragments/1475.feature | 1 + content/client-server-api/_index.md | 4 + .../modules/event_annotations.md | 92 +++++++++++++++++++ content/client-server-api/modules/push.md | 25 +++++ data/event-schemas/examples/m.reaction.yaml | 10 ++ data/event-schemas/schema/m.reaction.yaml | 37 ++++++++ 6 files changed, 169 insertions(+) create mode 100644 changelogs/client_server/newsfragments/1475.feature create mode 100644 content/client-server-api/modules/event_annotations.md create mode 100644 data/event-schemas/examples/m.reaction.yaml create mode 100644 data/event-schemas/schema/m.reaction.yaml diff --git a/changelogs/client_server/newsfragments/1475.feature b/changelogs/client_server/newsfragments/1475.feature new file mode 100644 index 000000000..a59c21778 --- /dev/null +++ b/changelogs/client_server/newsfragments/1475.feature @@ -0,0 +1 @@ +Add `m.annotation` relations (reactions), as per [MSC2677](https://github.com/matrix-org/matrix-spec-proposals/pull/2677). diff --git a/content/client-server-api/_index.md b/content/client-server-api/_index.md index a2ca4180f..f9b432d47 100644 --- a/content/client-server-api/_index.md +++ b/content/client-server-api/_index.md @@ -1996,6 +1996,7 @@ This specification describes the following relationship types: * [Rich replies](#rich-replies) (**Note**: does not use `rel_type`). * [Event replacements](#event-replacements). +* [Event annotations](#event-annotations-and-reactions). * [Threads](#threading). * [References](#reference-relations) @@ -2579,6 +2580,7 @@ that profile. | [Moderation policies](#moderation-policy-lists) | Optional | Optional | Optional | Optional | Optional | | [Spaces](#spaces) | Optional | Optional | Optional | Optional | Optional | | [Event Replacements](#event-replacements) | Optional | Optional | Optional | Optional | Optional | +| [Event Annotations and reactions](#event-annotations-and-reactions) | Optional | Optional | Optional | Optional | Optional | | [Threading](#threading) | Optional | Optional | Optional | Optional | Optional | | [Reference Relations](#reference-relations) | Optional | Optional | Optional | Optional | Optional | @@ -2665,5 +2667,7 @@ systems. {{< cs-module name="moderation_policies" >}} {{< cs-module name="spaces" >}} {{< cs-module name="event_replacements" >}} +{{< cs-module name="event_annotations" >}} {{< cs-module name="threading" >}} {{< cs-module name="reference_relations" >}} + diff --git a/content/client-server-api/modules/event_annotations.md b/content/client-server-api/modules/event_annotations.md new file mode 100644 index 000000000..8eafc04f5 --- /dev/null +++ b/content/client-server-api/modules/event_annotations.md @@ -0,0 +1,92 @@ +### Event annotations and reactions + +{{% added-in v="1.7" %}} + +#### `m.annotation` relationship type + +Annotations are events that use an [event +relationship](#forming-relationships-between-events) with a `rel_type` of +`m.annotation`. + +Annotations are normally used for "reactions": for example, if the user wants +to react to an event with a thumbs-up, then the client sends an annotation +event with the corresponding emoji (👍). Another potential usage is to allow +bots to send an event indicating the success or failure of a command. + +Along with the normal properties `event_id` and `rel_type`, an `m.relates_to` +property with `rel_type: m.annotion` should contain a `key` that indicates the +annotation being applied. For example, when reacting with emojis, the key +contains the emoji being used. + +An example `m.annotation` relationship is shown below: + +```json +"m.relates_to": { + "rel_type": "m.annotation", + "event_id": "$some_event_id", + "key": "👍" +} +``` + +{{% boxes/note %}} +Any `type` of event is eligible for an annotation, including state events. +{{% /boxes/note %}} + +#### Events + +{{% event event="m.reaction" %}} + +#### Client behaviour {id="annotations-client-behaviour"} + +The intention of annotations is that they are counted up, rather than being +displayed individually. Clients must keep count of the number of annotations +with a given event `type` and annotation `key` they observe for each event; +these counts are typically presented alongside the event in the timeline. + +When performing this count: + + * Each event `type` and annotation `key` should normally be counted + separately, though whether to actually do so is an implementation decision. + + * Annotation events sent by [ignored users](#ignoring-users) should be + excluded from the count. + + * Multiple identical annotations (i.e., with the same event `type` and + annotation `key`) from the same user (i.e., events with the same `sender`) + should be treated as a single annotation. + + * Implementations should ignore any annotation event which refers to an event + which itself has an `m.relates_to` with `rel_type: m.annotation` or + `rel_type: m.replace`. In other words, it is not possible to annotate a + [replacement event](#event-replacements) or an annotation. + + * When an annotation is redacted, it is removed from the count. + +{{% boxes/note %}} +It is not possible to edit a reaction, since replacement events do not change +`m.relates_to` (see [Applying `m.new_content`](#applying-mnew_content)), and +there is no other meaningful content within `m.reaction`. If a user wishes to +change their reaction, the original reaction should be redacted and a new one +sent in its place. +{{% /boxes/note %}} + +#### Server behaviour + +##### Avoiding duplicate annotations + +Homeservers should prevent users from sending a second annotation for a given +event with identical event `type` and annotation `key` (unless the first event +has been redacted). + +Attempts to send such an annotation should be rejected with a 400 error and an +error code of `M_DUPLICATE_ANNOTATION`. + +Note that this does not guarantee that duplicate annotations will not arrive +over federation. Clients are responsible for deduplicating received +annotations when [counting annotations](#annotations-client-behaviour). + +##### Server-side aggregation of `m.annotation` relationships + +`m.annotation` relationships are *not* [aggregated](#aggregations) by the +server. In other words, `m.annotation` is not included in the `m.relations` +property. diff --git a/content/client-server-api/modules/push.md b/content/client-server-api/modules/push.md index d50561190..b59c84bc4 100644 --- a/content/client-server-api/modules/push.md +++ b/content/client-server-api/modules/push.md @@ -539,6 +539,31 @@ Definition: } ``` +**`.m.rule.reaction`** + +{{% added-in v="1.7" %}} + +Matches any event whose type is `m.room.reaction`. This suppresses notifications for [`m.reaction`](#mreaction) events. + +Definition: + +```json +{ + "rule_id": ".m.rule.reaction", + "default": true, + "enabled": true, + "conditions": [ + { + "kind": "event_match", + "key": "type", + "pattern": "m.reaction" + } + ], + "actions": [] +} +``` + + **`.m.rule.room.server_acl`** {{% added-in v="1.4" %}} diff --git a/data/event-schemas/examples/m.reaction.yaml b/data/event-schemas/examples/m.reaction.yaml new file mode 100644 index 000000000..055145e82 --- /dev/null +++ b/data/event-schemas/examples/m.reaction.yaml @@ -0,0 +1,10 @@ +{ + "type": "m.reaction", + "content": { + "m.relates_to": { + "rel_type": "m.annotation", + "event_id": "$some_event_id", + "key": "👍" + } + } +} diff --git a/data/event-schemas/schema/m.reaction.yaml b/data/event-schemas/schema/m.reaction.yaml new file mode 100644 index 000000000..4d8ce43b9 --- /dev/null +++ b/data/event-schemas/schema/m.reaction.yaml @@ -0,0 +1,37 @@ +allOf: + - $ref: core-event-schema/room_event.yaml +description: |- + Indicates a reaction to a previous event. + + Has no defined `content` properties of its own. Its only purpose is to hold an + [`m.relates_to`](/client-server-api/#definition-mrelates_to) property. + + Since they contain no content other than `m.relates_to`, `m.reaction` events + are normally not encrypted, as there would be no benefit in doing so. +type: object +properties: + content: + type: object + properties: + m.relates_to: + description: |- + Indicates the event being reacted to, and the type of reaction. + type: object + title: ReactionRelatesTo + properties: + rel_type: + type: string + enum: ["m.annotation"] + event_id: + type: string + description: |- + The event ID of the event that this is a reaction to. + example: "$some_event_id" + key: + type: string + description: |- + An emoji representing the reaction being made. Should include the + unicode emoji presentation selector (`\uFE0F`) for codepoints + which allow it (see the [emoji variation sequences + list](https://www.unicode.org/Public/UCD/latest/ucd/emoji/emoji-variation-sequences.txt)). + example: "👍"