DE version is available. Content is displayed in original English for accuracy.
I always had the problem that building HTML pages is really simple now, but trying to save data required hosting it somewhere, and sharing it afterwards was not easy. Over the last few months, I've been building an app called Capsule (it’s also the file extension name) written in Rust with Tauri 2.0 that allows packing an HTML app and its data into a single SQLite file.
The HTML file and any related assets are directly embedded in the database. User data can either be saved as a localStorage key/value store or via a MongoDB-inspired collections API as documents, saved in a table in the file. You can also save other assets, like PDF files or images, directly in the database to keep different documents together. All data can be easily exported to CSV or JSON if needed.
Privacy and security were a big priority for me, so documents cannot do anything out of the box. They don’t have direct access to the file system and they require permission to access the internet. The permission model is still something I’m working to improve. Capsule documents can also use local or remote AI models for document specific AI features.
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.
I’m planning to open up the file format specification for the 1.0 version of the app so other apps can read or write Capsule files.
You can try it out in the web preview at https://withcapsule.app/preview with pre-built templates or use any AI provider of your choice to create a custom, Capsule-optimized app by using the following prompt:
"Please read the app wizard instructions at https://withcapsule.app/prompt.txt and help me design an app.“
I’m still working on the file format but there are migrations for each new version, so data should never be lost when using newer versions of the app in the future. Please let me know if you have any ideas or use cases where this might make sense or does not work.

Discussion (84 Comments)Read Original on HackerNews
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.
The File System Access API makes it possible.
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.
Bonus points for an intelligent way to manage these stored in OneDrive and other cloud folders. Easy to get corruption on SQLite files stored there.
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?
Concurrent editing wouldn't work, though.
You’re glossing over the recurring cost and annoyance of dealing with the hosting and having to secure the data. This way you just share and it’s local.
Sure, if you have to share data between people, your points are valid. But this seems like a way to build apps geared for individual users, like a notes or recipes app.
https://github.com/JoshTheDerf/uapp
Demo apps and games: https://thederf.com/uapp/demo/
Really curious to see where this goes. Do you plan to open-source the client, or simply make the file specification open when stabilized?
I always thought that there should be an easy way to export it, but I don't think that ever materialized.
[1] https://en.wikipedia.org/wiki/Web_SQL_Database
https://developer.mozilla.org/en-US/docs/Web/API/File_System...
That feels like a big barrier, almost like a Java runtime.
I prefer worse UX for the sake of standards and zero install, but many people would prefer the opposite. I don't think Capsule is intended for the HN crowd.
Isn't html/css a better distribution mechanism as most computers already have the tech to run them?
Hence 200MB applications that are complete copies of the Chromium browser to run under 1MB of actual web code.
I've experienced the same limits building small tools for myself and friends that I wanted to contain in a single HTML file without external dependencies... but I understand why the same project without these restrictions could easily become malware, and ones that could be easily propagated.
1: https://en.wikipedia.org/wiki/TiddlyWiki
However, every browser will let you download a new version of the HTML file and save it over the old one - yes, even from a local HTML file:
... but you need the user to do this for every update. So we're back to manual "Save" buttons.Im finding a lot of success embedding metadata and data in SQLite files for music management.
Having a spec for a single file with a schema, version, metadata and binary blobs is super easy to shuffle around.
Agents crush reading and writing the data and writing tools around the spec.
All of a sudden things like backup, sharing and dedupe are snapping into place for my music library.
More thoughts here: https://deadca7.com/blog/deadca7-open-music-database-specifi...
> 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?
I don't know about the stability/market value of this if you intend to turn this into something that attempts to make money, however. Said friend is currently using stuff like Gemini to generate HTML mini-apps as well; while he's not storing anything in databases, he's able to generate receipts and other things for essentially free.
The whole shift to SaaS has decimated software quality and has made most tasks a nightmare to complete (or at best, an obstacle course of multiple tools and "upgrades" and other bs).
Do you have any plans to do merging of two versions of the same app? E.g. I send a todo list to someone, they mark some things as done and send it back to me. Will that merge into my copy if I've added some more items or would it open as a "fresh" app?
How would I know if I need this, vs something else?
I'm having Lotus Notes flashbacks.
https://pocketbase.io/docs/
"PocketBase is an open source backend consisting of embedded database (SQLite) with realtime subscriptions, builtin auth management, convenient dashboard UI and simple REST-ish API. It can be used both as Go framework and as standalone application.
The easiest way to get started is to download the prebuilt minimal PocketBase executable"
You're gonna end up having to build a complex state sync system to a central DB anyways...
>Keeping the data schemaless makes it also easier for merging data or importing data from a CSV.
Not sure how it makes easier. There is always an implicit or explicit schema. IMHO explicit is often better.