Difference between revisions of "Multi-Session Nicks"

From XMPP WIKI
Jump to: navigation, search
m (Implementation Status: prosody update, thx to daurnimator)
(Private Messages: updated with optimal behavior patterns)
Line 32: Line 32:
 
= Private Messages =
 
= 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 [http://xmpp.org/extensions/xep-0280.html XEP-0280]-enabled clients, even if these clients are not joined to the MUC.
+
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 [http://xmpp.org/extensions/xep-0280.html 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 <nowiki><private xmlns='urn:xmpp:carbons:2'/></nowiki>, 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.
+
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 ([https://mail.jabber.org/pipermail/standards/2017-January/032048.html rationale]).
  
'''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.
+
== Optimal MUC service behavior ==
  
'''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.
+
* a MUC service SHOULD add the <x/> tag to all sent PMs ([https://xmpp.org/extensions/xep-0045.html#privatemessage XEP-0045 §7.5])
 +
* a MUC service should send copies of a PM to all joined resources, marked with <private/> to prevent Carbons
  
'''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.
+
== Optimal XMPP server behavior ==
  
 +
* a server should not carbon-copy incoming MUC-PMs to other clients (that 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, or to all clients as a fallback
  
Furthermore, it might be a good idea to mark MUC PMs as such. Some MUC implementations do this by adding a <nowiki><x xmlns='http://jabber.org/protocol/muc#user' /></nowiki> element. This could be used to influence the filtering logic in XEP-0280, as well.
+
== Client-side workaround behavior ==
 +
 
 +
* when sending a MUC-PM, the client should tag it with <x/> (to let their server know), 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, '''add to the respective PM chat log
 +
'''
  
 
= Non-anonymous rooms =
 
= Non-anonymous rooms =

Revision as of 09:24, 21 February 2018

"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

Optimal XMPP server behavior

  • a server should not carbon-copy incoming MUC-PMs to other clients (that 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, or to all clients as a fallback

Client-side workaround behavior

  • when sending a MUC-PM, the client should tag it with <x/> (to let their server know), but not with <private/> (to allow sync to the user's other clients)
  • when receiving a "sent" Carbon:
    1. determine whether the bare JID is a MUC
    2. if this client is not joined, ignore
    3. if this client is joined, add to the respective PM chat log
  • when receiving a "received" Carbon:
    1. determine whether the bare JID is a MUC
    2. if this client is not joined, ignore or offer to join the MUC
    3. if this client is joined, add to the respective PM chat log

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 ?
prosody trunk primary session (first joined) primary session to IQ sender to all sessions, marked with <x>, carbon prevention <x> with <item>s for all sessions