This is not a systems issue this is a UI issue, the state status needs to be communicated to the user. It is ridiculous to retrofit locally first to a app that pretends to the user that it is always online.

Social media could allow you to make posts as a "draft" and automatically send it when you have a connection think of a email outbox. Or even give you a notification if after syncing with the master and it turns out the comment you replied to changed.

If you look at the web a lot of older (fundamental)protocols and applications have local-first build in. Often the design requirements required communication over a connection that is not as available. A few I can think of of HTTP, EMAIL, FINGER, GOPHER, FIDONET, NEWGROUP and more. A shared state is managed for a lot of different domains (code, gaming, chat, message boards) so I feel like it is already quite a solved problem, but there is no one size fits all solution. IMHO that's the sane thing to do for a networked application as you can never grantee that either party is available, and you want to still serve your user the best you can.

It can also have huge benefits for the data provider, especially at scale. - You can lower your bandwidth required drastically. - You can keep a consistent state for your user. - If you are evil you can send a lot more telemetry data or valuable (harvested) data instead.

the LWW is only really useful if you have a value where you can discard the previous updates for the latest, it's a bit like using UDP instead of TCP for communicating your position in a multiplayer game. Or if you don't mind forcing your user to resubmit.