View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005991 | unreal | ircd | public | 2021-11-02 18:31 | 2021-11-05 15:08 |
| Reporter | progval | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Product Version | 6.0.0-beta1 | ||||
| Summary | 0005991: Make the new extban names consistent with InspIRCd | ||||
| Description | Hi, I noticed that both UnrealIRCd and InspIRCd are both going to introduce named extbans in their next major version (respectively 6.x and 4.x). As neither is released yet, I think this is a great opportunity to make them consistent with each other, which will make life easier for client developpers. If both Insp and Unreal can agree on these names, I have good hope they can be standardized through IRCv3 (and followed by other IRCds like Solanum or Ergo) so client developers can implement nice GUIs/automation that does not require server-specific knowledge. Here is a review of Unreal's extbans (based on this: https://github.com/unrealircd/unrealircd/blob/4ea6c82a5d7b069e306936204a27794235829397/doc/conf/modules.default.conf#L193-L206 and an extra from https://www.unrealircd.org/docs/Extended_bans ) compared with InspIRCd's (based on https://docs.inspircd.org/3/extended-bans/ at the time I am writing this) > loadmodule "extbans/join"; /* +b ~j (prevent only joins) */ N/A (Insp does not have it) > loadmodule "extbans/quiet"; /* +b ~q (prevent only messaging) */ InspIRCd calls it "mute" > loadmodule "extbans/nickchange"; /* +b ~n (prevent only nick changes) */ InspIRCd calls it "nonick" (letter is "N") > loadmodule "extbans/realname"; /* +b ~r (ban by real name) */ Consistent with Insp (uses a different letter, though) > loadmodule "extbans/account"; /* +b ~a (ban/exempt if logged in with services account) */ Same name as Insp (uses a different letter, though) According to its documentation, Insp allows a subtly different set of of values, though: 1. wildcards are allowed (Unreal only allows `*` as special value) 2. uses a different extban ("unauthed" / "U") instead of `~account:0`/`~a:0` > loadmodule "extbans/inchannel"; /* +b ~c (ban/exempt if in channel) */ Insp calls it "channel" (and uses letter "j") > loadmodule "extbans/operclass"; /* +b ~O (ban/exempt by operclass) */ N/A instead, Insp has an "oper" extban that matches the oper account, and "class" for any user class > loadmodule "extbans/certfp"; /* +b ~S (ban/exempt by certfp) */ Insp calls it "sslfp" (letter "z") > loadmodule "extbans/textban"; /* +b ~T (censor or block text) */ N/A Insp uses a specific mode: https://docs.inspircd.org/3/modules/chanfilter/ > loadmodule "extbans/msgbypass"; /* +e ~m (bypass message restrictions) */ N/A > loadmodule "extbans/timedban"; /* +b ~t (timed bans / temporary bans) */ N/A > loadmodule "extbans/partmsg"; /* +b ~p (hide part/quit message) */ Consistent with Insp (including the letter) > loadmodule "extbans/securitygroup"; /* +b ~G (security group) */ N/A > loadmodule "extbans/country"; /* +b ~country (country/geoip) */ Consistent with Insp, including the values AFAICT > f forward chanmodes/link Forward user to another channel if matching mask. N/A As you can see, a large part of the extbans have a nice mapping to Insp's extbans. So I would love it if you could rename these. (To be clear I'm not suggesting Insp's names are better; I just needed to start somewhere and you seemed more open to the change :) If there are some names you really don't like, I'll send a similar suggestion to Insp to rename their extbans to yours.) Thanks for reading! | ||||
| Tags | mode | ||||
| 3rd party modules | |||||
|
|
What I always try to keep in mind when adding an extban is using the following logic: "for +b, i am banning.... [something]" So ~join, as i am banning joins So ~account, as i am banning an account And so on.. channel, security-group, operclass, realname, etc. (small side note, we do call it ~channel, just the module is called inchannel) With that reasoning in mind, I'm not much of a fan of something like "nonick" as it means "I am banning nonick" which is incorrect. Instead, as you can see I chose "nickchange", which fits with the "i am banning nick changes". I did not chose "nick" either (not that you mentioned this option) because you are not "banning a nick", it's the nick change you are banning. Now for 3 out of 13 this reasoning is NOT applied: * For ~forward: I think that is fine, as it is less of a ban and more of a different thing, and I don't see a better name here * For ~msgbypas: this one is only permitted in +e and then the name is fine. It says exactly what it does.. allows bypassing of message restrictions. And... then we get a real one: For "quiet", but also for "mute", the reasoning I always try to use does not work. You are not "banning quiet [people]" and you are "not banning mute(d) [people]". In fact, you're doing the opposite. If we were to follow the same logic that I try to apply everywhere, the one I mentioned at the beginning, then it would have to be called "speak", "talk" or "message", since you are "banning the ability to speak/talk/message". So: +b ~talk:nick!user@host +b ~speak:nick!user@host ~b ~message:nick!user@host So that is an inconsistency i wouldn't mind getting rid of. Import thing is, of course, that end-users must still be able to understand it. If going that route then I think something like "speak" or "talk" would be better than "message", because in IRC context "message" is sometimes seen different than notice (and it would obviously ban both). Don't know if you or Insp have any thoughts on that. Let me put it this way: IF we are going to change the name for ~quiet then I think it should be with that logic from above, and not with another one that is "just as wrong". So of the 3 different names between UnrealIRCd and InspIRCd: * quiet vs mute: see above, both are technically a misnomer IMO * nickchange vs nonick: i really think nickchange is better (see above) * certfp vs sslfp: haven't talked about that one yet, see below Since the name SSL is being phased more and more I don't think it would make much sense to call it ssl here. Also I think certificate is more accurate, as it is a fingerprint of the SSL/TLS certificate. Let's google a bit to see what is more common: * "ssl fingerprint": less than 5k hits * "tls fingerprint": 93k hits * "certificate fingerprint": 2 million results I have also pondered briefly about calling it just "cert" but I think "certfp" is more descriptive and as you can see where certfp stands for (certificate fingerprint) is used a lot. |
|
|
Well, I asked Insp to change their names, but it's a no https://github.com/inspircd/inspircd/issues/1940 |
|
|
I can understand the first and perhaps main point raised at InspIRCd. I mean, they also thought out some logic (naming them after modes). It's just not my logic or what I would prefer. Some other things I understood less, but that is probably because I am not an InspIRCd user or dev so I'm not familiar with it. Anyway, in the end it means the two naming philosophies are incompatible with each other. That's a pity, it was basically now or never. Well.. at least you tried :) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2021-11-02 18:31 | progval | New Issue | |
| 2021-11-02 18:31 | progval | Tag Attached: mode | |
| 2021-11-03 08:12 | syzop | Note Added: 0022157 | |
| 2021-11-03 23:50 | progval | Note Added: 0022164 | |
| 2021-11-05 15:08 | syzop | Assigned To | => syzop |
| 2021-11-05 15:08 | syzop | Status | new => closed |
| 2021-11-05 15:08 | syzop | Resolution | open => no change required |
| 2021-11-05 15:08 | syzop | Note Added: 0022168 |
