I'm here for the syntax bike-shedding:

• requirement~>viewer
• requirement=>viewer
• requirement.viewer
• requirement->>viewer

I'm here for the syntax bike-shedding

Additionally: &> or &-> but I like ~> best.

~> is certainly simpler to implement, but not sure if there is a strong connection between ~ and the intersection operation here

Another idea: requirement->&viewer, since it is the intersection of all the viewer's

We would be highly interested in this feature as we have a scenario like this in our business requirements for authorization to specific kinds of resources that have dependencies. What would be the current workaround for this problem? For the concrete example you gave, can such a check be achieved in spicedb at all, or would the client have to make sure to run all necessary checks as separate calls and evaluate the "intersection" constraint itself?

@phdowling Right now you'd need to issue the checks yourself and compute it client side. Intersection currently only operates over distinct relations, not within one.

Suggestions are welcome for the operator to use, as it is the main blocker for adoption

Thanks for the quick response @josephschorr. Since you ask: to me, => makes intuitive sense as it looks very similar to -> but has multiple lines, so you can read it as "follow all paths, not just any path". I also like &> and ->& (and other & variants) since it makes the logical operator clearly visible.

I would be happy to test any draft implementation even if the syntax is still subject to change.

Another possible syntax:

definition user {}

definition folder {
  relation viewer: user
}

definition document {
  relation parent: folder
  permission view = parent.any(viewer) + parent.all(viewer)
}

The parent.any(viewer) would be equivalent to today's parent->viewer (they'd be aliases) and parent.all(viewer) would represent the user being in viewer for all parents.

@josephschorr is this on your development roadmap now by any chance? We're still quite eager to push down more of our authz logic into SpiceDB, our current approach of issuing multiple calls to SpiceDB and computing the intersection ourselves feels like an anti-pattern. Coupled with caveated relationships (great stuff by the way) this would get us to a point of handling basically all authz business logic declaratively and efficiently through SpiceDB!

My 2 cents on notation: .any() and .all() are great options IMO, since they are very readable and self-explanatory. From all of the arrow-like options, I probably like => the best (see above, "one link vs. many links" mental model).

We have a similar use case to what is described in the issue with one exception. Here's a simplified version of our schema:

definition user {}

definition worker {
    relation manager: user
    permission manage = manager
}

definition job {
    relation viewer: user
    relation worker: worker
    permission edit = viewer & worker->manage
}

Not only would we want to make sure that a user has permission to manage all the workers of a job in order to edit it, we want a user to be able to edit a job if there are no worker relationships on it (so they can start/resume the job with their own workers). Though I'm not familiar with the spicedb internals, I think this would make sense when it comes time to implement.

• Assume the worker->manage check is true
• Start a goroutine for each worker relationship
  • Wait for them all to resolve to a user
  • If anyone of them do not resolve to true, the overall check can terminate early as false.

I'll also add on to the bike shedding over the operator. My first choice would be for .all() because it's the clearest and probably the easiest to google. I imagine a beginner looking over a spicedb schema they've been told to modify for work will Google something like this:
all function spicedb schema

which I bet will have better results than
->& spicedb schema
because google seems to ignore symbols these days.

But if an arrow of some sort is necessary, I prefer ->&.

We are evaluating SpiceDB as a centralized system for storing our old permission data for a decentralized world. For us, this intersection proposal would be crucial as our use case needs this 'can see all documents in a folder to access the folder' permission.

Are there any news (e.g. a roadmap) for this feature?
Are there any ways we can support the implementation of this feature?

Hey @tafli

It is possible to enforce that a user has a given permission on all of an object's parents with SpiceDB today. You'll need to use an "and tree" to do this.

In this example that continues the original example, a user can be required to have view permissions on all roles to view the document.

Thank you, @corkrean
I took a look at this and the problem I see is to build up (and manage) this "and tree". Imaging having hundreds of different files in a folder.

We also had a similar idea using a linked list, which also did work. But the same problem here with building and managing the relations.

@tafli Initial implementation has now been issued

After further internal discussion, with the introduction of .any and .all, we won't be adding another syntax for intersection arrows and, most likely, will deprecate and eventually remove -> down the road