[Standards] Proposed XMPP Extension: Message Fastening

Kevin Smith kevin.smith at isode.com
Thu Dec 12 17:48:46 UTC 2019


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 <xmpp at 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


More information about the Standards mailing list