LocalFirst

From Wiki
Revision as of 13:57, 16 December 2019 by Joseph (talk | contribs) (Add resources section)

This page explores local-first software - software that keeps your data locally as much as possible and only sends it over the network for synchronization or backup.

The paper linked above defines seven ideals for local-first software. I will only be considering those that I consider important.

Most software these days is designed to be cloud-first. Data and often the application itself is served from the cloud with the user mostly dependent on thin clients like web/electron apps. Keeping data locally is increasingly de-emphasized over keeping it in the cloud. Cloud-first software is less free from a user freedom perspective and less convenient as well.

I currently see a lot of potential in Syncthing and the SQLite database. Any application that exposes its storage as a set of files that Syncthing can sync or as a SQLite file can be potentially used as a local-first application.

Though local-first is something developers have to consider in the architecture of their applications, end-users can also take control by using their desktop and mobile applications together with synchronization solutions to have a local-first experience.

Single Writer, Multiple Readers

I once attended a meeting where the participants were writing notes into an Emacs org-mode file with auto-revert-mode enabled. The file is synced with the participants using Syncthing (using relays, there was no direct connection). We allowed only person to write to the file at a time but all could see the changes updated in their respective Emacs buffers with a lag of a second or two. I would consider this a pretty good alternative to most collaborative editing tools and it puts user freedom first. People get to use the text editor that they're most comfortable in, instead of a basic web-based editor that most collaborative editing tools have. The data is always persisted to the local disk and eventually synced irrespective of network issues. In case of a network failure, a cloud-first collaborative editing tool might either block the user from writing or fail to save data depending on the implementation. This local-first system saves the data in at least the writer's computer.

Guidelines for application developers

Note: Not all guidelines might not apply to all applications. For example, the first guideline might not apply if your application is a downloader.

  1. Your application should not require a network connection for its basic operation
  2. Think hard if your application has a really good reason to use MySQL/Postgresql instead of SQLite
  3. If your application's data is a set of files (including .sqlite3 files), allow the user to choose a different folder on the system for storing the files (usually a synchronized folder).
  4. Even if your application is built in a traditional cloud-first architecture, there is still the possibility to make your clients work offline. For example, a Diaspora client might accept a user's post and wait till it connects to the network to send the message.

Examples

Here is a listing of local-first software that I already use as replacements for cloud-first software.

Cloud-first software Local-first alternative
Google Docs LibreOffice + Syncthing
Evernote Emacs org-mode/BoostNote/Joplin + Syncthing
ToDoist Emacs org-agenda, Orgzly + Syncthing
SVN git
GitHub Fossil

Resources

  1. https://www.inkandswitch.com/local-first.html
  2. http://offlinefirst.org/