[Standards] distributed MUC rooms

Michal 'vorner' Vaner vorner at ucw.cz
Sat Jun 2 06:33:12 UTC 2007


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?

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

• 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?

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). Second - maybe interconnection between
some IRC transport and usual MUC? And third - large MUCs - every single
service does less sending, so there is less stress on the line and so.

Anyway, I really like this one.

Work with computer has 2 phases. First, computer waits for the user to tell it what 
to do, then the user waits for the computer to do it. Therefore, computer work 
consists mostly of waiting.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070602/40d269d6/attachment.sig>

More information about the Standards mailing list