Forums Bug Reports Autojoin of channels with +r

I don't think it is fair to suggest that Khaled has not been listening.

But the diversity of suggestions is great!!

This is something that I am completely against, for reasons that I have already explained in my previous posts. I will not make such a feature work based on checking for specific words in an event. Implementing a feature in this way is worse than using a server version number to decide whether to enable certain client features, which is what numeric 005 was meant to resolve.

The current issue is due to this feature being badly implemented on the server side. The server coders implementing this should have realized that clients need to have a clear way of detecting events like this, as opposed to requiring clients to implement hacks that can break across languages, ircds, ircd versions, and so on.

Raccoon pointed out that there are several different usermode +r alternatives, so mIRC would in that case have to cater for multiple different representations of usermode +r based on server version numbers.

I agree with Khaled about not coding something that has to detect different language strings or which uses e.g. modes which are not standardised.

But as posted in a comment above, I believe that this can be coded without either of these based only on:

1. User's mIRC Server settings for automated authentication;

2. Use of Nickserv response strings which are NOT language specific (like "/msg Nickserv" which are IRC commands and don't differ between languages) to identify Notices from Nickserv that should be ignored.

3. Assuming that user's mIRC server settings are correct and server is working correctly (which will be true 99.9% of the time) and so user will be authenticated ok and assuming that Nickserv notices not ignored by 2. are confirming authentication - but handling with a lengthy timeout the situation when this is not the case. (If Notice is a failed authentication, then we should still attempt a /join.)

With this approach you will not need to code for:

• Language strings
• User modes

So, the only method that will work for now, that is language-independent, seems to be:

1) After the MOTD is received, check incoming notices from "nickserv".
2) Ignore the notices if they contain "/msg" or "/nickserv".
3) Otherwise, assume it is a notice indicating success or failure of nickname identification, so trigger perform.
4) If no such notice is received after 60 seconds, trigger perform.

However, this will fail if an ircd changes the text in notices eg. there is no reason why a server could not say "visit this website" or "join this channel" to learn how to register/identify your nickname, instead of specifying /msg or /nickserv. This will also fail if nickserv sends any other notices eg. it could send notices informing users of other features or recent developments.

This change will be in the next beta.

IMO all of that would be a mistake. The suggestion of the three second delay should work fine.

Perform finishes > 3 second delay > Autojoin.

All of this other stuff of waiting for NickServ and +r mode is what scripts are for.

Just my 2 cents.

RoCk - in my experience (with 45+ years programming experience) any solution as simple as waiting for 3s will only work the majority of the time - maybe even most of the time.

But there is only one thing worse than something which doesn't work - and that is something that mostly works but sometimes doesn't. Intermittent problems are the worst type by far, because the cause can be incredibly difficult to work out.

And a simplistic solution that waits only 3s would have a significant number of intermittent failures. For example, I would think it highly likely to fail when a netsplit had occurred and hundreds of IRC clients were automatically logging in and authenticating at the same time.

To handle this, you have to increase the timeout substantially to cope with those (say) 10% of situations where it takes >3s, but that means all the automated joins have to wait for that period - and then the functionality becomes useless because people will turn it off.

So you need a deterministic solution which copes with hiccups but doesn't delay the autojoins - and the proposed solution is the simplest we have come up with so far which does that.

Khaled - I think you are being a little pessimistic here (though that is of course your job as designer/coder).

We are only talking about user settings for a server where they want mIRC to authenticate for them (as opposed to i.e. using perform or a script). You would only use this if the server supports /msg nickserv, /nickserv or SASL. (So e.g. Undernet X is NOT supported.)

It is possible that Nickserv may have been changed on a particular IRC network to do something non-standard, but that would be ... well, non-standard and so mIRC should not be expected to handle it.

So, providing that you only look at notices from nickserv (and not from any other services which might advertise before authentication), and providing that you check for "/msg nickserv" and / or "/nickserv" (which are what mIRC uses - so let's not check for anything wider), and providing that nickserv sends a notice for success or failure of authentication (i.e. doesn't not say anything), then this should work pretty reliably IMO.

I would also suggest that if 4. happens, then mIRC should put some sort of explanation up in the status window so as to prompt the user to fix the configuration (by e.g. switching to perform or a script).

P.S. My testing showed that SASL 903 response came much earlier in the connection than nickserv, but I am unclear whether that is because SASL is synchronous or just because it is significantly faster. If SASL is synchronous authentication (as opposed to nickserv which is asynchronous) then we don't need something similar to this proposal for SASL - but if SASL is asynchronous then we probably need the same sort of solution. The SASL specs should be able to clarify this.

However, if you are looking for a simpler solution and I believe it is effective and that it minimizes this problem to all users on any network, then you have to create an option in the mIRC Favorites dialog that allows you to customize the time of entry into the channels when we do the network connection.

You have missed the point of my previous email - if you work only on a timer there is NO single timer value that gives you a prompt autojoin and which works reliably when nickserv is running slowly. You need a deterministic solution.

He already stated that this issue is caused by the bad implementation of a feature on server side, should he add a workaround (hack) for every dumb little thing some server adds? The 3 second delay was workaround enough, make it 10 seconds if that's what it takes. If the delay solution is overly simple, then the other solutions mentioned before are way overly complicated.

A scripted solution is what's needed.

IRC is full of badly implemented features. That is real life.

But this is not (really) one of them - nickserv is asynchronous - which is a reasonable thing if you want people to be able to start off unauthorised and then authorise at a later date. (SASL by comparison assumes you authorise at connect time.)

When you have an async service, you need to have functionality that takes that into account.

Yes - we could have a fully scripted solution and not have mIRC provide any nickserv authentication functionality - and then expect every user to write the script necessary. But Khaled chose to provide nickserv asynchronous authentication , so this is fixing up an issue with it properly.

Or in other words, Khaled is going to create a proper solution not a Kludge which will fail intermittently and create a support headache.

It is called experience :-) As I mentioned, mIRC already needs to check for specific strings in certain numerics due to those numerics being used for different features on different ircds. These have had to be updated several times already. Unfortunately, it takes a long time for someone to notice that mIRC's behaviour has changed due to an ircd changing wording in a numeric - especially if the change in behaviour is subtle. In the meantime, mIRC would actually be doing the wrong thing in such a situation.

Depending on words in a server message along with the order of server events is not a reliable, long-term solution.

As I said, pessimism is part of the job - exactly for the reasons you describe.