James Hess wrote:
ACC 1 simply means the user is registered but either is not recognized as Even if enforce is enabled, a non-recognized user should be 'ACC 1' for the 60 second grace period to ID, until enforcement forces a nick collide.
That's what I said, it doesn't matter for services if the nick is [being] enforced or not.
Unsecure is currently broken but it'll make sense to let unsecure override ident (for the founder nick only).
Ignoring what it does currently. And it's hard to say for sure, as the detailed design documentation for services, like formats/design of channel access records, has never been made known to us.
It doesn't do anything at all (besides showing "UnSecure" on ChanServ INFO). It was supposed to do what the help text says (/ChanServ HELP SET UNSECURE).
But... Logically, turning on "UNSECURE" should provide access to every ChanServ command to the founder (except special ones like drop / set founder,). When UNSECURE is on and one of these are true: *If IDENT is disabled, when the channel is currently registered to an address mask instead of a NickServ nickname , and the online user matches the Founder address mask/pattern that was set. *If IDENT is _disabled_ , an actual NickServ nickname is listed as founder, and the online user is ACC 2 or higher to the founder nickname (through an access list match or identify). *OR: If IDENT is enabled, and the user is identified to the founder nickname
If UNSECURE is off, then all founder-level commands, such as 'SOP', 'SET', , etc, should require identification with ChanServ, regardless of NickServ ACC level.
That's an intersting idea, although if people don't trust themselves with founder access, they can add their secondary nick as SOP/AOP (I know a few founders are already doing it).
That a new list, or rather, 'founder flag or level' for the access list of some sort should be in order.
I would suggest a /ChanServ MANAGER command. which would work the same way as the SOP, AOP commands.
But provide most founder commands to a person identified with NickServ on the list, and have all other SOP properties.
Interesting idea, what do others think about it?
Perhaps a 'MODEFLUSH' and 'MKICK' ircd command for U:lined clients only would be in order (the name of the commands isn't important), to assist services, and reduce its need to track new types of state information, regarding new/future IRCD features that might impact MKICK, MDEOP, etc.
Bahamut 1.8.4's old trunk used to have CHANKILL that did the same but it never came into the official release, I'll see what we can do to bring it back. -Kobi.