19 Dec
2024
19 Dec
'24
2: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
2: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
6:41 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?
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
8:10 a.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
8:36 a.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.
9:30 a.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
3
days inactive
3
days old
5 comments
4 participants
participants (4)
-
Daniel Gultsch -
JC Brand -
Marvin W -
Stephen Paul Weber