-
-
Notifications
You must be signed in to change notification settings - Fork 405
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bot should track its user modes #2588
Comments
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. 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? |
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 theUser
object, just thebot
.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 oris_*()
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 theBOT
,CALLERID
, andDEAF
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.The text was updated successfully, but these errors were encountered: