Description
I noticed this weekend that .blocks add hostmask <regex> actually adds a host block, and doesn't work as expected if given an actual hostmask, e.g. *!*@bad-domain.tld. Ignoring the fact that I gave an invalid regular expression (starts with a quantifier), .*!.*@bad-domain\.tld won't work as expected either.
What .blocks add hostmask actually does is add to the host_blocks, which does exactly what it says on the tin: It blocks based on the line originator's host. It's a bit confusing, due to the command naming.
The simple solution would be to rename the .blocks ___ hostmask commands to .blocks ___ host, but I'd like to do more than that:
- Rename
.blocks ___ hostmaskcommands to.blocks ___ host(coretasks:.blocks hostmask->.blocks host#2344, for 8.0) - Implement a real
.blocks ___ hostmaskcommand set that actually works on hostmasks - Validate ignore masks before adding them (at present, adding an invalid entry can crash Sopel, but without saving the bad entry to the config file; implementing config: Auto-save logic #1354's config auto-save would make bad ignore entries a serious pitfall for new and fat-fingered bot owners alike)
- Add an API (perhaps
bot.is_ignored(Identifier)?) to check an arbitrary user Sopel knows about- Would need to handle unknown (offline) users somehow… probably with a specific exception. Sopel deletes users who part all common channels or quit IRC, so checking their blocked status would be incomplete at best
- Add
Triggerattribute(s) so@plugin.unblockablecallables can tell if they've been called in spite of a block entry - Make regex syntax optional for ignore-list entries, e.g.
/nick-?regex/vs.nickname(/will never appear in a valid hostmask, hostname, or nickname, so it's a logical choice)- Ideally, the new, default, non-regex syntax would support conventional wildcards identical to how ban masks are interpreted by IRC servers (
*and?)
- Ideally, the new, default, non-regex syntax would support conventional wildcards identical to how ban masks are interpreted by IRC servers (
The first three items definitely can be done in Sopel 6.x 7.x, as the only users who can actually use the ignore-system commands are bot owners/admins who read the changelogs before upgrading. (You do read changelogs before upgrading, riiight? 😛). Validation would be a nice non-breaking enhancement, too.
I'm less inclined to change how config file entries are interpreted in a point update, so making regex syntax optional might be a Sopel 7 8 thing. But if there's a clean way to just quietly tweak existing configs on first start and make all existing ignore entries into the regex variety (however that's represented in the file), it doesn't have to wait. The biggest barrier to that is that Sopel's config file isn't versioned—but determining the config format version is easy if it doesn't contain a version! 😁
Self-assigned this because I already started thinking about the implementation, but no code has been committed Yet™. Therefore, it's also Patches Welcome until I actually prototype (some of) the changes.