[Standards] Proposed XMPP Extension: MAM Fastening Collation

Dave Cridland dave at cridland.net
Thu Jan 2 17:23:02 UTC 2020


On Thu, 2 Jan 2020 at 15:56, Marvin W <xmpp at larma.de> wrote:

> With an updated version of the reactions XEP, it would indeed work for
> (non-encrypted) reactions to have the number of reactions, though it
> leaves open what happens if the same entity has two fastenings with the
> same summary. For reactions, those shouldn't be counted twice for
> reactions, but maybe they should be for a different protocol.
>
>
Yes, the intent here is that fastenings define themselves such that they'll
summarize neatly.

It's not clear to me whether sending two poop emojis should count as two
reactions or just one. (Surevine once had an internal product that, by
accident, allowed "multilikes". We liked it. Often more than once)

As things stand, we're effectively defining that people can like (or poop
emoji) other messages as many times as they like.

MAMFC is fairly light on processing updated and removals, but it should be
doing so - there's one for the TODO list.


> For the proposed edit summary, I see the issue that i typically like to
> know the timestamp of the original message and the timestamp of the last
> edit (though it's not important to know the original message body). I
> don't see how this is supposed to work with the proposed XEP. Also there
> is no way to check *who* did the edit and if servers are implementing
> this dumb, they'll allow anyone to edit a message.
>
>
Seems reasonable to include a timestamp here, and it should certainly
include the sender - good spot, and again one for the TODO list.

In general, the "edit" case (as with any retraction case and others) is a
little shaky here because of authorisation. I'm very much open to ideas
here - it might be sensible to have a switch like the "external" which
pulled in the stanza from attribute, for example, or we might simply choose
to have servers "know" about edits (but see below).


> Also note that the edit proposed in this ProtoXEP is not really
> compatible with the edit proposed in the fastening XEP
> <https://xmpp.org/extensions/xep-0422.html#external-payloads> as it is
> completely unclear what is supposed to happen with the <external
> name="body"/>.
>
>
Yes, quite, these need pulling into the fastening summary if they exist
(ie, they're not being pulled in from the encrypted blob). Totally happy to
make that clear.


> Also you mention delivery receipts and char markers. I think you are
> overly simplifying what those are being used for. For example chat
> markers in group chats are sometimes displayed as the position where
> users are with reading (like this <https://imgur.com/qZwXT75>). This
> seems to be rather impossible with your proposal (and seems to be what
> XEP-0333 was original intended for).
>
>
In a chatroom case that might be tricky. It's possible that we simply
cannot do anything useful with chat markers in that sense, and should just
include them in the main archive. (Or both, even).

FWIW, we use Chat Markers as super-receipts only, so I may have a blind
spot there.


> I also don't like that if I have a shell fastening, I only get to know
> that there are fastened messages. If there is 20 edits and one reaction
> and I want to know who send this reaction, I shouldn't be requires to
> download the 20 edit fastenings (using your proposed "fastenings" MAM
> call). I think all <applied> elements should carry the id of the
> underlying message from the archive, so that I can specifically fetch
> those.
>
>
Shell fastenings are for encrypted cases, so the server simply cannot tell
what these are and has no way to tell, by design. This was specifically to
satisfy cases where "everything must be encrypted".

We could have MAM filter the responses to match a particular fastening type
or summary which addresses your precise use-case there. However, in the
case where we really wanted a count, including all the fastenings seems
counterproductive.


> 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-mam
> (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 - 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.

I'm entirely open to tweaking this back and forth to get a better result,
but I would argue very strongly against having every fastening type declare
special rules. I'd rather take a while to see how various things would
work, and take a view on whether we should support them or not.


> All in all, this seems still rather unfinished and I fear that a
> functional version of MAM-FC as well as more use cases popping up will
> require further changes to fastening, further delaying all XEPs relying
> on it from becoming production-ready.
>
>
It *is* unfinished - of course. It doesn't even have a XEP number (though
it does have a schema etc already).

But I think the shape of it is sufficient for people to implement, even if
it might not do quite what we want yet.

In any case, your comment would apply to absolutely any proposal in a
similar space, so I'll treat this as "no action required".


> Just to come up with a new potential idea that would be hard to
> impossible to realize with your proposal: Clapping; on a popular blog
> platform you can clap for blog posts. Every user is entitled to up to 50
> claps on a blog post, but you can't undo claps. Usually only the total
> number of claps is displayed, but there is a detail view where you can
> see which persons clapped and how often.


Right, so, how would this work with MAMFC as written.

So, users can clap on a message - OK, so we have a fastening type of
<clap/>. This summarizes to <clap/>, and has a full fastening of <clap/>,
so that's trivial for MAMFC so far.

The total number of claps is shown, which again is fine for MAMFC.

Our problem is that each user can only clap 50 times, so one assumes that
in a chatroom of 10 users, the maximum clappage can be 500? (or 450, if one
cannot clap oneself, which is at least gauche...). MAMFC cannot currently
enforce that, you'd have to enforce it client-side, or by introducing a
blog service which mediating clapping.

But equally, it would have to be enforced somewhere, and to enforce it
inside MAM would mean it would have to be enforced in code on every users'
server who participated.

If we ignore the limit, it becomes trivial - if we have "undo" claps, then
I think MAMFC should be able to handle that, though I've not specified that
yet because I was slightly ahead of Kev's XEP-0422 update. But I will do.

So, summary: We cannot do your clap proposal with MAMFC, nor with any
similar system which doesn't involve either hardcoding the support in every
server or including an arbitrarily complex summarizer DSL code fragment
alongside every fastening.

Is this a problem?

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200102/0c58406e/attachment-0001.html>


More information about the Standards mailing list