Skip to content

Instantly share code, notes, and snippets.

@dlederle
Last active May 30, 2021 18:42
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dlederle/bfbcc42d3a0f9787c18b58d392ac01c8 to your computer and use it in GitHub Desktop.
Save dlederle/bfbcc42d3a0f9787c18b58d392ac01c8 to your computer and use it in GitHub Desktop.

Modern web-backed, “cloud software” has become ubiquitous, but has several fundamental usability issues that the authors believe can be solved by turning towards “local-first software”. Local-First means the software will work offline, but unlike old fashioned file-based software, LFS must support synchronizing work between collaborators. This requires LFS to implement some form of conflict resolution. This is a vision paper, proposing a new area of study, but they describe several working prototypes of the idea including a pixel art editor and a Trello clone.

Cloud software allows its users to collaborate in real time, access their data across all their devices, and takes backup out of the user’s hands. This feature set, particularly collaboration, is so important that it has led to the rapid adoption of cloud software. However, there are some significant drawbacks. By introducing the network cloud software is slower than local software. It also won’t work without a stable internet connection. The data lives on the cloud provider’s server, not the user’s hard drive. If the service goes down, or changes, users can lose access to their data. The author’s propose seven principles for LFS that combine the collaborative benefits of cloud software, while returning to the speed, data locality, and privacy of good old fashioned local software.

  1. Fast: LFS must not rely on networked computers: “no spinners”. User changes should happen immediately.

  2. Multi-Device: LFS must be able to easily share data across all of a user’s devices.

  3. Offline: LFS must not require an Internet connection. Some network is required to /sync/ changes, but the software should be operable without syncing.

  4. Collaborative: LFS should support fine-grained, soft realtime collaboration between multiple users.

  5. Longevity: LFS should continue to operate so long as the user has a computer that can run it. A server shutting down should not “brick” the software.

  6. Privacy: A user’s local data should not be shared with anyone else unless they choose to do so.

  7. User Control: Also described as “data ownership”, a user’s LFS data should belong to them to modify, delete, or store as long as they wish.

The authors survey a number of existing software systems and evaluate them along these seven principles. They find all of them lacking on one or more axes. The closest existing system is the combination of git and GitHub (or other remote repository).

The fundamental tech underlying LFS is the CRDT, or Conflict-Free Replicated Data Type. CRDTs are a class of data structure that are multi-user by default and automatically resolve conflicting modifications. This means that multiple users can manipulate the same data structure and can synchronize each other’s changes. Each device has its own copy of the data and changes are synchronized over the network, but no copy is privileged over others. CRDTs have been used in distributed systems, but primarily for server to server replication. The authors’ application of CRDTs as a client-side technology is novel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment