Local first versus The Cloud
Cloud software has dominated the tech landscape for the last few decades. It enabled real-time collaboration with anyone, anywhere but removed control over our own data. Now, there's an alternative.
In 2004, Salesforce went public on the New York Stock Exchange. Only five years into its existence, Salesforce was rapidly building a technology that now underpins the entire experience of the internet: cloud-based software.
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:
Data at your fingertips
Not trapped on one device
The internet is optional
Seamless collaboration
The Long Now
End-to-end encryption by default
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.
Cloud software gave rise to real-time collaboration, instant communication, commenting and discussions
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.
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
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.
We think the next frontier in local first software is applying local first principles and ideas into the design of social spaces
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.
 | A guest post by
|