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:
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 MUC service will fork it to all joined clients. As MUC PMs are of type "chat", they will be implicitly carbon-copied to all XEP-0280-enabled clients, even if these clients are not joined to the MUC.
The MUC specification was changed on 2017-05-31 to add an <x/> tag to all MUC-PMs, to allow other entities to differentiate them from regular non-MUC messages (rationale).
Optimal MUC service behavior
- a MUC service SHOULD add the <x/> tag to all sent PMs (XEP-0045 §7.5)
- a MUC service should send copies of a PM to all joined resources, marked with <private/> to prevent Carbons (the MUC can't know if the user's server supports Carbons, and if they are enabled on all joined clients)
Optimal XMPP server behavior
- a server should not carbon-copy incoming MUC-PMs to other clients (this requires tracking of MUC presence, or analysis of the <x/> element)
- a server should carbon-copy outgoing ("sent") MUC-PMs to other clients that are joined to the MUC
- if the server knows for sure those messages are MUC-PMs, it should add an <x/> tag to the message before CCing
- as a fallback, the server may send the carbon copy to all (other) clients if it doesn't track MUC presence
Client-side workaround behavior
- when sending a MUC-PM, the client
should tag it with <x/> (to let their server know)(this might prevent Carbon-copying to other clients), but not with <private/> (to allow sync to the user's other clients) - when receiving a "sent" Carbon:
- determine whether the bare JID is a MUC
- if this client is not joined, ignore
- if this client is joined, add to the respective PM chat log
- when receiving a "received" Carbon:
- determine whether the bare JID is a MUC
- if this client is not joined, ignore or offer to join the MUC
- if this client is joined, ignore (the MUC will send a forked message to you anyway)
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 - 0.10 | forwards all | ? | to IQ sender | to ?, marked with <x>, carbon prevention | ? |
| prosody 0.11+ | primary session (first joined) | primary session | to IQ sender | to all sessions, marked with <x>, carbon prevention | <x> with <item>s for all sessions |