XEP-Remarks/XEP-0203: Delayed Delivery
This is a page for information about XEP-Remarks/XEP-0203: Delayed Delivery, including errata, comments, questions, and implementation experience.
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:
- delay element without a from attribute or from a full JID - from the original message sender
- delay element from a bare JID - from a MUC (MUC history) or a user account
- delay element from a domain JID - server wasn't able to forward message immediately
- Forwarded message: <forwarded>'s delay element] - messages from MAM or Carbons
- Forwarded message: message payload: outer message's delay element] - fallback for when the forwarder didn't add a timestamp
- 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.