[Standards] Proposed XMPP Extension: MAM Fastening Collation
xmpp at larma.de
Thu Jan 2 15:56:29 UTC 2020
I have the feeling that the proposed summarizing feature is to targeted
to specific usecases and won't work good in others. Also it seems to
have practical issues if servers don't know what they are fastening
(which shouldn't be a requirement for fastening IMO).
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.
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.
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
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).
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.
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
(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).
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.
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.
More information about the Standards