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
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
