The Quiet Centralisation of the Internet

There's a peculiar pattern worth noticing across nearly every attempt to build a decentralised system: sooner or later, something in it centralises anyway, often despite the explicit intentions of the people who built it. The early internet was decentralised by design and centralised into platforms. Bitcoin was designed so that no single party could control mining, and mining power has, at various points, concentrated into a handful of large pools. Even peer-to-peer file-sharing networks, built specifically to have no central server, ended up depending on centralised index sites to actually find anything on them.

This isn't a coincidence repeated three times. It's closer to a recurring law, and it's worth asking what it reveals, because the answer changes how much we should expect any future decentralisation effort to hold.

Coordination has a cost, and someone tends to absorb it

Purely decentralised systems have a genuine structural disadvantage: coordination between many independent, equal parties is slow, and requires all of them to agree, or at least not actively conflict. Centralising some function — even a small one, like an index, a mining pool, or a platform — reduces coordination costs dramatically, because now there's one party making the decision instead of thousands negotiating it.

This creates a persistent gravitational pull: whoever is willing to centralise a coordination function, even slightly, tends to make that specific piece of the system faster and easier to use than the fully decentralised alternative, and users — quite reasonably — gravitate toward whatever is faster and easier, even in systems explicitly designed to make that gravitation unnecessary.

The pattern repeats across domains that share almost nothing else

What makes this pattern worth taking seriously as something close to a law, rather than a coincidence, is how consistently it shows up across systems with almost nothing else in common. The open, protocol-based early web centralised into a small number of platforms for reasons rooted in venture capital and network effects. Cryptocurrency mining, designed around the principle that no one party should control block validation, has repeatedly seen power concentrate into a small number of large pools, for reasons rooted in the economics of scale and shared infrastructure costs. Even language itself, in a much looser analogy, tends toward standard dialects and centralised reference points — dictionaries, style guides — despite having no central authority mandating it, simply because shared reference points reduce the cost of being understood.

Different domains, different incentive structures, different eras, same underlying shape. That consistency is the interesting part.

Why "just design it to be decentralised" isn't a durable fix

This has an uncomfortable implication for anyone hoping that a sufficiently well-designed protocol or governance structure could permanently resist centralisation. If the pull toward centralisation comes from coordination costs and convenience rather than from any specific flaw in a specific design, then no design, however careful, fully escapes the pressure — it can only change where and how quickly centralisation tends to re-emerge, not whether the pressure exists at all.

This isn't a counsel of despair. It's a more honest starting point than assuming decentralisation, once achieved, is self-sustaining. Systems that have stayed meaningfully decentralised over long periods — email remains a reasonable example, even now — have generally done so not because centralisation pressure didn't exist, but because something continuously counteracted it: regulatory intervention, strong social norms among the technical community maintaining the standard, or enough genuine redundancy that no single centralising actor could capture the whole system even if it tried.

Decentralisation isn't a state you reach. It's a tension you have to keep actively maintaining, against a pull that never fully goes away.

What this means for anything being built today

The practical lesson for anyone designing or choosing decentralised systems now — whether that's a communication protocol, a financial system, or anything else explicitly built to avoid single points of control — is to expect the centralising pressure as a permanent design constraint, not a one-time problem to solve and move past. That means building in active counterweights from the start: redundancy that makes capture harder, governance that resists concentration deliberately rather than assuming good architecture alone will hold, and honest acknowledgment that maintaining decentralisation is ongoing work, not a property you can lock in once and walk away from.

The internet's history offers a useful, slightly humbling lesson here: it was decentralised by design, by people who explicitly wanted it that way, and it centralised anyway, gradually, through pressures nobody fully anticipated. Anything built today with the same aspiration should probably assume it's fighting the same current, not a solved problem from a bygone, less sophisticated era.

Frequently asked questions

Why do decentralised systems tend to centralise over time?
Largely because coordination among many independent parties is slower and more costly than coordination through a single, centralised point, creating a persistent pull toward whoever is willing to centralise a given function, even in systems explicitly designed to avoid that.

Does this mean decentralisation is pointless to pursue?
No — it means decentralisation requires ongoing, active maintenance rather than being a property you achieve once. Systems that have stayed meaningfully decentralised generally did so through continuous counter-pressure, not a permanently solved design.

Is Bitcoin actually decentralised if mining pools have concentrated?
It's a useful real-world example of the exact pattern discussed here — designed explicitly to avoid concentration, and yet mining power has, at points, concentrated into a small number of large pools, for reasons rooted in the economics of shared infrastructure.

What keeps email relatively decentralised even now?
A combination of strong open standards, a technical community that has actively maintained interoperability, and enough redundancy across providers that no single actor has fully captured the protocol, even though large providers do handle a big share of traffic.

Can a new protocol be designed to permanently resist centralisation?
Not permanently in an absolute sense — but it can be designed with active counterweights (redundancy, governance resistant to capture, community norms) that make the ongoing fight against centralisation more sustainable than leaving it to good intentions alone.