but i have things i need to finish before i get there

im not sure its worth your time, but maybe it is. i don't truly understand the emerging industry of sass going heavy into oss territory.

by that i mean opensourcing their core offerings. I'm completely ignorant to the business model and naive to strategies surrounding decisions with regards to adoption and growth.

one bit of feedback for your service; from the perspective of a small fry bootstrapping startup, your offering is overkill at my stage

i am no where near needing the distribution and sophistication you currently provide. a single region/zone would be sufficient. I imagine that's actually more costly for you until you reach certain thresholds of adoption.

the SaaS is a single global deploy of spicedb with tenancy layered on top, so our expansion strategy is to go where our customers need us to be until we run out of datacenters to expand into

that's awesome. im sure you guys are stoked. its gotta feel good.

Building on top of a conversation a couple days back with granting access to a category of data, what would be the correct approach? There was a previous discussion of having e.g

definition example/resourcetype {
    viewer: example/user
}

for example, but how should we think about resource types that have different actions/permissions

for example, one resource type might be associated with permissions to

create

,

view

, and

comment

, while another will have the permission to

view

,

delete

,

restore

,

archive

,

unarchive

,

create

If we were to represent it through

resourcetype

, we'd have to take all permissions of all resource types, and make them available on the "resourcetype" definition

so in short, we have something like

definition entity1 {
    viewer: user
    creator: user
    commenter: user
}

definition entity2 {
    viewer: user
    deleter: user
    restorer: user
    archiver: user
    unarchiver: user
    creator: user
}

definition resourcetype {
    viewer: user
    commenter: user
    deleter: user
    restorer: user
    archiver: user
    unarchiver: user
    creator: user
}

in reality, we might have slightly fewer relations and more permissions (e.g archive and unarchive are probably covered by one relation and two permissions), but the problem still exists

or is the solution here to represent top-level permissions and policies with constraints? Like granting

job.view

, and then having a

Policy

with a constraint where the job ID must be 42

In general I haven’t yet found a solution to user defined resources like this yet. It seems like putting all of the possible mutations on resource type and then only referencing the specifically relevant ones from the leaf schemas might help a little

to be clear,

entity1

and

entity2

are owned by us, but our customers can define their own teams. Each team can have access to either a "category" or "type" (e.g "all recruitments within the company"), or an individual entity ("recruitment 42"), so that's what I'm trying to represent; the ability to have access to "all recruitments"

it's effectively a massive IAM and policy system

according to our google sheet we have a grand total of 126 different actions (some overlap in meaning though and could be narrowed down to the same relation), and 134 different entities (though again, some overlap)

So as long as your end user doesn’t need to define new “recruitments” then I think you can just have a concrete definition and aggregation layer that’s specific to each type

You might want to generate it though

Is there another layer of hierarchy that defines a customer tenant?

The other option is to just put relations for each sub-type action on that object

Would it be helpful to jump on a call?

So one issue that came up with this solution is that we want the role to apply for all team members which should include team maintainers as well. Adding

relation member: github/user | github/team#member

only covers the team members but not the team maintainers, who should also be considered members. The way we’ve been working with team membership as being inclusive of members and maintainers is with a permission on the team object which is

permission membership = maintainer + member

. I realize we could grant the role to the team maintainers in addition to the members via

github/role:repo_manager#member@github/team:team_fgp#maintainer

, but that doesn’t feel quite right. I’m wondering if there is a way we can adjust the team

member

relation to include the

maintainer

relation for the same team and get this to work. I added an assertion to our playground for a team maintainer which is currently failing to illustrate this https://play.authzed.com/s/op7kPxacSaMU

we usually do this with

member = maintainer + direct_member

and then keep

relation member: github/user | github/team#member

right, that's pretty much what we're doing

the difference in what you posted vs what I have is that I'm using the permission in the relationship, and you're using a relation only

with your exact example, you could also just change it to

relation member: github/user | github/team#membership

and then use the subject (computed, synthetic) relation

membership

when building your relationships

here is an updated playground link: https://play.authzed.com/s/k_ha6IZ6dd-V/schema

Ok yesss this is working! TIL you could do

github/team#membership

I had it in my head that relations can only reference other relations or objects