Contents
Documents the IRC channel setup/configuration for #freebsd* channels
Channel Settings
Disable GUARD: ChanServ does not inhabit channel. /cs set #<channel> GUARD off
Enable SECURE: Users without +o flag cannot gain operator status /cs set #<channel> SECURE on
Enable TOPICLOCK: /topic can only be set by /cs /topic (and users with +t). Note: Enables KEEPTOPIC /cs set #<channel> KEEPTOPIC on
Enable PUBACL: Channel access list is public. /cs set #<channel> PUBACL on
Channel Modes
Baseline
All channels shall have the following configuration set:
Channel modes: +cCgnt-iljksf set via /cs set <channel> MLOCK
Channel ban list: /mode <channel> +bq $j:#freebsd $j:#freebsd (all channels inherit #freebsd banlist, see Libera Guide: extbans (TODO)
Note: +q $j:<#channel> can be set, but doesn't work (but probably should, allowing inheriting quiet lists separately from / in addition to banlists)
- Exception: #freebsd (by definition, it inherits its own ban list)
Exceptions
#freebsd channel modes: Baseline + +Frf #freebsd-irc
#freebsd-ops channel modes: Baseline + +i (and remove -i) #TODO
#freebsd-pulse channel modes: Baseline + -nc (remove +nc), so bots can message channel without joining and with colours for event formatting
Channel Access
Where access is provided on a channel-specific basis, the following standard flags should be set.
Channel Leads
Channel leads are responsible for ensuring and cultivating a great user experience within the context of a specific channel. They also seek to promote use and growth of the channel.
Flags: /cs flags <channel> <nickname> +toer
t: Enables use of the topic and topicappend commands
- o: Ability to op oneself if, and when necessary
- e: Exemption from bans (+b) and enables un-banning self
- r: Enables use of the unban command
Registration Policy / Audits
Policy
All #freebsd* channels:
- SHOULD be registered by IRC Admin, in the standard configuration.
If they are not registered by IRC Admin,
- IRC Admin MUST have access to the channel for management purposes. (TODO)
- IRC Admin MUST be set as a successor (+s) to the channel in the access list (TODO)
- MUST have channel founders or managers that are active. (TODO)
Auditing
We regularly audit and review channels registered within our namespace (#freebsd*). Any channels found in the list not meeting the criteria above are marked for pruning and deregistered accordingly.
List channels: /msg alis list *#freebsd*
Other reason classes for de-registration include:
- Defunct, stale, out-of-date.
- No longer in use, lack of activity
- Inappropriate, abusive, trolling or reputation affecting
Information that is used to determine channel state can include:
Channel registration information: cs info #<channel>
- Registration date
- Last used date
- Registrant (known/unknown)
- User activity (number of used currently, over time)
- Current topic or entry message
Ban management
Libera.chat has a set of self-service bots available for ban management, including litharge, based on ChanTracker.
Per the Libera.chat documentation,
- When requesting litharge for your channel, simply /invite litharge #yourchannel. This bot will need the +o flag in your channel so that it can op itself to remove bans when they expire; /msg chanserv flags #yourchannel litharge +o.
From the github documentation, the user inviting the bot is its "owner", but other users can be added to litharge's admin list as follows (untested):
!user register opaccount password !hostmask add opaccount *!*@something !admin capability add opaccount #myChannel,op
...after which the user can issue private messages to the bot like:
/msg litharge 10m argumentative again /msg litharge 30d silly spammer