5 Sep
2026
5 Sep
'26
8:53 a.m.
Hi Daniel,
thanks for bringing up the points, I think this actually reveals a
deeper issue with the UX of the XEP, which is not adequately covered by
its Business Rules or its Security Considerations. In fact, we might
want to introduce a new top-level chapter into the XEP template to cover
Usability and mitigation of potential abuse.
* Daniel Gultsch <daniel(a)gultsch.de> [2026-09-04 11:33]:
Edits often have history (On Mastodon, on github
comments, on Signal,
in Conversations 2.20.2) while with deletes people usually don’t want
to have access to previous versions.
[from the other email of yours]
I see the reason why one would like to delete messages
one sent. I see
extremely few use cases where I would allow third parties to delete
messages they had sent to me. On the contrary I see multiple ways in
which this can be abused or cause harm in other ways.
Storing a recipient-side edit/retraction history is the only reasonable
way to cover harmful / abusive messages - once they were delivered to at
least one of the recipient's clients, that is. In fact, that would
actually be an argument for keeping the original message in MAM, instead
of replacing it with a tombstone.
There is obviously a highly important design trade-off between the
interest of the sender (oops, I disclosed a secret to the wrong person)
and the recipient (I don't want abusive messages to disappear, leaving
behind no evidence). I think that LMC (or, well, AMC) is a very
reasonable resolution to that trade-off.
For sure it is a much better trade-off than allowing the sender to
delete an abusive message right after it was seen by the recipient, and
I guess it is also a better trade-off than leaving an inadvertently
disclosed secret visible for all time (but still accessible with a few
clicks). In fact, given that there is no *guarantee* that '424 will
delete the message (as clearly stated in the XEP), any secrets need to
be considered as compromised anyway.
The '424/'308 use case is distinctly different from the '425 Moderated
Message Retraction use case, where the moderation decision was made by a
third party, which is supposed to not be collaborating with an abusive
sender.
Ultimately, I think that the same business rules should apply to both
'308 and '424 - it doesn't make UX sense to give a longer period for
retractions than for edits, and vice versa.
If you look at clients that actually implement Any
Message Correction
the 15 year head start melts away.
Do you mean "Any" as a synonym to '308/LMC, or are you specifically
speaking of clients that have looser restrictions on which messages they
allow to be corrected?
That said, do you have any data on how many clients have / have not
melted away between LMC and '424?
Georg