ハクソク

世界を動かす技術を、日本語で。

ローカルファーストソフトウェア：クラウドに関わらず、あなたのデータはあなたのものです

324日前原文(inkandswitch.com)

概要

  • クラウドアプリは コラボレーション と 利便性 を提供
  • しかし、 データ所有権の喪失 や 依存リスク が存在
  • ローカルファーストソフトウェアは 所有権 と 協働性 の両立を目指す
  • 理想の実現には 7つの指針 が存在
  • 本文ではその理想と課題を解説

クラウドアプリの利点と課題

  • Google DocsやFigma、Slack、Trelloなどの クラウドアプリ による共同作業の普及
  • データのどこからでもアクセス 可能、リアルタイム共同編集の実現
  • クラウドアプリ依存 による、サービス停止時のデータアクセス不能リスク
  • クリエイティブな仕事 では、自分の作成物への強い愛着や所有感が重要
  • サービス終了や障害時に データ喪失や操作制限 の危険性
  • クラウドは「他人のコンピューター」であり、 完全な所有権を持てない 実態

従来型アプリとデータ所有権

  • ローカルアプリ は自分のPC内にファイルを保持
  • 完全なデータ所有権、バックアップや他ツールでの加工が自由
  • サーバー依存なし、自分の意思でファイル管理が可能
  • テキストエディタ、IDE、Git、グラフィック/CADソフトなどが該当

両立の理想：ローカルファーストソフトウェア

  • コラボレーション と データ所有権 の両立を目指す新しいソフトウェア像
  • ローカルストレージ と ローカルネットワーク を優先利用
  • サーバーは 補助的な役割、データの主役はローカルコピー
  • 端末ごとに データのプライマリコピー を保持、サーバーはセカンダリ

ローカルファーストソフトウェアの7つの理想

  • 1. スピナー不要：即応性の高い操作感
    • 全操作がローカルディスクで完結、サーバー往復の遅延なし
    • ユーザー入力に 即座に反応、スピナー表示不要
    • データ同期は バックグラウンド で静かに実施
  • 2. データが端末に縛られない
    • 複数端末間での データ同期 による柔軟なワークフロー
    • サーバーを利用した バックアップ も可能
    • 同一ファイルの同時編集時には 競合発生 の課題
  • 3. ネットワークが必須でない
    • オフライン環境でも フル機能 で作業可能
    • ネット接続時に 他端末と同期
    • BluetoothやローカルWiFi経由での 端末間同期 も対応
    • インストール型アプリで オフライン対応 が理想
  • 4. シームレスなコラボレーション
    • 複数人による 同時編集 の実現
    • 従来型アプリでは編集競合やマージ作業が必要
    • Google Docsのような リアルタイム共同編集 の体験を目指す
    • 編集提案やレビュー、選択的適用など 多様なコラボフロー への対応
    • GitHubのプルリクエストやGoogle Docsのサジェストモードに相当する機能

（以降の理想や技術的詳細は、次セクションで解説予定）

ローカルファーストソフトウェアの今後

  • 即応性・所有権・協働性 の3要素を同時に満たすソフトウェア設計
  • 技術的課題として リアルタイム同期 や 競合解消 の高度化
  • ユーザー体験 の向上と データの持続的所有 の両立
  • 今後のアプリケーション開発における 新たな標準 への期待

Hackerたちの意見

読む価値ありだし、過去にはかなり活発な議論があったよね。 https://news.ycombinator.com/item?id=19804478 - 2019年5月、191件のコメント https://news.ycombinator.com/item?id=21581444 - 2019年11月、241件のコメント https://news.ycombinator.com/item?id=23985816 - 2020年7月、9件のコメント https://news.ycombinator.com/item?id=24027663 - 2020年8月、134件のコメント https://news.ycombinator.com/item?id=26266881 - 2021年2月、90件のコメント https://news.ycombinator.com/item?id=31594613 - 2022年6月、30件のコメント https://news.ycombinator.com/item?id=37743517 - 2023年10月、50件のコメント

データの部分は置いといて、プラットフォームや機能面について言うと、これらのクラウドや大規模な製品は、残念ながらもっと強力で高度な機能や便利さを提供してるよね。例えば、デバイス間でのシームレスな移動やコラボレーションを可能にするクラウドのマルチデバイス機能とか、標準のmssql dbを超えたあらゆる機能を提供するエンタープライズ製品のスノーフレークやファブリックとか。個人的にはベンダーロックインには反対だけど、彼らには一定の価値があると思う。

オンライン依存のものは、必然的に継続的なメンテナンスとコストがかかるよね。もしシステムがローカルファースト（理想的にはローカルオンリー）じゃなかったら、長期的な信頼性には向いてない。接続された家電や車って、実用的な観点から見ると、ほんとにバカなエンジニアリングだと思う。

└

すべてはサブスクリプション収益のせいだよね。サブスクリプション収益を得ている企業は、収益も高く、評価も上がるから、資金調達がしやすくなって、そういうモデルを取らない企業を打ち負かすことになる。これがローカルファーストのソフトウェアが消えた理由だよ。

これの背後にある原則を見るのは面白いけど、確実に消費者向けに向いてると思う。ちょっと宣伝になるけど、関連して言うと、今私たちは産業資産や産業データのためにこれをやってるんだ（www.sentineldevices.com）。全てのトレーニング、分析、意思決定プロセスが顧客の設備で行われるんだよ。データを送るサーバーすら持ってないし、私たちのモデルはすべてデバイス上で完結するように設計されてる（だから、記事で話されてたネットワークの原則がすごく興味深かった）。これは、データを外の世界に持ち出せないSCADAや産業オートメーションのユースケースをサポートするためなんだ。実際、データやAIの企業が無視してる大きな顧客基盤とユースケースがあると思う。顧客やユーザーがいる場所でサービスを提供するのは難しいから、彼らはデータを自分たちのところに持ってきたがるし、ベンダーロックインを維持したがる。面白いのは、顧客との話し合いの中で、「いや、これはローカルだから、外部接続はないよ」ってことをはっきり伝えないといけないこと。どこでもそんなこと聞かないから、時には一歩一歩説明しないと理解してもらえないことがある。これ、ソフトウェアベンダーの頭も混乱させることが多いよね。消費者向けでもローカルファーストのソフトウェアがもっと普及して、産業分野でも慣れていくといいな。

└

エキサイティングな分野だし、あなたとチームがそこに取り組んでいるのは嬉しいよ。キャリアページを見たけど、すべてのポジションがリモートじゃないね。これはローカルファーストのソフトウェアを扱う上で、対面が必要だから？それとも主に管理の問題？

理論的には、ローカルファーストの構築方法が大好き。プライバシーやデータ所有権が基本にある「スモールテック」哲学とよく合ってる。でも実際は難しい！同期エンジンを構築したり、競合解決を扱ったり、スキーマの移行を管理したりする責任があるからね。とはいえ、ローカルファーストのソフトウェア開発のためのツールは、ここ数年で改善されているみたい。ジャズツール、エレクトリックSQL、ロキコープのゼロを注目してるんだけど、他に何かある？

└

最近、オートマージのことを指摘している人を見た気がする。 https://automerge.org/ RustとJavaScriptの実装があって、いくつかのネットワーク戦略もあるみたい。ジャズツールのような無料や有料のオファリングはないけど、かなり良いよ。

└

サーバーにCouchDB、クライアントにPouchDBを使うのは、そんな環境を作ろうとした試みだったんだよね。 - https://couchdb.apache.org/ - https://pouchdb.com/ それから、"ローカルファースト"なアプリ開発についての考察が「数年前」（約10年くらい前）にここに載ってるよ: https://unhosted.org/

└

あのウェブサイト知ってる？ https://www.localfirst.fm 追記: 実は「ランドスケープ」リンク（上のメニューにあるやつ）を指摘したかったんだけど、そのURLはちょっと使いづらいね。

└

自分はローカルソフトを使って、ファイルをgitや時々fossilで同期してるよ（例えば、Androidのtermuxで使うやつね）。サーバーをホストしたり、特別な方法でデータを同期するソフトは使ってない。

└

このサイトにはデブツールのディレクトリもあります: https://lofi.so/

└

それからPowerSyncもあります: https://www.powersync.com/ これもオープンソースで、Dart、JS、Swift、C#、Kotlinなどのバインディングがあります。

それが、僕のプロジェクトを通じて広めようとしてることなんだ。 https://github.com/ibizaman/selfhostblocks と https://github.com/ibizaman/skarabox それらの共通の目標は、セルフホスティングをもっと身近にすること。NixOSをベースにして、できるだけ多くのものをすぐに使えるようにしてるよ。https、SSO、LDAP、バックアップ、ZFSのスナップショットなどね。VaultwardenやNextcloudをパッケージ化して、ほとんどのデータを保存するから、クラウドホスティングの競合になるんだ。ただ、それ以上のサービスも提供してるよ。例えば、ホームアシスタントとかね。YUNoHostの競合でもあるけど、個人的にはこっちの方がいいと思う（目指してるのもあるけど）。SelfHostBlocksが提供するビルディングブロックを使えば、好きなパッケージをセルフホストできるからね。フレームワークというよりはライブラリに近いかな。NASの競合でもあるけど、すべてオープンソースだからこっちの方がいい。ユーザーには技術的な知識が必要だけど、そのハードルを下げるために頑張ってるよ。目標の一つは、Nixやコマンドラインに触れずに、自分のハードウェアにインストールできるようにすることなんだ。

└

すごく素敵だね！これを作ってくれてありがとう！

個人的には、このアプローチには反対だな。これはビジネスの問題（クラウドプロバイダーを信頼できない）を技術的なトレードオフ（中央集権的なアーキテクチャを避ける）で解決しようとしてる。クローズドソースソフトの問題（制御の欠如、信頼性の欠如）は、新しいビジネスモデル、つまりオープンソース開発で解決されたんだ。新しいライセンスや収益を得る新しい方法（ライセンス料の代わりにメンテナンス契約）が生まれたからね。同じように、クラウドベンダーの問題にもビジネスモデルの解決策が必要だと思う。標準的な契約やライセンスを作って、ユーザーがクラウドベンダーとの関係に自信を持てるようにすることを想像してみて。時間が経つにつれて、ユーザーはそういうライセンスを持つベンダーとだけ取引するようになるかもしれない。その権利はこんな感じになると思う: * 終了契約: クラウドベンダーは、サーバーを維持できなくなった場合に何が起こるかを契約で明記するべき。 * データポータビリティの保証: ベンダーはデータの移行方法を明記し、すべてのフォーマットはオープンか（少なくとも）完全に文書化されているべき。 * データプライバシーの透明性: ベンダーはすべてのデータアクセスを追跡・監査し、ユーザーに誰がいつデータを読んだかを報告するべき。きっと他にもいろんな条項を考えられるよね。もちろん、難しいのは採用だよね。クラウドベンダーにとってのメリットは何？なぜ彼らがこれを採用するのか？クラウドベンダーの大きな恐れは、ユーザーが離れてしまうことだと思う。サービスを試してもらうためにお金をかけてるのに、ユーザーが離れたらお金を失うからね。これらの契約は年会費制かもしれないし、もしくは、これらの契約の魅力があれば、ベンダーがもっと高い料金を取ることもあるかも。

└

現在、法律はあるけどホスティングに関してはないね。例えば、SteamやUbisoftの契約を見てみて。Q: サーバーをシャットダウンしたら、ゲームコレクションはどうなるの？ A: 何も所有してないし、全てを失うよ、GG！ ユーザーのプライバシーを貪欲なウェブサイトから守るために、悪質なサイトにはクッキーを使ってユーザーを監視してることを明記させる必要があるんだ。そして、その結果が今のバナーなんだ。

└
  • データポータビリティの保証：ベンダーはデータがどのように移行されるのかを明確にしなければならず、すべてのフォーマットはオープンであるか、最低限完全に文書化されている必要があります。これは、どんなサイズのデータに対しても実用的ではありません。新しいデータベースへのプロダクト移行は、スムーズに進めたい場合、数ヶ月または数年かかります。危機的な状況では数週間でできることもありますが、本当に厄介なことになります。同じバージョンのオープンソースデータベース間での移動でも、クラウドサービス自体にかなりのバリエーションがあるため、これが当てはまります。最良の解決策は、最初から自分の環境にデータを持っていて、ただプラグを抜くことです。これは、オープンソースと組み合わせた自分のクラウド管理で可能です。私の会社はBYOCデータ製品を運営していて、このアプローチには経済的な利害関係があります。一方で、実際にうまくいくのを見てきたので、可能だと知っています。
└

エンドオブライフ契約：クラウドベンダーは、サーバーを運営できなくなった場合に何が起こるかを契約で明記すべきです。会社が閉鎖して、経営者が立ち去ったときに、これがどのように実行されるのか想像できません。

└

これって本当に問題を解決するの？例えば、私が楽しんでいるサービスのためにクラウドプロバイダーを使っているとしましょう。彼らは、もし閉鎖することになったらXヶ月の通知をしてデータのエクスポートを許可すると文書で明記しています。いいね、素晴らしい。でも、彼らが本当に閉鎖することを決めて、その契約を守った場合、私には何が残るの？巨大なJSONファイルが残るけど、それは自分でアプリを書くか、親切な誰かがやってくれない限り、実質的に役に立たない。考えはあるけど、何もないよりはマシだけど、会社が閉鎖したりサポートをやめたりした後でも、何年も何十年も動き続けるローカルアプリを持っている方がずっと良いよね。

└

ベンダーはデータがどのように移行されるのかを明確にしなければならず、すべてのフォーマットはオープンであるか、最低限完全に文書化されている必要があります。経験上、データフォーマットがコードのスキーマ以外で文書化されている場所で働いたことはありません。

└

個人的には、このアプローチには賛成できないな。これはビジネスの問題を解決しようとしてるけど（クラウドプロバイダーを信用できない）、単なるビジネスの問題じゃないんだよね。サブスクリプションモデルだけじゃなくて、自分のデータを安全に保ちたいから、クラウドベースのサービスは避けてる。データをクラウドサービスに送るとき、もしそのデータが送信前にローカルで暗号化されてないなら（そんな機能は珍しいけど）、そのデータが侵害されるのは「いつ」か「もし」かじゃなくて、確実に「いつ」なんだよ。

ほんとにその通り！私もこれに取り組んでるよ。みんなが自分のデータをクラウドに入れるためのユースケースを考え出そうとしてるのにはうんざりしてる。サブスクリプション料金を払わないといけないのは嫌だしね。今、フィットネストラッキングアプリを作ってるところで、サブライムモデルを使う予定だよ。つまり、買って、X年のアップデートを受け取って、すべてのデバイスと同期して、永遠に使えるって感じ。X年後にアップデートが欲しいなら、新しいバージョンを買ってね。今のままで十分良ければ、ずっと使い続けてほしい。これが、90%のソフトウェアに求めるモデルなんだ。合理的な価格で買えて、製品が良くて、クラウドに依存しすぎないものがいい。データプライバシー以外にも、このモデルにはたくさんの利点があるけど（ほとんどは記事に書いてある）、すべての問題が解決されるわけではない。まだまだ簡単にできるようにするためのツールが必要な大きな領域だけど、技術はそこにある。最後に、私が思うに、ローカルファーストソフトの一番の良いところは、より健康的なインセンティブ構造をもたらすことだと思う。広告やユーザーの追跡、エンゲージメントの最大化で収益化するんじゃなくて、ただ製品を作って、その良さに対してお金をもらうって感じ。ユーザーに実際に役立つソフトウェアだと思えるんだ。

└

広告でマネタイズしてないよね はい、してますよ。純粋にローカルなアプリで自分たちでマネタイズしているものがたくさんあります。

ベルリンで素晴らしい年次のローカルファーストソフトウェアカンファレンスが開催されています（https://www.localfirstconf.com/）。これはInk and Switchが主催していて、今度の11月にはサンフランシスコでスピンアウトしたSync Confも開催されます（https://syncconf.dev/）。今年は、リンクされた論文の共著者たちによる素晴らしいパネルディスカッションがありました。デブツールの文脈でローカルファーストソフトウェアが何であるか、そして元の論文以降に彼らが学んだことについて話し合いました。これは本当に見る価値があります: https://youtu.be/86NmEerklTs?si=Kodd7kD39337CTbf コミュニティは「Sync」がローカルファーストの一部であると定着しつつありますが、もっと広い範囲に適用されます。ローカルファーストソフトウェアはエンドユーザーソフトウェアの特徴であり、デブツール（例えば、同期エンジン）はそれを可能にするツールですが、自身が「ローカルファースト」であるわけではありません。過去数年のトークのフルセットはここでオンラインで見られます: https://youtube.com/@localfirstconf?si=uHHi5Tsy60ewhQTQ ローカルファースト/同期エンジンコミュニティにとってエキサイティングな時期です。私たちはリアルタイムの共同作業や非同期の共同作業を可能にするツールに取り組んでいて、今やAIの登場でこの市場が広がっています。すべてのAIアプリは本質的にマルチユーザーの共同作業であり、エージェントがシステム内のアクターとして機能します。これには、同期エンジンコミュニティが取り組んできた技術が必要です。

一般的な冗長性についてはどうかな。ローカルファーストでもクラウドファーストでもなくて、「何でも最初と最後になり得る」って感じ。これがそもそも「クラウド」の仕組みなんだよね。冗長性、メッシュネットワークもそうだし。