On Thu, 12 Dec 2019 at 12:11, Marvin W <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? Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
