NSIDs, due to their dynamic nature, create a challenge in modeling reusable permission building blocks. I will use SpiceDB as my example here
- You define the possible subjects, resources, and relations in a schema and apply that to the database
- We have to map application lexicon onto, and grant permissions over, within the schema, which we hope is general enough for most apps
So how do we represent something like permissions to read/write in a discord channel? It has a record under a NSID which is unknown to the permission schema. How do we assign permissions to operate on other NSIDs based on the current NSID? (i.e. creating a thread within a channel)
Apps will need to put constraints on the permissions available to a user, depending on context which may include another NSID. In the general schema, apps will have not have a way to specify domain specific permissions. (This idea, and the potential solutions to it, is another thread)
SpiceDB has two ways of dealing with dynamic data or context
- Create a generic (i.e. NSID) resource in the schema, this means we need to create two relations for every record. (parent→NSID→record)
- Use caveats, elegant but likely computationally prohibitive (in spicedb at the scale we need to use them for NSID)
- Contextual relationships - SpiceDB 1398, one of the founders of Authzed pointed me at this and said the atproto use case is probably a good example for implementing this feature request
Anyway, I’m working through this with SpiceDB, but it seems a general challenge that I’ve only discovered / encountered since I started building. At this point I mainly wanted to share this with the group and start to gather our collective thoughts.