Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

[MUC] Allow nicknames to be used more than once in the same room

Description

It is not possible to join an MUC room multiple times with the same nickname from different resources. This is a problem when using bookmarks (XEP-0048) to automatically join several MUC rooms. The resource that was first in there gets kicked! XEP-0045 says nothing about kicking users from the room in case of an nickname conflict!

More details in this forum thread.

XEP-0045: Multi-User Chat
7.1.10 Nickname Conflict
If the room already contains another user with the nickname desired by the user seeking to enter the room (or if the nickname is reserved by another user on the member list), the service MUST deny access to the room and inform the user of the conflict; this is done by returning a presence stanza of type "error" specifying a <conflict/> error condition:

Example 29. Service Denies Access Because of Nick Conflict <presence from='darkcave@chat.shakespeare.lit' to='hag66@shakespeare.lit/pda' type='error'> <x xmlns='http://jabber.org/protocol/muc'/> <error type='cancel'> <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </presence>

However, if the bare JID <localpart@domain.tld> of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource. If a service allows more than one occupant with the same bare JID and the same room nickname, it SHOULD route in-room messages to all of the user's resources and allow all of the user's resources to send messages to the room; it is up to the implementation to determine how to appropriately handle presence from the user's resources and how to route private messages to all or only one resource (based on presence priority or some other algorithm).

How nickname conflicts are determined is up to the implementation (e.g., whether the service applies a case folding routine, a stringprep profile such as Resourceprep or Nodeprep, etc.).

Environment

None

Activity

Show:

Daryl Herzmann 
April 12, 2014 at 11:17 AM

Hi Tom,

I asked in jdev about this and the prosody developer kindly shared his thoughts and implementation details. He agreed that the XEP is not clear on this situation. The next release of prosody will have further details on this as well. Hopefully further updates to the XEP will clarify what is to be done.

Tom Evans 
April 11, 2014 at 6:15 AM

Hi Daryl -

Sounds good, thanks for taking point to try getting some clarification on the specs.

Just to be clear, I am not broadcasting or exposing any additional information to the clients to implement the fix for MUC exit state. In the server we keep track of the number of connections by nickname, and when the number reaches zero (one actually, due to timing), then we send the regular "Unavailable" stanza as we have been doing all along. This seems to give us the correct behavior in the clients, where a single nickname is visible when there is at least one active session for the corresponding user.

In any case, certainly more testing and potentially some community feedback are in order.

Daryl Herzmann 
April 11, 2014 at 2:28 AM

Hi Tom,

I am not sure about this behaviour you coded in and agree that the spec is vague. I'll see about checking with the jabber folks about this and see about getting some clarity. I worry about the case when full JIDS are broadcast in the room and a occupants are not made aware of when this user actually leaves the room, this would be against SPEC I think.

Regardless, thanks for your hard work. This is a tremendous feature to have added to Openfire.

Tom Evans 
April 11, 2014 at 1:10 AM

Ok - changes committed to deal with the multi-connection exit scenario discussed above. Ready for more testing.

Daryl Herzmann 
April 10, 2014 at 11:34 PM

Hi Tom, Remember that the broadcasting of actual JIDs is an optional feature / has a permissions model. So some clients only see the nick and not that there are two plus JIDs behind it.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

Created October 16, 2008 at 2:06 AM
Updated October 28, 2020 at 11:02 AM
Resolved April 11, 2014 at 1:10 AM

Flag notifications