Hi, On 19.07.19 16:52, Georg Lukas wrote: > 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.
I totally agree that a single standard for referencing previous messages for the usecase of MAM and "thin clients" would be desirable, but I'd like to stress the point that until now and as far as I know: - There is no (experimental/prototype) standard for a procedure to fetch a message and all its related resources from a message archive, so it's hard to design a XEP to be compliant with such a method. - There is no (experimental/prototype) standard to indicate a sub-relation to another message (as would be required for LMC, Attaching, Reactions). The purpose of XEP-0372 (as I read it) is exactly the opposite: it's intended to link to any resource (external or internal) from the message or a part of it. The referenced resource thus might be fetched with such the message referencing it, but fetching the referenced resource in no way implies that the message referencing it should be fetched as well (and it obviously makes no sense for external resources to assume that). XEP-0372 does not define a way to actually reference another message. §3.4 of XEP-0372 defines a way to add a reference to a resource to an existing message (or a portion of it). As an example what this could be used for: If a message contains the name of a person, a second message can add a <reference> to that message such that the name links to the JID of that person (becomes a mention as described in §3.2). (On a funny side note: If we had a way to actually do the kind of reference we need for MAM/"thin clients", we'd have to update XEP-0372 to make use of that feature for exactly the kind of messages as described in §3.4) As soon as there is a XEP that defines a way to do the kind of reference/attaching that we need for the use case of MAM/"thin clients", this proposed reactions XEP as well as LMC and others should probably be updated to make use of it. I don't think the new XEP should actually rely on other XEPs being updated and be possible to be used beside other elements that reference a message, but longterm it would be desirable to just use that reference, if only to not have the referenced message id twice in the message, which would save some bytes in storage and ensure there is no conflict. However this functionality is completely out of scope of the reactions ProtoXEP for now and the fact that we miss a feature at some other place shouldn't keep the protocol from evolving. > 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. 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>. > 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. Currently XEP-0308 is not defined for anything but the last message. Reactions might be updated later on, so XEP-0308 can not be used for that. Beside that, using XEP-0308-like message correction with the full list of reactions would not have any benefit over the updating rule defined in the ProtoXEP, as you would just have to send additional message correction element, but the behavior would be the same (beside message correction could also be used to update a fallback body). > 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. That's how literally every reactions implementation I am aware of in other messaging apps work. We are kind of replicating a feature here and not providing the same feature set people are already used to isn't exactly a good way forward. > 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. "can be displayed as a single emoji, as specified in the latest revision of the Unicode® Technical Standard #51" as it says in the ProtoXEP is actually pretty well defined. Deduplication rules might be a bit more complex, as there are multiple ways to express the same emoji in unicode codepoints (we already noticed how GTK and Android by default use different ways to create the same emoji), but it is certainly possible and expectable of a client developer to handle this. As per this description, it does not matter what your font can actually display as a singly emoji, only that it "can be displayed" as such. Also as a side note, TS#51 defines a so called RGI (recommended for general interchange) set, which is a subset of all possible unicode emojis that is shall be supported by all clients, fonts and operating systems and for compatibility, one might want to limit sending to these. Additionally, for the RGI set also defines the recommended unicode codepoints to be used for each emoji, which is the minimal fully-qualified representation. If people are interested in this I can do a write-up of the details of unicode emojis and how they *should* be used in instant messaging as per TS#51. I can also write down how to correctly do deduplication over different codepoints for the same emoji. As there seems to be some misunderstanding on how this feature is (to be) used in practice, here <https://imgur.com/rNcMDfP> is a screenshot from Slack: the two reactions highlighted in blue are the ones that I already did on this message, the number indicates how many made such reaction to that message. This shows that - Multiple reactions per message from same user is a common thing (the 16 reactions were created by only 10 users). - It would be a hell if there was fallback messages for each of these reactions (total of 16) for legacy clients. Cheers, Marvin
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
