Up until about a month ago, my understanding of how Zanzibar was supposed to work was wrong. Some quick notes:
- I completely misunderstood Section 2.3. of the whitepaper. The pseudo-code notation is, in fact, a namespace configuration language.
- Zanzibar tuples aren’t enough to infer relationships in a Zanzibar-style system.
- This clarifies some of my misconceptions related to the implementation of unions, exclusions, and inheritance.
- It was clear in my previous posts that all my implementations missed the ability to define such relations.
- Tuples are a query language.
- The namespace configuration defines said relations.
- A configuration consists of a set of relations.
- A relation can define a set operation over user sets.
- An operation is usually one of union, exclusion, or intersection. Other operation types can be defined as needed.
- User sets to apply the operation are defined via the child element.
- There are three child types:
_this(): implies any user in the direct relationship.computed_userset: any computed user referenced via another relationship.tuple_to_userset: a computed user set of a relation defined by another tupleset.
Based on those points, I have implemented a tuple parser and a namespace configuration parser with a lexer. The output of the parser could be used to implement the API.
Working on the lexer, I have realized that pursuing this project further does not make sense. There are many types of applications: embedded, desktop, server-side microservices, distributed permissions API, sharded systems, geo-sensitive systems, and more.
A cliché: for a permissions API, there’s no one size fits all.
- Almost every application is unique in detail.
- Almost every use case is unique.
- There’s always an implementation detail preventing one from using an upstream library, or a project, without the necessity for minor adjustments to make it fit.
Many applications require the decision engine right at the edge close to the code where the decision has to be made. Thus negating a centralized API. OPA with Rego is the thing to use. No need to reinvent the wheel. Period. Full stop.
I said this before:
The challenge isn’t the API or general-purpose query mechanism. The challenge is the distribution of the facts used to make the decision.
Hence delivering the functional Zanzibar namespace configuration parser and lexer is an excellent moment to hang the towel. The code is available on GitHub.