[raelmiu]

Love this.

What are computers for?

Local first could be the file format that allows us to use devices without cloud services. Back to file first, vendors of software apps, pay for software once (or one year of updates or whatever).

It's s new horizon.

[rollcat]

I would still prefer to have my stuff synced between devices. Files are OK for data that doesn't change much (your music/photo/book library) - Syncthing works great there.

CRDTs allow for conflict-free edits where raw files start falling short (calendars, TODOs, etc). I'd love to see something like Syncthing for CRDTs, so that local-first can take the next logical step forward and go cloud-free.

[WorldMaker]

The other day I was riffing on ideas on what if Browsers had a third Storage called `roamingStorage`. Keep it the simple, stupid key/value store interface of localStorage and sessionStorage, but allow it to roam between your devices (like classic Windows %RoamingAppData% on a network/domain configured for it). It doesn't even "need" a full sync engine like CRDTs at the browser level, if it did something as simple and dumb as basic MVCC "last write wins, but you can pull previous versions" you can easily build CRDT library support on top of it.

The hardest trick to that would be securing it, in particular how you define an application boundary so that the same application has the same roamingStorage but bad actor applications can't spoof your app and exfiltrate data from it. My riffing hasn't found an easy/simple/dumb solution for that (if you want offline apps you maybe can't just rely on website URL as localStorage mostly does today, and that's maybe before you get into confusion about multiple users in the same browser instance using the app), but I assume it's a solvable problem if there was interest in it at the browser level.

[satvikpendem]

Local first access control via cryptography: https://www.inkandswitch.com/beehive/notebook/

[rollcat]

Look up CloudKit[1], many of these questions have been answered for Apple-native apps, but perhaps it's not obvious how to translate that to the web-world, or how to keep the object storage decentralised (but self-hosted shouldn't be a problem).

I'm also firmly in the native app camp. And again, Apple did this right. The web interface to iCloud works great from both Firefox and Chromium, even on OpenBSD, even with E2EE enabled (you have to authorise the session from an Apple device you own, but that's actually a great way to protect it and I don't mind the extra step).

It's probably harder to answer those questions if you can't build the solution around a device with a secure element. But there's a lot of food for thought here.

[1]: https://developer.apple.com/documentation/cloudkit/

[WorldMaker]

> I'm also firmly in the native app camp.

Then you are answering the wrong question. I want a "web native" answer and proposed a simple modification of existing Web APIs. As a mixed iOS/Windows/Linux user, I have selfish reasons to want a cross-device solution that works at the Firefox standardized level. Even outside of the selfish reason, the kinds of "apps" I've been building that could use simple device-to-device sync have just as many or sometimes more Android users than Apple device users. I've also seen some interesting mixes there too among my users (Android phone, iPadOS device, Windows device; all Chrome browser ecosystem though).

> It's probably harder to answer those questions if you can't build the solution around a device with a secure element.

Raw Passkey support rates are really high. Even Windows 10 devices stuck on Windows 10 because no TPM 2.0 still often have reasonably secure TPM 1.0 hardware.

Piggybacking on Passkey roaming standards may be a possibility here, though mixed ecosystem users will need ways to "merge" Passkey-based roaming for the same reasons they need ways to register multiple Passkeys to an app. (I need at least two keys, sometimes three, for my collection of devices today/cross-ecosystem needs, again selfishly at least.)

[rollcat]

> Then you are answering the wrong question. I want a "web native" answer and proposed a simple modification of existing Web APIs.

I don't see why this mechanism shouldn't be available both on the web and in native apps. The libraries would just implement the same protocol spec, use equivalent APIs. Just like with WebRTC, RSS, iCal, etc. And again, ideally with P2P capability.

> [...] that works at the Firefox standardized level.

What about a W3C standard? Chrome hijacked the process by implementing whatever-the-hell they like and forcing it upon Firefox & Safari through sheer market share. It would be good to reinforce the idea that vendor-specific "standards" are a no-no.

It also just doesn't work the other way: Firefox tried the same thing with DNT, nobody respected it.

> Piggybacking on Passkey roaming standards may be a possibility here [...]

WebAuthn sounds good, that kinda covers the TPM/SEP requirement. Native apps already normalised using webviews for auth. I wonder if there's a reasonable way to cover headless devices as well, but self-hosted/P2P apps like Syncthing also usually have a web UI.

> [...] again selfishly at least.

No problem with being "selfish". Every solution should start with answering a need.