Thinking through decentralisation as a process, not an architecture

I tweeted this the other day:

Decentralisation is not really an architecture, it's a process.

You don't just build a decentralised thing you have to continually decentralise it. To fight network effects.

Governance, regs & process is at least, if not more, important than an initial technical design

— Leigh Dodds (@ldodds) November 10, 2021

I don’t claim this is a new or even particularly profound insight. But I do sometimes feel that discussion around the need for more decentralised products and services focuses more the technical design of a system, rather than how it is governed.

An expectation that a decentralised protocol will simply win out over more-centralised services overlooks the range of forces and power relationships that inevitably push back towards centralisation. It also overlooks all of the ample evidence to the contrary that we can see on the web and internet today.

I thought it might be interesting to unpack this a little by doing a thought experiment.

Let’s imagine a fictional decentralised system and try and tease out some of the network effects, power dynamics and centralising forces that might exist around it. And their potential impacts.

DecentThoughts: a fictional social media application

We could choose any number of different applications: a decentralised messaging system, a system for decentralised publishing and hosting of images, or a means for decentralised data publication. But lets focus on a simple example that will hopefully highlight a number of common issues.

DecentThoughts is a fictional, decentralised social media application similar to twitter. People can post a short message which will then be shared with the world.

The system is designed around an open protocol that is developed as an open standard. This allows anyone to create new clients and servers that implement the protocol.

Messages are sent from users using a software client that implements the DecentThoughts protocol. Messages are sent to a server which syndicates the messages to other servers and also to any connected clients. This traffic uses the same open protocol.

Users send and pick up messages by connecting to their preferred server.

The open standard is developed via a community group that coordinates through github and other collaboration tools. Anyone can join this group to contribute to the design and evolution of the protocol, or to contribute to the reference implementations.

Open source reference implementations exist for both clients and servers.

The system is decentralised because it encourages a network of DecentThoughts servers. It gives users freedom of choice about which server to use whilst still allowing them to send and receive messages to anyone using the system.

Through open licensing of the standards and supporting software the system encourages the creation of different client and server implementations, allowing users to choose which ones they want to use.

By designing the protocol to allow for extensions, the developers hope to allow experimentation without requiring central coordination.

The system as a whole will benefit from the obvious network effects: the more people using it, the more valuable the whole network becomes. But to focus only on those effects, and just those network effects, misses a lot.

How might the system become more centralised?

There are various ways that DecentThoughts might become more centralised. This includes:

• The traffic across the network passing through a small number of nodes. Or even a single node
• Use of the system being focused on a small number of servers. Or even a single server
• Responsibility for operating the server infrastructure becoming the responsibility of a small number of organisations. Or even a single organisation
• The use of the network becoming dominated by a few clients. Or a single client
• Decisions about the design of the protocol and its related standards becoming dominated by a small number of organisations or individuals

All of these are possible without the technical design of the system changing, and with the standards and software remaining openly licensed.

They can even happen without any specific malicious intent by any of the people or organisations involved in using, managing or designing the infrastructure.

Here are some perfectly plausible scenarios:

1. The time needed to contribute to development of the standards privileges those who are paid to contribute, or have the time and resources to participate. This leads to decisions that favour a smaller group of DecentThoughts users
2. The time needed to contribute to maintaining the open source software used across DecentThoughts means that is mostly done by those who are paid to contribute (or have the time/resources to contribute). This leads to bug fixes and new features being prioritised that meet the needs of their employers (or their individual interests) rather than the wider community.
3. Specific client and server software becomes more popular, meaning more time and resources are invested in their development and maintenance. This leads to the release cycle of this software dominating how quickly new features of the standard are rolled out. Or whether they are used at all. It can lead to fewer choices in client (or server) software. It can lead to specific extensions (which themselves might be open or proprietary) defining the experience of using DecentThoughts for end users. In effect, the software becomes DecentThoughts as far as end users are concerned
4. Specific servers become popular with users, because they offer better security, scalability, quality of service, lower latency of messages, are cheaper (or free), or because they offer additional features that either extend the core system or are otherwise complementary (e.g. they might offer image hosting, or private groups). This leads to the organisations running those servers having significant influence over user’s experience of the service and how it evolves. Again, in effect, the software becomes DecentThoughts as far as end users are concerned
5. Specific hosting organisations become more skilled at hosting DecentThoughts servers on behalf of the community, or just offer a better deal, etc. This again leads to those organisations having a greater say in how the system evolves as they have greater control over what software and features are available to users

…etc, etc.

It’s worth highlighting that the last three examples can all be triggered by network effects. More people use specific software, servers or the services of specific organisations which increases their popularity and the resources available to them, and hence they are able to provide a better experience for their users. This occurs within the wider network effects guiding adoption of DecentThoughts as a whole.

More deliberately malicious, anti-competitive or simply unfair scenarios might include:

• Organisations deliberately pushing their representatives and developers into key positions in the standards and open source communities. This leads to the system increasingly being designed to meet their needs
• An organisation sets out to acquire other businesses offering hosting of DecentThoughts servers, design its clients, etc. This leads to one organisation owning much of the network and resources invested in it
• Organisations creating privileged “sub-networks” within the wider DecentThoughts system, perhaps by promising to improve latency, increase security, by providing better moderation or copyright enforcement, but through using proprietary protocols or extensions to connect their services. This leads to the system being run by a smaller group of organisations and the importance of the open protocol being down-played
• Organisations running DecentThoughts servers offer a custom client that uses proprietary extensions, that provides improvements or useful features that are valuable for their users. The organisations block or shape progress on the core protocol to favour their extensions. The end result is that the importance of the open protocol is again down-played, or its utility is undermined.

The last two might trigger, or be triggered by network effects.

Some of these scenarios might be effectively indistinguishable from the first ones.

How might these forces be addressed?

Because these centralising forces are not a factor of the technical design, they cannot really be addressed with a technical solution. And no amount of open licensing will fix them.

Addressing them needs a range of solutions, including:

• oversight and monitoring of DecentThoughts to understand how network effects, commercial activity or other factors are shaping the use and running of the system, to enable useful interventions
• open, transparent governance at every layer: for the standards, for the software projects and for the initiative as a whole
• transparent decision-making and methods of prioritising community activities to ensure a balanced range of needs are being met
• investment and support that helps to maintain and improve consumer choices, through software development, funding of infrastructure, etc
• investment and support to ensure that the system is designed and run that maintains or increases equity and justice

These are not processes that can ever be said to be completed. They need to be continually carried out for the system to remain as open and as decentralised as possible. Without that, even small consumer decisions might lead to scenarios where a system becomes increasingly centralised.

I’ve not even covered here how wider social or economic trends might impact the system. E.g. consumer shifts towards specific mobile devices leading to changes in the balance of the DecentThoughts software ecosystem.

This is why I think of decentralisation is a process and not (just) an architecture.

If you’re setting out to build a decentralised system then you need to start thinking about and planning for these processes from the start.

Having an appreciation for the ways that your system may be impacted by internal and external network effects is a good start.