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.
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. 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. We already have an 'IDENT' option for dealing with nickname identification level issues. It is good for IDENT to be on by default. Perhaps there should simple be a 'SECURE' option enabled by default and discard both IDENT and UNSECURE options, and then, matters would be simpler. I suggest that all channels be forced to either enable IDENT or turn off UNSECURE, by making UNSECURE automatically disabled for any channel with IDENT disabled, "ACC 2 to a founder nickname to utilize founder commands" is asking for trouble. We should be clear on what additional protection channels have when UNSECURE is off. In the above implementation, the benefit of having UNSECURE disabled: * Someone who guesses a founder's NickServ password only gains effective SOP access. The worst possible thing they can do is /NickServ DROP the nickname; which does not delete the channel. * Someone who gains access to the founder's computer with an idle IRC session identified to the nickname, will only have effective SOP access to the channel. -This would be more effective if ChanServ and NickServ 'time out' password identifications. For example: If you identify as founder to a channel, then leave your IRC session idle for a long duration, ChanServ and NickServ should ideally "forget" about your identification, or require you to re-identify, before you may issue further services commands at your current ACC level. -It would be more effective if SOP commands were treated the same way. For example, if a user's last ChanServ or NickServ command was more than a few hours ago, a new identify command with NickServ should be necessary before sending more SOP-level ChanServ commands.
With the above rules, how about making new channel registrants (founders) automatically added to the SOp list (as well as being named founder). Why?
Maybe i'm mistaken... but wasn't this the case at one point? I suppose it would be a reasonable quick fix, but truly.. there are enough use-cases for having 'Co Founder' users.. 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. Auto-add the founder to the MANAGER list on registration, require password identification to change the list. This would also eliminate any current need for "/ChanServ set #channel UNSECURE" By definition 'all channels' are UNSECURE by the old definition. Perhaps the new definition of 'unsecure' would be "All managers are just SOPs, whose only additional privilege is to manage the SOP list." Whereas with unsecure disabled, MANAGERS may use SET commands (other than SET founder)
ChanServ does kick everyone.. they may re-join right after they get kicked which is bad. I consider it as a bug, we should get it fixed (by either temporary sqlining the channel or having ChanServ remove the invites/excempts lists before starting a masskick).
Seems reasonable. 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. Could also help assure that a channel can be consistently MKICKed, even if the actual channel userlist has somehow become desynced on some server(s). :chanserv MKICK <channel> :<reason> <- The local server receiving this message forces all local users in the channel to part the channel with the given reason, and propagates ala sendto_serv_butone. :chanserv MODEFLUSH <channel> [<modeset>|*] [<nickname>] <- Reset the specified channel modes to the default (off) state, and propagate the message to all servers but source, * for all modes :chanserv modeflush #channel :be -- clear all bans -- clear all excepts :chanserv modeflush #channel :o -- clear all ops (useful for MDEOP) :chanserv modeflush #channel +* -- clear all modes, ops, bans, excepts, voice, etc So two commands modeflush #channel :e mkick #channel Would be fine for /ChanServ MKICK And the work of tracking except-like things is offloaded from services.
4.2.2 ChanServ restrict and channel excepts. When a restricted channel has a violation (a non AOp/SOp/Founder joins), and an except is set, ChanServ will join the channel and unset the excepts before removing the guest.
Maybe the founder wanted the except? Still... the channel could have just been MLOCK'ed +i with manual invites used. Perhaps we should have a /ChanServ EXCEPT command. With syntax similar to the AKICK command. Otherwise, it makes sense to override EXCEPTs. Or at least a way to 'provide a list of allowed members' without giving them OP access. Still, I doubt this is helpful for most restrict'ed channels, the excepts should simply be removed. -- -J