LAST CALL: XEP-0424 (Message Retraction)
This message constitutes notice of a Last Call for comments on XEP-0424. Title: Message Retraction Abstract: This specification defines a method for indicating that a message should be retracted. URL: https://xmpp.org/extensions/xep-0424.html This Last Call begins today and shall end at the close of business on 2025-01-06. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
On 19 December 2024 11:21:07 GMT+02:00, Daniel Gultsch <daniel@gultsch.de> wrote:
This message constitutes notice of a Last Call for comments on XEP-0424.
Title: Message Retraction Abstract: This specification defines a method for indicating that a message should be retracted.
URL: https://xmpp.org/extensions/xep-0424.html
This Last Call begins today and shall end at the close of business on 2025-01-06.
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
Disclosure: I'm the XEP author.
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Yes, there is no other spec covering the use-case of message retraction.
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?
I already have since a number of years.
4. Do you have any security concerns related to this specification?
No.
5. Is the specification accurate and clearly written?
Yes.
Your feedback is appreciated! _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
This message constitutes notice of a Last Call for comments on XEP-0424.
Title: Message Retraction Abstract: This specification defines a method for indicating that a message should be retracted.
URL: https://xmpp.org/extensions/xep-0424.html
This Last Call begins today and shall end at the close of business on 2025-01-06.
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
No, it is a subset of the functionality of https://xmpp.org/extensions/xep-0308.html
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?
I have partially in some code, to interpret incoming instead of showing ugly fallbacks some clients send.
4. Do you have any security concerns related to this specification?
No.
5. Is the specification accurate and clearly written?
Yes.
For messages of type 'groupchat', the stanza's Unique and Stable Stanza IDs (XEP-0359) [4] 'origin ID' MUST NOT be used for retractions.
I find this to be an unecessarily complicating requirement of this XEP. When retracting one's own stanza there is no reason one cannot safely use one's own message@id just as we do in XEP-0308
On Thu, 2024-12-19 at 08:41 -0500, Stephen Paul Weber wrote:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
No, it is a subset of the functionality of https://xmpp.org/extensions/xep-0308.html
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.
For messages of type 'groupchat', the stanza's Unique and Stable Stanza IDs (XEP-0359) [4] 'origin ID' MUST NOT be used for retractions.
I find this to be an unecessarily complicating requirement of this XEP. When retracting one's own stanza there is no reason one cannot safely use one's own message@id just as we do in XEP-0308
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
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
No, it is a subset of the functionality of https://xmpp.org/extensions/xep-0308.html
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.
Rather than "change body to empty" I would do "change to not have a body at all".
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.
"While it is possible to use this protocol to correct messages older than the most recent received from a full JID, such use is out of scope for this document and support for this SHOULD NOT be assumed without further negotiation." Perhaps it is time to specify the "further negotiation" then?
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.
I submit that a message stanza without those payloads forms a logical empty state.
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.
"not to change the nature of the stanza or its metadata (e.g. correction MUST NOT be used to turn a chat message into a pubsub notification" my interpretation is that it should not move from one "nature" of message (a chat message displayed in the chat UI) to an unrelated "nature" of message (a blog update that might be displayed in a totally different part of the UI, etc). Moving from a chat message to an empty chat message seems of the same nature to me.
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.
Absolutely, the commonly implemented fallbacks we see in the wild are pretty underwealming, telling the receipient something was retracted but not what for example.
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.
It reduced complexity because I submit that every client likely to implement retraction will also be implementing XEP-0308 and as such already has code to resolve these ids, check sender, etc. Using a totally different ID requires doing similar check and updates in a second code path instead of being able to reuse this.
On 19 December 2024 15:41:37 GMT+02:00, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
This message constitutes notice of a Last Call for comments on XEP-0424.
Title: Message Retraction Abstract: This specification defines a method for indicating that a message should be retracted.
URL: https://xmpp.org/extensions/xep-0424.html
This Last Call begins today and shall end at the close of business on 2025-01-06.
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
No, it is a subset of the functionality of https://xmpp.org/extensions/xep-0308.html
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.
Hello all,
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Yes. While I agree there is some overlap with XEP-0308, this is not limited to the last message. I know that in practice, XEP-0308 works for older messages too, but the XEP title explicitly forbids it, doesn't it? Also, I believe clients could benefit, UX-wise, from treating edits (LMC) differently than retractions, e.g., hide notifications for retracted messages. And finally, tombstones are not covered by anything else, AFAIK.
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? It's implemented in slidge. I also drafted a patch for gajim a while ago, but it's still a WIP. 4. Do you have any security concerns related to this specification? Maybe the XEP is not the place for this, but I would like clients to make it explicit that this is a "convenience" feature and not a a security one. Something like "consider anything you have sent (password, credit card number…) as now disclosed, retracting the message is not enough" (words are hard). 5. Is the specification accurate and clearly written?
Yes. I have a minor concern with Example 4 and its body "This person attempted to retract a previous message, but it's unsupported by your client.". I believe using a XEP-0428 fallback indication that the body is a fallback for XEP-0424, and setting this body to "/me retracted this message" is the way to go — this is how I implemented it in slidge. ;-) -- nicoco
On 2024/12/23 07:44, Nicolas Cedilnik wrote: <snip>
4. Do you have any security concerns related to this specification? Maybe the XEP is not the place for this, but I would like clients to make it explicit that this is a "convenience" feature and not a a security one. Something like "consider anything you have sent (password, credit card number…) as now disclosed, retracting the message is not enough" (words are hard).
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."
5. Is the specification accurate and clearly written?
Yes. I have a minor concern with Example 4 and its body "This person attempted to retract a previous message, but it's unsupported by your client.". I believe using a XEP-0428 fallback indication that the body is a fallback for XEP-0424, and setting this body to "/me retracted this message" is the way to go — this is how I implemented it in slidge. ;-)
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
Hi,
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."
You can use both the fallback and a XEP-0308 <replace>, so that non XEP-0424-supporting (but XEP-0308-supporting) clients will effectively edit the deleted message. It works nicely in practice. However, this is not strictly legal by XEP-0308 if this is not the last message that was sent. Also, YMMV but retracting the last message that was sent is the most common use case, for me at least. ("oops, wrong chat" and "oops, what I just posted actually didn't make any sense, forget about it") Example stanza: <message type="chat" from="juliet@aim.shakespeare.lit/slidge" to="romeo@montague.lit"> <body>/me retracted this message</body> <active xmlns="http://jabber.org/protocol/chatstates" /> <store xmlns="urn:xmpp:hints" /> <fallback xmlns="urn:xmpp:fallback:0" for="urn:xmpp:message-retract:1" /> <retract xmlns="urn:xmpp:message-retract:1" id="old_msg_id" /> <replace id='old_msg_id' xmlns='urn:xmpp:message-correct:0' /> </message> I will be slightly more annoying to implement if we switch to using stanza-id instead of origin-id (since XEP-0308 requires message@id which is == origin-id most of the time). -- nicoco
On 2025/01/18 10:46, Nicolas Cedilnik wrote:
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."
You can use both the fallback and a XEP-0308 <replace>, so that non XEP-0424-supporting (but XEP-0308-supporting) clients will effectively edit the deleted message. It works nicely in practice. However, this is not strictly legal by XEP-0308 if this is not the last message that was sent. Also, YMMV but retracting the last message that was sent is the most common use case, for me at least. ("oops, wrong chat" and "oops, what I just posted actually didn't make any sense, forget about it")
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
Example stanza:
<message type="chat" from="juliet@aim.shakespeare.lit/slidge" to="romeo@montague.lit"> <body>/me retracted this message</body> <active xmlns="http://jabber.org/protocol/chatstates" /> <store xmlns="urn:xmpp:hints" /> <fallback xmlns="urn:xmpp:fallback:0" for="urn:xmpp:message-retract:1" /> <retract xmlns="urn:xmpp:message-retract:1" id="old_msg_id" /> <replace id='old_msg_id' xmlns='urn:xmpp:message-correct:0' /> </message>
Given that the <retract> is used as a fallback, shouldn't that be indicated inside the fallback element? For example: <message type='chat' to='lord@capulet.example' 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>
I will be slightly more annoying to implement if we switch to using stanza-id instead of origin-id (since XEP-0308 requires message@id which is == origin-id most of the time).
You mean for MUCs? For 1:1 the message id is used.
Hello, Just to clarify, this is absolutely not a blocker for me (and I don't have any sort of veto rights as you know ^^). But a nice to have.
* Change to "/me retracted a message" (instead of "this") * Make the <body> empty instead
I think both are OK, I agree that "this" is problematic. I am slightly concerned that an empty body won't work in some (all?) clients; I think Cheogram uses a white space for this reason (singpolyma can you confirm?).
Given that the <retract> is used as a fallback, shouldn't that be indicated inside the fallback element?
I think you meant <replace>, which makes sense, but that's not allowed by XEP-0428, which only allows <body> and <subject> as sub-elements of <fallback>. I don't think it's worth making XEP-0428 more complex. Maybe XEP-0424 could mention that if a client supports <retract>, other sibling elements of a <message> should be dismissed? I am not confident about this being a good idea (?).
I will be slightly more annoying to implement if we switch to using stanza-id instead of origin-id (since XEP-0308 requires message@id which is == origin-id most of the time).
You mean for MUCs? For 1:1 the message id is used.
Indeed, for MUCs. I shouldn't have mentioned it, I believe it's part of another (broader) discussion. :) -- nicoco
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Yes, absolutely!
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, already implemented in Monal: XEP version 0.4.1, urn:xmpp:message-retract:1
4. Do you have any security concerns related to this specification? No
5. Is the specification accurate and clearly written? Yes
Your feedback is appreciated! _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hey hey, On Thu, 19 Dec 2024 at 09:21, Daniel Gultsch <daniel@gultsch.de> wrote:
This message constitutes notice of a Last Call for comments on XEP-0424.
Title: Message Retraction Abstract: This specification defines a method for indicating that a message should be retracted.
URL: https://xmpp.org/extensions/xep-0424.html
This Last Call begins today and shall end at the close of business on 2025-01-06.
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Yes, I think so. On the subject of whether it could be included within the scope of "last message editing", I think that's a clear no - "changing" a message to be retracted is a very different concept, with different implications, than "removing a message".
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?
No! But only because I don't really do much client stuff. It's possible, though, and if I do need to [try to] retract a message, it'll be with this specification.
4. Do you have any security concerns related to this specification?
Always! I think in this case the Security Considerations are quite light. In particular, there is no discussion of how a message might be deliberately retracted as a form of abuse - this is perhaps worst in cases where the tombstone support is implemented. In general, I think any specification which seeks to "change history" ought to have this as a consideration.
5. Is the specification accurate and clearly written?
Yes. 6. Do I think it gets everything as right as can be before we set it in stone? I'm curious about the use of origin-id here. I thought from previous discussions we'd decided that origin-id only had value within certain MUC cases; whereas the origin-id is explicitly only for 1:1 messaging here. Does this mean any message to be retracted has to use an origin-id, and (therefore) a client must send all 1:1 messages with an origin-id? Do we want to make it use the stanza id attribute instead? If not, why not? It seems that XEP-0308 handles this fine without the use of origin-id. What do existing clients do? Do they all really inject an origin-id for this one case (are there any others?) Dave.
Hi, On Tue, 2024-12-24 at 10:52 +0000, Dave Cridland wrote:
I'm curious about the use of origin-id here. I thought from previous discussions we'd decided that origin-id only had value within certain MUC cases; whereas the origin-id is explicitly only for 1:1 messaging here. Does this mean any message to be retracted has to use an origin-id, and (therefore) a client must send all 1:1 messages with an origin-id?
Do we want to make it use the stanza id attribute instead? If not, why not? It seems that XEP-0308 handles this fine without the use of origin-id.
What do existing clients do? Do they all really inject an origin-id for this one case (are there any others?
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
On Tue, 24 Dec 2024 at 15:09, Marvin W <xmpp@larma.de> wrote:
Hi,
On Tue, 2024-12-24 at 10:52 +0000, Dave Cridland wrote:
I'm curious about the use of origin-id here. I thought from previous discussions we'd decided that origin-id only had value within certain MUC cases; whereas the origin-id is explicitly only for 1:1 messaging here. Does this mean any message to be retracted has to use an origin-id, and (therefore) a client must send all 1:1 messages with an origin-id?
Do we want to make it use the stanza id attribute instead? If not, why not? It seems that XEP-0308 handles this fine without the use of origin-id.
What do existing clients do? Do they all really inject an origin-id for this one case (are there any others?
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"
Ah, I see this in 5.1, but the third para in section 3 says origin-id. So maybe fix that para?
So there is absolutely no requirement for <origin-id>, there is only a requirement for MUCs to assign a <stanza-id>.
Also 5 says that clients SHOULD put in an origin-id "to make them suitable", and that's certainly a requirement (albeit not an absolute one).
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.
Gotcha, though in either case, it's the same client that {retracts|edits} the message as has sent it (and presumably chosen the id), so if it cannot figure out a sensible strategy for generating ids, it presumably can't generate origin-id's any easier. Or is there some other reason why origin-id is less prone to collision? Overall, then, I'd rather strip origin-id from the spec. Dave.
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:
On Tue, 24 Dec 2024 at 15:09, Marvin W <xmpp@larma.de> wrote:
Hi,
On Tue, 2024-12-24 at 10:52 +0000, Dave Cridland wrote:
I'm curious about the use of origin-id here. I thought from previous discussions we'd decided that origin-id only had value within certain MUC cases; whereas the origin-id is explicitly only for 1:1 messaging here. Does this mean any message to be retracted has to use an origin-id, and (therefore) a client must send all 1:1 messages with an origin-id?
Do we want to make it use the stanza id attribute instead? If not, why not? It seems that XEP-0308 handles this fine without the use of origin-id.
What do existing clients do? Do they all really inject an origin-id for this one case (are there any others?
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"
Ah, I see this in 5.1, but the third para in section 3 says origin-id. So maybe fix that para?
So there is absolutely no requirement for <origin-id>, there is only a requirement for MUCs to assign a <stanza-id>.
Also 5 says that clients SHOULD put in an origin-id "to make them suitable", and that's certainly a requirement (albeit not an absolute one).
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.
Gotcha, though in either case, it's the same client that {retracts|edits} the message as has sent it (and presumably chosen the id), so if it cannot figure out a sensible strategy for generating ids, it presumably can't generate origin-id's any easier. Or is there some other reason why origin-id is less prone to collision?
Overall, then, I'd rather strip origin-id from the spec.
Dave. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Gotcha, though in either case, it's the same client that {retracts|edits} the message as has sent it (and presumably chosen the id), so if it cannot figure out a sensible strategy for generating ids, it presumably can't
Precisely. When validating sender, the risk of id clashes stops beieg an issue since the sender knows they need unique IDs for corrections. So using message@id instead of origin-id or stanza-id is the way as in the correction XEP.
Hi, On Tue, 2024-12-24 at 17:12 +0000, Stephen Paul Weber wrote:
Precisely. When validating sender, the risk of id clashes stops beieg an issue since the sender knows they need unique IDs for corrections. So using message@id instead of origin-id or stanza-id is the way as in the correction XEP.
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 2024/12/24 12:52, Dave Cridland wrote:
4. Do you have any security concerns related to this specification?
Always! I think in this case the Security Considerations are quite light. In particular, there is no discussion of how a message might be deliberately retracted as a form of abuse - this is perhaps worst in cases where the tombstone support is implemented.
What kind of abuse are you thinking of here, and what exactly do you think needs to be written down? You mean like someone trying to fill a chat history with useless tombstones? This doesn't seem to me like a XEP-0424-specific concern. You don't need retractions or tombstones to spam a chat with useless messages.
On Sat, 18 Jan 2025 at 07:35, JC Brand <lists@opkode.com> wrote:
On 2024/12/24 12:52, Dave Cridland wrote:
4. Do you have any security concerns related to this specification?
Always! I think in this case the Security Considerations are quite light. In particular, there is no discussion of how a message might be deliberately retracted as a form of abuse - this is perhaps worst in cases where the tombstone support is implemented.
What kind of abuse are you thinking of here, and what exactly do you think needs to be written down? You mean like someone trying to fill a chat history with useless tombstones? This doesn't seem to me like a XEP-0424-specific concern. You don't need retractions or tombstones to spam a chat with useless messages.
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 2025/01/18 14:38, Dave Cridland wrote:
On Sat, 18 Jan 2025 at 07:35, JC Brand <lists@opkode.com> wrote:
On 2024/12/24 12:52, Dave Cridland wrote:
4. Do you have any security concerns related to this specification?
Always! I think in this case the Security Considerations are quite light. In particular, there is no discussion of how a message might be deliberately retracted as a form of abuse - this is perhaps worst in cases where the tombstone support is implemented.
What kind of abuse are you thinking of here, and what exactly do you think needs to be written down? You mean like someone trying to fill a chat history with useless tombstones? This doesn't seem to me like a XEP-0424-specific concern. You don't need retractions or tombstones to spam a chat with useless messages.
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 jobCh
Ok, so rephrase into XEPanese: If message retraction results in the complete removal of any record of the original message's body, for example to be replaced by a tombstone, then this could be used to hide messages that moderators might want to be notified of. - JC
On Sat, 18 Jan 2025 at 17:18, JC Brand <lists@opkode.com> wrote:
On 2025/01/18 14:38, Dave Cridland wrote:
On Sat, 18 Jan 2025 at 07:35, JC Brand <lists@opkode.com> wrote:
On 2024/12/24 12:52, Dave Cridland wrote:
4. Do you have any security concerns related to this specification?
Always! I think in this case the Security Considerations are quite light. In particular, there is no discussion of how a message might be deliberately retracted as a form of abuse - this is perhaps worst in cases where the tombstone support is implemented.
What kind of abuse are you thinking of here, and what exactly do you think needs to be written down? You mean like someone trying to fill a chat history with useless tombstones? This doesn't seem to me like a XEP-0424-specific concern. You don't need retractions or tombstones to spam a chat with useless messages.
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 jobCh
Ok, so rephrase into XEPanese:
If message retraction results in the complete removal of any record of the original message's body, for example to be replaced by a tombstone, then this could be used to hide messages that moderators might want to be notified of.
This feels like a useful thing to point out, and the text seems good to me, thank you. Dave.
Hi JC and others, council feels strongly that this document should get rid of its use of orgin-id and instead use the message@id for 1:1 chats.¹ This is in line with a general consensus I feel in the community that we should get rid of origin-ids everywhere except for the niche purpose of tracking reflections in MUCs that do not announce #stable_id This means no XEP should refer to or make use of origin-id. There are obviously other XEPs that need to be modified including of course XEP-0359 itself. The jury is still out on whether stanza-ids or message@id should be used for retractions in MUCs. Community feel free to discuss this in the comments. Personally I’m leaning towards stanza-ids (meaning leave that part as is) which would be in line with other relatively modern XEPs like reactions or displayed markers. cheers Daniel P.S.: Since most clients set message@id==origin-id when sending getting rid of origin-ids in this document should just work(tm) in practice and not require a NS bump or anything.
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:
Hi JC and others,
council feels strongly that this document should get rid of its use of orgin-id and instead use the message@id for 1:1 chats.¹
This is in line with a general consensus I feel in the community that we should get rid of origin-ids everywhere except for the niche purpose of tracking reflections in MUCs that do not announce #stable_id
This means no XEP should refer to or make use of origin-id. There are obviously other XEPs that need to be modified including of course XEP-0359 itself.
The jury is still out on whether stanza-ids or message@id should be used for retractions in MUCs. Community feel free to discuss this in the comments.
Personally I’m leaning towards stanza-ids (meaning leave that part as is) which would be in line with other relatively modern XEPs like reactions or displayed markers.
cheers Daniel
P.S.: Since most clients set message@id==origin-id when sending getting rid of origin-ids in this document should just work(tm) in practice and not require a NS bump or anything. _______________________________________________ Standards mailing list --standards@xmpp.org To unsubscribe send an email tostandards-leave@xmpp.org
On 2025/01/13 11:34, Daniel Gultsch wrote:
council feels strongly that this document should get rid of its use of orgin-id and instead use the message@id for 1:1 chats.¹
I've created a pull request which implements some of the Last Call feedback. https://github.com/xsf/xeps/pull/1419 * Use a XEP-0425 /me command in the fallback body * State that a tombstone's <retracted> element's 'id' attribute should match the retraction message's 'id'. * Specify XEP-0359 as a dependency and require that the stanza 'id' be used instead of the origin-id. * Update the "Security Considerations" to mention the risk of not being able to uniquely identify which message should be retracted when retracting messages from clients that don't support XEP-0359. Concerning the <origin-id> debate: One benefit I can see from using <origin-id>, is that if you're retracting a message from a different client (as larma wrote about), and there is no <origin-id>, then you are at least made aware that there's no guarantee that it will be possible to correctly identify which message should be retracted. A client could then choose not to allow retractions, or otherwise inform the user about the issue. Without <origin-id>'s, a client could do a disco query to check for support, but the other client might be offline, so this is not foolproof. I've updated the Security Considerations to mention this issue, which to be fair is an issue regardless of whether <origin-id>'s are used or not. JC
Hi, On Thu, Dec 19, 2024 at 10:21 AM Daniel Gultsch <daniel@gultsch.de> wrote:
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?
I’m unsure tbh. Obviously there is some user demand so probably yes in some form or another however it feels super weird to essentially be able to delete my half of a conversation with a friend even weeks or month after the fact. For my personal implementation I would probably put some kind of limit on that. Signal seems to be using 30 mins which at least from the order of magnitude feels OK. However if there is no suggested limited and no way to discover that in the XEP than different clients may pick very different limits (ranging from none to 5 seconds) I’m not talking about a security issue (I’m very well aware the security considerations say: There is no guarantee). I’m talking about a weird UX. So to go back to the first question: Does this fill a gap in the protocol. Yes I guess. But not exactly the gap that I would have wanted to be addressed.
4. Do you have any security concerns related to this specification?
I have some concerns with regards to the fallback message. If you deliberately put some completely unrelated content into the body clients that support retractions will render that very differently (meaning not at all) from clients that do support retraction. This can especially be a problem (and this depends on the implementation) if the retraction is for a message that simply doesn’t exist. I’m worried that some clients will then not render anything. I have similar concerns with reactions, display markers and receipts and I have "fixed" this in Conversations. https://codeberg.org/iNPUTmice/Conversations/commit/cd46067681c23551f3a7ba3e... I admit this is far from the biggest issue XMPP had over the years but I’m still considering it a weird side effect. Especially now that I have mentioned the downside of fallbacks for reactions I’m unsure what the real upside is: With the suggested default of "the user has retracted 'a' previous messages" I’m not really sure what to do about that as a user. I don’t know which one; or if I should feel bad for the other user now or what.
5. Is the specification accurate and clearly written?
origin id is still mentioned in https://xmpp.org/extensions/xep-0424.html#usecase "In the case of a group chat message, for example Multi-User Chat (XEP-0045) [4], instead of the origin ID, the XEP-0359 stanza ID that was assigned by the group chat SHOULD be used." This should be message id Otherwise yes it is clearly written.
Le jeudi 19 décembre 2024, 10:21:07 heure normale d’Europe centrale Daniel Gultsch a écrit :
This message constitutes notice of a Last Call for comments on XEP-0424.
Title: Message Retraction Abstract: This specification defines a method for indicating that a message should be retracted.
URL: https://xmpp.org/extensions/xep-0424.html
This Last Call begins today and shall end at the close of business on 2025-01-06.
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Yes, I think it's a different use case that message correction (in Libervia, I show history for message correction, and just a tombstone for retraction).
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?
It's implemented in Libervia.
4. Do you have any security concerns related to this specification?
No more that was has already been stated.
5. Is the specification accurate and clearly written?
Globally yes. I just find that the section "The Sender MUST NOT send a retraction request for a message with non-messaging payloads. For example, a sender MUST NOT send a retraction for a roster item exchange request or a file transfer part." could state more explicitly that things like SFS (XEP-0447) can be removed, because the <body> is only a fallback there, and it's not clear if it's a messaging payload or not. With my council hat on, I'll most probably vote +1 on this one, I'm just waiting for Daniel feedback and mine above to be resolved. And in any case, thanks to the authors for their contributions.
Hi Goffi and Daniel, Thank you both for the detailed feedback. I've made a PR which addresses your feedback: https://github.com/xsf/xeps/pull/1551 Goffi wrote:
I just find that the section "The Sender MUST NOT send a retraction request for a message with non-messaging payloads. [...]" could state more explicitly that things like SFS (XEP-0447) can be removed, because the <body> is only a fallback there, and it's not clear if it's a messaging payload or not.
Agreed. The Business Rules now define "non-messaging payloads" as messages that serve as a transport for protocol signalling and aren't displayed as messages to the user. And we now state that a message that conveys user-visible content is considered to have a messaging payload, even when that content lies outside the <body> (with XEP-0447 mentioned as an example). Daniel wrote:
However if there is no suggested limited and no way to discover that in the XEP than different clients may pick very different limits (ranging from none to 5 seconds)
I've now added a way to discover a retraction time limit. An entity that enforces one SHOULD advertise a `max-age` via XEP-0128 in its disco#info response.
I have some concerns with regards to the fallback message. If you deliberately put some completely unrelated content into the body clients that support retractions will render that very differently (meaning not at all) from clients that do support retraction. This can especially be a problem (and this depends on the implementation) if the retraction is for a message that simply doesn't exist. I'm worried that some clients will then not render anything.
Good catch. The Business Rules now say that a supporting client MUST NOT display the <body> of a message containing a <retract/> element regardless of whether the body carries a XEP-0428 fallback marker or not. And also when no message matching the given id can be found. There's also a new Security Considerations section which describes the abuse you outlined: unrelated fallback content combined with an id that matches no message.
Especially now that I have mentioned the downside of fallbacks for reactions I'm unsure what the real upside is
I think the fact that someone retracts a message is potentially important information (a signal of intent that can change the meaning of a conversation) and so should be communicated to non-supporting clients. It also helps non-supporting servers to archive the message (based on the `body`).
origin id is still mentioned in https://xmpp.org/extensions/xep-0424.html#usecase [...] This should be message id
Fixed. I hereby request another Last Call round for this XEP. Thanks again for the reviews. JC On 2/4/25 18:48, Goffi wrote:
Le jeudi 19 décembre 2024, 10:21:07 heure normale d’Europe centrale Daniel Gultsch a écrit :
This message constitutes notice of a Last Call for comments on XEP-0424.
Title: Message Retraction Abstract: This specification defines a method for indicating that a message should be retracted.
URL:https://xmpp.org/extensions/xep-0424.html
This Last Call begins today and shall end at the close of business on 2025-01-06.
Please consider the following questions during this Last Call and send your feedback to thestandards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Yes, I think it's a different use case that message correction (in Libervia, I show history for message correction, and just a tombstone for retraction).
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? It's implemented in Libervia.
4. Do you have any security concerns related to this specification? No more that was has already been stated.
5. Is the specification accurate and clearly written? Globally yes.
I just find that the section "The Sender MUST NOT send a retraction request for a message with non-messaging payloads. For example, a sender MUST NOT send a retraction for a roster item exchange request or a file transfer part." could state more explicitly that things like SFS (XEP-0447) can be removed, because the <body> is only a fallback there, and it's not clear if it's a messaging payload or not.
With my council hat on, I'll most probably vote +1 on this one, I'm just waiting for Daniel feedback and mine above to be resolved. And in any case, thanks to the authors for their contributions.
_______________________________________________ Standards mailing list --standards@xmpp.org To unsubscribe send an email tostandards-leave@xmpp.org
participants (9)
-
Daniel Gultsch -
Dave Cridland -
Goffi -
JC Brand -
Marvin W -
Nicolas Cedilnik -
Philipp Hörist -
Stephen Paul Weber -
Thilo Molitor