[IRCServices Coding] Feature Suggestions

[Kieron Thwaites]

> 1. /ns set autoop [on|off] - Just like Anope

If this is what I think it is, which is that the nick in question
won't be auto-opped on any channel (next time please elaborate on what
Anope does), I believe that Andrew may have been considering this at
one point (I think it was in one of the TODO lists). That being said,
I haven't seen this in 5.1, so it may have been dropped or thrown out.

> 2. I think channel passwords suck, so:
>
> - Leave /cs register the same, but ignore the password field, like on
> Surreal Services
>
> - Add an xOP level called QOP or CF or Co-Founder, access level 900 (not 999
> please).
>
> - Only the "true founder" can set successor.
>
> - Remove /cs identify
>
> - /cs drop won't require the user to do /cs identify first
>
> - Add commands owner and deowner, and levels autoowner and owner
>
> - /cs deprotect will no longer set mode -q, it will do -a only

I was actually thinking of something like this a while back. I'll
leave it up to Andrew to make the final call on this one, but I
suggest a few more things: firstly, regarding the "only the 'true
founder' can set successor" bit, go further - only the true founder
should be able to modify such a list in the first place. Secondly,
dropping a channel should always require a password, for security
reasons and to guard against accidental drops.

What I like about this method is that it reduces the possibility of
someone changing the "true founder" of a channel, as I assume that
users on a "co-founder" list wouldn't be given that permission.

As a sidenote, 5.1 has dropped support for the channel owner mode (+q
on UnrealIRCd for example); channel owners will be given the same
modes as those on the SOP list or access level >= 100.

> 3. /cs clear #channel users - make this only kick users who don't have the
> access to use it.

No opinion on this.

> 4. When someone sets a new founder for the channel, they immediately lose
> their founder-level access.

Kind of stupid, as someone losing their founder-level access and
knowing the channel password could just identify using the channel
password and get founder-level access straight back. If the system
mentioned in your second point were to be implemented, then I could
see a use for this, but right now it makes no sense at all.

> 5. /ns listchans - make this list all of the user's channel accesses, like
> /ns alist in Anope

If I understand you correctly, you want this to display the access
list for a channel as well. Services already does this. (/msg ChanServ
ACCESS #channel LIST - or something like that)

> 6. When someone does /cs info #channel, and it shows the mode lock, make it
> show the locked mode paramaters too.

Bad idea. I'm sure that no-one wants to see their channel key
displayed in this manner. :)

--K