Bug 132608

Rename for clarity.

The problem seems that the command is not parsed but directly sent to the server. So /msg wont work, but PRIVMSG ... will do. The documentation should be fixed, it clearly states "/msg " as examle, the server response then is unknown command.

So it is not a timing issue but maybe a documentation / not parsed issue.

I rewrote "Commands" in SVN a couple of months ago - it does parse now. The timing issue exists regardless in a number of situations, though, so I chose to make this the bug for it.

I just noticed that the problem especially exists when a nickname is already in use. The auto commands are sent before the alternate nickname.

P.S. I am using 0.19 #3100, wich is the latest available for Kubuntu.

Rename to serve as meta-bug.

*** Bug 140696 has been marked as a duplicate of this bug. ***

*** Bug 144279 has been marked as a duplicate of this bug. ***

The same goes for auto-join. It should only be run after fully identified to services, which is not the case right now.

On freenode, the following happens:

== Main window ==
[Notice] -NickServ- This nickname is owned by someone else
[Notice] -NickServ- If this is your nickname, type /msg NickServ IDENTIFY <password>
[Notice] -NickServ- Password accepted - you are now recognized
[Notice] -kornbluth.freenode.net- NickServ set your hostname to "gentoo/developer/rbu"

== Channel window ==
--> You have joined the channel #gentoo-dev (n=rbu@i59F773B4.versanet.de).

  while it should be
--> You have joined the channel #gentoo-dev (n=rbu@gentoo/developer/rbu).

For the record: The reason we're not currently doing this isn't because we're lazy or because we're stupid, but because it's non-trivial, or rather because the only "solutions" are extremely unattractive.

Authentication on IRC is essentially unstandardized, despite multiple efforts to correct that problem over the years (the latest of which is IRC+, which we're involved with to some degree). There's no reliable protocol by which to authenticate and wait for success or failure. 

The first thought tends to be "so just delay that stuff by a few seconds". That solution is undesirable for a number of reasons:
* If the amount of time to wait is fixed and too low, it enters the realm of being unreliable; creating potential race conditions due to variable latency.
* If the amount of time is fixed and too high, it's detrimental to the user experience: Connecting to a network takes longer for (to the user) unclear reasons.
* If the whole thing is to be optional and the delay configurable, we're dealing with an ugly option cluttering up the UI.

A better solution what we're calling "the contingency waiting scheme", which roughly works as follows:
* If the Auto-Identify fields are filled in, the authentification command is sent as early as possible in the connection process. Similarly, if one of the auto-connect Commands matches one in a list of known authentification message patterns, it's singled out and sent first.
* Auto-join and the other auto-connect commands are deferred until a timer set to a fixed amount times out. 
* If a known authentification success message is received prior to timeout (checked against a white list), the timeout is pre-empted and auto-join and commands commence immediately. The same for a known failure.

The reason that solution is undesirable is that it opens up the Pandora's Box of trying to abstract all the different services implementations out there by collecting their replies and shipping the lists in the app, and keeping them updated.

The third solution is to defer the problem to the user: Add a scripting interface that allows power users to upload some code into the app that disables automatic auto-join/commands and instead triggers it when recognizes an incoming message as an authentification success. I find that degree of customizability/scriptability to be desirable and we will strive to attain it, but as a solution to this problem it's ultimately rather user-unfriendly.

Thus we're currently leaning towards option #2, but implementing it is definitely not our idea of a good time.

What's the status on this? I'm tired of typing '/join #python' on freenode because I get rejected.

My issue here is auto-join which is ATM totally unusable since all channels needing identification are flat out rejected.
99.9% of the time a 1000 ms delay between nickserv identification and autojoin commands is sufficient. I'm not in favor of defaulting to this delay, but please just make this delay user settable in either the 'edit network' dialog or the 'identities' dialog and make it default to zero, wich would reproduce current behavior while at the same time allowing for a trivial workaround. This will make things useable again while waiting for a more efficient solution.

On Freenode, you can use the network-specific workaround (although it has been adopted by other networks as well by now) of using the nickserv password as the server password, in which case the network will take care of it.

Thanks for the tip. I'll make use of it at once.

Lloeki, any reason to remove the CCs?

sorry, it was a mistake on my part. I was stupidly marveling at how the form worked and forgot to uncheck. apologies.

*** Bug 211462 has been marked as a duplicate of this bug. ***

*** Bug 225712 has been marked as a duplicate of this bug. ***

It would help if "/sleep <seconds>" was a valid command in the Command window.  That way the user could delay the automated sending of commands.  Many telephones/cellphones have a similar concept for speed-dialing, where "t<number>#" causes a pause of <number> seconds, useful to get past menues.  E.g. 555-555-5555t11#2t3#5t2#7  would successfully dial a number, wait 11 second, dial 2, wait 3 seconds, dial 5, wait 2 seconds, dial 7.

*** Bug 258415 has been marked as a duplicate of this bug. ***

*** Bug 266250 has been marked as a duplicate of this bug. ***

Okay. It might be helpful if this information could be hinted at in the Identity dialog. Currently the user experience is suboptimal, too.  It could also enter the handbook.

in konversation:
f2 (quick server list) > Freenode Server > under that irc.freenode.org <<---- there Edit.
enter your password there, and it helps

To expand on what Alex has said, and to provide information on what has changed in the next release:

- Authenticating via the server password is indeed supported by several networks. On Freenode, you can also enter "accountname:password" (with the colon but without the quotation marks) as the server password to authenticate independently of the nickname you are connecting with.

- To make this easier to discover the 1.5 release has a new Auto Identify UI in the Identities dialog. You can now choose among several types of authentication there, including "Server Password". If the server password is set via the identity this way, it will override the server settings.

- Additionally, we now support SASL PLAIN authentication, also configurable in the Identities dialog. This is now the recommended method to authenticate with services on networks that support it, including Freenode.

- And the "Standard NickServ" authentication type has been improved as well, making the command configurable (previously hard-coded to "identify").

- We also have plains to add support for authenticating with client certificates soon, supported e.g. by OFTC. At that point we will support basically all authentication options supported by networks today.

*** Bug 310839 has been marked as a duplicate of this bug. ***

*** Bug 311540 has been marked as a duplicate of this bug. ***