[Standards] Proposed XMPP Extension: Message Reactions
dave at cridland.net
Tue Jul 23 10:02:52 UTC 2019
On Fri, 19 Jul 2019 at 15:52, Georg Lukas <georg at op-co.de> wrote:
> * 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.
General agreement here.
> 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.
General disagreement here.
I'm all in favour of backwards compatibility, but I'm not convinced we
should burden the network with long-form descriptions of what the stanza
might do if only the recipient had a client which understood it.
The trouble is, this body will be sent, for example, over a push
notification. And look ugly. And it'll be stored in MAM until, when,
It'll use bandwidth - sure, only a few octets, but still doubling or
trebling the stanza size in order explicitly to handle the case where a
recipient wouldn't understand the message anyway.
> 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.
I know of many cases where users want to send multiple reactions to the
same message. Irrespective of whether I think it's childish and silly, I'll
still agree it's a desirable use case. Perhaps even because it's childish
and silly, and that can be important too.
> 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.
Loose agreement here, but also, I suspect people will rapidly want to react
in custom ways not expressible in Unicode, so we might want URls or inline
media to be possible too.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 79400 bytes
Desc: not available
More information about the Standards