An invite exemption is NOT a ban exemption.

[yunginnanet]

This should require no further explanation.

[yunginnanet]

#1875

[progval]

Invites usually override bans. And invite exceptions are treated like a permanent invite, so this doesn't seem wrong to me.

[yunginnanet]

Invites usually override bans. And invite exceptions are treated like a permanent invite, so this doesn't seem wrong to me.

Seriously!? I mean, I guess I'll double check the RFC(s).

[progval]

I may be wrong, but the current behavior is not completely nonsensical either.

[yunginnanet]

Invites usually override bans. And invite exceptions are treated like a permanent invite, so this doesn't seem wrong to me.

https://datatracker.ietf.org/doc/html/rfc1459#section-4.2.1

RFC 1459 - Internet Relay Chat Protocol - May 1993

   Command: JOIN
   Parameters: <channel>{,<channel>} [<key>{,<key>}]

   The JOIN command is used by client to start listening a specific
   channel. Whether or not a client is allowed to join a channel is
   checked only by the server the client is connected to; all other
   servers automatically add the user to the channel when it is received
   from other servers.  The conditions which affect this are as follows:

           1.  the user must be invited if the channel is invite-only;
           
           2.  the user's nick/username/hostname must not match any
               active bans;

           3.  the correct key (password) must be given if it is set.

furthermore

That's literally what +e is for. +I is not +e.

[slingamn]

I'm willing to reconsider this, but it is not a straightforward decision at all, particularly considering that it is a compatibility break that will result in people becoming newly unable to join channels.

Keep in mind that the RFCs are not necessarily authoritative on this issue (or any other, really); that's what modern.ircdocs.horse is for. It sounds like you are experiencing a problem with the current behavior in your deployment? What is the problem specifically?

[progval]

Looking at the code, it doesn't seem like INVITEs override bans in Ergo, so there's indeed an inconsistency here, but it does not seem to be such a big deal. I agree with slingamn this deserves to be discussed.

[slingamn]

INVITE was intended to override +b (and did so in v2.2 and v2.3), but does not due to a regression introduced in v2.4. I have filed a separate issue for this as #1876.

The issue in this PR (whether +I should override +b) was discussed previously in connection with #1168, and the outcome was that it should, so the current behavior is intentional (although it can still be reconsidered, of course). But in the absence of a specific reason to change the behavior, the current behavior will probably stand.

[deltreed]

What about the potential for ban evading? If I were able to get a bot +o in a channel where i was +b previously, i could technically avoid being banned if that was overridden by an invite every time.

[FiskFan1999]

I agree with /invite overriding channel bans and all other restrictions. Invites can only be done by channel ops (or higher) which is the same level of moderation that adds channel bans. I don't see what would be the gain of making this change, except perhaps to protect the chanop from themselves, so to speak.

[slingamn]

If I were able to get a bot +o in a channel where i was +b previously, i could technically avoid being banned if that was overridden by an invite every time.

You could just have the bot remove the ban, right?

[deltreed]

If I were able to get a bot +o in a channel where i was +b previously, i could technically avoid being banned if that was overridden by an invite every time.

You could just have the bot remove the ban, right?

Yeah, you're right. I for a moment thought that halfop could invite but I just verified this is not the case. However you're right, the other circumstances of having a bot or alternate client in the channel as an operator has no weight on either direction of functionality. My mistake.

[yunginnanet]

aight den

explain why +e exists.

[slingamn]

Here's where we're at in this discussion: on other ircds, +e and +I are orthogonal, but in Ergo, +I is a superset of the privileges of +e, i.e., +e exempts you from bans only, but +I exempts you from both bans and the +i mode.

The question "what is +e for?" seems like a distraction since, after all, +e has its normal semantics in Ergo; the place where Ergo has changed the semantics is +I. I am looking for an example of a situation where the current behavior actually restricts the options available to moderators, i.e., a setting where a channel is sometimes -i (public) and sometimes +i (invite-only), and there is an actual use case for making a mask +I (invited under +i) but having some people who match that mask be banned by a +b ban.

[DanielOaks]

I'm alright with this being resolved either way, no stress. We don't pay too much mind to the RFCs, but if this is causing a usability issue then definitely let us know.