On Thu, 2024-12-19 at 08:41 -0500, Stephen Paul Weber wrote: 1. I don't think that "changing body to be empty" conveys the same semantic meaning as "retracting a message". A client might decide to display both similar or they might decide to display them different. 2. XEP-0308 by specification only applies to the previous message (whatever that means in practice), XEP-0424 may be used to retract any previous message, no matter how many messages have been written since. 3. XEP-0424 retracts any kind of message, e.g. it can also be used to retract a XEP-0447 file share message that doesn't have a body. If the element you want to retract is not the body, there might be no logical "empty state" that could be used as part of a XEP-0308 correction. 4. XEP-0308 also states that it must not be used to "change the nature of a message". As for my understanding, retracting a message changes its nature. 5. One could even argue the opposite: XEP-0308 is a subset of the functionality of XEP-0424 combined with XEP-0203: It retracts the old version of the message and replaces it with a new message that gains a historic timestamp / position in the chat. Nonetheless, I think it could be a good idea to state in XEP-0424 that it might be sensible to include a better fallback with the message, that is, if possible, use XEP-0308 to change the body of the previous message to "(retracted)" or similar. XEP-0359 origin-id is not the same as message@id. message@id can only be used in MUCs if the MUC has the #stable-id feature announced. What both have in common though, is that they are sender-decided. This means there can be duplicates of those ids. If there can be duplicates, it needs to be specified what to do in case a retract matches multiple messages. Not saying that's not possible, but I question if that really reduces complexity over just using the room-wide unique id from the stanza-id. Marvin

On 19 December 2024 15:41:37 GMT+02:00, Stephen Paul Weber <singpolyma(a)singpolyma.net> wrote: I disagree. 1. There is no mention in XEP-0308 of retracting messages or the potential implications of doing so. Simply removing the text is a hack and not mentioned in XEP-0308 AFAIK. 2. The semantics are different. Retractions are not corrections. For example, in Converse, we show previous versions of a corrected message, which we don't for retracted messages. Servers may choose (and some do) to deal differently with retracted messages versus corrected ones. 3. XEP-0308 only specifies correcting the last element, this one allows you to retract older ones as well. 4. This XEP mentions tombstones, which XEP-0308 doesn't and there is no need for them in XEP-0308, so logically, just based on that last point, this XEP isn't a subset.

On 2024/12/23 07:44, Nicolas Cedilnik wrote: <snip> In the introduction is written: "Due to the federated and extensible nature of XMPP it's not possible to remove a message with full certainty and a retraction can only be considered an unenforceable request for such removal. Clients which don't support message retraction are not obligated to enforce the request and people could have seen or copied the message contents already." In example 4 there is already a `<fallback>` element. Concerning setting the body to "/me retracted this message", using `/me` is a nice touch, but the rest doesn't make sense to me, since that is not the message being retracted, but rather a previous one, and non-supporting clients have no way of knowing which one that was. So I think it can only be something like "/me retracted a previous message, but it's unsupported by your client." JC

On 2025/01/18 10:46, Nicolas Cedilnik wrote: This is clever, but then what about clients that support neither retractions nor corrections? In this case you'll see the message that should have been retracted as well as an additional /me message and it won't necessarily be clear that the /me message applies to a different message further up in the chat history. For example: JC: I prefer XEP-0136 to XEP-0313 Dave: I can't believe what I just read. ** JC retracted this message Potential remedies: * Change to "/me retracted a message" (instead of "this") * Make the <body> empty instead Given that the <retract> is used as a fallback, shouldn't that be indicated inside the fallback element? For example: <message type='chat' to=&#39;lord(a)capulet.example&#39; id='retract-message-1'>   <retract id="wrong-recipient-1" xmlns='urn:xmpp:message-retract:1'/>   <body>/me retracted a message</body>   <replace id='old_msg_id' xmlns='urn:xmpp:message-correct:0' />   <store xmlns="urn:xmpp:hints"/>   <fallback xmlns="urn:xmpp:fallback:0" for="urn:xmpp:message-retract:1">     <body />     <retract xmlns="urn:xmpp:message-retract:1" />   </fallback> </message> You mean for MUCs? For 1:1 the message id is used.

Hi, On Tue, 2024-12-24 at 10:52 +0000, Dave Cridland wrote: I think what you wrote does not reflect what is written in the XEP: - if a message is of type 'groupchat' -> Use "the ID assigned to the stanza by the group chat itself"   - for MUCs, that means to use the XEP-0359 <stanza-id> from the MUC - if a message is of any other type -> Use "<origin-id> if present, or the value of the 'id' attribute on the <message> otherwise" So there is absolutely no requirement for <origin-id>, there is only a requirement for MUCs to assign a <stanza-id>. Regarding XEP-0308 "handles this fine without the use of origin-id", what I wrote in an earlier mail applies: The id in XEP-0308 serves a different goal. It's not meant to be used to identify the message in the history, it's meant to ensure that both entities have the same understanding of which the last message is, so that if for whatever reason the message ends up out of order or at a different client than expected (e.g. recipient client goes offline and message is routed to another resource instead), it won't be misunderstood to edit an unrelated message. The risk of collision is significantly less in that case. Marvin

Why mentioning origin-id at all, and not simply write Clients SHOULD use a message-id that conforms to Unique and Stable Stanza IDs (XEP-0359) <https://xmpp.org/extensions/xep-0359.html> [4 <https://xmpp.org/extensions/xep-0424.html#nt-idm45702685434944>] on sent one-on-one "chat" messages to make them suitable for message retraction. Meaning *not* adding origin-id, rather putting an id that conforms to whatever origin-id should be into the message id attribute. Then we don't have to deal with yet another id, and if we receive a retraction request, we know the client implements 0424 and therefor knows to use unique ids. Regards Philipp On Tue, Dec 24, 2024, at 16:26, Dave Cridland wrote:

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

On Sat, 18 Jan 2025 at 07:35, JC Brand &lt;lists(a)opkode.com&gt; wrote: If an abusive message is retracted, and the service actually excises the message entirely from the archive, replacing it with a tombstone, then there's no record of the abusive message (but it's been seen by its target, and so has done its job). So, for example, I send a message saying something highly abusive such as "JC Brand prefers XEP-0136 to XEP-0313" to xsf@ and then after you've seen it and understandably been shocked to your very core, and then I retract the message, it'd be sensible if the moderators could examine the archive, find the message, and uphold your complaint - rather than my retraction disposing of the evidence. Does that make more sense? Am I misreading the intent of tombstones there (and, therefore, could this be made clearer?) Dave.

On Sat, 18 Jan 2025 at 17:18, JC Brand &lt;lists(a)opkode.com&gt; wrote: This feels like a useful thing to point out, and the text seems good to me, thank you. Dave.

Thanks everyone for their reasoned comments and feedback. I'll remove the reference to origin-id. On 2025/01/13 11:34, Daniel Gultsch wrote: