Allow takeover of a MUC nickname if it's by the same account that owns the nickname


With BOSH based implementations, you find yourself left with sessions that "hang around" for a while. In theory browser based apps can just log out, cleaning up the session. However, browsers crash, and the sessions can get "stuck". As a result, you may reconnect and end up having a nickname conflict that you can't get rid of because the old session is still around. What this issue will address is the ability for, if there's a nickname conflict but it's owned by you, allowing you to take over that nickname. (you "kick" the original instance and take it over basically) The original login, if it's a real login, will see a kicked message indicating that they got booted because they logged in from a different location.




Pedro Solá
November 13, 2013, 2:28 PM

Correct me if I'm wrong, but it seems to me this functionality goes against the XEP-0045 (7.2.9) Nickname conflict spec.

It states:

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 this spec were followed it would resolve the original problem described in this issue.

But the real reason I'm commenting on this is because the current implementation is causing me problems. To describe my setup: I've got a MUC running over BOSH on my website. I'm "pre-initializing" the sessions, to avoid prompting the user for a password. Every time the user opens a new tab, a new session is created, and is kicking the other sessions.

What do you think about the spec? Can you recommend a workaround for me?


Your pinned fields
Click on the next to a field label to start pinning.


Daniel Henninger


Daniel Henninger