Hi, 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. cheers Daniel _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
