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

Kim Alvefur 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...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190619/8ec407b6/attachment.sig>

More information about the Standards mailing list