diff --git a/xep-0444.xml b/xep-0444.xml new file mode 100644 index 00000000..914cb86c --- /dev/null +++ b/xep-0444.xml @@ -0,0 +1,237 @@ + + + %ents; + ]> + + +
+ Message Reactions + This specification defines a way for adding reactions to a message. + &LEGALNOTICE; + 0444 + Experimental + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + XEP-0030 + XEP-0115 + XEP-0203 + XEP-0334 + XEP-0359 + + + + reactions + + Natalie + Wirth + xsf@larma.de + + + Marvin + Wissfeld + xsf@larma.de + jabber@larma.de + + + 0.1.0 + 2020-10-13 + XEP Editor (jsc) + Accepted by vote of Council on 2020-10-07. + + + 0.0.1 + 2019-07-14 + nw/mw +

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. +

+ + Hello, world! +]]> + + + 👋 + + +]]> + + +

+ 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 Unicode® Technical Standard #51 <http://www.unicode.org/reports/tr51/>.. + Receiving entities MAY ignore <reaction> elements that do not comply + with this specification. +

+

+ 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;).

+
    +
  • urn:xmpp:reactions:0
    • +
+ + +