Proposed XMPP Extension: MUC is ready
The XMPP Extensions Editor has received a proposal for a new XEP. Title: MUC is ready Abstract: This specification provides a way for MUC components to inform clients that a room is ready to be re-joined. URL: https://xmpp.org/extensions/inbox/muc-ready.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.
Le vendredi 2 octobre 2026, 17:45:23 heure d’été d’Europe centrale Daniel Gultsch a écrit :
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: MUC is ready Abstract: This specification provides a way for MUC components to inform clients that a room is ready to be re-joined.
URL: https://xmpp.org/extensions/inbox/muc-ready.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi Nicolas, thank you for this contribution. I see the point in this, my only issue with it is that it's MUC only, while this could be generally useful for about any service (any service can be down for maintenance, and it would be useful to know when it's back). However, with MUC we can know if an entity was in the room at the time of shutdown, for other services it could be more complicated. But it would be useful to know if e.g. a file sharing service is back after maintenance. Maybe handling other services would be a separated issue (i.e. could be a future XEP)? I was just thinking out loud. Anyway, the feature seems useful. Best, Goffi
On Tue, Oct 06, 2026 at 05:03:45PM +0200, Goffi wrote:
Le vendredi 2 octobre 2026, 17:45:23 heure d’été d’Europe centrale Daniel Gultsch a écrit :
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: MUC is ready Abstract: This specification provides a way for MUC components to inform clients that a room is ready to be re-joined.
URL: https://xmpp.org/extensions/inbox/muc-ready.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi Nicolas,
thank you for this contribution. I see the point in this, my only issue with it is that it's MUC only, while this could be generally useful for about any service (any service can be down for maintenance, and it would be useful to know when it's back).
XEP-0310: Presence State Annotations <https://xmpp.org/extensions/xep-0310.html> feels like prior art for this kind of problem? -- Kim "Zash" Alvefur
On Tue, Oct 6, 2026 at 5:21 PM Kim Alvefur via Standards <standards@xmpp.org> wrote:
XEP-0310: Presence State Annotations <https://xmpp.org/extensions/xep-0310.html> feels like prior art for this kind of problem?
I scrolled quickly over that XEP: - it doesn't seem like it'd provide an update when the service is _back_ - it seems aimed at reporting that a fulljid and possibly barejid are unavailable, rather than a service itself But per my other email I'd expect presences to serve that purpose (like they seem to in XEP-0310) - except a client would need to indicate interest in receiving it without confusing the user with roster spam.
On Tue, Oct 6, 2026 at 4:04 PM Goffi <goffi@goffi.org> wrote:
Le vendredi 2 octobre 2026, 17:45:23 heure d’été d’Europe centrale Daniel Gultsch a écrit :
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: MUC is ready Abstract: This specification provides a way for MUC components to inform clients that a room is ready to be re-joined.
URL: https://xmpp.org/extensions/inbox/muc-ready.html thank you for this contribution. I see the point in this, my only issue with it is that it's MUC only, while this could be generally useful for about any service (any service can be down for maintenance, and it would be useful to know when it's back).
However, with MUC we can know if an entity was in the room at the time of shutdown, for other services it could be more complicated. But it would be useful to know if e.g. a file sharing service is back after maintenance. Maybe handling other services would be a separated issue (i.e. could be a future XEP)?
For most other things, it seems like a directed <presence/> would be the right approach. MUC's use of presence varies, so a direct MUC invitation might be better. Question arises, of course, about the relationship between services and roster. I have a few of my services' JIDs on roster, but most other people won't do that.
Hello, Thanks a lot for the feedback.
it's MUC only
Goffi, I can see the appeal in making this more generic indeed, and it looks like Zash's finding is very interesting in this regard.
XEP-0310: Presence State Annotations
Zash, the "use case" of my proposal is not covered, but it looks like it could be added indeed. Something like: <presencefrom='service.montague.lit'to='romeo@montague.lit'><state-annotationxmlns="urn:xmpp:psa"from="montague.lit"><server-available /><description>Slidge has finally finished booting up. Re-join all my MUCs!</description></state-annotation></presence>
I have a few of my services' JIDs on roster, but most other people won't do that.
Ivan, I don't think using presence would be an issue here, even if you don't have the service in your roster. Supporting clients could treat it differently than "roster spam", unsupporting clients likely already ignore it. Maybe I am missing something? My concern with using XEP-0310 would be more about the requirement of special support for this use case in clients. With my proposal, we use a mechanism that does something already in most clients. On the other hand, the XEP-0310 approach would solve the obvious missing optimisation from my proposal: a single stanza from the service per member instead of one stanza per member per room. Also, the MUC service I develop is expected to be the user's roster, and already sends an "available" presence to registered users on startup, so that's very minimal work for me to implement (as is my proposal). I am glad my proposal started a discussion about this topic. I am opened to retracting it in favor of an update to XEP-0310. - Kev, would you be in favour of such an update of your submission from yesterday? (wait, 2012 isn't yesterday?) I guess it would simply be a new "4.4 MUC service restarts" paragraph with a new <server-available> element. - Client devs, do you have any feedback? If no one of you think this is a good idea, there isn't much point in advancing this further. I would love to know why though! -- nicoco
Hello all, After some thought I would like to cancel my protoxep submission. I am now convinced that MUC services could be in roster and send a presence on startup to achieve the same thing with a lot less traffic. Sorry about the noise and thanks for the feedback. Cheers -- nicoco
On 8 Oct 2026, at 05:56, Nicolas Cedilnik <nicoco@nicoco.fr> wrote:
- Kev, would you be in favour of such an update of your submission from yesterday? (wait, 2012 isn't yesterday?) I guess it would simply be a new "4.4 MUC service restarts" paragraph with a new <server-available> element.
Ah, I’d missed this question here (but I answered it on XMPP where I was also asked). I guess this isn’t relevant now, but I wonder if it would work better as the user’s server announcing the unavailability (and re-availability) of the remote, in a more PSA-ish way, if done within PSA. /K
Ah, I’d missed this question here (but I answered it on XMPP where I was also asked).
You did answer in the chat room, it's fine!
I guess this isn’t relevant now, but I wonder if it would work better as the user’s server announcing the unavailability (and re-availability) of the remote, in a more PSA-ish way, if done within PSA.
If we follow XEP-0045, unavailability is sent to each occupant already, so I guess we would need to change that too? Implementations in the wild already do not necessarily announce that they go down, though. The MUC service could announce its re-availability to the remote user's directly, but then the server has to know users it has to dispatch the announcement too. I can imagine various ways to do that, maybe PSA is a good fit for this traffic optimisation. -- nicoco
participants (6)
-
Daniel Gultsch -
Goffi -
Ivan Vučica -
Kevin Smith -
Kim Alvefur -
Nicolas Cedilnik