[Standards] distributed MUC rooms

Bruce Campbell b+jabber at bruce-2007.zerlargal.org
Wed Jun 13 04:56:31 UTC 2007

On Sat, 9 Jun 2007, Justin Karneges wrote:

> I question the purpose of distributing a single MUC room across many public
> XMPP servers.  You're right, we should probably look to IRC if we want tips
> on how to do that, but why do we want this at all?
> I thought the only reason individual IRC rooms were distributed was simply a
> side-effect of the fact that every IRC server must host every room.  All ten
> thousand rooms of some IRC network are each hosted by every IRC server within
> that network.

Flaw in the 'standard' IRC protocol.  There are probably varients that do 
the smart thing and only distribute IRC rooms (#channels) to servers that 
have users using that room on that host, or are hubs for such servers. 
IMO, any distributed MUC approach should take the same tactic to reduce 
bandwidth costs.

> Peter mentions distributed MUC being useful in a tactical environment.
> Wouldn't it be enough to just use a good, distributed XMPP server deployment,
> that also supports distributed MUC internally?

Interoperability is preferred.

> The proposed XEP would allow for distributed MUC nodes to be external,
> owned/operated by different people, and potentially running different
> implementations.  Sure, standards are good, and this is exactly the kind of
> spec we'd promote if it were needed.  I'm just not convinced anyone needs it.
> Who will implement it?  It is expected that general IM clients should support
> it? (this is my concern)

On reading it, it appears that the only client side support required is 
understanding the <redirect/> response to joining a room.  For clients 
that don't grok that, the invite from the peer host is within the 
existing MUC protocol.

Having the client retain knowledge of the various peerhosts (with the aim 
of resending a message to one of them if its chosen peerhost is MIA) is 
probably overkill.

> I hope that we are not trying to clone IRC's behavior just for the sake of
> saying we can.

Much of IRC's quirks come from the server to server protocol, and the 
design being based around a star configuration.  Mesh-based designs are 
more resilient.

   Bruce Campbell.

   [1] He says, having suggested a new client protocol for private chats.

More information about the Standards mailing list