On 12 Dec 2019, at 15:08, Dave Cridland <d...@cridland.net> wrote: > > On Thu, 12 Dec 2019 at 12:11, Marvin W <x...@larma.de <mailto:x...@larma.de>> > wrote: > 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. > > > Interesting - from a syntactic viewpoint, you're absolutely right. But I > think you're entirely wrong from a protocol behaviour standpoint. So I wonder > if there's a distinction to be made between various kinds of relationship: > > * Messages that are pure ancillary messages, like a reaction. If I don't see > the reactions at all, it's not great, but probably a reasonable degradation. > Normally, I'll just want a summary on view. Sometimes I'll dig for more > detail. > > * Messages where the content of the message substantially alters another. > Edits, attachments, etc. If I don't see these at all, I've got significant > information loss with regards to the conversation - I'm not just missing out > on some additional content, I'm actually seeing different content. > > * Messages where the content relates to another. Comments, threading, > replies, etc are all closely related to another message, but they're clearly > a message in their own right. A degradation here might involve losing the > relationship rather than the message. > > I think Fastenings really only cover the first - MAM would here provide a > summary view of any fastenings. MAM doesn't urgently need to support the last > case at all. The middle case is somewhat harder - we might want to have MAM > aware of these but it would need to collate these in full - and perhaps it > even provides a unified view of a message and its edits etc? > > As a thought experiment, it'd be interesting to ask: > > 1) Are there any other "buckets" of message relationship types? > > 2) What existing relationships fit into what types? > > 3) What typical behaviours do we want to see (and thus support) on the > clients?
I agree more or less with these distinctions, and think each needs distinct handling. I do see them all as being feasibly within fastening. After a a discussion with Dave, I think the current best suggestion is that we annotate a fastening based on what type of summary is possible. This also largely aligns with Dave’s asterisks above. 1) summary=‘urn:xmpp:fastening:count:0': <xmpp:fastening:count:0':> Messages that can be counted by having the same bodies (by the archive). e.g. Reactions where you want to know at a glance that 50 people reacted with 🤦🏻♂️, 20 with 🤮. These messages are ‘pure ancillary messages’ in Dave’s above list, and so don’t themselves get fastened to. You can quick-query an archive to get the summary - you can also full-query to get the full details if you want, such as who made each fastening(reaction). 2) summary=‘urn:xmpp:fastening:full:0': <xmpp:fastening:full:0':> Messages that can’t be collated with others, but where you need them for the first message to be complete. e.g. edits. These also don’t get fastened to. These are ‘where the content of the message substantially alters another’ in Dave terms. 3) summary=‘urn:xmpp:fastening:none:0': <xmpp:fastening:none:0':> Where the new message is a new message in its own right, but that has some sort of link to a previous one. e.g. Comments (I’m not convinced that this is the right way to be doing comments, but if we did, like this). These can have their own fastenings. ‘Messages where the content relates to another’ from Dave’s list. An indivdiual fastening type would have (in the defining XEP) a particular summary approach (e.g. Reactions are always count, edits are always full, comments are always none). This lets us put a cap on the madness that ensues if e.g. you can react to reactions to reactions, while also allowing reactions to those messages that logically contain content of their own, e.g. comments. It is compatible with the previously discussed splitting of content and pointer in some manner that lets archives still return relevant fastenings in some manner while encrypted, although if the content is encrypted it will obviously be unable to count things. This is a bit more optimistic than a strawman, but may well have holes. Please drive your busses through them. Thoughts? /K
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
