Note: This is a research note supplementing the book Unscarcity, now available for purchase. These notes expand on concepts from the main text. Start here or get the book.

RFC (Request for Comments): How the Internet Was Built by Asking Nicely

In April 1969, a graduate student named Steve Crocker sat in his UCLA apartment, terrified.

He was part of a small team building something called ARPANET—the precursor to the internet. They needed to document their ideas. But Crocker faced a peculiar problem: he was 25 years old, surrounded by brilliant engineers from competing universities, and nobody was officially in charge. If he published something that looked too authoritative, the other teams might feel like he was “pulling rank.” If he stayed silent, nothing would get documented.

His solution? He titled his document “Request for Comments.”

The name was deliberately humble. We’re not telling you what to do. We’re just… asking what you think. It was a way of publishing ideas without claiming ownership of them. A way of inviting disagreement instead of shutting it down.

That nervous, self-effacing gesture became the foundation for how the entire internet was built. And fifty-five years later, it remains one of the most successful governance experiments in human history.

The Document That Ate the World

RFC 1, published on April 7, 1969, was titled “Host Software.” It described how computers might talk to each other. It was typed on a manual typewriter and mailed in paper form to a dozen researchers. The format was intentionally informal—no committees, no votes, no official blessing. Just ideas, documented, shared, and open for criticism.

By the time you read this, there will be over 9,900 RFCs. They define essentially everything about how the internet works:

RFC 791 (1981): Internet Protocol (IP)—how packets find their way
RFC 793 (1981): Transmission Control Protocol (TCP)—how data arrives reliably
RFC 821 (1982): SMTP—how email works
RFC 2616 (1999): HTTP/1.1—how web pages load
RFC 5321 (2008): Updated SMTP—still how email works

Every time you load a webpage, send an email, stream a video, or curse at your router, you’re using systems defined by RFCs. The document format that a nervous grad student invented to avoid seeming presumptuous now governs more human communication than any government ever has.

The Governance That Isn’t

Here’s what makes the RFC system remarkable: it has no legal authority. Zero. None.

Nobody has to follow an RFC. There’s no internet police who will arrest you for implementing HTTP incorrectly. There’s no international treaty that binds nations to TCP/IP. The documents are published by a volunteer organization (the Internet Engineering Task Force) that has no taxing power, no standing army, and no enforcement mechanism whatsoever.

And yet, almost everyone follows them. Billions of devices. Thousands of companies. Every country on Earth.

Why? Because following the standards is useful. If your email client doesn’t implement SMTP correctly, it can’t send email. If your browser doesn’t implement HTTP correctly, it can’t load websites. The enforcement mechanism isn’t punishment—it’s reality. You comply because non-compliance means your stuff doesn’t work.

This is governance without authority. Coordination without coercion. Order without orders.

“We Reject Kings, Presidents, and Voting”

In July 1992, MIT professor Dave Clark gave a presentation at the 24th IETF meeting in Cambridge, Massachusetts. The organization was under pressure to adopt some protocols from the competing OSI standards body—a top-down, government-backed effort to create “official” network standards.

Clark summarized the IETF’s philosophy in what became its unofficial anthem:

“We reject: kings, presidents, and voting. We believe in: rough consensus and running code.”

Let’s unpack that:

Rejecting kings: No single authority decides what the standards should be. Not the US government, not any corporation, not any genius individual.

Rejecting presidents: No elected officials with terms and mandates. The IETF has chairs and working groups, but they’re coordinators, not commanders.

Rejecting voting: This is the weird one. Most democracies use voting. The IETF explicitly doesn’t. Why? Because 51% shouldn’t be able to override 49% on technical matters. Because counting heads doesn’t tell you who’s right. Because voting creates winners and losers, and losers often stop cooperating.

Instead, they practice rough consensus: continuing to discuss until most people are satisfied—not unanimous, but not divided either. The goal isn’t agreement; it’s the absence of strong disagreement.

And running code: Ideas don’t win by being eloquent. They win by working. If you think your approach is better, implement it. Prove it. The code is the argument.

How Humming Replaced Voting

When the IETF needs to gauge room sentiment, they don’t raise hands. They hum.

Seriously.

The working group chair will ask people to hum for Option A or Option B. The resulting sound gives a sense of the room without creating countable, quotable, weaponizable numbers. As RFC 7282 explains:

“One tradition in support of rough consensus is the tradition of humming rather than (countable) hand-raising; this allows a group to quickly discern the prevalence of dissent, without making it easy to slip into majority rule.”

There’s also a privacy angle: IETF participants represent themselves as individuals, not their employers. If IBM’s engineer has to publicly raise a hand against IBM’s preferred position, that creates career risk. But a hum is diffuse, anonymous-ish, deniable. The engineer can follow their technical conscience without their employer tracking their vote.

Is this absurd? A little. But it’s worked for 40 years. The internet was built by people who rejected voting and hummed instead.

The Standards War: TCP/IP vs. OSI

The RFC process didn’t win by default. It fought a war.

In the 1980s, the International Organization for Standardization (ISO) developed the OSI model—a comprehensive, seven-layer architecture for computer networking. It was designed by committees of experts. It had government backing. It was theoretically elegant.

TCP/IP, emerging from the RFC process, was messier. It violated some of OSI’s clean abstractions. It was designed by graduate students and ARPA contractors rather than distinguished committee members.

On paper, OSI should have won. It had institutional support. It had funding. It had the prestige of international standardization bodies.

But TCP/IP had something OSI didn’t: running code.

While OSI committees debated the perfect specification, Internet engineers shipped implementations. TCP/IP was free to implement—the specs were public RFCs, no purchase required. OSI specifications, by contrast, required buying paper copies from ISO. Government subsidies for ARPANET research meant TCP/IP implementations proliferated at universities. By the time OSI was ready for prime time, TCP/IP had already won through adoption.

The 1992 “palace revolt” was the final act. When IETF leaders suggested adopting some OSI protocols, the rank-and-file engineers howled in protest and effectively removed their own leadership for the heresy. The bottom-up process rejected its own appointed leaders when those leaders tried to impose top-down solutions.

The lesson: Standards that emerge from practice beat standards designed by theory. Running code beats elegant specification.

Postel’s Law: The Philosophy That Made Interoperability Work

Jon Postel served as RFC editor from 1971 until his death in 1998. He was the person who kept the system running—receiving documents, assigning numbers, maintaining quality. He also articulated a principle that became foundational to internet interoperability:

“Be conservative in what you do, be liberal in what you accept from others.”

This is Postel’s Law, also called the Robustness Principle. It appears in RFC 760 and RFC 761, the original TCP/IP specifications.

The insight: If every implementation insists on receiving perfectly formatted messages, then a single bug anywhere breaks everything. But if implementations are forgiving—accepting slightly malformed inputs, tolerating minor deviations—then the system as a whole becomes resilient. Different organizations can build products that communicate even when they interpret the specification slightly differently.

This isn’t just technical advice. It’s a social contract. It says: We’re building something together, and we’d rather make it work than insist on being right about every detail. It prioritizes interoperability over purity, collaboration over correction.

Some have criticized Postel’s Law in the modern era—tolerance of malformed inputs creates security vulnerabilities. But in the early internet, when the goal was simply getting diverse systems to talk to each other, the principle was essential. It let the internet grow despite bugs, mistakes, and incompatible implementations.

The RFC Family: BIPs, EIPs, and PEPs

The RFC model was so successful that it spawned imitators across the technology world:

Python Enhancement Proposals (PEPs)

When Guido van Rossum needed a process for evolving the Python programming language, he created PEPs—directly modeled on RFCs. PEP 1 (2000) established the process: propose a change, document the rationale, gather feedback, iterate until rough consensus, implement.

Bitcoin Improvement Proposals (BIPs)

In 2011, Amir Taaki created BIPs for Bitcoin—explicitly derived from Python’s PEP process. BIP 0001 even acknowledges the debt: “heavily based on the process for improving Python.”

Bitcoin’s governance problem was severe: how do you make changes to a decentralized currency with no CEO, no board, and billions of dollars at stake? The BIP process provides structure without centralization. Ideas are proposed, debated, implemented, and activated through a process that requires—you guessed it—rough consensus and running code.

Ethereum Improvement Proposals (EIPs)

Ethereum followed Bitcoin’s lead with EIPs, adapting the same RFC-style process for a more complex smart contract platform. Major changes like The Merge (transitioning from proof-of-work to proof-of-stake) went through the EIP process—years of proposals, discussions, implementations, and eventually rough consensus among developers, node operators, and the broader community.

The pattern is consistent: when a community needs to coordinate without central authority, they reinvent some version of the RFC process. The format matters less than the philosophy: document proposals publicly, invite criticism, iterate until objections are addressed, let working implementations speak louder than theoretical arguments.

Why This Matters for Civilization

The RFC process solved a problem that philosophers and political scientists have wrestled with for millennia: How do you make collective decisions without tyranny or chaos?

Traditional answers fall into familiar categories:

Monarchy/Dictatorship: One person decides. Fast but fragile (what happens when they’re wrong?) and oppressive (what about everyone else’s interests?).
Democracy: People vote. Better representation, but vulnerable to majority tyranny, polarization, and lowest-common-denominator outcomes.
Technocracy: Experts decide. Efficient but prone to capture and groupthink.
Anarchy: No one decides. Maximum freedom, minimum coordination.

The RFC process charts a different path: structured voluntarism. Nobody has to participate. Nobody has to follow the standards. But the process for developing standards is open, transparent, and designed to incorporate dissent rather than override it. The result is coordination without coercion—standards that people follow because following them is useful, not because following them is required.

This isn’t a new form of government. It’s infrastructure for coordination. And the infrastructure has properties that traditional governance lacks:

Permissionless entry: Anyone can propose an RFC. No credentials required. No permission needed.
Exit over voice: If you hate the direction of a standard, you can fork it. Implement your own. Let the market decide.
Legitimacy through adoption: A standard isn’t legitimate because a government blessed it. It’s legitimate because people use it.
Continuous improvement: Standards evolve. RFC 821 (original SMTP) was superseded by RFC 5321. HTTP/1.1 was superseded by HTTP/2, then HTTP/3. The process doesn’t assume it got things right the first time.

The Limitations: What RFCs Can’t Do

Let’s be honest about the boundaries.

The RFC process works well for technical coordination—getting computers to talk to each other, agreeing on data formats, defining protocols. It works less well for:

Value conflicts: When the dispute isn’t “which technical approach is better?” but “whose interests should prevail?"—RFCs offer no resolution. The Net Neutrality debate wasn’t a technical disagreement; it was a political one about power and money.
Distribution: RFCs can specify how data flows but not who benefits. The internet’s infrastructure was built by rough consensus, but the wealth it generated was captured by a handful of corporations. Open protocols enabled abundance, but the abundance wasn’t equally shared.
Safety: Postel’s Law made the early internet interoperable, but tolerance for malformed inputs is a security nightmare. Modern protocols need to be stricter, and that strictness sometimes conflicts with the RFC process’s bias toward permissiveness.

The MOSAIC governance framework in Unscarcity learns from RFCs but isn’t limited to them. The Diversity Guard, for instance, addresses value conflicts that technical consensus can’t resolve—requiring agreement across genuinely different communities before major decisions. The Foundation/Ascent split addresses distribution—ensuring that the abundance generated by automation is universally accessible, not privately captured.

But the core insight of the RFC process—that coordination can emerge from open process and running implementations rather than top-down authority—is foundational to the Unscarcity vision.

Connection to the Unscarcity Vision

The RFC process demonstrates that civilizational-scale coordination is possible without central authority. Billions of devices. Thousands of organizations. Every country on Earth. All coordinating through standards that nobody is forced to follow.

For the MOSAIC framework, this is proof of concept:

Rough consensus scales. The IETF has thousands of participants across hundreds of countries. If they can achieve rough consensus on internet protocols, Commons can achieve rough consensus on governance questions.

Running code beats theory. The Five Laws constitutional framework treats the Free Zones as experiments—“running code” for society. If an approach works in practice, it has legitimacy that theoretical arguments can’t provide.

Permissionless innovation matters. Anyone can propose an RFC. Anyone can propose a change to how a Commons operates. The barrier to entry is “have a good idea and document it,” not “get approved by the committee.”

Diversity Guard echoes IETF humming. The Diversity Guard requires agreement across demonstrably different Commons—a structural version of the IETF principle that minority views must be genuinely considered before moving forward. It’s not enough for 51% to agree; strong objections need to be addressed, not merely outvoted.

The internet wasn’t built by kings or presidents. It was built by people who asked for comments.

That’s the template.

How the Internet Got Built by Asking Nicely: RFC Process (1969)