[Standards] Proposed XMPP Extension: Message Reactions

Marvin W xmpp at larma.de
Wed Jul 24 20:00:30 UTC 2019


Hi,

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

Given the feedback this proposed XEP received, I'd like to drop a few
more comments on the issues raised. Sorry, wall of text ahead.

> Referencing messages

There seems to be consensus that a generalized feature to annotate that
a message semantically belongs to a previous message or is a "child"
message of a specified "parent" might be of use for this and other XEPs.

For some reason, people always suggest XEP-0372 in this context, however
that XEP seems unusable for that purpose to me, for various reasons:
a) A XEP-0372 reference to a message or other resource doesn't and
shouldn't imply that it semantically belongs to that resource or
"parent" message.
b) XEP-0372 allows to reference multiple resources.
c) XEP-0372 does not allow to reference messages.
d) XEP-0372 seems to be a client only annotation, i.e. the §2 only talks
about clients to be able to implement it.
Additionally XEP-0372 is rather unfinished. I really wondered how it was
able to reach standards track given that it is mostly a list of todos.
This also means that one could update it to address the aforementioned
issues, if this is actually what the original author intended (define a
new 'parent' value for the 'type' attribute, that may only exist once
per message; define a way to reference messages instead of URIs or
define a way how a URI references a message; ...)

On the contrary, XEP-0367 does not suffer from any of these issues. It
also reads way more like intended for that use. It defines the same
logic regarding selection of message id as the proposed Reactions XEP.
It just comes with the ugly business rule that servers may strip the
<attach-to /> and that <attach-to /> must not be used for
"non-messaging" payload (whatever exactly this means).

Another alternative that I'd like to propose is to not mix server
processing information (which this seems to be, as it's mostly intended
to be used by a yet-to-be-created version of MAM) with client and
message information. That would mean that this proposed XEP as well as
others like LMC, Message Attaching, etc. are not directly affected.
Instead, some other XEP (Could be XEP-0334, but it could also be an
entirely new one) specifies a <child-of id='X' /> element that would
only be used to describe the child annotation to the MAM server and
nothing else. XEPs like LMC or others can than mandate that clients
SHOULD attach this <child-of /> element, but not make any use of the X
on the receiving end. The advantage of this approach is that it doesn't
mandate client side semantics that likely will at some point cause
troubles (how would a LMC of a attached message look like if both are
supposed to make use of the same <reference id='X' />?) and still can
create a tree of the message children.

I am happy to work any of these three possibilities into a XEP
(modification) proposal, if there was consensus which is best.


> Backward compatibility

There clearly have been opposing opinions on that matter. I believe they
are partly driven by different understanding on how Reactions might be
used in the wild, but I doubt there will be any way to reach consensus
on a rule that mandates a specific body or its absence. That said, I
support Florians suggestion to gather some implementation experience
first and decide on a more specific business rule afterwards.


> Correcting reactions

There are two main reasons for me to not use XEP-0308. First (according
to its specification) it only can be used for the last outgoing message.
This doesn't reflect the Reactions implementation of any other chat
system I know and certainly isn't what users would expect. Second, it
increases the client side complexity and number of corner cases a lot:
- The correction message would have to include references to two other
messages (the message being reacted on and the first reaction message)
- What should happen if the correction does specify a different message
to react on than the corrected message?
- What should happen if the receiving client does not know the first
reaction message or learns the first reaction message only later
(through MAM)?
- What happens if a corrected message reaction does not include a
<replace /> because the sending client didn't know about the prior
reaction (send from another client)?
...
The only reason when LMC would make sense, is when we do have backwards
compatibility and the receiving client does support LMC but not
Reactions. As legacy clients tend to not support LMC either, there
probably isn't a lot of use case of this after an initial introductory
phase. Though with your strong opinion regarding backwards
compatibility, I understand why you propose this.


> Limitation to Emoji

I think the current specification is open enough to allow future
extension of what a reaction is. For now unicode emoji seems to be
enough. By having the reaction as a text and not as an attribute, future
versions of the XEP could allow for other elements including XEP-0231
images inside the <reaction> element. Clients not supporting these new
extension would than just ignore those Reactions, but display any other
by the same sender (at least according to the current XEP proposal).


I hope that, despite the valid discussion points, we can advance with
the standardization process of Reactions as fast as possible. At Dino,
we prefer to not implement any non-standard behavior on the master 😉.

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/20190724/755df3f5/attachment.sig>


More information about the Standards mailing list