I am a bit confused despite I have been using IRC for the past 5 years, there is the ChanServ bot and you can perform the operations (ACL changes) using it, Say, if you want to give the founder status for a user you perform /msg ChanServ #channel-foo-bar <nick> +F but why say if we want to ban someone we use ChanServ and set +b on a person, but my concern is, why if we want to set quieting for the person (which is +q) we should run /mode #channel-foo-bar <nick> +q. I though that ChanServ is being used to control the ACL bits per person and /mode is being used to set per-channel options, but it seems I was wrong, why, say we can not set the +q flag using ChanServ?
Asked
Active
Viewed 1,152 times
2
ZeroKnight
- 575
M.Mass
- 133
1 Answers
3
Well, both quiets and bans are actually set through /mode (/mode +q and /mode +b respectively). "Granting" someone the +b flag via ChanServ merely tells it to set the +b mode whenever the banned person returns (as well as kicking them from the channel).
The primary difference between using /mode +b and ChanServ's flags is that the latter are permanently stored (see full explanation below).
As an extra feature, ChanServ lets you put notes and expiry times on the bans. Although this isn't available through flags, but you can access this feature through /msg chanserv akick. Channel operators often find it useful to know why someone had been banned and for how long – without having to keep a shared google-doc for that.
Background: Most IRC networks do not have any sort of persistent storage. They don't have user "accounts". All channels are transient, their mode and ban lists kept in memory only as long as the channel has people in it. If you gain op status, it only lasts while you're in the channel – if you leave or disconnect, someone will need to /op you again. If a server reboots, it resyncs from zero. If the entire network reboots, all state is lost. (As has happened to EFnet in late 2012.)
(There are exceptions, but this is the usual case.)
Services bots (ChanServ) provide this storage in a completely separate program, acting very much like a traditional 'bot' or just a scripted client. All the flags you set in ChanServ don't actually affect the network directly – they just tell ChanServ to set some /modes on behalf of you. (If you're a channel operator, you can certainly set those /modes yourself, they'll just be temporary.)
So when you have +o or +F flags on freenode, that doesn't change your direct access to the channel; it gives you indirect access through ChanServ. The +o flag is an ACL that lets you ask ChanServ for a /mode +o on yourself. The +F flag is an ACL that lets you give flags/ACLs to others.
Why doesn't ChanServ have a +q flag to mute users? Well, it could but nobody has implemented that just yet.
One of the arguments is that mutes are often temporary and don't really need to be stored in ChanServ, whereas full-on bans are often permanent and make better use of the persistent storage.
Another reason is that the services software is written to work with several different types of IRC servers and juggle all of their custom extensions. Only full bans are a standard part of IRC – although freenode has mutes (quiets) as the +q mode, that's a nonstandard addition.
Other IRC servers have different extensions. For example, a much more common meaning of +q is the "channel owner" status – which doesn't mean ChanServ-style owner, but actually regular chanop access with some bonuses. You can see this on Foonetic or Rizon; instead of just "op/voice/peonnormal" you have "owner/admin/op/halfop/voice/normal". (Mutes/quiets, of course, must use a different letter.)
So the primary reason why freenode's ChanServ does not have a +q flag for muting is that it already uses the same flag to implement the 'owner' level in those other network types.
(There have been many cases of a network switching its base server software, but keeping the same services software and account database. When this happens, you certainly don't want services to convert all previous "+q (channel owner)" entries into "+q (muted)" entries...)
grawity
- 501,077