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 used. 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, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
