[Standards] Re: LAST CALL: XEP-0424 (Message Retraction)

On Sat, Sep 5, 2026 at 4:54 PM Georg Lukas <georg(a)op-co.de> wrote: Under absolutely no circumstances would I want *my* server to delete random messages from *my* archive just because a third party tells it to. Clients that accepts edits for any message instead of just the last one should be fairly rare. And since 'retraction' isn’t just for the last message I don’t think the wide implementation of *last* message correct can serve as an adequate replacement. I generally don’t understand why we are trying to pretend that edit and delete are the same operation. I mean for early adopters of "retraction" it was probably kinda neat that Conversations would not show the edit history and that you could edit to a whitespace to achieve roughly the same effect. At least in practice. However if we just look at those two features without any implementation baggage they are two very distinct features. Most platforms that I know of have a history for edits but very obviously not a history for a retraction. In scenarios where deletion is consensual, for example I sent you a password for you to use, but we both agree that it should not stay in message history, we obviously don’t want a history that contains that password. And yes, I agree that public channels operate under a completely different social contract and moderation should in fact permanently delete messages without history. (Very obviously you want that CSAM to be gone and not accessible via a history viewer.) That’s why Conversations implements moderation in public channels. But not retraction. To be very clear: I’m not vetoing this XEP. It’s good that clients that want message deletion have a mutually agreed upon standard. I merely truthfully answered the question "Will you implement this XEP" with a "probably not right now". And I have fairly strong opinion that edit and delete are not the same operation. But the current XEP is fine because it does not recommend edits as fallback.