On 7/3/26 14:15, Daniel Gultsch wrote: Disclosure, I'm one of the authors of the XEP. Yes. Even if retractions cannot be guaranteed in an open, federated network, they do still indicate intent. And in closed deployments they can be fully implemented and enforced. Yes I've implemented it in Converse. Nothing beyond what's documented already. Yes.

No Yes No. Message correction suffices and is more flexible. No Yes

On Fri, 2026-07-03 at 12:15 +0000, Daniel Gultsch wrote: Yes. The intent and semantics of retracting is clearly different from message edit/correction and receiving entities might be willing to handle them differently. Yes. Yes, already implemented in non-release version of Dino. No. (except what is made very explicit in the specification already) Yes.

* Daniel Gultsch &lt;daniel(a)gultsch.de&gt; [2026-07-03 14:16]: Yes. Yes. Yes. No. 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!). 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. §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. 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. 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? 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. 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. Thanks, Georg

On Fri, Jul 3, 2026 at 2:15 PM Daniel Gultsch &lt;daniel(a)gultsch.de&gt; wrote: […] Yes Yes No. Maybe as an opt-in at some later point. 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. I think the time limit can make the impact of those things a little less severe but on principle they are still there. No. I have major concerns with the feature itself but none that can be fixed in the XEP or via technical means (aside from the optional time restriction that has luckily already made it into the XEP) Yes.