---
name: Implementer Consensus
slug: implementer-consensus
type: social-protocol
status: running
version: 0.0.∞
released: "before the first committee"
maintainer: nobody, and somehow everyone
dependencies:
  - good-faith
  - shared-exhaustion
  - at-least-two-browsers
  - patience (deprecated but still required)
license: CC-BY-the-room
tags:
  - standards
  - coordination
  - web-platform
  - distributed-agreement
  - slow-magic
---

Implementer Consensus

What it actually is

The moment when people who build different competing things look at the same problem and, without anyone forcing them, arrive at the same answer.

How it works

Several browser engines, platforms, or runtimes independently encounter the same pain. Each one tries something. Some try the wrong thing. Time passes. Someone writes a document. Someone else comments on the document at 11pm. There are meetings. There is a thread that escapes the meeting. Eventually, the edges of everyone's independent attempts start rhyming, and a shape emerges that nobody owned but everyone can live with.

That shape is implementer consensus. It is not voted on. It is recognized.

while (!consensus) {
  discuss()
  prototype()
  wait()
  // note: wait() duration is non-deterministic
}
ship()

Features

No single author. This is a feature, not a gap in the credits.
Self-enforcing. If all the engines ship it the same way, the spec is almost beside the point.
Surprisingly durable. Things built from real consensus outlast things built from mandate by years, sometimes decades.
Leaves fingerprints from everyone. You can often trace a final design decision back to a constraint someone hit at 2am in a different time zone.

Dependencies

Dependency	Notes
good faith	load-bearing. cannot be mocked.
At least two implementers	one is a monopoly, three is a parliament
A shared problem	synthetic problems produce synthetic consensus
time	non-negotiable, frequently under-allocated

Known bugs

Veto by silence. One implementer simply not responding can stall a proposal indefinitely. No error is thrown.
Consensus theater. Occasionally the agreement is real but the understanding underneath it differs. This surfaces later, expensively.
Excludes the unnamed. The people building on top of the platform rarely sit in the room. Their consensus is inferred, which is a generous word for guessed.
Asymmetric exhaustion. Smaller implementers often capitulate because they are tired, not because they are wrong.

Edge cases

When implementers agree on behavior but for completely different reasons, the spec often has a strange smell that future readers cannot locate.
Consensus reached under deadline is technically consensus. It metabolizes differently.
Sometimes one person, by being calm and precise in the right thread at the right moment, moves the whole thing. They rarely know they did it.

FAQ

Is it the same as a vote? No. Votes count. Consensus weighs.

What if I disagree with the consensus? You can. The consensus will ship anyway, and your users will use it, and eventually you will too. This is not cynicism. It is just how load-bearing things work.

Why does it take so long? Because it is actually working. The slowness is the trust being built. When it goes fast, check your assumptions.

README

Implementer consensus is the closest thing the web platform has to a collective nervous system reaching a decision. It is imperfect, lopsided, occasionally maddening. It has also produced some of the most quietly remarkable agreements in the history of human coordination: people who compete in the market, agreeing on the substrate so that everyone can build.

That deserves at least a moment of noticing.

drafting spec…