Dear Khaled,

Long Long ago on an RFC far far away, ISON helped establish a means for users to be notified when their friends come and go from IRC. It has been an essential feature on so many clients and has kept people in touch for years.

However, the ISON command itself is rather deprecated, as it has limited functionality and consumes unnecessary network resources.

Most of the mainstream IRC Networks and Daemons support the MONITOR command, which is far superior to ISON as it provides for immediate updates to the client and only requires one-time-use instead of polling the server every 30 seconds.

Those networks that don't support MONITOR, may prefer WATCH instead, although WATCH has become deprecated in its own right it is still a superior alternative to ISON with the same client and network benefits.

Since mIRC is still the mainstream IRC client among Windows users, and with some Linux/Mac users (via emulation), the network resources that it uses does matter. The ISON commands may be small, but they are frequent, and its elimination could save gigabytes of network traffic over the large scale. This would be especially well received by small IRC servers with limited resources.

I would like to see it made a preference, at least.

I would also like to see that MONITOR, WATCH and ISON replies can be used within scripts. At present, it is not possible to hook ISON replies with the RAW prefix. I hope that MONITOR and WATCH would not be restricted from scripts as well.

I've never heard of MONITOR, but WATCH support was added in v5.51

I know MONITOR is supported on both Freenode and EFNet, usually regarded as two of the most popular networks. WATCH is supported by neither.

EFNet is Ratbox, Comstud, based on Hybrid IRCds.
Freenode is IRCD-Seven, based on Charybdis Atheme.

It's more than a little popular. WATCH will not be implemented in these.
(first hand statement when asking their developers)

Yeah, since I wrote that post I did a bit of digging around and found the IRCv3.2 proposal for it.

I don't mean to hijack the thread, but can I use this to suggest a related feature?

It would be great if we could enable/disable the notify list only on certain networks.

/notify on - enable on all networks.
/notify off - disable on all networks.
/notify on dalnet - enable on dalnet.
/notify off dalnet - disable on dalnet.

If this was implemented we could at least disable the notify list on networks that support monitor and script our own implementation of monitor.

As it stands right now, we would have to rewrite the entire notify feature.

You can disable Notify for specific networks, as an implied feature of setting specific networks on all of your Notify entries.

That is, if you want to turn off Notify for EFNet and Freenode, make sure all your Notify entries specify Dalnet, Undernet, and QuakeNet. Though, perhaps it's not possible to specify multiple networks per entry.

I would like to see comma delimited lists in Notify fields, too.

That would disable the feature for all networks other than the specified ones, rather than only stopping it on specified networks (i.e. whitelist-based rather than blacklist-based).

If you could enable/disable the notify list on a per-network basis then it would enable us to write scripts for others to use.

I was just looking into MONITOR and noticed that EFnet limits the MONITOR list to a maximum of 60 nicknames. I am a little worried that this will be too small for many users. I remember when I first implemented WATCH support, quite a few users were unhappy because their notify list, which worked fine with ISON for many years, was larger than the 128 nickname WATCH limit on some networks. A limit of 60 nicknames would almost certainly result in a large number of unhappy users. Freenode currently has a limit of 100 nicknames, which is a little more reasonable. In any case, I have added support for MONITOR to my to-do list.

Would it be overly-complicated to have mIRC do the first however many is supported using the MONITOR command and the remainder using WATCH/ISON?

That would be too complicated. Perhaps the best way to implement this is: if the MONITOR/WATCH limit is N users and your notify list has N users or less, mIRC will use MONITOR/WATCH, otherwise it will use ISON. This would ensure that IRC servers benefit from the decreased bandwidth usage for the majority of their users but for those users who need more nicknames in their notify list, the notify list will still work. I will be experimenting with this over the next week or two.

Sounds good to me!

Thanks for the follow-up sir! I'm pretty excited about this one actually! (It means I'll be able to recapture my nickname on EFnet as fast as the other bots competing for it.)

Did this ever get implemented?

I see ISON commands going to Freenode, Undernet and irchighway.

Freenode is a failure. Not too long after mIRC added support for MONITOR, freenode inexplicably disabled its MONITOR command. They've allowed it to remain in their 005-response, illegally.

Addendum: I'm informed that Freenode corrected its 005 response indicating explicit MONITOR support, a few months ago, but it still gives implicit MONITOR support which mayormaynot be confusing to some clients.

I can confirm that MONITOR is no longer in the freenode 005 response.


AFAIK there is no way to tell mIRC that MONITOR support is available if the 005 doesn't indicate it.