ability to "purge" channels

[slingamn]

AFAICT the closest precedent for this is something like forbid/suspend in anope.

The idea is: a community is bad for your network, you want to eliminate their channel. So an operator with the chanreg permission should be able to set a flag on their registered channel so that no one can use it (and it doesn't show up in /list?).

As part of this, we should make the chanreg operator permission exempt you from the max-channels-per-client restriction, so if the channel isn't registered yet, the operator can register it from under them and then set the flag.

[DanielOaks]

Related: Possibly doing something similar but with unregistered channels. Maybe this flag could be stored separately to the channel registration entirely so that even if e.g. the user who made the channel gets dropped, the channel restriction remains?

[slingamn]

Oh yeah, good point, we don't want unregistration to undo the purge.

I'll see which way's cleaner.

[slingamn]

I'm going with a separate purge status that's orthogonal to registration.

Any thoughts on commands for this? The basic operations are:

1. Mark a channel as purge
2. Unmark a channel as purged
3. See a channel's status (is it registered? is it purged?)
4. List purged channels (maybe not necessary?)

For 3, I'm thinking I'll finally create CHANSERV INFO (which will list registration information and purged status). For 4, I think I'll probably skip it for now.

So 1 and 2 need a verb (the closest anope concept is "suspend", there's also "forbid", and we could just do "blacklist" or "purge"). I'm leaning towards CS BLACKLIST #chan and CS UNBLACKLIST #chan.

The "implementation default" is that attempts to join a purged channel will just return 403 ERR_NOSUCHCHANNEL, similar to a channel with an invalid name. Is there any need for a more specific or informative error?

[slingamn]

bogdomania votes for CS PURGE and CS UNPURGE.

Should this operation take a comment, like a ban reason?

[bogdomania]

A comment/reason would be welcome, for medium-large networks.
But again, maybe shown only via API. Def. ok, just ChanServ output should be kept somehow lightweight.
A webpage should offer the extra infos, for sure I wouldn't like a screen full of text, just from a command output.

L.E. Better yet, how about throwing a config entry, via which OPS can choose if they want services to be verbose or not? Maybe some of them don't fancy a webpage.

L.L.E. In case that some channel is purged, after, unpurged, should ChanServ keep records of these actions? and the given reasons? date? Operator who did it?

[DanielOaks]

/CS PURGE #chan [reason here]

/CS UNPURGE #chan

/CS LIST PURGED
  -- for admins. maybe we can also have /CS LIST REGISTERED and others as well?
     I imagine a bunch of one-line channel info lines here

/CS INFO #chan
  -- same as in other services packages (e.g. see what freenode and the like output),
     makes sense to list some purge info here

def makes sense, I think a set of commands like this is pretty seamless. if the reason exists we can show it when someone tries to join the channel, we'll decide which numeric/etc is best and likely to be shown to users (maybe the you-are-banned-from-this-channel numeric with the text "Channel is disallowed: [reason]") or something could be interesting.

I don't think we need to keep records of all oper actions, at least not by default. if we want to down the line, cool, but I'm mostly concerned with keeping the current running state up-to-date right now

[bogdomania]

ChanServ - set of commands:

1. /CS PURGE #channame [reason]

2. /CS UNPURGE #channame

3. /CS LIST PURGED

   This should have, as output a list with all currently purged
   channels, but not as /help index. Stack them somehow, in some
   sort of table, as below:

Channel name	Date	Operator	Reason
#Channel1	Fri, 13, 2019	dan	Some reason here.
#Channel23	Thu, 12, 2019	sling	No reason specified.
#Channel44	Wed, 11, 2019	dan	Because I want to.

*** End of /PURGE ***

This list shouldn't be very big, even on a medium-large scale network. Is not that operators purge channels on a daily basis.

4. /CS LIST REGISTERED
   This would be a hairy output. I assume it reffers to all registered channels? If so, listing a few hundreds, if not thousands, is ...
   Again, leave it to the API, served on a webpage, where you can have some filters and sorting.

5. /CS LIST EXPIRED (yeah, not the best name, I know)
   Maybe, if the network grows and some channels are inactive for a long period of time,
   should be deleted? Useful for networks with hundreds of channels, to filter the "dead" ones.

[DanielOaks]

once we have an API we can look at that, but for now I'm only really considering the IRC interface. actually, I wonder whether a separate /CS LIST REGISTERED would be required at all, or if there's some way to do the same with the regular /LIST command's parameters, hmm...

that /CS LIST EXPIRED is an interesting idea. maybe it'd make sense to just look at a system of filters people could use, e.g. /CS LIST EXPIRED <15 (expired with less than 15 entries in their XYZ list), or something. I dunno, we can start with just listing purged and go from there if all else fails.

[slingamn]

Would "deactivate" and "reactivate" be better user-facing verbs for this? (Clearer, more professional?)