We do reserve the right to make them larger down the road to allow for better optimizations

what are special character not supported in the ID filed ? is it documented ?

it is documented in the API spec: https://buf.build/authzed/api/file/main:authzed/api/v1/core.proto#L64

I see that when you touch a relationship that already exists the

relation_tuple

table is still updated with a new row and the old row for the relationship is deleted. Is that expected?

Yes

It’s an internal implementation detail but it is expected

That may change over time

slightly off-topic (please stop me if this isn't a place for general conversation) - how would one think about integrating the authorization (zanzibar/spicedb) & discovery layers applications? eg. supporting full-text search across & pagination resources that you are authorized to use. our current system is a mix of ES (to support discovery) and inhouse authz (poc'ing spicedb right now)

today, you'd either pre-filter (e.g. you call LookupResources and then use that as a filter to ES) or post-filter (e.g. you do the ES search and then check each result). Usually post-filter is better if you expect to show only a small number of results from a very large result set

however, long term, the plan for supporting this use case is Tiger cache: https://github.com/authzed/spicedb/issues/207

that's really cool. i think the work on this has started, is there a roadmap/timeline I can refer to?

early prototyping has started and the necessary APIs behind it (LookupSubjects, ReachableResources) are done, but no firm timeline on it as of yet

got it

NOTE: In order to effectively use Roaring Bitmaps in the ways specified below, ALL resource IDs in the system must be 64-bit integers. We likely need to make it a requirement to use these new services, unless we can come up with an alternative way of storing and transmitting the data, in a compact and efficient form.

Would this mean that UUIDs would not be supported as resource IDs in order to utilize this? Unless I'm misunderstanding what 64-bit integers means (Resources being the objects that other things have permissions to act upon)

correct, you'd need to use basically half a UUID; its a restriction based on the fact that (AFAIK) there aren't any standard 128-bit roaring bitmap impls, (64-bit is only half standard as-is)

we've had some ideas on how to work around this, but ultimately, its a matter of using the bitmaps with whatever search index you've built, and those IDs need to match

i see. I'm reading through most of the documentation & comments on that issue - how would the tiger cache be able to support full-text searches on resources that a subject has access to? the API description in the issue post mentions

The Tiger Cache will expose one API, RoaringLookupResources, for returning the full set of accessible resources of the requested kind, for the requested permission, for a specific subject, in Roaring Bitmap form.

which (as far as i understand) is about listing the resources as opposed to performing some sort of searching on top of them?

you'd provide the roaring bitmap to your search index, say ElasticSearch

and have it used it as a filter

that would cut your working set of items to search down to those to which the user has access

or could have access

then you just check any results if need be

ahhhh got it

thank you so much!

Hi i'm testing SpiceDB on an ec2 instance and I'm having problems interacting with the server using the python SDK. Running locally Python 3.9. The issue seems to be with the grpc library. While using grpcurl with docker I have no issues. Starting the client as: client = Client( "my_instance_ip:50051", insecure_bearer_token_credentials("my_token"), ) Getting the following error for any type of requests: grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:     status = StatusCode.UNAVAILABLE     details = "failed to connect to all addresses; last error: UNKNOWN: ipv4:"my_instance_ip":50051: Endpoint is neither UDS or TCP loopback address."     debug_error_string = "UNKNOWN:failed to connect to all addresses; last error: UNKNOWN: ipv4:"my_instance_ip":50051: Endpoint is neither UDS or TCP loopback address. {grpc_status:14, created_time:"2022-10-31T13:30:28.815860789-03:00"}" > Any ideas or suggestions?

insecure cannot be used for anything but localhost; this is a gRPC restriction without special handling

Oh thanks for the clarification😅

I get this error when touching a relationship that already exists:

found duplicate update operation for relationship

. I thought it would just do nothing. Should there be errors when touching existing relationships?

no, but that error indicates you have multiple updates for the same relationship within the same update call

Hey Authzed Team, can you please point me to repository that has sample schemas? i am unable to find.