After carefully reading the current text again, I noticed that there is conflicting use of requirement keywords: - In section 3, "It's RECOMMENDED that you include fallback text in the <body/>, so that servers will archive the retraction and non-supporting clients can still indicate that there was an intent to retract." - In section 6.1, "senders MUST set fallback text that describes the retraction" I guess the intent of 6.1 is to disallow fallback text that does anything else than describing the retraction, aka. "senders MUST NOT set fallback text that describes anything beyond the retraction". That said, this doesn't make sense in security considerations: recipients can't base their security assumptions on the fact that something is forbidden for the sender through specification. I also am conflicted about the RECOMMENDED in section 3. or clarification, RECOMMENDED is the same as SHOULD, meaning there may exist valid reasons in particular circumstances to ignore this requirement. I would rather think the other way: there may exist valid reason to have a fallback in particular circumstances (e.g. in closed environments or when for some reason you know about the recipients setup, you can have a message "Upgrade to version x.y to correctly process messages in this chat"), but the default should be to not do it, especially if you consider a far future where every client implements this specification and thus no client would be using that fallback. Making a fallback a SHOULD is IMO inherently wrong. The fallbacks I have seen (and the one in the example) are telling the recipient that the sender intended to retract some message (without specifying which one) but that it didn't work because the client is not supported. Often this message is sent without encryption in an encrypted chat (causing the recipient to display a warning) and in English language (which may not be a language the recipient can understand). For the recipient user, this message is completely useless: It doesn't tell them the intended action of the sender in a sufficient way and it doesn't tell them how they can fix the situation of things not working. In practice, the only use of these fallback is to make people unhappy. [1] Dino current implementation does not send a fallback, no matter the circumstances. There seem to be absolutely no negative implications. We are considering to add a fallback body (in the realm of just "*Message deleted*") if, and only if, the deleted message is the very last message in the chat, and then we would also add a matching <replace />. This gives a good fallback UX for recipients that support XEP-0308 and a less useless fallback UX for those that support neither. Marvin [1] Anecdotal evidence from just a few days ago, in German: https://friendica.sokoll.com/display/74fe3dc8-336a-9c7e-a1dc-e0e344732034 On Fri, 2026-08-28 at 12:31 +0200, Marvin W. via Standards wrote:

On Fri, 2026-07-03 at 12:15 +0000, Daniel Gultsch wrote:

...

This message constitutes notice of a Last Call for comments on XEP-0424.

Title: Message Retraction Abstract: This specification defines a method for indicating that a message should be retracted.

URL: https://xmpp.org/extensions/xep-0424.html

This Last Call begins today and shall end at the close of business on 2026-07-20.

Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?

Yes. The intent and semantics of retracting is clearly different from message edit/correction and receiving entities might be willing to handle them differently.

...

2. Does the specification solve the problem stated in the introduction and requirements?

Yes.

...

3. Do you plan to implement this specification in your code? If not, why not?

Yes, already implemented in non-release version of Dino.

...

4. Do you have any security concerns related to this specification?

No. (except what is made very explicit in the specification already)

...

5. Is the specification accurate and clearly written?

Yes. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org

On Sat, 29 Aug 2026 at 19:17, Georg Lukas <georg@op-co.de> wrote:

* Daniel Gultsch <daniel@gultsch.de> [2026-07-03 14:16]:

...

This message constitutes notice of a Last Call for comments on XEP-0424.

1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?

Yes.

...

2. Does the specification solve the problem stated in the introduction and requirements?

Yes.

...

3. Do you plan to implement this specification in your code? If not, why not?

Yes.

...

4. Do you have any security concerns related to this specification?

No.

...

5. Is the specification accurate and clearly written?

I have detailed feedback:

§3 Use Case

| In the case of a group chat message, for example Multi-User Chat | (XEP-0045) [4], instead of the message ID, the XEP-0359 stanza ID that | was assigned by the group chat SHOULD be used.

This incomplete description should be replaced with a forward reference to §5.2 and §6.2.

| It's RECOMMENDED that you include fallback text in the <body/>, so | that servers will archive the retraction and non-supporting clients | can still indicate that there was an intent to retract.

I would strongly advise to also add a XEP-0313 LMC element to the retraction message:

<replace id='wrong-recipient-1' xmlns='urn:xmpp:message-correct:0'/>

XEP-0313 has a 15 years headstart, so there is probably quite a number of clients that support '313 but not '424 (look, the numerology is strong between these numbers!).

MAM over TINS? But I think you mean XEP-0308.

Adding LMC would have two benefits: first, it would overwrite the original (to be retracted) content with the fallback body. Second, it would render as one message and not as two messages.

That seems reasonable, though Retraction has no "Last" constraint. LMC probably should be AMC, or at least PMC.

§4 Tombstones

| replaced with a <retracted/> element which MUST include an 'id' | attribute that's set to the value of the retraction's <message/> | element's 'id' attribute [...]

This is only using @id, not <stanza-id> or <origin-id>, so it's asymmetrical to the usage in §5.2 (see below).

§5.2 Using the correct ID

| For messages of type 'groupchat', the ID assigned to the stanza by the | group chat itself must be used.

This should be extended with a forward reference to the rationale in §6.2.

I guess this is a normative "must" in "must be used" and it SHOULD be upper-cased?

The "must" is in contradiction with the "SHOULD" quoted above from §3, and with the next paragraph which describes what you MAY do if you CAN'T do what you MUST do:

| If a group chat does not support Unique and Stable Stanza IDs | (XEP-0359) [9], a client can still opt to include an <origin-id> | element in the message stanza, which can be used to refer to the | message in a retraction.

Yes, this does seem to stray from RFC 2119 to RFC 6919, doesn't it?

Using <origin-id> will only solve the problem for clients that already generate unique @id values and thus don't have the problem (aside: I'm still not convinced that <origin-id> should even exist, and if it is allowed to exist, it needs to be forced to be equal to @id). Using <origin-id> makes this XEP needlessly more complex.

I think origin-id is only of use in MUCs that don't do @id reflection, and since that's a REALLY SHOULD NOT (RFC 6919#3), we can broadly ignore them.

The rules assume that using XEP-0359 outside of MUCs is not useful. Maybe "use XEP-0359 <stanza-id/> if present and known to the retracting client" would be better?

No, because stanza-id is explicitly scoped, and we need one where the scope is known to all parties, and that seems to fit only MUC. '45 does not, of course, mandate '359, but in practice most referent specs (this, replies, reactions) reference stanza-id for MUC so it's really mandatory (RFC 6919#7). So we do have such a stanza-id in MUCs always, and in 1:1s never.

There is a certain latency between sending the original message and receiving the reflection that contains the <stanza-id> element required for a retraction. For a groupchat message sent over a bad network link or right before leaving network coverage, the user might be blocked from retracting for many minutes.

Understood, however unless the user knows they're losing network coverage, they're not going to be able to retract for several minutes anyway. Unless you can send a stanza without any network coverage at all, and if you know how, please tell me as it's very germane to my current research...

Finally, each client processing a received <retract/> element needs to perform three searches, first by <stanza-id>, then by <origin-id>, and then by @id.

All that said, I'm not sure if the benefits of using XEP-0359 for this specific use case outweigh the resulting complexity and would suggest to discuss the following approach:

Only use @id in '424, with the following business rulees:

- if a user tries to retract a message that has a non-unique @id in the time limit eligible for retraction, tell them to upgrade the other client ("This message cannot be retracted because it was sent from an outdated legacy client").

- if a client receives a retraction message for an @id that has multiple occurences, retract the last occurence.

I agree with this, but primarily because I agree with the LMC fallback, and LMC already uses @id irrespective of the MUC vs 1:1 thing, broadly mandating @id reflection.

Thanks,

Georg _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org

On Sun, Aug 30, 2026 at 1:17 AM Georg Lukas <georg@op-co.de> wrote:

I would strongly advise to also add a XEP-0313 LMC element to the retraction message:

<replace id='wrong-recipient-1' xmlns='urn:xmpp:message-correct:0'/>

XEP-0313 has a 15 years headstart, so there is probably quite a number of clients that support '313 but not '424 (look, the numerology is strong between these numbers!).

Adding LMC would have two benefits: first, it would overwrite the original (to be retracted) content with the fallback body. Second, it would render as one message and not as two messages.

I would strong advise against recommending LMC as a fallback. The semantics of edit are very different to a delete. 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. If you look at clients that actually implement Any Message Correction the 15 year head start melts away. cheers Daniel

On Sat, Sep 5, 2026 at 4:54 PM Georg Lukas <georg@op-co.de> wrote:

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.

Under absolutely no circumstances would I want *my* server to delete random messages from *my* archive just because a third party tells it to.

...

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?

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.