> 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.html1. 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.
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
