Multi-Session Nicks

"Multi-Session Nicks" describes a situation when you join the same Multi-User Chat from different client sessions (logged in at the same account, using different resources), using the same nickname.

Because nick sharing maps multiple user resources to one single MUC resource (nickname), it has some special issues. These issues are documented below.

Server Support

Nick sharing is known to be supported by the following MUC service implementations:

• prosody
• ejabberd
• M-Link
• Openfire

It might be possible to implement nick sharing on an XMPP server, so it only sends a single presence to a MUC component. That would require the XMPP server to cache the MUC state information.

Message Handling

MUC chat messages need to be forked to all connected clients. As messages sent by a client are reflected, this covers both the outgoing and incoming use-cases.

Presence Handling

Current implementations just forward presence updates from the users' clients as they come in. This means that a MUC participant can be displayed as "xa" even though they have an "available" client connected to the MUC.

Recommendation: Presence updates from different clients should be cached by the service, only exposing the "most-active" one to the other MUC participants. If the "most-active" resource leaves the MUC, the second-active one should be broadcasted.

IQ Handling

An IQ request sent to the MUC participant can not be forked to all clients, as that would cause multiple responses, violating the sender's expectations. Therefore, the IQ needs to be sent to a single resource, chosen by the MUC service. It might be useful to take the "most-active" client for that.

When a nick-sharing user sends an IQ to the MUC or to a different participant, it is very important for the IQ result to be correctly routed to the originating resource. Some existing implementations cease to do that, so an IQ request sent by juliet@capulet.lit/balcony might be answered to juliet@capulet.lit/chamber, causing confusion on both clients.

Private Messages

When a private message is sent to a nick-sharing participant, the service might deliver it to one or all resources. As MUC PMs are of type "chat", they will be implicitly carbon-copied to XEP-0280-enabled clients, even if these clients are not joined to the MUC.

Variant 1: the MUC service should fork outgoing PMs to all resources, and mark them as <private xmlns='urn:xmpp:carbons:2'/>, preventing them from being carbon-copied. This does not solve the problem of PMs sent by the user's other client being carbon-copied to the first one.

Variant 2: the XMPP server should keep track of the user's joined MUCs, and prevent carbon-copying of MUC PMs. The MUC service should fork outgoing PMs to all resources. This might be challenging for the server, as it is not possible to detect a "groupchat 1.0" join presence, and it requires keeping of additional data.

Variant 3: the XMPP server should keep track of the user's joined MUCs, and apply its carbon-copying logic only for the user's client that are joined to the MUC. The MUC service should only send PMs to a single resource. The implications for XMPP servers are comparable to Variant 2.

Variant 4: a client receiving a carbon-copy of a message that is not from a joined MUC needs to perform a service discovery on the bare JID to determine if the message is from a MUC or from a normal user.

Furthermore, it might be a good idea to mark MUC PMs as such. Some MUC implementations do this by adding a <x xmlns='http://jabber.org/protocol/muc#user' /> element. This could be used to influence the filtering logic in XEP-0280, as well.

Non-anonymous rooms

It is also necessary to deal with non-anonymous rooms. Here, the other occupants should be able to see at least one of the resources of each other occupant, but they somehow need to be informed when that resource leaves while a different resource is still present.

Implementation Status

The following table shows the current implementation status of the different MSN corner cases in existing implementations.

Editor note: If the behaviour changes, please add another line with the exact version number

Implementation	Presence	IQ Request Routing	IQ Response Routing	PM Routing	Non-Anon rooms
ejabberd 15.07	forwards all	to highest prio	to highest prio	to all sessions, marked with <x>, no carbon filter	?
M-Link x.xx	?	?	?	?	?
prosody 0.9	forwards all	?	to IQ sender	to ?, marked with <x>, carbon prevention	keeps first-joined resource