you might have basic permissions (

view

resource,

edit

resource), but you could also have specialized ones like

can_comment

, which could/would be a combination of various roles

so it really comes down to whether the item is computed (

permission

) or representing a concrete relationship (

relation

)

for walking via, say, an arrow, what you use on the right hand side is really up to you: we generally recommend having the right hand side be a permission, since that way you can always change it later

ah got it... thanks. follow up question, using your example here, say i have a

definition sub_resource {
  relation resource: resource
  relation writer: user
  permission edit = writer + resource->writer  // or writer + resource->edit
}

you could say either resource writers can edit sub resources, or those with permission to edit resource can also edit sub resources.... both are correct, right? is there a practical effect on the back end of using one or the other (i.e. an extra traversal walking back a computed permission vs. a relation)? or is that so small that it's negligible?

(sorry... started typing my question before i saw your very last answer)

no worries 🙂

yes, there is a tiny practical difference, in that there is an extra walk internally

but that's our job to optimize and, in practice, should all be done without any data lookup

got it. thanks!

in general, we recommend that all "accessed" "exported" items (whether via a

check

call, or on the right hand side of an arrow) be a permission

i.e. if it is checked from your app code, or is used by an arrow from a different definition, making it a permission means you have the flexibility to change it later without having to fix all the call sites

for arrows, that's minor, since you can just update everything in the schema

for external API calls, its nicer to have them all be permissions, unless you're explicitly checking if a subject is part of that relation

Hi, a couple of quick questions on importing relationships... It looks like

zed import

expects a YAML file... can you point me to the documentation describing that file? Also, are

zed import

operations idempotent?

you can see an example of the format if you go the play.authzed.com and click "download" - it's basically the contents of each of the four tabs in the playground under four keys in yaml (here's an example: https://gist.github.com/ecordell/fe3c81f753a5c425610a8b39accfb97c) and yes the import operation for one of these files is idempotent: it overwrites the schema (replacing what was there) and it writes the relationships with a "touch" operation

thanks!

Hi, one more question regarding importing; is there some way to tell the

zed import

command to use the prefix designated for the permissions-system at time of creation? The intention behind the question is to use a common schema file that all the devs can import into private development permission-system instances. But whenever I try to do an import, zed says that it finds resources without prefixes. If I recall correctly, I was able to author a schema in the playground and import it into the permissions system via the "import" button, and the prefix was just somehow automatically added.

currently the rewriting is done by the playground, yes

mind filing an issue in https://github.com/authzed/zed/issues to do the rewrite as well?

we've meant to do it

ok; filed as https://github.com/authzed/zed/issues/81

let me know if there's any more details needed

also, great username

danke

gerne geschehen!

Hi! I have a question about this blog post: https://authzed.com/blog/check-it-out/ How do you represent an exclusion in graph form? E.g. if you define

reader

as

reader

and NOT

blocked

?

https://authzed.com/blog/build-you-a-google-groups/ check out the banned users section in this post

Right, so I get that it would be represented as another tuple, but then in https://authzed.com/blog/acl-filtering-in-authzed/ it says "intersection and exclusion, however, cannot be computed without all child paths themselves having been computed, meaning that we’d have to perform the equivalent of a “reduce” operation at any intersection or union. Fortunately, this led to a natural solution: map, then reduce." and I didn't understand how this works

Another way to think about it is that the relationships form the directed graph, and the schemas provide a way to interpret that graph to make permissions decisions