[Standards] Proposed XMPP Extension: Message Reactions
jonas at wielicki.name
Mon Jul 22 19:26:55 UTC 2019
On Freitag, 19. Juli 2019 19:42:22 CEST Marvin W wrote:
> > 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:
> > [… snip by Jonas …]
> > 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
> 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>.
I’m going to pick this one out for now because I’m short on time, and this is
a critical point for me.
We discussed this in some MUC and I have a strong opinion on this. There MUST
be a fallback format defined, and it MUST be required. Here’s why:
Reactions are part of communication. Our goal should be to build reliable
communication systems. If communication is unintentionally only visible to
parts of the users, the communication system has failed.
I can come up with lots of situations where this is relevant, but it is
extremely relevant whenever the Reaction will be the only reaction (note
capital R "Reaction" referring to the ProtoXEP, "reaction" referring to the
concept of a reply to a thing). Often, this is when the thumbs up thing is
I think the XEP should mandate:
- a specific, mandatory format for the fallback, which includes the sender
name of the original post (multi-user context only), a timestamp of the
original post and parts of the text of the original post (original post ==
message to which the reaction refers)
- the <body/> MUST be exactly the text of the fallback
- conforming clients MUST NOT show the body
- conforming clients might want to verify the body
I don’t care whether it’s compatible with XEP-0393
The fallback will hurt UX in legacy clients. There are two categories of
- Hopeless cases such as Pidgin. There’s no hope for Pidgin users, like
myself. Let them (us) be hurt by this.
- Users who cannot upgrade for whatever reason. Especially in this case, I’d
argue that it’s important to preserve semantics. If it is a problem for those
users, there’s still the normal human interaction way to sort things out.
- Clients which were started before this XEP will have become popular, but
which are still maintained. Adding code which allows to strip the fallback of
the body (leaving only the reaction), hides the reaction altogether or
implement a proper visual representation of the reaction (in roughly
increasing order of complexity) should be no problem for those. But it eases
the transition period by offering the *content* and *intent* of the message in
Yes, there will be situations where you’ve got to explain something about that
weird format around your Emoji. That’s better than figuring out that your :+1:
or whatever reaction to a yes/no question was never received/seen.
I’m all for reducing technical debt and increasing efficiency, but not at the
cost of reliability of the communication. Silently dropping messages is *bad*,
and that’s what would happen if this XEP was deployed without a mandatory(!)
XMPP has enough cases of "losing" messages, especially once OMEMO is involved,
we don’t need more.
Convince me otherwise.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards