Version: (using KDE 4.3.5) OS: Linux Installed from: openSUSE RPMs I put "nickserv" for service and my password in the "Auto Identify" boxes in the "Identities" dialog for my nick so I guess that's setup as it should be. Nevertheless konversation always joins the channels before it identifies to the server. Noticeable is that this happens always since I use SSL with freenode while, without SSL, it happened only most times but not always. Problem is that this behavior is pretty annoying for channel that require registration like e.g. #centos since one gets redirected to #centos-unregistered all the time (same e.g. with ##linux). Last but not least it constantly leaks the real hostname this way instead of simply showing the cloak. Proposed solution: Simply let it wait 1-2 seconds after issuing the identify command and only after waiting join the channels. Should be easy to implement / change and isn't annoying since a delay of 1-2 seconds shouldn't do any harm. Log: [12:04] [Notice] -NickServ- This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify <password>. [12:04] [Notice] -NickServ- You have 30 seconds to identify to your nickname before it is changed. [12:04] [470] my_nick ##linux ##linux-overflow Forwarding to another channel [12:04] [Channel] Cannot join channel (+r) - you need to be identified with services [12:04] [470] my_nick #centos #centos-unregistered Forwarding to another channel [12:04] [Notice] -NickServ- You are now identified for my_nick. [12:04] [Info] 'unaffiliated/my_nick' is now your hidden host (set by services).
ADD: An even better solution would be to wait for the response from the irc server - like the [12:04] [Notice] -NickServ- You are now identified for my_nick. line above and only then try to join the channels instead of waiting a fixed time after issuing the identify command. However, I have no idea if that line is the same across all servers or if they return a more machine readable response instead of some human readable string.
See the other bug for more info, including effective workarounds on Freenode and similar networks (comment #11 there). *** This bug has been marked as a duplicate of bug 132608 ***