Hi all, I submitted a protoXEP today <https://github.com/xsf/xeps/pull/1563>. A rendered version is at <https://nicoco.fr/muc-ready.html> It is a proposition for a mechanism to avoid the following situation: 1. a MUC services shuts down and kicks clients out; 2. clients don't re-join the MUC automatically. This is generally not an issue for local users, since MUC services and XMPP server implementations are tightly coupled in practice and can work around the situation by supporting restarting the MUC service "silently". Also, when the whole XMPP server is restarted, clients re-login and re-join all MUCs after that, so the issue does not arise. It is however a problem for non-local users. Clients have adopted different strategies for this situation. For instance, Conversations does not attempt to re-join automatically, and gajim retries periodically. I propose that MUC services can emit MUC invitations on startup to signal that a room is ready to be re-joined. The invite stanza has a dedicated |<ready />| element, which lets clients treat these invites differently than others, eg, by avoiding to display it to the user or triggering re-join as they see fit. Slidge already has this "invite users on startup" behaviour and I developed a small prosody module <https://modules.prosody.im/mod_muc_invite_affiliated.html> <https://modules.prosody.im/mod_muc_invite_affiliated.html> with a similar behaviour. If this proposition is accepted, I will add the dedicated element in the invites of both this prosody module and slidge. Maybe this should be a new section in /XEP-0249: Direct MUC Invitations/ instead? What does the community think? Is it a terrible idea or does it fill a gap that is missing? -- Nicolas