Web3, Coherence, and Platform Sovereignty


In The crypto-communists behind the Web3 revolution, Benjamin Pimentel argues that "The future of decentralized finance echoes a decidedly Marxist vision of the future." He references various Silicon Valley icons like Jack Dorsey, Marc Andreessen, Elon Musk, and others, comparing their statements on Web3 and crypto with the ideology of communism. He references Tom Goldberg's essay exploring the similarities between Karl Marx and Nakamoto Satoshi:

"Marx advocated for a stateless system, where the worker controlled the means of production," [Goldberg] said. "Satoshi sought to remove financial intermediaries — the banks and credit card companies that controlled the world's flow of value."

But while Marx and Satoshi both "articulated a reasoned, well-thought-out vision of the future," Goldenberg added, "neither had the power to predict how their ideas would influence others or be implemented. And neither could control their own creations."

And, among other things, compares Musk to Lenin:

But Musk and Lenin seem simpatico when it comes to the "ultimate aim of abolishing the state" (Lenin): "Just delete them all," Musk recently said, of the government subsidies that have historically sustained his firms. (Perhaps he's studied Mao Zedong's essay "On Contradiction.")

"So long as the state exists there is no freedom," Lenin declared. "When there is freedom, there will be no state."

All in all, it's an interesting read with lots to think about. But what really made it speak to me is that I've also been reading The Stack: On Software and Sovereignty by Benjamin Bratton, the Director of the Center for Design and Geopolitics at the University of California, San Diego. I won't lie; the book is, for a non-sociologist like me, a tough read. Still, I keep going cause there are so many interesting ideas in it.

Relevant to the crypto-communist article is the idea of platform sovereignty. Bratton references Carl Schmitt's arguments on the relationship between political epochs and spatial subdivision. As Bratton says there is "no stable geopolitical order without an underlying architecture of spatial subdivision" and "no geography without first topology."

Here's his insight on the heterarchical relationship between markets and states

[O]ne of the things that makes neoliberalism unique is that markets do not operate in conjunction with or in conflict with sovereign states, but rather that sovereignty is itself shifted from states into markets.

The point here is that markets and states co-exist, influencing each other. And that sovereignty can shift. Both are ways of creating coherence among participants. I think that's a good way to explore what Bratton means when he talks about platform sovereignty.

One of the important ideas in The Stack is that platforms rarely replace each other. Rather, they co-exist, strengthening or diminishing other platforms. Market's didn't do away with states—even as they stole attention and power from them. And, the internet didn't do away with either. The degree of sovereignty these platforms and their Users (in Bratton's terminology) enjoy depends on a variety of factors, but it most assuredly doesn't rely wholly on permission from other platforms.

In this worldview, there are innumerable platforms, not nicely contained within each other, but stacked willy-nilly with overlapping boundaries. Schmitt was primarily interested in geopolitical boundaries that played out in the Westphalian regime1. Bratton recognizes that one thing networks have given us is lots of boundaries, each one giving rise to sovereignty of various forms and in different degrees.

While many focus on what Doc Searls calls "vendor sports" and talk about which platform triumphs over another, Bratton's view is that when you stop looking at platforms in a specific type or category, there's not necessarily competition, and less so, the means of control between them that would ensure the ascendance and triumph of one over the other. Each is a social system with its own participants, rules, and goals.

Social systems that are enduring, scalable, and generative require coherence among participants. Coherence allows us to manage complexity. Coherence is necessary for any group of people to cooperate. The coherence necessary to create the internet came in part from standards, but more from the actions of people who created organizations, established those standards, ran services, and set up exchange points.

Coherence enables a group of people to operate with one mind about some set of ideas, processes, and outcomes. We only know of a few ways of creating coherence in social systems: tribes, institutions, markets, and networks2. Startups, for example, work as tribes. When there's only a small set of people, a strong leader can clearly communicate ideas and put incentives—and disincentives—in place. Coherence is the result. As companies grow, they become institutions that rely on rules and bureaucracy to establish coherence. While a strong leader is important, institutions are more about the organization than the personalities involved. Tribes and institutions are centralized--someone or some organization is making it all happen. More to the point, institutions rely on hierarchy to achieve coherence.

Markets are decentralized—specifically they are heterarchical rather than hierarchical. A set of rules, perhaps evolved over time through countless interactions, govern interactions and market participants are incented by market forces driven by economic opportunity to abide by the rules. Competition among private interests (hopefully behaving fairly and freely) allows multiple players with their own agendas to process complex transactions around a diverse set of interests.

Networks are also decentralized. Most of the platforms we see emerging today are networks of some kind. The rules of interaction in networked platforms are set in protocol. But protocol alone is not enough. Defining a protocol doesn't string cable or set up routers. There's something more to it.

As we've said, one form of organization doesn't usually supplant the previous, but augments it. The internet is the result of a mix of institutional, market-driven, and network-enabled forces. The internet has endured and functions because these forces, whether by design or luck, are sufficient to create the coherence necessary to turn the idea of a global, public decentralized communications system into a real network that routes packets from place to place. The same can be said for any other enduring platform.

Funny, it was Marc Andreessen, one of Pimentel's crypto-communists, who introduced me to Neal Stephenson's Snow Crash in 1999. Snow Crash is set in a world where various network platforms co-exist with much-diminished nation states, a metaverse, and each other, molding the geopolitical landscape of the novel to the extent they engender coherence in their various Users.

So, while Pimentel's article is interesting and informative in comparing the stated aspirations of crypto-enthusiasts and communists, I think the more correct view is that crypto isn't going to replace anything—we're not headed to a crypto-communist future. Rather it's going to add more platforms that influence, but don't displace, the things that came before. And those who see Web3 as a passing fad will likely be disappointed that it refuses to die—so long it generates networked platforms that creates sufficient coherence among their Users.

Books Mentioned

The Stack: On Software and Sovereignty by Benjamin H. Bratton

A comprehensive political and design theory of planetary-scale computation proposing that The Stack—an accidental megastructure—is both a technological apparatus and a model for a new geopolitical architecture. What has planetary-scale computation done to our geopolitical realities? It takes different forms at different scales—from energy and mineral sourcing and subterranean cloud infrastructure to urban software and massive universal addressing systems; from interfaces drawn by the augmentation of the hand and eye to users identified by self—quantification and the arrival of legions of sensors, algorithms, and robots. Together, how do these distort and deform modern political geographies and produce new territories in their own image?

Snow Crash by Neal Stephenson

In reality, Hiro Protagonist delivers pizza for Uncle Enzo’s CosoNostra Pizza Inc., but in the Metaverse he’s a warrior prince. Plunging headlong into the enigma of a new computer virus that’s striking down hackers everywhere, he races along the neon-lit streets on a search-and-destroy mission for the shadowy virtual villain threatening to bring about infocalypse. • In this mind-altering romp—where the term "Metaverse" was first coined—you'll experience a future America so bizarre, so outrageous, you'll recognize it immediately • One of Time's 100 best English-language novels.

The Shield of Achilles: War, Peace, and the Course of History by Philip Bobbitt

For five centuries, the State has evolved according to epoch-making cycles of war and peace. But now our world has changed irrevocably. What faces us in this era of fear and uncertainty? How do we protect ourselves against war machines that can penetrate the defenses of any state? Visionary and prophetic, The Shield of Achilles looks back at history, at the “Long War” of 1914-1990, and at the future: the death of the nation-state and the birth of a new kind of conflict without precedent.


  1. For a deep dive into Westphalean "princely states" and their evolution into modern nation states, I can't recommend strongly enough Philip Bobbit's The Shield of Achilles: War, Peace, and the Course of History.
  2. To explore this more, see this John Robb commentary on David Ronfeldt's Rand Corporation paper "Tribes, Institutions, Markets, Networks" (PDF).

Photo Credit: Lenin from Arkady Rylov via Wikimedia Commons (CC0)

Web3 and Digital Embodiment

The ghost of Taira Tomomori, Daimotsu bay

Tim O'Reilly recently published Why it’s too early to get excited about Web3, an excellent discussion on industrial transformation and the role that bubbles play. He used this historical lens to look at Web3 and where we might be with all of it.

One of Tim's points is that we fluctuate between decentralized and centralized models, using Clayton Christensen's law of conservation of attractive profits to show why this happens. He says:

I love the idealism of the Web3 vision, but we’ve been there before. During my career, we have gone through several cycles of decentralization and recentralization. The personal computer decentralized computing by providing a commodity PC architecture that anyone could build and that no one controlled. But Microsoft figured out how to recentralize the industry around a proprietary operating system. Open source software, the internet, and the World Wide Web broke the stranglehold of proprietary software with free software and open protocols, but within a few decades, Google, Amazon, and others had built huge new monopolies founded on big data.

Tim's broader point is that while there's a lot of promise, the applications that deliver a decentralized experience for most people just aren't there yet. Enthusiasts like to focus on decentralized finance or "DeFi" but I (and I think Tim) don't think that's enough. While centralized payments are a big part of the problem, I don't think it's the most fundamental. The most fundamental problem is that people have no place to stand in the modern web. They are not digitally embodied.

In Why Web3?, Fred Wilson, who has as deep an understanding of how the underlying technology works as anyone, explains it like this:

It all comes down to the database that sits behind an application. If that database is controlled by a single entity (think company, think big tech), then enormous market power accrues to the owner/administrator of that database.

This is why I think identity is the most fundamental building block for Web3 and one that's not being talked about enough yet. Identity is the ability to recognize, remember, and react to people, organizations, systems, and things. In the current web, companies employ many ponderous technological systems to perform those functions. I don't just mean their authentication and authorization systems, the things we normally associate with identity, but everything they use to create a relationship with their customers, partners, and employees—think of the CRM system, as just one example.

In these systems, we are like ghosts in the machines. We have "accounts" in companies' systems, but no good way to recognize, remember, and react to them or anyone else. Self-sovereign identity (SSI) gives people the software and systems to do that. Once we can recognize, remember, and react to others online (with software we control, not just through the fragmented interfaces of our mobile devices) we become digitally embodied, able to take action on our own.

With SSI, Fred's application databases are decentralized. That's not to say that companies won't continue to have systems for keeping track of who they interact with. But we'll finally have systems to keep track of them as well. More importantly, we get ways to interact with each other without having to be in their systems. That's the most important thing of all.

I've no doubt that there will be adjacent areas with attractive profits that lead to other forms of centralization, as Tim suggests. But, SSI, DeFi, and other Web3 technologies change the structure of online interaction in ways that will be difficult to undo. SSI, more specifically DIDComm, creates a secure, identity-enabled, privacy-respecting messaging overlay on top of the internet. This changes the game in important ways that level the playing field and creates a new layer where applications can be built that naturally respect human dignity and autonomy.

That doesn't mean that non-interoperable and non-substitutable applications won't emerge. After all, Google, Facebook, Apple, Amazon, and others became dominant through network effects and there's nothing about Web3 that reduces those. The only thing that does is continued work on standards and interoperability along with our insistence on digital rights for people. We're all a part of that effort. As I tell my students: Build the world you want to live in.

Photo Credit: Kuniyoshi Utagawa, The ghost of Taira Tomomori, Daimotsu bay from Kuniyoshi Utagawa (CC0)

Leveraging the Identity Metasystem

Archimedes Lever

I recently saw the following tweet (since deleted):

Origin Trail and Vaccine NFTs

Soooo many questions:

  • Would a vaccination status NFT be transferable (a core feature of most NFTs)?
  • What's the underlying platform's security?
  • How's the smart contract written?
  • Who has control?
  • How do identifiers work in this system?
  • What are the privacy implications?
  • How much PII is on the blockchain?

Answering these questions would require significant work. And that work might have to be redone for each NFT used for SSI, depending on how Origin Trail is architected. If they are based on ERC-721, that tells us some things we may need to know, but doesn't answer most of the questions I pose above. If Origin Trail runs its own blockchain, then there are even more questions.

One of the big value propositions of an identity metasystem is that many of these questions can be answered once for the metasystem rather than answering them for each identity system built on top of it. In particular, the metasystem guarantees the fidelity of the credential exchange. Credential fidelity comprises four important attributes. Credential exchange on the identity metasystem:

  1. Reveals the identifier of the issuer
  2. Ensures the credential was issued to the party presenting it
  3. Ensures the credential has not been tampered with
  4. Reveals whether or not the credential has been revoked

I don't know anything about Origin Trail. It's possible that they have worked all this out. The point is simply that the tweet caused me to think about the advantages of a metasystem.

Metasystems give us leverage because their known behavior makes reasoning about systems built on top of them easier. Knowing how TCP works lets us know important properties of the protocols that operate on top of it. Similarly, in the identity metasystem, knowing how DIDs, DID Registries, DIDComm, and verifiable credential exchange protocols function means that we can more easily understand the behavior of a system built on top of it, like the health pass ecosystem. This leverage is an important component of the network effects that a well designed metasystem can provide.

Photo Credit: Archimedes Lever from ZDF/Terra X/Gruppe 5/ Susanne Utzt, Cristina Trebbi/ Jens Boeck, Dieter Stürmer / Fabian Wienke / Sebastian Martinez/ xkopp, polloq (CC BY 4.0)

In Memory of Kim Cameron

Kim Cameron speaking at EIC in 2018

I got word early last week that Kim Cameron, a giant of the identity world, had passed away. I was shocked. I still am. Kim was one of those people who played such a big role in my life over so many years, that it's hard to imagine he's not there any more. The week before we'd been scheduled to talk and he'd canceled cause he wasn't feeling well. He wanted to talk about verifiable credential exchange over OpenID Connect SIOP. He was still in the trenches...working on identity. I'm sad we'll never get that last talk.

I had met Kim and talked to him at several identity conferences back in the early 2000's. But my relationship with him grew into friendship through Internet Identity Workshop (IIW). We held the first IIW in October 2005. Along with many others, Kim was there to talk about his ideas and plans for identity. He'd already published his Laws of Identity and was working on a project called Information Cards.

At that first IIW, we went to dinner at the end of day one. The idea was that everyone would pay for their own meal since the workshop hadn't collected any money in the registration for that. Kim, with his typical generosity, told everyone that Microsoft would buy dinner...and drinks. Later he confided to me that he wasn't sure Microsoft would really pick up the tab—which turned out to be surprisingly large because of the alcohol—but he'd make sure it was covered either way. That started a tradition. Microsoft has sponsored the workshop dinner at every in-person IIW we've held. Not only with dinner, but in countless other ways, Kim's participation and support was instrumental in building IIW over the years.

Kim Cameron at IIW in 2006

Over the last several years I've remarked several times that Kim must be a being from the future. With his laws, Kim was telling us things about identity in 2004 that we weren't ready to hear until just the last few years. Kim not only saw the need for a set of laws to govern online identity system architecture, but also foresaw the need for an identity metasystem on the internet. Whether you view the laws as leading to the metasystem design or springing from it, they are both necessary to a future where people can live rich, authentic online lives. The laws are Kim's legacy in the identity world.

Kim's technical excellence got him a seat at the table. His position at Microsoft gave him a big voice. But what made Kim effective was his gentle approach to technical discussions, especially those he thought might be contentious. He listened, asked questions, and guided discussion. As a result of his leadership we made progress in many ways that might not have otherwise happened. The identity world will sorely miss his leadership. I will miss his company, learning from him, and, most of all, his friendship.

Other tributes to Kim can be found in these links:

Photo Credit: Photos of Kim Cameron from Doc Searls (CC BY 2.0)

Digital Memories

Supermarket counter

In a recent thread on the VRM mailing list, StJohn Deakins of Citizen Me shared a formulation of interactions that I thought was helpful in unpacking the discussions about data, identity, and ownership. His framework concerns analog vs digital memories.

In real life, we often interact with others—both people and institutions—with relative anonymity. For example, if I go the store and use cash to buy a coke there is no exchange of identity information. If I use a credit card it's rarely the case that the entire transaction happens under the administrative authority of the identity system inherent in the credit card. Only the financial part of the transaction takes place in that identity system. This is true of most interactions in real life.

In this situation, the cashier, others in the store, and I all share a common experience. Even so, we each retain our own memories of the interaction. No one participating would claim to "own" the interaction. But we all retain memories which are our own. There is no single "true" record of the interaction. Every participant will have a different perspective (literally).

On the other hand, the store, as an institution, retains a memory of having sold a coke and the credit card transaction. This digital memory of the transaction can easily persist longer than any of the analog memories of the event. Because it is a digital record we trust it and tend to think of it as "true." For some purposes, say proving in a court of law that I was in the store at a particular time, this is certainly true. But for other purposes (e.g. was the cashier friendly or rude?) the digital memory is woefully anemic.

Online, we only have digital memories. And people have very few tools for saving, managing, recalling, and using them. I think digital memories are one of the primary features of digital embodiment—giving people a place to stand in the digital world, their own perspective, memories, and capacity to act. We can't be peers online without having our own digital memories.

StJohn calls this the "analog-digital memory divide." This divide is one source of the power imbalance between people and administrative entities (i.e. anyone who has a record of you in an account). CitizenMe provides tools for people to manage digital memories. People retain their own digital memory of the event. While every participant has a similar digital memory of the event, they can all be different, reflecting different vantage points.

One of the recent trends in application development is microservices, with an attendant denormalization of data. The realization that there doesn't have to be, indeed often can't be, a single source of truth for data has freed application development from the strictures of centralization and led to more easily built and operated distributed applications that are resilient and scale. I think this same idea applies to digital interactions generally. Freeing ourselves from the mindset that digital systems can and should provide a single record that is "true" will lead to more autonomy and richer interactions.

Self-sovereign identity (SSI) provides a foundation for our digital personhood and allows us to not only taking charge of our digital memories but operationalize all of our digital relationships. Enriching the digital memories of events by allowing everyone their own perspective (i.e. making them self-sovereign) will lead to a digital world that is more like real life.


  • Ephemeral Relationships—Many of the relationships we have online don’t have to be long-lived. Ephemeral relationships, offering virtual anonymity, are technically possible without a loss of functionality or convenience. Why don’t they exist? Surveillance is profitable.
  • Fluid Multi-Pseudonymity—Fluid multi-pseudonymity perfectly describes the way we live our lives and the reality that identity systems must realize if we are to live authentically in the digital sphere.
  • Can the Digital Future Be Our Home?—This post features three fantastic books from three great, but quite different, authors on the subject of Big Tech, surveillance capitalism, and what's to be done about it.

Photo Credit: Counter Supermarket Product Shopping Shop Grocery from maxpixel (CC0)

Zero Knowledge Proofs

Under 25? Please be prepared to show proof of age when buying alcohol

Suppose Peggy needs to prove to Victor that she is in possession of a secret without revealing the secret. Can she do so in a way that convinces Victor that she really does know the secret? This is the question at the heart of one of the most powerful cryptographic processes we can employ in identity systems: zero-knowledge proofs (ZKPs). Suppose for example that Peggy has a digital driver's license and wants to prove to Victor, the bartender, that she's over 21 without just handing over her driver's license or even showing him her birthdate. ZKPs allow Peggy to prove her driver's license says she's at least 21 in a way that convinces Victor without Peggy having to reveal anything else (i.e., there's zero excess knowledge).

This problem was first explored by MIT researchers Shafi Goldwasser, Silvio Micali and Charles Rackoff in the 1980s as a way of combatting information leakage. The goal is to reduce the amount of extra information the verifier, Victor, can learn about the prover, Peggy.

One way to understand how ZKPs work is the story of the Cave of Alibaba, first published by cryptographers Quisquater, Guillou, and Berson1. The following diagram provides an illustration.

Peggy and Victor in Alibaba's Cave
Peggy and Victor in Alibaba's Cave (click to enlarge)

The Cave of Alibaba has two passages, labeled A and B, that split off a single passageway connected to the entrance. Peggy possesses a secret code that allows her to unlock a door connecting A and B. Victor wants to buy the code but won't pay until he's sure Peggy knows it. Peggy won't share it with Victor until he pays.

The algorithm for Peggy proving she knows the code proceeds as follows:

  • Victor stands outside the cave while Peggy enters and selects one of the passages. Victor is not allowed to see which path Peggy takes.
  • Victor enters the cave and calls out "A" or "B" at random.
  • Peggy emerges from the correct passageway because she can easily unlock the door regardless of which choice she made when entering.
  • Of course, Peggy could have just gotten lucky and guessed right, so Peggy and Victor repeat the experiment many times.

If Peggy can always come back by whichever passageway Victor selects, then there is an increasing probability that Peggy really knows the code. After 20 tries, there's less than one chance in a million that Peggy is simply guessing which letter Victor will call. This constitutes a probabilistic proof that Peggy knows the secret.

This algorithm not only allows Peggy to convince Victor she knows the code, but it does it in a way that ensures Victor can't convince anyone else Peggy knows the code. Suppose Victor records the entire transaction. The only thing an observer sees is Victor calling out letters and Peggy emerging from the right tunnel. The observer can't be sure Victor and Peggy didn't agree on a sequence of letters in advance to fool observers. Note that this property relies on the algorithm using a good pseudo-random number generator with a high-entropy seed so that Peggy and third-party observers can't predict Victor's choices.

Thus, while Peggy cannot deny to Victor that she knows the secret, she can deny that she knows the secret to other third parties. This ensures that anything she proves to Victor stays between them and Victor cannot leak it—at least in a cryptographic way that proves it came from Peggy. Peggy retains control of both her secret and the fact that she knows it.

When we say "zero knowledge" and talk about Victor learning nothing beyond the proposition in question, that's not perfectly true. In the cave of Alibaba, Peggy proves in zero knowledge that she knows the secret. But there are many other things that Victor learns about Peggy that ZKPs can do nothing about. For example, Victor knows that Peggy can hear him, speaks his language, walk, and is cooperative. He also might learn things about the cave, like approximately how long it takes to unlock the door. Peggy learns similar things about Victor. So, the reality is that the proof is approximately zero knowledge not perfectly zero knowledge.

ZKP Systems

The example of Alibaba's Cave is a very specific use of ZKPs, what's called a zero-knowledge proof of knowledge. Peggy is proving she knows (or possesses something). More generally, Peggy might want to prove many facts to Victor. These could include propositional phrases or even values. ZKPs can do that as well.

To understand how we can prove propositions in zero knowledge, consider a different example, sometimes called the Socialist Millionaire Problem. Suppose Peggy and Victor want to know if they're being paid a fair wage. Specifically, they want to know whether they are paid the same amount, but don't want to disclose their specific hourly rate to each other or even a trusted third party. In this instance, Peggy isn't proving she knows a secret, rather, she's proving an equality (or inequality) proposition.

For simplicity, assume that Peggy and Victor are being paid one of $10, $20, $30, or $40 per hour. The algorithm works like this:

  • Peggy buys four lock boxes and labels them $10, $20, $30, and $40.
  • She throws away the keys to every box except the one labeled with her wage.
  • Peggy gives all the locked boxes to Victor who privately puts a slip of paper with a "+" into the slot at the top of the box labeled with his salary. He puts a slip with a "-" in all the other boxes.
  • Victor gives the boxes back to Peggy who uses her key in private to open the box with her salary on it.
  • If she finds a "+" then they make the same amount. Otherwise, they make a different amount. She can use this to prove the fact to Victor.

This is called an oblivious transfer and proves the proposition VictorSalary = PeggySalary true or false in zero knowledge (i.e., without revealing any other information).

For this to work, Peggy and Victor must trust that the other will be forthcoming and state their real salary. Victor needs to trust that Peggy will throw away the three other keys. Peggy must trust that Victor will put only one slip with a "+" on it in the boxes.

Just like digital certificates need a PKI to establish confidence beyond what would be possible with self-issued certificates alone, ZKPs are more powerful in a system that allows Peggy and Victor to prove facts from things others say about them, not just what they say about themselves. For example, rather than Peggy and Victor self-asserting their salary, suppose they could rely on a signed document from the HR department in making their assertion so that both know that the other is stating their true salary. Verifiable Credentials provide a system for using ZKPs to prove many different facts alone or in concert, in ways that give confidence in the method and trust in the data.

Non-Interactive ZKPs

In the previous examples, Peggy was able to prove things to Victor through a series of interactions. For ZKPs to be practical, interactions between the prover and the verifier should be minimal. Fortunately, a technique called SNARK allows for non-interactive zero knowledge proofs.

SNARKs have the following properties (from whence they derive their name):

  • Succinct: the sizes of the messages are small compared to the length of the actual proof.
  • Non-interactive: other than some setup, the prover sends only one message to the verifier.
  • ARguments: this is really an argument that something is correct, not a proof as we understand it mathematically. Specifically, the prover theoretically could prove false statements given enough computational power. So, SNARKs are "computationally sound" rather than "perfectly sound".
  • of Knowledge: the prover knows the fact in question.

You'll typically see "zk" (for zero-knowledge) tacked on the front to indicate that during this process, the verifier learns nothing other than the facts being proved.

The mathematics underlying zkSNARKs involves homomorphic computation over high-degree polynomials. But we can understand how zkSNARKs work without knowing the underlying mathematics that ensures that they're sound. If you'd like more details of the mathematics, I recommend Christian Reitwiessner's "zkSNARKs in a Nutshell".

As a simple example, suppose Victor is given a sha256 hash, H, of some value. Peggy wants to prove that she knows a value s such that sha265(s) == H without revealing s to Victor. We can define a function C that captures the relationship:

C(x, w) = ( sha256(w) == x )

So, C(H, s) == true, while other values for w will return false.

Computing a zkSNARK requires three functions G, P, and V. G is the key generator that takes a secret parameter called lambda and the function C and generates two public keys, the proving key pk and the verification key vk. They need only be generated once for a given function C. The parameter lambda must be destroyed after this step since it is not needed again and anyone who has it can generate fake proofs.

The prover function P takes as input the proving key pk, a public input x, and a private (secret) witness w. The result of executing P(pk,x,w) is a proof, prf, that the prover knows a value for w that satisfies C.

The verifier function V computes V(vk, x, prf) which is true if the proof prf is correct and false otherwise.

Returning to Peggy and Victor, Victor chooses a function C representing what he wants Peggy to prove, creates a random number lambda, and runs G to generate the proving and verification keys:

(pk, vk) = G(C, lambda)

Peggy must not learn the value of lambda. Victor shares C, pk, and vk with Peggy.

Peggy wants to prove she knows the value s that satisfies C for x = H. She runs the proving function P using these values as inputs:

prf = P(pk, H, s)

Peggy presents the proof prf to Victor who runs the verification function:

V(vk, H, prf)

If the result is true, then the Victor can be assured that Peggy knows the value s.

The function C does not need to be limited to a hash as we did in this example. Within limits of the underlying mathematics, C can be quite complicated and involve any number of values that Victor would like Peggy to prove, all at one time.


  1. Quisquater, Jean-Jacques; Guillou, Louis C.; Berson, Thomas A. (1990). How to Explain Zero-Knowledge Protocols to Your Children (PDF). Advances in Cryptology – CRYPTO '89: Proceedings. Lecture Notes in Computer Science. 435. pp. 628–631. doi:10.1007/0-387-34805-0_60. ISBN 978-0-387-97317-3.

Photo Credit: Under 25? Please be prepared to show proof of age when buying alcohol from Gordon Joly (CC BY-SA 2.0)

Identity and Consistent User Experience

Using a wallet

The other day Lynne called me up and asked a seemingly innocuous question: "How do I share this video?" Ten years ago, the answer would have been easy: copy the URL and send it to them. Now...not so much. In order to answer that question I first had to determine which app she was using. And, since I wasn't that familiar with it, open it and search through the user interface to find the share button.

One of the features of web browsers that we don't appreciate as much as we should is the consistent user experience that the browser provides. Tabs, address bars, the back button, reloading and other features are largely the same regardless of which browser you use. There's a reason why don't break the back button! was a common tip for web designers over the years. People depend on the web's consistent user experience.

Alas, apps have changed all that. Apps freed developers from the strictures of the web. No doubt there's been some excellent uses of this freedom, but what we've lost is consistency in core user experiences. That's unfortunate.

The web, and the internet for that matter, never had a consistent user experience for authentication. At least not one that caught on. Consequently, the user experience is very fragmented. Even so, Kim Cameron's Seven Laws of Identity speaks for consistent user experience in Law 7: Consistent Experience Across Contexts. Kim says:

The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.

Think about logging into various websites and apps throughout your day. You probably do it way too often. But it's also made much more complex because it's slightly different everywhere. Different locations and modalities, different rules for passwords, different methods for 2FA, and so on. It's maddening.

There's a saying in security: "Don't roll your own crypto." I think we need a corollary in identity: "Don't roll your own interface." But how do we do that? And what should the interface be? One answer is to adopt the user experience people already understand from the physical world: connections and credentials.

Kim Cameron gave us a model back in 2005 when he introduced Information Cards. Information cards are digital analogs of the credentials we all carry around in the physical world. People understand credentials. Information cards worked on a protocol-mediated identity metasystem so that anyone could use them and write software for them.

Information cards didn't make it, but the ideas underlying information cards live on in modern self-sovereign identity (SSI) systems. The user experience in SSI springs from the protocol embodied in the identity metasystem. In an SSI system, people use wallets that manage connections and credentials. They can create relationships with other people, organizations, and things. And they receive credentials from other participants and present those credentials to transfer information about themselves in a trustworthy manner. They don't see keys, passwords, authentication codes, and other artifacts of the ad hoc identity systems in widespread use today. Rather they use familiar artifacts to interact with others in ways that feel familiar because they are similar to how identity works in the physical world.

This idea feels simple and obvious, but I think that conceals its incredible power. Having a wallet I control where I manage digital relationships and credentials gives me a place to stand in the digital world and operationalize my digital life. I think of it as digital embodiment. An SSI wallet gives me an interoperable way to connect and interact with others online as me. I can create both rich, long-lived relationships and service short-lived, ephemeral relationships with whatever degree of trustworthy data is appropriate for the relationship and its context.

Relationships and Interactions in SSI
Relationships and Interactions in SSI (click to enlarge)

We have plenty of online relationships today, but they are not operational because we are prevented from acting by their anemic natures. Our helplessness is the result of the power imbalance that is inherent in bureaucratic relationships. The solution to the anemic relationships created by administrative identity systems is to provide people with the tools they need to operationalize their self-sovereign authority and act as peers with others online. Consistent user experience is a key enabler of digital embodiment. When we dine at a restaurant or shop at a store in the physical world, we do not do so within some administrative system. Rather, as embodied agents, we operationalize our relationships, whether they be long-lived or nascent, by acting for ourselves. The SSI wallet is the platform upon which people can stand and become embodied online to operationalize their digital life as full-fledged participants in the digital realm.

Photo Credit: Red leather wallet on white paper from Pikrepo (CC0)

Picos at the Edge


Rainbow's End is one of my favorite books. A work of fiction, Rainbow's End imagines life in a near future world where augmented reality and pervasive IoT technology are the fabric within which people live their lives. This book, from 2006, is perhaps where I first began to understand the nature and importance of computing at the edge. A world where computing is ambient and immersive can't rely only on computers in the cloud.

We have significant edge computing now in the form of powerful mobile devices, but that computing is not shared without roundtrips to centralized cloud computing. One of the key components of 5G technology is compute and storage at the edge—on the cell towers themselves— that distributes computing and reduces latency. Akamai, CloudFront, and others have provided these services for years, but still in a data center somewhere. 5G moves it right to the pole in your backyard.

But the vision I've had since reading Rainbow's End is not just distributed, but decentralized, edge computing. Imagine your persistent compute jobs in interoperable containers moving around a mesh of compute engines that live on phones, laptops, servers, or anywhere else where spare cycles exist.

IPFS does this for storage, decentralizing file storage by putting files in shared spaces at the edge. With IPFS, people act as user-operators to host and receive content in a peer-to-peer manner. If a file gets more popular, IPFS attempts to store it in more places and closer to the need.

You can play with this first hand at NoFilter.org, which brands itself as a "the world's first unstoppable, uncensorable, undeplatformable, decentralized freedom of speech app." There's no server storing files, just a set of Javascript files that run in your browser. Identity is provided via Metamask which uses an Ethereum address as your identifier. I created some posts on NoFilter to explore how it works. If you look at the URL for that link, you'll see this:


The portion after the # is the Ethereum address I used at NoFilter. If we look at a single post, you'll see a URL like this:


Note that there's an additional identifier following the slash after my Ethereum address. This is the IPFS hash of the content of that post and is available on IPFS directly. What's stored on IPFS is the JSON of the post that the Javascript renders in the browser.

  "author": "0xdbca72ed00c24d50661641bf42ad4be003a30b84", 
  "title": "The IPFS Address", 
  "timestamp": "2021-10-25T22:46:46-0-6:720", 
  "body": "<p>If I go here:</p><p><a href=\"https://ipfs.io/ipfs/

As far as I can tell, this is completely decentralized. The identity is just an Ethereum address that anyone can create using Metamask, a Javascript application that runs in the browser. The files are stored on IPFS, decentralized on storage providers around the net. They are rendered using Javascript that runs in the browser. So long as you have access to the Javascript files from somewhere you can write and read articles without reliance on any central server.

Decentralized Computing

My vision for picos is that they can operate on a decentralized mesh of pico engines in a similar decentralized fashion. Picos are already encapsulations of computation with isolated state and programs that control their operation. There are two primary problems with the current pico engine that have to be addressed to make picos independent of the underlying engine:

  1. Picos are addressed by URL, so the pico engine's host name or IP address becomes part of the pico's address
  2. Picos have a persistence layer that is currently provided by the engine the pico is hosted on.

The first problem is solvable using DIDs and DIDComm. We've made progress in this area. You can create and use DIDs in a pico. But they are not, yet, the primary means of addressing and communicating with the pico.

The second problem could be addressed with IPFS. We've not done any work in this area yet. So I'm not aware of the pitfalls or problems, but it looks doable.

With these two architectural issues out of the way, implementing a way for picos to move easily between engines would be straightforward. We have import and export functionality already. I'm envisioning something that picos could control themselves, on demand, programatically. Ultimately, I want the pico to chose where it's hosted based on whatever factors the owner or programmer deems most important. That could be hosting cost, latency, availability, capacity, or other factors. The decentralized directory to discover engines advertising certain features or factors, and a means to pay them would have to be built—possibly as a smart contract.

A trickier problem is protecting picos from malevolent engines. This is the hardest problem, as far as I can tell. Initially, collections of trusted engines, possibly using staking, could be used.

There are plenty of fun, interesting problems if you'd like to help.

Use Picos

If you're intrigued and want to get started with picos, there's a Quickstart along with a series of lessons. If you need help, contact me and we'll get you added to the Picolabs Slack. We'd love to help you use picos for your next distributed application.

If you're interested in the pico engine, the pico engine is an open source project licensed under a liberal MIT license. You can see current issues for the pico engine here. Details about contributing to the engine are in the repository's README.

Bonus Material

Rainbows End by Vernor Vinge

The information revolution of the past thirty years blossoms into a web of conspiracies that could destroy Western civilisation. At the centre of the action is Robert Gu, a former Alzheimer's victim who has regained his mental and physical health through radical new therapies, and his family. His son and daughter-in-law are both in the military - but not a military we would recognise - while his middle school-age granddaughter is involved in perhaps the most dangerous game of all, with people and forces more powerful than she or her parents can imagine.

The End of Cloud Computing by Peter Levine

Photo Credit: SiO2 Fracture: Chemomechanics with a Machine Learning Hybrid QM/MM Scheme from Argonne National Laboratory (CC BY-NC-SA 2.0)

Token-Based Identity


I've spent some time thinking about this article from PeterVan on Programmable Money and Identity. Peter references a white paper on central bank digital currencies and one on identity composability by Andrew Hong to lead into a discussion of account- and token-based1 identity. In his article, Peter says:

For Account-based identity, you need to be sure of the identity of the account holder (the User ID / Password of your Facebook-account, your company-network, etc.). For Token-based identity (Certified claim about your age for example) you need a certified claim about an attribute of that identity.

In other words, while account-based identity focuses on linking a person in possession of authentication factors to a trove of information, token-based identity is focused on claims about the subject's attributes. More succinctly: account-based identity focuses on who you are whereas token-based identity is focused on what you are.

One of my favorite scenarios for exploring this is meeting a friend for lunch. You arrive at the restaurant on time and she’s nowhere to be found. You go to the hostess to inquire about the reservation. She tells you that your reservation is correct, and your friend is already there. She escorts you to the table where you greet your friend. You are seated and the hostess leaves you with a menu. Within a few moments, the waitress arrives to take your order. You ask a few questions about different dishes. You both settle on your order and the waitress leaves to communicate with the kitchen. You happily settle in to chat with your friend, while your food is being prepared. Later you might get a refill on a drink, order dessert, and eventually pay.

While you, your friend, the host, and waitstaff recognized, remembered, and interacted with people, places, and things countless times during this scenario, at no time were you required to be identified as a particular person. Even paying with a credit card doesn't require that. Credit cards are a token-based identity system that says something about you rather than who you are. And while you do have an account with your bank, the brilliance of the credit card is that you no longer have to have accounts with every place you want credit. You simply present a token that gives the merchant confidence that they will be paid. Here are a few of the "whats" in this scenario:

  • My friend
  • The person sitting at table 3
  • Over 21
  • Guest who ordered the medium-rare steak
  • Someone who needs a refill
  • Excellent tipper
  • Person who owes $179.35
  • Person in possession of a MasterCard

You don't need an account at the restaurant for any of this to work. But you do need relationships. Some, like the relationship with your friend and MasterCard, are long-lived and identified. Most are ephemeral and pseudonymous. While the server at the restaurant certainly "identifies" patrons, they usually forget them as soon as the transaction is complete. And the identification is usually pseudonymous (e.g. "the couple at table three" rather than "Phillip and Lynne Windley").

In the digital realm, we suffer from the problem of not being in proximity to those we're interacting with. As a result, we need a technical means to establish a relationship. Traditionally, we've done that with accounts and identifying, using authentication factors, who is connecting. As a result, all online relationships tend to be long-lived and identified in important ways—even when they don't need to be. This has been a boon to surveillance capitalism.

In contrast, SSI establishes peer-to-peer relationships using peer DIDs (autonomic identifiers) that can be forgotten or remembered as needed. These relationships allow secure communication for issuing and presenting credentials that say something about the subject (what) without necessarily identifying the subject (who). This token-based identity system more faithfully mirrors the way identity works in the physical world.

Account- and token-based identity are not mutually exclusive. In fact, token-based identity often has its roots in an account somewhere, as we discovered about MasterCard. But the key is that you're leveraging that account to avoid being in an administrative relationship in other places. To see that, consider the interactions that happen after an automobile accident.

Account and token interactions after an automobile accident
Account and token interactions after an automobile accident (click to enlarge)

In this scenario, two drivers, Alice and Bob, have had an accident. The highway patrol has come to the scene to make an accident report. Both Alice and Bob have a number of credentials (tokens) in their digital wallets that they control and will be important in creating the report:

  • Proof of insurance issued by their respective insurance companies
  • Vehicle title issued by the state founded on a vehicle original document from the vehicle's manufacturer.
  • Vehicle registration issued by the Department of Motor Vehicles (DMV)
  • Driver's license issued by the Department of Public Safety (DPS) in Alice's case and the DMV in Bob's
  • In addition, the patrol officer has a badge from the Highway Patrol.

Each of these credentials is the fruit of an account of some kind (i.e. the person was identified as part of the process). But the fact that Alice, Bob, and the patrol officer have tokens of one sort or another that stem from those accounts allows them to act autonomously from those administrative systems to participate in a complex, ad hoc, cross-domain workflow that will play out over the course of days or weeks.

Account-based and token-based identity system co-exist in any sufficiently complex ecosystem. Self-sovereign identity (SSI) doesn't replace administrative identity systems, it gives us another tool that enables better privacy, more flexible interactions, and increased autonomy. In the automobile scenario, for example, Alice and Bob will have an ephemeral relationship that lasts a few weeks. They'll likely never see the patrol officer after the initial encounter. Alice and Bob would make and sign statements that everyone would like to have confidence in. The police officer would create an accident report. All of this is so complex and unique that it is unlikely to ever happen within a single administrative identity system or on some kind of platform.

Token-based identity allows people to operationalize their digital lives by supporting online interactions that are multi-source, fluid multi-pseudonymous, and decentralized. Ensuring that the token-based identity system is also self-sovereign ensures that people can act autonomously without being within someone else's administrative identity system as they go about their online lives. I think of it as digital embodiment—giving people a way to be peers with other actors in online interactions.


  1. I'm using "token" in the general sense here. I'm not referring to either cryptocurrency or hardware authentication devices specifically.

Photo Credit: Tickets from Clint Hilbert (Pixabay)

NFTs, Verifiable Credentials, and Picos

Colorful Shipping Containers

Listening to this Reality 2.0 podcast about NFTs with Doc Searls, Katherine Druckman, and their guest Greg Bledsoe got me thinking about NFTs. I first wrote about NFTs in 2018 regarding what was perhaps the first popular NFT: Cryptokitties. I bought a few and played with them, examined the contract code, and was thinking about how they might enable self-sovereignty, or not. I wrote:

[E]ach kitty has some interesting properties:

  • Each Kitty is distinguishable from all the rest and has a unique identity and existence
  • Each kitty is owned by someone. Specifically, it is controlled by whoever has the private keys associated with the address that the kitty is tied to.

This is a good description of the properties of NFTs in general. Notice that nothing here says that NFTs have to be about art, or collectibles, although that's the primary use case right now that's generating so much hype. Cryptokitties were more interesting than most of the NFT use cases right now because the smart contract allowed them to be remixed to produce new kitties (for a fee).

Suppose I rewrote the quote from my post on Cryptokitties like this:

[E]ach verifiable credential (VC) has some interesting properties:

  • Each VC is distinguishable from all the rest and has a unique identity and existence
  • Each VC is owned by someone. Specifically, it is controlled by whoever has the private keys associated with the address that the VC was issued to.

Interesting, no? So, if these properties are true for both NFTs and verifiable credentials, what's the difference? The primary difference is that right now, we envision VC issuers to be institutions, like the DMV, your bank, or employer. And institutions are centralized. In contrast, because NFTs are created using a smart contract on the Ethereum blockchain, we think of them as decentralized. But, not so fast. As I noted in my post on Cryptokitties, you can't assume an NFT is decentralized without examining the smart contract.

There is one problem with CryptoKitties as a model of self-sovereignty: the CryptoKitty smart contract has a "pause" function that can be executed by certain addresses. This is probably a protection against bugs—no one wants to be the next theDAO—but it does provide someone besides the owner with a way to shut it all down.

I have no idea who that someone is and can't hold them responsible for their behavior—I'd guess it's someone connected with CryptoKitties. Whoever has control of these special addresses could shutdown the entire enterprise. I do not believe, based on the contract structure, that they could take away individual kitties; it's an all or nothing proposition. Since they charged money for setting this up, there's likely some contract law that could be used for recourse.

So, without looking at the code for the smart contract, it's hard to say that a particular NFT is decentralized or not. They may be just as centralized as your bank1.

To examine this more closely, let's look at a property title, like a car title, as an example. The DMV could decide to issue car titles as verifiable credentials tomorrow. And the infrastructure to support it is all there: well-supported open source code, companies to provide issuing software and wallets, and specifications and protocols for interoperability2. Nothing has to change politically for that to happen.

The DMV could also issue car titles as NFTs. With an NFT, I'd prove I own the car by exercising control over the private key that controls the NFT representing the car title. The state might do this to provide more automation for car transfers. Here too, they'd have to find an infrastructure provider to help them, ensure they had a usable wallet to store the title, and interact with the smart contract. I don't know how interoperable this would be.

One of the key features of an NFT is that they can be transfered between owners or controllers. Verifiable credentials, because of their core use cases are not designed to be transferred, rather they are revoked and reissued.

Suppose I want to sell the car. With a verifiable credential, the state would still be there, revoking the VC representing my title to the car and issuing a new VC to the buyer when the title transfers. The record of who owns what is still the database at the DMV. With NFTs we can get rid of that database. So, selling my car now becomes something that might happen in a decentralized way, without the state as an intermediary. Note that they could do this and still retain a regulatory interest in car titling if they control the smart contract.

But, the real value of issuing a car title as an NFT would be if it were done using a smart contract in a way that decentralized car titles. If you imagine a world of self-driving cars that own and sell themselves, then that's interesting. You could also imagine that we want to remove the DMV from the business of titling cars altogether. That's a big political lift, but if you dream of a world with much smaller government, then NFT-based car titles might be a way to do that. But I think it's a ways off. So, we could use NFTs for car titles, but right now there's not much point besides the automation.

You can also imagine a much more decentralized future for verifiable credentials. There's no reason a smart contract couldn't issue and revoke verifiable credentials according to rules embodied in the code. Sphereon has an integration between verifiable credentials and the Digital Assets Markup Language (DAML), a smart contract language. Again, how decentralized the application is depends on the smart contract, but decentralized, institution-independent verifiable credentials are possible.

A decade ago, Lucas, Ballay, and McManus wrote Trillions: Thriving in the Emerging Information Ecology. One of the ideas they talked about was something they called a persistent data object (PDO). I was intrigued by persistent data objects because of the work we'd been doing at Kynetx on personal clouds. In applying the idea of PDOs, I quickly realized that what we were doing was much more than data because our persistent data objects also encapsulated code and the name persistent compute objects, or picos was born.

An NFT is one possible realization of Trillion's PDOs. So are verifiable credentials. Both are persistent containers for data. They are both capable of inspiring confidence that the data they contain has fidelity and, perhaps, a trustworthy provenance. A pico is an agent. Picos can:

  • have a wallet that holds and exchanges NFTs and credentials according to the rules encapsulated in the pico.
  • be programmed to interact with the smart contract for an NFT to perform the legal operations.
  • be programmed to receive, hold, and present verifiable credentials according to the proper DIDCommm protocols.3

Relationship between NFTs, verifiable credentials, and picos
Relationship between NFTs, verifiable credentials, and picos (click to enlarge)

NFTs are currently in their awkward, Pets.com stage. Way too much hype and many myopic use cases. But I think they'll grow to have valuable uses in creating more decentralized, trustworthy data objects. If you listen to the reality 2.0 podcast starting about 56 minutes, Greg, Katherine, and Doc get into some of those. Greg's starting with games—a good place, I think. Supply chain is another promising area. If you need decentralized, automated, trustworthy, persistent data containers, then NFTs fit the bill.

People who live in a country with a strong commitment to the rule of law, might ask why decentralizing things like titles and supply chains is a good idea. But that's not everyone's reality. Blockchains and NFTs can inspire confidence in systems that would otherwise be too costly or untrustworthy otherwise. Picos are a great way to create distributed systems of entity-oriented compute nodes that are capable of using PDOs.


  1. Note that I'm not saying that Cryptokitties is as centralized as your bank. Just that without looking at the code, you can't tell.
  2. Yeah, I know that interop is still a work in progress. But at least it's in progress, not ignored.
  3. These are not capabilities that picos presently have, but they do support DIDComm messaging. Want to help add these to picos? Contact me.

Photo Credit: Colorful Shipping Containers from frank mckenna (CC0)