what's the use case you have in mind?

So our use-case: 1. We have a lot of various potential resources that can have attached permissions from various domains (teams) 2. Those resources can mean various things, but we were inclined on using a generic resource definition that can have attached various permissions - those permissions would be understandable by the teams setting the permissions 3. The permissions can be generic (like "edit" or "view"), but also very specific to the team's domain (e.g. "control_configuration"). What we were thinking about is whether we should go with the direction of specialized resource definitions (e.g. SystemADirectory, SystemBDirectory, SystemBFile, SystemCFIle), and then specialized permission+relationship definitions within that, or whether there is an easy way for us to manage this more dynamically - so we could attach relationships that would be specific to given domain, but basing on a schema that is domain-agnostic. As an additional level of complexity that we are thinking about potentially keeping outside of SpiceDB (but we might be wrong about that) are roles - which can cross-cut above domains but provide sets of relationships (permissions) at given level of hierarchy of resources I believe UDR can be helpful with the latter part, but not necessarily with the former (as in UDR example those relations that are referred to as "grantable capabilities" are static, and they are referred by static permissions to make the permission checks).

i wanna make sure we're talking about the same things - there's a "user defined roles" blog post that has a github-ish model that works one way and a "google cloud iam" blog post that creates something like AWS or GCP IAM that works a different way. which one are you referring to when you talk about "UDR?"

The githubish/jira model ;). The GCP IAM approach is actually what we are leaning towards now - more explicit, but obviously any new permission requires model change.

if everything was truly dynamic, can you give an example of what a concrete permission check would look like? like what's the experience you'd be looking to provide to your devs?

I'd say it's semi-dynamic, but to give an example: We have 4 levels of resource types: organization, department, repository, file Team A comes in and says they would like to add EditRepository, ViewRepository and DeleteRepository permissions -> and they want those permissions to be attachable at organization, department and repository level Team B comes in and says they would like to add EditFile, ViewFile and DeleteFile permissions an all levels -> and also make it that if someone has a \*Repository permission attached, then they get the appropriate \*File permission automatically. Now, in addition to above, we want Team A to be only able to directly query or set permissions they defined, and for Team B to be able to directly query or set permissions they defined (for domain separation) -> the only cross-team separation is through configuration of dependency between permissions We can do above through directly modifying the schema of SpiceDB, but we could also create a generic "relationship" that has e.g. two caveats of "EditFile" + "Team B" -> that way we can define that during query time only relationships for given resource that have those caveats will be taken into account -> that way we have extremely simple SpiceDB schema, but we do rely heavy on Caveat evaluation. Another thing above is the dynamism of resources -> we could have specific Org, Department, Repository & File entities in SpiceDB, or we could have a singular "Resource" one that can have child-parent relationship, but where we would not really need to worry about types and schema changes (we could implement types e.g. as composite keys, so an identifier of a resource could be Org:3245435, Repository:ABCDF etc.).

are Team A and Team B in this scenario teams of developers or teams of users?

Teams of developers - namely we are separating the different domains of our product so that any cross-dependencies are explicit and well-thought-through, so we don't end up with codependency everywhere. Will do! I am hoping to set aside some time this week for schema remodelling 🙂