[Standards] Proposed XMPP Extension: Message Reactions

Jonas Schäfer 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
> 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>.

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 
legacy clients:

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

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(!) 
fallback format.

XMPP has enough cases of "losing" messages, especially once OMEMO is involved, 
we don’t need more.

Convince me otherwise.

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190722/430866fe/attachment-0002.sig>

More information about the Standards mailing list