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:
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! 😀
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! 😀
This entry was edited (3 years ago)
like this
j.r / Julian reshared this.
JC Brand
in reply to Ingo Jürgensmann • •j.r / Julian
in reply to JC Brand • •Sadly the XEP is not really clear about connection lost cases and such stuff so it will need some work in my opinion...
Ingo Jürgensmann
in reply to j.r / Julian • •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! 😀
Ingo Jürgensmann
Unknown parent • •