For the curious, the note taking app Trilium has a "standalone" mode¹, built on top of OPFS² and sqlite OPFS persistence, such that your notes (~web pages here) are stored in sqlite locally, offline-available, optionally syncing with a remote, while being a pure local web app (after the app assets have been downloaded once). If you want to take your whole personal notes/wiki/pkms for offline access on a device you don't own/have install rights, that's the only way I know. I suspect that OP could have gone this route instead had he known about it?

¹: https://app.triliumnotes.org/

²: https://developer.mozilla.org/en-US/docs/Web/API/File_System...

³: https://sqlite.org/wasm/doc/trunk/persistence.md#opfs

> but trying to save data required hosting it somewhere

With the File System Access API, webpages nowadays can read and write local files just like desktop applications:

https://developer.chrome.com/docs/capabilities/web-apis/file...

Try this text editor for example:

https://googlechromelabs.github.io/text-editor/

It works nicely on Desktop and Mobile.

I was literally thinking of building something similar this summer, one requirement I had however was that it should be runnable/shareable over the web (it's web-tech after all).

My use case was storing a family tree with data/app that could be shared, and family members they would be able to add to it and later merge also.

Ie, it's a webpage you can dump anywhere, then download/edit locally.

I don't know, this seems like an idea that maybe works in a specific context being generalized past the point of the original idea making sense.

If the user needs to download a specific application to run this these web apps, then why not just send them that initial application in the first place? Why jump through the hoops of using Capsule when the same hoops can be jumped through to get to the same endpoint?

If this was a near-universally adopted application, then it'd make sense. But it's not, and the closest thing we have to that are browsers... which already do what you're describing?

Bundling data with the application makes sense, but is also only appropriate in pretty narrow circumstances. If I'm willing to ship my data with the web app, then I'll just embed the data in the HTML file. If the expectation is that the user will modify this data, then I don't think I'd want to ship it like this.

My take: If your app needs to update and preserve state (using SQLite or any other DB), it is probably not something you want to pass around as a bundled file.

Or at least, it's extremely limiting, compared with hosting it somewhere on the web, which is not that hard to do these days.

Think of the workflow: Any time the state changes, you need to email a new Capsule file to whoever else is using the app. And one would think the state would change at least occasionally, because otherwise there's little reason to use a DB.

Alternatively, you can just host it on the web, the DB state dynamically updates, and it's automatically available to anyone with app access. Isn't that a lot simpler?

I've been working on this exact idea, with sqlar as the "format specification". Works in the browser, and desktop + Android using Tauri.

https://github.com/JoshTheDerf/uapp

Demo apps and games: https://thederf.com/uapp/demo/

You can get a cheap approximation of this with chromium browsers + Filesystem API and a PWA manifest for that native-ish feel. AI has reignited my interest in building based 100% on browser native features.

https://developer.mozilla.org/en-US/docs/Web/API/File_System...

I miss from the home page a link to github and/or a description of it's license and/or some code of an actual capsule app (what backend language is used? -- I have no clue and cannot find out) and/or does this bundle Node?

While I wish your project success and like the simplicity of Sqlite; I prefer to start with Postgres. PG has many of the benefits (x-platform, free, embeddable, etc) that sqlite has, but also provides an industrial strength db in case you need to scale at some point, or want to use more complicated constructs.

I love this idea! One of the fallouts from widespread AI adoption that I've seen: They're very good at creating visual artifacts, but if you ever have to provide data in those artifacts, you don't really have a great way to share it without hard coding it.

> One downside with this approach is that multiple people working on it will create different copies. To make it possible to merge different copies of the same file, each data entry has a unique UUID and timestamp.

This was the first thing that popped up in my mind: Changes stemming from two sources and reconciling them. I see that you have a statement about how to handle data entry from different sources, but I don't see exactly how those are reconciled? For instance, if two users have a copy of the .capsule and make changes, then want to share their changes with the other, you have two individual .capsules with different data.

How do you merge them?

It kinda reminds me of MS Access, which ended up being a pain in the butt for IT departments, but also covered a need within some department with limited resources.

Really curious to see where this goes. Do you plan to open-source the client, or simply make the file specification open when stabilized?