how do channel ops fit into our planned ACL scheme?

[kaniini]

@Argure brings up an interesting point that since we're doing away with channel ops, we probably shouldn't fake them.

This is a request for comments concerning that.

[pgodschalk]

I'd go for removing the concept of channel operators altogether (along with what is traditionally cmode +o). It serves no purpose other than vanity, i.e., "look at me, I am better than you because I have a symbol in front of my name". There will be plenty of people, including client developers, that want to do this regardless but there is no reason that behaviour should be enabled in ircd.

If you actually need an overview of who has which capabilities, an ACCESS LIST-esque command (similar to atheme-services' FLAGS #channel for users with +A) would provide more meaningful output considering actual capabilities might differ between users. Mode prefixes do not achieve this even remotely and practically serve no other purpose than epeen b0ner.

[kaniini]

ACCESS LIST was always on the plans anyway. I somewhat agree that we shouldn't bother with channel ops, but my main concern is that might be too much "culture shock" for experienced IRC users.

[kaniini]

I think what we will do is implement the prefixes as optional flags. That way channels which want hierarchy can implement it. The flags will probably be provided as ext modules once that subsystem is live.

[Mikaela]

I just thought, what about those clients that cycle to get opped when not opped and alone in channel?

Update on 2015-04-06: this was discussed on IRC long time ago and it appears that e.g. ZNC's *autocycle which I use doesn't attempt autocycling forever, I am not sure if it even cycled once.