Support Nickname changing #2

Closed
mweibel opened this Issue Aug 5, 2011 · 28 comments

Projects

None yet

6 participants

@mweibel
Member
mweibel commented Aug 5, 2011

We should provide an easy way to support nickname changing.

Basicly there are two steps to do:

  1. Support e.g. Candy.Core.Jabber.Action.NicknameChange
  2. Maybe also something in the gui, although this could be done with a plugin or so
@pstadler
Member
pstadler commented Aug 5, 2011
  1. Agreed. Let's add a method called Candy.Core.Action.Jabber.SetNickname().
  2. Since we don't want to clutter up the UI / UX, this feature should be implemented as a plugin.

We need to clarify if a nick change would have an impact to the roster and user handling in general.

@aadityabhatia
Contributor
  1. The config object passed to Candy.init() should contain a "defaultNick" property under CORE_OPTIONS, which will be particularly useful for assigning names when using sasl_anon authentication.
  2. "Nickname" can be a part of the login screen that prompts for XMPP ID and password. At this time the assumption is that XMPP ID's username part == nickname. Since this is not the desirable behavior in many cases, it is the best to let the user land in a MUC with the desired nick instead of having to go through a nick change afterwards.

I agree with implementing this feature as a plugin. Firstly, it will keep the code modular and clean. Secondly, it will allow restricting nickname changes by disabling the plugin, which might be desirable.

@wescleveland

I could use this asap so if you want me to test on my site just send me a message

@pstadler
Member
pstadler commented Aug 5, 2011

@dragonsblaze: Thanks for your response.

However, integrating this feature as a core option is most likely not the way to go. There are better ways to offer this functionality without unnecessarily bloating the core.

I'm totally aware of the different use cases, but at the same time I think that choosing a nickname - which is not related to the jid - even before connecting isn't very common. Pre-binding and Candy.Core.attach() might solve your problem. There's a good article about this topic: http://metajack.im/2008/10/03/getting-attached-to-strophe/

@pstadler pstadler closed this Aug 5, 2011
@pstadler pstadler reopened this Aug 5, 2011
@mweibel mweibel was assigned Aug 6, 2011
@mweibel
Member
mweibel commented Aug 6, 2011

@dragonsblaze: Your idea could be easily implemented by yourself (maybe as a plugin, too) by listening to the CHAT-event which happens when a new status (like connected, attached etc.) is happening. Take a look at core/event.js and view.js / view/observer.js :).
Of course first the setNickname command has to be supported, which I'm currently implementing.

I ran into an issue with implementing the SetNickname command:

  • User A and B are chatting in a private chat
  • User B changes Nickname
  • User A loses track of User B in private chat because he's chatting to room@conference.server.tld/B and not to B@server.tld
  • B still has the private chat to A open and does also have to history in it (and can also chat with user A again).

That's a little bit weird and I don't know yet how to resolve this.

@mweibel mweibel closed this Aug 6, 2011
@mweibel mweibel reopened this Aug 6, 2011
@pstadler pstadler closed this in b6680d4 Aug 6, 2011
@pstadler pstadler reopened this Aug 6, 2011
@pstadler
Member
pstadler commented Aug 6, 2011

it fixes #3. too late to apologize.

@pstadler pstadler closed this Aug 6, 2011
@pstadler pstadler reopened this Aug 6, 2011
@pstadler
Member
pstadler commented Aug 6, 2011

What a disaster. I can haz removed teh button?

@aadityabhatia
Contributor

Thank you @mweibel and @pstadler. I agree that adding nickname option to the login screen would be an overkill for the core functionality, so it makes sense to add this as a separate plugin, continuing the modular approach that's been applied to the project so far.

However, allowing for a default nickname under CORE_OPTIONS will improve the overall UX. Here's an example:
Anonymous users entering the demo on the project page are taken by surprise, since they are not used to being addressed by random numbers (connection.stream_id). A typical user wants to see names, and not numbers, talking to each other. Speeqe got this part right in their random nickname generator.

I disagree that this will bloat the core, since this change involves adding very few lines to Candy.Core.Action.Jabber.GetJidIfAnonymous() for good. That said, it entirely depends on the overall direction of the project.

if(Candy.Core.getOptions().defaultNick) {
    nick = Candy.Core.getOptions().defaultNick;
} else {
    nick = connection.stream_id,
}

For the demo and default out of box behavior in example/index.html, adding a random nickname generator's output to the core options passed to Candy.init() will do the job well.

@pstadler pstadler reopened this Aug 7, 2011
@mweibel
Member
mweibel commented Aug 8, 2011

I created a working branch issue2-nickname because it will take some time to implement it, as it's not that easy.

@dragonsblaze: Regarding defaultNick: I'm not sure if it's really that important, but your right, it's a small improvement with only a few codenames to change.
But: I spot a problem, because for e.g. our Demo it would be neat to have a little more identifying nicknames (autogenerated). But is that really the real use case? I mean, for "normal" installations (with anonymous support) it would be a lot better if the user could enter a nickname he wants to use.

What bothers me also is: what to do when two users connecting would have the same nickname? This logic needs to be added as well.

@wescleveland

For my site it would be perfect for users to be able to enter a nickname if they anonymously connect. Even better, let me make an anonymous connection but pass in a username as a parameter in the connection. If it is a duplicated username, just append a count to it, user, user2, etc... For your basic anonymous chat room I think it would be great for the user to be able to choose a username easily. For communities, just letting the community software pass a username parameter would be really useful.

@aadityabhatia
Contributor

@mweibel:

  • I'd say it's more practical to let the user enter a nickname before they join, instead of assigning them a random one at all.
  • If a nickname is already taken, it's the best to prompt and not allow that nick-change. If the nick-change is allowed with appended digits, many users will easily overlook the fact that they have a nickname very similar to another occupant.
  • In regards to the private conversation issue that you mentioned above: If users A and B are in a private conversation and B changes their nickname to C, A will receive a presence packet from room@example.com/B with code 303 and an attribute "nick" with value C. Assuming that A is using Candy, the PM tab in A's Candy session needs to update the pointer from room@example.com/B to room@example.com/C. While it's better if the messages are sent to the exact XMPP ID, e.g. b@example.org instead of room@example.com/B, XMPP ID is not always available to the occupants of a MUC.
@mweibel
Member
mweibel commented Aug 11, 2011

@dragonsblaze & @wescleveland: yeah I also think that prompting for the nickname is better for the user experience. And re-prompting if nickname is already taken would be the better idea, as dragonsblaze mentioned.

Regarding private conversation: We used the room@example.com/B solution because then we know if a user is online or not (in our use case, we don't store offline messages).
The thing with the presence packet is right and I already implemented a little bit of it to do that change of the pointer.

As I'm currently busy with exam preparation it will take some time to implement it. But as usual, you're welcome to contribute :)

@Trandel
Trandel commented Sep 1, 2011

Hello i was wondering if its possible to use "user name" field in openfire instead of jid ? It would help me a lot because usernames can have utf-8 characters.

@mweibel
Member
mweibel commented Sep 1, 2011

@Trandel: Not sure what you mean? Could you explain a little bit more?

@Trandel
Trandel commented Sep 1, 2011

In my openfire admin panel i have users and those users have several fields: "username" (jid), "email", "creation date", "name" etc. Im using external DB to fit those fields. My problem is that i have a web-besed game where are two field that im puting into openfire users list. First is login that i used for "username" and second is player_name witch is used in "name" field. What i would like to do is to display in chat only "name" not "username". The "name" field has special characters for my language. Is it possible to get "name" from openfire and use it in Candy as nickname showed in list etc. ?

@pstadler
Member
pstadler commented Sep 1, 2011

@Trandel:
To keep Candy simple (codebase and usage) we won't implement this feature, but our target is to support UTF-8 JIDs and therefore UTF-8 usernames. See issues #24 and #17.

@Trandel
Trandel commented Sep 1, 2011

@pstadler:
That would help a lot. But as far as i know i can't have utf-8 JIDs with spaces in my openfire server. Ok if i can't make it in Candy can I preBind those names in PHP and set it to Candy?

@mweibel
Member
mweibel commented Sep 1, 2011

@Trandel: as far as I know it's not possible to prebind those names in php. But as soon as this feature (nickname changing) is implemented, you could set those names as the nickname shortly after connecting (before any rooms are visible should be possible)

@aadityabhatia
Contributor

@Trandel: You may want to look at this simple workaround for specifying a default nickname before entering a MUC, until we have the support for changing a nickname during the chat:
dragonsblaze/candy@86da861

@mweibel: This change is literally 3 lines of addition to the core. Please consider incorporating this into candy to improve the out of box behavior and make the nickname changing issue less urgent.

@Trandel
Trandel commented Sep 2, 2011

@dragonsblaze: Thanks for simple solution, but i need to ask one thing. Is it posibble to set nick when user isn't connected as Anonymous?

@mweibel: Any plans when the nicknames will be implemented?

@mweibel
Member
mweibel commented Sep 2, 2011

@dragonsblaze: well of course it's only three lines, but we really want to keep the codebase small, even if it's only a small change. A lot of small changes are still a lot of lines of code.

Regarding the nickname changing: I really hope I can work on it today or at least next week again.

@mweibel mweibel added a commit that referenced this issue Sep 5, 2011
@mweibel mweibel nick change support: change user objects & DOM element attributes; ch…
…ange roster items

still todo: private chats

references #2
8a598db
@mweibel mweibel added a commit that referenced this issue Sep 8, 2011
@mweibel mweibel privateRoom nickchange works
still one thing left to do: User A is chatting privately with user B. User A changes nick to C. User B and C chat now with each other. If User C (aka A) leaves the chat, joins again (as A), changes the nick to C and chats with B again, B is in trouble because he has now two private chat tabs opened with the same nickname and this causes a bug

commit is regarding issue #2
43e9068
@mweibel
Member
mweibel commented Sep 29, 2011

Status update:
As you see in the commit #43e9068 there's one problem left to solve and I'm not really sure about how to solve it at the moment. Needs some thinking :)

I changed my mind regarding @dragonsblaze's feature request about the initial nickname change support. I will implement that as soon as possible.

I'm currently pretty busy, that's why I can't work a lot on it.

@aadityabhatia
Contributor

@mweibel It's implemented in 86da861. For a live example, try www.eagull.net.

@mweibel
Member
mweibel commented Oct 3, 2011

@dragonsblaze: I implemented my fix a little different, hope you can live with that :)

@ghost
ghost commented Oct 3, 2011

I have tried #96e74e6. However, with a Login always there comes "Authentication failed" - I don't know where the problems lie. Can somebody give me German Support? I do myself a little bit hard. :D

@mweibel
Member
mweibel commented Oct 3, 2011

@longiweb: send an email to the candy support mailinglist, One of us can answer you in german.

@ghost
ghost commented Oct 3, 2011

@mweibel Thanks for your comment. Up to now, unfortunately, I could find no e-mail address.

@mweibel mweibel added a commit that referenced this issue Oct 5, 2011
@mweibel mweibel issue #2: fix nickname setting on anonymous connect (jid is set by th…
…e server, Candy needs to retrieve it first in order to be able to connect)

otherwise, a non-anonymous connect is used and this can lead to being not able to connect
fea688d
@billionssg

"In my openfire admin panel i have users and those users have several fields: "username" (jid), "email", "creation date", "name" etc. Im using external DB to fit those fields. My problem is that i have a web-besed game where are two field that im puting into openfire users list. First is login that i used for "username" and second is player_name witch is used in "name" field. What i would like to do is to display in chat only "name" not "username". The "name" field has special characters for my language. Is it possible to get "name" from openfire and use it in Candy as nickname showed in list etc. ?" quote by Trandel

please i have same problem with Trandel, i want to show my nickname with "name" in my openfire. At this time, my nickname is displayed with "username". Somebody help me please

@mweibel
Member
mweibel commented Jan 8, 2014

Closing this in favor of discussion in #205

@mweibel mweibel closed this Jan 8, 2014
@mweibel mweibel added a commit that referenced this issue Jan 10, 2014
@mweibel mweibel Support for changing nickname
This finally fixes issue #2 and is a result of
the combined effort of many contributors. Thanks!
1084b1f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment