[Standards] Solving the not staying connected in a MUC problem
zash at zash.se
Wed Jun 19 07:38:09 UTC 2019
On Tue, Jun 18, 2019 at 11:47:10AM +0000, Daniel Gultsch wrote:
> 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
> 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.
Prosody already stores MUC state on graceful shutdown, or if there
are too many rooms in memory and it swaps some out.
> When coming back online the muc service will send invites to all those
> full jids.
MUCs are then not restored on startup, but on activity. Resources get
dropped out of rooms if that (broadcasted) activity causes them to
return an error reply.
> 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.
Could however send an invite when they get removed for sending an error.
> 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.
I'm going to be worried about interactions with carbons and clients that
automatically follow invites.
Kim "Zash" Alvefur
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Standards