(This may be an XY problem where there's an underlying skill issue in writing a maintainable fine-grained + hierarchical schema) When adding a new capability to a hierarchical schema, it seems like one would have to define relations and permissions on each parent in the hierarchy. So can_create_project would be added to grant, project, team, organization, ... and each is checking parent->can_create_project The cloud modelling blog post shows an example of how granting multiple layers of parents some granular permission requires updates in multiple places https://authzed.com/blog/google-cloud-iam-modeling So at this point I imagined a JSON format that is managed programatically, where the output is transformed to

.zed

for human validation, education, and so on. I'm curious how the team currently recommends building and maintaining these larger schemas, how often it leads to programatically producing

.zed

files, and if those folks would like to write JSON but read

.zed

instead.

i know @verdverm.com has been writing schemas with the help of

cue

. in my own work at my last company where we were using a google cloud iam-ish schema we just let the schema be verbose. my personal take is that the verbosity isn't a bad thing, because keeping things simple/less indirect means it's easier to grok and verify a schema. there is a [composable schema syntax](https://authzed.com/docs/spicedb/modeling/composable-schemas) that may help with organizing a schema, though it doesn't necessarily help with propagating a permission up through a hierarchy.

My CUE based schema gen is here: https://github.com/blebbit/atproto/tree/main/packages/pds/src/authz/spicedb/schema

Since CUE produces JSON, would it have been interesting to author CUE (comments there) and produce the schema as .json instead of .zed?

What would the JSON version offer me? I'm producing the .zed directly, which is surely more readable than the JSON version, and I find it unlikely either is as readable as the CUE version (imho)

Basically the removal of string formatting. Admittedly it's not that hard so no paradigm shift Then having a json<>zed transformer would let you still read the zed file if you wanted

I'm at the CUE level of abstraction, so if

zed

accepted both JSON and .zed files, I probably wouldn't really care which format. I'm fine with the text/template or string formatting because the sources of truth is used for more than generating the schema. Also, if you have the JSON->Zed transformer, it will be the same thing, so why even put the JSON in the middle?

If a schema scales to the point where you write your own compiler, you could build it on a strongly typed foundation (a JSON schema, library, ...) If you built a logical abstraction over definitions, relations, etc... you could minimize its drift from the actual concepts, the same way you likely will build a higher level API on the existing protobuf based libraries, like

v1.WriteRelationshipsRequest

If json was an accepted format, rather than putting it in between, you wouldn't generate .zed at all - or it would be an optional side effect for human readability or auditing. There are products out there that have solved the json serialization of the algebra, paraphrasing a simple example in the screenshot: https://cdn.discordapp.com/attachments/1421147009967984660/1421227741163814983/image.png?ex=68d844fa&is=68d6f37a&hm=9708dc5d9585b463f810242761da4e1c5aa3873ed7c8ac28dc86f3473e16c4fc&

How would I represent

admin + (user - banned)

in JSON? How would it be clearer than what I just wrote?

and we do have a serialization of a schema in the sense that we have protobuf that describes schema; that's how it's stored in the DB we do want to expose some sort of IR at some point in the future, because there are at least three projects that i know of that are doing their own parsing of a SpiceDB schema to produce well-typed references to permissions + relations + definitions in client code, and it would be nice if they could consume an IR rather than needing to do their own parsing. this will likely come with a schema/v2 package, which is in the works but i don't know that i would describe it as close

very cool, getting access to IR is always nice. I regularly side step this with

CUE -> { DSL, clients }

, but then I also wrote a framework for

CUE -> anything

generally, so I may be biased 😄 https://hofstadter.io