[Standards] Backwards compatibility in rich messaging XEPs [Was: Proposed XMPP Extension: Message Reactions]

Maxime Buquet pep at bouah.net
Fri Jul 19 18:14:26 UTC 2019

I assumed this does not apply only to reactions, as you mentioned on
xsf@ yesterday, so I'm using this as a start for these comments.

On 2019/07/19, Georg Lukas 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 personally don't have an issue with this as a developer. If I want
support I can implement the XEP.

I am also certain many users wouldn't mind either, as you can see a
trend for example in clients not displaying presences anymore and thus
making users lose quite some context in discussions (join/parts, nick
changes, kick/bans, status, etc.)

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

Apart from the fact that you use the abomination that is 393, I am
mostly curious what you're expecting with all this.

What is your target?

I can see clients easily get away with never implementing any of the
XEPs and just using your fallback body, and I am not ok with it.

I don't want more pidgins out there getting by doing nothing and
tainting the little UX wins we got with recent clients.

I also don't want to encourage the use of 393. With what you propose,
we're definitely going on the slippery slope that started when 393 was
introduced. "Why implement anything else than 393?"

I can also see this being misguiding for new developers first seeing
this. "It's already there! I don't need to do anything!".

Lastly, as a developer you're now forcing me to support the XEP if I
don't want to support it (the irony).

Maxime “pep” Buquet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190719/7da28820/attachment.sig>

More information about the Standards mailing list