Invitation: Gordian Clubs - Autonomous Cryptographic Objects inspired by Project Xanadu

[Christopher Allen]

I became involved with Project Xanadu in the early 90s, during its ending days. Although its hypertext system was before its time, one feature that particularly struck me was the Xanadu Club system, which allowed for read and write permissions to be passed among both users and clubs (groups) in a fascinating recursive manner that was quite different from anything else I'd ever seen before (or since!).

The problem? The architecture was centralized. At the time, I suggested to one of Xanadu's architects, Mark S. Miller, that we use cryptography as an alternative, but the cryptography field wasn't mature enough. What we had was slow, and almost everything was encumbered by patents.

Jump forward 30 years. Schnorr is now available in the public domain, and powerful new cryptographic protocols like FROST have been built on top of it. It's exactly what I needed to make my vision of cryptographic clubs a reality.

And I've done so, in a first proof of concept.

I'll be talking about Gordian Clubs and demoing that proof of concept at a meeting next Wednesday, October 1st.

WHAT? Gordian Clubs Introduction
WHEN? 10-11.30am PT, Wednesday October 1st
WHERE? Zoom ( https://us02web.zoom.us/j/88143195571?pwd=BVv4zCnnaNor97Vj8ayajh26yyICBr.1 )

Today’s access control systems rely on servers, databases, and constant network connectivity. That creates fragility: they fail during outages, struggle in censorship-heavy environments, and assume trust in infrastructure that isn’t always reliable.

Gordian Clubs are a new approach. They are self-contained cryptographic objects that let groups transmit and update information without central servers or live networks.

Permissions are enforced through cryptographic object capabilities, not code running on a trusted server. Unlike traditional ocap models that rely on software enforcement, Gordian Clubs embed rights directly using cryptographic primitives.

Gordian Clubs can be shared by email, stored on USB drives, or even printed as QR codes. They work offline, across air-gapped connections, and in adversarial conditions — even during internet blackouts.

The result is a tool for digital autonomy. Gordian Clubs empower resilience and dignity where it matters most: for journalists, dissidents, long-term archives, disaster response, and any situation where access must remain possible, regardless of censorship or connectivity.

I’d love to bring experts from the Xanadu world, as well as those currently working on object capabilities and credentials, into this conversation. Together we can explore goals and possibilities in a collaborative meeting of minds. I hope you’ll join us!

-- Christopher Allen & The Blockchain Commons Team

(I wrote about this previously on the ocap-talk mailing last back in 2018 https://groups.google.com/g/cap-talk/c/SCRpXZWe-Eo/m/9dYQhWbxEAAJ which also offers some interesting commentary in the thread)

[Chris Hibbert]

On 9/24/25 6:29 PM, Christopher Allen wrote:
>
> I'll be talking about Gordian Clubs and demoing that proof of concept at
> a meeting next Wednesday, October 1st.
>
> WHAT? Gordian Clubs Introduction
> WHEN? 10-11.30am PT, Wednesday October 1st
> WHERE? Zoom (

> https://us02web.zoom.us/j/88143195571?pwd=BVv4zCnnaNor97Vj8ayajh26yyICBr.1 <https://us02web.zoom.us/j/88143195571?pwd=BVv4zCnnaNor97Vj8ayajh26yyICBr.1> )

Hi Chris,

I expect to be busy Wednesday morning. Is there any chance the
presentation will be recorded so I can watch it later?

Chris
--
Computers are telescopes we use to see the infosphere.
Some care about telescopes, most want to see the stars.
Paraphrased from Gelernter

Chris Hibbert
hib...@mydruthers.com
Blog: http://www.pancrit.org
http://mydruthers.com

[Jonathan S. Shapiro]

Welcome, Christopher!

On Wed, Sep 24, 2025 at 6:29 PM Christopher Allen <Christ...@lifewithalacrity.com> wrote:

I became involved with Project Xanadu in the early 90s, during its ending days. Although its hypertext system was before its time, one feature that particularly struck me was the Xanadu Club system, which allowed for read and write permissions to be passed among both users and clubs (groups) in a fascinating recursive manner that was quite different from anything else I'd ever seen before (or since!).

While the overlap isn't perfect, much of what was done by the Club system can now be done with RBAC systems that include role inheritance. The Club system mostly predates the current preference for Capability-driven intuitions. That said, there are a number of things Clubs support that don't have a graceful implementation with capabilities.

 

The problem? The architecture was centralized.

The Xanadu implementation at the time was centralized. The underlying architecture was not. In retrospect, I suspect that some of MarkM's later work on eventual consistency may have had its origins in efforts to make certain parts of the Xanadu architecture asynchronously distributed. Perhaps he will comment.

Cryptography is a fine way to implement, but it doesn't (in and of itself) address the need for eventual convergence of independently made updates to the access rules.

Sounds like maybe you've got something interesting to add to the discussion!

Jonathan

[Mark S. Miller]

On Wed, Sep 24, 2025 at 10:02 PM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

Welcome, Christopher!

On Wed, Sep 24, 2025 at 6:29 PM Christopher Allen <Christ...@lifewithalacrity.com> wrote:

I became involved with Project Xanadu in the early 90s, during its ending days. Although its hypertext system was before its time, one feature that particularly struck me was the Xanadu Club system, which allowed for read and write permissions to be passed among both users and clubs (groups) in a fascinating recursive manner that was quite different from anything else I'd ever seen before (or since!).

While the overlap isn't perfect, much of what was done by the Club system can now be done with RBAC systems that include role inheritance. The Club system mostly predates the current preference for Capability-driven intuitions. That said, there are a number of things Clubs support that don't have a graceful implementation with capabilities.

 

The problem? The architecture was centralized.

The Xanadu implementation at the time was centralized. The underlying architecture was not. In retrospect, I suspect that some of MarkM's later work on eventual consistency may have had its origins in efforts to make certain parts of the Xanadu architecture asynchronously distributed.

<self indulgent. skip if you don't care>

Indeed. I started working on Xanadu in 1976 or so, just before the RSA papers. Absorbing Ted's ambitions for Xanadu -- which do resemble the cypherpunk perspective 10 years later -- I tried to solve the needed distributed systems problems myself. I could not. This led to four things:

• fascination with Actors, for reasons that are now obvious ;)
• leaving Xanadu to take a job at Datapoint, the inventor of the first good local area network (Arcnet) and a decentralized OS that ran across large numbers of Datapoint's tiny desktop computers -- 64K memory altogether. I went there for several reasons, but mainly because it seemed to me the best place to learn about distributed systems. That OS was fascinating and unlike anything I've seen since.
• went from Datapoint to Xerox PARC, which just so happened to become the new best place to learn about distributed systems. This was more accident than intentional. I wanted to go there mostly because of Smalltalk.
• joining the early cypherpunk movement.
• by the time I left PARC to return to Xanadu, taking Dean with me, I felt I was ready.

But the work that you all know me for, ocaps with decentralized secure communicating event loops, does not itself involve eventual consistency. 

• Xanadu did have strong elements of eventual-consistency, though I do not recall ever explaining things in those terms.
• Dean and I did important eventual-consistency work at the "Agoric" company of the 1990s under the term "available objects" and written in Joule. But little of that saw the light of day. 
• The one part that made it into E was the Lamport Cell (only inspired by Lamport), that was really cool, but was not redone in E's successors. All that eventual-consistency logic is mostly subsumed many years later by CRDTs. 

The actual history is of course much messier than my tidy story above.

</self indulgent. skip if you don't care>

 

Perhaps he will comment.

Christopher's breakthrough here is that it is not just decentralized, it is infrastructure-less. This is an extreme level of protection that I never imagined would be possible for something like this. 

 

Cryptography is a fine way to implement, but it doesn't (in and of itself) address the need for eventual convergence of independently made updates to the access rules.

Christopher will be explicit about what kind of consistency can be achieved under his constraints. It is not eventual consistency, but IMO it is still quite valuable. I am excited!

 

Sounds like maybe you've got something interesting to add to the discussion!

Jonathan

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/friam/CAAP%3D3QPEEJSAug%3D1ryLqS_sgyyBi5nc9JEhD%3DkVvPP2%2BQeJrDA%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Mark S. Miller]

On Wed, Sep 24, 2025 at 10:39 PM Mark S. Miller <eri...@gmail.com> wrote:

On Wed, Sep 24, 2025 at 10:02 PM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

Welcome, Christopher!

On Wed, Sep 24, 2025 at 6:29 PM Christopher Allen <Christ...@lifewithalacrity.com> wrote:

I became involved with Project Xanadu in the early 90s, during its ending days. Although its hypertext system was before its time, one feature that particularly struck me was the Xanadu Club system, which allowed for read and write permissions to be passed among both users and clubs (groups) in a fascinating recursive manner that was quite different from anything else I'd ever seen before (or since!).

While the overlap isn't perfect, much of what was done by the Club system can now be done with RBAC systems that include role inheritance. The Club system mostly predates the current preference for Capability-driven intuitions. That said, there are a number of things Clubs support that don't have a graceful implementation with capabilities.

 

The problem? The architecture was centralized.

The Xanadu implementation at the time was centralized. The underlying architecture was not. In retrospect, I suspect that some of MarkM's later work on eventual consistency may have had its origins in efforts to make certain parts of the Xanadu architecture asynchronously distributed.

<self indulgent. skip if you don't care>

Indeed. I started working on Xanadu in 1976 or so, just before the RSA papers. Absorbing Ted's ambitions for Xanadu -- which do resemble the cypherpunk perspective 10 years later -- I tried to solve the needed distributed systems problems myself. I could not. This led to four things:

• fascination with Actors, for reasons that are now obvious ;)
• leaving Xanadu to take a job at Datapoint, the inventor of the first good local area network (Arcnet) and a decentralized OS that ran across large numbers of Datapoint's tiny desktop computers -- 64K memory altogether. I went there for several reasons, but mainly because it seemed to me the best place to learn about distributed systems. That OS was fascinating and unlike anything I've seen since.
• went from Datapoint to Xerox PARC, which just so happened to become the new best place to learn about distributed systems. This was more accident than intentional. I wanted to go there mostly because of Smalltalk.
• joining the early cypherpunk movement.
• by the time I left PARC to return to Xanadu, taking Dean with me, I felt I was ready.

But the work that you all know me for, ocaps with decentralized secure communicating event loops, does not itself involve eventual consistency. 

• Xanadu did have strong elements of eventual-consistency, though I do not recall ever explaining things in those terms.
• Dean and I did important eventual-consistency work at the "Agoric" company of the 1990s under the term "available objects" and written in Joule. But little of that saw the light of day. 

Sorry. The "Agorics" company of the 1990s, as opposed to the "Agoric" company of today. I forgot my mnemonic: We used the plural when there was only one, but the singular when there was more.

 

• The one part that made it into E was the Lamport Cell (only inspired by Lamport), that was really cool, but was not redone in E's successors. All that eventual-consistency logic is mostly subsumed many years later by CRDTs. 

The actual history is of course much messier than my tidy story above.

</self indulgent. skip if you don't care>

 

Perhaps he will comment.

Christopher's breakthrough here is that it is not just decentralized, it is infrastructure-less. This is an extreme level of protection that I never imagined would be possible for something like this. 

 

Cryptography is a fine way to implement, but it doesn't (in and of itself) address the need for eventual convergence of independently made updates to the access rules.

Christopher will be explicit about what kind of consistency can be achieved under his constraints. It is not eventual consistency, but IMO it is still quite valuable. I am excited!

 

Sounds like maybe you've got something interesting to add to the discussion!

Jonathan

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/friam/CAAP%3D3QPEEJSAug%3D1ryLqS_sgyyBi5nc9JEhD%3DkVvPP2%2BQeJrDA%40mail.gmail.com.

--

  Cheers,
  --MarkM

--

  Cheers,
  --MarkM

[Ken Kahn]

Apropos Xanadu I wonder what people think of this:

https://www.astralcodexten.com/p/your-review-project-xanadu-the-internet

Best,

-ken

To view this discussion visit https://groups.google.com/d/msgid/friam/CAK5yZYgAyxkOACW%3D3LLPwnR%2BFLNcBrzfBJfwWKwrymJOCpPG1g%40mail.gmail.com.

[Mark S. Miller]

I love some parts and hate others. I don't have the energy to correct. It just makes me tired.

To view this discussion visit https://groups.google.com/d/msgid/friam/CAFybx9%3DXbK%3DO-LgnxtmPgdJMCn-1gfP3LkGx%3DK2Ooy7-%2BxQEUQ%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Christopher Allen]

On Wed, Sep 24, 2025 at 8:43 PM Chris Hibbert <hib...@mydruthers.com> wrote:

I expect to be busy Wednesday morning. Is there any chance the
presentation will be recorded so I can watch it later?

Yes! All of our meetings are recorded and annotated at:

https://developer.blockchaincommons.com/meetings/

-- Christopher Allen

[Christopher Allen]

On Wed, Sep 24, 2025 at 10:39 PM Mark S. Miller <eri...@gmail.com> wrote:

Christopher's breakthrough here is that it is not just decentralized, it is infrastructure-less. This is an extreme level of protection that I never imagined would be possible for something like this. 

Yes, autonomy is a fundamental design choice in Gordian Clubs: they are cryptographic objects that operate without any external infrastructure. This isn't just a technical decision, it's a philosophical stance that shapes everything about how they work.

This autonomy comes with trade-offs. You can't have time-based expiration without a trusted time source. You can't check external conditions without oracles. You can't track usage without infrastructure. But what you gain is something more profound: mathematical certainty that doesn't depend on any third party's continued existence, honesty, or availability.

For instance, you can't rotate your publically-available public keys in XIDs (our version of Decentralized Identifiers) in a new edition without updating their origins (though this doesn't necessarily require point-to-point internet - you could use Blockstream Satellite https://blockstream.com/satellite/ to distribute an update at the cost of a few Lightning Network sats, or leverage a very efficient sneaker-net).

Cryptography is a fine way to implement, but it doesn't (in and of itself) address the need for eventual convergence of independently made updates to the access rules.

Christopher will be explicit about what kind of consistency can be achieved under his constraints. It is not eventual consistency, but IMO it is still quite valuable. I am excited!

In this initial proof-of-concept, consistency is not guaranteed, especially without net access.

However, irreconcilable forks can be limited if you require majority quorums for write approvals. For instance, if you have a 3 of 100 quorum write club you are LIKELY to fork. This can be a feature ;-)

That being said, there are a lot of interesting possible given scriptless scripts / adapter signatures (see https://raw.githubusercontent.com/LLFourn/one-time-VES/master/main.pdf & https://eprint.iacr.org/2024/1809.pdf) - basically anything that can be expressed as a series of zk-proofs can be used as an adapter signature. Other new cryptography such as VDF (Verifiable Delay Functions) offer other possibilities.

The intent of this project is not production code, but a solid proof-of-concept to inspire others to consider the possibilities, and to explore the security and cryptography issues. For instance, we had to create a novel VRF to leverage the same cryptographic shares that FROST uses for signing, but we don't have a formal security proof.

-- Christopher Allen

P.S. One of my side goals of this early prototype is to play around with various governance types: see Polis Play (https://PolisPlay.com) and Spectrum of Consent (https://www.lifewithalacrity.com/article/a-spectrum-of-consent/).

[Christopher Allen]

On Thu, Sep 25, 2025 at 9:54 AM Christopher Allen <Christ...@lifewithalacrity.com> wrote:

That being said, there are a lot of interesting possible given scriptless scripts / adapter signatures (see https://raw.githubusercontent.com/LLFourn/one-time-VES/master/main.pdf & https://eprint.iacr.org/2024/1809.pdf) - basically anything that can be expressed as a series of zk-proofs can be used as an adapter signature. Other new cryptography such as VDF (Verifiable Delay Functions) offer other possibilities.

For the cryptographic nerds, here are two other important papers on adapter signatures:

"Consecutive Adaptor Signature Scheme: From Two-Party to N -Party Settings" https://eprint.iacr.org/2024/241.pdf. The paper extends adaptor signatures from two-party to secure multi-party (N-party) settings, introducing a new security model, the PreAdapt mechanism for chaining adaptations, and a concrete Schnorr-based construction. It shows why naïve chaining of two-party schemes fails, and highlights applications like content provenance that benefit from this generalized design.

Another paper on my list as important (but not fully grok'ed) is "Adaptor Signatures: New Security Definition and A Generic Construction for NP Relations" https://eprint.iacr.org/2024/241.pdf. This paper strengthens adaptor signature theory by introducing witness hiding, ensuring that a secret witness can only be extracted when both the pre-signature and the final signature are available, not from either alone. It then provides a generic construction using trapdoor commitments, and shows via the Hamiltonian cycle problem that such witness-hiding adaptor signatures can be built for any NP relation from basic one-way functions.

Right now we have only very basic support for creating adapter signatures, but the Gordian Club architecture already supports them. Delegation using an adapter signature for read clubs is very easy. For write clubs it is a little more complicated but reasonable. More novel constructions (say for various forms constraints) feels feasible but not obvious.

All of these require the Schnorr, however, there has been research on PQR adapter signatures (which I don't follow deeply).

I believe there are other ways to implement autonomous cryptographic object capabilities than Schnorr, which I hint at in my 2018 message to Cap-Talk https://groups.google.com/g/cap-talk/c/SCRpXZWe-Eo/m/9dYQhWbxEAAJ, but I haven't explored them any further. 

-- Christopher Allen