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 name="body"/>. 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 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). 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. Marvin _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
