[Standards] Solving the not staying connected in a MUC problem

Daniel Gultsch daniel at gultsch.de
Tue Jun 18 11:47:10 UTC 2019


by this point we are all aware of the problem of staying connected
(joined in) a MUC hosted on a remote server.
In case you are not here is a quick summary. MUC server shuts down; it
might send a shutdown event to participants (whether or not that will
arrive depends on whether or not the s2s link is currently
established.) After that participants either don’t know that they have
been kicked out of a MUC or they do know but don’t know when it is
fine to reconnect.

To remedy this 0410 was introduced. While not very explicit about it
the XEP implies that a client should regularly ping the MUCs it is
connected to and attempt to reconnect. I’m not trying to go too deep
into how utterly ridiculous it is to ask clients to ping a bunch of
MUCs in a regular interval when usually clients go through extra
length to optimize pings to their own server and keep them to an
absolute minimum. Just note that some platforms couldn’t do that even
if we somehow decided this was a good idea. However 0410 will come in
handy in a second; just bear with me.

There are a few reasons why a participant might get (knowingly or not)
be kicked out of a MUC. While it might be tempting to find a solution
that works for every scenario I suggest we look into the different
causes and address them individually.

Those causes are:
1) Graceful shutdown / reboot
2) crash
3) unstable internet connection

I think the answer for (3) is stream management on the s2s. We don’t
have that yet but the building blocks are here. This will be out of
scope for this email.

For the remaining cases I think (1) happens much more often than (2).

So what we really need is the server informing its former participants
that the server is back online after a reboot or a down time.

I have previously suggested to some people a scheme that uses MUC push
to trigger that. With the assumption that MUC push is something we
probably need independently of said problem to trigger things like
Slack-like email notifications. My admittedly crazy scheme would have
been to register my own full jid as an app server and thus get
notified on messages when i'm not in the room (which then could be a
trigger to rejoin the room.)
The down side of this is that it a) by default would only work after
the first message b) is a pretty big deal to implement for what we
really want: A notification when a server has come back online.

So instead here is my quick and dirty solution to fix (1).
During graceful shutdown a muc service shall remember all full account
JIDs currently joined in it's various rooms. When coming back online
the muc service will send invites to all those full jids.
A client (just pushed the code for Conversations to do that to github)
upon receiving an invite to a room it thinks it's already in; will
issue a 0410 ping. Or if the client already knows that it has been
kicked out of the room use that as a signal to rejoin.

If people are too paranoid about sending 'unsolicited' invites after
coming back online I could also imagine the client (via flag in the
join presence) opting in to receiving invites. But personally I'd be
fine with just doing it.

What do other people think about that?
Yes I know it only works for graceful shutdowns however I think that
those are the majority of shutdown and we could ease the problem a lot
by at least fixing those.


More information about the Standards mailing list