This is an umbrella ticket. There are likely many self-consistent, increment steps that can be taken towards the overall goal. These can be described in separate tickets and resolved individually.
ZKAPAuthorizer works on capabilities in many places. It frequently represents these capabilities using str or bytes values. These are problematic because they are opaque:
is any given str or bytes value a capability? Who knows.
What kind of capability does a given str or bytes value represent, if any? You won't know until you parse it.
Additionally, where more expressive types are used they are frequently from Tahoe-LAFS which doesn't promise a public Python API.
Instead of these things, use the recently created and released tahoe-capabilities library. Where that library is missing functionality we need to get away from string representations and private Tahoe-LAFS APIs, add that functionality to tahoe-capabilities.
This is an umbrella ticket. There are likely many self-consistent, increment steps that can be taken towards the overall goal. These can be described in separate tickets and resolved individually.
ZKAPAuthorizer works on capabilities in many places. It frequently represents these capabilities using
strorbytesvalues. These are problematic because they are opaque:strorbytesvalue a capability? Who knows.strorbytesvalue represent, if any? You won't know until you parse it.Additionally, where more expressive types are used they are frequently from Tahoe-LAFS which doesn't promise a public Python API.
Instead of these things, use the recently created and released
tahoe-capabilitieslibrary. Where that library is missing functionality we need to get away from string representations and private Tahoe-LAFS APIs, add that functionality totahoe-capabilities.