It's not using the File System Access API, on Firefox it uses <input type="file"> for file-picking, and the save just downloads it. It's not synchronizing anything with your filesystem.
Firefox unfortunately does not support the File System Access API. You can try by calling the most fundamental function, the one that asks the user to select a file:
window.showOpenFilePicker()
What Firefox supports is a "File System API" which creates something similar to the other old ways of storing data in a browser, like cookies and indexeddb. You cannot use it to edit normal files on your disk.
This is my main gripe with Firefox. They force their users to either store everything in the cloud or go through the arcane "download" workflow where you have to manually save files.
> Firefox unfortunately does not support the File System Access API.
I would not call it unfortunate. Browsers should not have access to the file system, USB ports, etc. Perhaps in "PWA"s, if the user has a way of giving and withdrawing consent.
Why is that true? Some applications require file system access. People would grant the application the permission to access files like any other resource like camera, mic, location.
Because vulnerabilities, coarse access granularity and lazy or ill-informed users. E.g., you now grant cam access per domain. Changing functionality on that domain doesn't revoke permission, so a simple bait and switch is already possible. Now imagine granting access to your file system to some Microsoft domain and finding out that there was a change of heart and some new script has uploaded your files to OneDrive and deleted them from your disk.
Taking that logic of protecting users from themselves to the extreme, a website should not be able to display text either. Because it can use text to ask the user to open their explorer and delete the files manually.
I think the flow of Chrome where the user has to select a file from disk and then acknowledge a prompt that the site will have access to that file until they close the window is fine. But if Mozilla wanted to protect users from themselves even more, they could make it as strong as they like. For example, by requiring to turn the functionality on in about:config.
Not giving the user the choice at all, if they want a cloud only browser or a browser that lets them work with local files is the wrong way.
Iirc the File System Access API should always originate File objects from an input picker so that the user selects the file to be opened and not give more access to apps than users allows?
I believe you are able to connect to a Google Drive account with a purely client side site via google oauth and then using the Google Drive rest api. There was an article in particular that I liked that walked through it. Let me see if I can find it
Yes but Google OAuth is a nightmare if you want to "publish" your client so that anyone can use it. If only you use it, you can add yourself as a test user. Just know your access token expires super fast and you will have to frequently re-auth. Its crazy annoying.
Ease of backup too. One of the issues I take with browsers allowing web apps to save data locally is that they don’t also expose a way to easily locate the data in the filesystem or export it, and to my knowledge on-disk format isn’t standardized and so portability between browsers is also a concern.
The effect of this is that unless the user uses migration assistants or similar when upgrading to a new computer is that they’ll lose all local web app data. To me to this feels like a serious problem but when it’s brought up it tends to be hand waved away.
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?
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.
Not a bad thing, but it's just another dependency and tied to an OS-specific base software install.
They could work well pre-installed on the Mecha Comet with a bunch of app files ready to launch.
Can the added layers guarantee a new level of security or privacy like zero telemetry or keyjacking? Protection from bad actors is a good thing while making things faster and easier overall. Browser extensions are a security risk, right?
Java applets were a good idea in the sense that so long as you had Java installed, the applet was just sitting there on a webpage. Finding and managing the apps is the problem, and using browser bookmarks is a decent solution to it. The web page should demo the app, and there can be an 'install local' button next to it. But at some point all these local versions need to be updated and then not be messed with like browser extensions can be. FanFare would be a decent name.
Seems pretty useful in an enterprise context to me. I see it as an alternative to 10 million vibe coded apps to dockerize and manage. You can put the runtime on everyone’s machine and provide a web version for really collaborative stuff.
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.
It could be useful for us with home labs for the same reasons. Kind of annoying to deploy docker containers for all the services I build that amount to personalized/skinned trello boards.
Not trying to plug myself, but I’ve been working on a similar project for this exact reason. It doesn’t use special file types. Just HTML and localStorage proxies to sync devices.
It’s self-hostable too. I’ve got a bunch of super niche todo lists and personal apps running on my home server with it.
There are a few things in Capsule to avoid corruptions of the file during syncing. The DELETE journal mode is used and writes are batched into transactions so that updates are always complete changes. And if there is a copy created because of a conflict merging two capsule files is supported.
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?
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.
For most users having to mail a file to someone is way more work than having to just share a link. The cost of cloud storage is almost nothing (since email is mentioned I assume 50MB max per project). A notes app that don't sync between all devices is just a text editor to most.
I do like apps that have sensible export formats though. Having control over my data is important.
> For most users having to mail a file to someone is way more work than having to just share a link.
Citation very much needed. Sharing a link, especially if you’re already at your computer where the app runs, very often means emailing the link.
> The cost of cloud storage is almost nothing
“Almost nothing” is not nothing. I really wished we stopped with this idea of “I can afford it, so everyone can too”. And you’re summarily ignoring the very important point of the annoyance (especially for someone inexperienced) and security aspects, which are huge.
> A notes app that don't sync between all devices is just a text editor to most.
Maybe for you. I recommend you observe more regular people.
Also, that is a single example, not representative of the whole.
Or the copies can go their own way. I could send someone an itinerary and they could change the dates or drop half the stops and add their own notes without needing to send an updated copy. Getting them to install another app just to open it might be a problem, especially if they only want to use it once.
In a corporate context it's basically impossible for employees to host an app anywhere. So an app that works entirely locally and you can send to colleagues sounds useful.
theres still lots of programs where local is the main user. but as time goes on the user may want to portably move it just by emailing the file itself.
i made like a very light clone of notepad++ using it for my macbook.
as a side note: i think they missed an opportunity to call it .pdfv rather than .capsule
Beyond "not working", concurrent editing is likely to silently lose data, or corrupt data, or possibly just fill up your drive with lots of "conflicted copies" that you have to manually reconcile.
When I read about this project, it doesn’t seem like concurrency is much of a concern. I think it’s _supposed_ to be treated like sharing a document with someone else.
If a capsule is a recipe, like in one of the examples, that’s pretty cool. If a capsule is a recipe _manager_, then I think it would get messy.
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.
If you want to distribute apps to many users this would probably be a better solution. The main benefit of Capsule is the personal document like app. You create a capsule, move it to an USB stick, save it in your cloud storage and it's still the same document. Nothing has changed, not the UI, not the data. The document will stay the same.
If it’s web native, anyone can just use it. If it’s a capsule, they first need to download the capsule app to associate the file extension with the OS and have it launch, right?
That feels like a big barrier, almost like a Java runtime.
In defense of capsule, the Filesystem API is janky and has kind of shit UX. Less sophisticated users would probably prefer the UX of a purpose built tool.
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.
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.
Each document record is saved with UUID and timestamps. When deleting a record the data is removed but the record keeps a tombstone so only the ID remains. For conflicts currently the newest one is used, but there will be a merge like UI in the future to confirm which one to use.
This would be great if it evolved in a universal format/spec/feature supported by all major browsers.
Only then you'd have to deal with cross web engine compatibilities. And if capsules need to do something non-trivial then you need to consider all the security aspects of having system, file or network level access. Just like any executable.
Otherwise with custom app to run capsules it feels like something that can be vibe coded with electron/nw.js rather easily.
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
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?
I'm currently 50/50 on open source the full app vs just the spec. Since I'm currently having a strong idea of what features and functionality is still missing I feel that open-sourcing right now would distract to much in this phase. But maybe when the main features are done it would make sense to have more people looking at and improving it.
An idea for a killer feature:
Make it so that auhors can expose their capsules to the internet, and the people whoe wants to use them(lets call them users) can type the name(lets call it address) of the caplsue into the app, and your program will pull that capsule in the the users device..
This is great. Curious: this requires users to have a host app installed on their machine that can read .capsule file right? Won't that be a point of friction for distribution?
Isn't html/css a better distribution mechanism as most computers already have the tech to run them?
You'd think so, but web browsers are downright lobotomizing the ability for local HTML files to run any meaningful javascript code. Want to run a JS file from the same directory? CORS ERROR!!!!
Hence 200MB applications that are complete copies of the Chromium browser to run under 1MB of actual web code.
couldn't you just embed the js directly into the html file though? that would sidestep the CORS error. and since most of the people using a program like this are likely to be using AI to generate their ( likely throwaway ) applets anyway, readability and maintainability for the source doesn't matter as much as it would with human authors so having a separate js file doesn't bring that many advantages anyway.
Sharing HTML files with embedded Javascript is problematic: iOS users can't open the files directly, and have to save the file and then 'open with ... '.
Isn't that the price of a relatively well sandboxed experience by browsers?
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.
I wish the browser would either allow local-only or internet-only, then only make up its mind after the first attempted request. Fetch an image from the internet? No script access for local files. Fetch a JS from elsewhere on the hard drive? No internet access. That could provide the sandbox while still being flexible.
The problem is that you can't save the user data in way that you can click a single file, similar to a Word or Excel file. I you think a about it, a Excel spreadsheet is also just UI + data in a single file.
This is a frustration of mine as well, but I vaguely remember someone showing something on HN where the file could essentially save itself, I think they were using some file APIs for that... sadly I can't find the details anymore. But I keep running into the "HTML file opened locally can't update itself" issue repeatedly now that I build tools for myself with LLM agents.
The File System Access API can do this, and it works in local ("file:///") HTML files, but it's only currently supported in desktop Chromium browsers: https://caniuse.com/native-filesystem-api
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:
If try to do data management in Excel or need to download an app just to save some recipes, this could be an alternative. For example you can track time and billing with a nice UI without requiring a SaaS subscription. You can try some examples in https://withcapsule.app/preview
I’ve been experimenting with Capsule and really like the concept.
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.
Thank you for providing such a concrete use case, this is exactly why I created Capsule in the first place. I will add support for APIs without CORS in the next version of the app.
Decker works similarly to this (without the SQL-lite, but directly in the single flat html file which can be statically hosted or passed around, and includes an editor for itself!) https://github.com/JohnEarnest/Decker
I really like the idea. It's so easy to create small tools with AI now, but hard to install them as local apps or share them.
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.
This is a really cool and practical idea! Some of my first professional efforts out of college were writing Python mini-apps with Tkinter to replace "abused" Excel spreadsheets. One of my friends working in sales might benefit from something like this, I'll send it his way.
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.
Indeed. But Lotus Notes actually had the design and data stored independent of one another and you had database templates. You could update your design without breaking the data, or even have entirely different design that works with the existing data model.
This capsule thing seems to store the design itself within the database, which is odd to me. I guess I don't get it at 100%.
Yeah, it's not an exact match. But I could email you a lotus notes nsf file and you could open it in your Notes client and have the data and the application in front of you.
With the battle of AI versus human agency raging I have a prediction that local-first desktop apps are going to make a comeback. It's nice to see something like this make it easier.
I agree and would love to see a shift back to what we had circa ~2009-2010: high quality, desktop and platform-specific apps that you could just pay for once (the best variant for everyone being an app that works indefinitely, but only receives updates if you renew your license every year).
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).
In preparation for the upcoming [Android lockdown](https://keepandroidopen.org/) I've started vibe-coding some PWAs for apps that I like so I can have a webby version of them with no ads and no Google/iOS lock-in. I like this, it feels like a good direction.
It's depressing that everyone decided Electron was the final form of all applications and that native apps were dead until AI came along, and if native apps come back it will only be as vibe-coded slop. It's like we've just moved from once circle of hell into another.
Also Show HN is supposed to be for posting code that the community can discuss and play with. Plain advertisements and landing pages aren't allowed.
This sounds like a Smalltalk image, just without the self-modifying capability, which is what makes this whole idea of code+data in a single file so appealing IMHO.
I wish there was a way to see the underlying HTML/JS and schema of these container files. Maybe you can on the desktop app? But it would be cool to see what's happening under the hood.
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?
Merging works already but is a little bit hidden under the data editor function in the Capsule edit menu. Currently the last record update wins, but a merge UI is planed to do manual conflict resolving.
I remember a million years ago, when I was writing apps with Cordova/Phonegap, I would use Web SQL to do all my storage [1]. This kind of reminds me of that.
I always thought that there should be an easy way to export it, but I don't think that ever materialized.
I've been doing this with bun lately, single file app with built in SQLite. JS runtime which serves the app with SSR, websockets, and all that good stuff. The binary size is not that small, but that's usually worth the convenience.
Many big companies are starting now to test agentic coding to automate business processes. This could be a nice tool to distribute apps for workflows that aren't big enough to justify the operational overhed of maintaining a traditional web app backend. Nice!
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.
Whats the advantage over plain single html files/apps using colocated css and use the browser/web view local storage? Those could be saved as PWAs or not?
Looks useful, but the Mac download shows "“Capsule” is damaged and can’t be opened. You should eject the disk image." and then you realize it could be ripe for malicious payloads as well.
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.
"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"
I just added Google Drive support to the Capsule Web app, which supports reading and writing capsule files. More cloud providers and features are planned, along with integration into the desktop app.
It seems a bit ridiculous but there’s definitely something here. I have been really enjoying building similar single-file prototypes with agents. They seem to have no trouble dealing with all the code being piled in one big file and you can skip all the complexity, time, and token cost of of bundling.
I really like this idea. It will be useful for local first users for simple applications. Is it open source? If yes, can you share the link? if not, how can we send templates under our name? are there any template or app marketplace? @bashtian
Adding to the chorus of “this looks like X old thing”.
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.
Interesting concept. Looks like zip replacement. UX improveemnt.
I have one concern, can my machine natively read capsule file format? Else no one would open the shared files.
This reminds me a little bit of https://webtil.es/, which can be either bundled standalone files or hosted, and add a special secure execution context.
For saving data in the capsule file it would create complexity regarding migration handling when updating the HTML file to add a field to a form for example. Keeping the data schemaless makes it also easier for merging data or importing data from a CSV.
I like that there are so many haters who don’t get it or don’t think it’s useful and then there are 5 or so very similar projects in various stages of development listed in the comments. It’s giving “what if I don’t like beans?”
The HTML files does not have any permission to access anything on the file system. Ideally the whole app will be running inside a sandbox on desktop, for mobile apps this will be the default anyway.
Personally, you lost me at `.capsule`. I assume this is your format? Now, what happenss when you are not around or I don't have access to you when it is needed most?
Sorry I am confused. If you(u1) share a link (html page) with your friend (u2), they fill data/form, then it get saved in u2's desktop. How does u1 see it?
The problem would be cross-platform support. In the end the capsule file is the standalone binary similar to a PDF or a Word document, you only need the viewer app to open any capsule file.
you can trivially bake X binaries if you have the viewer app for each platform. This is the normal way to distribute software for cross-platform support.
I might just be hyper-defensive to any sort of vendor lock-in like a "viewer app".
i built something similar back in 2013, but it used to keep the persistent state in the url params (obv not a good storage backend), and you would get a super long url to share over facebook haha
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.
This is for local document like apps. Tauri is actually using the OS webview instead of bundling Chromium like Electron. That's why the download is only 10MB for Mac.
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 have been meaning to use Justine's RedBean to build a "project app" (kind of like what the OP describes, but leaning more towards something like Datasette). It would contain the data, the paper(s), and the UI for interacting with the data (and supporting scripts or R that can be run with other tools). I just like the idea of a portable single-file scientific artifact.
Looks amazing, I don't know if this is legit or useful feedback, but I navigated away after reading "Generate & update apps using AI".
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.
> 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.
*In Chrome.
That file editor seems to work in Firefox. I just tested the save/open functionality.
It's not using the File System Access API, on Firefox it uses <input type="file"> for file-picking, and the save just downloads it. It's not synchronizing anything with your filesystem.
I see. Thanks for enlightening me.
Do you know the reason for that? The File System API does seem to be well supported on Firefox: https://developer.mozilla.org/en-US/docs/Web/API/File_System...
Firefox unfortunately does not support the File System Access API. You can try by calling the most fundamental function, the one that asks the user to select a file:
What Firefox supports is a "File System API" which creates something similar to the other old ways of storing data in a browser, like cookies and indexeddb. You cannot use it to edit normal files on your disk.This is my main gripe with Firefox. They force their users to either store everything in the cloud or go through the arcane "download" workflow where you have to manually save files.
> Firefox unfortunately does not support the File System Access API.
I would not call it unfortunate. Browsers should not have access to the file system, USB ports, etc. Perhaps in "PWA"s, if the user has a way of giving and withdrawing consent.
I would prefer that Browsers be given access via permissions - that way webapps will become more prevalent than appstore apps.
Why shouldn’t browsers have these capabilities..?
It's unsafe and allows for even more privacy invasion.
Why is that true? Some applications require file system access. People would grant the application the permission to access files like any other resource like camera, mic, location.
Because vulnerabilities, coarse access granularity and lazy or ill-informed users. E.g., you now grant cam access per domain. Changing functionality on that domain doesn't revoke permission, so a simple bait and switch is already possible. Now imagine granting access to your file system to some Microsoft domain and finding out that there was a change of heart and some new script has uploaded your files to OneDrive and deleted them from your disk.
Taking that logic of protecting users from themselves to the extreme, a website should not be able to display text either. Because it can use text to ask the user to open their explorer and delete the files manually.
I think the flow of Chrome where the user has to select a file from disk and then acknowledge a prompt that the site will have access to that file until they close the window is fine. But if Mozilla wanted to protect users from themselves even more, they could make it as strong as they like. For example, by requiring to turn the functionality on in about:config.
Not giving the user the choice at all, if they want a cloud only browser or a browser that lets them work with local files is the wrong way.
Iirc the File System Access API should always originate File objects from an input picker so that the user selects the file to be opened and not give more access to apps than users allows?
It just downloaded the file on my firefox.
*In browsers that have implemented it
My dream is that you could write to Google Drive or iCloud Drive transparently too if the browser allows you to
I believe you are able to connect to a Google Drive account with a purely client side site via google oauth and then using the Google Drive rest api. There was an article in particular that I liked that walked through it. Let me see if I can find it
Yes but Google OAuth is a nightmare if you want to "publish" your client so that anyone can use it. If only you use it, you can add yourself as a test user. Just know your access token expires super fast and you will have to frequently re-auth. Its crazy annoying.
This is possible with RxDB, you can sync from browser to google drive or ms onedrive
it's not only about saving data but easily sharing too. I think the capsule file is great for sharing one's work without the hassle of hosting.
Ease of backup too. One of the issues I take with browsers allowing web apps to save data locally is that they don’t also expose a way to easily locate the data in the filesystem or export it, and to my knowledge on-disk format isn’t standardized and so portability between browsers is also a concern.
The effect of this is that unless the user uses migration assistants or similar when upgrading to a new computer is that they’ll lose all local web app data. To me to this feels like a serious problem but when it’s brought up it tends to be hand waved away.
Even better how about a fully functional VSCode: https://vscode.dev
The File System Access API makes it possible.
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
I did not know this! What a cool feature.
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.
Yep, like Hyperclay. https://news.ycombinator.com/item?id=49690814
They're like lightweight versions of https://github.com/kem-a/AppManager which is for AppImages.
Not a bad thing, but it's just another dependency and tied to an OS-specific base software install.
They could work well pre-installed on the Mecha Comet with a bunch of app files ready to launch.
Can the added layers guarantee a new level of security or privacy like zero telemetry or keyjacking? Protection from bad actors is a good thing while making things faster and easier overall. Browser extensions are a security risk, right?
Java applets were a good idea in the sense that so long as you had Java installed, the applet was just sitting there on a webpage. Finding and managing the apps is the problem, and using browser bookmarks is a decent solution to it. The web page should demo the app, and there can be an 'install local' button next to it. But at some point all these local versions need to be updated and then not be messed with like browser extensions can be. FanFare would be a decent name.
Seems pretty useful in an enterprise context to me. I see it as an alternative to 10 million vibe coded apps to dockerize and manage. You can put the runtime on everyone’s machine and provide a web version for really collaborative stuff.
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.
It could be useful for us with home labs for the same reasons. Kind of annoying to deploy docker containers for all the services I build that amount to personalized/skinned trello boards.
Not trying to plug myself, but I’ve been working on a similar project for this exact reason. It doesn’t use special file types. Just HTML and localStorage proxies to sync devices.
It’s self-hostable too. I’ve got a bunch of super niche todo lists and personal apps running on my home server with it.
https://github.com/momja/Exhibit
There are a few things in Capsule to avoid corruptions of the file during syncing. The DELETE journal mode is used and writes are batched into transactions so that updates are always complete changes. And if there is a copy created because of a conflict merging two capsule files is supported.
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?
> Isn't that a lot simpler?
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.
For most users having to mail a file to someone is way more work than having to just share a link. The cost of cloud storage is almost nothing (since email is mentioned I assume 50MB max per project). A notes app that don't sync between all devices is just a text editor to most.
I do like apps that have sensible export formats though. Having control over my data is important.
> For most users having to mail a file to someone is way more work than having to just share a link.
Citation very much needed. Sharing a link, especially if you’re already at your computer where the app runs, very often means emailing the link.
> The cost of cloud storage is almost nothing
“Almost nothing” is not nothing. I really wished we stopped with this idea of “I can afford it, so everyone can too”. And you’re summarily ignoring the very important point of the annoyance (especially for someone inexperienced) and security aspects, which are huge.
> A notes app that don't sync between all devices is just a text editor to most.
Maybe for you. I recommend you observe more regular people.
Also, that is a single example, not representative of the whole.
Or the copies can go their own way. I could send someone an itinerary and they could change the dates or drop half the stops and add their own notes without needing to send an updated copy. Getting them to install another app just to open it might be a problem, especially if they only want to use it once.
In a corporate context it's basically impossible for employees to host an app anywhere. So an app that works entirely locally and you can send to colleagues sounds useful.
theres still lots of programs where local is the main user. but as time goes on the user may want to portably move it just by emailing the file itself. i made like a very light clone of notepad++ using it for my macbook. as a side note: i think they missed an opportunity to call it .pdfv rather than .capsule
> hosting it somewhere on the web, which is not that hard to do these days.
Tell any non-tech person that.
A non-tech person could handle this: https://app.netlify.com/drop
I asked mum. I'm not going to type in what she said, otherwise my comment will get flagged.
Why not on a shared drive like dropbox?
Concurrent editing wouldn't work, though.
Beyond "not working", concurrent editing is likely to silently lose data, or corrupt data, or possibly just fill up your drive with lots of "conflicted copies" that you have to manually reconcile.
When I read about this project, it doesn’t seem like concurrency is much of a concern. I think it’s _supposed_ to be treated like sharing a document with someone else.
If a capsule is a recipe, like in one of the examples, that’s pretty cool. If a capsule is a recipe _manager_, then I think it would get messy.
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/
FYI requests from your demo are being blocked by CORS in Firefox and it never loads.
Thanks for the heads up! Fixed now, was a bug in the service worker.
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...
If you want to distribute apps to many users this would probably be a better solution. The main benefit of Capsule is the personal document like app. You create a capsule, move it to an USB stick, save it in your cloud storage and it's still the same document. Nothing has changed, not the UI, not the data. The document will stay the same.
If it’s web native, anyone can just use it. If it’s a capsule, they first need to download the capsule app to associate the file extension with the OS and have it launch, right?
That feels like a big barrier, almost like a Java runtime.
In defense of capsule, the Filesystem API is janky and has kind of shit UX. Less sophisticated users would probably prefer the UX of a purpose built tool.
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.
how is a filesystem supposed to prevent you from doing that?
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?
Each document record is saved with UUID and timestamps. When deleting a record the data is removed but the record keeps a tombstone so only the ID remains. For conflicts currently the newest one is used, but there will be a merge like UI in the future to confirm which one to use.
Git, html+css+svg and data in json.
This would be great if it evolved in a universal format/spec/feature supported by all major browsers. Only then you'd have to deal with cross web engine compatibilities. And if capsules need to do something non-trivial then you need to consider all the security aspects of having system, file or network level access. Just like any executable. Otherwise with custom app to run capsules it feels like something that can be vibe coded with electron/nw.js rather easily.
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
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?
I'm currently 50/50 on open source the full app vs just the spec. Since I'm currently having a strong idea of what features and functionality is still missing I feel that open-sourcing right now would distract to much in this phase. But maybe when the main features are done it would make sense to have more people looking at and improving it.
Do what you feel is best for this project and good luck :)
An idea for a killer feature: Make it so that auhors can expose their capsules to the internet, and the people whoe wants to use them(lets call them users) can type the name(lets call it address) of the caplsue into the app, and your program will pull that capsule in the the users device..
Hear me out. Here is the name
PWA : Probably Web Again
nice. we should call it web, like spiders' web all connected.
wow, that sounds revolutionary.
This is great. Curious: this requires users to have a host app installed on their machine that can read .capsule file right? Won't that be a point of friction for distribution?
Isn't html/css a better distribution mechanism as most computers already have the tech to run them?
You'd think so, but web browsers are downright lobotomizing the ability for local HTML files to run any meaningful javascript code. Want to run a JS file from the same directory? CORS ERROR!!!!
Hence 200MB applications that are complete copies of the Chromium browser to run under 1MB of actual web code.
couldn't you just embed the js directly into the html file though? that would sidestep the CORS error. and since most of the people using a program like this are likely to be using AI to generate their ( likely throwaway ) applets anyway, readability and maintainability for the source doesn't matter as much as it would with human authors so having a separate js file doesn't bring that many advantages anyway.
Sharing HTML files with embedded Javascript is problematic: iOS users can't open the files directly, and have to save the file and then 'open with ... '.
Sounds like iOS is problematic.
Isn't that the price of a relatively well sandboxed experience by browsers?
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.
I wish the browser would either allow local-only or internet-only, then only make up its mind after the first attempted request. Fetch an image from the internet? No script access for local files. Fetch a JS from elsewhere on the hard drive? No internet access. That could provide the sandbox while still being flexible.
That reminds me of TiddlyWiki[1], a wiki application in the form of a single self-contained HTML file.
1: https://en.wikipedia.org/wiki/TiddlyWiki
The problem is that you can't save the user data in way that you can click a single file, similar to a Word or Excel file. I you think a about it, a Excel spreadsheet is also just UI + data in a single file.
This is a frustration of mine as well, but I vaguely remember someone showing something on HN where the file could essentially save itself, I think they were using some file APIs for that... sadly I can't find the details anymore. But I keep running into the "HTML file opened locally can't update itself" issue repeatedly now that I build tools for myself with LLM agents.
Are you thinking of Nash? a standalone editable note as HTML that was featured on HN some time ago. https://keepworking.github.io/nash/
The File System Access API can do this, and it works in local ("file:///") HTML files, but it's only currently supported in desktop Chromium browsers: https://caniuse.com/native-filesystem-api
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.This is the approach Bento took I believe (similar idea, but just for decks): https://github.com/nyblnet/bento.
Saw it on HN a few weeks back
Technically that was more MS Access :-)
I imagined the capsule website would be able to either convert or directly run/open them
That's pretty cool. But who is this for? What problem does it actually solve?
How would I know if I need this, vs something else?
If try to do data management in Excel or need to download an app just to save some recipes, this could be an alternative. For example you can track time and billing with a nice UI without requiring a SaaS subscription. You can try some examples in https://withcapsule.app/preview
I’ve been experimenting with Capsule and really like the concept.
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.
Thank you for providing such a concrete use case, this is exactly why I created Capsule in the first place. I will add support for APIs without CORS in the next version of the app.
Decker works similarly to this (without the SQL-lite, but directly in the single flat html file which can be statically hosted or passed around, and includes an editor for itself!) https://github.com/JohnEarnest/Decker
I really like the idea. It's so easy to create small tools with AI now, but hard to install them as local apps or share them.
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.
This seems ripe for an injection attack. Can it be inspected before running?
This is a really cool and practical idea! Some of my first professional efforts out of college were writing Python mini-apps with Tkinter to replace "abused" Excel spreadsheets. One of my friends working in sales might benefit from something like this, I'll send it his way.
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.
>>Capsule packs your entire app — UI, data, and everything — into a single portable .capsule file.
I'm having Lotus Notes flashbacks.
Indeed. But Lotus Notes actually had the design and data stored independent of one another and you had database templates. You could update your design without breaking the data, or even have entirely different design that works with the existing data model.
This capsule thing seems to store the design itself within the database, which is odd to me. I guess I don't get it at 100%.
Yeah, it's not an exact match. But I could email you a lotus notes nsf file and you could open it in your Notes client and have the data and the application in front of you.
With the battle of AI versus human agency raging I have a prediction that local-first desktop apps are going to make a comeback. It's nice to see something like this make it easier.
I agree and would love to see a shift back to what we had circa ~2009-2010: high quality, desktop and platform-specific apps that you could just pay for once (the best variant for everyone being an app that works indefinitely, but only receives updates if you renew your license every year).
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).
In preparation for the upcoming [Android lockdown](https://keepandroidopen.org/) I've started vibe-coding some PWAs for apps that I like so I can have a webby version of them with no ads and no Google/iOS lock-in. I like this, it feels like a good direction.
I know that I personally have a handful of personal local only apps under development, that in the past I would have reached for a web solution.
It's depressing that everyone decided Electron was the final form of all applications and that native apps were dead until AI came along, and if native apps come back it will only be as vibe-coded slop. It's like we've just moved from once circle of hell into another.
Also Show HN is supposed to be for posting code that the community can discuss and play with. Plain advertisements and landing pages aren't allowed.
This sounds like a Smalltalk image, just without the self-modifying capability, which is what makes this whole idea of code+data in a single file so appealing IMHO.
I wish there was a way to see the underlying HTML/JS and schema of these container files. Maybe you can on the desktop app? But it would be cool to see what's happening under the hood.
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?
Merging works already but is a little bit hidden under the data editor function in the Capsule edit menu. Currently the last record update wins, but a merge UI is planed to do manual conflict resolving.
I remember a million years ago, when I was writing apps with Cordova/Phonegap, I would use Web SQL to do all my storage [1]. This kind of reminds me of that.
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
I've been doing this with bun lately, single file app with built in SQLite. JS runtime which serves the app with SSR, websockets, and all that good stuff. The binary size is not that small, but that's usually worth the convenience.
Many big companies are starting now to test agentic coding to automate business processes. This could be a nice tool to distribute apps for workflows that aren't big enough to justify the operational overhed of maintaining a traditional web app backend. Nice!
This sounds like the modern take on MS Access.
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.
Looks neat. Shuffling artifacts around is more important than ever with all the agentic web sites and apps we are making.
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...
Whats the advantage over plain single html files/apps using colocated css and use the browser/web view local storage? Those could be saved as PWAs or not?
Looks useful, but the Mac download shows "“Capsule” is damaged and can’t be opened. You should eject the disk image." and then you realize it could be ripe for malicious payloads as well.
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'm surprised to not see Pocketbase mentioned in this thread at all.
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"
I've always wanted something like this!
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?
I just added Google Drive support to the Capsule Web app, which supports reading and writing capsule files. More cloud providers and features are planned, along with integration into the desktop app.
Very cool!
It seems a bit ridiculous but there’s definitely something here. I have been really enjoying building similar single-file prototypes with agents. They seem to have no trouble dealing with all the code being piled in one big file and you can skip all the complexity, time, and token cost of of bundling.
I really like this idea. It will be useful for local first users for simple applications. Is it open source? If yes, can you share the link? if not, how can we send templates under our name? are there any template or app marketplace? @bashtian
Adding to the chorus of “this looks like X old thing”.
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.
Ah yes that was a whole era of programming for me. It was really fast to ship features... and then came the web!
Interesting concept. Looks like zip replacement. UX improveemnt. I have one concern, can my machine natively read capsule file format? Else no one would open the shared files.
This reminds me a little bit of https://webtil.es/, which can be either bundled standalone files or hosted, and add a special secure execution context.
What is wrong with using IndexedDB?
For saving data in the capsule file it would create complexity regarding migration handling when updating the HTML file to add a field to a form for example. Keeping the data schemaless makes it also easier for merging data or importing data from a CSV.
Doesn't indexedDB have builtin migration mechanism?
>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.
I like that there are so many haters who don’t get it or don’t think it’s useful and then there are 5 or so very similar projects in various stages of development listed in the comments. It’s giving “what if I don’t like beans?”
New way to deliver viruses just dropped! Great idea but it can be abused for sure.
The HTML files does not have any permission to access anything on the file system. Ideally the whole app will be running inside a sandbox on desktop, for mobile apps this will be the default anyway.
Love the UI. Simple and clean. Html instead of full app is nice idea. Make online sharing for collaboration edit, but yep need cloud storage.
Personally, you lost me at `.capsule`. I assume this is your format? Now, what happenss when you are not around or I don't have access to you when it is needed most?
Sorry I am confused. If you(u1) share a link (html page) with your friend (u2), they fill data/form, then it get saved in u2's desktop. How does u1 see it?
this is for local apps
if state is best shared, why keep it w/ the code?
You're gonna end up having to build a complex state sync system to a central DB anyways...
How do I build apps that save data to the .capsule file, beyond the templates?
Is the file still fairly readable as plain text when opened with any old text editor? Is this asking too much?
Seems very "packable into a standalone binary" but doesn't seem like that is a planned use case.
The problem would be cross-platform support. In the end the capsule file is the standalone binary similar to a PDF or a Word document, you only need the viewer app to open any capsule file.
you can trivially bake X binaries if you have the viewer app for each platform. This is the normal way to distribute software for cross-platform support.
I might just be hyper-defensive to any sort of vendor lock-in like a "viewer app".
Attackers / Malware Developers: "A document as a web app?, What could possibly go wrong?"
reminds me of https://fzakaria.com/2026/08/23/your-executable-is-a-sqlite-...
This is great. My initial thought is to create a zettel for my research projects.
i built something similar back in 2013, but it used to keep the persistent state in the url params (obv not a good storage backend), and you would get a super long url to share over facebook haha
“Capsule.app” is damaged and can’t be opened. You should move it to the Trash.
Is this project open source?
Do you plan to open source it? Seems like a proprietary app & spec.
So, let’s do Visual Basic again, but this time with LLMs and web stuff.
This is proprietary. Yuck
I feel like this is close to a good idea.
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.
is the idea this would be hosted or run locally (like Electron)?
This is for local document like apps. Tauri is actually using the OS webview instead of bundling Chromium like Electron. That's why the download is only 10MB for Mac.
i like that idea. Anything that improves native OS UI, responsiveness (120hz) and reduces resources is a good idea.
We are so back. I remember ActiveX in the old days
It's 1990s Microsoft Access but with AI
Neat!
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 have been meaning to use Justine's RedBean to build a "project app" (kind of like what the OP describes, but leaning more towards something like Datasette). It would contain the data, the paper(s), and the UI for interacting with the data (and supporting scripts or R that can be run with other tools). I just like the idea of a portable single-file scientific artifact.
(also another call for jart to fix their certs!)
I'm kind of exhausted...
I want to sick Claude on porting tsnet to a C/C++ library that can run in a fat binary Actually Portable Executable.
And then I want to use tailscale share / tailscale funnel APEs for... everything...
Like... everything. So many things.
like downloading exe files from the web. but we should invent something to catch bad actors putting bad stuff in them
could see this being handy for a little game with the save bundled in
Was Capsule written in Capsule?
this is great for the 'make a webapp for me and my family' thing
Looks amazing, I don't know if this is legit or useful feedback, but I navigated away after reading "Generate & update apps using AI".
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.
"No cloud. No accounts. Just share it." close tab
Can you elaborate a little?
It reads like the whole thing was vibe coded and 0 work was done beyond what the AI spit out.
well that's a first
yes yes we get it, you don't like AI ...
Really really nice
my-bookreport-v2-final-final-done.capsule
Is this open source ?
love this idea!
Is this a durable object? /s