Show HN: EACL is a situated ReBAC authorization library for Datomic and Datahike

EACL is a situated ReBAC authorization library inspired by SpiceDB & Google Zanzibar, built in Clojure and backed by Datomic Pro, Datahike, Datalevin or DataScript. EACL is suitable for multi-Peer deployments. I have been working on EACL for ~2 years in my personal capacity and I use it in all my Clojure projects now.

- You can try the EACL performance demo: https://demo.eacl.dev/

- And play with EACL Drive, a toy clone of Google Drive: https://drive.eacl.dev/ (runs in-browser on DataScript)

EACL can efficiently answer questions like:

- "Does <subject> have <permission> on <resource>?" via `eacl/can?` or `eacl/check-permission`

- "Which <resources> does <subject> have <permission> for?" via `eacl/lookup-resources`

- "Which <subjects> have <permission> on <resource>?" via `eacl/lookup-subjects`

EACL supports four Consistency Modes that map to SpiceDB's consistency semantics, so you can run these queries against the database as-of now, or <N seconds ago> via `at-least-as-fresh` semantics for better cache reuse.

SpiceDB is the most faithful open-source implementation of Google Zanzibar, and is used OpenAI, Reddit and Netflix. Zanzibar powers Google Drive, YouTube, Gmail and Google Calendar, serving billions of authorization requests per day over billions of Relationships.

"Situated" here means that permission data co-exist with your application data. This has several advantages over external AuthZ:

- Reduced network latency (no network hop to external system),

- Strong local consistency,

- Scale reads by scaling Peers horizontally, and

- Real-time UI view maintenance – tail the tx-log and run `eacl/lookup-subjects` for changed permissioned entities and notify online users of novelty, instead of polling or re-querying for all online users.

Rationale:

I spent the better half of 2024 integrating with SpiceDB at a former employer. SpiceDB is great, but it becomes non-trivial to keep an external authorization system in-sync, especially when there is an impedance mismatch between your data and SpiceDB’s 3-tuple Relationship schema. Plus, you also have to deal with eventual consistency.

So, you change your data model to match the Spice schema to make syncing easier. Now you can tail the transactor log via `d/listener` and write Relationship changes 1-for-1.

But once you do that, you might as well run your permission queries in your application and then you have one less system to deal with...and this is exactly what EACL does. You still retain the option to migrate to SpiceDB later.

EACL is aimed at a different scale from SpiceDB: Spice is benchmarked against 100B Relationships. EACL aims for ~1-100M Relationships in a situated environment, but there is no reason it won't scale further if you scale out Peers.

EACL is open-source under EPL 2.0.