[Standards] Message Reactions vs XEP-0367 vs. XEP-0372

Georg Lukas georg at op-co.de
Mon Jul 29 12:29:04 UTC 2019


Hi Marvin,

* Marvin W <xmpp at larma.de> [2019-07-24 22:02]:
> > Referencing messages

I agree with all that you wrote about XEP-0372, and I suppose the only
reason it gets referenced so often in these discussion is because it's
inadequately titled "Message References".

> On the contrary, XEP-0367 does not suffer from any of these issues.

That's a great catch. I actually think that 0367 is a perfect match for
Reactions, even though I consider it to be too specific for the problem
of generic message association - it is not well-suited for:

 - Delivery Receipts
 - Last Message Correction (do you attach a correction to the original?)

I don't see the Business Rules of 0367 as a problem here - I'm pretty
sure they don't interfere with Reactions, and we could change them if
they do anyway.

> Another alternative that I'd like to propose is to not mix server
> processing information ([...]) with client and message information.

I think this is opening a can of worms, because as a sender, you end up
adding multiple elements with the same semantic meaning (this message
belongs to X). A malicious client could start gaming implementations by
adding different references to the different elements.

> I am happy to work any of these three possibilities into a XEP
> (modification) proposal, if there was consensus which is best.

I think that the issues inside of 0367 are outside of your scope and
should be solved by its authors/the Council, and that it would make very
much sense to use the 0367 attach-to element in Reactions.

> > Backward compatibility
> 
> That said, I support Florians suggestion to gather some implementation
> experience first and decide on a more specific business rule afterwards.

Yes, let's go on with that. Nothing I have read so far got me convinced,
but this is not a blocker for moving to Experimental.

> > Correcting reactions
> 
> There are two main reasons for me to not use XEP-0308. First (according
> to its specification) it only can be used for the last outgoing message.

You can well supersede that rule in your XEP by saying that LMC can be
applied for Reactions without any time / history constraints.

That said, I accept your arguments, and I'd be fully OK with LMC only
getting used for the backward compatibility part of Reactions.

> > Limitation to Emoji
> 
> I think the current specification is open enough to allow future
> extension of what a reaction is.

My issue is with TR51 being a living standard, which will inevitably
cause implementations to disagree on what is valid and what is not. If
you want a demonstration of the (arguably worst-case) effect of this,
try to join a large public MUC with a nickname of "🤖" (U+1F916 Robot
Face), and then send a message there.

This is why I had a hard time with this specific statement:

| Receiving entities MAY ignore <reaction> elements that do not comply
| with this specification.


> By having the reaction as a text and not as an attribute, future
> versions of the XEP could allow for other elements including XEP-0231
> images inside the <reaction> element.

But then you'd want to have a backward-compatible emoji text inside of
<reaction> anyway, to accommodate the first generation of Reactions
clients ;-)

> I hope that, despite the valid discussion points, we can advance with
> the standardization process of Reactions as fast as possible. At Dino,
> we prefer to not implement any non-standard behavior on the master 😉.

None of my points was blocking the acceptance of Reactions as an
Experimental standard, but you'll have a hard time convincing me on the
backward compatibility issue, if you want to get it into Draft fast.


Kind regards,


Georg
-------------- 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/20190729/0d341b03/attachment.sig>


More information about the Standards mailing list