Protocol | Book Review

EPISODE 19 | TRANSCRIPT

Watson  -   Host

B. Sovereign  -   Co-Host

[00:00:35]  Watson

Hello, and welcome to Episode 19 of the BitLemmas podcast. I am Watson, here with B. Sovereign. Today is a book review of Protocol by Alexander Galloway. The book's claim is not that decentralization is fake. Its claim is that control does not vanish when you remove the center. The standard story says centralized control is bad. Decentralized networks remove the center. Open standards are neutral plumbing. And if anyone can connect, power has been defeated. Galloway asks us to inspect the control surface. Which rules define valid participation? Who controls names and addresses? Who sets the defaults and the clients? Who controls the upgrade path? And what happens to whoever is incompatible? We will review four counterintuitive truths: decentralization does not remove control; openness can be a control surface; the Internet is horizontal and vertical at once; and resistance works through protocol. So what is this book about? It is a theory of technical standards as political control. There is also a close reading of the network standards of TCP/IP, DNS, RFCs -  which is Request for Comments -  browsers, and the forms of the network, the topologies. It is a challenge to the idea that decentralization automatically becomes freedom. And it is also a warning to builders: the rule layer is the power layer. Now there is control after sovereignty and discipline. What are we talking about here? The author uses some models from different philosophers. One is Deleuze. Another is the more well-known Michel Foucault. The Deleuzean way to talk about control comes in three levels. First, you have sovereign societies. When we say sovereign here, we are using the Thomas Hobbes definition -  control is violence. You have a sovereign at the top and everyone doing as they say: the master's word. Then you have disciplinary societies, where control is bureaucratic, command, and enclosure. Think of a prison, or a school where the bell rings and you are programmed to move your body to the next class. This is more the disciplinary model -  Michel Foucault's Discipline and Punish. Then you have control societies -  the Deleuzian view. Within control societies, control runs on information technology and computers. The author is saying that protocol is to control societies what the Panopticon was to discipline. What is the Panopticon? It was coined by the philosopher Jeremy Bentham, the founder of utilitarianism -  the most good goes to the most people. He conceived of a good prison: one with the least amount of pain and the least number of guards. Imagine a tower in the middle of the prison. You cannot really see the guards, but you know they are in that tower, and you think they are watching you -  though you cannot tell. So you self-censor. You behave, because you believe you are always being watched. That is the Panopticon. This is where discipline comes in, versus the punishment implied in the previous phase -  the sovereign -  where people faced the guillotine, as Michel Foucault would describe. So the question is not whether there is a center, but what this era's form of control is. The standard story: centralized control is bad. Decentralized networks remove the center. Open standards are neutral plumbing. If anyone can connect, then power has been defeated. The thesis of this book is that control survives decentralization by becoming protocol, using examples of TCP/IP and DNS. TCP/IP, the standard of the Internet, distributes relations among autonomous hosts -  it is peer-to-peer and horizontal. DNS, however, reintroduces hierarchy through names and root authority. If you have a domain name like google.com, you can be censored from the top. It is far more difficult to censor an IP address. The Internet is controlled because shared rules make it possible. The emphasis is on the word because: it is the shared rules that make control possible. The major premises of the book: networks are material -  physical systems, not just metaphors. Every functioning network needs shared rules, and that is where the control will be. Compatibility creates connection; incompatibility creates exclusion. Protocol can distribute control while standardizing behavior. And resistance must operate through the same technical field as protocol. Subversive behavior cannot exist outside the rules -  it has to operate within them. The four counterintuitive truths from the book: Truth 1 -  decentralization does not remove control. Truth 2 -  openness can be a control surface. Truth 3 -  the Internet is horizontal and vertical at once. Truth 4 -  resistance works through protocol. Truth number one: decentralization does not remove control. A distributed network removes the obvious center. The author defines decentralization as removing a center, but you could then have multiple centers. So he says DNS is decentralized, but a truly distributed network -  TCP/IP -  does not even have hubs. You could argue DNS is decentralized, even though there is an authority that can censor you. The network needs rules that decide valid participation. That is where protocol comes in. No shared protocol means no shared network. You cannot have a network unless participants agree on the rules. Control moves from a top-down command hierarchy into compatibility.

[00:11:15]  B. Sovereign

The deeper insight here is that rules replace the center. Control no longer has to sit in a single command node. It can live in the shared rules that all nodes must follow. The diagnostic question for any decentralized system is: which rules define valid participation, who can change those rules, and what happens to incompatible actors? If you can answer those three questions, you have found your control surface -  even in a system that appears perfectly flat.

[00:11:54]  Watson

Now we have our diagram. The center disappears. The autonomous nodes remain. Call this TCP/IP. The rules define valid participation. Compatibility decides connection. And control lives on in the protocol. I will use the example of Microsoft and the Open Document Format. In the early 2000s, the Open Document Format was an initiative to make documents a standard that anyone could interpret and build their own software around. It was a major push by governments and countries alike. What allegedly happened is that Microsoft exploited the rules of the standards bodies themselves. The standards bodies were stacked with members who would vote for Microsoft's protocol to be an open standard, and it was rammed through -  too complex to understand in the time allotted, but approved nonetheless. There was the Open Document Format, but there was also the protocol of the standards bodies themselves -  and that is where the control went. I will keep returning to this example. Truth number two: openness can be a control surface. Open documentation can still standardize behavior. Interoperability requires agreed technical constraints. For the Internet's protocols, there are standards bodies that communicate through documents like RFCs -  Request for Comments. You put a document out, the standards body reviews it, and the protocol forms around it. But then there is all the politics around the standards body itself, and that is what the author focuses on heavily. Here is a point I think is really important: universal adoption can homogenize local differences. Take HTTP. The web appears heterogeneous -  websites look different, some great, some not -  and there seems to be a lot of diversity. But because HTTP, the protocol that allows web servers to connect to your browser, requires everyone to operate at the same level, it actually kills the diversity. That is what the author keeps returning to: where the control lies. Control here is born from the openness itself. You could also frame this as network effects. The fact that it is an open protocol -  seemingly inclusive, seemingly universal -  is what allows the anti-diversity, because it constrains you to behave. Otherwise, you get excluded. If you are in a control society, information networks are very costly to be excluded from. Being cut off from the Internet would make it nearly impossible to function in modern society. The more people depend on the protocol, the more powerful its rules become. Think of Metcalfe's Law: the value of a network is the square of its nodes. That exclusion is where the power comes from.

[00:17:43]  B. Sovereign

This is where the compatibility gate solidifies. You have open specification leading to shared implementation, which leads to interoperability -  which means noncompliance disconnects. Openness becomes enforceable. Valid behavior connects; invalid behavior disappears. This is not a flaw. This is simply how protocol is meant to work. The more people depend on a protocol, the more powerful its rules become. For builders, the question is: what should you inspect in an open protocol? The compatibility test, the upgrade process, the default clients, the naming rules, and failure behavior. Those are your governance documents.

[00:18:39]  Watson

Back to the Open Document Format. There was a movement to have an open way to reference and interpret documents so that anyone could build an implementation around it. Have you ever done business with a corporation and had to create a Word doc or a Google Doc? You may have never even heard of the Open Document Format, because the other formats are so pervasive. That is vendor lock-in. Before Google Docs, you had a significant vendor lock-in. You have the standard of the document itself, and then you have the rules of how you create those standards -  the standards bodies. One of those rules: if you are part of the standards body, you can vote. So now you have an open specification of the standards body itself, a shared implementation, and all of these standards bodies across different countries, all voting. What Microsoft did was ram through another standard. The ODF format went through, but then came another one -  and this was a battle for market share. Once that second standard came through, they exploited the rules to stack the standards bodies with their voters. One person in Sweden described it as someone trying to go through a supermarket checkout with six carts -  that is how aggressively they were pushing it through. Why did that matter? Because now they had an open standard -  in quotes. And since they were compliant, they could continue to exclude everyone else. The standard was so complicated that no one could build an interpreter for it except Microsoft, and they could change it at will. This is where control lives: in creating these protocols. The openness of the OOXML standard became enforceable through exclusion. Truth number three: the Internet is horizontal and vertical at once. TCP/IP, the Internet protocol stack, allows for packet routing -  sending network data through multiple different paths with no central command to pick the path. It is distributed in the author's terminology. It enables horizontal host-to-host communication. But DNS maps human-readable names to machine addresses. Google.com maps to something like 192.168.0.0.1. The namespace is hierarchical, even when the packet routing is distributed. The Internet's control is both horizontal and vertical. You are not going to memorize IP addresses -  you will use domain names, which are controlled by a standards body at the top.

[00:24:04]  B. Sovereign

The packet-name split is the tension between distributed TCP/IP routing and hierarchical naming. The practical audit question for DNS is: who controls the namespace, who can update records, who can revoke names, and what fallback paths exist? If the answer is a root zone administrator or a registrar, then your decentralized access still depends on a vertical authority. The horizontal layer exists, but it sits on top of a vertical one.

[00:24:51]  Watson

To reiterate: TCP/IP routes packets. The author defines a host as a computer on the network capable of both consuming and providing communication services -  so the hosts communicate peer to peer. DNS resolves names through roots and zones, which order the namespace of human-readable names. Horizontal access depends on vertical naming. Truth number four: resistance works through protocol. Refusal can mean disconnection, and disconnection from a valuable network carries a high cost. But the tactical actors work inside the protocol. How? They exploit. They use counter-protocols -  fork, encrypt, reroute, mutate rules. The Microsoft example, counterintuitively, shows a large company exploiting the rules of standards bodies and mutating them from within. You have a vote? We will stack the votes. We will stack the members. They were following the rules. In a network society, networks fight other networks.

[00:26:31]  B. Sovereign

Galloway provides a few examples that really solidify this point. The first: hacker tiger teams form around a problem and then dissolve. There is no center. Reading them as a criminal conspiracy misrecognizes how they actually work. Then there was the I Love You virus, which exposed Microsoft Outlook as an anti-protocol application. The logical weakness was the real target, not the virus itself. Another example involves cyber-feminism and tactical media acting as a bug that mutates protocol into hypertrophy -  pushing it in new directions. The pattern here is that resistance is an autonomous agent acting inside the protocol field. It is not a unified group standing outside it. The counter-protocol loop: protocol sets what is possible; tactical actors find constraints; interventions use the same rule field; then defaults, routes, or standards mutate -  and control and resistance co-evolve. Resistance is strongest when it understands the rule field. And this is the hard version of the claim: opposing protocol is like opposing gravity. There can be no resistance to protocol in any direct or connected sense. The move is to steer it, not to destroy it.

[00:28:15]  Watson

The hard version of the claim: opposing protocol is like opposing gravity. There can be no resistance to it in any direct or connected sense. It seems counterintuitive, but think of it this way. There is a book called The Hacker's Mind that reviews this well. Resistance to a protocol works more like a parasite. You do not want to destroy the system. You want to redirect where it is going. You have to behave inside the system in order to extract value from it. That is the cost of opting out of the Internet itself -  an extremely high penalty. But the author also pushes back and says protocological control is still an improvement over the violence and discipline stages he quotes from Deleuze. He is imploring us to guide our efforts through protocol, not against it. The main argument of the book, as succinctly as possible: Protocol as decentralized control. If new communication technologies remove centralized command, critics will claim that control disappears. If protocol is how technological control exists after decentralization, then that disappearance claim is false. If you need compatible rules to create a network, and incompatible rules prevent or destroy the network, then shared protocol rules define who is connected to whom. If the shared protocol rules define the network's field of possibility, then protocol is decentralized control. Our critique of the author's domain language. If we were to implement this as builders in software, we would use three different frameworks: The Structure and Interpretation of Computer Programs by Sussman; Domain-Driven Design by Evans; and The Timeless Way of Building by Christopher Alexander. First, we treat protocol like a language -  it has primitives, composition, and abstraction. The primitives are: nodes, packets, names, layers, standards, clients, defaults. These are the bottom layer of what the author is working with. Then you have composition -  the combining of primitives: TCP/IP and DNS, horizontal and vertical; browsers and RFCs, requests for comments; processes, meaning the standards bodies and how they interact; and implementations. The fundamental methods of abstraction -  you can think of these as meta-composition, or the workhorses of the domain: decentralized control at the highest level; compatibility gates; and the bilevel Internet, horizontal and vertical. These are all ways to reason about the problem inside the domain. As for the ubiquitous language: if you are going to create a framework, build something, or avoid talking past someone who is reasoning about these problems, one of the key takeaways from this book is that you want to name the rule surface. If you are debating freedom and control, name what is controlling you. Is it the standards bodies? Where exactly is the control happening?

[00:34:39]  B. Sovereign

Onto the exit and choke point analysis. A protocol choke point is a rule surface everyone must pass through to be recognized, routed, named, upgraded, or treated as compatible. If you cannot pass through it, you do not exist on the network. The names, clients, defaults, compatibility, and upgrades -  these are the actual choke points. They are not servers; they are rules. Who controls the namespace? Who is allowed to set the default client? Who writes the compatibility tests? This is where ultimate power sits. For our exit paths, common options are: forks, alternative namespaces, self-hosting, mirroring, encryption, alternate clients, and routing around bottlenecks. The sharpest fork example I can bring up here relates to blockchain technology. We will look at two specific chains: Bitcoin and Ethereum. Ethereum does hard forks by design -  the upgrade is the command. Non-upgraders are eventually disconnected from the network. The exit path is to stay on the old chain, but you are now on a separate network, which becomes Ethereum Classic. Bitcoin, by contrast, does soft forks -  backwards compatibility by design. A node runner can decide whether to enforce new rules, and if they refuse, they remain on the network. The exit path exists within the protocol, not outside it. It is the same word -  fork -  but the exit cost is fundamentally different. One forces a split; the other lets you stay and decide which side you back. Our Bitcoin-adjacent question is: what rules can users verify themselves? This is our framing, not necessarily Galloway's. But it goes to the point of which rules users can verify on their own, instead of trusting a central operator or an opaque default. And finally, the trade-off: there can be fragmentation, a UX burden, liquidity discovery, or governance costs. Exit is not free -  but not having an exit path means the protocol is a cage.

[00:38:01]  Watson

For our builder's usability critique and making control surfaces legible: this is really about user adoption. If you see a problem with standards bodies -  and that is where the control is -  how would you deal with it if you were building something and wanted maximum adoption? You want to expose protocol creation defaults in a happy path. How the standards body creates its defaults should be visible to everyone -  for example, a voting rule: the default is that one person has one vote. Everyone should be able to see that. Convention over configuration. You want to make standard creation inspectable and safe -  not hidden. Who can vote? How do you reach the point of voting? Think of Omakase: you go into a restaurant and the chef decides the meal. You want one method for instantiating the standards. In Bitcoin terms, that would be validation rules and the node's table of blocks. Each person can decide what rules they validate with. But the key here is a reference implementation -  when you are onboarding people, you want a reference implementation they can copy. Go back to standards bodies. If you could fork a standards body -  say, the W3C, the standards body for the web -  and you could see how they resolve conflicts and what their code of conduct is, then if you are building your own standards body, you want it to be forkable, easy to replicate, and to have a reference implementation for others to copy. Lean: test where users can identify who can break or change the connection, who can exclude whom from the network. That is a great test for finding where the power is. And then: worse is better, a visible control map. Who within the standards body has the control? Who sets the rules? Being able to see that -  that is the hidden architecture made legible. Questions to contemplate: Which rules define valid participation? Who controls the names, defaults, upgrades, and clients? What happens to incompatible users? That is a significant power area. And where is the counter-protocol path -  if you are trying to exploit and resist, how are you going to do that? The conclusion: decentralization changes where control lives. Protocol makes distributed networks possible, but compatibility is where the governance is. As a builder, can users see and contest the rule surface? If you take one thing away, take this: Protocol argues that decentralization does not end control -  it relocates control into standards, compatibility layers, and names. Galloway's argument is a diagnostic tool. Do not only ask who owns the server. Ask which rules define valid participation, who controls the names, defaults, upgrades, and clients, and what happens to the incompatible users. For builders, the translation is practical. Make the rule surface legible by default. Show all of these resources so that everyone can see and contest who decides who connects with whom. If you have any comments, leave them in the comment section and visit bitlemmas.com for past episodes and other information. We will see you next time. Thanks.