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 _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
