Is there an analogue to a _zookie_?

[dblclik]

Hey everyone 👋 Apologies if I missed this in the docs or an RFC, but in Section 2.2 of the Zanzibar paper, the authors describe the Zookie token, which encodes universal time during a permissions update and can be provided during a check operation so that any checks use data at least as fresh as the time given by the zookie. I know that SpiceDB uses a zed token to similar effect, and some of the articles where dev teams have made their own version of Zanzibar copied this feature, but I can't find anything like it in the docs or API specs -- am I missing something?

[aaguiarz]

Hi @dblclik

No, OpenFGA does not support zookies.

The current OpenFGA implementation does not have a cache, so it is strongly consistent.

We'll be adding a cache in the future, and initially we'll support strongly consistent reads + eventually consistent reads, but not "bounded staleness" which is what zookies support.

Do you have a use case were you'd want to use them?

[dblclik]

Hey @aaguiarz, thank you for the quick reply! That's what I had assumed as well, but wanted to verify since some in the market offer it but not all. Presently I don't have the case for it, for what it's worth, but doing a landscape survey for an upcoming project and this was one of the few I couldn't answer off the top of my head 😅

Personally I feel like it simplifies things to not have them, and since my upcoming use cases aren't globally distributed I don't suspect they will be required.

From a contributor/curious standpoint, I'll be curious to see if/how any issues arise in the cases of eventually consistent reads w/o bounded staleness (hopefully anyone using EC reads doesn't put them into the wrong situation, but we can only do so much for the end user 🙃)

Thanks!

[rhamzeh]

This article on the Auth0 FGA side re: eventual consistency might be also worth reading.

https://docs.fga.dev/writing-data/advanced/eventual-consistency

[rhamzeh]

Not having Zookies was one of the decisions we made early on for OpenFGA.

TLDR:

• Zookies add a lot of implementation complexity on the developers
• Zookies add a lot of complexity on the software side
• When we talked with people in the industry who have built Zanzibar-like systems, Zookies were either unsupported or ended up being unused after being built
• When we talked to customers, the problems Zookies safe guard against was not one that they had

Note that our decision is not final. We (and the industry) are still learning and building. In case we saw a need in the future, we would revisit our decision.

As @aaguiarz mentioned, when we add a cache for OpenFGA we might add an option to bypass the cache if you need to and go directly to the database (note: that is still not strongly consistent unless you use a single database, and even then not guaranteed).

You can also read this article in which Abishek Parmar, one of the co-creators of Zanzibar, talks about why they left Zookies out when they built a Zanzibar implementation at AirBnB called Himeji.

The article is worth reading, but the most relevant section for Zookies is:

What from Zanzibar did you leave out in Himeji?

The biggest thing that we left out was this clever but hard-to-use feature that ensured that you could get extremely consistent results. The "Zookies" feature, which defends against the “new enemy problem.” Google Plus's leadership cared a lot about consistency at that time. Whereas in practice, you know, it doesn't seem to matter much. Also, we didn't have the Spanner database to help build that feature. We could have used other databases, but we just decided to leave it out because it wasn't very useful.

This insistence on consistency was a requirement imposed from the product side. We worried about a disaster or failure if we ever made a single authorization mistake. This made sense at the time, but in hindsight, we could give the wrong authorization answer for a second and it would be ok. Certainly, for most products using Zanzibar, it didn't matter. At the time, the consistency that Zookies gave us was important because we were building a social media platform. But, that's not the one feature that will make or break a social media platform. For instance, Facebook has plenty of inconsistencies when you interact with the product.

Other things we left out because they were artifacts of having to scale the system.

[dblclik]

Hey @rhamzeh, thanks for quick reply and great to hear from you! I've read the Himeji post before, but am rereading it now since you mentioned it and it's always a good read 📖

I mentioned it above in my reply to @aaguiarz, but I'm more than happy using a system without the temporal token for as long as any services I work on don't have the distributed and/or EC caching needs that Zanzibar had (which, is rare lol).

In my latest iteration of standing up centralized authorization I've been thinking more about using something like a temporal token so that for cached checks the requestor can indicate if they are or are not comfortable with a check based on its recency, but not for maintaining a cache of the relationship graph itself. Even then I'm on the fence 🙂