[Standards] Ephemeral messages to offline users (XEP-0085, XEP-0160?)

Georg Lukas georg at op-co.de
Thu Jun 6 09:05:30 UTC 2019


Hi,

recently I started noticing bounces for CSNs (XEP-0085) sent to an
offiline (ejabberd) user. This behavior corresponds to XEP-0160, §2.3:

> Recipient's server determines that if the server can store offline
> messages on behalf of the intended recipient; if not (e.g., because
> the recipient's offline message queue is full), the server returns a
> <service-unavailable/> error to the sender.

The user experience in at least the client I'm using (poezio) is very
disturbing, as the message log is flooded with error bounces that are
unrelated to the actual messages I send:

10:34:05 uesr at jabber.at: 503 - cancel: User session not found
10:34:08 uesr at jabber.at: 503 - cancel: User session not found
10:34:09 uesr at jabber.at: 503 - cancel: User session not found
10:34:09 Ge0rG> test
10:34:14 uesr at jabber.at: 503 - cancel: User session not found

The obvious long-term solution will be to change CSNs from being
<message> to directed <presence>. However, that will take some years,
and I'm interested in a principal solution of what to do with ephemeral
messages.

The problem at hand, CSN bounces, has a number of possible solutions:

1.  Tracking of CSNs in the sending clients and suppressing display of
the bounces. That requires additional logic and (potentially persistent)
tracking of ephemeral message IDs, or some other ugly hacks like
encoding the ephemerality into the ID, and it doesn't work over multiple
clients.

2.  Mandating that the bounce MUST contain the original bounced message
(this is optional as per the RFC), so that the client can suppress the
error in a state-less way. That will also work better if the original
CSN is not carbon-copied to the sender's other devices, but the error
is(*).

3. Receiving server silently drops unimporant/ephemeral messages instead
of bouncing them. This would make the client less complex (at the cost
of the server, which fits the original design of XMPP), and reduce the
overall network load.

Jonas has pointed out that certain kinds of ephemeral messages
definitively need to be bounced, e.g. OTR payloads. We already have the
"ephemerality" debate in the context of MAM / offline storage, where we
don't have a clear set of rules yet. So we should also move forward with
defining what's ephemeral (bounce silently) and what's semi-ephemeral
(don't store but bounce).


Georg

(*) I'd really like to mandate carbon-copying of message errors, but
this is up to a separate standards@ thread; the relevant part here is
that a bounce obviously inherits the ephemerality property of the
bounced message.
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190606/de2b3efa/attachment.sig>


More information about the Standards mailing list