Local-first is a new movement that focuses on apps that:
- Store user data primarily on the client side and automatically sync them across devices
- Increasing user privacy, decreasing attack surface (rogue employee, data breach)
- Work offline-first:
- Decreasing reliance on costly and sometimes unavailable third-party servers, defeating vendor lock-in and increasing user freedom, especially the freedom of connecting their identifier to an ecosystem of apps, and then choosing which data to selectively disclose to them
- Increasing interoperability with the decentralised web, with blockchains, and with peer-to-peer interactions, while still being compatible with client-server interactions
To achieve this purpose, the local-first movement relies on the following technologies:
- Local-first authentication based on asymmetric cryptography, and local-first authorization based on capabilities instead of access-control lists. Notable examples:
- UCAN, which is used by Bluesky for server-server communications
@localfirst/auth, which signature chain is inspired by the Keybase implementation
- CRDT (conflict-free replicated data type) for resolving conflicts with other devices' data once the device goes back online
- End-to-end encryption to preserve privacy and provide private communications, only using servers as proxies
- Enable users to configure their own data sources directly from the frontend, whichever the source is (IPFS, NAT server, cloud services, etc.)
Advantages
- Down-to-earth movement that acknowledges that the vast majority of users own powerful cell phones that can host many of their valuable data, preserving their privacy.
- Flexible, protocol-free authentication and data ownership mechanisms. Variety of data sources, variety of targeted architectures.
- (Very) cheap to scale for certain kinds of apps
- Killer approach for collaborative apps
Limitations
- New, immature. Most notably, local-first databases are still a work in progress.
- CRDT is hard to comprehend.
- Browser storage behaves differently across OS and vendors. For example, on iOS, it can be wiped out arbitrarily after a certain amount of time. Web Apps may require PWA capabilities that aren’t always supported or accepted by users.
- Not adapted to every kind of app. For example:
- Syncing a large volume of data across a large number of users without a centralised server will cause performance issues.
- Apps focused on compute-intensive algorithms are not suitable for local-first, especially when the computation needs to be applied to data owned by a large number of different users. (IPVM tries to solve that, but it is still in its infancy.)
- Large datasets may not fit in devices’ local storage.
- Maintenance is more challenging because devs have to update the local database of each and every device (not to mention service workers or native code).
Could it be useful for our requirements?
Our application does not focus on privacy as in encryption, and it is not a collaborative app, so this aspect of local-first isn’t very useful for our project.
The verifiability, flexibility, and interoperability of the local-first authentication approach, however, is highly relevant to our requirements.
