Feature request: support for automode

[Mikaela]

Is your feature request related to a problem? Please describe.

In IRCnet there is no centralized channel management by ChanServ so the task of keeping ops falls down to users themselves or their bots. In the worst case scenario that ops are lost entirely, there is channel mode +R <hostmask> which allows the server to restore ops to matching user when they are lost entirely.

I have seen particularly Finnish users getting frustated with channel reop giving the operator status to Matrix users or Matrix users being the only ones staying connected and keeping ops. This results to the need of instrcuting the Matrix user in performing obscure commands such as !cmd irc.snt.utwente.nl MODE #channel +o Mikaela in order to handle things like IRC spambots. There are also worse cases when the ops belong to Discord or Telegram user who is bridged to IRCnet through Matrix and thus they couldn't share power no matter how much they wanted to.

Describe the solution you'd like

I would like Matrix users to be able to have their personal list of hostmasks for which to grant mode +o or mode +v as the hostmasks are seen joining or when the Matrix user gets mode +o themselves. I think the list should have option for both, network-wide and channel-wide hostmasks for cases where the Matrix user by themselves is an IRC user or trusts another user to be opped everywhere (such as they are running an IRC bot to handle opping).

Describe alternatives you've considered

I cannot think of good alternatives to this feature. One is banning Matrix entirely and just using IRC which I think would be undesirable on Matrix side, another would be just giving ops to random users, which could be even worse and then there is the option of asking network operators for help (which could lead to them being annoyed and thus have undesirable consequences for Matrix).

Additional context

IRCnet bridge is ran by Utwente.io who also run an IRCnet server. I have seen several Matrix users recommending IRCnet for IRC-bridged channels as they are the most friendly to Matrix due to running a server and it's especially popular amongst Finnish users.

[Half-Shot]

I've been generally resistant to having the bridge manage ops in this capacity because it feels like something that can easily go wrong and/or suddenly increases the responsibility of the bridge and the matrix.org team to keep your channels safe (it's not to be understated how much of a burden automatic channel management would be on the bridge).

At the moment we deliberately defer that to the IRCD/Service bots in the hope that they can correctly and securely manage the channel with the correct modes. In general I'd expect the IRC network you are connecting to would have support for correctly moding users in the channel via chanserv, so I'm afraid I'm not too sure why this hasn't been possible for some folks? (I think autoop is a chanserv feature for most ircds?). I understand that IRC is not the most friendly of systems to configure, but it's sort of part of the package that if you want to bridge your community to IRC then you will need to spend the time configuring it.

I see why it's convenient for the bridge to manage this state as it's already reading a lot of state from IRC, but personally I'd much prefer this be solved by external services before we make the IRC bridge responsible for managing channels themselves.

[eras]

One partial mitigation that would be easier to implement: when the bridge connector bot notices that the channel doesn't have +R set up (should be easy enough: just query the R mode and determine list if it is empty), it could send a message to the room indicative of this highly likely misconfiguration. The message should only be sent once per channel.

Then on top of this the +R logic could be itself implemented in the bot: IF only the bot is +o, then it should implement the rules of the +R itself for users other than itself. This would eliminate the need for any particular configuration interface for this.

Edit: And for this operation the bridge bot should perhaps prioritize users that are in the IRC side and perhaps activate already when nobody else on IRC has ops.

[Mikaela]

IRCnet doesn't have ChanServ or other service bots resulting into this issue and I don't think they will ever implement them.

I agree that showing warnings about lacking mode +R would be nice, but it would be specific to IRCnet, or at least I don't know other networks having channel reop system like that.

Could the bridge at least have a command for opping users without the obscure !cmd irc.snt.utwente.nl MODE #channel +o nickname?

[Half-Shot]

IRCnet doesn't have ChanServ or other service bots resulting into this issue and I don't think they will ever implement them.

I realise it's not the best news, but it's on the network to solve this rather than the bridge. Alternatively there may be self hostable IRC bots to do this.

Could the bridge at least have a command for opping users without the obscure !cmd irc.snt.utwente.nl MODE #channel +o nickname?

I think having short hand commands in the bridge is within scope, and actually since we merged the ability to do commands inside channels, we could support this fairly easily. Will take to #1328.

when the bridge connector bot notices that the channel doesn't have +R set up (should be easy enough: just query the R mode and determine list if it is empty), it could send a message to the room indicative of this highly likely misconfiguration. The message should only be sent once per channel.

Then on top of this the +R logic could be itself implemented in the bot: IF only the bot is +o, then it should implement the rules of the +R itself for users other than itself. This would eliminate the need for any particular configuration interface for this.

Potentially, although this really feels like logic for a irc bot rather than the bridge. The bridge concerns itself with connecting A to B and doing the best job of mapping state. It's not really the concern of the bridge if the channel is misconfigured. There may be scope for doing this the first time the room is connected, but not on restart / user join. I would really like to avoid the bridge becoming too opinionated about what a misconfigured room looks like.

[olmari]

For what it's worth, mine .02: I kinda like the @eras idea for client-based bridges "flow", this way it wouldn't be bridge integration itself that itself decides new powers etc..

Root-issue in broad general is that users deployed irc-bot is very often propably down when user oneself is down too, or connections related to irc-server state---

"Only" other thing that would solve this kind issue is dual-stack irc-matrix server.

[eras]

I think it would be fair for the bridge to either not use ops at all (and thus not working properly, so this is not a solution) or not "break" the +R mechanism by virtue of just sticking with the sole +o and not sharing it with anybody. This can happen with the proposed command shortcut as well, because it can happen so that nobody has permission to instruct the bridge bot to give anyone ops. Well, except I suppose the helpful people in the Matrix support room :).

So IMHO something should be done automatically with the general idea Don't break things without fixing them.

An alternative that is easier to implement: if nobody in the room has ops, then the bridge should also -o itself. This would permit the normal +R mechanism to function. Of course, it could happen so that +R is configured to op the bot itself, in which case we're back to square one ;).

This latter solution doesn't help with rebooting the room, though, if there is no +R—unless there's someone to instruct the bot to also leave, like the support room.. But I think we all prefer systems that just work automatically without human interference.