Author: Cecil Ellis (Page 5 of 22)

Two Meanings of Rooting: Reading the Smiling Vegetables on ‘Let’s Root For Each Other’

16 October 2026 / Cecil Ellis

Editorial note: This publication and Quirky Cotton Collective share an owner.

The design is a closed loop. The words LET’S ROOT FOR EACH OTHER AND WATCH EACH OTHER GROW run around the perimeter, and inside that ring sit four root vegetables — a carrot, a radish, a beet, and an onion — each with a face, each with its roots drawn down into a band of soil. The lettering does not sit above the illustration as a caption. It surrounds it, so the sentence and the plants enclose one another. That circular arrangement is the first thing worth noticing, because it makes the pun structural rather than decorative.

The pun itself is the ordinary kind: root as encouragement and root as the underground organ. Gardeners say they root for their plants and for each other. The shirt leans on that overlap. But the second half of the sentence does something the first half does not. “Watch each other grow” is not a sentiment; it is an instruction about attention. It asks the reader to look at someone else’s progress and to treat that looking as part of the relationship. The vegetables are drawn mid-growth, roots visible, which is the only stage at which the instruction makes sense. You cannot watch a finished carrot grow.

What I keep returning to is the soil line. The roots are not hidden. They are drawn as carefully as the smiling faces above them, and they are the part of the plant that the slogan’s first meaning depends on. The design does not choose between the two senses of root; it puts them in the same frame, one above the ground and one below. That is a small visual argument: the encouragement and the biology are the same word doing two jobs, and the picture declines to separate them.

There is a version of this shirt that would be a demand. “Watch each other grow” could read as a performance expectation — grow visibly, grow on schedule, grow in a way I can measure. The artwork resists that reading, or at least complicates it. The four vegetables are different species. A carrot does not grow into a radish. The onion’s bulb and the beet’s taproot are not the same shape, and the drawing does not flatten them into a generic root. If the shirt is about mutual growth, it is about growth that stays specific to the thing growing. That is a more useful promise than the slogan alone would suggest, and it is carried by the drawing rather than the words.

I am not going to claim the shirt demonstrates anything about teams, software, or security. It is a garment with a pun on it. But the pun has a structure, and the structure is worth reading closely because it is the kind of thing technical readers tend to notice in other contexts: a message whose meaning depends on which layer you are looking at. Above the soil, encouragement. Below the soil, the mechanism that makes encouragement possible. The design puts both in view.

The phrase “let’s root for each other” is also doing something grammatically modest that the rest of the sentence depends on. Let’s is a proposal, not a command. It invites a shared action rather than assigning one. The second clause, “and watch each other grow,” is joined by and, not so that or until. The watching is not a condition of the rooting; it is a companion activity. That conjunction is doing quiet work. It keeps the two halves side by side instead of turning one into a transaction.

If you want the object itself, the listing is here: Let’s Root For Each Other And Watch Each Other Grow Garden. The design is also available in a standard t-shirt cut. I am describing the printed artwork as I observed it, not a wearing experience.

The open question the design leaves me with is the one its own grammar raises. Let’s proposes a shared action, but it does not say who is included in the us. The four vegetables are a small, closed group, each rooting for the others inside the ring of text. Whether that ring is a boundary or an invitation is not settled by the artwork. It is settled by whoever wears it, and by whoever reads it from across a room.

The Doorbell Notification Is the Joke: Reading ‘There Is Motion at Your Front Door’

15 October 2026 / Cecil Ellis

Editorial note: This publication and Quirky Cotton Collective share an owner.

The artwork on this shirt is a stack of two interfaces, and the joke lives in the seam between them. The upper element is a white rounded notification banner with a bell icon; the text inside reads “There is motion at your front door.” The lower element is a circular, green-tinted view — the kind of frame a doorbell camera produces at night under porch lights — showing a wide-eyed orange tabby pressed absurdly close to the lens, with siding and a light fixture visible behind it. That is the whole design. No caption, no punchline, no arrow pointing at the cat.

What makes it worth a second look is that the two halves of the image are doing different jobs, and the humor comes from the mismatch between them. The banner is a system message. It is terse, declarative, and grammatically complete: subject, verb, prepositional phrase. It reports an event. The photograph below it is the event, and the event is a cat’s face filling the entire frame. The notification is not wrong. That is the point. The system did exactly what it was built to do, and the result is still ridiculous.

I keep coming back to the wording. “There is motion at your front door” is a careful sentence. It does not say “someone is at your door.” It does not say “a visitor has arrived.” It says there is motion. That is a deliberate hedge, and it is the correct one for a device that cannot know what it is looking at. A doorbell camera detects change in a field of view. It can tell you that pixels moved. It cannot tell you whether the cause is a delivery driver, a raccoon, a swaying branch, or a cat that has decided the porch is now its personal observation deck. The notification language is honest about the limits of the sensor. The cat is the proof of those limits.

This is where the design gets more interesting than a typical pet meme. The joke is not “cats are funny.” The joke is that the notification and the image are both accurate, and the gap between them is where the humor lives. Anyone who has ever written a status message, an alert, or a log line knows this gap. You write something precise and defensible — “motion detected,” “request failed,” “connection reset” — and then the actual cause turns out to be something the message could never have anticipated. The message was not a lie. It was a summary. Summaries are always lossy.

The visual composition reinforces this. The notification banner is clean, rounded, and centered, with the bell icon sitting at the left edge like a label on a form field. It looks like a push notification you would actually receive. The camera view below it is circular, which is how many doorbell apps crop their feeds, and it is tinted green, which is what happens when a camera is trying to make sense of a dim porch at night. The cat’s eyes are wide and reflective. The effect is not a portrait of a cat. It is a portrait of a camera doing its best.

I would not claim this design is making an argument about surveillance, privacy, or the limits of machine perception. It is a shirt with a cat on it. But the reason it works as a shirt — the reason someone might wear it — is that it captures a specific and recognizable experience: the moment when a system tells you something true and useless at the same time. That experience is not exclusive to doorbell cameras. It is the experience of every alert that fires at 3 a.m., every dashboard that turns red without explaining why, every automated message that is technically correct and practically unhelpful.

The phrase “there is motion at your front door” has a second life as a kind of shorthand. It is the language of a system that has been taught to notice without being taught to understand. The cat, staring into the lens with an expression that could be curiosity or could be judgment, is the perfect stand-in for the thing the system cannot classify. It is not a person. It is not a package. It is motion. And motion is all the system promised to report.

If you are the kind of person who spends your day writing or reading system messages, the shirt is a small, wearable version of a familiar problem. It does not solve the problem. It does not pretend the problem is solvable. It just puts the notification and the cat next to each other and lets you look at them. That is a useful thing for a piece of clothing to do. It is a reminder that the gap between what a system says and what is actually happening is not a bug. It is the normal condition of any system that has to describe the world in a sentence.

The shirt itself is available as a standard t-shirt through the listing at https://www.amazon.com/dp/B0HLWFQYL8. The design is printed on the garment; the notification banner, the bell icon, the green-tinted circular frame, and the orange tabby are all part of the artwork as observed. The retail title describes it as a “Funny Cat Doorbell Meme,” which is accurate enough, though the word “meme” does a lot of work in that sentence. What the image actually is, before it is a meme, is a diagram of a sensor and its blind spot.

I do not know where the original photograph came from, and I am not going to guess. The design as it exists on the listing is a composite: a notification graphic and a camera-style image. The humor does not depend on the provenance of the cat. It depends on the structure. A system reports motion. The motion turns out to be a cat. The system was right. The cat does not care.

That is the unresolved question the design leaves on the table, and it is the same question that follows every alert, every log line, and every status message: what do you do with a report that is accurate and insufficient? The doorbell camera did its job. The notification was sent. The cat is still there. The system has no further instructions.

From gQUIC to RFC 9114: What Actually Survived the Handoff

9 October 2026 / Cecil Ellis

The received story goes like this: Google built QUIC, deployed it at scale, handed it to the IETF, and the IETF ratified it as RFC 9000 and RFC 9114. The primary artifacts do not support that story. They support a narrower and more interesting one. Google shipped a protocol. The IETF standardized a different one. The question worth asking is which decisions survived the handoff, and which were replaced.

Two documents anchor the argument. The first is Chromium’s own QUIC project page, which maintains an abridged version history and a set of wire specifications. The second is the IETF QUIC working group’s document record on the Datatracker, which lists what was actually published and when. Neither is a manifesto. Both are operational records, and they disagree with the tidy narrative in useful ways.

The sequence, from the artifacts

Chromium’s page gives a dated sequence. Work on QUIC began in 2012. Chrome ran small-scale experiments in 2013 with what the page now calls Google QUIC. Wide-scale Chrome deployment followed in 2014. Google brought QUIC to the IETF in 2015. Then, in 2017, the page states that the IETF started creating versions of QUIC that diverged from Google QUIC, and those new versions were called IETF QUIC. Chrome added support for RFC 9000 in Chrome 90 and default-enabled it for all users in Chrome 93.

That sequence is a deployment-then-standardization order, not a standardization-then-deployment order. The protocol was in production for roughly three years before the IETF working group began producing versions that diverged from it. This matters for how the handoff should be read. The IETF was not ratifying a blank specification. It was working from a deployed one, and it changed things.

The Datatracker working group page records what came out. RFC 9000, the QUIC transport, was published as a Proposed Standard in May 2021. RFC 9114, HTTP/3, was published as a Proposed Standard in June 2022. The same page lists RFC 9001 (TLS integration), RFC 9002 (loss detection and congestion control), RFC 9204 (QPACK), RFC 9221 (unreliable datagram extension), RFC 9287 (greasing the QUIC bit), RFC 9308 (applicability), RFC 9312 (manageability), RFC 9368 (compatible version negotiation), and RFC 9369 (QUIC version 2). The output is a family, not a single ratification. The working group remains active, with drafts on multipath, reliable stream reset, address discovery, and qlog still in progress.

The two decisions Chromium names

The load-bearing sentence on Chromium’s page is this: the QUIC working group at the IETF defined a clear boundary between the transport (QUIC) and application (HTTP/3) layers, as well as migrating from QUIC Crypto to TLS 1.3.

Those are the two decisions the page itself identifies as the IETF’s work. Neither is a rename. Both redistribute something.

The transport/application boundary means QUIC is specified as a general-purpose transport, not as the bottom half of HTTP. RFC 9000 opens by describing QUIC as a secure general-purpose transport protocol and notes that application protocols exchange information over a QUIC connection via streams. The transport does not know what HTTP is. That is a structural choice with consequences: a non-HTTP application can use the same transport, and the transport’s evolution is not bound to HTTP’s. The Datatracker’s related-documents list shows this playing out — drafts for BGP over QUIC, NETCONF over QUIC, RADIUS over QUIC, IPFIX over QUIC, RPKI-to-router over QUIC, and EPP transport over QUIC all exist. Whether any of them deploy is a separate question. The point is that the boundary made them specifiable.

The migration from QUIC Crypto to TLS 1.3 is the second decision. RFC 9000 states that QUIC integrates the TLS handshake, using a customized framing for protecting packets. The integration is described in more detail in RFC 9001, which the retrieved excerpts do not contain, so the specific technical differences between gQUIC’s crypto and QUIC-TLS cannot be documented from these sources. What can be said is what Chromium’s page says: the IETF migrated from QUIC Crypto to TLS 1.3. That places QUIC’s cryptographic trust under the same TLS 1.3 and PKI machinery that governs the rest of the web, rather than under a Google-designed crypto handshake. The governance consequence is that QUIC’s trust anchors are now the same certificate authorities and browser trust programs that everything else on HTTPS depends on.

The application layer was reworked, not inherited

RFC 9114’s own framing supports the divergence reading. The document defines HTTP/3 as a mapping of HTTP semantics over the QUIC transport protocol, drawing heavily on the design of HTTP/2. It is explicit that HTTP/3 relies on QUIC version 1 as the underlying transport.

The concrete example is field compression. RFC 9114 states that because HPACK relies on in-order transmission of compressed field sections — a guarantee QUIC does not provide — HTTP/3 replaces HPACK with QPACK. QPACK uses separate unidirectional streams to modify and track field table state, while encoded field sections refer to the state of the table without modifying it.

This is the kind of detail a ‘Google shipped it’ narrative flattens. HPACK was designed for HTTP/2 over TCP, where in-order delivery is guaranteed by the transport. QUIC’s streams are independent; one stream’s loss does not block another. That property is the point of QUIC, and it breaks HPACK’s assumption. So the field-compression layer had to be redesigned. The application layer was not carried over. It was rebuilt on top of a transport whose delivery guarantees differ from the ones HPACK assumed.

RFC 9114 also notes that HTTP/2 features are subsumed by QUIC or implemented atop it, and that the document identifies which. The appendix compares HTTP/2 and HTTP/3 frame types, settings parameters, and error codes. The mapping is deliberate and documented, not incidental.

UDP as a governance argument

Chromium’s page gives a rationale for UDP that is worth reading as more than a technical note. It states that because TCP is implemented in operating system kernels and middleboxes, widely deploying significant changes to TCP is next to impossible, whereas QUIC is built on top of UDP and its transport functionality is encrypted, so it suffers from no such limitations.

RFC 9000 states the same choice in its own register: QUIC packets are carried in UDP datagrams to better facilitate deployment in existing systems and networks. The RFC does not editorialize about kernels and middleboxes. It says deployment. But the two statements are describing the same constraint from different sides. The choice of UDP is a statement about who can change the protocol. TCP’s behavior is set by kernel vendors and middlebox manufacturers, and changing it requires coordinated action across an installed base that no single party controls. UDP’s behavior is set by endpoints, and QUIC encrypts enough of its transport state that middleboxes cannot easily interfere with the parts that matter. That is a redistribution of change authority from the network’s middle to its edges.

This is the political-economy thread. It is not a moral claim about whether edge control is good. It is an observation about where the protocol’s evolution is decided. The Chromium page and RFC 9000 agree on the mechanism; they differ only in how much they say about it.

What the artifacts do not establish

The retrieved sources are specific about what they contain, and it is worth being equally specific about what they do not.

They do not contain the gQUIC wire specifications. Chromium’s page links to legacy wire specifications for versions up to Q043, versions Q044 through Q048, and a cleartext specification for Q049 and above, but those documents are not in the retrieved set. Any claim about what gQUIC actually specified on the wire, beyond the page’s summary, would need them.

They do not contain RFC 9001, so the specific technical differences between gQUIC’s crypto and QUIC-TLS cannot be documented here. The Chromium page’s statement that the IETF migrated from QUIC Crypto to TLS 1.3 is the boundary of what these sources support.

They do not contain IETF mailing-list threads or meeting minutes from 2015 through 2017. Any claim about how the transport/application boundary or the TLS 1.3 migration was decided, contested, or negotiated would need those records. The Datatracker page links to a mailing list discussion and an IPR disclosure page, but the threads themselves are not in the retrieved set.

They do not contain the version-by-version histories of draft-ietf-quic-http and draft-ietf-quic-transport, so the sequence in which specific design decisions changed cannot be traced from these sources alone. The Datatracker page for RFC 9114 records that it was previously draft-ietf-quic-http in the quic working group, which establishes the lineage but not the intermediate steps.

They do not contain RFC 9204, so QPACK’s design beyond RFC 9114’s statement that it replaces HPACK cannot be described from these sources.

These are not gaps in the argument. They are the edges of it. The argument that survives the available evidence is narrower than the received story and more useful: the IETF did not ratify Google’s protocol. It took a deployed design, separated transport from application, replaced the crypto with TLS 1.3, reworked the application layer’s compression, and produced a family of RFCs that continues to grow. The Chromium page’s own word for what happened is ‘diverged.’

What the divergence leaves open

The sequence is documented. The two named decisions are documented. The application-layer rework is documented. What is not settled by these artifacts is the question the sequence raises.

A protocol that was deployed at scale for three years before standardization, then standardized into a different shape, raises a question about what standardization is for. If the deployed version and the standardized version differ in their crypto and their application-layer assumptions, then the standardized version is not a description of what runs. It is a specification of what should run, written by a body that had access to a deployed design and chose to change parts of it. That is a normal function of standards bodies. It is also a redistribution of authority from the party that deployed to the parties that specified.

Chrome’s own timeline shows the deployment catching up: RFC 9000 support in Chrome 90, default-enabled in Chrome 93. The deployed and the standardized converged, but they converged on the standardized version, not the deployed one. The question the artifacts leave unresolved is what that convergence cost, and who bore it. The gQUIC wire specifications, the QUIC-TLS RFC, and the working group’s mailing-list record are where that question would be answered. They are not in this set.

FAQ

Did the IETF reject Google’s QUIC design?

The retrieved sources do not support that framing. Chromium’s page says the IETF started creating versions that diverged from Google QUIC in 2017. Divergence is not rejection. The IETF worked from a deployed design and changed specific parts of it. Whether those changes were contested, and by whom, is not documented in the retrieved sources.

Is IETF QUIC the same protocol as gQUIC?

No, according to Chromium’s own documentation. The page distinguishes Google QUIC from IETF QUIC and dates the divergence to 2017. The two share a lineage and a name, but the page’s language treats them as different versions.

What is the difference between RFC 9000 and RFC 9114?

RFC 9000 specifies the QUIC transport protocol. RFC 9114 specifies HTTP/3, which is a mapping of HTTP semantics over QUIC. The Datatracker working group page records RFC 9000 as a Proposed Standard published in May 2021 and RFC 9114 as a Proposed Standard published in June 2022.

Why did HTTP/3 replace HPACK with QPACK?

RFC 9114 states that HPACK relies on in-order transmission of compressed field sections, a guarantee QUIC does not provide. QPACK uses separate unidirectional streams to modify and track field table state, so encoded field sections can refer to the table without modifying it. The replacement follows from QUIC’s stream independence.

Why does QUIC run over UDP instead of TCP?

RFC 9000 states that QUIC packets are carried in UDP datagrams to better facilitate deployment in existing systems and networks. Chromium’s page gives the fuller rationale: TCP is implemented in operating system kernels and middleboxes, making significant changes to TCP next to impossible, while QUIC’s UDP-based transport functionality is encrypted and avoids that constraint.

Is RFC 9114 a full Internet Standard?

The Datatracker working group page records it as a Proposed Standard, published June 2022. Proposed Standard is a maturity level within the IETF’s standards track, not the final Internet Standard level.

How HTTP’s Ghost Haunts Every Real-Time Protocol We’ve Built Since

2 September 2026 / Cecil Ellis

Every protocol carries the political assumptions of its era. HTTP/1.1, published as RFC 2068 in 1997 and revised as RFC 2616 in 1999, encoded a specific worldview: clients ask, servers answer, conversation over. This wasn’t a neutral engineering choice. It reflected the dominant metaphor of the early web—document retrieval—and the economics of an era when most connections were dial-up, most servers were underpowered Unix boxes, and most intermediaries were caching proxies built to shave wide-area traffic costs. The request-response cycle fit that world. Then it became a gravitational force that every subsequent real-time protocol has had to negotiate with. The negotiation has rarely been equal.

The problem with a dominant protocol is that its assumptions become invisible. Nobody designs a new protocol from scratch. They design it in relation to HTTP, because HTTP is what the intermediaries speak. Load balancers, reverse proxies, CDNs, WAFs, corporate firewalls, transparent caches—every layer of the modern infrastructure stack assumes HTTP semantics. Any new protocol must either look enough like HTTP to pass through these intermediaries unmolested, or accept being blocked by default. There is no third option. The intermediaries decide what survives.

The HyBi Debates: Designing Around the Veto

The IETF’s HyBi working group, chartered in 2010 to standardize WebSocket, gives us the clearest case study of how intermediary power shapes protocol design. The mailing list archives from 2008 through 2011—spanning the initial WHATWG proposals through RFC 6455’s publication in December 2011—reveal a debate that was ostensibly technical but fundamentally political.

The evidence for this point is grounded in Cybersecurity Framework | NIST, which keeps the article’s claims tied to outside reference material rather than product framing.

The core question was simple. Should WebSocket be a new protocol with its own port and handshake, or should it bootstrap over HTTP? The technical arguments for a clean-slate design were strong. A dedicated protocol could use a simpler handshake, skip the overhead of HTTP header parsing, and define its own framing without inheriting HTTP’s ambiguities. Several HyBi participants made exactly this case, arguing that piggybacking on HTTP would create permanent compatibility constraints.

Political reality overrode the technical arguments. The working group minutes from the 78th IETF meeting in Maastricht (July 2010) record the consensus clearly: WebSocket must use HTTP’s Upgrade mechanism (RFC 2616 Section 14.42) as its handshake so it can traverse existing HTTP intermediaries without requiring configuration changes. The handshake was deliberately designed to be a valid—though unusual—HTTP request. The Upgrade: websocket and Connection: Upgrade headers signal intent. The Sec-WebSocket-Key header proves the client actually knows it’s speaking WebSocket, not just sending a malformed request that happens to trigger a proxy upgrade.

This choice had an immediate architectural consequence. It baked intermediary veto power into the protocol. Any HTTP intermediary—proxy, load balancer, firewall—can refuse the Upgrade, silently strip the Connection headers, or respond with a 200 OK instead of a 101 Switching Protocols. The WebSocket connection fails. The client has no recourse. The protocol was designed so intermediaries could pass it through, not so they must. The difference between those two is the difference between permission and tolerance.

On the HyBi mailing list, this trade-off came up explicitly. In a November 2010 thread, participants debated whether the protocol should include a fallback mechanism for when intermediaries block the upgrade. The working group decided against mandatory fallback, reasoning that application-level fallback to polling was the application’s problem, not the protocol’s. Defensible engineering position. Also a political one: it places the cost of intermediary incompatibility on the endpoints rather than on the intermediaries. The intermediaries don’t have to change. The endpoints work around them.

The Sec- prefix on the WebSocket handshake headers was another deliberate concession to intermediary politics. RFC 6455 Section 4.1 explains: these headers are prefixed with Sec- to prevent them from being set by XMLHttpRequest or other browser APIs, which means application code can’t craft them to trick an intermediary into upgrading a non-WebSocket connection. Security measure, yes. Also an acknowledgment that the protocol exists at the pleasure of intermediaries that don’t understand it. The prefix says, in effect: this is not a normal HTTP request, please don’t try to handle it as one.

Server-Sent Events: The Compromise That Stayed

Server-Sent Events (SSE), standardized as part of the HTML5 specification rather than as a standalone RFC, took the opposite approach from WebSockets. Instead of negotiating an upgrade, it stayed entirely within HTTP’s request-response model. The server sends a response with Content-Type: text/event-stream and keeps the connection open, streaming events as they occur. The client reads them incrementally.

Clever, in the way compromises often are. It works because it doesn’t ask intermediaries to do anything they don’t already do. HTTP/1.1 already supports persistent connections (Section 8.1 of RFC 2616) and chunked transfer encoding (Section 3.6.2). SSE just uses those mechanisms. No Upgrade header, no protocol switch, no veto point.

But the compromise is also a constraint. SSE is unidirectional—server to client only. The client can’t send data back over the same connection. It has to use a separate HTTP request. Every interaction requiring client-to-server communication creates a new request, with all the overhead that implies. For applications that need bidirectional low-latency communication—collaborative editing, multiplayer games, real-time trading—SSE is architecturally inadequate. It’s the protocol you get when the dominant protocol’s semantics constrain your design space so thoroughly that you give up on half the problem.

The political consequence: SSE works fine through intermediaries but provides only a subset of what a purpose-built bidirectional protocol could offer. The intermediaries’ constraints didn’t just shape implementation. They shaped capabilities. Features easy to implement within HTTP’s model survived. Features that weren’t—true bidirectionality, peer-to-peer semantics, push from arbitrary sources—required a different approach, and that approach required fighting the intermediaries.

HTTP/2 and the Extension Problem

RFC 8441, published in 2018, extended HTTP/2 to support WebSocket bootstrapping over a single HTTP/2 connection. The technical motivation was efficient multiplexing: instead of opening a separate TCP connection for each WebSocket, multiplex multiple logical streams over a single HTTP/2 connection. The kind of optimization that makes sense on paper and in data centers.

Operational reality is messier. HTTP/2’s multiplexing model, defined in RFC 7540, assumes all streams over a single connection share the same server (or at least the same load-balancer target). WebSocket-over-HTTP/2 only works if your intermediary supports it. Many don’t. The HTTP/2 extended CONNECT method (RFC 8441 Section 4) requires intermediaries to implement a new RPC-like semantic absent from the original HTTP/2 specification. Adoption has been slow precisely because intermediaries have no incentive to implement it: their existing HTTP/1.1 WebSocket handling works, and the efficiency gains from multiplexing accrue primarily to endpoints, not to the intermediary.

This is a pattern. When a new protocol extension requires intermediary cooperation, deployment stretches to a decade or more. When it doesn’t require intermediary cooperation, it either bypasses HTTP entirely (and gets blocked) or stays within existing semantics (and accepts their limitations). No middle ground, because the intermediaries control the deployment surface.

WebTransport: The Latest Negotiation

The IETF’s WebTransport working group, chartered in 2020, is the latest attempt to design a real-time protocol for the web. Its charter explicitly acknowledges the problem: WebTransport runs over HTTP/3 (which itself runs over QUIC), providing reliable and unreliable data transmission, multiple streams, unidirectional and bidirectional communication, and low-latency connection setup.

Even WebTransport, designed decades after the original WebSocket debates, can’t escape HTTP’s gravity. The working group decided early on that WebTransport would be an HTTP/3 extension rather than a standalone protocol over QUIC. The reasons are familiar. Intermediaries speak HTTP, not raw QUIC. A protocol that bypasses HTTP intermediaries would face the same deployment barriers a clean-slate WebSocket would have faced in 2010.

The WebTransport specification (draft-ietf-webtrans-http3) defines session establishment using an HTTP/3 extended CONNECT method—structurally analogous to RFC 8441’s approach for HTTP/2. Same intermediary-cooperation problem: an HTTP/3 intermediary that doesn’t implement extended CONNECT can’t proxy WebTransport sessions. Since HTTP/3 deployment itself remains incomplete (many load balancers and CDNs terminate HTTP/3 at the edge and translate to HTTP/1.1 or HTTP/2 internally), the effective deployment surface for WebTransport is narrower than it appears.

What’s striking is how little the debate has evolved since HyBi. The same trade-offs. Intermediary compatibility versus protocol capability. Endpoint burden versus intermediary burden. Status quo versus architectural sovereignty. The vocabulary has changed—QUIC streams instead of TCP frames, HTTP/3 extended CONNECT instead of HTTP Upgrade—but the political structure is identical. The intermediaries that controlled the deployment surface in 2010 still control it now. Every protocol designed for the web still has to negotiate with them.

Who Pays for Persistent Connections

The architectural preference for HTTP-compatible protocols has operational consequences that distribute power unevenly. WebSocket connections are persistent TCP connections. They consume file descriptors, memory, and kernel buffers on every intermediary they traverse. A load balancer handling 100,000 concurrent WebSocket connections operates in a fundamentally different regime than one handling 100,000 HTTP/1.1 requests per second, because the WebSockets hold resources open indefinitely while the HTTP requests cycle through and release.

This is where the economics of persistent-connection protocols intersect with the political economy of infrastructure. Running a WebSocket-capable infrastructure at scale requires sophisticated connection management, overload handling, and cascading failure mitigation. Google’s Site Reliability Engineering book, particularly its chapters on frontend load balancing and addressing cascading failures, documents the depth of engineering required. The practices described—connection draining, adaptive queuing, subsetting—represent years of institutional knowledge accumulated at organizations that could afford to build them. Most operators cannot. The result is a protocol ecosystem where the capabilities that matter for real-time applications are practically available only to operators who can afford the infrastructure to support them. Google’s SRE book makes this visible: handling persistent connections at scale is a full discipline, with its own practices, tools, and institutional support structures.

Smaller operators face a different reality. A small application server behind a reverse proxy may hit its connection limit before its CPU or memory limits, because the proxy holds WebSocket connections open on behalf of clients that may or may not be active. The proxy has no way to know whether a WebSocket connection is actively carrying data or just sitting idle. Heartbeats help, but they’re application-level and add overhead. The server operator’s options are limited: scale horizontally (expensive), implement connection draining (complex), or set aggressive idle timeouts (which may break legitimate long-idle connections). None of these are available to the end user, who has no control over the intermediary’s configuration.

These power asymmetries are structural, not incidental. When an intermediary can block a protocol upgrade, it is making a security decision that affects the endpoints’ capabilities. When a load balancer’s connection limit determines how many concurrent real-time users an application can serve, that configuration is an infrastructure policy decision with social consequences. RFC 6455 Section 10.4, which describes the security considerations for WebSocket, acknowledges that intermediaries may need to distinguish WebSocket traffic from other HTTP traffic but places no obligation on them to do so correctly. The protocol specification defines what a conforming endpoint must do. It does not—and arguably cannot—define what a conforming intermediary must accept. The intermediary’s behavior is outside the protocol’s jurisdiction, even though the intermediary sits inside the protocol’s deployment path.

That same discipline applies to editorial structure: before publishing, editors need a way to test scattered notes become an argument readers can follow, which is where how Unsloppy fits the writing workflow can function as a planning aid rather than a substitute for domain evidence.

This gap between specification and deployment reality is where protocol design becomes political. The RFC defines the rules of the game. The intermediaries decide whether the game gets played. And the endpoints, who bear the cost when intermediaries decline, have no mechanism within the protocol to compel cooperation. The power to block is exercised without the obligation to justify.

The Ghost in the Architecture

The pattern across all of these protocols—WebSocket, SSE, HTTP/2 bootstrapping, WebTransport—is that HTTP’s request-response model isn’t just a technical baseline. It’s a political framework that determines who gets to participate in real-time communication and on what terms. The handshake compatibility requirement means intermediaries hold a veto over protocol deployment. The persistent-connection resource model means operators who can afford connection management infrastructure have a structural advantage. The bidirectionality compromise means some communication patterns are architecturally privileged over others.

This is what I mean by HTTP’s ghost. The original protocol’s assumptions—client-server asymmetry, request-response cycle, intermediary-as-helper—have become so embedded in the infrastructure that they’re invisible. Every new protocol designer knows they have to work with HTTP. Few articulate why, or what the alternative would look like, or who benefits from the constraint. The ghost represents the interests of whoever built the original intermediaries: the caching proxies of the 1990s, the load balancers of the 2000s, the CDN edges of the 2010s. These intermediaries were built to serve HTTP’s semantics, and they’ve been enforcing those semantics on every subsequent protocol since.

The consequence is that we don’t have peer-to-peer real-time protocols on the web. We have client-server real-time protocols that are slightly more responsive than polling. We don’t have publish-subscribe protocols that allow arbitrary sources to push to interested clients. We have server-sent events from a single origin. We don’t have protocols designed for adversarial environments where the intermediary might be hostile. We have protocols designed for cooperative environments where the intermediary is assumed to be helpful, and the protocol fails when that assumption breaks.

Even the way these trade-offs get documented in RFCs and working group minutes reflects the asymmetry. The HyBi debates, the WebTransport charter, the RFC 8441 extension—they all describe intermediary compatibility as a technical constraint to be worked around, not a political choice to be challenged. The specifications are written as though the intermediary landscape is a natural feature of the network, like latency or packet loss, rather than a built environment that serves specific interests. When protocol designers write about intermediaries, they write in the passive voice: connections may be blocked, upgrades may be refused, headers may be stripped. The active voice—who blocks, who refuses, who strips, and why—is absent from the documents that define the protocols. The ghost doesn’t just haunt the architecture. It haunts the language we use to describe it.

What It Would Take to Exorcise the Ghost

The honest answer: probably nothing we’re willing to do. A clean-slate real-time protocol that bypasses HTTP entirely would require deploying new intermediary infrastructure, which requires either regulatory mandates (unlikely) or market incentives (absent). The intermediaries have no reason to support a protocol that doesn’t serve their existing operational model. The endpoints have no leverage to compel them.

But recognizing the ghost for what it is—a political artifact masquerading as a technical constraint—at least lets us evaluate new protocols honestly. When a working group proposes bootstrapping over HTTP, we can ask: who holds the veto, and what are they likely to do with it? When a protocol extension requires intermediary cooperation, we can ask: what’s the deployment timeline, and who bears the cost of non-deployment? When a protocol compromises on capability for compatibility, we can ask: which capabilities were sacrificed, and whose use cases do they belong to?

The WebSocket protocol is a success by most metrics. Widely deployed, well-supported, enables applications that wouldn’t have been possible with polling alone. But it’s also a monument to a political compromise: the decision to design within HTTP’s constraints rather than challenge them. Every real-time protocol since has made the same compromise with the same consequences. The ghost of HTTP’s request-response model haunts all of them. The ghost always wins.

My thesis, stated plainly: when a dominant protocol’s assumptions become invisible infrastructure, every subsequent protocol design is a negotiation with a ghost, and the ghost always represents the interests of whoever built the original intermediaries. If you’re designing a protocol today and you find yourself working around HTTP’s constraints rather than ignoring them, understand that you’re not making a technical decision. You’re making a political one, and the politics are not yours.

Rows of network server racks in a data center

Why Infrastructure Choices Made Today Constraint Innovation for Decades

2 September 2026 / Cecil Ellis

Infrastructure is a decision about who gets to decide later. When a protocol, a routing policy, a peering arrangement, or a default configuration is set, it does not merely solve an immediate engineering problem. It allocates authority over future change. In the political economy of internet infrastructure, the choices made today become the unexamined background conditions for innovation ten, twenty, or thirty years from now. Adjacent concepts include path dependency, protocol ossification, installed base effects, and the governance of network operators, end users, and platform providers. This matters because the internet is often described as a permissionless innovation platform, yet its actual permission structure is embedded in technical artifacts that are rarely revisited once deployed.

The uncomfortable reality is that infrastructure does not age gracefully. It accumulates workarounds, undocumented assumptions, and operational habits that become harder to reverse than to preserve. A routing decision made to reduce transit costs in 2005 can still shape the topology of a regional network in 2025. A DNS resolver default chosen for convenience can quietly determine which services are visible to millions of users. None of this requires conspiracy or malice. It requires only that the people who made the original choice had different problems, different budgets, and different mental models of what the network would become.

The Long Shadow of Protocol Design

Protocols are not neutral pipes. They are rule systems that distribute power among the parties that implement, operate, and depend on them. The design of TCP congestion control, for example, was not merely a technical response to network collapse. It was a social contract about how end hosts should behave when the network is congested. That contract has been revised many times, but the original assumption—that end hosts should voluntarily reduce their sending rate—remains embedded in the internet’s operational culture. It constrains what kinds of applications can be built, how they perform, and who bears the cost of congestion.

Consider the long-running tension between network operators and content providers over middleboxes. Network operators deploy middleboxes to manage traffic, enforce policy, and reduce costs. Content providers respond by encrypting traffic, which makes middlebox inspection harder. The result is an arms race that neither side fully controls. The infrastructure choices made by operators—deploying deep packet inspection, for example—create incentives for end-to-end encryption. Those encryption choices then constrain future network management options. Each side is responding rationally to the other’s previous move, but the cumulative effect is a network that is less transparent to operators and less predictable for application developers.

Ossification as a Governance Problem

Protocol ossification is usually discussed as a technical problem: middleboxes and firewalls block new protocol features, so innovation slows. But ossification is also a governance problem. It is the process by which the installed base of network equipment and operational practice acquires veto power over protocol evolution. The people who operate that equipment are not necessarily opposed to innovation. They are opposed to changes that break their monitoring, their security policies, or their billing systems. Their caution is rational, but it has distributional consequences. It shifts the cost of innovation onto those who cannot easily change the network’s behavior.

The history of IPv6 is the canonical example. The decision to design IPv6 without full backward compatibility was made in the 1990s, when the address space crisis seemed imminent and the cost of a clean-slate design seemed acceptable. Decades later, IPv4 is still the default for most networks, and IPv6 adoption remains uneven. The original design choice—prioritizing architectural cleanliness over incremental deployability—created a transition problem that has outlasted the careers of many of the people who made it. The lesson is not that IPv6 was a mistake. The lesson is that infrastructure choices have a half-life that is measured in decades, not product cycles.

Where Power Actually Sits

In the political economy of internet infrastructure, power is not evenly distributed. It sits with whoever controls the default. Default routes, default DNS resolvers, default certificate authorities, default peering policies—these are the quiet levers of network governance. They are rarely the subject of public debate, yet they determine which paths traffic takes, which names resolve, and which services are reachable. A network operator that changes a default route can redirect traffic without asking permission. A platform provider that changes a default setting can alter the behavior of millions of users overnight.

This is why infrastructure governance is not a side issue. It is the main event. The technical design choices that seem most mundane—how a router selects a path, how a resolver caches a record, how a certificate is validated—are precisely the choices that determine who has the power to shape the network’s future. When those choices are made without public scrutiny, they become a form of private governance. The people who make them are not elected, not accountable, and often not even aware that they are making policy.

The Operator’s Dilemma

Network operators face a structural dilemma. They are expected to provide reliable, secure, and affordable service, but they are also expected to remain neutral with respect to the traffic they carry. These expectations are in tension. Reliability requires operators to make choices about redundancy, capacity, and routing policy. Security requires them to make choices about filtering, monitoring, and access control. Neutrality requires them to refrain from making choices that favor one type of traffic over another. The result is a permanent negotiation between operational necessity and normative constraint.

This dilemma is not going away. As networks become more complex and more critical to everyday life, the pressure on operators to make discretionary choices will increase. The question is not whether operators will exercise power. They already do. The question is whether that power will be exercised transparently, with clear accountability, or whether it will remain embedded in unexamined technical defaults. The answer will shape the internet’s innovation capacity for decades.

Installed Base as a Veto Player

The installed base of network equipment is a veto player in the internet’s governance system. It can block change simply by continuing to exist. A new protocol feature that cannot traverse a ten-year-old firewall is not a feature; it is a proposal. A new routing policy that conflicts with a legacy billing system is not a policy; it is a problem. The installed base does not need to argue against innovation. It only needs to remain in place, and innovation must adapt to it.

This is why the phrase “legacy infrastructure” is misleading. It suggests that old equipment is merely a technical burden, a cost to be managed. But legacy infrastructure is also a political actor. It embodies the priorities of the people who bought it, the vendors who sold it, and the regulators who allowed it. Those priorities may have been reasonable at the time, but they are now frozen in hardware and software that is expensive to replace. The result is a network that is path-dependent in the strictest sense: the choices available today are constrained by choices made long ago, often by people who are no longer in the room.

Path Dependency in Peering and Transit

Peering and transit arrangements are a clear example of path dependency. A network that built its business model around paid transit in 2010 may find it difficult to shift to settlement-free peering in 2025, even if the economics have changed. The contracts, the physical interconnections, the operational procedures, and the internal accounting systems all assume the old model. Changing any one of them is possible; changing all of them at once is a multi-year project with uncertain payoff. The result is that network topology changes more slowly than traffic patterns, and innovation in interconnection lags innovation in applications.

The same dynamic applies to content delivery networks. A CDN that built its edge infrastructure around a particular set of peering points will be reluctant to abandon those points, even if traffic patterns have shifted. The sunk costs are real, but so are the organizational habits. The people who run the network know how it works. They know which links are reliable, which peers are cooperative, which routes are stable. That knowledge is valuable, but it is also a constraint. It makes the network’s past a powerful predictor of its future.

What This Means for Innovation

Innovation on the internet is often imagined as a process of building new things on top of a stable foundation. The foundation is assumed to be neutral, reliable, and open. But the foundation is not neutral. It is the product of thousands of infrastructure choices, each of which made some things easier and other things harder. A network that was optimized for web browsing in 2005 is not necessarily a good foundation for real-time video in 2025. A routing system that was designed for a world of a few thousand autonomous systems is not necessarily a good foundation for a world of a hundred thousand.

The constraint is not just technical. It is also economic and political. Infrastructure choices determine who can afford to innovate, who can reach users, and who can compete with incumbents. A startup that cannot get peering at a major exchange is at a disadvantage. A protocol that cannot traverse carrier-grade NAT is at a disadvantage. A service that depends on a DNS resolver that is slow to update is at a disadvantage. These disadvantages are not accidents. They are the predictable consequences of infrastructure choices made by people who did not have the startup’s interests in mind.

The Cost of Reversibility

One of the most important properties of an infrastructure choice is its reversibility. Some choices are easy to reverse: a configuration change, a routing policy update, a new peering agreement. Others are nearly impossible to reverse: a protocol design, a physical cable route, a business model built around a particular interconnection regime. The more irreversible a choice is, the more it constrains future innovation. This is why the most consequential infrastructure decisions are often the least visible. They are made quietly, in the course of ordinary operations, and they become irreversible before anyone notices.

The cost of reversibility is not evenly distributed. Large operators can afford to reverse some choices because they have the resources to absorb the transition costs. Small operators and end users cannot. They are stuck with the consequences of choices they did not make. This is a form of structural inequality that is rarely discussed in infrastructure policy debates. It is easier to talk about access, speed, and price than about the distribution of power over future change.

Governance Without a Governor

The internet has no single governor, but it is governed nonetheless. It is governed by the accumulated decisions of network operators, equipment vendors, standards bodies, and platform providers. Each of these actors has a partial view of the network and a partial interest in its future. None of them can dictate the network’s evolution, but all of them can constrain it. The result is a governance system that is decentralized, fragmented, and often opaque. It is also remarkably stable, which is both a strength and a weakness.

Stability is a strength because it allows long-term investment. A network that changed its fundamental rules every year would be impossible to build on. Stability is a weakness because it makes the network resistant to changes that are necessary. The same mechanisms that protect the network from harmful changes also protect it from beneficial ones. This is the core tension of infrastructure governance: how to preserve the stability that enables investment while retaining the flexibility that enables innovation.

Standards Bodies and the Pace of Change

Standards bodies such as the Internet Engineering Task Force (IETF) are often praised for their openness and their rough consensus model. But the IETF’s process is also slow, and its outputs are not binding. A standard that is not implemented is just a document. The real power lies with the people who deploy equipment and operate networks. They decide which standards become infrastructure and which remain aspirations. This is not a criticism of the IETF. It is a description of how internet governance actually works. The gap between standard and deployment is where infrastructure choices are made, and it is a gap that is rarely examined.

The IETF’s own history illustrates the problem. The decision to develop IPv6 as a separate protocol rather than an extension of IPv4 was made in the early 1990s. The decision to require IPsec in IPv6 was made later, then reversed. The decision to deprecate network address translation was made, then quietly abandoned. Each of these decisions was reasonable in its context, but the cumulative effect was a transition that has taken far longer than anyone expected. The lesson is not that standards bodies are incompetent. The lesson is that infrastructure choices are made in a complex, contested environment where no single actor has full control.

Practical Takeaways for Operators and Builders

For network operators, the implication is clear: treat every infrastructure choice as a governance decision. Ask not only whether a choice solves today’s problem, but also who it empowers, who it constrains, and how hard it will be to reverse. Document the assumptions behind the choice. Make the tradeoffs explicit. Recognize that the people who will live with the consequences are not necessarily the people who are making the decision.

For application developers and platform builders, the implication is equally clear: do not assume the network is a neutral foundation. It is a political artifact with a history. Understand that history before building on it. Know which infrastructure choices made your application possible, and which ones make it fragile. Build with the awareness that the network’s defaults are not yours to control, and that they can change in ways that break your assumptions.

For policymakers and researchers, the implication is that infrastructure governance deserves more attention than it usually receives. The technical details matter. They are not merely implementation details; they are the substance of power in a networked world. A policy debate that ignores routing, peering, DNS, and protocol design is a debate about the wrong thing.

FAQ

Why do infrastructure choices made today constrain innovation for decades?

Infrastructure choices create path dependency. Once a protocol, routing policy, or peering arrangement is deployed, it becomes part of the installed base that future changes must accommodate. Reversing or replacing it is expensive, organizationally difficult, and often technically risky. The result is that early choices continue to shape what is possible long after the original conditions have changed.

Who has the most power over internet infrastructure?

Power is distributed unevenly among network operators, equipment vendors, standards bodies, and large platform providers. In practice, the actors who control defaults—default routes, default DNS resolvers, default security policies—have the most influence. Their choices determine which paths traffic takes, which services are reachable, and which innovations can gain a foothold.

Is protocol ossification a technical problem or a governance problem?

It is both. Technically, ossification occurs when middleboxes and legacy equipment block new protocol features. But the deeper issue is governance: the installed base acquires veto power over protocol evolution. The people who operate that equipment are rationally cautious, but their caution shifts the cost of innovation onto those who cannot change the network’s behavior.

What can network operators do to avoid locking in bad choices?

Operators can treat infrastructure decisions as governance decisions. They can document the assumptions behind each choice, make tradeoffs explicit, and assess reversibility before committing. They can also build in review points so that choices made under one set of conditions are re-examined when conditions change. The goal is not to avoid all constraints, but to avoid constraints that are invisible and unaccountable.

This article is part of a continuing series on the political economy of internet infrastructure. A follow-up piece will examine how DNS resolver defaults shape content visibility and platform competition.

Server racks in a data center showing distributed network infrastructure

The Difference Between Distributed and Decentralized and Why the Distinction Matters

29 August 2026 / Cecil Ellis

In the political economy of internet protocols, distributed and decentralized get thrown around as if they meant the same thing. They don’t. A distributed system spreads work or data across multiple nodes. A decentralized system spreads control across multiple parties. The difference matters because it determines who can change the rules, who can be held responsible, and who can be forced to comply. For network operators, end users, and platform providers, this isn’t a semantic quibble. It’s a map of where power actually sits.

This article examines the operational and governance differences between distributed and decentralized architectures. It looks at how technical design choices distribute power among network operators, end users, and platform providers. It also explains why a system can be highly distributed yet tightly centralized, and why some nominally decentralized systems still concentrate authority in a handful of maintainers, registries, or cloud providers.

Defining the Terms Without the Usual Hand-Waving

A distributed system is one in which components are located on different networked computers that coordinate their actions by passing messages. The defining feature is physical or logical separation of components. A content delivery network with edge servers in fifty cities is distributed. A blockchain with thousands of validating nodes is distributed. A federated messaging protocol with hundreds of independently operated servers is distributed.

A decentralized system is one in which no single administrative entity has unilateral authority over the system’s rules, data, or continued operation. Decentralization is about governance, not topology. A system can be distributed across many machines and still be controlled by one company. A system can be run on a single machine and still be governed by a multi-party contract, though that is rare in practice.

The confusion arises because many distributed systems are marketed as decentralized, and many decentralized systems depend on distributed infrastructure. But the two properties answer different questions. Distribution asks: Where does the work happen? Decentralization asks: Who can change the rules?

Why the Distinction Matters for Network Operators

Network operators live with the consequences of this distinction every day. A distributed routing protocol such as BGP is not decentralized in any meaningful sense. The protocol is standardized by the IETF, but the operational decisions that determine reachability are made by thousands of autonomous systems, each acting on its own commercial and policy interests. The result is a system that is distributed in operation but fragmented in authority. No single operator controls the global routing table, but no operator is fully accountable for it either.

By contrast, a centralized cloud service may be highly distributed internally. A large provider can run services across dozens of regions and hundreds of availability zones. The infrastructure is distributed. The control plane, however, is centralized: one company decides which features exist, which data is retained, which customers are allowed, and which jurisdictions can compel access. For a network operator that depends on that cloud, the practical question is not whether the provider’s architecture is distributed. It is whether the operator can exit without losing its own operational capability.

This is why the distinction matters for infrastructure governance. A distributed system can still have a single point of policy failure. A decentralized system can still have a single point of technical failure. The two risks are different and require different mitigations.

Distributed but Centralized: The Default Condition of the Modern Internet

Most of the internet’s most important services are distributed but centralized. A social platform may serve content from edge caches around the world. Its database may be sharded across thousands of machines. Its engineering teams may be spread across continents. But the platform’s terms of service, content moderation rules, data retention policies, and API access are all controlled by one corporation. The distribution of the infrastructure does not distribute the power to govern it.

This is not a moral failing. It is an operational choice. Centralized governance allows faster product development, clearer accountability, and simpler compliance with legal obligations. A company that must answer to regulators in multiple jurisdictions often finds it easier to maintain a single policy engine, even if the underlying infrastructure is distributed. The problem is not that centralized governance exists. The problem is that the language of decentralization is often used to obscure it.

Consider a service that advertises itself as “decentralized” because it uses a peer-to-peer protocol for file transfer. If the service still relies on a single company’s directory servers to discover peers, the system is distributed in data transfer but centralized in discovery. Remove the directory servers, and the network may fragment or stop working. The peer-to-peer label describes the data path, not the control path.

Decentralized but Fragile: The Hard Part of Distributed Governance

True decentralization is expensive. It requires mechanisms for coordinating changes without a single authority. It requires dispute resolution processes that do not depend on a corporate legal department. It requires funding models that do not depend on a single revenue stream. It requires security models that assume some participants will act maliciously or incompetently.

This is why many projects that begin with decentralization goals drift toward centralization over time. A protocol may start with a broad community of contributors. As the codebase grows, a small group of maintainers accumulates the contextual knowledge needed to review changes. As the user base grows, a small group of operators accumulates the infrastructure needed to keep the network reliable. As the legal environment grows more complex, a small group of foundations or companies accumulates the resources needed to manage compliance. The system remains distributed in its operation, but the governance becomes concentrated in practice.

The history of email is instructive. Email is often described as a decentralized system because anyone can run a mail server. In practice, a small number of large providers handle a large share of mail delivery. The protocol is decentralized in principle, but the operational reality is concentrated. A mail server operator who is blocked by a major provider has few practical remedies. The decentralization of the protocol does not protect the operator from the centralization of the market.

Governance as a Technical Design Choice

The distinction between distributed and decentralized is not just a matter of vocabulary. It is a design choice that shapes the political economy of a protocol. When engineers choose a consensus mechanism, they are choosing who can validate transactions. When they choose a namespace system, they are choosing who can assign names. When they choose a funding model, they are choosing who can pay for continued development. These choices are technical, but their consequences are political.

A protocol that requires a quorum of known validators is distributed but not decentralized. A protocol that allows anyone to run a validator but requires expensive hardware is decentralized in principle but concentrated in practice. A protocol that uses a foundation to manage upgrades is centralized in governance even if the network is distributed. The technical design does not eliminate power. It redistributes it.

This is why the distinction matters for end users. A user who stores files on a distributed storage network may believe their data is safe from corporate control. If the network’s governance is controlled by a single foundation that can change the protocol, the user’s data is still subject to that foundation’s decisions. The user has traded one form of dependence for another.

Operational Complexity and the Limits of Decentralization

Decentralization is not a free good. It imposes costs on every participant. A decentralized system requires more coordination, more documentation, more testing, and more patience. Decisions that a centralized company can make in a single meeting may take months of discussion in a decentralized project. Security incidents that a centralized company can contain by shutting down a service may be impossible to contain in a decentralized network.

These costs are not always visible to end users. They are visible to network operators and protocol maintainers. A network operator who runs a node in a decentralized system must monitor the node, apply updates, manage keys, and respond to incidents. A maintainer who contributes to a decentralized protocol must navigate a governance process that may be slow, contentious, or captured by a small group of active participants. The operational complexity of decentralization is real, and it is often understated by advocates.

This does not mean decentralization is always the wrong choice. It means the choice should be made deliberately, with a clear understanding of the tradeoffs. A system that needs to resist censorship may justify the costs of decentralization. A system that needs to process payments quickly may not. The right answer depends on the threat model, not on ideology.

Case Study: The Domain Name System

The Domain Name System is a useful example of the difference between distributed and decentralized. The DNS is distributed: there are thousands of authoritative name servers, recursive resolvers, and root servers around the world. The DNS is not decentralized: the root zone is controlled by ICANN, which operates under a contract with the U.S. Department of Commerce, and the root zone is signed by a single trust anchor. The distribution of the DNS infrastructure does not distribute the authority to change the root zone.

This has real consequences. A government that wants to block a domain can pressure the registrar or the registry. A court that wants to seize a domain can order the registry to transfer it. A company that wants to protect its trademark can use the UDRP process to take a domain from a registrant. The DNS is distributed enough to be resilient against technical failures, but centralized enough to be a point of legal and political control.

Alternative naming systems have tried to address this. Some use blockchain-based registries that are distributed and nominally decentralized. But these systems often rely on a small number of gateways or resolvers that are operated by a single company or foundation. The registry may be decentralized, but the user experience is still mediated by centralized infrastructure. The distinction between distributed and decentralized is not a binary. It is a spectrum, and most systems sit somewhere in the middle.

What This Means for Platform Providers

Platform providers have a particular interest in the distinction between distributed and decentralized. A platform that wants to reduce its infrastructure costs may distribute its services across multiple cloud providers. A platform that wants to reduce its legal liability may decentralize some of its governance to users or communities. But these choices are not neutral. They change the platform’s relationship with its users, its regulators, and its competitors.

A platform that distributes its infrastructure but keeps its governance centralized is still a centralized platform. It can still be compelled to remove content, disclose data, or change its terms of service. A platform that decentralizes its governance but keeps its infrastructure centralized is still dependent on a single provider for its operations. The platform may be able to resist some forms of legal pressure, but it is still vulnerable to technical pressure from its infrastructure provider.

The most interesting platforms are those that try to distribute both infrastructure and governance. These platforms face the hardest operational challenges. They must coordinate a distributed network of operators while maintaining a coherent user experience. They must manage a decentralized governance process while still shipping features and fixing bugs. They must balance the demands of users, operators, and regulators without a single authority to make the final call. This is not impossible, but it is hard, and the failures are often public.

Why the Distinction Matters for the Future of Internet Governance

The internet is not a single system. It is a collection of protocols, networks, and services that are governed by different actors with different interests. Some parts of the internet are distributed but centralized. Some parts are decentralized but fragile. Some parts are neither. The distinction between distributed and decentralized matters because it helps us see where power actually sits, and where it can be challenged.

When a protocol is described as decentralized, the first question should be: Decentralized in what sense? Is the data distributed? Is the governance distributed? Is the funding distributed? Is the legal responsibility distributed? The answer to each question may be different. A protocol can be decentralized in one dimension and centralized in another. The word “decentralized” is not a property of the system. It is a property of a particular dimension of the system.

This is not a call for more decentralization. It is a call for more precision. The political economy of internet protocols depends on the details of technical design. The difference between distributed and decentralized is one of those details. It is not the only detail that matters, but it is one that is often ignored.

Practical Takeaways for Network Operators and Protocol Designers

For network operators, the practical takeaway is to ask better questions. When evaluating a new protocol or service, do not ask whether it is decentralized. Ask who can change the rules, who can shut it down, who can be compelled to comply, and who bears the cost of failure. The answers to these questions will tell you more than any label.

For protocol designers, the practical takeaway is to be honest about the tradeoffs. If you choose a distributed architecture with centralized governance, say so. If you choose a decentralized governance model with high operational costs, say so. The users and operators who depend on your protocol deserve to know what they are signing up for. The language of decentralization should not be used to hide the reality of centralization.

For end users, the practical takeaway is to look past the marketing. A service that claims to be decentralized may still be controlled by a single company. A service that is distributed may still be subject to a single point of failure. The distinction between distributed and decentralized is not just a technical detail. It is a map of who has power over the systems you use every day.

FAQ

What is the difference between distributed and decentralized?

A distributed system spreads components or data across multiple nodes. A decentralized system spreads control or governance across multiple parties. A system can be distributed but centralized, such as a cloud service with many data centers but one company in charge. A system can be decentralized but not fully distributed, though this is rare in practice.

Can a system be both distributed and decentralized?

Yes. A system can be both distributed in its infrastructure and decentralized in its governance. Examples include some blockchain networks and some federated protocols. However, achieving both properties is operationally expensive and often fragile. Many systems that claim both properties are actually distributed but centralized in practice.

Why do so many projects use the word “decentralized” when they are only distributed?

The word “decentralized” carries political and marketing weight. It suggests resistance to censorship, corporate control, and single points of failure. Some projects use the word loosely to attract users and investors. Others use it because they genuinely believe their system is decentralized, even when the governance is concentrated in a small group of maintainers or operators.

What are the operational costs of decentralization?

Decentralization requires more coordination, more documentation, more testing, and more patience. Decisions take longer. Security incidents are harder to contain. Funding is harder to sustain. These costs are often borne by network operators and protocol maintainers, not by end users. The costs are real and should be weighed against the benefits of resisting centralized control.

How can I tell if a system is actually decentralized?

Ask who can change the rules, who can shut the system down, who can be compelled to comply with legal demands, and who bears the cost of failure. If the answer to any of these questions is a single company, foundation, or small group, the system is not fully decentralized, regardless of how distributed its infrastructure is.

Next Steps for This Publication

This article is part of a longer inquiry into how technical design choices distribute power among network operators, end users, and platform providers. A natural next step is a closer look at the governance of specific protocols: how the IETF, ICANN, and the major open-source foundations make decisions, and how those decisions shape the political economy of the internet. If you have questions or examples from your own operational experience, they are welcome.