XEP-Remarks/XEP-0203: Delayed Delivery

Revision as of 13:30, 28 January 2021 by Ge0rg (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This is a page for information about XEP-Remarks/XEP-0203: Delayed Delivery, including errata, comments, questions, and implementation experience.

Multiple delay tags

There are multiple hops involved in delivery of a stanza, multiple points where it may be delayed. It may even be delayed multiple times, e.g. because the users client had to resume their XEP-0198 session and their server took its sweet time to get s2s up and running.

Thus it makes sense to allow multiple delayed delivery payloads on a stanza.

Suggested order of precedence, pick the first one that's available:

  1. delay element without a from attribute or from a full JID - from the original message sender
  2. delay element from a bare JID - from a MUC (MUC history) or a user account
  3. delay element from a domain JID - server wasn't able to forward message immediately
  4. Forwarded message: <forwarded>'s delay element] - messages from MAM or Carbons
  5. Forwarded message: message payload: outer message's delay element] - fallback for when the forwarder didn't add a timestamp
  6. Local timestamp taken on receiving the message

Missing from attribute

A stanza sent without a from attribute implies from=senders full JID. Applying the same to delayed delivery makes sense, ie missing from means that it was the original sender that had a delay.

Including ones own full JID would also be a privacy leak in the context of (semi-)anonymous MUC.