search

sopel-irc / sopel

:robot::speech_balloon: An easy-to-use and highly extensible IRC Bot framework. Formerly Willie.
https://sopel.chat
Other
951 stars 405 forks source link

Bot should track its user modes #2588

Open dgw opened 6 months ago

dgw commented 6 months ago

Requested Feature

Pretty much what it says on the tin. There definitely will be cases where some Sopel plugin (hopefully on a carefully controlled network!) needs to know whether the bot is an oper, for example, and it's moderately annoying to figure that out right now.

Sopel's ModeParser should be extensible to handle the bot's own user modes. The fact that viewing or modifying other users' modes isn't allowed (per RFC 2812) makes things easier—no need to account for this in the User object, just the bot.

First thought-experiment implementation: A property bot.modes exposes which modechars are enabled for Sopel's own nick (stored in a _modes attr, perhaps, like other property-backing objects). Either properties or is_*() methods allow quickly checking the presence of certain standardized modes like +o for opers.

Problems Solved

@half-duplex should be the one to fill in this section if/when they're so inclined, since this issue is a response to their grumbling about user modes on IRC ("there's workarounds for all the issues I've had" but "it just could have been easier to get there").

Alternatives

Because OPER status is what specifically brought this up, that's what I can most readily discuss here. OPER status actually has the highest number of viable alternatives; some of the interesting user modes have zero.

Something like the bot's OPER status can be monitored manually by a plugin, listening for e.g. 381 RPL_YOUREOPER, or polling the bot's WHOIS info to listen for 313 RPL_WHOISOPERATOR. Both of these alternatives suffer from the "missing negative", that is there's no corresponding numeric to indicate the removal or lack (respectively) of OPER status.

It's of course possible to kick off a MODE {bot.nick} and hand off a callback to be triggered when the bot gets a 221 RPL_UMODEIS, but that's a ton of overhead for plugin authors to write and it's potentially flaky. (At least this approach gives a definitive OPER/not-OPER answer, unlike polling WHOIS.)

Notes

To be fair, besides +o, most interesting user modes are protocol extensions (like the BOT, CALLERID, and DEAF tokens in RPL_ISUPPORT). That's a big reason I suggest using properties/methods to expose checks for the interesting user modes: because making plugin authors write e.g. if bot.isupport.get('DEAF') in bot.modes is pretty obtuse vs. if bot.deaf—plus the relevant property/method can do something useful like raise a specific exception type if the server doesn't advertise that feature.

half-duplex commented 6 months ago

I think the modes a plugin developer is most likely to want to check are +o (oper) or +r (registered), since those are set by a server, indicate success/failure of something you tried to do, and affect the bot's permissions. Most of the others are either set on request or set predictably when opering or identifying to services, and most are useful primarily for human-interfacing clients. +r is probably the harder to work around, since afaik without SASL that would require parsing NickServ NOTICEs, the format of which can vary widely. I'm fine leaving this on the wishlist until someone else needs it or has an interest.

ETA: Another annoying part of this - There's no ISUPPORT CHANMODES type attribute for user modes, so I guess we would have to assume everything but +s (snomask) has no attributes?