Skip to main content


Federated MUCs in XMPP


Some may have experienced that I'm somewhat in favor of #XMPP as a messaging protocol. One of the greatest things about XMPP is the federation. Another great thing are the Multi User Chats (MUCs).

So, you can register on any XMPP server and join a MUC on a different server. Isn't that great?! ;)

Only downside is: when the server goes down on which the MUC is hosted, the MUC will become unavailable. There are other chat solutions like Matrix that support chat rooms on multiple servers.

How about XMPP then? Well, there is https://xmpp.org/extensions/xep-0289.html for that:
MUC's design generally assumes a highly reliable network providing plenty of bandwidth, and it functions well in Internet settings. It is sometimes the case that server to server traffic is heavily constrained, with typical problems for constrained links being high latency, tiny amounts of available bandwidth and unreliability (including, potentially, long-term failure of S2S links). This document provides methods for allowing experiences close to those of standard MUC use while operating across such constrained links by allowing rooms to federate with remote counterparts and for users to connect to the federated MUC node nearest to them on the network for a given FMUC room. It requires no setup in advance, and needs no bandwidth for remote rooms without local occupants. The premise is that a proxy room joins another room and receives stanzas from the MUC just as another occupant would; this is analogous to the client to server model, whereby a client would connect to their local server and the server deals with connections elsewhere - the client joins a local room and the room deals with connections to other federated rooms.

The draft is from 2012, so it's a little bit dated and therefor in "Deferred" state. But wouldn't it be great to have federated MUCs that are somewhat redundant and available, although a server goes down, e.g. for maintenance?

So, what do other XMPP gals & guys think? Maybe there are some parts missing in that XEP in its current state, but well... feel free to comment! 😀
#XMPP
This entry was edited (3 years ago)

j.r / Julian reshared this.

in reply to Ingo Jürgensmann

I know that Guus der Kinderen who's an Openfire XMPP server developer asked about that XEP recently and I think he might have been working on an implementation for Openfire.
in reply to JC Brand

thats how I found out about it... the Newsletter was talking about it and I told @ij

Sadly the XEP is not really clear about connection lost cases and such stuff so it will need some work in my opinion...
in reply to j.r / Julian

Maybe it's a good idea to discuss this in a next XMPP sprint or something like that.
I think the XMPP world would greatly benefit from federated MUCs, but I can understand that there is lots of work to do, before it can be tested.

It's maybe not that bad when Guus goes forward on OpenFire and keep interoperatibility in mind with other XMPP servers. In a first step FMUC between a cluster of two would be nice, expanding to a setup of two independent nodes of same software version/vendor and then to fully federated interop-mode with XMPP servers from different vendors.

Thanks, @j.r for bringing this up to me! 😀
Unknown parent

Ingo Jürgensmann
I also would prefer a configurable list of possible servers for federation, though. It's also a matter of GDPR, I think...