#383 XEP-0198, also implement the "committing the stanza for offline storage" variant
*Description of feature:*
Been using/testing XEP-0198 for a few days now and very happy with what is possible. One request:
XEP-0198 describes the treatment of ended streams thusly:
"A server SHOULD treat unacknowledged stanzas in the same way that it would treat a stanza sent to an unavailable resource, by either returning an error to the sender or committing the stanza to offline storage."
The "returning an error" bit is there and works, but it would be very nice if it were possible to configure and use the "commit to offline storage" alternative as well. I was told in your chat that this is something that devs actively want, it's just "complicated".
So, filing this here for future reference and tracking of progress of this feature request.
until there is an official solution, one may use my merge of mod_offline and mod_smacks.
In a combined module, there is no problem to use the offline storage for unacked stanzas. At least for me this workaround is doing well since a few weeks.
Unfortunately that doesn't work quite right when the user has multiple online resources. It's common for a mobile client that supports XEP-0198 to be online at the same time as a desktop client, and in this case you don't want the messages to go to offline storage, but to be delivered to the other resource.
Then you also have to consider that there may be even more than two resources, and some of them may also be using XEP-0198. That is, you could forward the messages to another resource, which might also go offline without acking them...
Also consider a user's phone crashing/restarting without properly closing the session. Most clients will not (and cannot) resume old sessions after a restart. The old session will still be open ("hibernating" it is called inside mod_smacks). The user may continue their conversation with their friend, while some of their friend's old messages are still pending (unacked) to the old session. Eventually that old session will timeout and the messages will suddenly be delivered to the new session... minutes or hours later (some people like to set really high hibernation timeouts), possibly long after the user finished chatting to their contact. This certainly doesn't lose messages, but it is not a very good experience for the user.
There are lots of edge cases in the use of XEP-0198, which is why we haven't implemented things like this yet.
Multiple resources are a confusing issue for most users anyway...
When there is an interrupted xep-198 session with some mobile resource, I would prefer that the (rebooted) mobile phone will get the remaining messages (as desired) instead of the PC at home. But I'm aware that this is not necessarily the case :/
My target was to eliminate the lost message case, as that is more annoying, confusing and common than getting messages to the wrong resource (at least for me).
I did not meant this to be a real patch, but a solution for some cases (like me sitting in a train with bad wwan-connection and gajim not resuming properly).
I will just add to clarify that in no case in the current implementation are messages "lost". Delivery errors are returned to the sender. A sensible client will tell the user that the message was not successfully delivered, and possibly even offer a way to retry the message.
I know some clients don't display message errors at all, but they are really at fault. There are other kinds of delivery errors that will cause messages to be silently dropped if clients ignore them, and XEP-0198 can't solve that. I always encourage people to report bugs against any clients that aren't handling message delivery errors.
What happens, if the sender also goes offline (sitting in a train with bad connection or so) shortly after sending? Then the delivery error cannot be returned to the sender for the same reason the recipient doesn't get the message.
All of this issues can be solved by MAM.
If the messages are received by the server they are stored in the message archive and every client logging in without resuming an existent session should sync with the MAM store to receive such messages.
There is no need to store smacks messages as offline messages when the session times out when using MAM this way.
Sending delivery errors in this scenario (namely: all clients support MAM) even hurts the user experience since the message actually will be delivered (or even was delivered) through MAM.
I wrote a small prosody module to NOT send those delivery errors at all when the hibernation timeout occurs and it is working well for me for over 3 months now.
My clients are: Gajim and Conversations.
As this is still an unsolved problem for most people, I would like to propose the following change:
IFF the current session (the one we are destroing) did perform a MAM query some time in the past AND the user account has MAM enabled, THEN silenty drop the queue.
The rationale would be that we obviously just lost a MAM enabled client, and we have an archive from which the client will resynchronize.