Thanks Marvin. I really am sorry for the delay in the reply. On 6 Sep 2019, at 23:11, Marvin W <x...@larma.de> wrote: > > Just a few things I noticed while reading this proto xep: > > In the introduction it describes "a server adding information on a link > previously posted to a chat room" as a use case of Fastening, which is > exactly a use cases of XEP-0367 (Message Attaching) as already pointed > to by Sam. Is it expected that XEP-0367 is updated to use Fastening > instead or basically be completely abandoned in favor of Fastening?
There was a discussion in Council at the time about this. It was believed (I forget who asserted it now) that Sam had said he didn’t want 367 used for the things 422 is to be used for, and we decided it was easiest to start a new spec for the sake of expediency. If we want to roll 422 into 367 or whatever, it’s probably orthogonal to getting the right protocol specced. > 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). So we could allow this, obviously, but I think there needs to be a very strong story as to why the complexity is needed before we do - I suspect that if we did allow such generality in the spec it would then be ignored (potentially in non-interoperable ways) by implementations (e.g. some implementations will end up only rendering reactions to the first layer, etc.). Is anyone working on a project that has this as a concrete requirement? > §3.3 describes a `replace="true"` attribute that can be added to > <apply-to> to indicate that a message replaces a previous message. The > rules say that it is to be decided by the namespace and name of the > child payload, which element to replace. Does that mean that an > <apply-to> must contain exactly one element? How does this play together > with <external> elements? This is a good question. Do you think this needs clarification, or is broken? 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. Shall I go ahead and update to reflect this, or does it need further discussion? > 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 see severe problems when using this together with XEP-0420 (Stanza > Content Encryption). Which content is expected to be encrypted? If the > whole stanza is encrypted, the server looses the id information and thus > can not make use of the advantage of Fastening. If we encrypt the > content of <apply-to>, the replacing logic will select the <encrypted> > element from XEP-0420 to decide which message to replace, which means > all encrypted messages would (potentially) replace each other (for > example an encrypted read marker and an encrypted thumbs up reaction). > If the encrypted content is a sibling to the <apply-to> and the > <apply-to> contains an <external> to reference inside the encrypted > content, it would leak the name of the element inside the encryption. 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? > There is a bit of uncertainty which ID to use. §3 says <origin-id> > should be used and the examples all refer to an origin-id. §4 says > <stanza-id> must be present. IMO the correct would be to use <stanza-id> > in groupchat and either <origin-id> or message id (in that order, if > they mismatch) in chat. This behavior is also described in other XEPs IIRC. I will try to address. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
