[Standards] Proposed XMPP Extension: Message Reactions

Florian Schmaus flo at geekplace.eu
Fri Jul 19 21:28:23 UTC 2019

On 19.07.19 19:42, Marvin W wrote:
> 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.
> > 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.

I am sure that this what we should do. There appears to be some
potential for a generic building block which could be beneficial for
various other XEPs. If everyone would just throw in new XEPs without
caring for those building blocks, then we would probably miss an
important opportunity.

Why not create a small section in your XEP which specifies how to
reference messages in a generic way, and then make use of that
mechanism? We can later factor out that section into its own XEP if we
think that it is ready.

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

Why not gather some implementation experience first and see what we can
learn from it. There is no need to decide for one or the other at this
early stage.

That said: I tend to agree with Georg on this.

- Florian

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

More information about the Standards mailing list