On Fri, 19 Jul 2019 at 15:52, Georg Lukas <[email protected]> wrote: > * Jonas Schäfer <[email protected]> [2019-07-15 17:59]: > > Title: Message Reactions > > This specification defines a way for adding reactions to a message. > > This is a long overdue feature. However, I have some principal and some > practical issues with that. > > 1. Referencing messages > > This is yet another XEP that creates its own encoding for "this message > is related to that message". With MAM and "thin clients", it is > increasingly important to be able to obtain not only a given message > from the archive, but also everything related to it, be it acks, > corrections, references, reactions or attachments. That means each > server implementation needs to know about each (client-side) XEP that > references messages, and serve data according to those relationships. > > XEP-0372 is in a rather sad state, as it attempts to do too many things > at once. I think we would win very much by moving the "this message > belongs to that message" part into its own very short XEP (or heavily > trim 0372), basically defining just one element, which is either a > companion or a wrapper around the actual payload that makes use of the > reference: > > <reference id="X" /> > > That would also make section §4.2 obsolete, which has very strong > assumptions on which IDs are the "right ones" to use, and where I'm not > convinced I fully agree with. > > General agreement here.
> 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: > > | <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. > > General disagreement here. I'm all in favour of backwards compatibility, but I'm not convinced we should burden the network with long-form descriptions of what the stanza might do if only the recipient had a client which understood it. The trouble is, this body will be sent, for example, over a push notification. And look ugly. And it'll be stored in MAM until, when, forever? It'll use bandwidth - sure, only a few octets, but still doubling or trebling the stanza size in order explicitly to handle the case where a recipient wouldn't understand the message anyway. > 2. Correcting reactions > > I think that with XEP-0308, we have a very good mechanism to do > correction of messages, and for the sake of consistency, we should make > use of that instead of inventing another one. > > General agreement. > > 3. Multiple reactions > > I'm not sure what the use-case is for allowing multiple reactions from > the same person for a single message. I think it's adding complexity and > corner cases (you need to remove all "old" reactions from a user on an > update; you need to perform deduplication), without a benefit. > > General disagreement. I know of many cases where users want to send multiple reactions to the same message. Irrespective of whether I think it's childish and silly, I'll still agree it's a desirable use case. Perhaps even because it's childish and silly, and that can be important too. > 4. Limitation to Emoji > > I'm not sure how much this makes sense. Unicode is steadily evolving, > and it's already non-trivial to determine what's a "single emoji" > according to the current rules (i.e. some fonts will auto-combine > Regional Indicator Symbol Letters into flags, while others won't). > > I think it makes sense to keep the first part of the rule, for sending > entities, but receiving clients should be able to just render whatever > they get. While this opens up a little for abuse, it will make interop > between clients running on different versions of the Unicode > specification much smoother. > Loose agreement here, but also, I suspect people will rapidly want to react in custom ways not expressible in Unicode, so we might want URls or inline media to be possible too. [image: image.png] [Apologies] Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
