Thanks for the feedback. I don’t want to ignore this, but was trying to digest bits.
> On 12 Dec 2019, at 12:10, Marvin W <x...@larma.de> wrote: > > On 12/11/19 6:50 PM, Kevin Smith wrote: >>> The business rules in §4 say that a Fastening can not have a Fastening >>> themselves. If both message attaching, reactions and others are realized >>> using Fastening, this implies that you can not react to an attached >>> message, for example you would not be able to thumbs-up the fact that a >>> bot provided a helpful attaching. While it is arguable that this is not >>> strictly a required feature, the restriction seems to be unreasonable in >>> that case. >> This one was deliberate - reacting to reactions to reactions (and similar) >> is the sort of scenario that it’s easy to spec, but then generally horrific >> to implement (I refer to pubsub collections as a simpler example of where a >> similar concept seems pleasantly general but ends up being overcomplicated >> to work with - to the point of neglect). > > I think the question this comes down to is, what we want to build using > fastenings. I don't want reactions to reactions, but if we allow some sort of > "comment" as a Fastening, then we should also allow reactions to such > comments. > If we keep this restriction, I believe we'd need a generic standard for > associating a message to another message, independent of it being a fastening > or another kind of message (that can have fastenings). I think we’re moving on this later in the thread. > Also one of the reasons why everyone agreed it would help to have the > fastened elements as a sub-element of the <apply-to> instead of directly in > the <message> as in XEP-0367, is that if we don't do that, it isn't clear how > to handle the correction of a message attaching case (a fastening of a > fastening). Thus if we decide against allowing fastening of fastenings, the > decision to use sub-element and <external> etc should be revisited... > >> I think <apply-to> can contain multiple elements, and they’re treated >> independently >> So if you apply-to two elements, and then replace apply-to one element, it >> would replace the relevant one, leaving the other intact. If you then >> replace apply-to both elements, it would replace both of them. This is >> under-(not at all) specified. >> For <external/> elements, it should be the target name/namespace, as if it >> was a child. > > How are edits supposed to work then? Because for various (good) reasons they > exist of multiple elements in the example. > https://xmpp.org/extensions/xep-0422.html#example-4 I need to go back and work through examples. I’m not immediately sure that what I was saying didn’t make sense. If you have multiple elements in an apply-to, you would replace them by specifying the replacement of the particular element (or elements) you wanted to replace. Am I missing the point? > >>> What happens if a client accidentally does not add the `replace="true"` >>> (for example because the same element was send from two different >>> devices at about the same time)? Will a) there be two elements with the >>> same namespace and name then, b) the second silently ignored or c) the >>> first silently replaced? In case of a), how to decide which to replace >>> in the future? In case of b), how does the sending entity know if there >>> message was first or second? In case of c), why put `replace="true"` at >>> all if it is implicitly done anyways? >> Is it sufficient to assert that protocols that want to attach multiple of >> the same namespace then can’t replace them, or do we need ids on the >> fastenings? >> I guess if we have 😂 and >> 🤦🏻♂️ as individual fastenings, we need to be able to remove one and leave >> the other intact. OTOH, if a fastening contained one reaction for both 😂 and >> 🤦🏻♂️, it could be replaced with a reaction with just 🤦🏻♂️. > > I don't quite understand what you want to say here. If each reaction is a > separate fastening, how do you remove a single one if you only identify > reactions by their qname. That’s what I was saying, I think. If we were to treat multiple reactions as multiple fastenings, we would need to introduce new mechanisms. If we were to treat all reactions as one fastening, we wouldn’t. > Also it apparently is currently specified how to replace but not how to > remove a fastening. Replacing with an empty variant may be technically > possible, but that empty variant would then still be required to send out to > clients (because we don't want servers to have to know what an empty variant > looks like for each fastening). I’d made a note that removal isn’t specified, yes. I’ll address this. >> I have assumed that if you’re doing full stanza encryption, and want >> archiving, your only choice as things stand is to have a complete download >> of your archive, and to do all collation locally. Having both smart >> archivability (without decryption) and encryption is a more or less >> unsolvable problem. >> Does anyone have a workable way to go beyond ‘archive can’t be smart’ with >> E2E? > > It depends on how "smart" your archive should be. Just attaching a message to > another message does work perfectly fine with encrypted messages, but you can > obviously not summarize them. > > What does not work with encryption is to know the qname of the element. And I > think it would be desirable to not leak that for the sake of smarter > archiving (so that it cannot be seen if I react to a message or just mark it > as read), so if we can come up with something that makes this not required, > that would be great. It could even be that this can not work well with race > conditions (= you have to have received the last encrypted reaction before > you can send a new encrypted reaction and if you didn't, others will always > have to fetch both just to find out that they only needed one after > decrypting). > > By the way, I can hardly imagine summarizing to work in a generic way. The > only thing that makes sense to me is to have the procedure to summarize a > certain fastening defined with that specific fastening (e.g. in the reactions > XEP for reactions) and not generically. This also implies that servers may > not be aware of how to summarize certain fastenings and thus clients would > always have to be ready to ask for the raw messages for these if they want to > display them (obviously servers should announce via disco which they do > support). I think I’ve covered, or at least started a discussion on a proposal for, this later in the thread. > > ---- > > As a general remark, I think it makes sense to think about what this generic > feature should cover, so we can correctly model at least those usecases. > > The XEP itself mentions: > - Message edits: only added by original author (and maybe moderators?) only > the last one is relevant, but history is likely to be needed in some cases > - Link information: one for each link attached by author or server, but > should be removable by the author if automatically generated info is crap > - Emoji reactions: each user can add, all that remain active are relevant, > but can be summarized as it's not that relevant *who* reacted in first place. > > Outside the XEP we have mentioned: > - Message retraction (XEP-0424): only one per message, by auther or server > - Adding markup (references proposed by ralphm in his blog): not sure about > this one in general, seems to me more like an edit that doesn't need special > handling. > - Received/Read markers: each user can add, there can only be one per sender > > Do we have others, should we maybe start a wiki page or something to collect > them? We certainly need to think about this. I’ll try to think of some and note them somewhere. (I don’t necessarily think all the above are sensible with fastening, but will try to make a list). /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
