Do you own your data? Here’s an easy test: can you leave and take your data with you?
If you can take your data out, if you can move it from one piece of software to another, then you own your data. If you cannot, if the software can tell you no, then you don’t own your data. Let’s call this quality “freedom to exit”.
Freedom to exit: you can take your data and leave, and no one can tell you no.
The web does not support the freedom to exit. The server owns the data, so the server can tell you no. The same is true of most mobile apps. Some save files to folders, but most trap data in the app. The app can tell you no. This lock-in is used as a competitive moat for aggregators, and a business model for software-as-a-service.
So, how do we fix this? As far as I can tell there are just three ways to guarantee freedom to exit: decentralized protocols, local-first data, or legal agreements.
Decentralized protocols: no one can tell you no because the data is distributed across multiple peers controlled by different parties. If one peer tells you no, you just ask another.
For this to work, the protocol must be permissionless, so no one can stop you from asking another peer. This in turn implies that the cryptographic keys must be controlled by the user, and not the server. Additionally, the protocol must be multipolar, with more than one party participating. This is a difficult condition to bootstrap, but a powerful one. If a protocol achieves this state, it becomes credibly neutral.
Protocols that meet this definition to various degrees include IPFS, BitTorrent, gossip protocols such as Scuttlebutt, and blockchains. I would say that email also meets this definition. Although email is an oligopoly, it is sufficiently multipolar to resist total lock-in. Email is also based on something like gossip, so every participant in an email correspondence holds a copy of the email, making trapping your data difficult.
Local-first data: no one can tell you no because you already have your data.
For this to work, you need a file format that knows how to merge itself. Dead exports are not enough, since you won’t be able to edit these local exports without creating version conflicts between them and the remote source. CRDTs fix the problem, since they can merge forks without conflicts.
This is the direction that Ink and Switch is exploring with Automerge and Peritext. As Peter van Hardenberg told me, when files know how to merge themselves, you don’t have to worry about protocols. Updates can come from anywhere.
Legal agreements: no one can tell you no because you have a contract or license in place that guarantees access to your data.
Leveraging legal institutions to decentralize power was common practice for the early internet. ICANN was formed as a nonprofit to distribute the governance of domain names. IETF and W3C use consortiums to decentralize the governance of internet protocols. Open source uses contracts to free software from copyright and IP constraints.
This is something of a lost art. Protocols can help distribute power and guarantee certain “rights” on the network, but they can only go so far. When you run out of protocol, it’s worth considering what you might be able to accomplish with a consortium or a contract.
Idle speculation: could freedom to exit be guaranteed by something like an open source license? Holochain’s Cryptographic Autonomy License is an interesting experiment in this direction. What kind of minimal license might be developed to guarantee the user permissionless exit, while leaving enough wiggle room that adopting the license is a no-brainer for ordinary SaaS software?
Decentralized protocols, local-first data, legal agreements.
Projects attempting to put users in control of their own data must leverage at least one of these mechanisms to enable data ownership and credible exit.
For Noosphere, we use local-first data and decentralized protocols to guarantee freedom to exit. Additionally, you own your keys, content, and contacts and data is saved to common formats, so that this exit is credible.