I would like to model something analogous to permission boundaries in spicedb. For example, a user should only have view access if they have a shared permission AND they have an accesslevel (e.g. permission boundary) that grants them that minimum level of access. An accesslevel can have one or more minimum permission boundaries that it governs. Do you guys have any examples of this? Basically I want to be able to define a permission in one resource definition based on the intersection of a permission in that definition and a permission in another resource definition.

I think you're on the right track with using intersection

do you have a playground link that I can use as a starting point?

This is what I have so far: https://play.authzed.com/s/GeueNJx6Hymd/schema

The issue I'm running into is that I want to express that an access level can have multiple relations defining the "permission boundaries" and the user is a member of a given accesslevel. And then not having to enumerate all of the accesslevel relations in subsequent resource definitions by instead just referencing the permission.

this is what I came up with, before having looked at your example

wdyt?

you'll need to redefine the

object_type

per tenant to avoid having a user match by having the permission boundary in a different tenant but the direct access level in the document's tenant

Yeah I think that'll work based on my initial modeling with your example. I'm trying to understand your comment better though > you'll need to redefine the object_type per tenant to avoid having a user match by having the permission boundary in a different tenant Thinking about that comment..

Is there a good way to avoid having to write the

document:firstdoc#type@object_type:document

relationship in your example? I'd prefer not to have to write the relationship for every document object that gets created. It'd be nice to have an overarching tuple instead of duplicating that many times. I haven't thought through it much, but that's what I'm hoping for. If it's not possible it's no biggie, but it would be nice not to have to write a tuple per resource.

👋🏻 hi frands!

Is discord the preferred venue for questions, vs say GitHub Discussions?

So far, it’s GitHub issues for proposals and discord for everything else

awesome, sounds good!

Alright, let me drop a couple of questions I have so far after looking at the docs and tinkering with the API, hope that's ok! - Is there general guidance for schema evolution in a production system? - Are lookup / expand operations paginable? - Just to check if I got it right: the reverse of "Lookup" semantics can be done with "Expand"? Is it expected the response tree needs to be traversed by the client application? I'm looking at the convenience of the Lookup response - Write API allows adding and deleting relationships, in bulk, and conditionally. When would one want to use the Delete API?

- In the future we may make additions to the spice/authzed.com API which allows us to help with migrations, for now the guidance is to use the same methods you would use for a db schema migration, i.e. 4 phase migrations for anything that is backward incompatible: add new and write both read old, write both read new, write new only, delete old

- lookup is streaming, expand is neither, we may make a backward compatible envelope with a cursor to our streaming responses which would allow the stream to be resumed from any point

- expand is not quite the inverse of lookup since it doesn't recursively resolve and preserves the tree information. we're considering a new API: lookupsubjects which would do what I think you're looking for. I think the only public reference we've made to it so far is in the tiger cache proposal: https://github.com/authzed/spicedb/issues/207

right now usersets with optionalrelations that appear in an expand response would have to be manually re-expanded, and the tree has to be walked by the client

- delete with filter is the inverse to read with filter. It allows you to do things like: "delete all relationships for this tenant without enumerating them ahead of time"

go ahead and file issues for the changes/improvements you want to see, and we'll gather feedback from the community and prioritize their inclusion

sounds like #1 would be

LookupSubjects

though?

we've already wanted that one for ourselves, the most contentious part of the discussion is whether we need to preserve the resolution path for each subject, e.g. this user has the read permission on this resource via being a writer on the resource

LookupSubjects is certainly a use-case we have in production and would want to replace with the SpiceDB equivalent. I think potentially having the client do the recursion could be a temporal stopgap for us until

LookupSubjects

is in place. It's also worth noting that

LookupSubject

is more infrequent in our application than

Lookup

semantics

right, we only use expand/lookupsubjects for driving permissions panels basically

but lookup is often used for driving user-specific pages

We'd be looking at having our engineering team also potentially contribute what's missing in SpiceDB, and the idea of sponsoring y'all has also come up.

We want to avoid at all costs having to maintain a fork