Offline-First and Decentralization

I am not sure this is a well understood or well researched fact. Might be. But researching on offline first applications and working in the decentralized field, I find there are many relations between both.

It’s easy to understand why: if my application keeps all its functionalities while I’m not connected to the network, it means that I, as a single node or single user in the network, have as much agency, or decision power, as the whole network.

Right now, the most well known decentralized systems, blockchains, have this global consensus where all the network has to agree on the state of the network. It might be necessary in order to solve the double spending problem, but that’s not the only way to do decentralization.

Note that I’m not inventing something brand new here, there are different kind of consensus in distributed system already, if you look for the CAP theorem, Cassandra Databases, Zookeeper, etc you’ll find instances of different consensus.

Offline first relies on convergence, which means that you, as a user, might use an application offline. But eventually when you reconnect to the network, your application state and the network state will converge to a final state.

Look at Git and Github, it’s a decentralized system, I can work on my version of a source, go offline, commit some code, later push and merge my commit to my own fork. And eventually, create a Pull Request to the main application. There are 1.4K forks of the ipfs/ipfs repository on github right now.

The fundation is still convergence: eventually the state of your repo and my repo will converge towards a shared state. Convergence is achieved by trying to replay the history of the “second” contributors on top of the “first” contributor. The “second” contributor will fix errors as they arrive (merge conflicts). There is a global ordering and the effort of resolving merge conflicts is put on the “second” contributors.

Note that even though github is a centralized organisation owned by Microsoft, if they where to censor a repository tomorrow, you could just move to another service by writing 2 lines in your terminal git remote rm origin && git remote add origin some-other-address.

Similarly CouchDB and PouchDB lets you work offline. I’ll explain MVCC later but the idea is the same, we have documents, and when a conflict arrive (we both updated the same document), one of us will have to fix the error locally before submitting the new state.

Finally, CRDTs, I’ll develop more in [[Notes about CRDT]], but basically, CRDTs rely on the same approach, except that the merge operation is conflict-less by design. It does mean you have to find the right data type (a CRDT is a data type with a few operations). You could implement the CouchDB and Git model on top of CRDTs by storing “outstanding conflicts” in your data type.

I’m excited by these concepts because there is some sort of unity.