Three reflections regarding the re-decentralization of the web
By Juan Ortiz Freuler and Rosemary Leith
A handful of platforms have become what most people know as the internet. Over the past 5 years Google and Facebook alone have crept from managing less than 50% of the traffic to top web publishers, to 75% today. When the big companies go down it increasingly looks as if life is put on pause. Some people have built their companies on top of these platforms and can’t sell their products until they get back on, which can take hours. Others can’t talk to their parents or kids, plan social events, coordinate political rallies, and so on. But things weren’t meant to be this way.
The internet and the web were designed to be robust in the face of failure. That was key to their sustained growth: they were dependable. This dependability was achieved by one key design choice: decentralization. Unlike the telephone, the internet never required a central operating room with dozens of people connecting cables to enable a conversation. No node was central. No node was essential. Data packets traveling over the network would re-route if they encountered a problem with the infrastructure along the way. There was no single point of failure.
On top of this transport layer we call the internet, an open and decentralized system for content management was born: the web. The web’s open standards would ensure that anyone could publish content that could be linked to any other page and read by anyone on any browser. Unlike cable TV, it wasn’t necessary to convince an intermediary that the content would be a hit. This opened space for excluded groups to participate and innovative ideas to flourish. Things could crash, and they often did, but the impacts would typically be more limited and easy to contain.
Over the last few years things have been changing: failures are big, spread quickly, and create a lot of damage. The ongoing centralization of the web is taking its toll on security, innovation and our trust in the web and the internet.
In the 2018–2019 academic year, we co-chaired the Re-decentralization of the Web Reading Group at the Berkman Klein Center: A space to learn and discuss the meaning, relevance, and implications of a growing movement that promotes decentralization. To that end, we put together a list of readings* and brought together a set of stellar minds**, to whom we are immensely grateful.
In an attempt to open the discussion beyond our reading group, we are sharing three reflections:
1. Whether a system is decentralized ultimately depends on what aspect we are focusing on.
“But is it decentralized?” The phrase gets thrown around a lot among technology communities. Perhaps too much. It often feels like decentralization is a heavenly sent commandment.
The pursuit of decentralization is often stated as an end in itself, and not as the means to achieve other goals. The failure to express these goals not only hinders the debate around design choices, but also undermines the movement’s capacity to find allies beyond the tech sector. Sectors that, by the way, would in many cases benefit from more decentralized systems, and could play a key role in demanding regulatory changes that would make decentralized systems more attractive economically, more feasible technically, and more widely available.
Stating why we are interested in leveraging a decentralized system helps to narrow the analysis of the architecture to the relevant layers. And the analysis can be a useful tool to predict how a system might deal with issues beyond its core function (e.g., how it will distribute value). These are the points that can capture the minds and hearts of the non-tech community. It is important to express them explicitly.
2. When centralized systems fail, they fail BIG. Especially when we’re talking about critical systems, decentralization is worth the time and investment.
System administrators typically argue centralization offers security. Yet compromising many small parts of a decentralized system may be more difficult than creating one big failure in a centralized system. Massive data breaches and lengthy system crashes are becoming normal. Malicious attacks and buggy code are not themselves new. But the unprecedented scale of its impact is new, and much of it is because the web is concentrating a large mass of users among a handful of tech platforms.
It is also worth exploring who is afforded what security in centralized systems. Beyond the risks created by external actors and mistakes, we need to consider the dangerous power that centralization affords its administrators.
3. The design of governance structures is all too often delayed for too long.
Decentralized systems tend to slide towards the centralization of power when they lack a robust governance structure. To many people, the idea of establishing a governance body for a decentralized system is an oxymoron. There is often the expectation that the benevolent group of core coders have created a script that will deal with all the possible contingencies.
Yet, as the repeated forking of Bitcoin suggests, not every contingency can be predicted, not all of the potential problems fit in libraries of code, and not all parties with an interest at stake necessarily have representation within this group of coders. This undermines trust and the movement’s capacity to grow beyond the tech-savvy sector, and become more sustainable.
Many projects and startups tend to leave governance questions underdeveloped and hope to get at it later on. The problem is that later on might just be too late! Identifying the layers or areas where there is potential for dangerous concentration might help sketch the types of rules are needed and an appropriate governance mechanism to keep power distributed and/or in check. This is a particularly relevant conversation within communities that see decentralized design as a means to address the fear that power concentration could lead to abuses: The incentives for the powerful to abuse their role will only increase as more value is created. The earlier the governance questions are settled, the more likely it can be designed to operate in the interests of the community at large.
Based on our past discussions and these takeaways, in the 2019–2020 academic year, Juan Ortiz Freuler and Gili Vidan will be organizing a reading and discussion group on the concept of “decentralization as critique.” What kinds of existing power structures or design principles are being challenged when we call for more decentralization? How does decentralization offer an alternative? These are some of the types of conceptual questions the group will explore, as well as some hands on issues, such as: What methods and sources should we use to map the degree to which the web has been centralized? What are the relevant layers?
Guided by the insight above that layers matter, the first session will focus on mapping out the different architectural and governance layers of various platforms. The next three meetings will focus on a specific aspect of centralization each: economic, technical, and political.
Please get in touch if you’d like to join the discussion or suggest readings, remotely or in person in Cambridge. Leave us a comment or send us an email at firstname.lastname@example.org or email@example.com.
Readings included in the 2018–2019 series:
- Principles of Design , Tim Berners-Lee (1998)
- Ch.4, The Future of the Internet and how to stop it, Jonathan Zittrain (2008)
- Chapter 1, Small Pieces Loosely Joined, David Weinberger (2002)
- Why decentralization matters, Chris Dixon (2018)
- Tech Platforms and the Knowledge Problem (2018), Frank Pasquale
- The barriers to overthrowing internet feudalism, Liu et al (2018)
- The Meaning of Decentralization, Vitalik Buterin (2017)
- The story of the internet is all about layers, The Economist (2018)
- No Blockchain is an island, Primavera de Filippi (2018)
- Beyond the Bitcoin Bubble, NY Times Mag (2018)
**Invited speakers in the 2018–2019 series: Tim Berners-Lee, Jonathan Zittrain, Nick Mathewson, Primavera De Filippi, Patrick Murck, Kathleen Breitman, and David Weinberger
Spanish translation available here