and don't worry too much about the number of relationships created

@Singha1 if you're using it to relate a user to themselves, this proposal might interest you: https://github.com/authzed/spicedb/issues/338

sounds very similar to your case

This is excellent !!

feel free to add your use case and a +1 to the issue

and if you have any preference, what keyword you'd prefer 😄

In my Organization there is discussion going on OPA vs Zanzibar, After looking at SpiceDB, I am very much convinced with SpiceDB. Only valuable argument I see in OPA is its reduced network latency due to running as side service. Checking permission against remote service might cause delay if there is network latency (not because of SpiceDB, I tested it and it is able to do permission check ~15-20 MS for most of cases for me) but checking against local may cause consistency issue. Can you refer me some document where detail comparison is being done?

we don't have a detailed comparison in a single place right now; we plan on writing one

one of the big items to note about any policy engine is that it will make the "acl aware index" problem much harder, because policy can filter based on pretty much any criteria

Hey joey, I know an issue has already been raised for getting all the permissions for a resource relation. I am actually in need of that API. If it's possible can you guys give an ETA.

Hi Jake & Joey, Thanks for helping me solve my previous use case. We have a new use case where we want to define the schema for custom objects. Custom objects are new entity types that an admin can define in their account & that will be available only in their account. We need to allow authorization on these custom objects. As a dummy example, consider a retailer company might define an Order entity, while a subscription based company might define Subscription & Deal entities. Even Order entities can have different attributes across different companies. For instance, a retail company might have only buyer info, while a marketplace company might have both buyer & seller info. Who can access these custom objects could be different for each entity & could be based on the attributes of the CO. Is this possible today? AFAIK , we need to statically define up-front the schema and it's relations with permissions.

Related to this point: is there a downside to running spicedb as a sidecar, like OPA does? It would certainly reduce latency

you would miss out on dispatch cache hits, and it could make the overall service slower depending on the latency between your datastore and your pods and the frequency of datastore access

Hi Rupa, user-defined resources is one nut that we haven't cracked yet. As you say, the permissions and relations can be different per-resource. It could be possible to use a single definition that defines CRUD operations, and then use namespacing on the object ID to get them all to fit the same underlying object definition, but I would have to know more about your specific object requirements.

i'm trying to get a CI flow together for schema validation and testing. I'd like to keep my schema separate from the validations and have a single source of truth (accounting for

zed schema write

and

zed validate

having different shapes), so I've written a script that sticks them together in a tempfile. This works, but when I went to add comments to my schema, the validations started failing. I can reproduce if I create a validations file that has a schema with comments. Something like this will trigger it:

schema: >-
  // This is a user
  definition user {}
relationships:
assertions:
  assertTrue:
  assertFalse:
validations:

which errors. is that expected behavior?

what error are you seeing?

its probably an issue with YAML escaping, if I had to make a wild guess

I think its treating the YAML string slightly incorrectly

yeah

this is the JS result

so its combining the lines :/

try changing to

schema: |

ahhh

YAML syntax seems like it should be an easy thing to learn but i keep getting caught out by it 😛 thank you for putting my nose in it

that also explains why i found i needed to put newlines between each of the statements in

relationships: >-

yeah, longer term, we have plans to make a better format for validate

it started as a format designed for the playground to output and sort of just evolved from there

makes sense