[Standards] Proposed XMPP Extension: Message Fastening

Marvin W xmpp at larma.de
Thu Dec 12 12:10:15 UTC 2019


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).

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

> 
>> 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.

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 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).

----

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?

Marvin


More information about the Standards mailing list