[Standards] distributed MUC rooms

Peter Saint-Andre stpeter at jabber.org
Mon Jun 4 16:29:31 UTC 2007

Michal 'vorner' Vaner wrote:
> Hello
> On Fri, Jun 01, 2007 at 09:37:15PM -0600, Peter Saint-Andre wrote:
>>  Last October I talked with some folks in the XMPP community about the idea 
>>  of distributing MUC rooms across domains. Late this afternoon and this 
>>  evening I finally got around to writing up an approach to this problem. The 
>>  document I've started working on is quite tentative, but I figured I'd send 
>>  it out for feedback anyway (release early, release often!).
>>  http://www.xmpp.org/extensions/inbox/distributedmuc.html
>>  I'll try to work on it more this weekend, since I'd like to present some of 
>>  the ideas at a conference I'm attending next week.
> I like it, but few notes:
> • Section 3.4 should say that the "other instances" must send the
> message to its local occupants too and not again to other instances (to
> prevent looping).


> • Can a peerhost connect to other peerhost?

Yes. Or at least I see no reason to forbid that.

> • Who has the last word when the firsthost dyes? (That will be in 3.6,
> right?)

Yes, that's hard. Maybe I stopped working when I realized I had gotten 
to the hard parts. :)

> • I did not notice a way to make my muc component connect to some other
> room. Will it be done by ad-hoc or there will be some special support
> for it?

I don't think I understand your question. Do you mean that your 
component would be an occupant in another room?

> By the way, I would know about more usecases. First, MUC aliases (every
> big server could have the same jdev room and you could be sure if you
> join it anywhere, you are home). 

Good point. I guess that the list of registered roomnicks is something 
else we'd need to share and sync between instances.

Another challenge may be ensuring that room names are unique across 
peerhosts (e.g., what if you try to create a room "jdev" and a peerhost 
already has a room by that name?). One solution would be to specify that 
room JIDs are UUIDs, but I don't know if we need to go that far.

> Second - maybe interconnection between
> some IRC transport and usual MUC? 

I don't know if that belongs in this document or in a spec that defines 
how to gateway between IRC and MUC.

> And third - large MUCs - every single
> service does less sending, so there is less stress on the line and so.


BTW, about saving traffic in large MUCs, I think also we would want to 
suppress presence for the majority of participants. There is a room 
config option for this in XEP-0045 ("muc#roomconfig_presencebroadcast").

> Anyway, I really like this one.

So far so good. But it needs more work!


Peter Saint-Andre
XMPP Standards Foundation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070604/5437e942/attachment.bin>

More information about the Standards mailing list