Blah, I flipped 367 and 372 a couple of times here. I’m fine with using Attaching for this and not References - apply that rule whenever I screwed up the numbers.
/K > On 31 Jul 2019, at 16:58, Kevin Smith <[email protected]> wrote: > > 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] > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
