you'd also use the zedtoken returned from

WriteRelationships

and store it on the resource you're modifying

right on. the thing that complicates that on my team is that we use a variant of the clean architecture, so we don't know if a particular function is going to produce spicedb changes or not since that is an implementation detail. something we could do, though, is rather than making individual calls to spicedb within repo methods that a function might call, aggregate the relationship update structs into a single list and then write them all at once when the business logic finishes. like a custom transaction implementation. it would be tougher to validate that relationship updates will be valid within the business logic but it would work

so long as you can store the `zedtoken`s, yeah

unless you don't mind having eventual consistency on the

check

for sure, that list that gets filled in with relationship updates could also accept like redis keys for each entity involved in the change and the zed token could be written to those keys once everything else succeeds

yep!

we do recommend storing zedtoken's next to the data in the DB, but redis works too (so long as it isn't considered completely ephemeral)

@User correct me if i'm wrong, but i think in this case redis is the durable storage

our primary data store is a relational database but we have durable redis instances as well that have backups and all that kind of thing

i think that's beside the point, we could also set up separate tables in the database or just write to the appropriate zed token columns before committing the db transaction. the point is that it would totally work and you guys really helped me out here today

thank you! 🙏

our pleasure

Hey Guys, just came across SpiceDB from hackernews while researching about Zanzibar (complete newbee on that field=. I am working für Siemens and we are evaluating different options on how to implement authz for our newly digital twin platform. SpiceDB seems an interessting option for us, since it would make things easier. I have evaluated some use cases using the playground you provide and so far it was "relatively" easy. As digital twins represent a state of a real life asset (in our case some machines) we also have some use cases, where we need to evaluate the permission based on the state of that twin. I wonder how to model such use cases in SpiceDB? - So in concrete that would mean: We have a role support engineer. This role support engineer is only allowed to set a specific value on the twin (let's say last maintenance date) if the state of the machine is NOT_RUNNING. Would be nice if someone cloud guide me to some helpful docs or give me a hint on how to model such a use case, as I can't get my head around it! - Thx in advance.

I have a second question regarding the schema: How do we manage versions / expand a schema in production? - I think of a system, where we start small and then expand depending on the use case.

I slapped together a really basic example of your problem as I understood it. Basically the idea is to create a type for running machines and check the permission through that type. https://play.authzed.com/s/XTGuyZNQxGzD/schema (take a look at test relationships and assertions)

Managing schemas in production is very similar to managing the schema of a relational database. We recommend defining new permissions that are backwards compatible with the old permissions such that once all your code is updated, the old permissions can be dropped from the SpiceDB schema. You can define permissions in terms of other permissions, which helps a lot for this use case (e.g.

permission read = readers; permission write = writers + read

if the definition of

read

changes in this example, there are no changes to

write

to make it have the desired behavior).

Happy New Year to everyone!

one follow up question to this strategy: what would you do if the call to either

transaction.rollback()

or

transaction.commit()

failed?

i guess i'm actually just asking "how do you do a distributed transaction" which i can learn about on my own. nevermind!

yeah, unfortunately its not simple

you could just "undo" the write by deleting the stuff you just wrote

but that has its own risks

we've been mulling some ideas to make this much easier

Hi, I have a few more questions, which are in some way interconnected: 1. what's the consequence of not using zed tokens, the checks probably would be eventual consistent, but what type of latency could we expect for the convergence, are the permissions/relations cached and if yes for how long? And the second disadvantage probably is slightly slower checks... Are there any other disadvantages? 2. Is it possible to run 2 deployments - one, which is used only for writing and one, used only for reading permissions? Are there any real disadvantages? As I understand, there is currently no other way to define some sort of access control for the clients. 3. I don't see any frontend JavaScript libraries (there is a NodeJS library, but it uses gRPC and is strictly for the backend usage, as far as I understand ), is it some sort of an anti-pattern to check the permissions directly from the front-end?

1. If you don’t use a zedtoken it’s up to the server to pick a recent snapshot to evaluate against, it will attempt to maximize cache usage by default. We don’t promise a convergence period, as of right now production is configured to converge within 10s, but we recently changed that from 5s to 10s.

2. I can’t think of any reason why it wouldn’t work to run spicedb like you describe, you will have to handle service naming, request routing, ssl etc. to make it work

In authzed.com our tenancy layer has access tokens with specific roles

3. Yes it’s an anti-pattern to check from the front end as you would need to give your secret key to the client in the browser, which the user could compromise

Thanks for the quick and helpful response, I could now at least eliminate some solution possibilities. authzed.com, as far as I see, does not store data explicitly in EU, so it is unfortunately not an option for us.

@User that is something we're willing to address for EU-based customers