Hi

The audio is cracking in this video.

Hi

time stamped sections would be nice. this is quite a long video.

Awesome!!! Thank you so much

Great presentation, but I'm missing any mention of the downside of this solution. Namely that all services that contribute authorization data have to sync that data to SpiceDB, which is a pretty big distributed transaction problem.

Very comprehensive .. thanks a ton

Thank you for this video, it was very informative! Any release date for the next video?

Very useful 🎉🎉🎉

Hi, wouldn't it work if you did "parent->change_team_name + parent->change_name" ?

Great video thanks

I'd read the Zanzibar paper a couple years ago, and it sounded robust and useful. But like a lot of things Google publishes, it felt like I couldn't justify the complexity of writing and maintaining something like that? It's great to hear about SpiceDB / Authzed though; I'm gonna have to check them out.

Great presentation and introduction, hopefully I can give it a try to integrate into some stack.

Thanks for this - it is really valuable that you go through these types of problems to show off how this system can be used in real applications. I'll check out more of your resources, but I would like to see some information on how these relationships are maintained and could be synced up with existing systems.

These are super helpful, thanks! I'd love to see a followup where the Google Group permission slider functionality was implemented.

Ok we model then what, how does this get translated over to the database and application?

Thanks for the great video! It was really helpful to see the questions that come up as a model changes. Choosing permission granularity was particularly interesting to me because its something I've been challenged by in the past. You said that it would be easier to start with fine-grained permissions, but I don't think it would be difficult to split apart permissions on an as-needed basis. Take your example of allowing billing managers to be distinct from admins. That could be done by creating a new 'manage_billing' privilege. Then, this privilege would be granted to a new relation 'billing_manager'. At the point of introducing this change, all existing admins could be assigned the 'billing_manager' relation, and their effective permissions would be the same. New admins would need to be assigned 'billing_manager' manually, and existing admins could lose it. Is there some problem with that approach I am overlooking? If not, then it seems better to me to define only the permissions I need at the moment so that I am not maintaining extra permissions. Then if business needs require new privs in the future, I'll have more concrete examples/data to make a more informed decision. Thanks again!

Beautiful. Thank you for sharing.

I'm honestly surprised that this doesn't have more views to it. As a software engineer one of the most obfuscated problems that I've dealt with is modelling complex permission systems, and it never seemed like there were any resources to aid in that development, or any sort of systems available to have it done for you in a robust way, so I am extremely appreciative of the work you guys have done, and I hope to start a project soon where I can utilize this!

This is truly impressive. Well done folks.