DUH

forgot to save, sec

So instead of having a

resource:specificResource#parent@resource:group_of_resources

for every specific resource-group pair, if the resources group are known in runtime, we could tell the Check engine that it should consider those tuples

Currently the only way to achieve that would actually storing those pairs or make multiple check calls to see if the subject has access to either the specific resource or the group

So for the "Docs" example, you could completely omit storing relations for every single doc until that doc needs it (for example when it's shared) - and then, at runtime, make the engine aware that the doc is in a certain folder which the subject might have access to

i think the best thing would be to just store the relationships, why are you worried about doing so?

Primarily single source of truth

You could consider making spicedb your ~single~ source of truth for the hierarchy

that was supposed to be strikethrough, but i don't know how to do it in Discord

I'm actually doing that with something else (as per your suggestion), but this is so deeply coupled with another service. I'll probably just queue changes and make a "dumb" copy in SpiceDB

Probably shouldn't be so afraid

Hi folks, I would go about if i want to model some attribute based permissions? For instance say in a groups and users, where users can only post depending on the type of group? if that makes sense ...

definition user {}

definition group_type {
    relation type: group
}

definition group {
    relation member: user
    relation type_of: group_type

    permission can_post = member + type_of#type1
}

---

group:group1#member@user:user1
group:group1#type_of@group_type:type1

I know this is not correct but how would I express something like this?

@costap if you're going to use a user as your subject, all paths need to terminate in

user

objects

so you would need to find a way to include the group_type in a chain that heads toward the users

let me put something together

FWIW, using postgres triggers to transform app data into rows in

relation_tuple

is working pretty well, from preliminary tests. However, I'm wondering if we couldn't set that up as a view instead. IOW, I'd run the migrations, then delete

relation_tuple

and recreate it as a view on app tables. What I'm concerned we'd run into, however, is a lack of consistent values for the

created_transaction

and

deleted_transaction

columns, and possible issues with SpiceDB expecting a writable table.

@User maybe something like this:

definition user {}

definition group {
    relation member: user
    relation postable_group: group#member

    permission can_post = postable_group
}
---
group:group1#member@user:user1
group:group1#postable_group@group:group1#member

group:group2#member@user:user2

@User you could try that, although the transaction table would need to be correct if you wanted to be able to make use of zedtokens

spicedb can run in readonly mode

which will disable all writes to the backing datastore

i highly recommend synthesizing the transaction table and using zedtokens though, it's how you get scalability

So my understanding of zedtokens is they're used to prevent accidental access to a revoked resource when spicedb is eventually consistent with the application.

sort of

they're actually a mechanism to allow for some amount of staleness (and therefore caching and scalability), while still preventing the kinds of bad things that can happen when you do have an eventually consistent system

spicedb on any of its backends could actually be fully consistent by default, but then you would always have to go to the datastore for every single read

So for example, when you have an RDS cluster of Postgres databases. Within any given replica spicedb can be fully consistent with the app data. However, the write replica may have the latest data but the read replicas may not, and if you're querying a read replica, you could get stale data.

yep, although we haven't evaluated that exact case, cockroachdb would be the "scalable but still consistent" version of a backend for spicedb, we haven't evaluated what would happen if you hooked up the postgres driver to an eventually consistent datastore