13
edits
Difference between revisions of "Multi-Session Nicks"
Jump to navigation
Jump to search
no edit summary
(→Private Messages: updated with optimal behavior patterns) |
|||
| (11 intermediate revisions by 3 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 39: | Line 43: | ||
* 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 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 | * 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 == | == Optimal XMPP server behavior == | ||
* a server should not carbon-copy incoming MUC-PMs to other clients ( | * 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, | * 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 == | == 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 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''': | * when receiving a '''"sent" Carbon''': | ||
*# determine whether the bare JID is a MUC | *# determine whether the bare JID is a MUC | ||
| Line 56: | Line 62: | ||
*# determine whether the bare JID is a MUC | *# 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 not joined, '''ignore or offer to join the MUC''' | ||
*# if this client is joined, ''' | *# if this client is joined, '''ignore''' (the MUC will send a forked message to you anyway) | ||
''' | |||
= Non-anonymous rooms = | = Non-anonymous rooms = | ||
| Line 73: | Line 78: | ||
|- | |- | ||
|ejabberd 15.07||forwards all||to highest prio||to highest prio||to all sessions, marked with <x>, no carbon filter||? | |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||?||?||?||?||? | |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>||? | ||
|- | |- | ||
|} | |} | ||