So, except for #3, exactly like classic desktop apps that store data in local files. (#3 used to be called "peer-to-peer networking").
The modern equivalent of classic desktop apps (not that they've gone away) are mobile app stores. Mobile apps are installed and run locally on a phone, even though a key part in their business model is that most frequently sync back data to their server-side.
What's technically different between these and "local-first"? Nothing.
In #4, there's only an implied contract (not even explicit) that the local-first will be not doing "bad" things (like connecting server-side and then sending data there without user permission.) There's no technical limitation that keeps the app from doing that, though.
In other words, "local-first" seems to be a somewhat meaningless buzzword or critique about a business model, not a technical design.
When comparing desktop apps to web apps, we often forget that web apps came to dominate because they have a massive advantage when it comes to distribution.
It's much easier to go to a URL than to download and install software, not to mention the process of maintaining the upgrade versions. With web apps, there are no dialog boxes that interrupt you when you're firing up the app to get stuff done.
So while it's not mentioned in the local-first software manifesto, I'd add that we'd want to retain the property of easy distribution of web apps, and it's not just sync between clients.
This isn't about desktop vs web apps. Plenty of desktop apps (or mobile apps) use a centrally located database server side.
So, #3 (synchronize between clients) is about merging data using CRDTs in a distributed manner without requiring a centrally located database.
A better way to think about it is Google Docs (as a desktop app or web app really doesn't matter), and it offers real-time collaboration on a single doc between users without using a centrally located database.
1. data co-located with its UI
2. works offline
3. synchronizes between clients
4. lets its users own their data
So, except for #3, exactly like classic desktop apps that store data in local files. (#3 used to be called "peer-to-peer networking").
The modern equivalent of classic desktop apps (not that they've gone away) are mobile app stores. Mobile apps are installed and run locally on a phone, even though a key part in their business model is that most frequently sync back data to their server-side.
What's technically different between these and "local-first"? Nothing.
In #4, there's only an implied contract (not even explicit) that the local-first will be not doing "bad" things (like connecting server-side and then sending data there without user permission.) There's no technical limitation that keeps the app from doing that, though.
In other words, "local-first" seems to be a somewhat meaningless buzzword or critique about a business model, not a technical design.