Forums Feature Suggestions $isoper

I would like to see an $isoper identifier (or something similar) where the IAL records those that are irc operators

For what purpose? Each network has a specified channel where opers provide assistance. Opers not there generally are not helping users. The only reasons I've heard for such oper scanners are for spammers to know when to stop spamming.

That said - a simple whois and raw event will have the same effect. The IAL stores addresses only, so on networks where opers have a dedicated oper hostmask, you can use the IAL already. What you suggest would require the IAL to be expanded with additional information. I don't know exactly how the IAL is coded into mIRC, but I imagine there's no room for additional information other than the actuall address.

That can be identified in the Raw 313 command

Having it as a built-in identifier would mislead people into thinking the identifier was reliable, but there's no way it could be. Oper'ing up/down doesn't create any notification for other users (except perhaps some other opers with the right usermode).

The purpose I would want to use it for is to emulate what many scripts for text based clients do (ircii, bitchx and irssi) where they put a * in front of the nick of an oper when he/she says something. And also put a * in front of their nick in the nick list or even change the color of their nick. As an oper it would make things a little easier for me. I can script it myself since /who /whois and /userhost all show if they are an oper or not but it would have been easier if there was an identifier for it. I was not looking for any modification of the IAL. Just as you can do $ial(N/u@h,N).pnick or $ial(N/u@h,N).idle or $ial(N/u@h,N).mark, it should not be too hard to add $ial(N/u@h,N).isoper or something like that. I could just use the .mark to mark the address and update it with /who #channel . I know it would not be completely reliable because there is a lack of notification.

Really saying: So I know who is an operator so i dont mess with them or takeover a channel they are in



Wheter you script it, or mirc does--that traffic that sends all that information is still neccisery. its not like mirc has a command only the program can send tot he irc like "ISOPER :nickname". Again, I see no real relivance to having this feature other than a protection for screwing around. if you need to know who an oper is, go into #help, #ops, or your networks facsimile

I refer to earlier posts where it's said that opers when they connect have the chance to turn on their o:line or not (opering up). If they don't, they're still opers, only there's no way in heck you can tell...

good point some ircds allow u to hide the fact your an oper on that network ..... which would make anything mirc can check for virtually impossible. i mean really this feature is pretty similar to wanting an $isaway identifier. it would have to be implemented at ircd level and then mirc could support it. mirc cant support a command or identifier that is server level unless its actually inbuilt into the server

Even though I agree with everyone who has said that an $isoper identifier would be useless and/or unreliable, I must say that I am tired of replies like this one, in which some people find the "possible" malicious use of a new feature and try to judge the person who proposed it.

I mean, come on, sometimes somebody proposes a new feature that might be useful (even though the vast majority of times it isn't), and instead of explaining why it isn't useful, or why even though it is, it shouldn't be added, some of you start attacking by judging the person, when you don't really know if they intend to use that feature in a malicious way.

I weas more or less judging the suggestion, not the person. Anyways, I've yet to see a realistic reason for having this form of identifier. All they've mentioned is to add a * prefix onto the name. I dont see a reason why you would need a prefix other than to say "hey's there's an IRCop".

Again, if you want to know an IRCop, either navigate yourway to #help, #ops, etc--or /whois them.

I am an oper/admin on efnet and have no malicious intent with it but I do see your point of someone using it for malicious things. I will wind up scripting something one way or another (through /who, /userhost, /whois and /ialmark ) but it would have been easier for my scripting if there was an identifier. It's no big deal though

If you are on a network where it prefixes the oper's nickname with a * in the nicklist (/names), then you can use the following code to identify and enumerate the opers in a channel.

echo -a $nick($chan,Raccoon,*)
echo -a $nick($chan,%i,*)

As far as adding an $isoper identifier or IAL property, I think this would only encourage more users to "On Join /WHO $chan" which is extremely resource intensive on IRC servers, especially when popular scripts impliment this. What's worse, because opers can Oper-Up/Down, users may feel it necessary to now /WHO $chan every 30 seconds to keep on the cutting edge of Oper-Watch.

A single /WHO $chan in a 100 user channel, is the same as someone speaking 100 lines of above average conversation length. To have 100 users all doing this when they join said channel, equates to TEN THOUSAND lines of wasted bandwidth which adds up for IRC servers in the amount of gigabytes a month, terabytes if said script were used by -every- user.

Now imagine if they each did /WHO every 30 seconds or 5 minutes even.

I think the popular scripts already do a on JOIN /who $chan, simply to get the IAL going.

There are also many IRCDs that are stepping outside of the original RFC, such as Unreal IRCD (pretty common on many small networks) that now use other mode prefixes to identify channel operators on a channel. * happens to be one of them. if a * were to be used in mIRC's client, then it would mistake these users for IRC operators.

If there are ways for IRCOperators to block users from knowing who they are (a who reply has a * in generic replies that show IRC Operator status, I think these text-based clients use that in their modes), then those operators do have their right to privacy.

My scripting auto /whos on join. Probably slows down joins quite a bit, but ahh well