[Standards] Proposed XMPP Extension: MAM Fastening Collation

Jonas Schäfer jonas at wielicki.name
Thu Jan 2 17:33:28 UTC 2020

On Donnerstag, 2. Januar 2020 18:23:02 CET Dave Cridland wrote:
> > I played around with potential candidates for MAM-FC-like feature a lot
> > and I came to the conclusion that any generic solution for summarizing
> > is not going to work. Instead I think what does make sense is that the
> > summarizing feature happens on a per-XEP level, where each fastening
> > defines a set of summarizing rules and servers announce which server
> > side fastening summarizing they support. On top, this allows for even
> > dumber clients with smarter servers, as for example the message edit
> > could actually deliver the edited body, see for example
> > https://gist.github.com/mar-v-in/dd42833884fe671893dfcfb1f42ee6ca#smart-ma
> > m
> > (that proposal relies on the server knowing the type of the fastening
> > even in encrypted cases, which isn't really a good thing, but that's not
> > the important bit there).
> If fastenings are visible (to some degree), we can do rather a lot more
> with the server, indeed. Fastenings are specifically designed to be viable
> this way (and so if they are not, we should tweak until they are).
> But if each individual fastening type has to have code support in the
> server, that really slows down the rate of innovation. So I (and Kev, I
> think) thought that removing server knowledge would be essential.
> I'm absolutely not averse to having the client add in how a fastening
> should be summarized

I’m not sure if I’m missing something, or whether this is coming out of the 
blue. I can’t see anywhere where Marvin implies that *clients* should 
influence how Fastening works, only that each feature influences how it works 
(i.e. on the specification level).

What am I missing?

> - that was my original design actually - but we
> decided that the count + latest was sufficient for all cases. Potentially
> not ideal, but sufficient. It would be nice if we could at least make this
> the norm, since I think we run into problems if one client says to
> summarize reactions in one way and another says to do so in a different way.

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200102/cc546f84/attachment.sig>

More information about the Standards mailing list