Difference between revisions of "Multi-Session Nicks"

Jump to navigation Jump to search

Multi-Session Nicks (view source)

Revision as of 08:07, 28 February 2019

688 bytes added ,  08:07, 28 February 2019
m
no edit summary
(Update ejabberd's implementation status.)
 
m
(16 intermediate revisions by 3 users not shown)
Line 10: Line 10:
* [https://www.ejabberd.im/ ejabberd]
* [https://www.ejabberd.im/ ejabberd]
* [http://isode.com/products/m-link.html M-Link]
* [http://isode.com/products/m-link.html M-Link]
* [https://igniterealtime.org/projects/openfire/index.jsp Openfire]
* [https://igniterealtime.org/projects/openfire/ 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.
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 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 (the MUC can't know if the user's server supports Carbons, and if they are enabled on all joined clients)


'''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 (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


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 <del>should tag it with <x/> (to let their server know)</del> (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 =
= Non-anonymous rooms =
Line 56: Line 71:


{| 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||?
|-
|-
|ejabberd 15.07||?||to highest-prio||marks PMs as such, doesn't keep track of joined MUCs||?
|M-Link x.xx||?||?||?||?||?
|-
|-
|M-Link x.xx||?||?||?||?
|prosody 0.9 - 0.10||forwards all||?||to IQ sender||to ?, marked with <x>, carbon prevention||?
|-
|-
|prosody 0.9||forwards all||to IQ sender||?||keeps first-joined resource
|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
|-
|-
|}
|}
Neustradamus
216

edits

Retrieved from "https://wiki.xmpp.org/web/Special:MobileDiff/4795...10950"

Navigation menu