[jschorr]

It is actually slightly worse than even that: while New Enemy [1] is the primary concern, caching like this can also introduce a staleness issue from the other direction: let's say a user adds a new row or document, and immediately sends the link to their coworker... who tries to load that piece of data, but the (stale) access control dataset is cached and they are not in it... they get a "no access" error. While certainly fail safe (vs fail dangerous for New Enemy), it can be a fairly important UX concern as well.

Generally, the solution is to keep a timestamp of when the data changed (Zookies as you mentioned) or you can proactively reload or recompute the cache when the underlying data changes (sometimes in very smart ways), but yeah: it adds significant complications over a "simplified" approach to Zanzibar.

Disclaimer: I'm the cofounder and CTO of AuthZed and we develop the SpiceDB [2] and Materialize [3], which have quite a bit of logic around these exact problems

[1]: https://authzed.com/blog/new-enemies#the-new-enemy-problem [2]: https://spicedb.io [3]: https://authzed.com/docs/authzed/concepts/authzed-materializ...

[fud101]

Hi, i'd like to implement my own version for learning purposes. Do you have any recommendations?

[jschorr]

I'd start with reading the Zanzibar Paper. We built an annotated version [1] that provides additional guidance on some of the denser sections and how we interpreted them.

Then, I'd take a look at the history of SpiceDB [2] for how we developed the system over time.

Finally, if you have any questions, feel free to jump into our Discord [3] and ask: we're happy to answer!

[1]: https://zanzibar.tech/ [2]: https://spicedb.io [3]: https://discord.gg/spicedb