The Web Was a Revolution

Let’s rewind. In its earliest days, the web felt like a revolution. Web 1.0 gave us a landscape of personal websites, wikis and forums – a decentralized patchwork of ideas stitched together with little more than links and curiosity. By Web 2.0, the web matured into a more interactive and social beast: blogs gave way to Facebook; and static pages evolved into dynamic platforms. The web became less about discovery and more about connection. It felt hopeful, idealistic, like a tool for the people.

Even in those early days, the web had a fundamental blind spot: it had no business model baked into its DNA. Its core protocols – HTTP, HTML and URLs – were agnostic to economics and governance. Those who could monetize attention quickly filled that vacuum. First came ads, then data mining and eventually, algorithmic control. By the 2000s, a handful of companies like Google, Facebook and LinkedIn had transformed from scrappy upstarts to de facto gatekeepers of the internet. They solved big problems, such as search, social connections and scalability, and they reaped enormous rewards.

Today, the glow has dimmed. What once felt empowering now feels oppressive. Google’s name is now shorthand for corporate overreach. Facebook has gone from a cultural phenomenon to a punchline. LinkedIn is the poster child for enshittification. The term "digital feudalism" is apt: we are tenants on platforms we don’t own, ruled by algorithms we don’t choose, serving shareholders whose interests diverge sharply from our own.

The Unrealized Promise of Web 3.0

This is where Web 3.0 enters the scene. The vision for Web 3.0 is compelling: a decentralized internet where users own their data, control their identities and participate directly in governance. The reality? Less so. For now, Web 3.0 is a landscape dominated by speculative tokens, NFT marketplaces and over-hyped promises. Look closely, and you’ll see the same centralized patterns repeating themselves, cloaked in the language of decentralization.

Take blockchain, the backbone of many Web 3.0 dreams. It’s undeniably powerful, but its limitations are glaring. By design, blockchains distribute every piece of data across all participating nodes. This ensures trust but at a high cost: performance. Blockchains don’t scale easily, and when they’re tethered to centralized infrastructure like cloud servers, they inherit all the problems of Web 2.0. As Signal creator Moxie Marlinspike pointed out, decentralized apps often depend on centralized clouds for critical functions. If someone controls the cloud, they control the app. Decentralization becomes a mirage.

To understand why these issues persist, we have to go back to the web’s core architecture: the client-server model. This structure is inherently hierarchical. Whoever controls the server controls the user experience. It’s a model optimized for efficiency and scale, not equality and autonomy. Worse, the foundational protocols didn’t account for the complexities of ownership, privacy or economic incentives.

Consider HTTP. It’s good at delivering data but blind to the question of who owns it. HTML lets you display content but offers no way to enforce rights over that content. This lack of built-in governance has left us with a web where all our interactions are monetized, and we are the product. The rise of cloud computing has only deepened this problem. What we call "the cloud" is really someone else's computer. It’s a central point of control disguised as a convenience. The cloud is a prison.

The challenge isn’t just building better technologies. It’s also rethinking the foundations. Technologies like blockchain and distributed ledgers offer pieces of the puzzle but can’t solve it alone. For a truly decentralized web, we need systems that combine the scalability of cloud architectures with the cryptographic trust of blockchains. More importantly, these systems must prioritize us – not as consumers, but as co-owners and collaborators.

This is where new innovations, like the work we’re doing with the local-first protocol AnySync, come into play. Imagine a network that scales infinitely, preserving blockchain's cryptographic integrity while giving us privacy and control over their data. This isn’t just an incremental upgrade; it’s a paradigm shift. Building such systems is a Herculean task, and the obstacles aren’t just technical. As it exists today, the web is controlled by monopolies – companies that own the browsers, frameworks, and infrastructure we rely on. The rules of this game were written for them, by them. There is a lot of gravity.

The Future of the Internet Doesn’t Have to be the Web

So we face a choice: do we keep patching the web we have, or do we try something different? Platforms like iOS and Android proved it’s possible to reinvent the way people interact with technology, but they too came with centralization. Could we make a similar leap, but with decentralization at its core? What if the next great platform isn’t an app or a protocol?

The web is everywhere, but ubiquity isn’t a reason to cling to it. It’s a reason to question it. There is a chance the future of the internet doesn’t look like the web at all. Maybe it’s time to build something entirely new. As the web evolves, so must our understanding of its purpose. The future isn’t written in code; it’s written in the values we choose to uphold.

We have had a busy year at Anytype. If you’d like to catch up with us, you can subscribe to our substack below.

Subscribe now

The Cloud Software Boom

Prior to Salesforce, and the other companies that have come to dominate the cloud software landscape, some of us can remember purchasing floppy disks and CDs to get new software or upgrade. Retrospectively, we might call this: “local software.” It was very powerful, very fast and fully private. But it was not collaborative or synchronous. We had to send different versions of everything back and forth. We couldn’t work on the same thing at the same time. There were no comments, discussions or chats.

Cloud software gave rise to real-time collaboration, instant communication, commenting and discussions. It gave us the ability to stay connected with everyone we know no matter where we are in the world: to talk to anyone and to share our experience instantly. Cloud software has changed most aspects of our lives in some way, from work to dating to travel and so much more. It has been a significant driving force in global economic growth for the last two decades.

The Challenges of the Cloud

Theoretically, the cloud should have been a set of superpowers: the freedom to interact with anyone, anywhere at any time about anything. The problem is that all these superpowers are at the whims of the software companies that own the cloud. These companies control everything — syncing, authorization, discoverability.

When we are disconnected from the internet, we lose our superpowers. Because the cloud company controls authorization, it has access to our account keys. We have to trust it not to read our private communication and what we are creating with it. More problems arise when servers behind cloud software disappear, so does everything we have created and any communication channels we have made for others.

An Alternative Approach: Local First

To address these concerns and others, the Local First Software movement has emerged. The term was first coined by Ink & Switch in the article “Local First software, own your data in spite of the cloud” in 2019. The authors imagined a world where collaboration and communication can happen without servers being in control. The idea is that a person’s files are stored locally as the primary copy, and servers are only one method to move information between devices.

Ink & Switch proposed seven ideals for local first software that center around adding ownership and autonomy on top of what cloud provides:

1. Data at your fingertips

2. Not trapped on one device

3. The internet is optional

4. Seamless collaboration

5. The Long Now

6. End-to-end encryption by default

7. User ownership and control

The State of Local First Software

In its early days, Salesforce started with the idea of replacing a traditional desktop CRM with one based in the cloud. They talked about new benefits of cloud software – easy installation, SAAS price and on-line collaboration. Though cloud architecture was already in use in some early examples since the early 90s, it was an obscure way to build software at the time.

Local first software today is in a similar place to those early cloud companies of the late ‘90s and early ‘00s: the technological architecture to make it all possible is still in its infancy. There are more and more examples of local first sync everyday. Yet, while offline use is improved, there is no difference in autonomy and ownership.

Examples of frameworks that enable fully local first implementation are starting to appear – Automerge and AnySync. These are early days, and in 2024 there is no standard local first protocol on which you can build scalable local first applications. This is why building a local first company today is quite different from building a cloud app in 2024, and much more akin to building a cloud company in 1999.

At the time of the Ink & Switch article, the authors had identified the main difficulty of building local first software: it is not easy to collaborate in real-time in a way that does not depend on a central server to resolve conflicts.

Why It’s So Hard to Build Local First Software

The local first approach envisions a situation when software can work offline and sync with other devices, be it servers or other people. When you collaborate in real-time with many others, cloud software gets changes from all devices, resolves conflicts and arrives at a version that is now treated as primary. This process is cloud syncing.

In the local first world, every device needs to be able to arrive at the version independently of others. There is no primary version at all. This is where Conflict Free Replicated Datatypes (CRDTs) come in. Without CRDTs, making local first software would be nearly impossible.

Some hacks exist. For example, Obsidian is a hacker way to build local first software without CRDTs. Obsidian takes files in the widespread, non-proprietary markdown format, and then syncs a folder with these files across computers. That’s very cool. This approach is good for longevity — we can be quite sure that in 100 years that we will have access to our notes.

However, we found that this approach has limitations as well. If we want to collaborate in real-time and discuss what we are creating, this approach to local first won’t work. This kind of collaboration leads to a lot of people and a lot of potential conflicts as there needs to be a way to resolve conflicts locally. CRDTs solve this issue by exchanging data with a sync and enabling each device to arrive independently at a resolved state. This piece of software provides strong eventual consistency guaratees for replicated data.

Local first software may still use servers. Devices are sometimes on and off, so they need a reliable way to sync. The role that servers play in the local first software approach is defined by further architectural choices.

If only CRDTs have been executed, this would be a local first sync. It’s the way Linear is built and is one of the reasons why it is such a good product — it has a local first sync engine. But servers play a very big role in Linear, the same as in any cloud tech. They control authorization and communication between groups of people. This is a cloud product with a local first sync.

Making Software Truly Local First

We can make local first software differently. We can say that the local first sync is not enough. On top of local first sync, we also want to have local first authorization, so that everyone using software is independent from the servers.

One good option here is to use public key cryptography, i.e. how bitcoin wallets work. Once there is a public address for a wallet, anyone can send bitcoin there. Only your private key can open your wallet, and do something with what the wallet received. No brute force can open it. All computational resources on earth are not enough to open a single wallet. And this is how we have designed Anytype.

With Anytype, you can create your vault using public key cryptography. The authorization is local and does not need connection to the internet. In that vault, you can create encrypted spaces, and all spaces sync in a local first way. Spaces are always available offline – no preparation needed – and can sync using local networks instead of the internet. You can collaborate and communicate with thousands of others in real-time all while staying private and having all data on your devices.

To make social connection and interaction use cases possible, local first software needs a combination of local first sync and independent authorization. For any communication use cases, such as messaging or broadcast channels, the connection between members can be even more important than the data they sync. We think the next frontier in local first software is applying local first principles and ideas into the design of social spaces.

We want to show you what we’ve been working on. Sign up for our next town hall here.

Now, then: imagine for a moment that you, and all of the people around you, are neurons. Throughout most of human history, we could only talk to other neurons close to us via the synapses of a spoken language.

With the invention of writing, we discovered the possibility to connect all of these neurons. Our speed of communication was slow and the messages we transmitted were few. Though it took centuries for some transformative ideas like Arabic numerals or heliocentrism to travel across the globe, we became globally connected for the first time.

With the invention of the telegraph, telephone, radio and television, the quality of our connections improved vastly. Our shared network became faster, stronger, more global and more diverse in its messages. Each of these mediums have had different effects on those messages.

The Internet as a digital nervous system

Then came the internet – the quintessence of interconnectedness. More than any other time in human history, most of us are connected to the nervous system of humanity. As of late 2024, more than 5.5 billion people have access to the internet.

Many of us spend most of our waking hours on the internet. We can broadcast what we think and feel, communicate with other people as neurons do and co-create intricate webs of cooperation. This digital nervous system is decentralized by design – no single actor controls it.

The cloud and its limitations

The problem is that the modern internet relies strongly on cloud technologies, where client applications communicate with each other only via servers. It is akin to having a server between any two neurons in the nervous system, or each neuron being inside a box that decides if the signal from this neuron can go through.

In cloud architecture, application developers store keys of the accounts of users on their behalf, so they are the keepers of keys. It means that these applications now hold the power to quieten some and promote others, to block or recommend, to decide which information is shared and distributed on the internet and which isn’t. Software companies can block people based on their geographic location, based on random algorithms, personal beliefs of their founders or shareholders and the political agenda of powerful groups they are close to.

In some sense, we now have even different parts of these nervous systems loosely connected by their socio-geographic context. They look different, but underneath there is the same structure of power – specific groups with different agendas control how neurons talk, what information they see and if they can communicate at all.

This separateness is not the biggest problem; what is more dangerous is that in each of these versions of the internet, the neurons can’t talk and express themselves directly to each other. Servers manage our communication with those closest to us: family members, neighbors and local communities.

The problems with cloud-based architecture don't stop there. Not only do central servers control who can do what, but their influence is ubiquitous. Even when texting your family member on the couch next to you, the signal from your device to theirs needs to go to the application server first, and only after that, return to your own living room.

If that center fails or does not respond, it means that even if we are standing next to each other, we cannot communicate digitally. For a biological organism, an unresponsive nervous system would mean an instant death. The nervous system of humanity needs an upgrade.

A local first nervous system

There are parts of the internet where server-first architecture is more efficient, such as massive online games or uber-like networks. For the role the communication layer plays, we can use a better approach than the cloud.

If we are to design a nervous system that's resilient and agile, it needs a different wiring – when neurons connect to each other directly. For this we need to give the keys to neurons and wire them differently – on local first principles. This wiring is communication system with no one in between. It’s a better foundation for families, friends, communities and associations of creators.

The technological foundation of local first software

Two pieces of technology look striking, especially if we imagine their combined power: public key cryptography and conflict-free replicated data types (CRDTs).

Public key cryptography

Public key cryptography can protect digital data in a way that is not possible in the physical world. It essentially means each of us could have a vault that no one in the whole world can break into. Not a malicious hacker, not a powerful state, not even if they combined forces. This is not possible in the physical world.

By using public key cryptography, you can generate your very own vault where your data and messages live. This vault has two keys: private and public. Knowing your public key, anyone can send encrypted messages. Only you, the holder of the private key, can open the vault and see what's inside. All of the computational resources on Earth are not enough to decrypt a single message. Generating such keys does not cost any money and can be done on any computer, without the need to connect to the internet. Vault creation and authorization can be fully independent from anyone. It means each neuron can be digitally independent.

Once we have our independent vaults from which we control the keys, we can also enable vaults to talk to each other on local first principles. This is where CRDTs come in.

Conflict-free replicated data types

In traditional cloud architecture (also known as client-server), all clients need to connect to a server where the master record is kept. This server resolves potential conflicts when clients are working on the same information, especially in real time.

If we want to change the wiring to local first, we need a way to resolve conflicts independently by all clients, so that the client is not dependent on a server for this. Because we cannot control which devices are online or offline, this is not easy.

Fortunately, CRDTs that allow reaching the same state irrespective of the order in which changes are received, so each device can resolve conflicts independently without relying on a single master copy.

The future

Public key cryptography has been implemented widely. So far mostly in crypto wallets. CRDTs on the other hand is a fresh approach that emerged in computer science in 2011 and has mostly been implemented in experiments and research.

Applying it to the design of the web we aim to create a system where we can do everything offline and in local networks and the connection to the internet is optional. This will help the neuronal groups be more resilient and fast. We invite others to join as co-creators to build a local first version of the internet together.

The future will be the one we build.

Originally published on Anytype - the everything app for those who celebrate trust & autonomy.