glad to help though

I appreciate your blog content, it's been very informative so far. Glad you've avoided the SEO spam trap

Thanks! We appreciate the positive feedback. We're trying to keep a regular cadence as well, which can be tricky

I'm curious about your system design, are you getting customer pressure to offer a self-hosted version? It seems like a potentially tricky sell to have a hard dependency on an external service in the critical path of (most?) API requests. I say that as a proponent of laser focus on running/writing only the software that directly makes a company money and outsourcing the rest.

We don't promote it much just yet, but we are willing to work with customers that want self hosted. We've worked on enterprise software in the past and know complexity overhead for when you want to make large or delicate changes, so we're not waving a big flag for it just yet. We'll have some positive news for those users in the coming weeks though.

hi everyone, i am not super familar with ReBAC, but i imagine ReBAC will give you very granular access control. for RBAC, i can create a role to group a bunch of permissions and assign that role to the team/user, whenever is needed. can i do the same in authzed? what's the recommended way to assign a set of accesses to multiple users?

@User yes, you can do so by defining a role in the Authzed Schema: https://docs.authzed.com/reference/schema-lang. For example, if you wanted to have two roles (

reader

and

writer

) on a resource such as a

document

, you'd do:

definition user {}

definition resource {
  relation reader: user
  relation writer: user

  permission view = reader + writer
}

here, the permission to

view

a document is defined as any users that are either

reader

or

writer

(or both), which form the roles you want

wow, thanks for the knowledge! it's great for me to know we can create a permission to group access with authzed. but can we create a role to group permissions? i am curious about your thoughts on this: imagine this: there are often requests from eng teams to create a role that groups a bunch of permissions together: e.g. a

blah

role with write access to a s3 bucket, access to view a webpage, ability to login prod servers etc. but that would definitely put too much burden on iam engineers who review those requests: 1. each team may want to create a role for each of their use cases (oncall role, normal role, prod role etc.) 2. iam engineers don't have the context of everything, imagine thousands of resources and each of them is domain specific. how do you envision the process for users to create roles while following the least privilege principle, in a scalable way?

@User you're asking for "user defined roles": we're currently working on improvements to the permissions engine to support them

once supported, you'll be able to write a schema to define a dynamic role that has zero or more permissions

Technically, you can model this today, but it's complex to reason about and changes depending on your requirements. What Joey is referring to is us adding some functionality to improve the UX to the point where it's intuitive to build systems where your users can define their own roles on the fly.

It's complex because you have to create your own concept of roles and manage it all yourself -- you're fundamentally building another permission system within Authzed and using Authzed to delegate access to those that will then manage your permission system.

We have a brief description of User Defined Roles in our docs, along with some other good reading for RBAC patterns: https://docs.authzed.com/concepts/authz#user-defined-groups

hey 👋 I'm curious about how creation of new objects and zookies work. If I had to update a document in Google Drive type system, I would do what you mention on the docs:

def write_content(user, content_id, new_content):
    is_allowed, zookie = content_change_check(content_id, user)
    if is_allowed:
        storage.write_content(contentd_id, new_content, zookie)
        return success
    return forbidden

But how would I retrieve the zookie for a new document if I don't yet have the

content_id

? And how would I know if the user has access to write the content? Would I check if the user has access to the folder/account?

Hey there! You'd likely be wanting to check a permission for creating a document, rather than writing a document, in that case. You always want to try and use the most granular check possible, so that if you make changes to the schema, you don't have to change any checks in your code.

Yep, you're right that creating a document is likely to be a permission on the folder/account/owner of the document

Remember you can always define the writing a document permission as all of the users that have creating a document + anything else

Thanks @User! That makes sense, so the zookie in this case would come from the check on whether a user has writing permission on the folder.

Exactly! You can always update the zookie whenever a new write happens to the document itself, but first value should come from the act of creating it.

The best way to think of Zookies is as a way to say that you want to read "at least as fresh as the event that created this zookie"

Does anyone have a better understanding of why the leopard indexing system uses skip lists to store the index sets for fast set intersections? I get that it does a group2group set lookup and a user2group set lookup, and the intersection of those sets determine whether there is a path, but don’t fully understand why they use a skil list as opposed using a hashtable with hashsets as the values for fast intersections

@User purely speculating here, but I would surmise that its because skip lists are fairly memory efficient for storing LARGE numbers of entries with large gaps

Google, after all, has a lot of users, so I could easily see even a hashset with billions+ of entries being very hard on memory

and if you assume the list of tuples is sparse, and you keep them ordered, you can eliminate large groups of tuples (for example in intersection) without ever hashing them by knowing that they were in between two far entries in a skip list

@everyone we are very happy to announce today the open sourcing of SpiceDB, the core Zanzibar permissions on Authzed! Please star and share the repository https://github.com/authzed/spicedb and any support on HN would be appreciated as well!

Nice! Looks amazing. Congrats!

Amazing news!

Awesome work! Very interesting prospect!

this looks like a great project, thanks for that! is there any particular reason to use Go?

our team has roots in the distributed infra space (CoreOS, Kubernetes, Kubernetes Operators) most of which are written in go