Thanks for your response JC. There are a few more details that I think would be good to clarify.
Currently when a retraction message is processed by the server, the following criteria are used to find the original message - let's focus on 1-to-1 chat messages: - The id attribute specified in the apply-to element of the retraction message has to be the same as the id attribute of the origin-id element of the original message (required by XEP-0424). - Both messages need to originate from the same user (also required by the XEP). - Both messages need to be addressed to the same user - not required by the XEP, but it does not make sense to send a retraction message to a different user. This is done by the sender's server (outgoing message) and the recipient's server (incoming message). The operation is also done twice if there is one common server for both users. If more than one message matches the criteria, only the most recent one is retracted (replaced with a tombstone). If no messages match the criteria, no messages are retracted. The problem is that if the sender made a mistake and sent a message with an incorrect origin-id or to a wrong user, there would be no direct feedback to the sender. Do you think it is an issue? Regards, Paweł -- Paweł Chrząszcz https://www.erlang-solutions.com On Sun, May 17, 2020 at 10:14 PM JC Brand <li...@opkode.com> wrote: > Hi Pawel, > > sorry for taking so long to respond, this email didn't come up on my radar. > > On Mon, May 04, 2020 at 01:48:52PM +0200, Pawel Chrzaszcz wrote: > > ---- 8-< ---- > > > According to the XEP: "If a client or service implements message > > retraction, it MUST specify the 'urn:xmpp:message-retract:0' feature > in > > its service discovery information features". > > When should the server include this feature in its discovery > information? > > If a client sends a discovery request to the address of the main XMPP > > service, should the server response contain this feature if the server > > archives retraction messages in MAM (XEP-0313)? This should be enough > to > > satisfy the only mandatory server-side requirement of the XEP. > > Yes, I agree and will update the text to make this more explicit. > > > Another option would be to advertise this feature only if messages are > > really removed or replaced with tombstones whenever a retract message > is > > received. However, support for actual removal of messages is not > mandatory > > in the XEP. > > Yes, so for tombstones we can be more specific and let the XMPP server > advertise > "urn:xmpp:message-retract:0#tombstones" if it supports turning retracted > messages into tombstones. > > I'll update the XEP accordingly. > > > MongooseIM would replace the messages with tombstones if such > > a feature is enabled by the user. > > I think that whatever rule is chosen, the same should apply for a MUC > > service if message archive/retraction is enabled for it. > > Yes, agreed. > > Regards > JC > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
