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

Hi, On Tue, 2024-12-24 at 17:12 +0000, Stephen Paul Weber wrote: The sending user might use multiple clients, where one of the clients does create globally unique IDs and the other doesn't. If you don't want to propose that one can only retract a message from the same device that sent it (which might be reasonable to assume for the XEP- 0308 usecase), this would mean the retract-sending client can't know if a message id attribute is globally unique or even unique within the retraction scope. In group chats, there is no guarantee that the ID attribute is preserved when it's routed through the group chat server. In XEP-0045 v1.31 the requirement was added to use the same ID in the reflection "to allow clients to track their outbound messages". While in practice, many MUC servers nowadays will just use the very same ID as sent by the sending client and forward it to all recipient clients, those implementations are also not compliant to RFC6120 and to make messages identifiable, they add a unique stanza-id. Speaking about XEP-0308: I checked multiple client implementations, including Choegram Android, and in cases where origin-id is present and mismatches the message id attribute, they will actually divert from the specification and use the origin-id for corrections (both incoming and outgoing). On top of that, most clients handle id duplicates for last message correction in the obvious correct way for the context (that is: the newer message with the same id is corrected, because that's the one that's closer to being the last message). This shows that the XEP-0308 procedure might be suitable for last message correction (because there is a reasonable way to resolve ID duplicates), but is not for retraction (which is meant to work reliably for every message, even those sent from other clients and through a MUC). Marvin