2. Protocol Networks
What was often difficult for people to understand about the design was that there was nothing else beyond URLs, HTTP and HTML. There was no central computer “controlling” the Web, no single network on which these protocols worked, not even an organisation anywhere that “ran” the Web. The Web was not a physical “thing” that existed in a certain “place.” It was a “space” in which information could exist.1
A Brief History of Protocol Networks
In the fall of 1969, the U.S. military bootstrapped the earliest version of the internet:2 ARPANET, named after the Department of Defense’s Advanced Research Projects Agency (ARPA).
A broad community of researchers and developers spearheaded the internet’s development through the next couple decades. These academics and tinkerers brought with them a tradition of open access. They believed in the free exchange of ideas, equal opportunity, and meritocracy. In their view, the people who used internet services—the users—should have control. The structure and governance of their research communities, advisory groups, and task forces embodied their democratic ideals.
The internet carried this culture forward when it crossed from government and academia to mainstream users in the early 1990s. As more people joined the network, they inherited the egalitarian ethos. Cyberspace was radically open. As John Perry Barlow, the poet-activist and sometime lyricist for the Grateful Dead,3 would write in 1996 in his “Declaration of the Independence of Cyberspace,” “We are creating a world that all may enter without privilege or prejudice accorded by race, economic power, military force, or station of birth.” The internet represented freedom, a fresh start.
That same spirit infused the technology itself. The internet was underpinned by permissionless protocols, sets of rules for computers to participate in networks. In ancient times, “protocol,” from the Greek prōtokollon, meant “first sheet of a volume,” often referring to a table of contents. Over time, the word evolved to mean “diplomatic conventions” and, later, in the twentieth century, “technical standards for software.” The computing context became widespread with the advent of ARPANET because protocols—accessible by and open to all—were foundational to the development of the internet.
Think of protocols as analogous to natural languages, like English or Swahili. They enable computers to communicate with one another. If you change how you speak, there’s a risk other people won’t understand you. You cease to interoperate, in tech vernacular. If you’re influential enough, you might get others to change how they speak too because dialects can splinter into new languages, but only if other people join in. Protocols and languages both require consensus.
Protocols layer on top of one another,4 and ultimately on computing devices, in what is called the internet “stack.” For a computer scientist, knowing all layers of the stack and the nuances between them may be useful. (A popular model, called the Open Systems Interconnection model, or OSI for short, identifies seven layers.) For this discussion, just picture three layers where the lowest one consists of hardware: servers, PCs, smartphones, internet-connected devices like TVs and cameras, along with the networking hardware that connects them all. Other layers build on top of this foundation.
Above the physical layer is the networking layer,5 known simply as internet protocol, or IP. This protocol defines how to format, address, and route packets of information between the first layer’s machines. Vint Cerf and Robert Kahn, researchers at the same lab responsible for ARPANET, developed this standard in the 1970s. (That lab, ARPA, later renamed DARPA, also helped invent futuristic technologies6 like stealth vehicles and GPS.) The network officially completed implementing internet protocol on January 1, 1983, a date most people regard as the birthday of the internet.
On top of the internet layer is the application layer, so called because it’s where user-facing applications plug in. Two protocols chiefly define this layer, the first of which is email. The protocol behind email7 is called Simple Mail Transfer Protocol, abbreviated SMTP. Jon Postel, a researcher at the University of Southern California, created the protocol to standardize email communication in 1981, and his contribution primed email for widespread uptake. As Katie Hafner and Matthew Lyon recount in their history of the internet,8 Where Wizards Stay Up Late, “Just as the LP was invented for connoisseurs and audiophiles but spawned an entire industry, electronic mail grew first among the elite community of computer scientists on the ARPANET, then later bloomed like plankton across the Internet.”
The second protocol from which many applications have bloomed is the web, also known as Hypertext Transfer Protocol, or HTTP. Tim Berners-Lee, a British scientist, invented the protocol, along with Hypertext Markup Language, or HTML, for formatting and rendering websites, while working at the Swiss physics lab CERN in 1989. (Though people often use “internet” and “web” interchangeably, these are different networks: the internet connects devices; the web links web pages.)
Email and the web succeeded because of their simplicity, generality, and openness. After these protocols were created, programmers codified them into email clients and web browsers, many of which were open source. Anyone could download a client (what most people would call an app today) to join a network. Clients build on top of protocols and enable people to access and participate in underlying networks. Clients are like portals, or gateways, to protocol networks.
People interact with protocols through clients. For instance, the web started going mainstream9 only after the 1993 debut of the consumer-friendly Mosaic web browser, one such client. Today, the most popular web clients are proprietary browsers like Google Chrome, Apple Safari, and Microsoft Edge, while the most popular email clients are Gmail (proprietary, hosted on Google servers) and Microsoft Outlook (proprietary, downloadable to local machines). A wide range of software, both proprietary and open source, also remains available for running web and email servers.
The communications system that underpins the internet was designed to be decentralized and, therefore, resilient enough to survive nuclear attack. The system treated all nodes equally, so it could continue functioning even if sections were destroyed. Email and the web inherited this design philosophy. All nodes are “peers,” none privileged above any other.
One component of the internet was, however, designed differently, and it controlled a special function: naming.
Naming is a requirement in every network. Names are the most basic kinds of avatars, essential components for building communities. I am @cdixon on Twitter, and my website is cdixon.org. These human-friendly names make it easy for other people to identify and reach me. If people want to follow me, friend me, or send me something, they do so by referencing one of my names.
Machines have names too. On the internet, computers identify one another by what are called internet protocol addresses, sets of numbers that are difficult for humans to remember but easy for machines. Imagine having to summon up numbers for every web page you want to visit. Browsing Wikipedia? Try 198.35.26.96. Searching for a YouTube video? Hit up 208.65.153.238. People need directories, like contact lists on phones, to aid memory.
Through the 1970s and 1980s, one organization maintained the official internet directory.10 The Stanford Research Institute’s Network Information Center compiled all addresses into a single file, HOSTS.TXT, which it updated continuously and distributed to everyone on the network. Every time an address changed or another node joined the network (which happened often), everyone had to update their hosts file. As the network grew, recordkeeping became a hassle. People needed a less clunky system to serve as a single source of truth.
Enter domain name system, or DNS.11 Paul Mockapetris, an American computer scientist,12 invented this solution to the network naming conundrum in 1983. Under the hood, DNS was complex, but the main idea was simple: mapping human-friendly names to physical-computer IP addresses. The system was hierarchical but also distributed. At the topmost level, a collection of international organizations—government-affiliated agencies, universities, companies, nonprofit groups, and more—managed thirteen sets of root servers that to this day remain the system’s ultimate authorities.
From the 1980s through the rise of the commercial internet in the 1990s, a team directed by Postel administered DNS at the University of Southern California.13 In 1997, The Economist summed up the significance of his role:14 “If the Net does have a god, he is probably Jon Postel.” As the internet took off, a longer-term solution to DNS governance became necessary. In the fall of 1998, the U.S. government began transitioning oversight of the internet’s name space to a new organization, the nonprofit Internet Corporation for Assigned Names and Numbers, or ICANN. (In October 2016, ICANN became independent15 and moved to a global multi-stakeholder governance model that continues to supervise the system we use to this day.)
DNS is crucial to a working internet. When you search on a browser for a website, like google.com or wikipedia.org, your internet service provider routes the request through a special server called a DNS resolver that asks the top-level domain servers, responsible for domain suffixes like .com or .org, for further directions. These top-level servers then point to lower-level servers that provide the appropriate IP addresses to your browser to get you where you’re going. This whole process is called a DNS lookup, and it happens in a flash every time you try to connect to a website. (To make lookups faster, DNS providers also store, or cache, IP addresses on servers nearer to users.)
The protocols underlying email and the web are free to use except for DNS, which charges modest fees that go to ICANN and internet registrars. As long as users pay the fees, typically around $10 per year, and as long as they obey the law, they can do what they please with their domain names. Users can buy, sell, or hold on to them indefinitely. The fees behave more like property taxes than leasing fees.
Names are an important leverage point in the control of networks. In networks like Twitter and Facebook, corporate owners control the names. I am @cdixon on Twitter, but Twitter owns this name. Twitter can revoke it, charge me more money, or take away my audience. By controlling my name, Twitter also controls my relationships with other people. It can modify algorithms that show my posts more or less frequently, for example. I have no power except to quit the network.
The key design decision in DNS is that users, not a company or other higher authority, own and control their names. Specifically, users control the mapping between their names and IP addresses. They can therefore move their names from one computer to another, at any time for any reason, and run whatever software they want, without losing their network connections or anything else they’ve built.
Let’s say I host cdixon.org at Amazon’s web hosting services. Imagine that Amazon decides to charge me more money, throttle my website, censor my content, or do something else I don’t like. I can simply transfer my files to another provider and redirect the cdixon.org DNS record. I could even choose to self-host, the digital equivalent of living off the grid. When I redirect my name, all my network connections remain intact. People can still send me emails and the inbound web links that search engines use to rank my site still work. The switch to a new hosting provider happens behind the scenes. It is invisible to other participants on the network. Amazon knows this and knows it must therefore act within the guardrails of network norms and market forces, or risk losing customers.
This simple design decision—giving users full control of their names—keeps businesses honest. It restrains Amazon and other companies, forcing them to offer competitive services at competitive prices. Companies can still avail themselves of traditional business moats like economies of scale (the more servers they run, the lower their costs, the higher their margins), but they can’t rely on network effects to trap users the way centralized networks do.
Contrast how DNS works with what happens when you try to leave a service like Twitter or Facebook. Most corporate networks have a “download your data and delete your account” feature. You get records of your posts and maybe of your followers and friends. But you lose your network connections and your audience because those people followed your Twitter or Facebook account, and you can’t redirect that account to a new service. You don’t control the mapping. You can get the data, but you lose your network. These “data download” features are feints. They gesture toward openness and freedom, but they do nothing to increase user choices. The company has total control. Your only choice is to stay, or leave and start from scratch somewhere else.
Corporate services like Facebook and Twitter operate networks that interoperate with the web, using components like HTTP, but they are not part of the web in any meaningful sense. They do not adhere to the web’s entrenched customs and norms. Indeed, they break the web’s many technical, economic, and cultural tenets—like openness, permissionless innovation, and democratic governance. These centralized networks are essentially separate networks that sit adjacent to the web. They have their own rules, economics, and network effects.
The genius of DNS is that users own their names in the same way they own things in the physical world, providing the online equivalent of property rights. When you own something, you have an incentive to invest in it. That’s why, starting in the 1990s and continuing today, there has been so much investment in businesses related to email and the web, networks built around DNS.
Giving users control of their names might seem like a small design choice. But it has had cascading downstream consequences, ultimately enabling new industries to grow and flourish, from search engines and social networks to media and e-commerce sites.
As a side effect, digital ownership can spawn speculative markets. Buying and selling domains is a multibillion-dollar industry. Short English-word.com domains routinely sell for millions of dollars. (A recent example is voice.com, which sold for $30 million.) The market for domain names goes up and down, alternately creating and losing fortunes. In this way, the domain market is similar to real estate, which also suffers from bouts of speculation and, every so often, bubbles. Blockchain tokens, which enable a newer form of digital ownership, as we’ll discuss later, have also spawned speculative markets. In all these cases, speculation is a side effect. Yet the positives of ownership far outweigh the negatives.
Today, content moderation is a hot topic, especially with respect to social networks. Email and the web, however, don’t moderate content. They have just one job: deliver information reliably. The philosophy is if the protocols were to do the policing, they would become fragmented and dysfunctional. Different regions have different laws and customs where what’s illegal in one country may be permissible in another. To be universal, protocols must be unopinionated.
Content moderation still happens, but it’s done by users, clients, and services built at the network edges. This might seem risky: Can you trust the decentralized masses to successfully police themselves? Yet, in practice, the system does work well. Clients and servers enforce laws, regulations, and moderation. If you operate an illegal website, domain name registrars and web hosting companies will take it down. Search engines will de-index it. The sprawling community of software developers, app and website makers, tech companies, and international bodies that governs the web will exile it. The same is true for email. Clients and servers at the network edges filter spam, phishing, and other malicious content. Laws and incentives make the system work.
Email and the web, supported by DNS, have brought powerful general-purpose networks to the internet. The design lets users own what matters most: their names and, therefore, their connections and whatever else they decide to build on top of the network.
The Benefits of Protocol Networks
Protocol networks endow users with ownership, which benefits all network participants, including creators, entrepreneurs, developers, and others.
Like all networks, protocols have network effects: they get more valuable as more people use them. Email is useful because it is ubiquitous—because so many other people have email addresses. The difference between a protocol network like email and a corporate network like Twitter is that email’s network effect accrues to a community instead of a company. No company owns or controls email and anyone can access it through software created by independent developers that supports the underlying protocol. It’s up to developers and consumers to decide what to build and use. Decisions that affect the community are made by the community.
Because protocol networks have no central intermediary, they don’t charge “take rates,” or fees on money that flows through the network. (I’ll discuss take rates and their effects in depth in the chapter “Take Rates.”) Moreover, the structure of protocol networks provides strong assurances they’ll never charge take rates. This encourages innovation on top. If you are building something on top of email or the web, you know you can invest time and money, because you know that whatever you build, you will own and control. Larry Page and Sergey Brin, Jeff Bezos, Mark Zuckerberg, and countless other internet entrepreneurs were inspired by this promise.
Users also benefit from protocol networks. A vibrant software market and low switching costs mean users can shop around. If users don’t like how an algorithm works, or how a service tracks their data, they can switch. If users pay subscription fees or watch ads, the money earned goes directly to creators, instead of network intermediaries, incentivizing further investment in their preferred content.
The more predictable the incentives, the better, just as in the physical world, where predictable laws like property rights encourage investment. The interaction between private businesses and highway systems is a helpful analogy. Because highway systems are predictably open and mostly free, people and businesses are willing to build on top of them—meaning they’re willing to invest in resources such as buildings, vehicles, and communities whose ongoing value depends on the highways. This, in turn, stimulates more highway use, which encourages more private investment. In a well-designed network, growth begets growth, creating a healthy and dynamic system.
Corporate networks, like Facebook and Twitter, have unpredictable incentives and therefore limited investment by third parties. Corporate networks usually have high take rates, allowing them to claim a larger share of the revenue that flows through the network and eat into the profits that might otherwise flow to the edges. Today, the incumbent corporate networks—including Facebook, Instagram, PayPal, TikTok, Twitter, and YouTube—are owned by companies with aggregate market capitalizations in the trillions of dollars. It’s reasonable to assume that if these networks were protocols, a significant portion of that value would instead be distributed to developers and creators at the edges.
These dynamics explain why email, namely newsletter writing, is having a renaissance16 among so many content creators. Email gives creators a direct relationship with their audiences, unmediated by central network operators who can change the economics, access rules, or content rankings on a whim. If newsletter services like Substack, which layer on top of email, were to change the rules or the rates, users could simply leave and take their subscribers with them. (Many of these services currently let users export email subscriber lists.) The ability to exit lowers switching costs and, therefore, take rates. That’s the power of decoupling names from services in protocol networks. Users may not understand all the nuances of network design, but they do intuit their own economic risks, especially after many years of well-documented issues between content creators and corporate networks.17
Software developers are further along in their disillusionment. In the early 2010s, companies like Facebook and Twitter, despite originally presenting themselves as open and inviting, slammed their networks shut and revoked developers’ access. In January 2013, when Vine, a short-form video app (acquired by Twitter a few months earlier), made its debut, Mark Zuckerberg personally approved its neutering. According to court documents unsealed years later, Zuckerberg gave the nod to shut down Vine’s access18 to Facebook’s application programming interface, or API, a software connection that applications use to interoperate. “Yup, go for it,” he told another exec. The move crippled Vine’s growth, and Twitter discontinued the service in 2017 after years of neglect. Vine’s demise is well-known. Fewer people remember Facebook’s crackdowns on apps like BranchOut (job hunting),19 MessageMe (messaging),20 Path (social networking),21 Phhhoto (GIF making),22 and Voxer (voice chat).23
The promise of ownership motivates builders and investors alike. Because protocol networks don’t have network fees—and are guaranteed never to have them—startups are strongly incentivized to build on top of them. For example, the early web was hard to navigate and search. Dozens of technical teams started companies to solve this problem, including well-known companies like Yahoo and Google. When spam became a serious issue in the late 1990s,24 venture capitalists funded dozens of companies to address the problem, an effort that mostly succeeded. There’s still spam of course, but we’ve gotten a lot better at handling it.
Contrast this with how corporate networks like Twitter approach spam, bots, and similar problems today. Outside companies have no incentive to solve the problems. Only the company itself tries to solve them, reducing the pool of talent and resources that could be helping. That’s why some of these networks are drowning in bots and spam today.
I credit the opportunities I had as an entrepreneur to the design of protocol networks. In the early 2000s, issues like phishing and spyware were rampant. Today it’s hard to picture how bad the situation was. At the time, most people were using a notoriously insecure version of Microsoft’s web browser25 that made it easy for malicious software to install itself on their PCs. In 2004, I co-founded a web security startup called SiteAdvisor that built a tool to protect users from these threats. Because the web is a protocol network, we were able to crawl and analyze websites and build software that worked inside browsers and search engines. We didn’t need to ask for permission. No company owns the web or email.
Developers don’t need permission to build clients and apps on protocol networks. These networks are open, allowing the independent developer community to solve problems and develop new features. Even better, builders and creators can capture whatever economic value they create. These conditions and incentives allow markets to solve problems that protocols don’t.
It would have been impossible for my startup to have been built on a corporate network. Corporate networks are inhospitable to founders, and most venture capitalists know better than to fund people building on them. McAfee eventually acquired our company for a premium because it knew that we owned what we built. The web couldn’t change the rules or the rent. No higher power could take away what we made. The web, as a community, of which we were a part, succeeded because of the protocol architecture and the incentives it created.
The Fall of RSS
Since the rise of email and the web, no protocol network has succeeded at scale. It’s not for lack of trying. In the last thirty years, technologists created many credible new protocol networks. In the early 2000s, Jabber, an open-source instant messaging protocol26 (since renamed XMPP), tried to take on AOL Instant Messenger and MSN Messenger. Later in the decade, OpenSocial, a cross-platform social networking protocol, tried to challenge Facebook and Twitter.27 Diaspora, a decentralized social network28 that made its debut in 2010, tried to do this too. These protocols were technically innovative and built passionate communities, but none went mainstream.
Email and the web succeeded in part because of their special historical conditions. In the 1970s and 1980s, the internet consisted of a small number of collaborative researchers. Protocol networks grew in the absence of centralized competition. In more recent years, upstart protocol networks have had to compete with corporate alternatives with far more features and resources.
The competitive disadvantages of protocol networks are perhaps best illustrated by the fate of RSS, or “really simple syndication,” the protocol that came closest to challenging corporate social networks. RSS is a protocol with functionality similar to a social network. It lets you make lists of users you want to follow, and it allows those users to send you content. Web administrators can embed code on their sites to output updates in a format called XML, short for “extensible markup language,” whenever a new post is published. The updates get pushed to the customized feeds of subscribers, who follow the sites and blogs of their choice using their preferred RSS “reader” software. The system is elegant and decentralized. But it’s bare bones.
In the 2000s, RSS was a credible competitor to corporate networks like Twitter and Facebook. But by 2009, Twitter started supplanting RSS. People were relying on Twitter instead of RSS to subscribe to bloggers and other creators. Some members of the RSS community thought this was fine, because Twitter had an open API and a stated commitment to continuing to interoperate with RSS. To them, Twitter was simply a popular node in the RSS network. I continued to worry about where things were headed, as I blogged at the time:
The problem is Twitter isn’t really open. For Twitter to be truly open, it would have to be possible to use “Twitter” without in any way involving Twitter the institution. Instead, all data goes through Twitter’s centralized service. Today’s dominant core internet services—the web (HTTP), email (SMTP), and subscription messaging (RSS)—are open protocols that are distributed across millions of institutions. If Twitter supplants RSS, it will be the first core internet service that has a single, for-profit gatekeeper …. At some point Twitter will need to make lots of money to justify their valuation. Then we can really assess the impact of having a single company control a core internet service.
Unfortunately, my worries were justified. As Twitter’s network grew more popular than RSS, only social norms—nothing firmer—kept the company from pulling the plug. In 2013, as soon as doing so suited its corporate interests, Twitter stopped supporting RSS. Google shut down its main RSS product, Google Reader,29 that same year, highlighting how far the protocol had fallen.
RSS was once a credible protocol-based approach to social networking. While niche communities continued to use RSS in the 2010s, it was no longer a serious rival to corporate social networks. RSS’s decline directly correlated with the consolidation of network power among a few internet giants.30 As one blogger put it, “That little tangerine bubble”31—a reference to RSS’s orange logo—“has become a wistful symbol of defiance against a centralized web increasingly controlled by a handful of corporations.”
There are two main reasons why RSS lost. First: features. RSS couldn’t match the ease of use and advanced functionality of corporate networks. On Twitter, a user could sign up, choose a name and accounts to follow, and be up and running all in a few clicks. RSS was, by contrast, simply a set of standards. No company was behind it, and therefore no one ran a centralized database to store things like people’s names and lists of followers. The products built around RSS had more limited features, lacking user-friendly mechanisms for content discovery, curation, and analytics.
RSS expected too much from users. Like email and the web, the protocol used DNS for naming, but that meant content creators had to pay to register domains and then transfer those domains to their own web servers or RSS hosting providers. This onboarding experience was fine for email and the web back in the early days of the internet, when there were no alternatives and when many users were technologists who were accustomed to putting in the effort. But as people with less willingness and know-how came online, RSS couldn’t compete. Free, streamlined services like Twitter and Facebook offered easier ways for people to publish, connect, and consume, enabling them to amass tens, then hundreds of millions—and in Facebook’s case, billions—of users.
Other attempts by protocols to match the capabilities of corporate services foundered too. In 2007, Wired magazine documented its bid to build a social network32 of its own using open tools like RSS. The demo hit a dead end just before the finish line when the developers realized they were missing a key piece of infrastructure: a decentralized database. (In retrospect, the developers were missing exactly the technology that blockchains would later provide.) As the team wrote,
For the last couple of weeks, Wired News tried to roll its own Facebook using free web tools and widgets. We came close, but we ultimately failed. We were able to recreate maybe 90 percent of Facebook’s functionality, but not the most important part—a way to link people and declare the nature of the relationship.
Some developers, like Brad Fitzpatrick, who started the blog network LiveJournal in 1999, suggested solving this problem by creating a database of social graphs run by nonprofit organizations.33 In a 2007 post called “Thoughts on the Social Graph,” he proposed,
Establish a non-profit and open source software (with copyrights held by the non-profit) which collects, merges, and redistributes the graphs from all other social network sites into one global aggregated graph. This is then made available to other sites (or users) via both public APIs (for small/casual users) and downloadable data dumps, with an update stream / APIs, to get iterative updates to the graph (for larger users).
The idea was that a conventional database containing social graphs could help RSS match the streamlined onboarding of corporate social networks. Giving control of the database to a nonprofit would keep it credibly neutral. Implementing this, however, required widespread coordination between software developers and nonprofit groups. The effort never gained traction, and people have struggled to get nonprofits to work in other tech startup contexts too (which I cover later in “The Nonprofit Model”).
Meanwhile, corporate networks didn’t need to coordinate. They could simply move fast, even if it meant breaking some things.
This gets at the second reason RSS lost: funding. For-profit companies can raise venture capital to hire more developers, build advanced functionality, subsidize hosting costs, and so forth. As they grow, more capital becomes available. Companies like Facebook and Twitter, and almost every other large corporate network, have raised billions of dollars from private and public investors. RSS was just a loosely connected group of developers with no access to capital beyond voluntary donations. It was never a fair fight.
To this day, open-source software funding is subject to market forces that sometimes, but not always, correspond to what’s good for the internet. In 2012, a software update introduced a critical vulnerability into OpenSSL, an open-source project that powers a large portion of the internet’s encryption software. The bug, dubbed Heartbleed,34 endangered the security of broad swaths of internet communications. Security engineers only discovered it two years after its introduction. When people looked into why no one found the bug sooner, they learned that the nonprofit responsible for maintaining the internet protocol,35 the OpenSSL Software Foundation, consisted of just a few overworked volunteers and that it subsisted on paltry funding, including about $2,000 in direct donations per year.
Some open-source projects are well funded because their success aligns with the interests of big companies. The most widely used operating system in the world, Linux, falls into this category. Companies that benefit from the proliferation of open-source operating systems,36 like IBM, Intel, and Google, support Linux development. But building new protocol networks generally doesn’t align with corporate interests. Indeed, the strategy of most tech companies is to capture, control, and monopolize networks. The last thing they would want to do is fund a potential competitor. Protocol networks are in the collective interest of the internet, but the internet hasn’t had a significant source of direct funding since the government bankrolled it in the early days.
Protocol networks like email and the web succeeded because they arrived before serious alternatives. The incentives they created led to a golden period of creativity and innovation that persists to this day, despite the encroachment of Big Tech. But later attempts to build protocol networks have failed to go mainstream. The decline of RSS epitomizes the challenges protocol networks face. RSS’s cautionary tale also shows how protocol networks planted the seeds for a newer, more competitive network design, one that would define the next era of the internet.