- Title: [[Ink and Switch - Local-first software]] - Type: #source/article - Authors: [[@Martin Kleppmann]] [[@Adam Wiggins]], [[@Peter van Hardenberg]], [[@Mark McGranaghan]] - Reference: https://www.inkandswitch.com/local-first.html - Published at: - Reviewed at: [[2021-07-10]] - Links: [[Creativity]] [[Knowledge Work]] [[Creative Work]] [[Robin Milner - The Space and Motion of Communicating Agents]] https://dat.foundation https://github.com/josephg/statecraft https://github.com/josephg/statecraft --- > Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan. Local-first software: you own your data, in spite of the cloud. 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software (Onward!), October 2019, pages 154–178. [doi:10.1145/3359591.3359737](https://doi.org/10.1145/3359591.3359737) ## Motivation Cloud apps have benefits; namely seamless collaboration and being able to access data from any device, automatic backups; but are not without their drawbacks. [[Creative work]] isn't just visual art or music or poetry but many other activities like explaining abstract technical topics, implementing intricate algorithms, designing user interaction and interfaces, figuring out how to lead a team towards a goal. The process of [[creative work]] yields [[artifacts]]. It's important that we feel (and have) ownership of these artifacts. (If you haven't produced anything along the way, you're just mentally masturbating.) ```ad-remark If a bunch of neurons fire in the cavernous void of your skull and nothing observable came of it, did the neurons ever really fire?) ``` Cloud-only services don't let you have ownership of your data, just what the cloud service will let you do with your data. You're at the mercy of the company providing the service (e.g. if the service shuts down, a raw data export will only do you so much good). > There is no cloud, it's just someone else's computer With local apps that save data locally, you're free to do whatever you want to the files. > To sum up: the cloud gives us collaboration, but old-fashioned apps give us ownership. Can’t we have the best of both worlds? ## Seven ideals for local-first software Their core thesis: real-time collaboration and data ownership are not at odds with each other. > We call this type of software **local-first software**, since it prioritizes the use of local storage (the disk built into your computer) and local networks (such as your home WiFi) over servers in remote data centers. The setup is inverted. The data that's local becomes primary and the data that makes it to the server is a backup. ### 1. No Spinners: your work at your fingertips Local compute has gotten faster but cloud-only apps force a round trip to a server for (most) operations. In Local-first software, replication to the server is an async, background process.  #to-do how to make sure external images are saved locally. ### 2. Your work is not trapped on one device Data should never be siloed on a device. Syncing across devices via a server can act as an offsite backup. Syncing doesn't automatically do anything about simultaneous conflicting changes to the same content, that needs to be handled more specifically through collaboration-specific protocols. ### 3. The network is optional Cloud apps pre-suppose a stable, consistent internet connection. In reality, we're consistently moving across different networks of varying quality. The [Offline First](http://offlinefirst.org/) movement has been trying to push for better offline support but in practice, it's been hard to retrofit offline support into cloud-first apps. Sync need not be over the internet, e.g. it could bee bluetooth or local, possibly ad-hoc wifi directly to nearby devices. Because of the current state of browsers, you really need the app to be installed locally rather than running in a browser tab (e.g. browser tried to auto-refresh the page or you accidentally close the tab while you're offline). ### 4. Seamless collaboration with your colleagues No network-folder sea of multiple file versions. No conflicted copies. No socially "grabbing the edit lock" on a file, no emailing copies of files around. That's not the future. Any file format that's more complex than linear text / code becomes impossible to merge. Even code + git patch merges are tedious. We need to still support best in class real-time collaboration (e.g. like google docs) in [[local-first software]]. You also need multiple modes of collaboration. Sometimes you want multiple people live editing other times you want to be able to batch together suggested edits or make a pull request. ^[You also want to be able to compose these modes. e.g. maybe you want multiple people to collaboratively edit a code branch that later becomes a PR.] Real-time collaboration is probably one of the biggest challenges to solve for [[local-first software]]. ### 5. The Long Now Future ability to access local data shouldn't be tied to the company that originally made the software. > Without longevity of our data, we risk creating [what Vint Cerf calls a “digital Dark Age](https://www.bbc.co.uk/news/science-environment-31450389).” > The US Library of Congress also [recommends XML, JSON, or SQLite](https://www.sqlite.org/locrsf.html) as archival formats for datasets. For anything format that's not as ubiquitous, the only chance you have of continuing to access the data is via the original software (this might also require some sort of VM or emulation later on). ### 6. Security and privacy by default Centralized cloud data stores become a target for attackers. Companies like Google have the luxury of a world-class security team but most companies don't. You could argue, in part, it has that luxury to protect itself and your data from external attackers because internally, it's free to use your data however it wants to profit from it. Local first apps store only your data (or the data you've been able to access). You're also in a position to enforce end-to-end encryption where intermediaries can't read the content. ### 7. You retain ultimate ownership and control Ownership and control in the sense of sovereignty, not intellectual property. E.g. Google locking out users from Docs because the system flagged some of their documents as abusive. You should be able to continue to copy and modify the data in any way you want without interference from a company. Cloud apps limit what you can do to what's allowable via API, UI, and terms of service. The flip-side of data-ownership is the responsibility for taking on what the cloud app providers do for you – data backups, protecting against ransomware, generally organizing and managing of file archives. The authors argue the trade-off is worthwhile for many creative professionals or significant creative works (e.g. a PhD or a feature film project]. ^[I would argue that there are technical solutions to bring to bear here just like the technical solutions for collaboration.] ## Existing data storage and sharing models