if you choose to not use ZedTokens, your staleness risk is minimal but still real: if you're okay with staleness for at most a few 10s of seconds (its usually configured much lower), then you can simply not use ZedTokens at all

or you can explicitly use a fully consistent check in those locations where you know you can't afford staleness, but at a cost of some performance

> but i can hear my team trying to engineer around it by sticking redis in front of it and storing zedtokens there or some other approach this is basically a "zookie store" - it works, but if you lose the redis and you want to maintain consistency, then you need to switch to fully consistency checks until you once again have a ZedToken

got it. that makes sense. thank you!

Hello, I'm using Spice Db for evaluation purposes, so far so good, it seems to be a great product. I have 2 classic use cases remaining in my micro-service environment (most micro-services will have this kind of usage), and I'm not sure how to handle them with spiceDb (my knowledge is quite limited atm 😦 ). The first one is when I need to return a list of data. When I don't have any authorization check, I just execute a select statement with a where clause and voila. But now, I'll need to return only the data where the user has 'read' permission. There will be at the very least 150.000 objects in the database. This is the same as the issue https://github.com/authzed/spicedb/issues/280 Pre and post filtering are a no-go with 150.000 objects. The only solution remaining AFAIK is duplicating the permission data from spicedb to the microservices database. And from what I understand, the clean solution would be to wait for https://github.com/authzed/spicedb/issues/207: I'll then need to call the Lookup Watch API to be notified of any changes to any users permissions And then do a RoaringLookup to copy the roaring bitmap permissions into my micro-serevice database. I'll be able then to issue a select on my application data with a join on the permission local table. Is that right or is there a cleaner way to solve this issue? Thanks

how many objects do you expect the average user to have access to?

if it's on the order of hundreds or less, and you don't have any exclusions

-

or intersections

&

in the relevant schema, the LookupResources API might work fine for you

average user will have access to 50.000 objets

1/3 of all the objects in the system?

if that's the case then yes you probably need to wait for lookup watch and tiger cache

in the meantime I talked to my PO lol 300.000 objects in db and access to 50.000

what's more freaking for me is that's gonna be the volume per year (hence I suppose, it will accumulate over time), hehe

For the second use case:, it's how to display the action buttons on a list of data (to disable the action buttons for which the user has no access). Yes, sorry for the noob questions 😦 Let's say I display 100 items per page (and let's say my app can show 4 actions per line). The naive way would be to call the CheckPermission API for each button and per-line. Hence 400 calls to the CheckPermission API. Other than that, I could rely on the previous solution (permission locally stored on my app database with lookup watch and tiger cache) Is there another way ?

yeah if that's your desired UX, I don't see a way around doing the checks

if you want to tweak the UX, you could lazy load the actions when the user selects an item

or you could show all of the actions and then just show a permission denied (and a resolution?) when the user tries to do something they're not allowed

Thanks very much @Jake for your insights !

how does SpiceDB handle a case where you send

at_least_as_fresh

and there isn't a revision in the database associated with that zedoken? I'm imagining something where CockroachDB or Postgres logical replication takes a moment and somehow the zedtoken shows up before SpiceDB knows about it. does it block? does it error? is it impossible and therefore not a problem?

it takes the current revision

at_least_as_fresh

indicates it needs to be, well, as least as fresh as the time encoded

later is always fine

so if the caches are at time T+1 and the zedtoken is at time T, they can be used

> and somehow the zedtoken shows up before SpiceDB knows about it that's expressly not allowed

the zedtoken is returned only once the transaction has been committed; if the local CRDB node doesn't have the transaction, and we request the data at the time in the zedtoken, it'll go to the other CRDB node

Postgres driver doesn't have this problem because it is not using replication

at_exact_snapshot

, on the other hand, will always evaluate at the exact time of the ZedToken: if the datastore has since moved too far beyond it, SpiceDB will return an error

Hey Gurus, How can I design schema policy like, "Employee can see their own salary" ?

where is

view_salary

permission defined?

yeah, that's me anticipating my team wanting to use postgres replication for multi-region because that's how a lot of the rest of our application is built. are there gotchas there?

it doesn't scale quite as well