【新ツール】HTMLアプリとデータをSQLiteファイル1つに封じ込める「Capsule」が凄すぎる

Hacker Newsの皆さん、こんにちは。HTMLページの構築は今や非常に簡単ですが、データを保存しようとするとホスティングが必要になり、その後の共有も一苦労という問題にずっと悩まされてきました。そこでここ数ヶ月、RustとTauri 2.0を使って「Capsule」（ファイル拡張子も兼ねています）というアプリを開発しました。これは、HTMLアプリと関連データをひとつのSQLiteファイルにパッケージングできるツールです。HTMLファイルや関連アセットはデータベース内に直接埋め込まれます。ユーザーデータはlocalStorageのキー・バリュー形式、あるいはMongoDBライクなコレクションAPI経由で、ファイル内のテーブルにドキュメントとして保存可能です。PDFや画像といったアセットもまとめて管理できるほか、必要に応じてCSVやJSONへのエクスポートも簡単に行えます。プライバシーとセキュリティは最優先事項です。ドキュメントはデフォルトで制限されており、ファイルシステムへの直接アクセスは不可能で、インターネット接続には権限が必要です（権限モデルは現在も改良中です）。また、ローカルやリモートのAIモデルと連携した機能も利用できます。このアプローチの欠点は、複数人で作業するとコピーが乱立することですが、データエントリごとにUUIDとタイムスタンプを付与することで、将来的にマージ可能な仕組みを整えています。1.0リリース時にはファイルフォーマットの仕様を公開する予定なので、他のアプリでもCapsuleファイルを読み書きできるようになります。まずはWebプレビュー（https://withcapsule.app/preview ）で既存テンプレートを試してみてください。カスタムアプリを作りたい場合は、以下のプロンプトをAIに投げるだけでOKです。「Please read the app wizard instructions at https://withcapsule.app/prompt.txt and help me design an app.“ ファイルフォーマットは今後も進化しますが、バージョンアップ時のマイグレーションを用意しているためデータが失われる心配はありません。ぜひ皆さんのフィードバックや、こんな使い方があれば面白い！といったアイデアを聞かせてください。

Chromium系のブラウザとFilesystem API、それにPWAマニフェストを組み合わせれば、ネイティブアプリに近い感覚でかなり近いものが安価に作れるよ。AIのおかげで、100%ブラウザのネイティブ機能だけで構築することにまた興味がわいてきた。 https://developer.mozilla.org/en-US/docs/Web/API/File_System_API

個人的な意見だけど、アプリで状態を更新・保持する必要があるなら（SQLiteとか他のDBを使う場合）、それをわざわざバンドルファイルとしてあちこちに送るような形にするのはやめたほうがいいんじゃないかな。

少なくとも、今の時代それほど難しくないWebホスティングに比べると、かなり制限が多くなってしまう。

ワークフローを考えてみてよ。状態が変わるたびに、アプリを使っている全員に新しいCapsuleファイルをメールで送らなきゃいけないんだ。DBを使うからには、状態は少なくとも時々は変わるはずだよね。

それよりWebでホストすれば、DBの状態は動的に更新されるし、アプリにアクセスできる人なら誰でも自動的に最新の状態にアクセスできる。そっちの方がずっとシンプルじゃない？

まさにそのアイデアで取り組んでいるところだよ。sqlarを「フォーマット仕様」として使ってる。ブラウザで動くし、Tauriを使えばデスクトップやAndroidでも動作するよ。

https://github.com/JoshTheDerf/uapp

デモアプリやゲームはこちら：https://thederf.com/uapp/demo/

このアイデアすごくいいね！AIが広く普及して分かったことの一つに、AIはビジュアル要素を作るのはすごく得意だけど、その中にデータを含める必要がある場合、ハードコーディング以外にうまい共有方法がないという問題があるよね。

このアプローチの欠点として、複数の人が作業すると別々のコピーが作られてしまう。同じファイルの異なるコピーをマージ可能にするため、各データエントリには一意のUUIDとタイムスタンプが付与されている。

これを見て真っ先に思ったのが、2つのソースから生じた変更をどう統合するかという点だよ。異なるソースからのデータ入力をどう扱うかについての記述はあるけど、具体的にどうマージするのかがよく分からない。例えば、ユーザー2人がそれぞれ.capsuleのコピーを持っていて、それぞれ変更を加えた後に共有したくなったら、中身の違う2つの.capsuleが出来上がってしまうよね。

それをどうやってマージするの？

でもデータを保存するにはどこかにホスティングする必要があった

File System Access APIを使えば、最近のWebページはデスクトップアプリみたいにローカルファイルの読み書きができるよ。

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

例えばこのテキストエディタを試してみて。

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

デスクトップでもモバイルでも快適に動くよ。

うーん、どうだろう。特定の状況下では機能するアイデアを、本来の趣旨を超えて無理やり一般化しようとしていないかな。

もしユーザーがこのWebアプリを実行するために専用のアプリをダウンロードしなきゃいけないなら、最初からそのアプリをそのまま送ればいいだけじゃない？Capsuleを使うために面倒な手順を踏むのと、同じゴールにたどり着くのに手間をかけるのとで何が違うんだろう。

もしこれが世界中でほぼ標準化されたアプリなら意味があるけど、そうじゃないし。一番近い存在であるブラウザは、すでにここで言っているようなことを実現しているよね？

アプリケーションにデータを同梱するのは理にかなっているけど、それは非常に限定的な状況でしか適切じゃない。もしWebアプリと一緒にデータを配布してもいいなら、HTMLファイルにデータを埋め込むだけで十分だよ。ユーザーがそのデータを修正することを前提にしているなら、自分ならそんな形で配布したくないな。

なんだかMS Accessを思い出すな。IT部門にとっては頭痛の種だったけど、リソースが限られた部署のニーズを満たしていた側面もあったよね。

今後どうなるかすごく興味があるよ。クライアントをオープンソースにする予定はある？それとも、仕様が固まったらファイル仕様だけを公開する感じかな？

最近bunを使って同じようなことをしているよ。SQLite内蔵のシングルファイルアプリで、SSRやWebsocketなんかを全部こなすJSランタイムとして動かしてる。バイナリサイズは少し大きいけど、利便性を考えれば十分見合うよ。

すごく好きなアイデアだよ。今やAIを使えば小さなツールを簡単に作れるけど、それをローカルアプリとしてインストールしたり共有したりするのは難しいからね。

ただ、いくつか重要な機能が足りていない気がする。

1. デバイス間でのデータとアプリ（Capsule）の同期。SaaSを挟む必要はないけど、P2Pか何か既存のサービスを使いたい。
2. データとアプリは分離すべきだと思う。データを共有せずにアプリだけを誰かに渡したい場合があるから。
3. アプリのアップデート機能。既存アプリのコードだけを入れ替えて、データは保持したままにしたい。あと、ファイルを共有するか、公開HTTPサーバーやGitHubリポジトリのフォルダとして公開するような形での更新も必要かな。

デバイス間のデータ同期とオフライン機能の維持が両立するのが難しいのはわかってるけどね。

my-bookreport-v2-final-final-done.capsule