[Standards] Proposed XMPP Extension: Message Reactions

Georg Lukas georg at op-co.de
Fri Jul 19 14:52:03 UTC 2019

* Jonas Schäfer <jonas at wielicki.name> [2019-07-15 17:59]:
> Title: Message Reactions
> This specification defines a way for adding reactions to a message.

This is a long overdue feature. However, I have some principal and some
practical issues with that.

1. Referencing messages

This is yet another XEP that creates its own encoding for "this message
is related to that message". With MAM and "thin clients", it is
increasingly important to be able to obtain not only a given message
from the archive, but also everything related to it, be it acks,
corrections, references, reactions or attachments. That means each
server implementation needs to know about each (client-side) XEP that
references messages, and serve data according to those relationships.

XEP-0372 is in a rather sad state, as it attempts to do too many things
at once. I think we would win very much by moving the "this message
belongs to that message" part into its own very short XEP (or heavily
trim 0372), basically defining just one element, which is either a
companion or a wrapper around the actual payload that makes use of the

    <reference id="X" />

That would also make section §4.2 obsolete, which has very strong
assumptions on which IDs are the "right ones" to use, and where I'm not
convinced I fully agree with.

2. Backward compatibility

This XEP does not provide any way for legacy clients to see reactions.
This (silently) precludes a large number of users from a subset of the
discussion. I propose(d) the following addition:

a) Each reaction SHOULD contain a legacy reaction body, consisting of:

| <nickname of the sender> <timestamp>: (only for group chats)
| > <beginning of original message> (quotation according to XEP-0393 §5.1.3; limited to e.g. first line/40chars)
| <reaction(s)>

b) the <body> MUST NOT contain any other content than a legacy rendering
   of the reaction(s).

c) a compliant client SHOULD ignore the body element and just obtain the
   data from the actual <reactions> element.

This would allow legacy clients to see the reaction, making use of
XEP-0393 formatting, and potentially notify the original author by
mentioning their nickname.

2. Correcting reactions

I think that with XEP-0308, we have a very good mechanism to do
correction of messages, and for the sake of consistency, we should make
use of that instead of inventing another one.

3. Multiple reactions

I'm not sure what the use-case is for allowing multiple reactions from
the same person for a single message. I think it's adding complexity and
corner cases (you need to remove all "old" reactions from a user on an
update; you need to perform deduplication), without a benefit.

4. Limitation to Emoji

I'm not sure how much this makes sense. Unicode is steadily evolving,
and it's already non-trivial to determine what's a "single emoji"
according to the current rules (i.e. some fonts will auto-combine
Regional Indicator Symbol Letters into flags, while others won't).

I think it makes sense to keep the first part of the rule, for sending
entities, but receiving clients should be able to just render whatever
they get. While this opens up a little for abuse, it will make interop
between clients running on different versions of the Unicode
specification much smoother.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190719/4336b51e/attachment.sig>

More information about the Standards mailing list