On Fri, 11 Jun 2010, Peter Saint-Andre wrote:
Last month the XMPP Council approved publication of two proposals regarding distributed multi-user chat rooms (a.k.a. "DMUC"). I had intended to harmonize the two approaches before publication, but I've not yet found the time to do so. Therefore we have published both proposals as-is in order to encourage discussion. (It is also possible that one or more additional proposals on this topic will be published in the near future.) You can find the submitted proposals here: http://xmpp.org/extensions/xep-0281.html http://xmpp.org/extensions/xep-0282.html
Apart from both needing a spin through the speel czecher, they both seem to suffer from having a single point of failure for new users joining the room, being the initial root node ('firsthost' or 'MASTER') which is the only point which can distribute new users to nominated peer host/rooms.
281 doesn't suffer from the root node (firsthost) being a SPoF for the distribution of messages between peers, and supports the dynamic addition of new peers, but examples are needed to demonstrate the removal of an arbitary peer host and subsequent redistribution of users, verification of connectivity between peer hosts and how to deal with a non-fully-connected mesh; there's a nice empty section 3.5 waiting for this.
282 suffers from the root node (MASTER) being a SPoF for the distribution of messages between slaves. With the conditionals in 4.1, 282 is better suited towards easing the load of outgoing message distribution within a single organisation. It's unclear whether each slave is receiving each message twice; once from the user directed to the master, and once from the master for distribution.
282 4.5 possibly has the order of activities reversed. A given slave should confirm that it has added the new user to its distribution list before the other occupants of the room are informed of the new user's presence.
That's probably enough for a 5 minute review. Personally I think that if distributed MUC is to be done right, it should be more resilient then the stereotypical netsplitting IRC network.
-- Bruce.
