RFC 9518

Centralization, Decentralization, and Internet Standards

📅 published December 2023, from ietf

RFC 9518: Centralization, Decentralization, and Internet Standards 💖

  • RFC: 9518
  • Title: Centralization, Decentralization, and Internet Standards
  • Author: M. Nottingham
  • Date: December 2023
  • Category: Informational (not a Standards Track spec, just published for info 📚)
  • Stream: Independent Submission
  • ISSN: 2070-1721
  • Obsoletes / Updates: the header lists neither, so this doc doesn't replace or change any older RFCs 🎀

Abstract ✨

okay so this doc is all about centralization and how it connects to Internet standards 🌸 The big takeaway is that standards bodies can't fully stop every kind of centralization, BUT they can still help make the Internet more decentralized. so not powerless, just realistic 💅

Status of This Memo 📝

This doc is not an Internet Standards Track spec. It's published purely for info 🦋

It's a contribution to the RFC Series that's totally independent of any other RFC stream. The RFC Editor picked to publish it at their discretion, and they make no claims about whether it's valuable to implement or deploy 🫶 Docs the RFC Editor approves aren't candidates for any level of Internet Standard, see Section 2 of RFC 7841 for the deets.

For the current status, any errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc9518 🔥

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions for this doc 📜

Table of Contents 🗂️

   1.  Introduction
   2.  Centralization
     2.1.  Centralization Can Be Harmful
     2.2.  Centralization Can Be Helpful
   3.  Decentralization
     3.1.  Decentralization Strategies
       3.1.1.  Federation
       3.1.2.  Distributed Consensus
       3.1.3.  Operational Governance
   4.  What Can Internet Standards Do?
     4.1.  Bolster Legitimacy
     4.2.  Focus Discussion of Centralization
     4.3.  Target Proprietary Functions
     4.4.  Enable Switching
     4.5.  Control Delegation of Power
     4.6.  Enforce Boundaries
     4.7.  Consider Extensibility Carefully
     4.8.  Reuse What Works
   5.  Future Work
   6.  Security Considerations
   7.  IANA Considerations
   8.  Informative References
   Acknowledgements
   Author's Address

1. Introduction 🌈

One of the Internet's signature traits is that there's no single point of technical, political, or economic control. Arguably, that's a big reason it got adopted so fast and reached so far 🚀 Nobody needs permission to connect to it, build an app on it, or use it for a particular purpose. So it can meet all kinds of needs and show up in tons of different environments 🧚

Keeping that vibe going is a goal lots of people love, but consistently holding onto it across every service and app people call "the Internet" has been surprisingly hard 😭 Early services like NNTP and email had multiple interoperable providers. Lots of today's platforms, though, are run by one commercial entity with no interoperable alternative. Some have become so famous and so central to people's lives that they're literally mistaken for the Internet itself [Komaitis] 💀

All of this raises questions about what role architectural design can and should play in controlling centralization. Especially the design overseen by open standards bodies like the IETF 🤔

Here's the argument: decentralized technical standards may be necessary to avoid centralization of Internet functions, but they aren't sufficient on their own. Why? Because centralization is often caused by non-technical factors that standards bodies just can't control 🙈 So standards bodies shouldn't obsess over preventing every single form of centralization. Instead, they should take steps to make sure the specs they write allow for decentralized operation 💅✨

This doc has been talked about a lot in the IETF community (see the Acknowledgements section), but it's only the author's view, not community consensus 🫶 The main audience is the engineers who design and standardize Internet protocols. Designers of proprietary protocols and apps can benefit from thinking about this too, especially if they hope their work gets considered for standardization one day 🦋 And policymakers can use it to describe abuses involving centralized protocols and apps, and to judge proposed fixes 👑

Here's the roadmap: Section 2 defines centralization, explains why it's usually bad but sometimes helpful, and surveys how it shows up on the Internet. Section 3 explores decentralization and some strategies for it, plus their limits 🍓 Section 4 makes recommendations for what Internet standards can do about centralization. Section 5 wraps up with areas for future work 🌸

2. Centralization 🧠

In this doc, "centralization" means a situation where a single entity, or a small group of them, can observe, capture, control, or extract rent from an Internet function exclusively. Main character energy for the bad guys, not for us 😤

"Entity" can be a person, a group, or a corporation 💜 An organization might be under governance that reduces centralization risk (see Section 3.1.3), but it's still a centralizing entity, no cap 🫠

"Internet function" is used broadly here 🌐 The most direct examples are enabling protocols that standards already define, like IP [RFC791], BGP [RFC4271], TCP [RFC9293], or HTTP [HTTP]. It could also be a proposal for a brand-new enabling protocol, or an extension to an existing one ✨

People's experience of the Internet isn't limited to standards-defined protocols and apps, so this doc also looks at centralization in functions built on top of standards. Think social networking, file sharing, financial services, and news distribution 📰 The networking gear, hardware, operating systems, and software that enable the Internet can also affect centralization 💻 Supplying Internet connectivity to end users in a particular area or situation can be centralized too. So can supplying transit between networks, aka the so-called "Tier 1" networks 🏗️

Now, this definition doesn't capture every type of centralization, lowkey on purpose 🙈 Technical centralization is pretty well understood by engineers. For example, a single machine or network link being a single point of failure. That can be mitigated, usually by spreading a function across multiple components 🛠️ But here's the tea: those techniques might fix that type of centralization while still letting control of the function fall into a few hands anyway 👀 A cut cable, a power outage, or a failed server is well understood by the technical community, but it's a totally different thing from when a core Internet function has a gatekeeper 🚪

Political centralization is equally concerning, like when a country is able to control how a function is supplied across the whole Internet. It just isn't covered in depth here 🌍

Last thing: even when centralization isn't present in a function right now, some conditions make it more likely to show up later 🔮 This doc uses "centralization risk" to describe that possibility 💖

2.1. Centralization Can Be Harmful

okay so bestie, let's talk about why so many engineers get the ick from centralization 🫶 Like, the Internet's whole vibe is being a "large, heterogeneous collection of interconnected systems" [BCP95], a "network of networks" where everyone's a peer who agrees to help each other out instead of getting bossed around by someone else's demands 💅 That independence thing is literally baked into the design. Look at the "autonomous system" concept, it's giving self-determination 👑

So why the big fear? Because centralization comes with a whole list of red flags 🚩 Here they are:

  • _Power Imbalance_: okay this one is scary 😭 When a third party has unavoidable access to communications, they get informational and positional advantages. They can watch what you do (the "panopticon effect") and shape or even block what you do (the "chokepoint effect") 💀 Those powers can be used for coercive ends [FarrellH], or even to disrupt society itself. Like [Madison] says about good governance of the US states, power over any function should not be piled up in one place without appropriate checks and balances ⚖️ No notes.
  • _Limits on Innovation_: if one party controls communication, it can shut down "permissionless innovation" 🙅‍♀️ That's the ability to launch new, unforeseen applications without needing to coordinate with anyone except the people you're actually talking to ✨
  • _Constraints on Competition_: the Internet and its users thrive when apps and services come from lots of providers 🌈 Especially when users can build their own stuff on interoperable standards 🛠️ But if a centralized service is the only option because nothing else is suitable, it becomes an essential facility, and that opens the door to abuse of power 🚪 not it.
  • _Reduced Availability_: the Internet (and everything built on it) is more available when there are many ways to get access 🌸 A big centralized provider can be great for focused attention, sure, but if that provider fails, the impact is disproportionate 📉
  • _Monoculture_: a central provider's scale can magnify tiny flaws into big consequences 🔥 Like, a single codebase for routers means one bug or vulnerability hits everything at once 😱 One recommendation algorithm for content can have seriously severe social impact too 🙈 Diversity in how functions are implemented leads to a sturdier outcome when you look at the whole system, because "progress is the outcome of a trial-and-error evolutionary process of many agents interacting freely" [Aligia] 🦋
  • _Self-Reinforcement_: as widely noted (see [Abrahamson]), a centralized provider can access data and use it to improve its offerings, while denying that same access to everyone else 👀 Rude.

Now here's the nuance, because it's not always a simple story 🧠 These harms don't always show up when centralization does, and when they do, it's not always a clean trade-off.

Take availability. A centrally run system might be more available because a bigger operator has more resources 💪 But because it's so big, a single fault can have a much bigger impact 💥 Decentralized systems can be more resilient to some kinds of failure, but less resilient in other ways. For example, they may struggle to react to systemic issues, and they might be exposed to a larger collection of security vulnerabilities overall 🔓 So it can't be said that centralization reduces availability in all cases, nor that it improves it in all cases 🤷‍♀️

You can see this tension in the cloud and mobile Internet access 🌥️📱 If a popular cloud-hosting provider became unavailable (for technical or other reasons), lots of Internet experiences could break, especially since modern websites have so many dependencies (see [Kashaf]) 😵 Similarly, a big mobile Internet access provider could have an outage affecting hundreds of thousands of users or more, just like past issues at large telephone companies caused widespread outages [PHONE] 📞💔

In both cases, the services aren't technically centralized, and these operators have strong incentives to build in multiple redundancies and use various techniques to lower the risk of any one component failing 🛡️ But they generally still rely on a single codebase, a limited selection of hardware, a unified control plane, and a uniform administrative practice 😬 Each of those could set off a widespread failure.

If there were only one provider for these services (like the old telephone networks), they'd easily be seen as centralized in a way that seriously affects availability 📉 But many cloud providers offer similar services, and in most places there are multiple mobile operators 🎉 That weakens the argument that centralization is linked to their availability, because users can switch to other providers or use more than one at the same time; see Section 4.4 🔁

So when you're thinking about centralization and availability for a given function, one area to explore is: what barriers are there to switching providers (which keeps any disruption temporary and manageable), or to using multiple providers at once (which can mask the failure of a single operator)? 🧐 That's the question to ask, bestie 💜

Nuance check number two: competition 💅 Making provision of Internet functions more competitive might be a big goal for a lot of engineers, but only courts (and sometimes regulators) have the authority to define a relevant market and decide a behavior is anticompetitive ⚖️ Market concentration doesn't always mean there's a competition problem 🙃 So what the technical community calls undesirable centralization might not attract competition regulation at all 🤷‍♀️

2.2. Centralization Can Be Helpful

okay so the damaging effects of centralization we just listed? Everyone already knows about those 😤 What's less talked about is how some protocols and applications actually rely on centralization to do their thing 🧩

Sometimes centralization is there because of technical necessity 🔧 For example, a single globally coordinated "source of truth" is centralized by nature 👑 Think of the root zone of the Domain Name System (DNS), which turns human-friendly names into network addresses in a globally consistent way 🌍

Or think about IP address allocation 🏠 Internet routing needs addresses to be allocated uniquely, but if one government or company captured the addressing function, the entire Internet would be at risk of abuse by that entity 😱 Similarly, the Web's trust model needs a Certificate Authority (CA) to act as the root of trust for communication between browsers and servers 🔐 That brings a centralization risk, which has to be considered in the design of that system 🧐

Protocols that need to solve the "rendezvous problem" (coordinating communication between two parties who aren't in direct contact) also need centralization 📬 For instance, chat protocols need to coordinate communication between two parties who want to talk 💬 The actual communication can be direct between them (as long as the protocol allows it), but their mutual discovery typically needs a third party at some point 🫂 From those two users' perspective, the rendezvous function carries a centralization risk 🎀

Even when it's not strictly necessary, centralization can create benefits for a function's users and for society ✨

For example, it's been recognized for a long time that the efficiencies of economies of scale can lead to concentration [Demsetz] 📈 Those efficiencies can be passed on to users as higher quality products and lower costs 💸 They might even make a function possible that wouldn't be viable at smaller scale 🚀

Complex and risky functions, like financial services (e.g., credit card processing), are often concentrated into a few specialized organizations 🏦 That way they get the focused attention and expertise they need 🧠

Centralization can also open the door for beneficial controls 🛡️ [Schneider2] notes that "centralized structures can have virtues, such as enabling publics to focus their limited attention for oversight, or forming a power bloc capable of challenging less-accountable blocs that might emerge. Centralized structures that have earned widespread respect in recent centuries -- including governments, corporations, and nonprofit organizations -- have done so in no small part because of the intentional design that went into those structures".

This shows up when a function needs governance to reach common goals and protect minority interests 🤝 For example, content moderation functions impose community values that many people see as a benefit 🌈 Of course, they can also be viewed as a choke point where inappropriate controls get imposed if that governance mechanism has inadequate oversight, transparency, or accountability 😬

So deciding when centralization is beneficial is ultimately a judgment call ⚖️ Some protocols can't operate without a centralized function 🔒 Others might be significantly enhanced for certain use cases if a function is centralized, or might just be more efficient ⚡ Although, in general, centralization is most concerning when it isn't broadly held to be necessary or beneficial 🚨 when it has no checks, balances, or other accountability mechanisms 🙅‍♀️ when it picks "favorites" that are hard (or impossible) to displace 👑 and when it threatens the architectural features that make the Internet successful 💔

3. Decentralization ✨

okay so decentralization has a LONG history 📚 in economics, politics, religion, and international development, but the first definition that actually matters for computer networking came from [Baran], who described it as a condition where "complete reliance upon a single point is not always required" 🫶

technical centralization is (not a trivial topic, but) relatively well understood 🧠 avoiding ALL forms of centralization, including the non-technical ones, using only technical tools like protocol design is considerably harder 😭 there are a few issues that keep popping up

first, and most critically 🚨, technical decentralization measures have, at best, limited effects on non-technical forms of centralization. per [Schneider1], "decentralized technology alone does not guarantee decentralized outcomes" 💀 as we'll unpack in Section 3.1, technical measures are better characterized as necessary but insufficient to achieve full decentralization of a function. so the tech helps, but it's not the whole glow-up 💅

second, decentralizing a function means tackling challenges that centralized ones just don't face 🙈 a decentralized function can be harder to adapt to user needs (like adding new features or testing out new user interfaces) because that usually needs coordination between a whole bunch of different actors [Marlinspike]. centralized functions get economies of scale, plus data they can use to refine their design 📈 all of this makes centralized solutions more appealing to service providers, and sometimes a decentralized solution just becomes uneconomic 😤

third, figuring out WHICH parts of a function to decentralize can be tricky 🌀 partly because there are often lots of interactions between different types and sources of centralization, and partly because centralization sometimes only shows up after the function is deployed at scale 👀 efforts to decentralize often just end up shifting the centralization somewhere else, like into its governance, implementation, deployment, or ancillary functions. it's giving whack-a-mole 🙃

for example, the Web was envisioned, and widely believed, to be a decentralizing force in its early life 🌸 its potential as an enabler of centralization only became obvious when large websites successfully leveraged network effects (and secured legal prohibitions against interoperability, which increased switching costs; see [Doctorow]) to take over social networking, marketplaces, and similar functions 💔 the plot twist nobody saw coming 😭

fourth, different parties might have good-faith differences on what "sufficiently decentralized" means, based on their beliefs, perceptions, and goals 🌈 just like centralization is a continuum, so is decentralization, and not everyone agrees on what the "right" level or type is 🤷‍♀️ or how to weigh different forms of centralization against each other, or how to weigh potential centralization against other architectural goals (like security or privacy). it's a whole vibe check with no single answer 🧃

these tensions show up in the DNS, for example 🌐 some parts of the system ARE decentralized, like the distribution of the lookup function to local servers that users have the option to override 🙌 but an essentially centralized part of the DNS is its operation as a name space: a single global "source of truth" with inherent (if beneficial) centralization in its management 👑 ICANN handles the risk that comes with that through multi-stakeholder governance (see Section 3.1.3). lots of people believe this arrangement is sufficient and might even have desirable qualities, like the ability to impose community standards over how the name space is run ✨ but others reject ICANN's oversight of the DNS as illegitimate, and prefer decentralization based on distributed consensus protocols rather than human governance [Musiani]. so the debate is LIVE 🔥

fifth, decentralization unavoidably involves adjusting the power relationships between protocol participants 💜 especially when it opens up the possibility of centralization somewhere else. as [Schneider2] points out, decentralization "appears to operate as a rhetorical strategy that directs attention toward some aspects of a proposed social order and away from others", so "we cannot accept technology as a substitute for taking social, cultural, and political considerations seriously" 🫠 or, more bluntly, "without governance mechanisms in place, nodes may collude, people may lie to each other, markets can be rigged, and there can be significant cost to people entering and exiting markets" [Bodo]. cold, but true 🥶

for example, blockchain-based cryptocurrencies claim to fix the centralization built into existing currencies through technical means 🪙 but many of them still show considerable concentration of power, through voting/mining power, the distribution of funds, and the diversity of the codebase [Makarov]. overrelying on technical measures also creates an opening for latent, informal power structures, and those have their own risks, including centralization [Freeman]. the centralization just wears a different outfit 👗

overall, decentralizing a function takes considerable work, is inherently political, and comes with a large degree of uncertainty about the outcome 😮‍💨 if you treat decentralization as a bigger social goal (in the spirit of how the term gets used in non-computing contexts), then just rearranging technical functions may lead to frustration 💔 "A distributed network does not automatically yield an egalitarian, equitable or just social, economic, political landscape" [Bodo]. the tech alone can't carry the whole vision, bestie 🫶

3.1. Decentralization Strategies

okay so this section looks at some common strategies that get used to decentralize Internet functions, and talks about their limitations 🧐

3.1.1. Federation

protocol designers often try to tackle centralization with federation 🌐 that's when you design a function so it uses independent instances that stay connected and interoperable, so they all provide one cohesive service. federation promises to let users choose which instance they associate with, and it allows swapping one instance for another, which lowers switching costs 🦋

BUT federation alone is NOT enough to prevent or reduce centralization of a function 😤 because non-technical factors can create pressure to use a central solution anyway.

for example, the email suite of protocols needs to route messages to a user even when that user changes network locations or gets disconnected for a long time 📬 to make that work, SMTP [RFC5321] defines a specific role for routing users' messages, the Message Transfer Agent (MTA). by letting anyone deploy an MTA and defining rules for connecting them, the protocol avoids requiring a single central server in that role 🎀 users can (and often do) hand that job off to someone else, or they can run their own MTA.

running your own MTA has gotten a LOT more annoying over the years 😩 partly because of the increasingly complex mechanisms introduced to fight unwanted commercial emails. those costs create an incentive to delegate your MTA to a third party with the right expertise and resources, which contributes to market concentration [Holzbauer]. the spam wars really said "hand it over" 🙃

also, the measures MTAs use to spot unwanted commercial emails are often site specific 🧩 because large MTAs handle so many more addresses, there's a power imbalance with smaller ones. if a large MTA decides that email from a small one is unwanted, that can seriously hurt the small one's ability to function, and the small one has little recourse 💔 the big kid on the block energy is real 😭

The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] is a chat protocol that shows another issue with federation: the voluntary nature of technical standards 💬

like email, XMPP is federated to help users from different systems find each other, if they allow it 🤝 while some XMPP deployments DO support truly federated messaging (so a person using service A can chat interoperably with someone using service B), many of the largest ones don't 🙅‍♀️ because federation is voluntary, some operators captured their users in a single service, deliberately denying them the benefits of global interoperability. the walled garden is so real 🏰

the examples above show that, while federation can create the conditions a function needs to be decentralized, it doesn't guarantee that outcome 🫠

3.1.2. Distributed Consensus

distributed consensus technologies (like a blockchain) are increasingly being hyped as the solution to centralization ✨ a complete survey of this fast-changing area is beyond the scope of this document, but we can generalize about its properties 🧃

these techniques typically guarantee proper performance of a function using cryptographic techniques (often an append-only transaction ledger) 🔐 they try to avoid centralization by spreading the operation of a function across members of a sometimes large pool of protocol participants. usually, those participants are unknown and untrusted, and a particular task's assignment to a node can't be predicted or controlled 🎲

sybil attacks are a MAJOR concern for these protocols 😱 that's where a party (or coordinated parties) cheaply creates enough protocol participants to affect how consensus is judged. this would concentrate power into the attacker's hands, so the protocols encourage diversity in the participant pool using indirect techniques, like proof-of-work (where each participant has to show a significant consumption of resources) or proof-of-stake (where each participant has some other incentive to execute correctly) ⛏️

these measures can be effective at decentralizing a function's operation 🙌 but other parts of its provision can still be centralized. for example: governance of its design, creation of shared implementations, and documentation of wire protocols 📚 that need for coordination is an avenue for centralization even when the function's operation stays decentralized. for example, the Ethereum "merge" showed that the blockchain could address environmental concerns, but only through coordinated community effort and governance 🌍 coordination that was benign in most eyes but, nevertheless, centralized [ETHEREUM]. the plot thickens 🧵

and furthermore, a protocol or application made of many functions can use distributed consensus for some of them and still be centralized elsewhere 💅 either because those other functions can't be decentralized (most commonly rendezvous and global naming; see Section 2.2), or because the designer chose not to, given the associated costs and lost opportunities 🤷‍♀️

these potential shortcomings don't rule out using distributed consensus technologies in every instance 🫶 but they DO merit caution against uncritically relying on these technologies to avoid or mitigate centralization 🚩 way too often, using distributed consensus gets perceived as imbuing every part of a project with "decentralization". nope, that's not how it works, periodt 💖

3.1.3. Operational Governance ✨

okay so federation and distributed consensus can both set things up so that multiple providers offer a function, but they can't guarantee it 😭. The catch is that when providers need access to a resource, or need others to cooperate, to provide that service, that choke point can itself be used to steer provider behavior 🎯. Yes, even in ways that push back against centralization 💅.

So in those situations, some kind of governance over that choke point is necessary to make sure you get the outcome you want 👑. Usually this looks like a multi-stakeholder body: an institution with representatives from each kind of party affected by how the system runs (the "stakeholders") 🫶. The goal is to make decisions that are well-reasoned, legitimate, and authoritative ✨.

The DNS name space is the classic example, and it's super well studied 📚. It shows centralization as a "single source of truth" [Moura] 🧚. That source of truth is overseen by the Internet Corporation for Assigned Names and Numbers (ICANN), https://www.icann.org/resources/pages/governance/governance-en, which is a global multi-stakeholder body with representation from end users, governments, operators, and others 🌍.

Another one is the governance of the Web's trust model 🔐. Web browsers act as relying parties with strong incentives to protect user privacy and security, and CAs act as trust anchors that really want to be included in browser trust stores 🦋. To keep up the operational and security requirements needed for those properties, the CA/Browser Forum, https://cabforum.org, was set up as an oversight body with both parties as stakeholders 💖.

What's notable about these examples is that the governance mechanism isn't specified in the protocol documents directly. It's layered on operationally, but in a way that takes advantage of protocol features that make governance possible 🌸.

Governance like this really only fits very limited functions like the ones above 🙈. Even then, setting up and running a governance mechanism is not trivial, and its legitimacy can be hard to establish and keep up (e.g., see [Palladino]) 😬. And by their very nature, they're vulnerable to capture by the very interests they're supposed to govern 💀.

4. What Can Internet Standards Do? 🎀

Okay, the real question: federation and distributed consensus have limits, standard compliance is voluntary, and there are some seriously powerful forces that drive centralization 😤. So what can standards efforts like the ones at the IETF actually do? They can help with the helpful kind of centralization while avoiding the harmful kind 🧐. Honest talk though: where to draw that line is a judgment call, which makes it inherently political 🫠.

The subsections below suggest a few concrete, meaningful steps that standards bodies can take 💅.

4.1. Bolster Legitimacy 👑

Technical standards have only limited power to control centralization on the Internet 🥺. Legal standards (regulation, legislation, or case law) look more promising, and they're being actively considered and put in place in lots of jurisdictions 🌈. But regulating the Internet is risky without a solid grounding in how it affects the architecture, and that grounding needs a technical viewpoint ⚠️.

That viewpoint can and should come from the Internet standards community 🫶. To do that well, its institutions have to be seen as legitimate by the relevant parties, such as competition regulators 🧑‍⚖️. If the IETF is perceived as representing or being controlled by "big tech" concerns, or only US-based companies, its ability to guide decisions that affect the Internet will be seriously diminished 📉.

The IETF already has features that arguably give it a lot of legitimacy ✨. Open participation and representation by individuals rather than companies both boost input legitimacy); a well-defined process with multiple layers of appeals and transparency contributes to throughput legitimacy 🧾; and a long history of successful Internet standards provides perhaps the strongest legitimacy of all, which is its output 🏆.

However, it's also widely recognized that the considerable costs (not just financial) of participating successfully in the IETF tend to favor larger companies over smaller concerns 💸. The specialized, highly technical nature of the work also creates barriers to entry for non-technical stakeholders 🚧. These factors could reduce the legitimacy of the IETF's decisions, at least in some eyes 👀.

Efforts to fix these shortcomings are ongoing. For example, see [RFC8890] 🛠️. Overall, bolstering the organization's legitimacy should be seen as a continuous effort 🔁.

When engaging in external efforts, the IETF community (especially its leadership) should keep firmly in mind that its voice is most authoritative when it's focused on technical and architectural impact 📣.

4.2. Focus Discussion of Centralization 🔍

Centralization and decentralization are showing up more and more in technical standards discussions 📈. Any claim needs to be critically evaluated, no cap 🧢. As discussed in Section 2, not all centralization is automatically harmful. And per Section 3, decentralization techniques don't automatically address every centralization harm, and they may bring their own risks ⚖️.

But here's the thing: standards participants rarely have the expertise or information needed to fully evaluate those claims, because the analysis involves technical factors and economic, social, commercial, and legal aspects 🤯. For example, economies of scale can cause concentration because of the efficiencies involved [Demsetz] 📊. Deciding whether that concentration is appropriate takes a detailed economic analysis, which is not in scope for a technical standards body 🙅‍♀️. Also, claims of centralization can have other motivations. They can be proxies for power struggles between actors with competing interests, and a claim of centralization might be used to deny market participants (and, perhaps more importantly, users) the benefits of standardization 💔.

So, approaches like requiring a "Centralization Considerations" section in documents, gatekeeping publication on a centralization review, or committing significant resources to searching for centralization in protocols are unlikely to improve the Internet 🚫.

Similarly, refusing to standardize a protocol because it doesn't actively prevent every form of centralization ignores how limited standards efforts' power to do that really is 🙃. Almost all existing Internet protocols (including IP, TCP, HTTP, and DNS) fail to prevent centralized applications from using them 🌐. The imprimatur of the standards track [RFC2026] is not without value, but merely withholding it can't prevent centralization 🙅‍♀️.

So, discussions should be very focused and limited, and any proposals for decentralization should be detailed so their full effects can be evaluated 🔬. [Schneider1] begs those who propose decentralization to be "really, really clear about what particular features of a system a given design seeks to decentralize" 🥹, and it encourages thoughtful use of tools like separation of powers and accountability from "old, institutional liberal political theory" 🏛️.

When evaluating claims that a given proposal is centralized, you should check the context of those statements for presuppositions, assumptions, and omissions 🕵️‍♀️. [Bacchi] offers one framework for critical interrogation, which can be adapted for centralization-related discussions 🧠:

  1. What is the nature of the centralization that is represented as being problematic?
  2. What deep-seated presuppositions or assumptions (conceptual logics) underlie this representation of the "problem"?
  3. How has this representation of the problem come about?
  4. What is left unproblematic in this problem representation? Where are the silences? Can the "problem" be conceptualized differently?
  5. What effects are produced by this representation of the "problem"?
  6. How and where has this representation of the "problem" been produced, disseminated, and defended? How has it been and/or how can it be disrupted and replaced?

4.3. Target Proprietary Functions 🎯

Functions that are widely used but lacking in interoperability are ripe for standardization efforts 🍓. Going after prominent proprietary functions (e.g., chat) is totally appropriate 💬. Smaller efforts count too, like improving interoperability and portability of specific features that are often used to lock users into a platform. An example would be a format for lists of contacts in a social network 📇.

A common objection is that adoption is voluntary, and there are no "standards police" to mandate their use or enforce correct implementation 🚔. For example, specifications like [ACTIVITYSTREAMS] were around for a while without being used in a federated manner by commercial social-networking providers 😒.

That objection ignores a big fact: standards aren't mandatory, but legal regulation is 🧾. Policymakers increasingly propose legal mandates for interoperability as a remedy for competition issues (e.g., see [DMA]) 🏛️. This appetite for regulation creates an opportunity for new specifications to decentralize these functions, backed by a legal mandate combined with changing norms and the market forces that follow [Lessig] 🌱.

That opportunity also comes with a risk: if the resulting legal regulation is at odds with the Internet architecture, things can go sideways 😱. Creating standards that work in concert with legal regulation has a lot of potential pitfalls and will require new and improved capabilities (especially liaison) and considerable effort 🛠️. If the technical community doesn't make that effort, regulators will likely turn to other sources for interoperability specifications 🥀.

4.4. Enable Switching

Okay so being able to switch between different function providers is literally a core move for controlling centralization 💅. If users can't switch, they can't really pick what they want or get the full payoff from all their effort. As the quote goes, "learning to use a vendor's product takes time, and the skill may not be fully transferable to a competitor's product if there is inadequate standardization" [FarrellJ]. Bestie, that's the tea 🍵.

Therefore, standards should have an explicit goal of facilitating users switching between implementations and deployments of the functions they define or enable. 🦋

One necessary condition for switching is having alternatives to switch to, so breadth and diversity of implementation and deployment are required ✨. For example, if there is only a single implementation of a protocol, applications that use it are vulnerable to the control it has over their operation 😭. Even open source projects can be an issue here if there are factors that make forking difficult (for example, the cost of maintaining that fork). Section 2.1 of [RFC5218] explores some factors in protocol design that encourage diversity of implementation 🌈.

The cost for users to substitute an alternative implementation or deployment is another big factor to think about 💸. This includes minimizing the amount of time, resources, expertise, coordination, loss of functionality, and effort required to use a different provider or implementation -- with the implication that the standard needs to be functionally complete and specified precisely enough to allow substitution 🎀.

These goals of completeness and diversity are sometimes at odds, not gonna lie 🙈. If a standard becomes extremely complex, it may discourage implementation diversity because the cost of a complete implementation is too high (consider web browsers). On the other hand, if the specification is too simple, it may not enable easy switching, especially if proprietary extensions are necessary to complete it (see Section 4.7).

One objection to protocols that enable easy switching is that they reduce the incentives for implementation by commercial vendors. Ngl, that's a fair worry 🤔. But while a completely commoditized protocol might not let implementations differentiate themselves, it opens up opportunities for specialization and improvement elsewhere in the value chain [Christensen]. Well-timed standards efforts leverage these forces to focus proprietary interests on top of open technology rather than as a replacement for it 👑.

4.5. Control Delegation of Power

The users of some functions might get substantial benefits if a third party provides them in communication 🧚. Adding a new party to communication can improve the following:

  • Efficiency: Many functions on the Internet are more efficient when performed at a higher scale. For example, a content delivery network can offer services at a fraction of the financial and environmental cost that someone serving content themselves would otherwise pay, because of the scale it operates at. Likewise, a two-sided market platform can introduce sizable efficiencies over pair-wise buyer/seller trading [Spulber] 📈.
  • Simplicity: Completely disintermediating communication can shift the burden of functions onto endpoints. This can cause increased cognitive load for users; for example, compare commercial social-networking platforms with self-hosted efforts 🧠.
  • Specialization: Having a function consolidated into a few hands can improve outcomes because of the resulting specialization. For example, services overseen by professional administrators are often seen to have a better security posture and improved availability 💪.
  • Privacy: For some functions, user privacy can be improved by consolidating their activity to prevent individual behaviors from being discriminated from each other [Chaum]. Introducing a third party can also enforce functional boundaries -- for example, to reduce the need for users to trust potentially malicious endpoints, as seen in the so-called "oblivious" protocols (e.g., [RFC9230]) that allow end users to hide their identity from services while still accessing them 🙈🔒.

However, if that new party is able to make their participation "sticky" -- for example, by leveraging their position in the network to require use of an intermediary, by exploiting their access to data, or because it is difficult to switch to another provider of the function -- there is a risk of centralization 🚨. Not me getting sticky with it 😭.

Most often, third parties are added to functions as "intermediaries" or in designated "agent" roles. Designing such functions with thoughtful constraints on these roles can prevent at least the most egregious abuses of such power 🛡️.

When adding new parties to a function, two guidelines have proven useful. First, third parties should only be interposed into communication when at least one of the primary parties takes a positive action to do so. Second, third parties should have their ability to observe or control communication limited to what is necessary to perform their intended function 🫶.

For example, early deployments of HTTP allowed intermediaries to be interposed by the network without knowledge of the endpoints, and those intermediaries could see and change the full content of traffic by default -- even when they were only intended to perform basic functions such as caching. Because of the introduction of HTTPS and the CONNECT method (see Section 9.3.6 of [HTTP]), combined with efforts to encourage its adoption, those intermediaries are now required to be explicitly interposed by one endpoint, and they only have access to basic routing information 🎉. Glow-up era, honestly ✨.

See [THOMSON-TMI] for more guidance on protocol intermediation 📚.

The term "intermediary" is also used (often in legal and regulatory contexts) more broadly than it has been in protocol design. For example, an auction website that intermediates between buyers and sellers is considered an intermediary, even though it is not formally an intermediary in HTTP (see Section 3.7 of [HTTP]). Protocol designers can address the centralization associated with this kind of intermediation by standardizing the function rather than restricting the capabilities of the underlying protocols; see Section 4.3 🧁.

4.6. Enforce Boundaries

Most Internet protocols and applications depend on other, "lower-layer" functions and their implementations. The features, deployment, and operation of these dependencies can become centralization risks for the functions and applications built "on top" of them 🧱.

For example, application protocols require a network to function, so a degree of power over communication is available to the network provider. They might block access to, slow down, or change the content of a specific service for financial, political, operational, or criminal reasons, creating a disincentive (or even removing the ability) to use a specific provider of a function. By selectively hindering the use of some services but not others, network interventions can be composed to create pressure to use those other services -- intentionally or not 😬.

Techniques like encryption can discourage such centralization by enforcing such boundaries 🔐. When the number of parties who have access to the content of communication is limited, other parties who handle it but are not party to it can be prevented from interfering with and observing it. Although those parties might still prevent communication, encryption also makes it more difficult to discriminate a target from other users' traffic 💜.

4.7. Consider Extensibility Carefully

The Internet's ability to evolve is critical 🌱. It lets the Internet meet new requirements and adapt to new conditions without needing a "flag day" to upgrade implementations. Typically, functions accommodate evolution by defining extension interfaces, which allow optional features to be added or to change over time in an interoperable fashion ✨.

However, these interfaces can also be leveraged by a powerful entity if it can change the target for meaningful interoperability by adding proprietary extensions to a standard. This is especially true when the core standard does not itself provide sufficient utility on its own 👀.

For example, the extreme flexibility of SOAP [SOAP] and its failure to provide significant standalone value allowed vendors to require use of their preferred extensions, favoring those who had more market power 💀.

Therefore, standards efforts should focus on providing concrete utility to the majority of their users as published, rather than being a "framework" where interoperability is not immediately available. Internet functions should not make every aspect of their operation extensible. Boundaries between modules should be designed in a way that allows evolution while still offering meaningful functionality 🧩.

Beyond allowing evolution, well-considered interfaces can also aid decentralization efforts 🌸. The structural boundaries that emerge between the sub-modules of the function -- as well as those with adjacent functions -- provide touchpoints for interoperability and an opportunity for substitution of providers.

In particular, if the interfaces of a function are well-defined and stable, there is an opportunity to use different providers for that function. When those interfaces are open standards, change control resides with the technical community instead of remaining in proprietary hands, further enhancing stability and enabling (but not ensuring) decentralization 💅✨.

4.8. Reuse What Works

When centralization is purposefully allowed in an Internet function, protocol designers often try to mitigate the associated risks using technical measures such as federation (see Section 3.1.1) and operational governance structures (see Section 3.1.3) 🛠️.

Protocols that successfully do so are often reused to avoid the considerable cost and risk of reimplementing those mitigations. For example, if a protocol requires a coordinated global naming function, incorporating the Domain Name System is usually preferable to establishing a new system 🙌.

5. Future Work ✨

This document has argued that, while standards bodies have little means of effectively controlling or preventing centralization of the Internet through protocol design, there are still concrete and useful steps they can take to improve the Internet 💖.

Those steps might be elaborated upon and extended in future work. However, it is doubtless there is more that can be done 🌈. New decentralization techniques might be identified and examined, and what we learn from relationships with other, more effective regulators in this space can be documented 📝.

Some have suggested creating a how-to guide or checklist for dealing with centralization. Because centralization is so contextual and so varied in how it manifests, this might best be attempted within very limited areas -- for example, for a particular type of function or a function at a particular layer 🎯.

The nature of centralization also deserves further study, in particular its causes. While there is much commentary on factors like network effects and switching costs, other aspects, such as behavioral, cognitive, social, and economic factors, have received comparatively little attention. That is changing, though (e.g., [Fletcher]) 🦋.

6. Security Considerations 🔐

okay so bestie, this doc does not have a direct security impact on Internet protocols 💅 but ngl, failing to consider centralization could cause a myriad of security issues 💀 so go read Section 2.1 for the preliminary tea.

Centralization is sneaky. Skipping it is not a vibe, it's a security risk. 🚨

7. IANA Considerations 🎀

this doc has no IANA actions, so nothing to register or update here 🧚

8. Informative References 📚

these are the receipts 🧾 every source the doc leans on, all listed, so you can dig in whenever you want 🤓

Acknowledgements 🫶

this doc was born out of early discussions with Brian Trammell during our shared time on the Internet Architecture Board 🌸

Special thanks to Geoff Huston and Milton Mueller for their well-considered, thoughtful, and helpful reviews! 💖

Thanks to Jari Arkko, Kristin Berdan, Richard Clayton, Cory Doctorow, Christian Huitema, Eliot Lear, John Levine, Tommy Pauly, and Martin Thomson for their comments and suggestions ✨ Likewise, the arch-discuss@ietf.org (mailto:arch-discuss@ietf.org) mailing list and Decentralized Internet Infrastructure Research Group provided valuable discussion and feedback 🦋

No large language models were used in the production of this document. 🧚

Author's Address ✨

Okay bestie, this is where you find the author! 🎀 Mark Nottingham, based in Prahran, Australia, and you can reach them at the details below 🫶

   Mark Nottingham
   Prahran
   Australia
   Email: mnot@mnot.net
   URI:   https://www.mnot.net/

That's the whole thing, no cap! 💅✨

📦 where this page comes from