LocalFirst: Difference between revisions

From Wiki
(Correct typo)
(Add more examples)
Line 15: Line 15:
| Google Docs || LibreOffice + Syncthing
| Google Docs || LibreOffice + Syncthing
|-
|-
| Evernote || Emacs org-mode + Syncthing
| Evernote || Emacs org-mode/BoostNote/Joplin  + Syncthing
|-
|-
| ToDoist || Emacs org-agenda, Orgzly + Syncthing
| ToDoist || Emacs org-agenda, Orgzly + Syncthing
|-
| SVN || git
|-
| GitHub || Fossil
|-
| Facebook/Diaspora || [[ SSB ]]
|}
|}



Revision as of 13:41, 16 December 2019

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.

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
Facebook/Diaspora SSB

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).