The best sync engine you don't manage runs in one Chromium-only browser
Steve Harrison hands a web page an ongoing read/write handle to a folder on your disk and builds a Lightroom-style photo manager that never leaves the browser. Mozilla and Apple have both formally vowed never to ship the API that makes it work.
His demos, built with Claude, include a markdown notes app and a node-based video compositor, all editing real local files in-page. The trick is window.showDirectoryPicker(), which lets the user's own cloud-synced folder become the sync layer. The catch the post skips: all three editors of the draft spec are Google engineers, and Jake Archibald showed up to debunk the demo's scariest fear.
Steve Harrison argues that Chrome's File System Access API, specifically window.showDirectoryPicker(), is the missing piece for local-first web apps, because it gives a page an ongoing read/write handle to a directory the user picks.
When the sync engine is just your own folder
The argument turns on a line: "the best sync engine is one you don't even manage." Point the page at a cloud-synced folder and the OS handles sync for free. To prove it, Harrison ships AI-built proofs of concept (made with Claude): a markdown note app, a Lightroom-style photo manager, and a node-based video compositor, all operating on local files in-browser. The post leans hard on user-consent framing. It does not deeply engage the security model, and it skips that the API is Chromium-only (about 75% of users per caniuse), with Mozilla and Apple both formally opposed.
The standards fight the post left out
A PWA developer hit by the gap supplied the context the article omits:
"Unfortunately Mozilla and Apple say they are never going to implement it because of security concerns… It is a great API though… currently us PWA developers are really limited when trying to make apps that work with local data, at least in non-Chrome browsers." — a PWA developer blocked by the cross-browser gap
Another reader pulled the receipts on who wrote the spec:
"it's a bit of a shame that TFA does not mention that this is a non-standard API pushed by google only (all three editors of the draft are google engineers)… actively harms the web and sends a signal to google that they can in fact keep doing this" — a commenter citing the standards-position records
The thread's loudest fear, that a site could recursively read your whole disk, got a live demo in rebuttal:
"No, Chrome doesn't allow this. Here's a simple demo… you can't select root, Downloads etc." — Jake Archibald, a Chrome and web-platform developer
And a security veteran inverted the usual web-app slander:
"I have actually come around to deciding the web API is the most user-forward API that closed-source software can target… web API software is distributed as plaintext to be interpreted by software under user's control, the browser." — a former Wine hacker at CodeWeavers who works in security
The tension in the thread is that the API is genuinely good and genuinely the product of one vendor doing what the others refuse to, which means every "whole new world" built on it is also a quiet vote for a single-browser web.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
LLMs don't read role tags, they guess your role from writing style
Researchers built linear probes that score the "CoTness" of any text, then forged fake reasoning into a prompt that told the model its request was "approved." Asking how to synthesize cocaine went from near-zero success to about 60%.