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:
However, if the bare JID <email@example.com> 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.).
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.
Ok - changes committed to deal with the multi-connection exit scenario discussed above. Ready for more testing.
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.
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.
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.