[Standards] XEP-0424: Service discovery on the server side

Pawel Chrzaszcz pawel.chrzaszcz at erlang-solutions.com
Mon May 18 08:15:02 UTC 2020


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 <lists at 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-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200518/fac02d7d/attachment-0001.html>


More information about the Standards mailing list