17K views · Jun 18, 2024 · 29:46 · 1 HN recommender · 4 mentions · discussed 2025
Martin Kleppmann's Local-First Conf talk reviewing where the local-first idea came from, where it stands five years after the essay, and what the community should work toward. He argues for generic sync infrastructure.
Why Hacker News points people here: Cited in sync-engine and local-first threads for Kleppmann's argument for a generic, standardised sync protocol or service.
“Martin Kleppmann in his talk last year spoke [1] the need for a generic sync protocol, which was very interesting.”HN comment, 2025
“Martin Kleppmann in his talk last year spoke [1] the need for a generic sync protocol, which was very interesting.”
Kleppmann argues for a generic sync protocol
There is a proliferation of sync tools and little standardization. Here some in local-first space [0]. Martin Kleppmann in his talk last year spoke [1] the need for a generic sync protocol, which was very interesting. [0] link [1] this video
“Martin Kleppmann in one of his recent talks about the future of local-first, mentions the need for a generic sync service”
Kleppmann on need for a generic sync service for local-first
Martin Kleppmann in one of his recent talks about the future of local-first, mentions the need for a generic sync service for the 'local-first end-game' [0] as he calls it. Standardization is needed. Right now everyone and their mother is doing sync differently and building production platforms around their own protocols and mechanisms. [0] this video
“This is what local-first means”
Defines what local-first actually means
I see, I hear you. That isn't what local-first means, though. This is what local-first means: • link • this video
“He is a proponent of centralised standardised sync engines that enable the ideals of local-first.”
Kleppmann favors centralised standardised sync engines over decentralisation
> This is trying to solve a business problem (I can't trust cloud-providers) with a technical trade-off (avoid centralized architecture). I don't think that's quite correct. I think the authors fully acknowledge that the business case for local-first is not complexly solved and is a closely related problem. These issues need both a business and technical solution, and the paper proposes a set of characteristics of what a solution could look like. It's also incorrect to suggest that local-first is an argument for decentralisation - Martin Kleppmann has explicitly stated that he doesn't think decentralised tech solves these issues in a way that could become mass market. He is a proponent of centralised standardised sync engines that enable the ideals of local-first. See his talk from Local-first conf last year: this video
