First draft.
The primary motivation for Distributed Multi-User Chat (DMUC) is to minimize the server-to-server (S2S) traffic that is required for Multi-User Chat (MUC). In constrained environments, the traffic on the S2S link can cause severe degradation of service. Much of the S2S message traffic can be eliminated if each local server keeps a mirror of the chat room and responds to its local users on behalf of the actual MUC room.
MUC uses lots of bandwidth. Sometimes the network link that S2S traffic is carried on is heavily constrained. This protocol reduces the amount of traffic going across S2S through local mirrors of remote MUC rooms. It needs no bandwidth for remote rooms without local occupants.
The following is a list of goals for the design of this extension:
The following JIDs are used in this document.
Support for Distributed MUC in a given server instance SHOULD be determined using Service Discovery (XEP-0030)
To determine if a server or service supports Distributed MUC, the requesting entity SHOULD send a disco#info request to it.
If the server supports Distributed MUC, it MUST include a feature in the response.
User wayne@raleigh.tridsys.com/TransVerse wants to join MUC room chatroom@conference.fairfax.tridsys.com. At this point mirror.raleigh.tridsys.com knows nothing of the chatroom@conference.fairfax.tridsys.com MUC, and no existing mirror is in place beyond mirror.raleigh.tridsys.com being willing to mirror for wayne@raleigh.tridsys.com/TransVerse.
raleigh.tridsys.com determines that this message is bound for a MUC service supporting DMUC and sends it to the real MUC with an additional tag.
chatroom@conference.fairfax.tridsys.com recognises that the mirror service is now mirrorring it,
and performs the usual ACL checks as if wayne@tridsys.com/TransVerse had joined directly,
sending presence to all occupants. The master MUC will be able to take advantage of the fact that the
rosters are being maintained by the distributed MUC services and send one presence with no
<addresses/> (see Extended Stanza Addressing (XEP-0033)
If this mirror is unknown to the master, the room configuration MUST be sent to the new mirror. The room configuration will contain information like if the room is moderated, how much history, who is allowed in the room, etc.
Upon receiving the room configuration, the mirror MUST respond.
The master room MUST now send the roster to the mirror.
The mirror MUST send a response to the roster.
The new mirror SHOULD request room history. See Multi-User Chat (XEP-0045)
The history request MAY include any attributes specified in Multi-User Chat (XEP-0045)
The mirror service on raleigh.tridsys.com then relays the message to all of the room members that are in the raleigh.tridsys.com domain.
If the master doesn't allow the user to join, it sends the standard MUC error to the mirror. The mirror SHOULD only send the rejection to the user that failed to join. Other users don't need to know.
If a message is targeted to a specific user, JID Escaping (XEP-0106)
The mirror then extracts the user's JID and delivers the bad news to the user.
Now when a user joins the master directly it will do usual presence distribution to occupants (remembering the mirror is an occupant). Status codes are omitted from this example, see Multi-User Chat (XEP-0045)
The flow for a user leaving the mirror room is much the same as joining the mirror room:
The master needs to send the presence to locally attached users and mirrors that did not send this message.
Distribution of presence for users parting when connected directly to the MUC is identical to distribution of presence for users joining directly to the MUC.
Distribution of presence for users changing status is the same as that for joining and parting.
Normal fan-out like presence
The local server sends out this message to local users.
If the connection is lost to the master MUC, the mirrors should be able to continue on.
It is the responsibility of the mirrored DMUC to send unavailable presence on behalf of any user that is not attached locally.
It is the responsibility of the master MUC to send unavailable presence on behalf of the users attached to the disconnected remote domain to all local users and affected mirrors.
When the connection is re-established, there will be a flood of queued up presences and messages. Because presence information is most likely out of date, the master MUC should send all current presence information to the mirror. The mirror, should also send presence for its users to the master MUC.
To perform administration of the MUC, connect directly to the MUC and follow the standard process.
This allows a MUC mirror to mirror for another JID, so should only be deployed in scenarios where either the mirror service is trusted, or it is known that the users of the mirror service are in the same security domain as the mirror service.
None.
Needs a namespace.
When advanced.