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