Hi all,
We have added two new features to services: 1) Channel managers - lets founders give almost full control over a channel. http://www.dal.net/kb/view.php?kb=196 for the full list. 2) MemoServ ignores - lets users ignore other users and nick!user@host masks (see /MemoServ HELP IGNORE).
As a side effect, ChanServ ACC command's replies have been changed. The new replies are: -2 = Channel is frozen or closed -1 = User is autokicked from the channel. 0 = User has normal access. 10 = User has AOP access. 20 = User has SOP access. 30 = User has MANAGER access. 40 = User has founder access via a NickServ access list mask 50 = User has founder access via identification to NickServ 60 = User has founder access via identification to ChanServ
News announcement is available at http://www.dal.net/news/shownews.php?id=68
FYI,
-Kobi.
I found out about these features today (from another help-channel helper). I played with them for 20 minutes, and found some things I guess...
1. Only Access 60/50 can modify the Manager list (add/del/wipe). 2. Access 40/30 cannot WIPE the akick list; only access 60/50 can wipe it. 3. Access (50 or 40)/30/(20 or 10, by address) - CS Why replies highest access level (if added as all 3... 1/2/3). 4. Successor can be named Manager. 5. Access 60/20/10/-1, added by fully-registered nick, cannot be Manager simultaneously. Exception occurs when Manager is named then access 20/10/-1 is added by hostmask.
Why am I posting this (without testing more)? Normally I wouldn't, but I am lost as to why manager was added. I re-read the dalnet-services@ Dec 2009 thread, and manager was brought up there.
Questions I have (without testing further)...
1. Why isn't Access 40/30 combined? What can 40s do that 30s cannot? One of the 2 can be eliminated if "powers" mimic the other. If they mimic, is it practical to have both?
2. What else can 60/50s do that 40/30s cannot (aside from what I posted above, and what is on the docs page)?
3. Why not make AOp/SOp registered nick only (like manager); not hostmask?
4. Wouldn't it be more practical to offer halfops (%)... a. Users from other servers/networks can transition into DALnet easier b. Help channels can use halfops to manage lamers if ops are not present. c. Allow 5 halfops and 5 managers (combining 40/30). Halfops can be proving grounds for staff promotions to AOp/SOp.
I think the addition of manager blurs the lines of Access 10/20/30/40, and complicates access levels (more than meets the eye). For me, 30s make 20s look like 10s, and 10s look like nobodys/halfops. Is the goal to replace UNSECURE?
I think users enjoy playing with the manager feature (feeling more free to manage their channels, etc). I can see rants ensuing from my lack of further testing, and my assertions. People like change, and greater freedom.
Lemme know if I could ever weasel a spot on the new services features test squad (before they are implemented). I enjoy testing new features. For now, maybe some discussion/findings can occur (to liven up the mailing list).
I didn't get to play with MemoServ Ignore much, but I found out that MS Forward bypasses MemoServ Ignore (just as it does NickServ NoMemo). Stored memos can be 52 (per nick) despite what the docs page states (50). Anyone test the ignore max (50, 52, other)?
Sorry for being unprofessional (not testing thoroughly). I am starting classes Tuesday, and running around like a chicken with its head cut off for the next week or 2. Maybe we can get some debate going from this post.
Thanks,
PapaSmurf
--- On Fri, 5/28/10, Kobi Shmueli kobi@DAL.NET wrote:
From: Kobi Shmueli kobi@DAL.NET Subject: [DALnet-services] Channel managers and MemoServ ignores To: dalnet-services@lists.dal.net, helpers@lists.dal.net Date: Friday, May 28, 2010, 6:19 PM Hi all,
We have added two new features to services:
- Channel managers - lets founders give almost full
control over a channel. http://www.dal.net/kb/view.php?kb=196 for the full list. 2) MemoServ ignores - lets users ignore other users and nick!user@host masks (see /MemoServ HELP IGNORE).
As a side effect, ChanServ ACC command's replies have been changed. The new replies are: -2 = Channel is frozen or closed -1 = User is autokicked from the channel. 0 = User has normal access. 10 = User has AOP access. 20 = User has SOP access. 30 = User has MANAGER access. 40 = User has founder access via a NickServ access list mask 50 = User has founder access via identification to NickServ 60 = User has founder access via identification to ChanServ
News announcement is available at http://www.dal.net/news/shownews.php?id=68
FYI,
-Kobi. _______________________________________________ DALnet-services mailing list DALnet-services@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-services
Hey PapaSmurf,
Without having full insight into all of this, I'm gonna go ahead and give some answers!
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 founder who hasn't identified to ChanServ, how do you tell who is who if they've got the same access? Giving an unidentified founder a higher access level sets him apart.
2) Unfortunately, I can't offer anything on this one.
3) The ability to have access granted by hostmask has uses. It provides a certain level of flexibility for how your ops can gain access, and can cover instances when they haven't identified to their op nick, or have joined using a different or unregistered nick. Obviously, it may not be recommended for public or large channels, but in instances where you and a couple friends have a nice, cozy channel, it may make it feel less regimented.
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?
Manager, from my guesswork, isn't intended to be a new "everyone becomes less important" rank to the op structure, but instead offers the users the way to get the "co-founder" they've been trying to get for a while. By granting this type of role, we can ensure that our users are far less likely to share the founder password, as I'm sure you've seen happen in plenty of reported takeovers.
On those lines, access 40 should remain distinct from 30, showing the clear division between the founder and a channel manager.
I have to admit, I believe this feature will go a long way towards our users securing their channels more by not sharing the password with so called "co-founders."
--Vin
1. Why isn't Access 40/30 combined? What can 40s do that 30s cannot?
One of the 2 can be eliminated if "powers" mimic the other. If they mimic, is it practical to have both?
- What else can 60/50s do that 40/30s cannot (aside from what I posted
above, and what is on the docs page)?
Why not make AOp/SOp registered nick only (like manager); not hostmask?
Wouldn't it be more practical to offer halfops (%)...
a. Users from other servers/networks can transition into DALnet easier b. Help channels can use halfops to manage lamers if ops are not present. c. Allow 5 halfops and 5 managers (combining 40/30). Halfops can be proving grounds for staff promotions to AOp/SOp.
I think the addition of manager blurs the lines of Access 10/20/30/40, and complicates access levels (more than meets the eye). For me, 30s make 20s look like 10s, and 10s look like nobodys/halfops. Is the goal to replace UNSECURE?
I think users enjoy playing with the manager feature (feeling more free to manage their channels, etc). I can see rants ensuing from my lack of further testing, and my assertions. People like change, and greater freedom.
Lemme know if I could ever weasel a spot on the new services features test squad (before they are implemented). I enjoy testing new features. For now, maybe some discussion/findings can occur (to liven up the mailing list).
I didn't get to play with MemoServ Ignore much, but I found out that MS Forward bypasses MemoServ Ignore (just as it does NickServ NoMemo). Stored memos can be 52 (per nick) despite what the docs page states (50). Anyone test the ignore max (50, 52, other)?
Sorry for being unprofessional (not testing thoroughly). I am starting classes Tuesday, and running around like a chicken with its head cut off for the next week or 2. Maybe we can get some debate going from this post.
Thanks,
PapaSmurf
--- On Fri, 5/28/10, Kobi Shmueli kobi@DAL.NET wrote:
From: Kobi Shmueli kobi@DAL.NET Subject: [DALnet-services] Channel managers and MemoServ ignores To: dalnet-services@lists.dal.net, helpers@lists.dal.net Date: Friday, May 28, 2010, 6:19 PM Hi all,
We have added two new features to services:
- Channel managers - lets founders give almost full
control over a channel. http://www.dal.net/kb/view.php?kb=196 for the
full
list. 2) MemoServ ignores - lets users ignore other users and nick!user@host masks (see /MemoServ HELP IGNORE).
As a side effect, ChanServ ACC command's replies have been changed. The new replies are: -2 = Channel is frozen or closed -1 = User is autokicked from the channel. 0 = User has normal access. 10 = User has AOP access. 20 = User has SOP access. 30 = User has MANAGER access. 40 = User has founder access via a NickServ access list mask 50 = User has founder access via identification to NickServ 60 = User has founder access via identification to ChanServ
News announcement is available at
http://www.dal.net/news/shownews.php?id=68
FYI,
-Kobi. _______________________________________________ DALnet-services mailing list DALnet-services@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-services
DALnet-services mailing list DALnet-services@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-services
On Sun, May 30, 2010 at 9:47 AM, Vin King vin.king@gmail.com wrote:
- 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
- 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
-
James Hess -
Kobi Shmueli -
PapaSmurf -
Vin King