PapaSmurf wrote:
NickServ ACC 1 = Nick is registered
ACC 1 = User is not online or is not recognized by NickServ as the true owner.
Either the person using the nick isn't the owner, or the owner is using it and they registered the nick before Jan 1, 2003 (and they never turned Enforce On). The owner, under this scenario, had to AUTH via the web link (not through services). Else, the nick had to be registered before Jan 1, 2000 (when AUTH wasn't around), and never set Enforce On.
The dates are incorrect but it is really irrelevant if enforce is enabled or not, ACC 1 simply means the user is registered but either is not recognized as the real owner or is not currently online.
1.1 The ChanServ Ident feature is set on, by default, upon new channel registrations for very good reasons. This does two things:
a. It negates access matches (and potential problems for channel managers/founders). b. It negates ChanServ's Unsecure feature (which requires access matches to function).
Unsecure is currently broken but it'll make sense to let unsecure override ident (for the founder nick only).
Services Coders:
With the above rules, how about making new channel registrants (founders) automatically added to the SOp list (as well as being named founder). Why?
Easier to simply prevent sops from being able to akick founders. This will probably be added on the next services upgrade.
SECTION 3: UNREGISTERED CHANNEL FOUNDERS (NICKSERV ACC 0)
3.1 In the "eyes" of services (ChanServ/NickServ), a dropped nick is the same as an expired nick.
3.2 A founder purposely drops his founder nick. He/she will continue to have ChanServ ACC 5 as long as: A) they do not log off DALnet B) Successor doesn't take over C) anyone else doesn't set themself as founder.
Users can identify to ChanServ if they have the correct password for channels with dropped/expired founder that is still registered, the only difference is that they cannot drop it.
3.3 Such a founder can do all channel-related management they could before with two exceptions:
A) They cannot send channel memos (a registered nick is required to send/read memos). B) They cannot drop the channel (ChanServ memos the drop code).
ChanServ doesn't memo drop codes. Users cannot drop channels with dropped/expired nick like you said, though.
4.2.1 ChanServ mkick and channel excepts.
Excepts (channel mode +e) are designed to allow people in who match a large ban set (from abusive users, etc). If a guest is on the except list and an mkick is issued (by the highest ranking op on the channel), guess who ChanServ doesn't kick? Right, the guest. Mass kick does not unset excepts, and allows excepts to remain in the channel throughout the mass kick process.
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).
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.
4.3 Excepts, like all channel modes, are IRCd command features. The bond bahamut and services share is more apparent than what we think we know. This avenue needs to be explored more. Maybe we can get this mailing list kickstarted with said chatter (pertaining to findings resulting from testing any and all interactions).
While only the founder can set restrict on and only sops/founder can add akicks, invites/excempts can be added by any op (sometimes even during netsplits) which is why excempts aren't trusted by ChanServ and are removed if ChanServ needs to enforce a restrict/akick. I don't know how many people will like a services invites/excempts list that will let founders/sops override restrict/akicks. It may or may not be added in the future. -Kobi.