* 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.
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.
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.
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.
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.
Georg
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
