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.

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

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

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

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.

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?

https://github.com/JoshTheDerf/uapp

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

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

> 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?

But there is something compelling in the idea - there is need for an interactive smart document format that you can share around easily. Kind of like a next gen markdown derivative cross with jupyter notebook where you bundle data, live parametric visualizations, code, audio, video, asciicinema like playback, comments, metadata, file artifacts etc

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

Isn't html/css a better distribution mechanism as most computers already have the tech to run them?

How would I know if I need this, vs something else?

But I'm missing a few relevant features:

1. syncing data and apps (capsules) between my devices. not necessarily over a single SaaS, but maybe p2p or some existing service

2. I think data and apps should be separated, I might want to share an app with someone else without sharing the data

3. Apps should support updates, install the same app again and just replace the code for the existing app, but keep the data. Also share updates either as a file or publish apps to a repo (just a folder of files on a public http server or github repo)

Both keeping data in sync between devices and providing offline capabilities is hard, I know.

I confirmed that external REST APIs work from Capsule via fetch(). I’d like to use Capsule as a lightweight/offline client for Claris FileMaker Server, but FileMaker Data API does not support CORS or OPTIONS preflight requests, so a direct request currently fails with TypeError: Load failed.

Would you consider providing a native HTTP API through the Capsule/Tauri host, e.g. capsule.http.request()?

That would allow:

Capsule → Native HTTP → FileMaker Data API

without requiring a separate proxy server, while still allowing Capsule to control network access through its permission system.

I think this would be useful beyond FileMaker too — for internal/legacy REST APIs, NAS devices, IoT devices, and other local-network APIs without browser-compatible CORS support.

The idea of a self-contained Capsule app that works offline, stores data locally, and syncs directly with an existing business system when online is especially interesting to me.

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.

I'm having Lotus Notes flashbacks.

solves the storage issue

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?

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

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.

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...

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"

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.

But I'd want to see some kind of clouds storage sync to actually use it for anything practical.

Maybe it could include YJS, with agents taught to use it, and save/load them to Google Docs?

This reminds me of Clipper/dBase software tools. One of my favorite pieces of software was a tiny program file + flat-file .dbf for storage. Drag and drop the folder to install or share.

You're gonna end up having to build a complex state sync system to a central DB anyways...

What I would want to see is a version of this that lets me write an app that can write to the DB through an API, and then have a google drive-esque "host this for me" thing.

A focus on local-first really misses the point IMO. Like sure it's good it can be run locally, but really most people have a distribution problem. Be a distribution solution!

The thing I would do involves having the hosting just be available by dropping the capsule into the google drive/dropbox-y thing, and then having it be that you can just copy/paste the file to someone _and it carries over the data and everything by default_.

For a lot of people the "thing" is the app + the data. Sometimes you want to decouple them but a lot of times you don't want to.

I think it would be very rare for someone to want to share the single-file bundle just without data.

Another way to achieve something like this is Cosmopolitan C Compiler, Actually Portable Executables. For example, Redbean. (Jart, all of your certs are bad! I can't open your websites any more!) http://justine.lol/

It's a binary that can run on Windows, Mac, Linux, and it is also a zip file. The application can read the zip file and on several systems (not Windows), it can self-modify the zip file. Including hosting SQLite inside the ZIP file.

I'm so tired of AI everywhere and everything trying to sell to you because of AI this and AI that.

I think that at this point we assume AI will be available if it makes sense for the product, making it a selling point to me is like slapping "No cholesterol!" on lettuce.