Wavacity – a FOSS port of Audacity to the web

You know how everyone complains about Flatpak sandboxing until they learn about portals and Bubblewrap because the programs are isolated from the rest of their disk? The web is like that, except without portals and Bubblewrap. You can save stuff and drag files in, but you can't really integrate a webapp with a user's local filesystem -- and it's very hard to keep all of a webapp's data in a user-inspectable format that's easy to transform, open up with native apps, or transfer across browsers or websites.

Now, the problem is that persistent read/write access to user-defined folders is wildly dangerous. And Google's proposal is... not the worst thing in the world? But it's suboptimal and it's a missed opportunity to build something far better, and I kind of understand why Mozilla considers it harmful.

Getting this wrong would have permanent implications for the web. Mozilla is absolutely right to be cautious. However, it's also really holding the web back and in particular holding back PWAs because the only really reliable way as a developer to store data via the web is to sync it to an online account. As a result offline webapps are very limited; you never really trust the storage.

It's an extremely dangerous feature that we really need, but it's not clear who should champion it and I don't really trust Google to be heavily involved in the spec process, let alone to be the people writing the first draft. I don't think Google is good at building nuanced web specs even when there's no conflict of interest at all (see the web audio API, HTML templates, etc...). A lot of Google specs end up being very weird and they end up having strange quirks and very strange limitations that don't need to exist? They're very often kind of orthogonal to what the community needs. I don't know if the problem is that Google doesn't think enough about the spec or that they think too much and over-complicate things, but for low-level important features I prefer other browser-makers to lead the way.

What would be best is if a team with more earned trust picked up the spec and went over it again trying to better address the dangers and trying to make something that better addressed everyone's needs in a cleaner way, but there are not a ton of stakeholders on the web that I trust to do that. As it stands the proposal is... ok-ish? But needs a lot more discussion and could be better. I don't blame anyone for being hesitant about it; the potential for abuse is so unbelievably high.

But... it is a serious limitation that I can't ask for persistent read/write access to a folder from an offline webapp.

Which is kinda what I thought. This isn't about your upthread point about Fugu. You're doing a platform advocacy thing, which I'm not interested in. I jumped in to point out that it's simply not true that Fugu is poorly supported in ChromeOS, because it's not. I'm not trying to have a fight about platforms.

As a result there are a number of web-apps that could be entirely account-free and offline that aren't. It also makes it a lot harder for users to move and transform data, although maybe that's less of a consideration nowadays since mobile has kind of standardized data silos even for native apps that would have previously had portable databases or worked directly with files.

Not saying you should want it, I completely understand and am completely sympathetic to anyone who says "the benefits don't outweigh the risks." That is a fine position for someone to take. That being said, this isn't just about trying to make the web more powerful, it's also in a lot of ways about fixing long-time deficiencies in the web that have made it less private and that forcibly shift the majority of even well-intentioned web software into a user-hostile SaaS model. When every webapp is a SaaS business with web accounts, that decreases hobby development in favor of corporate development and encourages users to spread their data in (imo) irresponsible ways.

Because that seems to me to be a very awesome use-case ..