Hey folks, I've got a couple of questions: 1. Is it possible to make a LookupResources call without specifying the permission? meaning all permissions are of interest. We could make multiple calls but then the results might not reflect the same DB state, unless we also specify a ZedToken from some prior call. 2. Thinking on how to keep track of a ZedToken server side, it could be saved in some KV cache (e.g. redis) and updated when writes are made, but then how to verify when we update the cache that indeed the ZedToken is newer? Thanks

Hey 👋 1. It's not possible. Could you perhaps elaborate on your use-case? We are working on a BulkCheck API (https://github.com/authzed/spicedb/issues/621) and I wonder if that would be sufficient for your use-case If you issue multiple LR calls, you can use

at_exact_snapshot

consistency to get the same results across all permissions 2. it's currently not possible to determine if a ZedToken is newer than another one. Feel free to add your use case in https://github.com/authzed/spicedb/issues/1162

1. The use case is simply listing the resources of a certain type a user may access along with the permission such as read/write. I don't believe BulkCheck would help here, and using at_exact_snapshot sounds like a solution but requires providing some zookie, and also risks the case where the snapshot is no longer available. 2. The issue does raise a similar case, although it does suggest a workaround that could apply there but not for the current use case. I wonder how such situations don't rise more often, are ZedToken normally only used within the context of some larger operation and then discarded rather then saved somewhere in which cases some comparison is likely needed?

Hey @magaf sorry for the late follow up 🙏 >The use case is simply listing the resources of a certain type a user may access along with the permission such as read/write. It all depends on what your business domain looks like and how you want to reflect it in the application. When you say "read/write" permission we could be talking about a grant, e.g. someone has been granted the

writer role

by writing a specific relationship that grants them permission, or you could be talking about the synthethic permission defined in your SpiceDB schema, e.g.

permission can_write = writer + admin

For example, you could read all the resources of a given type a user has a relationship with using

ReadRelationships

by passing a filter without

resource_id

and providing

resource_type

,

subject_type

and

subject_id

. If you still feel like using the synthethic permission is what you want to show (I could imagine some sort of debugging / staff UI to understand what permissions a user have been given)

LookupResources

would give you that. Now, wr.t.

at_extact_snapshot

, you are totally right. The right way to go would be to do an initial call with

minimize_latency

and then do all subsequent calls with the zedtoken returned back on that initial call. >I wonder how such situations don't rise more often, are ZedToken normally only used within the context of some larger operation and then discarded rather then saved somewhere in which cases some comparison is likely needed? The problem here is that ZedTokens are meant to be written alongside the content change, so if you are writing it to another system of record, in this case Redis, you'll find yourself in the race you are trying to solve. Are you storing your business objects also in Redis?

No worries, thanks for following up.

LookupResources

is indeed what I'm looking for, I guess in the future the API requirement to request a single permission might be dropped, but meanwhile your suggestion could work. Is the

looked_up_at

token in the

LookupResourcesResponse

guaranteed to be the same for all resources in the

LookupResources

response? Edit: also

LookupResources

for some permission might not find any matches in which case we wouldn't have a token, is the alternative making a dummy

CheckPermission

request? Regarding the storage of ZedToken, after some more reading I see what you mean, the below discussion also helped: https://github.com/authzed/spicedb/issues/1117 Storing the token at the "organization level"/"top level" is simillar to what I was looking for, and in that use case sounds like some kind of locking is the way to go.

>Is the looked_up_at token in the LookupResourcesResponse guaranteed to be the same for all resources in the LookupResources response? They would be _at_least_as_fresh_ as the returned token >Edit: also LookupResources for some permission might not find any matches in which case we wouldn't have a token, is the alternative making a dummy CheckPermission request? You can run a CheckPermission over a relation you may know exists always (e.g. a well known relationship set by your application). There is also the possibility to define a permission like

permission noop = nil

. You can also do

SchemaRead

which returns also

readAt

Of the mentioned options to get a current

ZedToken

, would you recommend a specific option? leaning towards

SchemaRead

but might check later if there's a big difference. Yeah lock contention could be an issue, good to hear you are thinking on that problem 🙂

>Of the mentioned options to get a current ZedToken, would you recommend a specific option? leaning towards SchemaRead but might check later if there's a big difference. a check permission on a permission that is

nil

would be probably very cheap, because all it would have to do is to compute the optimized revision and maybe some schema validation based on the input arguments