The immediate disruption was minor: the models were only days old, and Anthropic’s other models still run. What matters is what it proved: a government can reach in and switch off a frontier model for everyone, overnight. The off-switch exists, and now we know who controls it.

For years I’ve been making a different argument, and building a name for the alternative: Self-Sovereign Computing and the design pattern I call Exodus Protocols. The Fable suspension is one more confirmation of why they matter.

I’m not the first to warn that frontier AI companies have become part of the problem. The sharpest version of that case belongs to Ahmad Osman, an AI researcher and r/LocalLLaMA moderator who recently wrote the essay “Anthropic’s War on Opensource AI”. The Anthropic framing is his. He wrote his article arguing a general pattern, not this specific event. The recent suspension isn’t even in it!

“It is selling cognition as infrastructure. Once cognition becomes infrastructure, anti-competitive access control stops being a normal vendor dispute and becomes a social bottleneck.”

“Claude is not your agent. Claude is Anthropic’s agent, rented to you.”

Read after Friday’s suspension of Fable, it reads like a forecast. The government pulling Fable is that pattern arriving on schedule.

This isn’t hypothetical

A frontier model was pulled for everyone, by government order, and Fable access already required 30-day retention of your data. The next step writes itself: an identity check to use a frontier model — age-gating technology, but for thought — and monitored sessions as the price of entry. We have built that machinery before, for other purposes; now, it ports cleanly to cognition. Ahmad’s name for where that leads is hard to improve on:

“A society where a few labs own the frontier and everyone else rents obedient wrappers is not advanced. It is feudalism with GPUs.”

Or, as I say in my community draft of The Architecture of Autonomy:

“We are human beings, not digital serfs.”

The pattern is older than AI

This is where my own framing comes in, because the shape is not new. When I co-authored TLS 1.0, we already understood that technical protocols encode power relationships. The coalition that stopped Microsoft/Visa/Mastercard from owning the internet plugged that hole. Yet, in every decade since, we have closed one architecture that funneled rent and control toward a center — certificate authorities, platforms, identity systems — only to watch a larger one open in its place. As I wrote in my article, “When Technical Standards Meet Geopolitical Reality”:

“We build protocols for human autonomy and watched them become instruments of platform control.“

Permissioned AI is the biggest such hole yet. It is the inversion I have spent years naming: a right quietly rewritten as a revocable privilege. The test is simple: when a capability depends on someone’s approval, it is not a right. It is permission.

The way out is the one that has always worked: Exit

As I say in “The Exodus Protocol”:

“Without the ability to walk away, consent collapses into coercion.”

The answer to a permission regime is not to petition for kinder permissions; it is to stop needing them. Own the model. Own the hardware. Own the keys. Local inference, open weights, and your own cryptographic control: this is what Self-Sovereign Computing and Exodus Protocols have always been about. Ahmad arrives at the same place from the builder’s side:

“A GPU is a tiny declaration of independence.”

None of this is inevitable. We have routed around centralized control before, and we can build the exit again: self-sovereign identity, self-sovereign computing, and now self-sovereign cognition that no one can revoke, degrade, or rent back to you.

Own the stack

A decade ago I helped write the principles of Self-Sovereign Identity. We are revisiting them now, for their tenth anniversary, because the frontier has moved, from who controls your identity to who controls your cognition. The principle has not changed, only the stakes: own it or rent it.

The short answer is that proliferation is not actually the deepest problem (and I say that having spent thirty years architecting trust systems and watching credentials standards evolve to the ones we have today, and having co-authored TLS 1.0). Instead, it’s that most of the existing formats share a small number of design choices that I think are wrong.

As an example, I watched cryptographic agility get oversold in the ’90s, retrofitted with ciphersuite negotiation, exploited through downgrade attacks, and finally walked back in TLS 1.3. That arc isn’t unique to TLS. It shows up everywhere: optionality has long been treated as a design feature rather than a liability. JOSE is the most recent and visible example. The alg header put attackers in the verifier’s seat, and the standard has spent a decade patching around it rather than admitting the choice was wrong. There are any number of situations like this where our design choices were wrong, including not just in-band algorithm negotiation, but also signature over literal bytes rather than over meaning, issuer-controlled disclosure, JSON’s malleability, layer violations, and singular private keys.

I say “wrong” with affection. The JOSE working group built something that shipped, got adopted, and pays a lot of mortgages. That matters. But we should be willing to look at what shipped and say: the optionality is the problem. The bag-of-attributes JSON is the problem. The signature over literal bytes rather than over meaning is the problem. The bolt-on for selective disclosure is the problem. Each of these is a place where the standards bodies did the best they could under the constraints of the moment but they produced something that comes up short when we measure it against the trust properties we actually want for the next decade.

No amount of additional formats sharing these incorrect choices will solve the underlying problems. But a new format with new design choices could.

A New Solution

So that’s “Why build another?” But what about “Why now?” I’ll be transparent about the timing. When JWT and JSON-LD fought it out during the DID 1.0 process (and that fight slowed the standard down by years), I didn’t feel that I could object. Both sides had real problems. I had opinions, but in the old IETF tradition, opinions without shipping code don’t count for much.

Though I didn’t have shipping code, I do now.

Gordian Envelope is my attempt to make different choices at the substrate layer and see what falls out. Whether that justifies the fifteenth standard is a question I’ll come back to at the end.

So: what does Gordian Envelope do differently?

Gordian Envelope is a substrate, not a credential format. It’s dCBOR underneath, structured as semantic triples (subject, predicate, object), with every node carrying a digest and the whole thing forming a Merkle-like tree. A signature commits to the root. Any subtree can be elided (any subject, predicate, object, or assertion) and the signature still verifies. The holder (not the issuer) gets to decide what to reveal. This is the property I want as a human first and an architect second.

Envelope is also radically recursive. Any subject, object, or assertion can itself be an envelope. That recursion is what lets the same substrate carry property graphs, hypergraphs, labeled directed multigraphs, and several other shapes — not by adding modes or options, but because the structure is general enough that those graph models fall out of it. My Lead Researcher, Wolf McNally, and I wrote that up in BCR-2024-006. I want to be precise about what this is and isn’t: it is not cryptographic agility in disguise. There is one encoding, one signature semantics, one elision mechanism. The expressivity lives in the data model, not in protocol switches.

The Advantages of Envelope

I also want to be specific about what Gordian Envelope buys you, because vague privacy claims have done enough damage already.

It buys you canonical encoding. dCBOR has one representation per semantic content. Two parties assembling the same envelope from the same facts produce byte-identical outputs. JSON cannot do this without enormous effort and a lot of footguns. JSON Canonicalization Scheme exists, but ask the people who tried to deploy it how it went. JSON-LD’s situation is worse, and worth naming specifically: to canonicalize the bytes you have to first understand the semantic layer above them. That’s because the RDF Dataset Canonicalization algorithm (URDNA2015 and its successors) requires you to parse the JSON-LD into an RDF graph, resolve the @context, expand IRIs, and canonicalize that, before you can produce a stable byte sequence to sign. That’s a layer violation, or even an inversion! The encoding layer has been made dependent on the meaning layer, and any disagreement at the meaning layer (such as a context that dereferences differently, a blank-node labeling difference, or an unresolvable IRI) breaks the signature. Envelope refuses that dependency. dCBOR canonicalizes at the encoding layer, full stop, and the semantic structure is built on top of bytes that are already stable.

It buys you data minimization that doesn’t depend on the issuer’s foresight. SD-JWT requires the issuer to commit, at issuance time, to a set of disclosable fields. The issuer is deciding, in advance, what you might want to share. With Envelope, the issuer signs everything and walks away. You — the holder — then decide what to reveal at presentation time. That’s closer to what RFC 6973 “Privacy Considerations for Internet Protocols” actually calls for. It’s also closer to how human trust works in the real world, which is the entire premise of progressive trust.

It buys you cryptography that doesn’t negotiate with attackers. The verifier knows what it accepts. The envelope doesn’t tell it. We learned this from TLS. We learned it again from JOSE. I would like us not to have to learn it a third time.

It buys you composable structure. Signatures are assertions. Expiration is an assertion. Audience binding, witness attestation, revocation, and notarization are all assertions. The protocol layer and the application layer share a uniform shape, and you extend the format by adding assertions, not by petitioning a registry for another reserved claim name.

The Challenges for Envelope

Now the honest part.

We made mistakes in the early design. The most public is BLAKE3, which we originally used to produce the hashes that are signed. We picked it because it’s modern and fast. We then discovered that our actual use cases (air-gapped wallets, constrained devices, and hardware seed managers) don’t need BLAKE3’s streaming features and do need SHA-256’s ubiquity. Backing out to use SHA-256 instead cost us code, drafts, docs, and credibility. I wrote about it in “Problems of Cryptographic Agility”. If we’d shipped with cipher-suite agility, we could have just deprecated the algorithm and moved on. We chose not to, and we paid for that choice with a year of cleanup. I still think the choice was right. Optionality is a debt you eventually have to pay.

In addition, adoption is small. Reference implementations are in Rust and Swift. We have a third-party Typescript library, but JavaScript support is overall thin, and the credential world runs on JavaScript whether we like it or not. Meanwhile, our IETF draft for Envelope is still at the “individual-submission” stage. Finally, there’s no IANA registry entry that makes a procurement officer’s life easier. None of this is fixed yet, and I won’t pretend otherwise.

Ultimately, I don’t think Gordian Envelope will replace JWT. JWT will continue being the bearer-token shape for OAuth and OIDC for the foreseeable future, and that’s mostly fine: OIDC is a short-lived-token use case where many of JWT’s worst properties are tolerable. The places I want Envelope to win are the ones where the holder has to live with the document for years. Credentials. Key and seed storage. Capability tokens. Software-release attestations. Healthcare consent. Anything where data minimization and progressive trust matter more than fitting in an HTTP header.

Final Notes

The XKCD punchline is “there are now 15 competing standards.” It doesn’t say one of the fifteen can’t be better than the previous fourteen. It says that adding the fifteenth, framed as unification, is the joke. I don’t frame Envelope as an unification. It’s a substrate that respects principles I’ve spent three decades trying to articulate: human dignity, holder agency, progressive trust, minimum viable architecture. If a better substrate emerges that respects those principles, I’ll migrate to it. The principles are what matter; the format is the carrier.

I’d rather we argue about whether the principles are right than whether we have too many standards. We have too many standards because we keep ducking the harder conversation. Let’s have it.

— with thanks to Wolf McNally, who actually writes the code; to Shannon Appelcline who writes the docs and tests our ideas; to the Decentralized Web community, who pushes back when I’m wrong; and to the dCBOR working group at IETF, who are doing the unglamorous foundational work.

Envelope Intro Videos

See our videos Understanding Envelope Part One and Understanding Envelope Part Two for more on Gordian Envelope

Envelope Structure:

Envelope Hashes:

Redacted Hashes:

Related Reading

• BCR-2024-006, Envelope as a Universal Graph Substrate — https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-006-envelope-graph.md
• Problems of Cryptographic Agility — /article/musings-agility/
• Data Minimization & Selective Disclosure — /article/musings-data-minimization/
• Progressive Trust — /article/musings-progressive-trust/
• Progress Trust Life Cycle — /article/progressive-trust/
• Minimum Viable Architecture — /article/musings-mva/
• When Technical Standards Meet Geopolitical Reality — /article/musings-gdc25/

“[Amira] wishes to take a more active role in making a better world. However, she knows if she stands out from the crowd that any activism she may get involved in may not only affect her, they may affect her parents or even her extended family abroad.”

It detailed the need for a pseudonymous identity that was separate from a user’s real-life, physical-world identity, but that would be stable and could progressively gain measures of trust over time such as endorsements and links to completed work.

Amira has been my North Star for much of the last decade. It informed my work as a co-author of the DID standard and after we finished that work, it continued to inspire my development of my own decentralized identifier, the XID.

Today, I’m very pleased that my 2017 use case has become a 2026 reality. My Learning XIDs course demonstrates how the requirements of the Amira use case are now being met by a working technology.

There’s a lot more in the Blockchain Commons article, including how we got from there to here, what requirements the Amira use case surfaced (in a few different iterations), what requirements were still missing even after DIDs were published, and how it’s all gone into the development of the XID technology. I hope you’ll take a look!

I noted this briefly in my recent Dispatch on Technology Paternalism, but the new mandate deserves its own treatment. When Vitalik talks about working to “preserve technological self-sovereignty” and “enable cooperation without coercion, domination or rugpulling,”³ something is happening that those of us working on Exodus Protocols, Architectures of Autonomy, and coercion-resistance lenses of Self-Sovereigh Identity should pay attention to.

This Dispatch is about what Vitalik and the Ethereum Foundation are saying, where it overlaps with what I’ve been saying, and where the work goes from here.

What Vitalik Said

Vitalik’s March 3 posting introduced the idea of sanctuary technologies:

“Ethereum should conceptualize ourselves as being part of an ecosystem building ‘sanctuary technologies’: free open-source technologies that let people live, work, talk to each other, manage risk and build wealth, and collaborate on shared goals, in a way that optimizes for robustness to outside pressures.”¹

He added to that framing by talking about the creation of a collaborative space:

“Ethereum’s role is to create ‘digital space’ where different entities can cooperate and interact.”¹

Instead of trying to compete with Apple or Google, his goal is “de-totalization”:

“Do not try to be Apple or Google, seeing crypto as a tech sector that enables efficiency or shininess.”¹

“[instead] reduce the stakes of the war in heaven, by preventing the winner from having total victory.”¹

When Vitalik announced the EF mandate on March 13, he repeated his framing, saying that Ethereum is to be “a sanctuary technology, to preserve technological self-sovereignty, to enable cooperation without coercion, domination or rugpulling,” ensuring “no single person, organization or ideology’s victory in cyberspace can be total.”³

This is not isolated to Vitalik. Bastian Aue, whose appointment as Co-Executive Director was announced in February, said it more bluntly in his own statement at the time:

“The mandate of the EF is to make sure that real permissionless infrastructure, cypherpunk at its core, is what gets built.”⁴

As for the mandate itself? It makes a lot of the self-sovereign ideas that Vitalik talks about in his personal posts concrete by requiring Ethereum to have the property of CROPS⁵: Censorship Resistance; Open Source and Free, as in Freedom; Privacy; and Security. It also emphasizes long-duration survival by highlighting a walkaway test: could Ethereum continue to function without the Ethereum Foundation?²

All together, this is a pretty big commitment to self-sovereign ideals, and one worth talking more about.

Where Sanctuary Meets Exodus

I’ve been talking about self-sovereignty since I introduced the term in “The Path to Self-Sovereign Identity”⁶, the principals of which I’ve been updating through the Revisiting SSI project⁷. Recently, I wrote about self-sovereignty from the perspective of Exodus Protocols⁸. I define them as “systems that free us from the control of external sources (like Google or Yahoo! or Sony) by creating infrastructure that doesn’t require infrastructure.” Bitcoin is my prime example of a working Exodus Protocol.

My discussion of freedom from external control is a good match for Vitalik’s discussion of optimization “for robustness to outside pressures.” Generally, I feel like his Sanctuary Technologies match a lot of my Exodus Protocol patterns for creating autonomous infrastructure⁸:

1. Operate Without External Dependencies.
2. Encode Rules in Mathematics, Not Policy.
3. Make Constraints Load-Bearing.
4. Preserve Exit Through Portability.
5. Work Offline and Across Time.

Vitalik’s call for “technological self-sovereignty” aligns with patterns one and two while the discussion of survivability mirrors points from patterns four and five. The CROPS priority stack reveals the reason for many of these patterns, something I discuss further in Revisiting SSI lenses such as “Coercion Resistance”, “Self-Coercion”, “Choice Architecture & Exit Rights”, and “Binding Commitments”. Vitalk even reaches for the term “tech enshittification / corposlop”¹ — which is Cory Doctorow’s term that I have also used in describing why our digital infrastructure is built on sand.

I do feel like there’s one major difference, however: Sanctuary Tech is a goal while Exodus Protocols are an architecture.

Vitalik’s test for Sanctuary Tech is functional: robustness to outside pressures. By that test, his examples include Starlink, locally-running open-weight LLMs, Signal, and Community Notes.¹ These are good things, and at the present moment they meaningfully expand human autonomy. But Starlink is centrally owned by a single corporation. By my Five Patterns, Starlink fails Pattern 1 (Operate Without External Dependencies) and Pattern 2 (Encode Rules in Mathematics, Not Policy). It is liberating today, but it’s not architecturally resilient against the day whoever owns it changes their mind. Similarly, Signal has a dependence on access to a cell phone with a cell number.

The EF Mandate’s test is sharper than the X post. Walkaway resistance and long-duration survival are closer to the Exodus framing. But the gap remains: Sanctuary Tech describes what we want, while Exodus Protocols describe what is needed to deliver it.

This is the same gap I’ve been working in the Architecture of Autonomy and the Revisiting SSI coercion-resistance lenses: the difference between naming a value (privacy, decentralization, sanctuary) and engineering it as a load-bearing constraint that holds when the political wind changes.

What’s the Next Step

The Ethereum Foundation has named the right goal. The work now is the architecture.

Concretely, three things would help:

1. Cross-pollinate the conversations. The identity community has spent ten years working through the failure modes of sovereignty claims, including our own. The Ethereum Foundation has spent ten years building the most credibly-neutral programmable infrastructure on the planet. The lessons translate in both directions. The work has been siloed for too long, and the Revisiting SSI initiative is one venue where that cross-pollination can happen.

2. Test Sanctuary Tech candidates against the Five Patterns. Starlink does not pass. Signal does not pass. Some Ethereum protocol-layer mechanisms, such as FOCIL for inclusion lists, encrypted-mempool proposals, and account abstraction at the right layer, plausibly do. The LEAN Ethereum roadmap and the post-quantum work the EF has named are candidates that deserve to be examined as Exodus Protocols, not merely as performance or security improvements. The Five Patterns work as a checklist.

3. Apply coercion-resistance lenses to wallet and L2 architectures. Finally, we can revisit the RSSI lenses for coercion and apply them to wallets. Though they were built for identity, they’re agnostic about which stack they analyze, and Ethereum’s wallet layer deserves the same scrutiny that we have brought to digital identity wallets. Unfortunately, we already know that many “sanctuary technology” candidates, especially wallets, currently ride on the same Apple/Google attestation infrastructures that we identified as compromised in EUDI wallets.

We are at an unusual moment. An institution with the resources, talent, and protocol surface area of the Ethereum Foundation has just declared, in writing, that it considers itself in the business of building infrastructure that can’t be taken away. That alignment with the Exodus Protocol thesis is rare. It is also fragile: the EF’s executive leadership has turned over twice in the last twelve months⁹, and institutional resolve in technology rarely outlasts the people who first articulated it. Wo we need to take advantage of this opportunity now.

If you are building anything you would call a Sanctuary Technology or an Exodus Protocol, I would like to talk. My Architecture of Autonomy draft is open for community comments, the Revisiting SSI lenses are open, and the Exodus Protocol patterns are public. The Ethereum Foundation has named the goal.

We must use that opportunity to build a foundation that won’t fall.

Citations

I did not expect what happened next.

Those ten principles — which I had written more as a first draft than a manifesto — became the conceptual foundation of an industry. They have accumulated more than a thousand academic citations. They’ve been quoted, adapted, debated, critiqued, translated, and deployed in contexts I could not have imagined. They anchor work on decentralized identifiers and verifiable credentials, show up in United Nations discussions, and (occasionally) on conference T-shirts. And for most of a decade, they have stayed largely unchanged.

That is, in part, a compliment. And in part, a problem.

Principles written in 2016 could not have anticipated the commodification of behavioral data at the scale we now live with, the normalization of mandatory digital ID as a precondition for civic life, or the ways “self-sovereign” would come to be invoked at the protocol layer, in regulatory filings, and at venture pitches, by organizations whose interests are not the same as the interests of the people the principles were meant to protect.

Capital flows to centrality. We wrote the principles loosely enough that the loopholes were exploitable. And they have been exploited.

I have spent much of the last year talking about this with others in the RevisitingSSI project — working circles on principal authority, anti-coercive design, properties vs. principles, and what it means to exist at all in a digital age. Those conversations, with academics and standards people, with civil society practitioners and critics that I learn from, have convinced me that the original ten were not wrong. They were incomplete.

Today, on the ten-year anniversary, I am publishing the first community draft of a revision:

Principles of Self-Sovereign Identity — 2026 Revised, First Community Draft

A stable archival copy is mirrored at revisitingssi.com/library/ssi-principles-2026-redline/ for permanent reference.

The draft keeps the 2016 language verbatim wherever it survives, so continuity stays legible alongside revision. It updates each original principle, introduces six new ones (Inalienability, Cognitive Liberty, Relational Autonomy, Stewardship, Equity, Anti-Coercive Design), and organizes all sixteen principles into four layers: foundational, relational, technical, and political.

It is unfinished on purpose.

I am publishing it in redline form, on the anniversary, precisely because I do not want it read as a press release. I want it read as a draft: a draft I expect others to push back on, to correct, and to sharpen. That is what I asked for in 2016. It is what I am asking for again.

What has changed is that I now know how long this work takes, and how much of the work that the community has to do.

If you have been in SSI for any length of time — whether as a believer, a skeptic, or both at different hours of the day — the Google Doc is open. Leave comments. Argue in the margins. Tell me where the new language is weaker than what it replaced. Tell me which of the six new principles I should not have added. Tell me which ones I am still missing.

I will be at the Internet Identity Workshop in Mountain View this coming week (April 28–30), as a guest on the W3C Credentials CG call on May 5 (9am PDT / 12pm EDT / 6pm CEST), and hosting a dedicated community discussion on May 20 (10am PDT / 7pm CEST). The goal between now and September, when we aim to present a more mature version at the Global Digital Collaboration summit in Geneva, is to take the redlines from “first draft” to something worthy of the next ten years.

If you would like to be part of that, join the announcements-only email list, the Signal group, or simply open the doc.

The goal is not to settle the questions of self-sovereign identity.

The goal is to make these principles worthy of the next ten years.

Today that concern is more important than ever because of the deployment of LLM-driven agentic systems. We can increasingly empower agents in the digital ecosystem to compile our searches, to augment our coding, and to generally solve our problems. But how do we do so in a way that supports our autonomy rather than eroding it?

What follows are three views of the agentic future: two problems we need to address and one solution that we can look forward to. They reflect some of the current work I’m doing with various groups on AI, agency, and the future of computing.

View #1: The Authority Problem

The nature of human agency is rapidly changing due to the possibility of agentic delegation and augmentation. Once you could say that an individual’s agency would be maintained by their purposefully and mindfully agreeing to all actions undertaken by an application. But that’s no longer possible when agents can act at superhuman speeds that are too rapid to actively monitor. Maintaining agency therefore requires a change from tactical overview (agreeing to every action) to strategic overview (agreeing to the scope of action and setting boundaries for the activity).

Fortunately, we already have a model that supports this sort of strategic control while maintaining agency: “Principal Authority”. It’s literally part of the Laws of Agency, which define how an agent can be empowered to take on certain tasks. Back in 2021, my work with the Wyoming legislature helped to bring it into the world of digital identity by defining your digital identity as something over which you have Principal Authority.

Following the implicit understanding that an individual has control of their identity, the most important element of Principal Authority is probably its definition of duties. When you are temporarily extending your identity to others, including agents, they must promise to use it in certain ways. Those duties should include many of my original self-sovereign principles, including access, interoperability, minimization, portability, protection, and transparency, as well as many others: agents must work for you in good faith, must put your interests above those of theirs (or rather those of their corporate masters), and must act with reasonable care.

Again, a state legislature has taken the lead on this work. Just this year, Utah passed the state-endorsed digital identity (SEDI) amendment, which includes a full digital Bill of Rights. Among those Rights is a “Duty of Loyalty”, which says that processors of digital identity must act in the identity holder’s best interest.

Creating similar duties and requirements for LLM agents, to ensure that they are working for you, without hidden agendas, is a crucial milestone as the AI era quickly dawns. Principal authority should be a model for doing so. We must use it to answer questions like: Who is an agent delegating from? What is it tasked to do? How can it undertake that task in the way that best protects the Principal and their data? What are the constraints placed on the agent?

I’ve suggested some “predicates” for the Gordian Known Value system that might start to address some of these issues, by allowing users and their agents to record things like:

• principalAuthority — The entity with authority over the work
• assertsDelegationFrom — Agent’s claim of delegation from a principal
• delegationScope — Boundaries of delegated authority
• delegationConstraints — Specific limitations on the delegation

But, it’s a starting point, not an end-point.

View #2: The Credit Issue

When you’re using an agent, even if your authority is being protected, another question arises: how do you credit work done?

This isn’t actually a new problem created by AI. Ghost writers have existed for centuries. Collaborations have always involved complex divisions of labor that don’t map cleanly to “author” and “contributor”. What AI does is make the gap undeniable. When an agent is performing actions (or moreso: creating content), we can no longer quietly elide the distinction between “who wrote this” and “who is responsible for it.”

The ghost is visible now.

The question is how we can properly note which work is entirely ours and which is LLM driven. But, it’s not even that simple, as LLMs could be trained largely on our own work, rehashing our arguments and knowledge, or they could be built on the summed-up Wisdom of the Crowd. How do we differentiate between those two situations? And how do we give fair notice to readers who may think differently about spending their time reading an LLM-authored piece, an LLM-supported piece, and a human-written piece?

As I said, the problem goes beyond LLMs and is fundamentally about credit in authorship. Again, I’ve suggested some predicates as a starting point, with my focus not on the question of AI input, but instead what the roles are in a creative process. Those predicates currently include: Author, Editor, Architect, Designer, Manager, ConceptOriginator, Documenter, TechnicalProducer, Curator, Reviewer, Maintainer, MaterialContributor, Performer, IntellectualContributor.

Do we need more? Less? And are these sufficient to also define LLM-driven work on a piece?

View #3: The Self-Sovereign Computing Solution

Though I’ve talked so far about the work I’ve been doing on issues (or at the least, “new questions”) that are arising from the LLM revolution, it’s also important to talk about some of the advantages. And one of the advantages is a growth in the potential of a topic that I’ve addressed before: self-sovereign computing.

In my original article on “self-sovereign computing”, I talked about how you could control your digital destiny by running your own tools on your own local machine. It was yet another way to address the issue of agency.

Local AI on your own silicon is Self-Sovereign Computing in practice. Apple Silicon + MLX + local models make it real infrastructure. There’s no cloud dependency, no data leaving your machine, no subscription toll. Your data stays on your device. Your inference runs on your hardware. No API key is required.

It’s also really coming of its own. Some recent advancements in leveraging the M-series silicon have doubled the inference speed of certain models:

Metal (Q4_K_M quantization):

MLX (nvfp4 quantization):

We built Self-Sovereign Identity so that your keys and credentials could stay under your control rather than being held by a platform that could revoke them. Local inference is the same principle applied to AI: the model runs where you do, on hardware you own. Combined with a self-sovereign wallet holding your keys and credentials, this is a complete stack where nothing about your digital life requires asking permission from a third party.

Final Notes

I’ve long written that identity is a double-edged sword. If wielded right, it can provide us with considerable power, but if wielded wrong, it can wound us fatally.

The same is true of the agentic power being unleashed by the LLM revolution. The possibilities of self-sovereign computing show how this power could be turned to our advantage, truly empowering the self-sovereignty that I’ve long advocated. However, the credit issue demonstrates the new (or at least newly highlighted) questions arising from agentic use, while the authority problem reveals that we need to carefully construct guard rails for this new technology.

If you’d like to talk more about these possibilities email me. I’m also looking for sponsors and partners to support me in doing more of this work.

“Privacy” doesn’t name the problem any more because it means something different to every regulator in the room. “Decentralization” became a buzzword, but it no longer prevents coercion due to compromises. “Interoperability” has been similarly corrupted by EUDI wallets that claim the term while depending on Apple and Google attestation infrastructures.

Martina Kolpondinos, who spent 15 months inside the Swiss federal eID team and is a co-editor on the WebVH spec, has just published a piece¹ that may offer an answer by naming the pattern we keep running into: Technology Paternalism.

The term goes back to Spiekermann & Pallas², who argued that ubiquitous computing raises concerns beyond privacy: specifically, whether people can maintain control when systems decide for them. They proposed “the right for the last word”: the ability to overrule autonomous system behavior. Unfortunately, twenty years later, things are worse, not better: 84% of organizations doubt they can even audit their AI agents³.

In my upcoming Architecture of Autonomy work, I’ve mapped how legal protections designed as shields against coercion get inverted in digital systems: property becomes privilege, contracts become coercion, due process becomes algorithmic absolutism, and exit becomes erasure. Kolpondinos shows how these same inversions manifest as paternalistic “features.” She does so by building a four-part taxonomy for Technology Paternalism:

• Design Paternalism. The “quick setup” for systems is prominent, and “advanced” settings are buried. You aren’t forced, but you are guided to a preferred usage pattern.

• Algorithmic Paternalism. Systems pre-select what you see. The defaults require no action, but choosing diversity requires effort.

• Infrastructural Paternalism. Your credentials, reputation, and relationships accumulate in a single ecosystem. Though you can leave, you leave empty-handed. This is what happens when the “interoperable” standard requires a specific device stack.

• Protective Paternalism. Restrictions are framed as safety. If you question them, you sound irresponsible. This is what silences objections in standards bodies. As discussed in the replies to Martina’s post, we ultimately want to annotate information, not censor it. This doesn’t suppress contradicting claims, but instead holds them as attributable, visible, and resolvable. That’s the kind of trust infrastructure we should be building: systems that make reasoning inspectable, not systems that decide for you.

Fundamentally, this paternalism is all coercion: it’s taking away your choices and replacing them with the designer’s choices. This is an increasing problem in technological spaces, and fighting coercion (through anti-coercion or coercion resistance) is definitely something that could replace our old buzzwords such as “privacy”, “decentralization”, and “interoperability”.

Vitalik Buterin recently discussed the issues when he published the Ethereum Foundation mandate⁴, three days before Martina’s article. There, he frames Ethereum as “sanctuary technology”, designed to “support technological self-sovereignty and allow cooperation without centralized coercion.” His CROPS priority stack (Censorship resistance, Open source, Privacy, Security) tracks the same concerns from the protocol layer.

We’ve also been developing coercion-prevention lenses⁵ in the Revisiting Self-Sovereign Identity initiative (revisitingssi.com). Kolpondinos’s article is the first published output from a workshop participant, and it translates the identity community’s coercion analysis into language the broader design community can use.

Ultimately, I think “technology paternalism” and “coercion resistance” work as a pair. Paternalism offers the diagnosis: it names an anti-pattern. Coercion-resistance then provides the treatment. Both do more work than “privacy” because they name the mechanism, not just the domain.

However, Technology Paternalism is harder to fight than outright ideology because it embeds moral choices in technical decisions and then presents them as neutral engineering. You could argue with someone if they were making an unvarnished moral claim, but you can’t easily argue when they say “that’s just how the protocol works.”

But Kolpondinos’ four countermeasures are a great response. She suggests tests that I wish every identity project would apply: Can you override the system’s decision? Contest it? Inspect the reasoning? Leave without losing everything?

Apply that to any wallet architecture currently in standardization.

Read Martina’s article, “Technology Paternalism Expands — A Case for Self-Sovereign Identity”: https://www.kosmaconnect.net/interactionblog/technologypaternalism

Citations

#DigitalIdentity #SelfSovereignIdentity #CoercionResistance #TechnologyPaternalism

UPDATE, March 5, 2026: SB 275 has passed the Utah legislature unanimously — the Senate voted 25-0 and the House 70-0 — and has been sent to the governor for signature. It takes effect May 6, 2026. This is a huge win. If you’re in Utah, thank your representatives. If you’re in another state, point your legislators at SB 275 and Wyoming SF39 as model legislation. The fight now shifts to preservation — watch for future amendments that weaken the Duty of Loyalty or selective disclosure protections.

Most of my identity advocacy work in the United States has been in Wyoming. They’ve been very open to the goals of self-sovereignty and as a result we’ve passed laws such as private key protection and we’ve defined digital identity as being controlled by an individual’s principal authority.

So it’s great to see another jurisdiction, which I have been less directly involved with, progressing on their own vision of self-sovereignty. That’s the whole purpose of advocacy: to seed the ideas so that they spread.

I’m talking about Utah, whose State-Endorsed Digital Identity (SEDI) has been moving in a great direction for a while. The newest bill introduced for it, S.B. 275, the “State-Endorsed Digital Identity Program Amendments”, which does all the heavy lifting of establishing SEDI, solidifies it as a privacy-first, decentralized design.

A Bill of Identity Rights

The first thing that caught my eye in the SEDI update was a new Bill of Rights. It immediately presents the digital-identity user not just as a digital serf, but someone who can claim privileges.

The lead right was surprising:

(1) “An individual possesses an individual identity innate to the individual’s existence and independent of the state, which identity is fundamental and inalienable.”

That’s pretty close to my first principle of self-sovereign identity, existence:

Existence. Users must have an independent existence. Any self-sovereign identity is ultimately based on the ineffable “I” that’s at the heart of identity. It can never exist wholly in digital form. This must be the kernel of self that is upheld and supported. A self-sovereign identity simply makes public and accessible some limited aspects of the “I” that already exists.

It was great to see an understanding that any digital identity is founded in a real person. That lays the foundation for its importance in the digital world.

There was tons more in the bill of rights that was amazing.

This is pretty close to self-sovereignty:

(2) An individual has a right to the management and control of the individual’s digital identity to protect individual privacy.

This requires transparent architecture:

(7) An individual has a right to transparency in the design and operation of a state digital identity, including the right to access, read, and review the standards and technical specifications upon which the state digital identity is built and operates.

This is a little wobbly (because of the “except as authorized by law”), but is a strike against the surveillance state:

(10) An individual has a right to be free from surveillance, profiling, tracking, or persistent monitoring of the individual’s assertions of digital identity by the state, except as authorized by law.

But this may be my favorite:

(8) An individual has the right to choose what identity attributes are disclosed by the individual’s state digital identity in accordance with standards established by the Legislature.

This is potentially full empowerment of selective disclosure, depending on what the standards are. I wrote recently that one of the big failures of the SSI community is the fact that they stepped away from a holder being able to determine what they can redact in their identity. That a state legislature may beat them to the punch is shocking.

I think a digital-identity bill of rights is a great thing. It’s what I was thinking about when I put together the original principle of self-sovereign identity. I’m now revisiting those principles for the SSI 10th anniversary, and this looks like another great source to consider.

The Duty of Loyalty

There’s a ton to like in the bill, including anti-correlation, selective disclosure, minimal disclosure, and a variety of requirements for digital-wallet providers, verifiers, and relying parties that all tend to protect the holder of the identity. It’s clear that someone was involved who really knew what they were doing and also undestood the importance of a user controlling their own identity.

But the other one that I thought was of particular note was the “Duty of Loyalty”

63A-20-701. Duty of loyalty. The department, a digital wallet provider, a verifier, a relying party, and a digital guardian shall refrain from practices or activities related to the processing of an individual’s identity attributes that:

(1)conflict with the best interests of an individual;

(2)take advantage of or otherwise exploit an individual;

(3)result in a disproportionate risk to an individual;

(4)are to an individual’s detriment; or

(5)cause harm to an individual.

This is a critical right, tying into the Principal Authority work that I did with the Wyoming Blockchain Select Committee. It similarly evokes agency law to say that when other entities are using your digital identity, they can only do so to support your best interests. Compare that to the modern-day ecosystem of surveillance capitalism and extraction and the difference is obvious. Many modern-day digital services are built on allowing you to create an identity (on Facebook, on Google, whatever) and then mercilessly extracting from that, stealing your attention, your creativity, and everything else.

There are obviously questions with how this will be managed. For one, I can’t see how “related to the processing of an individual’s identity attributes” will be interpreted. Obviously, it’ll protect you from hi-jinks on the part of your verifier (which is a huge win) but it’s unclear whether it’ll provide any protection for someone who is enabling you to interact online with your identity (e.g., Facebook).

The other question is whether entities can coerce users to give up this right, which is a common modern-day tactic (c.f. “clickwrap”). From the research I’ve done so far (IANAL), it looks like these aren’t rights that could be signed away in a contract—they represent minimum statutory requirements, and that as long as carve-outs aren’t created in the law, this Duty of Loyalty will be protected.

That’s what we need to fight against here. We need to “beware platforms bearing gifts”: we have to watch for Googles and Facebooks using regulatory capture to ask for carve-outs in this law that will steal away the rights from us and give it to them by making them optional. And that’s unfortunately a pretty big task in the modern world.

Make a Difference

I haven’t analyzed every line in S.B. 275. I wouldn’t be surprised if I find some things I don’t agree with as I explore it further. But in the big picture, this is a big win for self sovereignty and for user agency and autonomy in digital identity. Adding it on to Wyoming’s work creates another model for how digital identity that maintains human dignity could spread across the United States.

If you want to help in this effort:

• If you’re in Utah, call up your state representatives and tell them that you support the bill. Maybe even express concerns about regulatory capture.
• If you’re in another state, call up your state representative and tell them of your interest in self-sovereign identity, offering Utah SB275, Wyoming SF39, and maybe Wyoming HB86 as model legislation.
• If you want to support our advocacy, become a GitHub sponsor or talk to me directly about supporting advocacy at a larger scale.

The work going on in Utah is great. But it’s just a start in supporting our digital rights!

At the time, I asked for support in refining those principals. And, we tried: at ID2020, Rebooting the Web of Trust, IIW, and elsewhere. But for nearly a decade, the original principles have remained largely unchanged, inspirational yet sometimes misunderstood.

Now, in 2025, as the Self-Sovereign Identity movement turns ten next year, I’m renewing that invitation. And I’m asking for your participation.

📌 The 10-Year Revision Project

The 10-year SSI Revision Project is an effort to revisit and refine the original SSI principles, not as a rigid standard, but as a living framework for people designing, governing, and deploying identity infrastructure that respects and protects the people it serves.

SSI is no longer a theory. Its infrastructure has been adopted by governments, companies, communities, and protocols. As that adoption accelerates, the foundational values must evolve to meet today’s ethical, legal, and technical challenges including coercion, use of biometrics, AI agency, exclusion by design, and gamified behavioral manipulation.

The goal is ultimately to revisit old principles and to propose new ones while making a renewed call to protect the dignity of all identity holders.

📅 Join the Collaboration

To support this project, I’ll be hosting a series of open online calls over the next year to co-develop and discuss revised principles, new proposals, and system guidance. These sessions will welcome technologists, designers, researchers, regulators, and community stewards from across the SSI and identity ecosystem.

Kickoff Meeting 1 — EU/US time compromise

• Tuesday, December 2nd, 2025
• 10:00am PT / 7:00pm CET

Kickoff Meeting 2 — EU/Tokyo time compromise

• Tuesday, December 9th, 2025 (Tokyo local)
• 3:00pm Tokyo / 7:00am CET / (10:00pm PT Monday for the host)

The goal of these first two meetings is to discuss opportunities for different topics, with the goal of writing up some initial rough “concept papers” (ala RWOT’s “topic papers”) to scope some of ideas that people have of what needs to be done.

Hopefully you’ll join us for these initial calls. No longer commitment is required, but the intent is to investigate your participation in writing some papers on this topic by May! However, the most important thing is ultimately that your ideas and your feedback help to shape the continued development of Self-Sovereign Identity.

Please let me know that you’re interested in joining us!

🧭 Team Topics

If we get enough participation, I expect we may split up into teams, to cover some of the various topics that bear discussion as we rethink SSI.

Some early broad topics that we are considering currently are:

1. Beyond Property: Principal Authority and the Legal Foundation of SSI. Agency law, principal authority, and revamping or expanding the SSI principles based on them.
2. Anti-Coercive Design and Cognitive Liberty. Avoiding coercive design, which will likely include more academic discussions of philosophy and may reveal new principles.
3. From Principles to Properties: Operationalizing SSI. A deep dive into the CSSPS 42-property framework published in IEEE Access, looking for objective design principles that might contribute to SSI. And forward from that.
4. More Than a Digital Shadow: Rewriting Principle 1 – Existence. Reclaiming the original intent of the first principle, that every person has an identity that precedes any digital system, drawing on generative identity, Ubuntu philosophy, feminist sovereignty, decolonial theory, legal personhood guarantees, and real-world harms.

The intent is to write articles on each of these topics, and hopefully some more, by May 2026, in time for the anniversary and to use those articles to revise, revamp, and expand the original principles. But to get there from here, we need to start coordinating now!

🌱 Why This Matters

SSI has always been more than a technical spec. It’s a movement for restoring dignity, agency, and trust in a digital world that too often erodes all three. As its adoption spreads, we must ensure that the principles at its foundation still serve the people they were meant to protect.

Let’s not let another ten years pass before we act.

📙 Requested Reading

I’ve written a number of articles about SSI over the years. I think three of them are particularly important to these discussions, and I suggest that people read them as part of this process:

• The Path to Self-Sovereign Identity (2016). My original article, which lays out the pre-history of SSI and the initial 10 principles.
• Origins of Self-Sovereign Identity (2021). A look at the philosophical and political roots of SSI, including its lineage in civil liberties, cryptographic activism, and human rights frameworks.
• Principal Authority: A New Perspective on Self-Sovereign Identity (2021). How identity should not be framed as property, but as a domain of agency governed by fiduciary duty and inalienable rights.

I am also working on an annotated syllabus of some of the most important papers and articles published the last 9 years. I’ll share my initial pass before our first meeting in December.

For more info on everything, see the Revisiting SSI website.

🤝🏼 Join Us

Some of the people that have expressed interest in joining us for this effort are Kim Hamilton Duffy (DIF), Rodolfo Costa (University of Coimbra), Georgy Ishmaev (Inria), Vinay Vasanji (EF), Ian Grigg, and Philip Sheldrake. This includes a mixture of both critics and supporters of SSI, coming from a variety of backgrounds, from academia to technology. What we are weak on so far are people from law and regulation.

You can email me directly and let me know you’d like to be involved, or sign up for an announcements-only #RevisitingSSI email list or alternatively join our Signal group, which we’ll be using to coordinate our initial calls.

If you or your organization wishes to demonstrate its support for goals of Self-Sovereign Identity, I am seeking financial sponsors for this project. Contact me about different sponsorship opportunities, or you can directly support my work on these kinds of efforts via GitHub (via a one-time donation or ongoing monthly patronage) at https://github.com/sponsors/ChristopherA.

I look forward to collaborating with you!

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.

It’s 2025. Digital infrastructure has become the heart of not just our economy, but our culture.

But it can be taken from us in a heart beat.

Those of us in the decentralized space have warned against this future for a long time, but it first hit me in a truly visceral way a decade ago when I was teaching technology leadership at Bainbridge Graduate Institute. I supported my students with a powerful coordination system that tied together del.icio.us bookmarks, Google Reader, and Google Docs. My students could discover information through RSS feeds, collaboratively bookmark and annotate it, and then work with their peers using that shared data. It was an effective tool for both learning and cooperative action that was soon adopted by the whole school.

But then Yahoo sold del.icio.us and Google shut down Reader. Without warning, without a chance to migrate, our learning community’s entire digital infrastructure collapsed. A generation of learners was quietly deplatformed from the tools that had empowered them to think, share, synthesize and learn together.

By now, everyone probably has a story of digital infrastructural loss. How they lost their Google+ circles. How their internet radio turned off forever one day. How their digitally stored MP3s disappeared into the ether. It’s a pattern that’s encouraged by the perverse incentives of capitalism. A useful service becomes essential infrastructure. Companies move in to collect rent on the technology. Then, they exert their power by reducing features and increasing distractions. Eventually, it becomes non-profitable and they kill it. (Cory Doctorow calls this pattern enshittification.)

Which leads to the question that haunts me: how can we create digital infrastructure that can’t be taken from us?

Enter the Exodus

To resolve this problem, we need what I call Exodus Protocols. These are systems that free us from the control of external sources (like Google or Yahoo! or Sony) by creating infrastructure that doesn’t require infrastructure.

What in the world do I mean by that?

There’s actually a well-known Exodus Protocol: Bitcoin. It provides financial infrastructure, allowing users to transfer value among themselves, but it does so without enshrining permanent infrastructure or empowering centralized authorities.

Miners can come and go. Full nodes can exist as services, but you can also spin them up locally. Some type of network is important for miners to collect transactions and form them into blocks, but the average user doesn’t need that: they can create their own transactions air-gapped and transfer them using QR codes. It’s generally hard to censor Bitcoin, and it would be unthinkable for the entirety of it to disappear in any short amount of time.

Bitcoin demonstrated something profound: that fundamental capabilities can exist as mathematical rights rather than centralized privileges. When your ability to transact depends on a bank’s approval, it’s not a right, it’s permission. Bitcoin restored transaction as a right through autonomous infrastructure. That’s an Exodus Protocol.

Unfortunately, Bitcoin only creates an Exodus Protocol for a small (but important) corner of what we do on the internet: value transfer. It does have some cousins, such as IPFS for data storage, but there aren’t great Exodus Protocols for the vast majority of what we do within the digital sphere. We need more Exodus Protocols, to free us from dependency on centralized services, so that our carefully constructed infrastructures don’t suddenly disappear, as happened for my students at BGI. We need to empower coordination (whether it be for my students or a board of directors), collaboration (at a forum or on a shared artists’ whiteboard), and identity (to correct the missteps made by the self-sovereign identity movement).

Five Patterns for Creating Autonomous Infrastructure

An Exodus Protocol is only successful if it’s designed to actually empower through autonomous service. We don’t want to just create a new digital prison. To design for success requires five architectural principles that help to create the architecture of autonomy itself.

An Exodus Protocol must …

1. Operate Without External Dependencies

If something requires permission to operate, it’s not autonomous. If it stops working when a company fails or a government objects, it’s infrastructure built on sand.

We instead need truly independent architecture. This can be accomplished either through objects that are self-contained, with everything needed for operation either within the object or derivable through math (e.g., autonomous cryptographic objects such as Gordian Clubs); or through distributed operations without centralization, where any operator can be replaced.

₿ — Bitcoin’s approach: Bitcoin took the distributed approach, with validation, verification, and recording of value transfers done by hundreds of thousands of replaceable independent nodes. There’s no central server or authority.

2. Encode Rules in Mathematics, Not Policy

Policy means that someone else decides how a service works. They can make arbitrary or biased decisions. They can succumb to coercion, and they can censor.

In contrast, math doesn’t discriminate, doesn’t take sides, and doesn’t change its mind under pressure. Replacing policy rules with mathematical rules means introducing cryptographic proofs such as private keys and signatures. They make verification deterministic: the same inputs always produce the same outputs.

₿ — Bitcoin’s approach: With Bitcoin, the control of value is ultimately determined by who holds a private key. Sophisticated systems such as threshold signatures and secret sharding offer more nuanced control.

3. Make Constraints Load-Bearing

Constraints make systems less flexible. But, that’s not necessarily a bad thing. We just need to ensure that those constraints serve dual purposes by also supporting a system’s autonomy.

We must be aware of what constraints mean: how they’re helpful and how they’re harmful. Then we must design constraints that create the autonomous infrastructure that we want. As an example: if a credential can’t expire, then it works forever. Similarly, if it can’t be revoked, then it offers perfect access to past content.

₿ — Bitcoin’s approach: Bitcoin offers a number of constraints that strengthen its autonomy largely by building upon mathematics rather than arbitrary policy. Transactions can’t be reversed, which means: 🟥 that you can’t walk back a mistake; but also that 🟢 your funds can’t be seized by fiat. Rules changes require consensus, which means: 🟥 that important updates can require months or years of coordination; but also that 🟢 your funds can’t be threatened by an arbitrary increase of supplies.

4. Preserve Exit Through Portability

Centralized systems lock you in, which is the opposite of sovereignty. True autonomy requires not just the ability to leave, but the ability to take everything with you. Without the ability to walk away, consent collapses into coercion.

Escaping lock in requires interoperability and open standards. Data and credentials must be portable across implementations without proprietary formats that trap users.

₿ — Bitcoin’s approach: Bitcoin keys work in any wallet. Standards for the use of seeds to generate HD keys and the use of wallet descriptors further this interoperability.

5. Work Offline and Across Time

Infrastructure that requires connectivity can be denied connectivity. Infrastructure that requires specific platforms can be denied those platforms.

True autonomy works with whatever channels remain available when coercion attempts to deny others. It requires asynchronous operations, creating services that work during outages and across decades regardless of infrastructural changes.

₿ — Bitcoin’s approach: Bitcoin transactions can be signed offline and broadcast later. The protocol doesn’t care about internet connectivity for core operations.

Foundation, Not Fiat

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.

Exodus Technology

Early in the month, I introduced Gordian Clubs. They’re another example of the Exodus Protocols that I discuss in this article.

Here’s how Gordian Clubs, which are Autonomous Cryptographic Objects (ACOs) that can be used to coordinate (by sharing data) and collaborate (by updating data), fulfill the five patterns.

(This is a repeat of a list from the Gordian Clubs article.)

Gordian Clubs …

1. Operate Without External Dependencies. Everything you need is within the Gordian Club: data and permissions truly operate autonomously.
2. Encode Rules in Mathematics, Not Policy. Permits are accessed through mathematical (cryptographic) constructs such as private keys or secret shares.
3. Make Constraints Load-Bearing. Members can’t be removed from a Gordian Club Edition, but that also means permissions can’t be unilaterally revoked. Gordon Clubs don’t have live interactivity, but that means they can’t be censored by a network.
4. Preserve Exit Through Portability. An ACO that can be freely passed around without network infrastructure is the definition of portability.
5. Work Offline and Across Time. Gordian Clubs are meant to be used offline; archival is a major use case, allowing access across a large span of time.

There are numerous other technologies that can enable Exodus Protocols. Many of them are puzzle pieces that could be adopted into larger scale solutions. These include:

• QR Codes. Data that can be printed or displayed on air-gapped devices and that can be automatically read into other systems.
• Bluetooth. Another method for transmitting data when networks are down.
• Threshold Signatures. A method of coordination (signing) that typically does not require live interactivity.

Though we haven’t previously used the term, Blockchain Commons technologies are often built as Exodus Protocols:

• Animated QRs. Animation extends QRs to allow the automated transmission and reading of larger quantities of data.
• Gordian Envelope. Envelopes are built to allow selective disclosure of information without a network. They’re the foundation of Gordian Clubs.
• XID. Also built atop Gordian Envelope, XIDs (eXtensible IDentifiers) are decentralized identifiers that are truly autonomous, avoiding the failures of the SSI ecosystem.

From Five Patterns to Six Inversions

The threat of our digital infrastructure being taken away from us is part of a larger issue that I call “The Six Inversions.” It’s the systematic transformation of rights into revokable privileges in the digital world.

In the physical world, we have property rights that assure us of access to infrastructure, but in the digital world, centralized entities can take away that infrastructure at any time for any reason. We have no rights to property, to justice, to transparency, or to exit. Our contractual power is neutered, and our identity is sold. As a result, digital infrastructure is unstable, which is why we need to create infrastructure without infrastructure, in the form of Exodus Protocols.

I’ll write more about the Six Inversions in the future, but for the moment I wanted to point it out as an underlying philosophy for why digital infrastructure is unreliable and must be reimagined.

It’s because we don’t have the rights that we expect from the physical world.

Conclusion

As I said, Exodus Protocols aren’t for everyone or everything, but there are situations and services where they’re critical.

When we’ve identified these cases, we can then deploy Exodous Protocol patterns: operating without dependencies, encoding rules in mathematics, making constraints load-bearing, preserving exit through portability, and working offline across time. This creates a blueprint for infrastructure that holds when everything else fails.

What is your critical infrastructure? What have you spent years building and would be hurt without? What infrastructure’s loss would damage your ability to identify yourself, to communicate, to cooperate, or to collaborate? I’d love to hear what they are and to work with you to design the next generation of autonomous infrastructure.

Bitcoin is just the beginning.