I definitely understand the appeal of using SpiceDB as the source of truth for some of your business domain, as you'd potentially eliminate a set of problems surrounding state synchronization. You can certainly build client logic that would know how to walk the SpiceDB graph and issue a bulk delete (e.g.

ReadRelationships

+

DeleteRelationships

). The latter comes with preconditions https://buf.build/authzed/api/docs/main:authzed.api.v1#authzed.api.v1.DeleteRelationshipsRequest so I wonder if you build a statement that fails if a new element appears in the graph. If that was the case, you'd need to retry the operation again (similarly to how distributed databases like CockroachDB would do in case of overlapping transactions).

That's very interesting, I hadn't considered using MUST_NOT_MATCH pre-conditions for this purpose.

yeah you can certainly "short-circuit" permissions. One strategy you can use is to create a root container (e.g. not a folder, but call it "root" or "platform") and have a relation with type

User:*

. Then any permission definitions in your folder should be defined in terms of their own relations, but then intersect those with the top level "on/off" flag. Let me see if I illustrate with an example

definition user{}

definition file{
  relation parent: folder
  relation viewer : user

  permission view: viewer & parent->exists
  
}

definition root{
  relation exists: user:*
}

definition folder {
  relation children: resource | folder
  relation parent: folder | root
  
  permission exists: parent->exists
}

Haha thanks, I do really appreciate it!

that may address the problem, but you end up with dangling elements in the graph, but maybe you could write a GC job that runs from time to time. We also want to implement relationship expiration eventually.

Yes, "dangling elements" describes the problem I'm trying to concisely solve perfectly

>I wonder how it would fair under a "deep depth" scenario, i.e. A -> B -> C -> D -> E -> F -> G, and while we're deleting B -> C -> D -> E -> F -> G because B was deleted by a user, whether preconditions would protect against someone creating G -> X yah I'm not completely sure. the API allows you to specify filters based on resource names, relation, and optional subject. Maybe you could come up with a pattern to identify existence of a resource. @Joey is not up in his TZ yet but maybe he's able to come up with some pattern to solve this

Thanks @vroldanbet . Hopefully @Joey can shed some light like you say. Regardless, I really appreciate you workshopping these ideas with me

https://github.com/authzed/spicedb/issues/315 is an issue someone filed around a similar issue