Difference between revisions of "Multi-Session Nicks"
Jump to navigation
Jump to search
(20 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
"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. | "Multi-Session Nicks" describes a situation when you join the same Multi-User Chat ([https://xmpp.org/extensions/xep-0045.html XEP-0045]) 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. | Because nick sharing maps multiple user resources to one single MUC resource (nickname), it has some special issues. These issues are documented below. | ||
Line 7: | Line 7: | ||
Nick sharing is known to be supported by the following MUC service implementations: | Nick sharing is known to be supported by the following MUC service implementations: | ||
* [https://www.ejabberd.im/ ejabberd] | * [https://www.ejabberd.im/ ejabberd] | ||
* [https://github.com/ortuman/jackal Jackal IM] | |||
* [http://isode.com/products/m-link.html M-Link] | * [http://isode.com/products/m-link.html M-Link] | ||
* [https://igniterealtime.org/projects/openfire/ | * [https://metronome.im/ Metronome IM] | ||
* [https://www.erlang-solutions.com/products/mongooseim.html Mongoose IM] | |||
* [https://igniterealtime.org/projects/openfire/ Openfire] | |||
* [https://prosody.im/ Prosody] | |||
* [https://tigase.net/xmpp-server/ Tigase XMPP Server] | |||
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. | 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. | ||
Line 32: | Line 36: | ||
= Private Messages = | = Private Messages = | ||
When a private message is sent to a nick-sharing participant, the service | 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. | ||
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]). | |||
== Optimal MUC service behavior == | |||
* 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 (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, however this might prevent Carbon-copying to other clients on some legacy servers), 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 = | = Non-anonymous rooms = | ||
Line 56: | Line 75: | ||
{| class="wikitable" | {| class="wikitable" | ||
!Implementation!!Presence!!IQ Response Routing!!PM Routing!!Non-Anon rooms | !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||? | |||
|- | |||
|Jackal IM||?||?||?||?||? | |||
|- | |||
|M-Link x.xx||?||?||?||?||? | |||
|- | |||
|Metronome IM||?||?||?||?||? | |||
|- | |||
|Mongoose IM||?||?||?||?||? | |||
|- | |||
|Openfire||?||?||?||?||? | |||
|- | |- | ||
| | |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 | ||
|- | |- | ||
| | |Tigase 7.0.0+||Configurable per-room, default highest priority||N/A for multi-nick||N/A for multi-nick||to all sessions, NOT-marked with <x>||? | ||
|- | |- | ||
|} | |} |