11. Network Governance

Democracy is the worst form of government, except for all the others that have been tried.1

—Winston Churchill

The internet’s core protocol networks approximate a democracy. At their foundation, developers weigh in on and implement technical standards. Many developers are independent and free to make their own choices, or they are part of larger companies that make client applications. If someone proposes to change an existing protocol or invent a new one, it’s up to developers and businesses to put the ideas into practice. Proposals are just that, proposals.

It is in this sense that these protocols are owned and operated by the internet community. Developers “vote” on proposals by deciding whether to include them in software. Users “vote” too, indirectly, by deciding on which products to use. Everyone more or less has a say.

At a higher level, internet governance emerges from an organizational patchwork of technical standards coordinators. The World Wide Web Consortium (W3C), an international nonprofit, provides a forum for hundreds of member organizations,2 including research institutions, government groups, small companies, and big corporations, to discuss web-related standards. The volunteer-only Internet Engineering Task Force (IETF), part of the separate nonprofit Internet Society, maintains standards for internet protocols like email.3 ICANN, yet another nonprofit, oversees the internet’s name space, including by allocating IP addresses, accrediting domain name registrars, and adjudicating disputes over trademarks and other legal matters. Except for ICANN, these organizations are not really governing bodies. Yes, they set protocol standards and convene discussions but, for the most part, they issue recommendations, not edicts.

Governments are responsible for regulation and enforcement, though they generally do not interfere with underlying technology. Government groups participate in internet governance as advisers, providing input on protocols, but the policies that result are ultimately the product of a dialogue among industry, civil society, academia, and others. David Clark, an MIT researcher and internet pioneer, best captured the spirit of protocol network governance4 when he said, “We reject: kings, presidents, and voting. We believe in: rough consensus and running code.” (The IETF would later adopt Clark’s words as its unofficial motto.)

Historically, internet regulation has not targeted protocols, but instead has targeted the people and companies who interact with protocols. That includes businesses that make client apps. Authorities do not require that the email protocol, SMTP, block the transmission of spam, for example. Instead, governments regulate the misuse of email by fining any person or business that violates certain spam-fighting laws, such as false advertising or ignoring email opt-out requests. Software developers, businesses, and others can comply with such regulations (which target their apps, companies, and client software, rather than the underlying protocols) or suffer the consequences. It’s their choice. By observing this simple setup—regulating apps, not protocols—governments help preserve the promise of the underlying technology.

If protocol networks are democracies, corporate networks are dictatorships. They’re governed, absolutely, by their owners: effective at coordinating, but inherently unfair. When management issues a directive, everyone must obey. At the same time, nothing stops management from changing policies at will to suit corporate interests at the expense of other network stakeholders. The economic might of corporate networks and these networks’ ability to make unilateral decisions give them a competitive edge over protocol networks. But corporate decision-making processes are usually opaque, capricious, and, as some users allege, discriminatory.

Most of today’s popular internet products are corporate owned, meaning they’re governed as dictatorships. Corporate networks have been a boon for big players in Silicon Valley, many of whom are happy with the status quo. The corporate model is so intertwined with how the internet operates today that people sometimes forget there are other ways to govern networks. But cracks in the edifice of corporate networks are beginning to show, and people are catching on to their harmful effects. The fissures are most pronounced in social networks, arguably the most significant class of corporate networks.

While questions of network governance might have seemed academic a few years ago, they’ve since become mainstream concerns. Debates over the governance of popular corporate networks like Facebook, Twitter, and YouTube are increasingly common. How should the algorithms rank content? Who should have access? What are the right moderation policies? How should user data be handled? How should ads and monetization work? For many businesses and creators, these questions directly affect their livelihoods; they may even affect democracy itself.

I believe there’s a better way to govern networks—and I’m not the only one. People who share this mindset believe that network governance shouldn’t depend on who might own a specific company, or the views of whoever happens to work there at any given time. Take Twitter, for example. Maybe you liked the way the company ran before Elon Musk took over, but do you like it now? Maybe you like the way your favorite network is currently governed, but will you like it in the long term? A growing number of people are coming around to the idea that networks are too important to leave to the whims of single, powerful companies or individuals.

The Nonprofit Model

Some people believe nonprofit legal entities provide a solution. The network would still be a dictatorship, but at least it would be controlled by an organization that has motives beyond financial success. Proponents of this approach cite Wikipedia, the crowdsourced encyclopedia owned and supported by the nonprofit Wikimedia Foundation, as a model. It’s an interesting idea, but is it capable of being extended to other areas of technology?

Wikipedia is a special case:5 it is the only large-scale internet service structured as a nonprofit. Wikipedia was able to succeed this way due to a combination of factors, including the goodwill of its founders, its long-standing network effects, and its low upkeep costs. Unlike many other internet services, Wikipedia hasn’t needed many product changes since its introduction in 2001. Consumer demand for encyclopedia information hasn’t changed much as tech platforms have shifted. As a result, Wikipedia’s expenses have remained relatively low and supportable through voluntary donations.

To the credit of its founders and board, Wikipedia hasn’t wavered in its mission even when it might have been easy to get distracted or try to cash in. It would be great if Wikipedia’s nonprofit model could extend to other areas, but it is exceedingly rare for modern internet services to need so little ongoing investment. Indeed, the two most prominent attempts to replicate Wikipedia’s success in other domains have both since pivoted away from their founding nonprofit structures.

The first is Mozilla,6 creator of the Firefox web browser. Mozilla began in 1998 as an open-source project to steward code for the early web browser Netscape Communicator. In 2005, two years after spinning out Netscape assets as a nonprofit, Mozilla created a for-profit subsidiary, the Mozilla Corporation. This allowed it to pursue more aggressive business tactics that are prohibited for tax-exempt nonprofits, including inking a multi-hundred-million-dollar deal with Google7 and acquiring smaller companies8 to accelerate product development.

The second example is OpenAI, creator of ChatGPT and other tools. OpenAI originally started as a nonprofit9 in 2015. Four years later, it rolled out a for-profit subsidiary to raise the billions of dollars it needed to compete with Big Tech AI efforts. The startup went corporate.

It’s hard to be a nonprofit in a for-profit world. Both of these organizations’ transitions were probably necessary. The internet is a highly competitive place dominated by big companies with tens of billions of dollars in cash reserves. Competing without generating revenue or accessing capital markets immediately puts nonprofits at a disadvantage. The nonprofit model sounds good in theory, but it is very hard to make work in practice.

Federated Networks

Another solution to better governance is to return to protocol networks. Jack Dorsey, co-founder and former chief executive of Twitter, has advocated for this approach.10 No “individual or institutions should own social media, or more generally media companies. It should be an open and verifiable protocol,” Dorsey tweeted in April 2022, after having stepped down as Twitter CEO. Later that year, asked to reflect on his tenure, Dorsey added that Twitter becoming a company was “the biggest issue and my biggest regret.”11

We’ve already discussed some attempts to revive protocol networks in “The Fall of RSS.” There have been many others: Friend of a Friend,12 a 2000s-era decentralized protocol for social graphs. StatusNet, a distributed open-source social network,13 from 2009, which later merged with similar projects, FreeSocial and GNU Social. Scuttlebutt, a self-hosted social networking project,14 from 2014. Mastodon, a network built on the decentralized social protocol ActivityPub, from 2016. The web creator Tim Berners-Lee’s Solid,15 short for “social linked data,” in 2018. Bluesky, a Dorsey-backed Twitter alternative16 that uses a decentralized protocol of its own design, incubated in 2019. Meta’s answer to Twitter, Threads, which launched in 2023 and will one day interoperate with ActivityPub,17 so the company says. Miscellaneous others: Friendica (decentralized Facebook), Funkwhale (decentralized SoundCloud), Pixelfed (decentralized Instagram), Pleroma (decentralized Twitter), PeerTube (decentralized YouTube), and more.

People keep trying to make the protocol approach to social networking work. Maybe one or more of these protocols will achieve mainstream adoption, but they have challenges to overcome, many arising from their network designs. Most implementations rely on a specific variation of protocol networks called federated networks. These protocols don’t use centralized data centers to host people’s data the way corporate networks do. Instead, people run their own instances of the software, called servers, to host the data. People refer to such efforts, collectively, as the Fediverse.

Several Twitter alternatives, including some mentioned above—Bluesky, Mastodon, Meta’s Threads—either work or intend to work this way. Anyone can download open-source software and run their own server or apply for an account as a user at an existing server. Every server has its own admissions process and community standards. Cross-server communications protocols, the most popular of which is ActivityPub, allow users to follow the activity of users on other servers. This lets the system simulate some features of centralized systems without having a single company in control.

A physical analogy helps to explain the design. Think of a corporate network like Twitter as a large country with a single ruler. By contrast, federated networks are like a collection of smaller countries, each controlled by a single ruler. These countries are still dictatorships, but there are now many dictatorships to choose from. Users can decide where to spend time, which gives them some say over how they are governed. The system is an improvement over corporate networks, where there is no choice.

Federated networks have two main weaknesses,18 though. The first is friction. The impediments are due mainly to the boundaries between servers that are running independently. For example, searching for content and interacting with users across servers can be cumbersome because there is no central data repository. One server might store a user’s post, and another server might store a reply to that post, but no central servers store the entire thread. This makes it difficult to provide a global view of what is happening across the network.

Because of their architecture, federated networks have difficulty matching the smooth user experiences of other networks. Corporate networks eliminate friction by storing data in centralized data centers while blockchain networks eliminate friction by storing data on a blockchain. (Recall that blockchains are distributed, virtual computers that can store arbitrary information, including social data.) Federated networks, like protocol networks, have no centralized components, and thus no central place to store data, which is a problem because, as history shows, even small amounts of friction can stymie adoption.

How might one fix this? Imagine another system on top of a federated network that collects data from the individual servers and aggregates that data into a single, centralized database. Sometimes servers will disagree, so the system needs a way to adjudicate disputes to decide which servers best represent the network’s true state. Well, guess what? We’ve just invented a blockchain. Blockchains provide a mechanism for centralizing data while keeping control of that data decentralized.

Many proponents of federated networks refuse to use or even to consider blockchains, presumably because of the associations blockchains have with the casino culture of scams and speculation. This is unfortunate. Anyone who looks at blockchains dispassionately will see them as powerful tools that can help to compete with corporate networks. (See “The Computer versus the Casino” for more.)

To complicate matters further, some federated-network proponents will consider using blockchains, but only specific blockchains. For one, Dorsey has expressed interest in using Bitcoin as part of a decentralized social network. The problem is that Bitcoin has high transaction fees (typically more than $1 per transaction) and slow transaction times (usually ten minutes or longer, depending on various factors including network conditions). Some projects are trying to fix these limitations by building layers on top of Bitcoin. I hope they succeed. Without them, it’s hard to see how Bitcoin can be a key component of a decentralized social network that can credibly challenge corporate networks.

Meanwhile, other systems already have sufficient performance to help power next-generation social networks. Newer blockchains and so-called layer-two systems built on top of Ethereum are among the existing options.

Protocol Coups

The second weakness of federated networks is the risk of protocol coups. That is, even if a federated network succeeds, it may spawn a new corporate network and thereby re-create the same problems discussed throughout this book.

As mentioned, federated networks are like a federation of countries. They have common rules but they still have cross-border frictions. Users tend to cluster in the most popular country (read: server), which gives that country’s ruler (read: server owner) effectively unlimited authority to set and change rules. People who study such systems are aware of the risks.19 As one privacy researcher aptly put it in a 2018 blog post titled “Federation Is the Worst of All Worlds,” “Without building consent and resistance into the protocol and infrastructure, we’re just forcing most users to pick a new dictator for their data without any real basis for that choice.”

Nothing binds a server in a federated network to its word. That’s the problem. The system has no guardrails.

Similar coups have already happened. As discussed in “The Fall of RSS,” people once viewed Twitter as an interoperable node in RSS’s open network, even though it was, in fact, a corporate network. Eventually, Twitter pivoted and removed support for RSS.20 It switched from attract to extract mode, as is the fate of all corporate networks. A successful federated network would face the same coup threat from its largest nodes. Without stronger constraints in place, it would be only a matter of time before economic incentives superseded high-minded ideals.

Consider the typical life cycle of a server in a federated network. Running a server as a hobby works for a while, but if it grows to millions of users, the costs to run it go up too. Networks need money to grow, which is why most major social networks have raised billions of dollars in funding. The money can come from investors or from revenue sources like subscriptions and advertising. Since federated networks have no core by design, they have no easy way to raise money for the network itself. Instead, the money will find its way to popular servers. In time, the corporate network logic will take hold and interoperability will become a liability. The servers will clamp down, just as Twitter did—attract, extract.

Breaking a large dictatorship, like a corporate network, into smaller dictatorships, as in federated networks, works only if the countries stay small. But network effects ensure the opposite, that small advantages compound to create big winners. Thus, federated networks have a tendency, a fundamental by-product of their architecture, to evolve into corporate networks. The strongest nodes can co-opt the network.

It’s worth noting that the risk of protocol coups exists even in classic protocol networks like email and the web. Nodes that acquire large user bases can exert outsized influence. Gmail and Chrome both have billions of users, which gives Google an outsized number of “votes”21 it can use to sway email and web governance in its favor. For example, Gmail’s approach to spam filtering favors email sent by other large email providers. As a result, people sending email from personal or small-business-hosted servers get flagged as spam more often. This is a relatively minor issue affecting email purists, but Gmail has gotten so popular that Google could probably go much further and unilaterally modify core email standards if it wanted to. So far, Google hasn’t tried this, partly because other large companies like Apple and Microsoft act as counterweights, and partly because the communities that have formed around email and the web have strong, deeply entrenched norms.

New networks don’t have the same counterweights and historical norms. When governance is a function of network topology, as in protocol and federated networks, corporate takeover is always a risk. Communities need a network architecture that allows for growth while minimizing the risk of protocol coups. In the absence of rules explicitly enshrined in code, only custom—nothing more—keeps tyrants at bay.

Blockchains as Network Constitutions

Blockchains offer a new approach to network governance that gives people the ability to encode immutable rules in software. These rules can specify how networks are governed and in so doing build trust, improve transparency, and resist takeover.

National constitutions, like the U.S. Constitution, provide a helpful analogy. Constitutions formalized the shift of national governance from individual rulers to written law. In the same vein, blockchains shift network governance from corporate management to written code. Like legal documents, software can be extremely expressive. Blockchain governance systems are written in general-purpose programming languages that can codify virtually any governance system that can be written in English as a step-by-step procedure. They are constitutions for networks.

Even in the presence of a blockchain, forms of governance can vary widely. A blockchain constitution can emulate corporate networks by putting a single organization in charge. The leader can change whatever it wants, including algorithms, economics, and access rules. Alternatively, a blockchain constitution can restrict the powers of a leader, as in a constitutional monarchy. A blockchain constitution can also establish a light-touch republic with no single ruler, and it can set fees and controls to minimal levels in a way that takes inspiration from protocol networks. Most blockchain networks push decisions to the community, incarnating a governance design analogous to constitutional democracy. These are only a few points on a wide, multidimensional spectrum of possibilities: any system that can be written down can be realized.

Blockchain Governance

Blockchain governance tends to come in two flavors. Some blockchain networks use what’s called off-chain governance, which is similar to protocol network governance in that the network is run by a coalition of developers, users, and other community members. The advantage of off-chain governance is that it is time tested, building on decades of lessons learned from protocol networks and open-source software projects. The downside is that, as with protocol networks, governance is a function of network structure. If certain nodes get too popular and gain too much power relative to others, they can take over the network.

Many newer blockchain networks use “on-chain” governance, where token holders explicitly vote on proposed network changes. They do this with voting software that lets them sign blockchain transactions associated with tokens they hold. These signatures indicate which way they are voting when proposals are made. The blockchain network automatically obeys the outcome of the vote. If you depend on a network, you’ll probably want to cast a ballot.

Clout in on-chain governance is usually a function of how many tokens a voter holds. Divorcing governance from network structure removes the risk of large software providers gaining outsized influence. But tokens trading on open markets introduces a new risk: that a deep-pocketed actor could gain disproportionate influence. In other words, there is a risk of plutocracy, where big token holders could co-opt the network.

The best way to mitigate this risk is with a broad distribution of tokens. Token ownership should be widespread across the community such that no voting bloc has too much power. This requires thoughtful faucet design, as discussed in the previous chapter.

Some networks also have a second line of defense against plutocracy: splitting voters into two groups. The approach resembles the bicameral systems used by national governments, such as the U.S. Senate and House of Representatives. In a blockchain network, one house might consist of respected community members chosen by a foundation, while the other might consist of token holders. Sometimes the foundation house can veto proposals made by the token house if it deems the proposals overly self-interested. Other times certain responsibilities, such as technical and financial decisions, are split across houses.

Blockchain networks vary in how much they can be modified through governance. At one extreme are networks where any participant can propose changes to core network code. Users submit proposals on discussion forums, either as informal proposals or as working code. Proposals with enough support go to a token-holder vote. If a proposal passes, the network implements the updates automatically. No further action is necessary.

At the other extreme are networks where the token holders don’t have any control over core network code. Once the software is uploaded to a blockchain, that’s it. It’s immutable. The code just runs on autopilot. This means new versions of the software are released as entirely new networks, coexisting with older versions that remain indefinitely active. Token holders cannot tamper with the code, which limits what they’re able to do and simplifies governance debates. Instead, token holders vote on more limited matters, such as supporting software development with treasury distributions.

None of these governance systems are perfect, but being able to formalize network governance at all represents a step forward in network design. The problem with informal governance is that rules and leaders inevitably emerge, but they are usually a product of inscrutable social dynamics rather than thoughtful design. The feminist author Jo Freeman calls this “the tyranny of structurelessness.” In her 1972 essay of the same name,22 she describes how hidden, unaccountable hierarchies form within supposedly leaderless organizations. When you create formal rules, you can debate them, learn from them, and improve them. (This is also why when tech startups experiment with “holacracy” and other structureless management styles, it almost never ends well.)

This is one advantage corporate networks have over protocol networks. Someone is in charge, usually a CEO, and that person is chosen through a process that at least tries to pick good leaders and hold them to account. In protocol and federated networks, there are still rules and leaders, but they are usually the products of opaque interpersonal relations rather than well-considered processes that are designed to keep power dynamics in check.

Network designers can use blockchains to create formal rules that are enforced by code. These rules are like constitutions for networks. What these constitutions say is subject to debate, contention, and experimentation, but their very existence, the ability to enshrine rules in immutable software, is a meaningful advance that was not possible in previous network designs. Now is the time to think intentionally about network governance, a subject far too consequential to leave up to chance.

Blockchain constitutions enable users to share in the control of networks, just as composability enables developers to share in contributions to software and tokens enable participants to become owners with interests. By combining these tools, we can build a new generation of community-owned networks—digital cities that provide something for everybody, because they are built by everybody.