19 Dec
2024
19 Dec
'24
10:21 a.m.
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(a)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!
19 Dec
19 Dec
10:51 a.m.
On 19 December 2024 11:21:07 GMT+02:00, Daniel Gultsch <daniel(a)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(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
2:41 p.m.
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(a)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
4:10 p.m.
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
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 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
4:36 p.m.
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. 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.
5:30 p.m.
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.
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(a)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
23 Dec
23 Dec
6:44 a.m.
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
18 Jan
18 Jan
7:12 a.m.
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
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. ;-)
9:46 a.m.
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(a)aim.shakespeare.lit/slidge"
to="romeo(a)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
19 Jan
19 Jan
4:33 a.m.
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
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(a)aim.shakespeare.lit/slidge"
to="romeo(a)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(a)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.
1:55 p.m.
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.
Indeed, for MUCs. I shouldn't have mentioned it, I believe it's part of
another (broader) discussion. :)
-- nicoco
* 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.
24 Dec
24 Dec
6:05 a.m.
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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
11:52 a.m.
Hey hey,
On Thu, 19 Dec 2024 at 09:21, Daniel Gultsch <daniel(a)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(a)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.
4:08 p.m.
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
4:26 p.m.
On Tue, 24 Dec 2024 at 15:09, Marvin W <xmpp(a)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.
5:32 p.m.
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(a)larma.de> wrote:
Hi,
On Tue, 2024-12-24 at 10:52 +0000, Dave Cridland wrote:
Ah, I see this in 5.1, but the third para in section 3 says origin-id. So maybe fix that
para?
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>.
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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
6:12 p.m.
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.
7:25 p.m.
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
18 Jan
18 Jan
8:34 a.m.
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.
1:38 p.m.
On Sat, 18 Jan 2025 at 07:35, JC Brand <lists(a)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.
6:17 p.m.
On 2025/01/18 14:38, Dave Cridland wrote:
On Sat, 18 Jan 2025 at 07:35, JC Brand <lists(a)opkode.com> wrote:
On 2024/12/24 12:52, Dave Cridland wrote:
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
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
6:24 p.m.
On Sat, 18 Jan 2025 at 17:18, JC Brand <lists(a)opkode.com> wrote:
On 2025/01/18 14:38, Dave Cridland wrote:
On Sat, 18 Jan 2025 at 07:35, JC Brand <lists(a)opkode.com> wrote:
This feels like a useful thing to point out, and the text seems good to me,
thank you.
Dave.
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.
13 Jan
13 Jan
10:34 a.m.
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.
8:27 p.m.
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(a)xmpp.org
To unsubscribe send an email tostandards-leave(a)xmpp.org
18 Jan
18 Jan
8:42 a.m.
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
4 Feb
4 Feb
3:49 p.m.
Hi,
On Thu, Dec 19, 2024 at 10:21 AM Daniel Gultsch <daniel(a)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/cd46067681c23551f3a7ba3…
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.
5:48 p.m.
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(a)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.
3 Jul
3 Jul
11:30 a.m.
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(a)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(a)xmpp.org
To unsubscribe send an email tostandards-leave(a)xmpp.org
13
days inactive
574
days old
27 comments
9 participants
participants (9)
-
Daniel Gultsch -
Dave Cridland -
Goffi -
JC Brand -
Marvin W -
Nicolas Cedilnik -
Philipp Hörist -
Stephen Paul Weber -
Thilo Molitor