This is just a nugget of an idea for now, but I was reminded toward the end of drafting the changelog for 8.0.0 that we did indeed lay the foundations for making privileges / access levels integrate better with what the server advertises.
As Sopel continues to improve its handling of ISUPPORT, STATUSMSG, and other protocol features, I can foresee that there will be demand for more dynamic functionality. Some wild ideas that came to me:
Make available only the AccessLevel members that actually map to available prefixes the server advertises in ISUPPORT's PREFIX
Given a STATUSMSG prefix, look up which AccessLevel that corresponds to
Given a desired canonical access level, find out whether the server supports it
Specify fallback sequences for decorators such as @plugin.require_privilege() (e.g. require at least HALFOP if it's available, otherwise require OP or above)
I haven't looked at the protocol again just yet to see how feasible these might be, but all the same I wanted to get them out of my private notepad and into the issue tracker so they don't get lost—and so others can weigh in.
This is just a nugget of an idea for now, but I was reminded toward the end of drafting the changelog for 8.0.0 that we did indeed lay the foundations for making privileges / access levels integrate better with what the server advertises.
As Sopel continues to improve its handling of
ISUPPORT,STATUSMSG, and other protocol features, I can foresee that there will be demand for more dynamic functionality. Some wild ideas that came to me:AccessLevelmembers that actually map to available prefixes the server advertises inISUPPORT'sPREFIXAccessLevelthat corresponds to@plugin.require_privilege()(e.g. require at leastHALFOPif it's available, otherwise requireOPor above)I haven't looked at the protocol again just yet to see how feasible these might be, but all the same I wanted to get them out of my private notepad and into the issue tracker so they don't get lost—and so others can weigh in.