Re: Restarting work on the zCap (Authorization Capabilities) work item

The clubs website says, "Gordian Clubs are autonomous cryptographic objects
that provide read and write access to data" but services in general need
more than that.  That's the reason I didn't include the Tahoe LAFS in our
list of technologies to consider.  I know that the Plan 9 philosophy says
that you can treat everything as a file, but shoehorning enterprise
services into that model is challenging.

--------------
Alan Karp


On Thu, Apr 2, 2026 at 12:18 PM Christopher Allen <
ChristopherA@lifewithalacrity.com> wrote:

> At Blockchain Commons we’ve been working on a different approach to object
> capabilities, which we call cryptographic capabilities.
>
> Instead of authorization for access to a process on a server, it allows
> access to read and write privileges in an autonomous cryptographic object
> (ACO) and supports delegation and attenuation (but has limitations on
> revocation). These objects can reside anywhere and do not require
> infrastructure (i.e., you can read and write ACOs entirely on your offline
> machine using sneakernet).
>
> We’ve implemented this initial in Gordian Clubs, inspired by Mark S
> Miller’s Xanadu Club System:
>
> https://developer.blockchaincommons.com/clubs/
>
> More details at:
> https://developer.blockchaincommons.com/clubs/ocaps/
>
> Also an article on the goals:
> <https://www.blockchaincommons.com/musings/musings-swiss-eid/>
> <https://www.blockchaincommons.com/musings/musings-swiss-eid/>
> https://www.blockchaincommons.com/musings/musings-exodus-protocol/
>
> ABSTRACT: Digital infrastructure is built on sand due to its control by
> centralized entities, most of which are focused on profit over service. We
> need Exodus Protocol services that build infrastructure without
> centralization, ensuring its continuation into the far future. Bitcoin
> offers our prime example to date. Five design patterns suggest how to
> create similar services for coordination, collaboraiton, and identity.
>
> KEYQUOTE (relevant to this thread):
> > Not every digital service needs to be an Exodus Protocol. In fact, there
> are definitely services where you want centralization. You want more
> vulnerable people to be able to recover their funds in case of fraud. You
> want parents to be able to act as guardians for their children.
> >
> > But there are services that are irreplaceable and so would benefit from
> Exodus. These are digital services that store data, create identity, and
> manage assets that would be difficult to replace. And there are times when
> Exodus Protocols become more important than ever: when we’re under threat,
> under siege, or just struggling to survive.
> >
> > We still want to offer the ease of access and usability of centralized
> services in those situations where they’re appropriate, but we want to
> build those centralized services upon a strong, unwavering foundation of
> Exodus. If the centralized services fail, there must still be foundations
> that cannot fall.
>
> This relates to what Vitalik Buterin and the Ethereum Foundation have been
> calling "Sanctuary Technologies" in recent weeks.
>
> I hope that at some level anyone working on standards for more traditional
> zcaps will consider this form of object capabilities as well.
>
> -- Christopher Allen
>