On Sun, May 30, 2010 at 9:47 AM, Vin King <vin.king@gmail.com> wrote:
1) Access 40/30 probably shouldn't be combined even if they have the same rights as a matter of book keeping. If you've got a few managers, and a
Clearly the numerical access levels are for the benefit of user scripts and quickly communicating the access status of a user. As you do not specify a numerical access level when adding channel ops. Using English text (rather than just a number) to describe actual access situation is the simplest for the average person to understand. There is a distinction to be made here... a Manager identified by nick is different from a founder recognized only by access mask. In case of a security breach, the way for channel management to go about clearing it up is completely different. If anything, the distinction should be removed from ACC between founder identified to nick, and founder recognized by NickServ mask. It would be more flexible if the two were treated as orthogonal... as in Channel Access Level, VS NickServ Identification level. And both levels should always be displayed with the ChanServ ACC command. Should be separate numbers. And some commands (like DROP) should simply always require a higher identification level. The current implementation is OK, but may be too complex, if additional levels are ever added later. It would be more flexible to have /Chanserv acc #channel user -ChanServ- <nick> ACC #channel ACCESS:<x> IDENTIFY:<y> [NICK|MASK:<text>] x = Access Level -1 < akick 0 < none 10 < AOP 20 < SOP 30 < MANAGER 40 < FOUNDER y = Identification Level 0 < no access 1 < by mask 2 < by nickserv access mask 3 < by nickserv identification 4 < by chanserv identification <text> = The actual nickname or channel op mask used to achieve 'access' if applicable
4) I have to admit, I like the simple +o/+v/nothing rank structure for channels. Having a billion different symbols for each minute change in power seems more of a vanity thing than having actual uses. For help channels, would it not be more efficient to have more AOps than a couple halfops who don't have the full capacity to manage a channel?
It doesn't necessarily need to be true that changes in channel access level, indicate changes in IRCD access level. We already have AOP and SOPs which have the same IRCD access level. I see MANAGER as an extension to SOP. Founders may want to further enable some or all of their SOPs to have channel management functions. This provides them more flexibility. If not, they can simply ignore the new MANAGER function and continue to manage their channels as they always have. Implementing HALFOPs and reducing the IRCD powers of AOPs would reduce the flexibility actually, and force channels to make a majority of their OPs... SOPs. The new MANAGER level should be a huge security improvement, if the argument can now be convincingly made that founders should never share their channel, nick password, or use founder nickserv access list, to assign ad-hoc "assistant founder" access. If HALFOPs or other should be desired, they should be a new access level, added without reducing the access of existing AOPs, but the introduced complexity may be confusing to some users. You get UI questions like * Should opguard prevent an AOP from setting a user +h ? * What level of channel OP in ChanServ should be allowed to add HalfOps ? Introducing new (potentially unwanted) security risks to channels is probably undesirable, so there should likely be some need for founders to 'opt in' as in /chanserv set #channel opguard <0 | 1 | 2> * 0 - normal * 1 - Prevent anyone not in the list from being set +o, but +h ok * 2 - Prevent anyone not in the list from being set +o or +h /chanserv set #channel halfops <AOP | SOP> * AOP - Allow AOPs to add/delete halfops * SOP - Allow only SOPs to add/delete halfops -- -J