Spacedrive - オープンソースベースのクロスプラットフォーム・ファイルエクスプローラー
(github.com/spacedriveapp)- Spacedrive は、複数のデバイスやクラウド上のファイルを一か所で扱う cross-device data platform であり、ファイル、メール、ノート、外部ソースをインデックス化して検索し、P2P で同期する
- Finder や Explorer を置き換えるのではなく、OS のファイルマネージャーの上で、ローカルディスク、外付けドライブ、NAS、クラウドストレージ、アーカイブデータソースを検索・探索する 上位レイヤー として機能する
- すべてのファイルに BLAKE3 コンテンツハッシュを付与し、同じファイルを同じハッシュで識別することで、複数デバイス全体での 重複追跡 と重複排除を可能にする
- デバイス間同期は Iroh/QUIC ベースの P2P sync で直接接続され、サーバー、クラウド、単一障害点なしにメタデータを同期し、ファイルは元の場所に保持する
- S3、Google Drive、Dropbox、OneDrive、Azure、GCS をローカルストレージとともに cloud volumes としてインデックス化し、Gmail、Apple Notes、Chrome Bookmarks、Slack、GitHub などはスクリプトベースのアダプターによって検索可能なストアになる
- Spacebot と連携し、選択可能な別プロセスとして AI エージェントランタイムを実行する。Spacedrive がデータ、権限、実行レイヤーを担い、Spacebot が知能を担当する
- 各 Spacebot インスタンスは 1 つの Spacedrive ノードとペアリングされ、そのノードがエージェント認証、デバイスグラフの維持、権限解決、ピアデバイスへの作業伝達を行う
- ファイル読み取り、シェルコマンド、タスクは Spacedrive を通じて対象デバイスへプロキシされ、アクセス可能なデバイス、パス、作業、人による確認が必要かどうかを権限システムが処理する
- 有効化すると、インデックス対象レコードは検索可能な状態になる前に Safety Screening パイプラインを通過する
- Prompt Guard 2 が、メール、メッセージ、文書内のプロンプトインジェクションをローカル分類器で検出する
- 信頼レイヤー、隔離システム、コンテンツフェンシングにより、フラグ付けされたレコードを AI エージェントのクエリから除外し、デスクトップアプリでレビュー可能にする
- 中核アーキテクチャは Virtual Distributed Filesystem、コンテンツ識別システム、トランザクションアクション、リーダーレス同期で構成される
- ファイルとフォルダーは物理的な場所から独立したオブジェクトとなり、各ファイルは複数のデバイスで機能する
SdPathアドレスを持つ - ファイル操作は、実行前のプレビュー、承認またはキャンセル、ネットワーク切断やデバイス再起動に耐える durable job の形をとる
- ファイルとフォルダーは物理的な場所から独立したオブジェクトとなり、各ファイルは複数のデバイスで機能する
- 実装は Rust の単一クレートと CQRS/DDD アーキテクチャに基づき、主要技術として Tokio、SQLite、SeaORM、sqlx、Iroh、BLAKE3、LanceDB、FastEmbed、OpenDAL、Tauri 2、React Native、React 19、Vite、TanStack Query、Tailwind CSS v4、Specta を使用する
- デスクトップアプリは macOS、Windows、Linux、モバイルアプリは iOS、Android を対象とし、CLI とデーモン、headless server、browser client の構成も併せ持つ
- 実行要件は Rust 1.81+、Bun 1.3+、just、アダプター用 Python 3.9+ で、開発コマンドとして
just setup、just dev-desktop、just testを使用する - プライバシーとセキュリティのモデルは local-first であり、P2P トラフィックは QUIC/TLS で暗号化され、ライブラリは SQLCipher によるディスク暗号化が可能で、追跡や分析用のテレメトリーはない
- ライセンスは FSL-1.1-ALv2 Functional Source License で、2 年後に Apache 2.0 へ移行する
1件のコメント
Hacker Newsの意見
インストール直後にライブラリの作成、分析データの共有、ログインを求められたので、ほかのファイルエクスプローラーとは期待していたものが違った
ドライブ上の任意のディレクトリに移動してダブルクリックしたが何も起きず、コンテキストメニューから開いても同じだった
調べてみると、1つのディレクトリにファイルが1.5万個あると、事実上ブラウズできなくなるらしい
Total CommanderやWindows Explorerではこうした問題はないので、Spacedriveは基本的なファイル閲覧機能からもっと磨く必要がありそう
Spacedriveは、ここでの一部返信とは違い、大容量データを念頭に設計されており、Locationを事前にインデックス化してキャッシュを作り、すべてをキャッシュ・仮想化している
次のアップデートで、Locationではない場所をブラウズするときのバグを修正する予定で、多くのユーザーはLocationとして追加する前にまずブラウズしてみるようだ
まだアルファ版ソフトウェアなので、時間をかけて磨いていってほしい
開発者だけのせいにするのは難しく、フレームワークが標準で対応すべきだと思う
仮想化リストを理解していないといけない、という状態であるべきではない
SwiftUIでTableViewを作ったときは、内部動作をまったく知らなくても数千項目をスクロールできた
ソート順キャッシュがないので、アルファベット順以外の方法で開くと、ソートのために5分以上待たされる
かなり前に見たときは実際に試せるリリースパッケージがなかったので、準備ができたら確認しようと思っていたが、1時間前にアルファ版が出たようで、またHNに上がってきたらしい
コンセプト自体は歓迎できる
最近は、厳密なローカルファイルと複数のクラウドストレージとの境界が曖昧になっている
個人的にはその境界を保っていて、Macにクラウドストレージをほとんどマウントしないが、研究者である妻はDropbox、iCloud Drive、Google Drive、Microsoft系のストレージをすべて扱っている
一緒に仕事をする人たちが、それぞれのサービスでファイルを共有し、レビュー作業で共同作業するからだ
こうしたツールがベンダーごとの接続問題や特有の挙動を覆い隠し、ローカルのように見えるが裏側にはどのクラウドストレージが接続されていてもよい透過的なファイルシステムを提供するなら、ワークフローにはかなり役立つはずだ
肝心なのは使いやすさで、レイテンシが大きくFinderより遅く感じるなら可能性は低くなる
Hacker Newsはこの種の製品にとって最適なユーザー層ではない可能性が高い
ここにいる人たちは、すでに各自で最適化したワークフローを持っている可能性が高く、自分も同じだ
この製品は、WindowsとMacを使うがターミナルには慣れていないデジタルクリエイターにより向いていそうだ
アニメーター、イラストレーター、動画編集者、3Dアーティスト、音楽プロデューサー、YouTuber、ストリーマーのような人たちだ
ただ、その2つ目のグループが本当にこういうものを求めているのかはよく分からない
マーケティングを見るだけでは、このソフトウェアが正確に何をするのか分からず、そのグループも同じだと思う
「ユニバーサルなファイル体験」を言いたいのは分かるが、具体的に何を意味するのか不明確だ
ユーザーが機能を理解するためにソフトウェアをインストールしなければならない、という状態であってはならない
オープンソースであることやLinuxで動くことも、彼らにとってはそれほど重要ではなさそうだ
この段階なら、マーケティングを完全に作り直し、その2つ目のグループ向けに最適化すると思う
PR担当者やマーケティングの専門家と一緒に、自分たちが作っている価値が何なのかを具体的かつ効率的に伝えたほうがいい
またチームの労力を節約するために、ソースリポジトリを閉じてLinux版も中止するか、需要が出るまで非公開にしておくと思う
幸運を祈る
かなり長く見守ってきて、いくつかフィードバックがある
ローカルの開発ディレクトリ1つをインデックス化するのに、今のところ35分以上かかっており、最後まで待つつもりはなさそうだ
ほかの人も言っているように、レイテンシが問題だ
macOS M1 14インチの基本モデルで、Locationを追加した後でも、フォルダを開いてファイルが表示されるまで時々2〜4秒かかる
自分が見落としていなければ、まだタブはないようだ
ファイルのソートとグループ化機能はあまりに貧弱、あるいは実質的に存在しないが、開発中に改善されると思う
妥当なインデックス状態を作るには、Locationを手動でたくさん追加するなど、ユーザー側でやることが多そうだ
ローカルファーストなのは分かるが、テレメトリとログインの方式はまったく気に入らない
全体として実際に使ってみると少し期待外れで、自分には合わない可能性が高いが、ターゲットユーザーはいるかもしれないし、まだ先は長い
見た目は本当に良い
なぜこれをReactで作ったのか気になる
RustにQtのようなGUIフレームワークがないというのは分かるが、だからといってこれが答えなのかと思う
新しいものを学びたくないからなのか？
C++アプリやQtで十分作れるし、GUIはQMLで書き、Lua、Python、JavaScriptをスクリプト言語として組み込むこともできる
もちろん作業ではある
ブラウザでレンダリングするのは、OpenGLのようなGPU APIでGUIを作るより簡単な版に近い
OSにはすでにGUIツールがあるのだから、それを使えばいい
そのほかはかなり良さそうだが、pcmanfmのようなものもリモートロケーションの追加をサポートしていないだろうか
もう1つ気になるのは、なぜPrismaを使っているのかという点だ
Tauriは高性能な処理やOS連携が必要なときにRustへ降りやすく、主要プラットフォーム向けのパッケージングもあらかじめ備えている
Reactを使えば、多くのUIコンポーネントがすでに存在する優れたエコシステムを活用できる
ほとんどのネイティブRust GUIフレームワークとは違う
さらにフロントエンドエンジニアと、彼らのWeb技術・デザイナーとの協業能力を再利用できる
Qtほど成熟していないとは言えるが、ブラウザで動くものと比べれば十分な場合が多い
このリポジトリは初期アルファ段階で、既知のバグも多いのに、GitHubスターがこれほど多いのは少し信じがたい
しかもVC投資を受けているように見えるが、langchainやpineconeが投資を受けたことよりさらに混乱する
あちらはAIベースのプロジェクトではあるが、このプロジェクトはすでにかなり扱われてきた領域だ
永久に無料だとしても人々は求めない気がするし、広告・トラッキング・月額サブスクが入ればなおさら求めないだろう
基本的に信頼する理由はなく、不信に思う理由は多い
個人攻撃ではないが、こういう見方を考慮していなかったなら考えてみるとよいと思う
「welcome」の次の最初の画面がログインだ
なぜファイルエクスプローラーにログインしなければならないのか分からないし、この時代はおかしい
ログインする理由は、これがリモートファイルシステムだからだ
ファイルエクスプローラーというよりは Dropbox を思い浮かべるほうが正しい
次のアップデートで変更される予定
最終的にログインは、Tailscaleのようにデバイスを素早く接続する方法になる
散在するクラウド・ローカル、マウント済みストレージと未マウントのストレージのすべてを対象にした検索・閲覧可能なメタインデックスは確かに興味深く、しばらくの間ある種の聖杯のようなものだった
デジタル資産管理は新しい概念ではないが、現在の選択肢が豊富な分野ではない
PortfolioやAdobeの複雑な製品群はこうした機能を多く提供しているが、クラウドストレージよりもワークフローとメタデータに重点を置いている
最近、また一つクラウド依存サービスを導入するには非常に慎重になる必要がある
「ローカルとオフラインファイルまで含めたすべてのファイル」という機微性を考えると、セルフホスティング/オンプレミスが絶対要件になり得る
アカウントが必要なら、OIDCやSAMLを通じた既存のID管理との統合を望むだろう
このツールがファイル全体を見るための必須の単一窓口になり、その上にワークフローを構築するなら、可用性を確信できる継続性機能も必要だ
このまま推し進めてほしい
まだこれを完全に解決したところはない
プロジェクトは格好よく見えるし、野心も気に入っている
いくつかメモがある
すべてのWANアクセスに対して明確なトグルを1つ用意し、分析データや利用データ送信用のトグルは別に設けつつ、デフォルトはオフにすべきだ
さらに良いのは、これらもコンパイル時フラグにすることだと思う
以前、Warpという新しいターミナルは非常に魅力的だったが、デフォルトでネットワーク経由でデータを送信していたため、多くの人にとって即座に候補から外れる理由になった
WindirstatとEverythingから大いに着想を得てほしいし、特にEverythingの検索性能を目標にしてほしい
ロードマップにあるのは見たが、改めて言うとタブが必要だ
Prismaから離れることも検討してほしい
データベースを包み込みすぎていて、魔法が多い
根拠は弱いかもしれないが、いつかライセンスを変更するのではないかと少し心配している
READMEの冒頭に出てくる written in Rust を機能のように扱うのは、そろそろやめてほしい
そういう文言を見るたびに「より安定していそう」ではなく「誰かの趣味プロジェクトなんだな」と感じる
READMEであれば、オープンソースプロジェクトの関連詳細として入れるのは妥当に見える