On 24 Jul 2019, at 21:00, Marvin W <[email protected]> wrote: > > 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: <snip/> > On the contrary, XEP-0367 does not suffer from any of these issues <snip/>
The intention of References was both that it could add a reference to something outside XMPP to a message (e.g. adding an image to a message) and that it could reference a message in XMPP (and, indeed, that it can do both, in order to attach an image URI to a previous message). I’m happy for these two functions to be split and work on 372 to be the basis of the ‘refer to a message’ bit (and then potentially 367 would make use of 372 when it’s attaching a reference to a previous message). So if References is removed from the running here for this, I’m not going to be opposing it at all. > 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. This bit, though, doesn’t make sense to me. If there’s a way of saying that one message is an update (metadata or data) to another message, it makes sense to me for that to be standardised and understood by both clients and servers. 372 can be the basis of this, I think. >> Correcting reactions > > There are two main reasons for me to not use XEP-0308. <snip/> I think the complexity of using 308 for this might be substantial and difficult to reason about, and a new syntax that’s just concerned with ‘I remove this thing I previously attached to the message’ might be better - probably in terms of 372. >> Limitation to Emoji <snip/> I think easier to limit it now, and expand later, once things are better understood, than to start with the extra stuff in and remove it later. That doesn’t usually work. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
