* 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!). 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