core: add inspircd operprefix !/+y channel mode

[half-duplex]

On inspircd 3 with the operprefix module, as oper, create a channel. You'll have !. Add the bot. The bot sees you as having no modes (0), and you can't do anything until you +o yourself.

Might not be a 6.6.x thing, but if I don't open this now I'm not going to remember.

Future enhancements:

• Have the symbol/mode/constant stuff in one place instead of 5 (!)
• Just generate this stuff from what the server tells us when we connect

[dgw]

Parsing supported modes from server connect spam is definitely on the road map. The current state annoys me, too! See #1536 for the parsing bit, after which we can rewrite the mode handling again to take advantage of the new data.

Does this really need to touch the indentation? Not that I think we'll actually put this into 6.6.x, though, so maybe the best choice would be rebasing onto master.

[HumorBaby]

Regardless of how I feel about adding these highly IRCd-specific modes/prefixes, if you're gonna add Insp3 stuff, might as well get it all 😁

[HumorBaby]

Just to address my comment from the review:

Regardless of how I feel about adding these highly IRCd-specific modes/prefixes...

I'm not a fan :/ According to modern specs, the only standard mode/prefixes are (ov)@+ (OP and VOICE). While I understand (and appreciate) the inclusion of commonly used modes like HALFOP and OWNER (founder) etc., I am really looking forward to the re-work of mode/prefix + privilege tracking 😄

half-duplex:

On inspircd 3 with the operprefix module, as oper, create a channel. You'll have !. Add the bot. The bot sees you as having no modes (0), and you can't do anything until you +o yourself.

... as (I believe) it should be. The bot does not need to recognize a server op as anyone special in a channel until they make themselves act that way. If they really needed to override things with the bot, they could just +o themselves as needed, no?

[half-duplex]

The bot does not need to recognize a server op as anyone special in a channel until they make themselves act that way. If they really needed to override things with the bot, they could just +o themselves as needed, no?

Until we can support custom/dynamic modes, ignoring +y (and probably +Y) is a POLA violation, and something I expect to trip on regularly. I acknowledge and agree that manually adding support for new modes is the wrong way to do this, but until we have something better, this fixes it simply and without any obvious side effects.

[HumorBaby]

but until we have something better, this fixes it simply and without any obvious side effects

That's fair; plus, InspIRCd is pretty common, so might as well have it in here until we have something better™

[dgw]

Until we can support custom/dynamic modes, ignoring +y (and probably +Y) is a POLA violation

I disagree with this. No one should be astonished that a non-standard mode is not handled.

At present I honestly don't intend to merge this. Maybe if we can't get proper dynamic mode handling done for 7.0, it can go in as a stopgap. But if #1536 and follow-ups proceed apace, we shouldn't need it.

so might as well have it in here until we have something better™

*sprays water* Or we can just implement something better™ the first time!

[dgw]

Updated Just In Case™. I still don't really like this change.

[dgw]

@half-duplex I asked this on IRC, but for the sake of keeping the conversation together:

Would you be interested in implementing "proper" mode parsing based on the server's PREFIX token, on top of the ISUPPORT parsing to be introduced soon by #1758? That could straight-up replace this and all the other nasty hard-coded privilege prefixes at once.

Understandable if you want to leave it for a future release, though. 7.0 is going to come out this month no matter what if I have anything to say about it, and we might have to alter some API (e.g. the privilege constants in sopel.module) around such a change. That would probably take longer to design than is reasonable for this late in the cycle.

[dgw]

7.0 is going to come out this month no matter what if I have anything to say about it

Ended up not finishing 7.0 in time for my long (and very busy) overseas trip, so here we are in the next month with another rebase. No way am I delaying 7.0 again to design dynamic mode parsing/handling, so looks like this will get to be a stopgap after all.

When merging, I'll make sure we have an issue to remind us about dynamic mode/prefix parsing.

[half-duplex]

See #2197 for prefix parsing 😄