Accepted as Draft as per Council vote from 2020-10-07.
First draft.
+ Message reactions allow to express an opinion or feeling towards a message + in a quick and light-weight way. Reactions are described in the form of + emojis and can enhance communication especially when chatting with multiple + parties. Other possible uses include voting and checking to-do list items. +
++ Reactions are typically displayed in a summarizing fashion visually attached + to the message they belong to. +
++ Related work has been done in &xep0367;. However, it can't be used for + reactions, as it would cause difficulties with non-supporting clients, is + not tailored to emojis and does not specify removal of reactions. To solve + these issues, this XEP introduces a separate XML element for reactions. +
++ If a client implements message reactions, it MUST specify the + 'urn:xmpp:reactions:0' feature in its service discovery information features + as specified in &xep0030; and the Entity Capabilities profile specified in &xep0115;. +
++ When a user chooses to react to a message with a certain emoji, the + client sends a <message> stanza containing a <reactions> + element. The chosen emoji is included in a <reaction> element within + the <reactions> element. The message is referred to by including its + id or in MUCs its stanza-id as defined in &xep0359; in the 'id' attribute + of the reactions element. +
++ If the user chooses to remove reactions from or add reactions to a + message they have already reacted to, the client sends a <message> + with all <reaction> elements that are (still or newly) applicable + to that message. +
++ In order to remove all reactions from a message, an empty + <reactions> element is sent. +
+Messages MUST NOT contain more then one <reactions> element
++ A message containing a <reactions> element SHOULD be of type 'chat' + or 'groupchat'. +
+
+ A <reaction> element SHOULD only contain Unicode codepoints that can
+ be displayed as a single emoji, as specified in the latest revision of the
+ Unicode® Technical Standard #51
+ A receiving client SHOULD show reactions attached to the message they where + in response to. Reactions MAY be displayed in a summarized fashion. +
++ A <reactions> element MUST NOT contain the same reaction more than + once. A receiving entity SHOULD ignore duplicate reactions inside a + <reactions> element. +
++ The sending entity SHOULD add a <store/> hint, as defined in &xep0334;, + if the message being reacted to does not carry a <no-store/> hint. +
++ If a message is updated using &xep0308;, the 'id' attribute of the + <reactions> element SHOULD reference the original message id. + A receiving entity SHOULD accept messages with a <reactions> element + referencing a message correction and SHOULD handle such element as if + it was using the message id of the original message. +
++ In direct conversations, a reaction MUST only be accepted if the senders + bare JID matches the bare JID of any of the two involved parties. +
++ In MUCs and MUC PMs, the recipient SHOULD ensure that the real bare JID of + the sending occupant did not already send a reaction to that message to + accept it as a new reaction, e.g. by keeping track of leave/join + presences since the message was send. This implies that in semi-anonymous + MUCs it MAY be impossible to attach reactions to a message received from + the history. A reaction MAY still be a valid reaction update (as per the + next paragraph) if it was not accepted as a new reaction. +
++ A reaction MUST only be considered an update if it orignates from the same + sender as a previous reaction message. In direct conversations, this means + the bare JID MUST match the original bare JID. In MUCs and MUC PMs the + senders full JID MAY not match the original full JID, but the recipient + MUST ensure that the real bare JID of the sending occupant is the same as + the real bare JID of the previous reaction message, e.g. by keeping track + of leave/join presences. +
++ If a message containing a <reactions> element arrives delayed, which + means it carries a <delay/> element, as defined in &xep0203; it SHOULD + only be accepted, if no newer reaction from the same sender was already + accepted. +
++ For messages of type 'groupchat', the stanza's 'id' attribute MUST NOT be + used for reactions. Instead, in group chat situations, the ID assigned to + the stanza by the group chat itself must be used. This is discovered in a + <stanza-id> element with a 'by' attribute that matches the bare JID + of the group chat, as defined in &xep0359;. +
++ This implies that group chat messages without a &xep0359; stanza-id cannot + be reacted to. +
++ For other message types the sender should use the 'id' from a &xep0359; + <origin-id> if present, or the value of the 'id' attribute on the + <message> otherwise. +
+This document requires no interaction with &IANA;.
+The ®ISTRAR; includes 'urn:xmpp:reactions:0' in its registry of protocol namespaces (see &NAMESPACES;).
+