[Standards] Proposed XMPP Extension: Message Fastening
jonas at wielicki.name
Tue Dec 17 17:51:10 UTC 2019
(lots of snipping going on, comment inline)
On Donnerstag, 12. Dezember 2019 17:49:20 CET Kevin Smith wrote:
> On 12 Dec 2019, at 15:08, Dave Cridland <dave at cridland.net> wrote:
> > On Thu, 12 Dec 2019 at 12:11, Marvin W <xmpp at larma.de
> > <mailto:xmpp at 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 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?
> 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.
The third case deviates a lot from the original intent of Fastening (e.g. by
allowing recursion) and covers cases for which we’re very far from having
I suggest to omit this use case from fastening if you ever get to the point
where it would complicate matters (e.g. business rules w.r.t. recursive
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards