long term, this is the better solution: https://github.com/authzed/spicedb/issues/207

today, if you are going to have 50 million, its probably best to prefilter on the Mongo side and then check the results

so is the idea to create replica of what is in spicedb closer to the document storage? other strategy might be to determine the records based on the filter in both places, and then get the smallest set and cross it with the bigger one.

but again performance of this solution is concerning

when you deal with one record at a time, obviously everything is perfect, but when you need to query lots of records this is the hardest part

today, the recommendation is to prefilter on one side (whichever results in the smaller set) and the filter on the other

longer term, the tiger cache will be the proper solution

Ok Thank you so much for your help. I'll give it a try.

cool thanks a lot!

https://github.com/alsbury/chiphpotle-rest I created a SpiceDB PHP REST API library for PHP 8. It was generated by an OpenAPI code generated, then modified. It's can certainly be improved, but it works. Figured I'd put it out into the community.

@jzelinskie ^

oh nice to see you got it working!

ah, you built it on the http api

I’d like to get a gRPC version working at some point, but this will do for now. The gRPC tooling for PHP isn’t easy to debug.

agreed! in the mean time, i added your library to the awesome list: https://github.com/authzed/awesome-spicedb#third-party-libraries

hello, does authzed/spicedb support contextual tuples (https://openfga.dev/docs/concepts#what-are-contextual-tuples) like OpenFAG does? Contextual tuples open for interesting use cases, for example with a jwt token can be passed with client request to a service protected by authzed. This token may contain claims that could be turned into contextual tuples for the request. For example a group belonging claim. That would allow to not have to track all the users in authzed but just all the groups.

no, as we believe contextual relationships/tuples are often a non-ideal solution. For data that does not change all that often, such as group membership, the relationships should be written into SpiceDB to ensure that proper caching can be done. For dynamic information, such as whether the user has a particular scope, we are working on the caveats feature https://github.com/authzed/spicedb/issues/386. Contextual tuples have a number of major problems, including causing caches to no longer work, issues with consistency, questions around data overlap, etc

I have another use case. Let's consider a multitenant scenario where an authzed/spcieDB instance serves multiple client. And let's consider the case where a user can operate on behalf of multiple tenants. It would be nice to pass the information that the permission check evaluation should be performed withing the scope of a specific tenant (the one the user is logged in at the time of the request)

currently you'd do that by writing an object type that was a "tenanteduser" or some equivalent and issue a check for that subject

caveats will make that easier, however

however "tenanteduser" is more correct, because you are checking not for the user as a whole, but a specific version of the user

I see. I have to understand what caveats are. But in general anything that decreases the need to keep spiceDB in sync with every entity that has to do with permissions would help. Keeping in sync is one of the major obstacles to adopting this technology as there is no simple way to solve for the dual write problem. So for example in my current use case permissions are essentially dependent on the concept of location. Locations can be multilevel hierarchical structure, but the rules for permissions on things (aggregates or entities) that are at a given location are pretty much the same. What matter is the location. So the sync problem for my model would simplify extremely if I could check for permission passing two contextual tuples: the user membership to a group and the thing's location. Yes locations, groups, roles would still need to be synced, but everything could be dynamic.

caveats will allow for passing in location or other "dynamic" data, but allowing for arbitrary dynamic relationships breaks the core benefits of a Zanzibar-like system. The reason the synchronization is required is because it ensures both scalability (via aggressive caching and combined data retrieval), and consistency, via ensuring that there is always only a single version of the relationships set at any given point in time

if a relationship can be specified at Check time, however, then none of the caching can be used, because there is no guarantee that the addition of that relationship hasn't fundamentally altered the result of any Check operation

would request-scoped relationships remain impossible from your point of view even if someone was willing to give up consistency?

not impossible, per se, but it would compromise a number of benefits of the system

caveats, in our opinion, are a far better solution for dynamic conditions

ok, I'll try to study up on them

it looks like caveats were merged, when will it be possible to test them?

The first PRs were merged but the feature is not finished yet; we expect to have it ready for testing in the next few weeks