Hi, > * Jonas Schäfer <[email protected]> [2019-07-15 17:59]: > Title: Message Reactions > This specification defines a way for adding reactions to a message.
Given the feedback this proposed XEP received, I'd like to drop a few more comments on the issues raised. Sorry, wall of text ahead. > Referencing messages There seems to be consensus that a generalized feature to annotate that a message semantically belongs to a previous message or is a "child" message of a specified "parent" might be of use for this and other XEPs. For some reason, people always suggest XEP-0372 in this context, however that XEP seems unusable for that purpose to me, for various reasons: a) A XEP-0372 reference to a message or other resource doesn't and shouldn't imply that it semantically belongs to that resource or "parent" message. b) XEP-0372 allows to reference multiple resources. c) XEP-0372 does not allow to reference messages. d) XEP-0372 seems to be a client only annotation, i.e. the §2 only talks about clients to be able to implement it. Additionally XEP-0372 is rather unfinished. I really wondered how it was able to reach standards track given that it is mostly a list of todos. This also means that one could update it to address the aforementioned issues, if this is actually what the original author intended (define a new 'parent' value for the 'type' attribute, that may only exist once per message; define a way to reference messages instead of URIs or define a way how a URI references a message; ...) On the contrary, XEP-0367 does not suffer from any of these issues. It also reads way more like intended for that use. It defines the same logic regarding selection of message id as the proposed Reactions XEP. It just comes with the ugly business rule that servers may strip the <attach-to /> and that <attach-to /> must not be used for "non-messaging" payload (whatever exactly this means). Another alternative that I'd like to propose is to not mix server processing information (which this seems to be, as it's mostly intended to be used by a yet-to-be-created version of MAM) with client and message information. That would mean that this proposed XEP as well as others like LMC, Message Attaching, etc. are not directly affected. Instead, some other XEP (Could be XEP-0334, but it could also be an entirely new one) specifies a <child-of id='X' /> element that would only be used to describe the child annotation to the MAM server and nothing else. XEPs like LMC or others can than mandate that clients SHOULD attach this <child-of /> element, but not make any use of the X on the receiving end. The advantage of this approach is that it doesn't mandate client side semantics that likely will at some point cause troubles (how would a LMC of a attached message look like if both are supposed to make use of the same <reference id='X' />?) and still can create a tree of the message children. I am happy to work any of these three possibilities into a XEP (modification) proposal, if there was consensus which is best. > Backward compatibility There clearly have been opposing opinions on that matter. I believe they are partly driven by different understanding on how Reactions might be used in the wild, but I doubt there will be any way to reach consensus on a rule that mandates a specific body or its absence. That said, I support Florians suggestion to gather some implementation experience first and decide on a more specific business rule afterwards. > 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. This doesn't reflect the Reactions implementation of any other chat system I know and certainly isn't what users would expect. Second, it increases the client side complexity and number of corner cases a lot: - The correction message would have to include references to two other messages (the message being reacted on and the first reaction message) - What should happen if the correction does specify a different message to react on than the corrected message? - What should happen if the receiving client does not know the first reaction message or learns the first reaction message only later (through MAM)? - What happens if a corrected message reaction does not include a <replace /> because the sending client didn't know about the prior reaction (send from another client)? ... The only reason when LMC would make sense, is when we do have backwards compatibility and the receiving client does support LMC but not Reactions. As legacy clients tend to not support LMC either, there probably isn't a lot of use case of this after an initial introductory phase. Though with your strong opinion regarding backwards compatibility, I understand why you propose this. > Limitation to Emoji I think the current specification is open enough to allow future extension of what a reaction is. For now unicode emoji seems to be enough. 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. Clients not supporting these new extension would than just ignore those Reactions, but display any other by the same sender (at least according to the current XEP proposal). 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 😉. Cheers, Marvin
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
