The fundamental@problem is just that you have to keep making more and more requests to re-expand things that are intermediate

Do you have any intersections or exclusions in your resolution path? There is a known issue with lookup right now where it falls back to just checking every resource in a loop when there are such negations.

It should be possible to write a resolver that reads SRV records to replace the kuberesolver. We used to have a service that did this, but SRV records coming from kube coredns are updated with a wonky lifecycle and it caused us to drop requests. Maybe ECS is better.

Sorry I don't get it, once this operation tree is computed, couldn't it be resolved within SpiceDB? As in, apply the operation on each node of the tree

Oh sorry I misread! I thought you asked what the problem with doing it on the client is

The biggest implementation barrier is figuring out how to stream the result set to the caller

Actually, I'm trying to implement it client-side but I'm hitting a wall: I can't do much with an

EXCLUDE(['*'], ['id1', 'id2'])

. I know which subjects do not have the permission (

id1

and

id2

), but not which ones do have the permission!

You could couple the wildcard with a read

Do you mean fetching all users from SpiceDB, to replace the wildcard with the actual IDs? I'm not aware of an endpoint to get all objects of a type

No you’re right there isn’t one. You would need at least the object type of the left hand side to enumerate them

Even the lookup subjects api won’t be able to do this

Because wildcard will match subjects we don’t even know about

> Because wildcard will match subjects we don’t even know about Good point

This is going to require some thought

Maybe lookup subjects will have to return an expression sometimes

You could always fix this for your use case by making sure there is some common relationship that all users have

Like

platform:yourco#user@user:william

> You could always fix this for your use case by making sure there is some common relationship that all users have Yeah. Would probably mean more hops in the graph when doing checks though: I assume that intersecting/excluding against

user:*

is cheaper than

platform->user

you wouldn't have to use it in permissions calculations

but it would give you a filter that you could use to go get "all users" from authzed

Ah, I see

honestly though since it's not paginated there is a certain scale at which that would time out unless you could find other ways to filter

if you use the Expected Relations tab in the Playground, you'll see this creates an expression of the form

* - {id1, id2}

for this exact reason

LookupSubjects will likely return something similar

Question that I haven't found in the docs yet. If a single RelationshipUpdate fails in a batch of Updates for a WriteRelationships call, does that fail the whole WriteRelationships request or just the single invalid RelationshipUpdate?

The whole thing is atomic

thanks, back to the drawing board on the LDAP importer then. the email staff isn't consistent with 'name', 'first.last', 'initial.last'.

I don’t understand

I'm trying to speed up the loading of all the groups->users mapping. some of the sAMAccountName have the periods in it which are getting rejected because of the periods. We're just going to have to make a separate uuid to real lookup pgsql or spanner table for humans I think for the admin ui side of things. I've got the group names being stored with uuidv5 values, but we can convert them on the fly in the admin tool.

You can base64 encode them