NGMUC

This page is about a next generation multiple user conference protocol. At the moment, just a time to write down some ideas. Just for your information, there is no NGMUC protocol at the moment.

The protocol which is used for many-to-many conversations nowadays: XEP-0045

Issues

Here is a list of some things which would be nice to have.

Resource Support

XEP-0045 doesn't support multiple resources for one participant. You have to log into the conferece again as another participant by using another nickname. Multiple participants who are one and the same individual can lead into confusion and missunderstanding. Of course there is not much confusing in room with just 13 participants but the XMPP protocol is no hobby project and up to 100 users can join a conference.

Role/Affiliation Management

Roles and Affiliations are inconsistent. XEP-0045 treats them as if an affiliation implies a role, but in fact affiliations have effects beyond the roles assigned.

• A moderator role with an admin affiliation can ban people, while other moderators can't.

• A moderator role with an owner affiliation can configure the room, while other moderators can't.

• In some rooms, a participant role with a member affiliation can modify the topic, while other participants can't.

• In some rooms, a member can send a message, while non-members cannot.

The other half of the problem is that affiliations persist, while roles do not. This tends to make the role system close to useless, since no change will stick around after the assignee leaves.　Impossibilities under the current system:

• Allow someone to kick, but not ban, and change the topic, and make this status remain even if they leave and return.

• Prevent someone from speaking in a room, and make sure they can't get around it by simply leaving and rejoining.

• Allow someone to speak in a room, and make sure it stays that way when they leave and rejoin.

Finally, the roles and affiliations distinction makes for a complex 2-dimensional grid of possibilities, with 20 combinations where only 13 actually make any sense (you can't have an admin or owner who is not a moderator, or an outcast who has any role except "none"), and even less are useful (admins and owners can't be kicked, outcasts can't hold any role but "none", and the moderator/participant/visitor roles don't persist for members or "none")

Conference Component Intercommunication

Confererence Component Intercommunication will decentralize the MUC protocol. You can link two or more MUC components together and as a result they share the room browse list. The server "conference.capulet.net" tells the servers "conference.montague.com" and "conference.jabber.org" that it is hosting the room "balcony", and all three servers include "balcony@conference.capulet.net" in their service discovery response. This is very close to working as is. All that's needed are:

• a protocol for advertising rooms among components
• a protocol for deciding which server will host a newly-created room, and telling the client about it. This is probably not strictly necessary, but might be good for some sort of load balancing.
• possibly, a protocol for redirecting users to "balcony@conference.capulet.net" when they try to join "balcony@conference.montague.com". This might not be necessary, given room bookmarks and "recent room history" in clients.

Support for More Participants

This is the easiest point. You just ged rid of the thought that the XMPP protocol and its enhancements called XEPs were just written for hobby usage. It's altogether a serious project which is used by hundred tousands of people. Where is the advantage of a conference with limited participants? In IRC networks there are rooms with 700 people inside. Who said that isn't possible with XMPP technologies? I think, it is.