[Standards] Proposed XMPP Extension: Message Reactions

Marvin W xmpp at larma.de
Fri Jul 19 17:42:22 UTC 2019


Hi,

On 19.07.19 16:52, Georg Lukas wrote:
> 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:
> 
>     <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.

I totally agree that a single standard for referencing previous messages
for the usecase of MAM and "thin clients" would be desirable, but I'd
like to stress the point that until now and as far as I know:

- There is no (experimental/prototype) standard for a procedure to fetch
a message and all its related resources from a message archive, so it's
hard to design a XEP to be compliant with such a method.

- There is no (experimental/prototype) standard to indicate a
sub-relation to another message (as would be required for LMC,
Attaching, Reactions).

The purpose of XEP-0372 (as I read it) is exactly the opposite: it's
intended to link to any resource (external or internal) from the message
or a part of it. The referenced resource thus might be fetched with such
the message referencing it, but fetching the referenced resource in no
way implies that the message referencing it should be fetched as well
(and it obviously makes no sense for external resources to assume that).
XEP-0372 does not define a way to actually reference another message.

§3.4 of XEP-0372 defines a way to add a reference to a resource to an
existing message (or a portion of it). As an example what this could be
used for: If a message contains the name of a person, a second message
can add a <reference> to that message such that the name links to the
JID of that person (becomes a mention as described in §3.2). (On a funny
side note: If we had a way to actually do the kind of reference we need
for MAM/"thin clients", we'd have to update XEP-0372 to make use of that
feature for exactly the kind of messages as described in §3.4)

As soon as there is a XEP that defines a way to do the kind of
reference/attaching that we need for the use case of MAM/"thin clients",
this proposed reactions XEP as well as LMC and others should probably be
updated to make use of it. I don't think the new XEP should actually
rely on other XEPs being updated and be possible to be used beside other
elements that reference a message, but longterm it would be desirable to
just use that reference, if only to not have the referenced message id
twice in the message, which would save some bytes in storage and ensure
there is no conflict. However this functionality is completely out of
scope of the reactions ProtoXEP for now and the fact that we miss a
feature at some other place shouldn't keep the protocol from evolving.

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

Backwards compatibility was intentionally not included in the XEP, we
were even discussing to add a MUST NOT have a <body> rule. This is
because reactions are often used when a (full blown) message would hurt
the user experience. If users realize that some of the recipients of the
reaction would received them displayed in the way you described, they
are likely to refuse to send the reaction at all. It thus totally
combats the purpose of the XEP to have such a backwards compatibility
fallback.

We left the <body> open to allow to send a fallback message in
circumstances where it makes sense. If you pledge for adding a MUST rule
for the <body>, I'd pledge for a rule that a reaction message MUST NOT
have a <body>. If you think we should have at least some rules mentioned
in the XEP, I'd go for something like SHOULD NOT have a <body> + MUST
NOT convey more content in <body> than in <reactions>.


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

Currently XEP-0308 is not defined for anything but the last message.
Reactions might be updated later on, so XEP-0308 can not be used for that.
Beside that, using XEP-0308-like message correction with the full list
of reactions would not have any benefit over the updating rule defined
in the ProtoXEP, as you would just have to send additional message
correction element, but the behavior would be the same (beside message
correction could also be used to update a fallback body).


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

That's how literally every reactions implementation I am aware of in
other messaging apps work. We are kind of replicating a feature here and
not providing the same feature set people are already used to isn't
exactly a good way forward.

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

"can be displayed as a single emoji, as specified in the latest revision
of the Unicode® Technical Standard #51" as it says in the ProtoXEP is
actually pretty well defined. Deduplication rules might be a bit more
complex, as there are multiple ways to express the same emoji in unicode
codepoints (we already noticed how GTK and Android by default use
different ways to create the same emoji), but it is certainly possible
and expectable of a client developer to handle this. As per this
description, it does not matter what your font can actually display as a
singly emoji, only that it "can be displayed" as such.

Also as a side note, TS#51 defines a so called RGI (recommended for
general interchange) set, which is a subset of all possible unicode
emojis that is shall be supported by all clients, fonts and operating
systems and for compatibility, one might want to limit sending to these.
Additionally, for the RGI set also defines the recommended unicode
codepoints to be used for each emoji, which is the minimal
fully-qualified representation.
If people are interested in this I can do a write-up of the details of
unicode emojis and how they *should* be used in instant messaging as per
TS#51. I can also write down how to correctly do deduplication over
different codepoints for the same emoji.

As there seems to be some misunderstanding on how this feature is (to
be) used in practice, here <https://imgur.com/rNcMDfP> is a screenshot
from Slack: the two reactions highlighted in blue are the ones that I
already did on this message, the number indicates how many made such
reaction to that message. This shows that
- Multiple reactions per message from same user is a common thing (the
16 reactions were created by only 10 users).
- It would be a hell if there was fallback messages for each of these
reactions (total of 16) for legacy clients.

Cheers,
Marvin

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


More information about the Standards mailing list