[Standards] Dealing with offline messages in times of MAM

Georg Lukas georg at op-co.de
Wed Jun 10 07:55:01 UTC 2015

* Daniel Gultsch <daniel at gultsch.de> [2015-06-10 07:01]:
> However if the MAM capable client is the only client in the game it
> will (with normal setups) regularly receive both the offline messages
> and the messages downloaded from the MAM archive.

This is one of the specific aspects that I have in mind when proposing
to "rethink message routing in the context of MAM".

MAM and offline messages are duplicating the same functionality. Still,
we can not get rid of one as long as not all clients support the other.

> Is there a solution to this problem that can simply be solved by server
> side configuration?

My proposal would be to replace the offline messages on the server with
the MAM-ID of the last delivered (or first undelivered, whatever the
implementor sees fit) message from MAM.

When a MAM-capable client connects and requests MAM/MAMSub, the server
simply wouldn't deliver the offline messages to it, but would update
that last_offline_mid property accordingly.

To accomplish that, two requirements must be fulfilled:

a) MAM will store the same messages as offline or a superset of them.
This is probably easy to do, we just need to specify which messages go
into MAM.

b) We need to solve the race condition between opening a session (when
the server starts delivering offline messages) and requesting MAMSub.
This is very similar to the MAM download / MAMSub race condition and
related to the possible MAM download / new incoming messages race
condition. I think an interesting solution to all of these would be to
replace/extend the <session> element, i.e. by adding a MAM namespace to

With a separate MAM session type, the server would be aware of the
changed routing rules, would implicitly MAM-subscribe the client and
inhibit offline message delivery, in a consistent and atomic way. That
would also allow the server to push MIDs / reflected messages / Carbons
to the client for all client-generated messages, to update it with the
according MIDs.

> Will simply disabling offline message return all messages to the sender
> even though they are stored in MAM?

This is another interesting question. If a client has enabled MAM but is
offline, no errors should be generated for new incoming messages, unless
the MAM archive is over quota.

I think this also holds true for yet unacked SM messages. The above
solution (track last_offline_mid) should work for both scenarios, as
long as all messages were sent to the bare JID.

If messages were sent to the full JID, things start to become
interesting. We might need to define MAM/offline-storage business rules
for re-routing full-JID messages into the archive. Personally I'd go
with only ever archiving bare-JID messages, and only use full-JIDs
for ephemeral messages like CSN or OTR. However, as opposed to the
radical suggestion for (b) above, this would be way too radical as it
would break most existing clients.

|| 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: 811 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150610/e6b42462/attachment.sig>

More information about the Standards mailing list