ローカルファーストソフトウェアとは？ データ主権を取り戻せ（2019）
引用元：https://news.ycombinator.com/item?id=44473135
超同意！自分も同じこと考えてて開発中だよ。データ全部クラウドにあげて、サブスクでお金取られるのホントうんざり。
フィットネスアプリ作ってて、Sublimeみたいな買い切りモデル目指してるんだ。一度買えばX年アップデート付き、その後もずっと使えるってやつ。X年後にアップデート欲しければまた最新版を買えばいい。今のままで十分なら、そのまま永遠に使い続ければいいってモデルね。
90%のソフトはこれが理想だよ。適正価格で買わせて、良い製品作って、クラウドに依存しすぎて使えなくしないでくれればいい。
データプライバシー以外にもメリットはいっぱいあるけど（記事にも書いてあったね）、全部の問題がこれで解決するわけじゃない。まだまだツールが必要な大きな分野だけど、技術的には可能だよ。
最後に、ローカルファーストソフトの最高の点（個人的にね）は、健全なインセンティブ構造に戻ることだと思うんだ。広告とかユーザー追跡とかエンゲージメント最大化で稼ぐんじゃなくて、製品作って、それがどれだけ良いかで対価を得る。ユーザーに本当に貢献するソフトって感じだね。
超同意！もしよかったら教えてくれる？そのフィットネスアプリ、どんな技術スタック使ってるの？特にデバイス間の同期ってどうやってるのか興味あるな。
ノートアプリのObsidianもすごく良いモデルだよ。クライアントは完全に無料だけど、同期はオプションで有料サービス。ノートは全部Markdownファイルで保存されるから、クライアントなしでも完全に使えるんだ。
これが、Bearノートアプリがいかに優秀でサクサク動くとしても、ずっと使うのをためらってた理由なんだ。今ノートをSQLite DBに保存してるから、そのファイルはバックアップやローカル管理できるけど、ノートに簡単にアクセスできないんだよ。
他のエディタ（Macでよく使うやつ）で気軽に編集できないし、バージョン管理のバックアップや同期もiCloud以外で思い通りにできない。
悲しいのは、以前はローカルファイルファーストのノートアプリだったのに、同期やパフォーマンスの問題を理由にSQLiteに移行しちゃったこと。
クラウドのインフラなしで、どうやって同期するつもりなの？
＞＞you’re not monetizing via ads
いや、そうじゃないよ。完全にローカルなアプリでも、広告で収益化してるやつはいっぱい見つけられるから。
＞＞データ全部クラウドにあげて、サブスクでお金取られるのホントうんざり
AIの写真・動画生成は、ローカルで動かすのは現実的じゃないんだよね。
ComfyUIやFluxはあるけど、すごく高価なゲーマーGPU持ってる超ニッチな層向けだよ。その層に対応しようと思ったら、何十種類ものSKUをサポートして、Pythonの依存関係地獄に対処しなきゃいけない。
ローカルアプリとローカル処理をずっと求めてたけど、エッジでのAIはまだ未熟で力不足だから、次のカテゴリのアプリはクラウド経由でしか使えないってことになるかもね。
そして、こういうアプリが時間の節約になるなら、ソフトの大部分を占めて支配的になるんじゃないかと思ってるんだ。
前は写真や動画の編集はローカルでしかやりたくなかったけど、クラウドのサービスは強力すぎて、ローカルは真剣に太刀打ちできないね。
純粋にローカルなのに広告で稼いでるアプリがいっぱいあるじゃん。ネットに繋がずにどうやってるの？
AIの話なんて誰がしたんだ？
たくさんのローカルファーストアプリはAIなんて全然必要ないよ。
ちなみに、Topaz Labsには写真や動画編集向けのローカルで動くAI機能があるけど、あれはたくさんのユースケースで使えるよ（Veoとかみたいに完全に生成するんじゃなくて、アップスケーリングとかノイズ除去みたいだけど、あれも生成AIは使ってるけどね）。
BearアプリがSQLiteに移って残念だって言うけど、あれまだローカルファーストだよ。
外部編集はちょっと大変になったけど、SQLiteデータベースは簡単に操作できるし、スクリプト書けば大丈夫。
バージョン管理やバックアップできないって？できるって！SQLiteデータベースをSQLファイルにダンプすればいいじゃん。ここ見てよ：https://stackoverflow.com/questions/75675/how-to-dump-the-da…
同期とパフォーマンスの問題でSQLiteに移ったのは正解。プレーンテキストファイルは遅いし同期も大変。何十万ものノートを持つ人には SQLite の方が安心で頑丈だよ。開発者は正しい判断をしたと思う。スクリプトを使えば外部エディタから SQLite をいじれる。プレーンテキストじゃデータベースみたいに高速で頑丈には絶対ならないよ。
BearがSQLiteに移ったなんて知らなかった。乗り換えを考えなきゃいけないな。
アプリ自体はすごく良かったのに、もったいないな。
「ローカルオンリー」じゃなくて「ローカルファースト」だよ。
フィットネスデータには色々な情報があるんだよ。健康状態、毎日のスケジュール、ランニングやサイクリングで正確な位置情報とか。結構価値ある情報だ。
メモ帳じゃ心拍数と特定の運動を関連付けたり、時系列でプロットしたりできないだろ。
うん、わかる。同じ気持ちだよ。
たった一つの開発者の選択で、すごく良いアプリが台無しになった。
でも開発者を非難するつもりはないよ、彼らの選択だからね。でも「テキストノート」がSQLiteデータベースに“ロックされる”のは一番嫌なことなんだ。
Bearはまさに“プレーンテキストノートアプリ”だったのにね。ただただ残念。
もっと聞かせてくれよ。笑
ちょうど10キロ走ったんだけど、時計で追跡したデータが俺以外に誰に重要なんだよ？（HRなんか自分でも気にしないし）フィットネスアプリって何のためにあるのかマジで分かんない。今までで一番役に立たない発明かもね。
10年以上前にClojureで自分でアプリ書いて、1〜2年ワークアウト追跡したけど、一週間以上前のワークアウトなんて一度も見返さなかったよ。マジで良いデータじゃない。一番価値のないデータだ。
あなたのコメント、個人的にはどうかしてると思うよ。ああいう話し方する人もリアルにいるし、LLMが発明されたからってその人たちのせいじゃないでしょ。
将来、ほとんどのコンテンツは生成されるようになるだろうし、その生成がクリエイティブ分野、ホワイトカラーの仕事、そしてほとんどのインターネット利用を支配するんじゃないかと俺は思ってる。もしそうなら、データとコンピューティングの古いパラダイムにとっては大混乱だね。
もちろん、やろうと思えばできるだろうけど、俺はローカルファーストの精神には合わないと思うな。お金も払わないだろうけど、もし君や他の誰かがそういうソフトを作りたいなら、自由な世界だよ :)
Syncthingみたいなものかな？
＞そして本当に気にするなら、ノートを掴んで一時的なテキストファイルにエクスポートし、編集を許可し、SQLiteデータベースを更新するスクリプトを作れたかもしれない。
Bearの開発者たちはそれをお勧めしてないよ：「一般的に言って、データベースへのアクセスは読み取りだけなら安全」だって。
https://bear.app/faq/where-are-bears-notes-located/
「そんなことはしない」と言うのは簡単だけど、従業員を一人抱えてて、不況時に解雇するか、広告出してでもあと一四半期給料を払い続けるか選ばなきゃいけない状況になったら、考え直すかもしれないよ。
うん、それは本当だけど、フィットネストラッカーみたいなアプリの場合、それは”コンテンツ”ベースじゃないんだよね。もちろん、現在の進捗に基づいてどんなダイエット計画にすべきか尋ねるチャットボットみたいなAIがあるかもしれないけど、それは君が話してることじゃない。
俺の経験だと、ほとんどのローカルファーストアプリは、TikTokみたいなコンテンツを見る手段じゃなくて、このフィットネストラッカーみたいにユーティリティツールなんだ。
BerlinでLocal-first Softwareのカンファレンス（https://www.localfirstconf.com/）が毎年あって、SFでSync Conf（https://syncconf.dev/）もできたらしい。今年の論文共著者パネルディスカッションはDev toolでのLocal-firstについて学んだこととか話してて、見る価値あり（https://youtu.be/86NmEerklTs?si=Kodd7kD39337CTbf）。
SyncはLocal firstの一部だけど、広く使えるって考えになってきてるみたい。Local firstはユーザーソフトの特性で、Sync engineみたいなDev toolはそれを可能にするツールって感じ。過去トークはここで見れる（https://youtube.com/@localfirstconf?si=uHHi5Tsy60ewhQTQ）。
AIの出現で市場が広がり、Sync engine技術がAIアプリに必要になってきてて、Local-first / Sync engineコミュニティにとってワクワクする時期だよ。
Local FirstのPodcastもあって、Local-firstアプリやインフラを作ってるエンジニアにインタビューしてるらしいよ！https://www.localfirst.fm/
読む価値あるよ。過去にもかなり活発な議論があったんだ:
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コメント
オンライン依存は継続的な維持と費用がかかるから、Local-first（理想的にはLocal-only）じゃないと長期的な信頼性はないね。実用的に見ると、コネクテッド家電や車は一番バカげたエンジニアリングだと思うよ。
これ全部サブスク収入が原因だよ。サブスクで稼ぐ会社は収益も評価額も高く、資金調達で有利だから、そうじゃない会社に勝つ。だからLocal first softwareは廃れたんだよ。
誰かが「SaaSは価格モデル」「SaaSは金融化」って言ってたの、マジでその通りだわ。サブスクは定期収入と価格差別化になる。SaaSより買い切り（ユーザーコントロール効くしLock-in少ない）の方が優れてるのに、心理、文化、市場の力でほぼ全部SaaSになるのは悲しいね。データ管理の利点はあるけど、価格要因ほどじゃない。買い切り＋オプションサブスクみたいな世界ならよかったのにと思うよ。
SaaSはビジネスモデル、CloudはDRMだよ。Cloudで動かせばPiracyできず、完璧なLock-inになる。データExportできなきゃ二重だね。
今のOpen sourceはCloud SaaSをサポートするEcosystemになってるんじゃないかって前から考えてる。Cloud SaaSはソフトにとって一番自由がないモデルなのに、これはすごくParadoxicalだね。クローズドソースの商用ローカルソフトよりはるかにね。
うん、これがCloud化の主な理由だと思うよ。Adobeみたいに技術的にローカルで動くソフトがSaaSになるのは、これ以外に理由がない。Netflixみたいなサブスクと同じ。SaaSモデルは完璧なRacketeering setupで、哲学的に違法にすべきレベル。ビジネスが力を悪用しないわけないし、もう証明済みだね。
Open Sourceに関する意見に同意。多くのものと同じく矛盾を抱えてる。今のLinuxは、大手商業プレイヤーの資金なしには存在できなかっただろうね。
もっとコメントを表示（1）
そうそう、SaaSはビジネスモデルで技術的な概念じゃないんだよね。でも本当の問題は、ローカルファーストのソフトウェアを売るビジネスモデルがないことだよ。昔のデスクトップアプリは買い切りだったけど、ローカルファーストはブラウザでウェブサイトにアクセスするだけで、あらまあソフトウェアが手に入っちゃう。ローカルファーストのソフトウェアからどうやってお金を稼ぐか、その方法が必要なんだ。
＞ローカルファーストのソフトウェアを売るビジネスモデルがない
あるじゃん：「500ドルを前払い、または月21ドルを24ヶ月*」
*もし24回払いを完了しなかったら、ライセンスを凍結します。
へー、じゃあローカルファーストのDRMってこと？
＞ローカルファーストのソフトウェアからお金を稼ぐ方法が必要
いや、必要なのは人々が飢えずに済む方法だよ。そうすれば全くお金稼ぎをせず、代わりに情熱を傾けるプロジェクトに集中できるからね。コホン、UBIコホン。
UBIの最終目的が全然理解できないんだ。もし「誰もが食事ができるように」が期待されてるなら（立派な目標だと思うけど）、食料をタダで提供するんじゃなくて、人々にお金を与えることでそれを分かりにくくする理由は何？もし本当に特定のアイテムが必須で、みんながそれにアクセスできるようにしたいなら、お金を払わせるのは意味不明だよ。お金は必須じゃない物や贅沢品には意味があるかもしれないけど、政府が私にお金をくれて、彼らが本当に私に食べて欲しい物にそれを使わせるなんて、ただ邪魔なだけだ。
全てのUBI支持者の代弁はできないけど、食料だけを取り上げて、「彼らが私に食べて欲しい食料」って言うのは、誰も望まない権威主義的なトップダウン構造を暗示してると思うよ。UBIの肝は、自律性を可能にすることなんだ。人々は自分のニーズが何かを自由に探求し、理解できるべきで、誰かに指図されるべきじゃない。メッセージで「飢える」って言葉を使って分かりにくかったかもね。もちろん食料は最も重要な基本的なニーズで、それを奪うのは今の社会の残酷さを示す顕著な方法だけど、UBIは食料だけじゃなく、もっと広く基本的なニーズ全般に関することなんだ。
でも、UBIの金額って、基本的な財のリストの推定費用に基づいて決定されるんじゃないの？きっと食料だけじゃないだろうけど、いずれにせよ政府がアイテムのリストを作成して、それにUBIを基づかせるんでしょ。もしそれらのアイテムが「誰もがアクセスすべき」ってくらい必要だと見なされるなら、最初にお金を介して抽象化するんじゃなく、無料で提供すればいいんじゃない？
全てがみんなに無料で手に入れば本当に良いけど、それが無理なら、良い第一歩はみんなが全ての公平な分け前に参加できるようにすることだよ。それがUBIが実現すること。また君はまだトップダウンの権威主義で考えてるね。誰かが俺たちに必要な物のリストを作って、それを俺たちに指示すると思ってるんでしょ？そうじゃなく、俺たちは自分で決定したいんだ。UBIの金額は、上の誰かが俺たちに必要なものを考えるんじゃなくて、利用可能なものに依存するべきなんだよ。
デザインとして、UBIはトップダウンのアプローチに依存してるね。これは当然のことのように思える。UBIが存在するには、政府が基本所得レベルの設定方法に関する何らかのシステムを定義する必要がある。CPIが計算されるのと同じように、財（とサービス）のバスケットを定義して、そこからUBIを計算する式を定義すると思うよ。どういう形であれ、政府の誰かが「必須」のリストを作成し、いくら補助するかを決定することになる。時間の経過によるUBIの調整方法も同様に定義する必要があるだろうね。価格は時間とともに変化するし、UBIが最初に施行されるとかなり急速な価格上昇が起こる可能性が高い。結局、トップからの集権的な計画なしにUBIは決して実現しないと言える。それが権威主義的かどうかは議論の余地があるけどね。
SaaS価格モデルをローカルファーストソフトに適用する必要なんてないと思うんだ。Obsidianは同期機能を無料で提供してるけど、クライアント版はすごくいい仕事してるよ。IMHOでは、コミュニティプラグインサポートもある最高のMarkdownエディターで、競合するPKMクラウドツール全部に勝ってると思うね。
これがまさに典型的な例だと思うな。この製品、〜35年前からあるらしいよ。https://www.gpsoft.com.au/
これが中間層がないってことだね。マネージャーなら月25ドルは経費で落とせるけど、2000ドルだと承認プロセスが必要で、外部営業が必要、つまり実際は最低2万ドルかかるんだよ。
ハハ！それが本当ならね。年間25ドルのライセンス買おうとしたけど、TPSレポート書きすぎてもう諦めたよ。たぶんそれもシステム設計の一部なんだろうな。
問題の根本原因は、パーソナルなものを作るのがサーバー／バックエンド（クラウド？）ありの方がなしより簡単だからじゃないかな？
例：LLMでフォーム自動入力するFirefox拡張機能作ったんだけど、LLM部分以外は完全にオフラインなんだ（LLM部分はOllamaもローカルでサポートしてるから任意）。問題は、ほとんどの人にとって使うのが大変すぎること。実行するLLMを探して、どうにかして入手して（オンラインで実行するかOllamaでローカルにDL）、API URL設定して、APIキー入力して、フォーム入力用の詳細全部をローカルのテキストファイルに保存して、それを自分でバックアップ＆同期しなきゃ。
代替案は：アカウント作って、お金払って、詳細入力したら、全部デバイス間で自動で同期＆バックアップされて、オンラインLLMも事前に選ばれて設定済み。すぐに始められる。Ollamaとかopenrouterで色々やる必要なし、ただ始めるだけ。
サブスク方式みたいにユーザーフレンドリーなローカルな方法をどう解決すればいいかわからないな。
車とか洗濯機みたいなのは別の話だけどね :p
＞問題の根本原因は、パーソナルなものを作るのがサーバー／バックエンド（クラウド？）ありの方がなしより簡単だからじゃないかな？
それと、全部デフォルトでクラウドに永続化されることには、エンドユーザーにとって実際のメリットもあるんだよ。
設定を手動で同期したり（あるいは不必要なLLMをセットアップしたり）するのが、「ローカルファーストソフトが廃れた理由」の「根本原因」だとは全然思わないな。
LLMはローカル部分の設定を手伝ってくれないのかな？（ごめん、ただ最初に思いついたことなんだ）
なんでダウンボートされてるか分からないな。将来LLMが全てのOSの標準になったらこれはたぶんうまくいくと思うんだけどね。
でもその頃には、たぶんOSに統合されちゃって、僕の拡張機能ももう必要なくなるんだろうな。
DropboxとかApple、Cloudflareみたいなサービスのおかげで、ストレージの値段がよくわかるよね。月10ドルで2TBとかさ。Cloudflareなら静的ファイルはほぼ無料。ローカルファーストのアプリをDropboxとかに月10ドルで同期させれば十分。クラウドの機能のほとんどっていらないんじゃね？
「Stop Killing Games」って運動に反対するやつは、これ読んどけって感じ。ゲームをオンライン必須にするかなんてただのチョイスじゃん。依存させといて「あとで直すのに金かかる！」とか言うの、マジで情けないわ。誰もそんなの許しちゃダメ。
これ読んでスッキリしたわ！マジでローカルファーストなアプリ増やすべき。ユーザーはクラウド同期なしを選べるようにしろよ。俺はBrisqiってオフラインファーストアプリ作ってんの。オフライン完全対応が基本で、クラウド同期はオプションって設計。キャッシュだけのアプリはオフラインファーストじゃねーよ。ローカルDB必須。作るのは大変だけど、同期は確実じゃないとね。ブログにも書いたよ。
[0] https://brisqi.com
[1] https://blog.brisqi.com/posts/how-i-designed-an-offline-firs…
ビジネス、どうですか？このモデルやってみようかと思うけど、稼ぎ続けるのってどれだけ大変なんだろって心配。
またゼロからやるなら、もっとシンプルにすっわ。まずオフライン版だけで試して、同期はDBのデータだけにしよ。ユーザーが何したかじゃなくて、どのレコードが変わったかだけ追跡する感じ。これで分かる？ビジネスはまあそこそこだけど、マジで自分が欲しかったアプリだから続けられてる。いつも使ってるのがモチベーションかな。
この考え方、面白いけど、コンシューマー向けっぽいね。宣伝だけどさ、うちはSentinel Devicesってとこで産業機器向けにローカルファーストやってんの。トレーニングとか分析は全部、客先の機器でやる。サーバなし！データは外に出せない現場向けってわけ。他のデータ/AI企業は、データ集めてベンダーロックインしたいから、こういう現場向けサービス無視しがち。うちは「外部接続なしのローカルですよ」ってマジで強調しないと、客もピンとこないみたい。コンシューマーでもっと普及してくれれば、産業界も慣れるかな。 https://www.sentineldevices.com
SCADAのベンダーがみんなクラウドに飛びついてきて、そっちに誘導しようとしてんのがムカつくわ。「スマホで工場動かせますよ！」だって。いいかげんにしろ。これでゼロデイ攻撃食らったら、スクリプトキディにポンプで遊ばれるとこだったじゃねーか。
熱い分野だね！あなたとチームが頑張ってて嬉しいよ。求人ページ見たんだけど、全部リモートなしなんだ？ローカルファーストだから？それともマネジメントの問題？
俺は個人的に、このやり方には反対だな。クラウドプロバイダを信用できないってビジネス問題を、技術で解決しようとしてるだけだろ。クローズドソースの問題はオープンソースってビジネスモデルで解決したじゃん。クラウド問題も同じくビジネスモデルで解決すべき。ユーザーが安心できる標準契約とかライセンスを作ろうぜ。例えば、サービス終了したらどうなるか？データ移行は？プライバシーどうなるか？とか契約に盛り込む。難しいのは、ベンダーにメリットないってこと。でも、こういう契約があれば高めに設定できるかも？
＞終了契約: サーバ維持できなくなったらどうするか明記。会社が潰れて経営者が逃げたら、こんな契約どうやって守らせるんだ？って想像しちゃった。
＞これはビジネス問題を（クラウドプロバイダーを信用できない）技術的なトレードオフ（集中型アーキテクチャを避ける）で解決しようとしてるね。
ビジネスや政治の問題を技術で解決できるなら、それは強いアプローチだよ。だって敵対者の能力を排除できるから。クラウド使うなら暗号化が良い例だね。プライバシーポリシーとか規則でデータ守ろうとするのは無理。データは価値あるし、こっそり売られてもセキュリティ手抜きされても分かりにくい。でもクライアントで暗号化して、サーバーが中身見れないって証明できれば心配いらない。問題はサーバーで処理したい時で、その時は自分のサーバー使うしかないね。
＞個人的にはこのアプローチには反対だなあ。これはビジネス問題（クラウドプロバイダーを信用できない）を解決しようとしてる。
ビジネス問題だけじゃないんだ。俺がクラウドサービス避けるのは、サブスクだけじゃなくデータの安全も欲しいから。クラウドにデータ送る時、ローカルで暗号化されてないなら（それは稀だけど）、データがやられるのは時間の問題だよ。
もっとコメントを表示（2）
今は法律あるけど、ホスティングにはないんだ。SteamとかUbisoftとか見てよ。Q: サーバー閉鎖したらゲームコレクションどうなる？ A: お前は何一つ所有してないし、全部失う。GG！って感じ。ユーザーのプライバシーを守るために、悪い業者にクッキー使うって明示させようとした結果が、今のバナーだらけだよ。
これって本当に問題を解決するのかな？例えばクラウドサービス使ってて、契約書にサービス終了時〇ヶ月前通知とデータエクスポートって書いてある。OK。で、本当に閉鎖して契約守ったとする。何が残る？巨大なJSONファイルだ。自分でアプリ書くか誰かが書いてくれない限り、実質役に立たない。発想はいいし何もないよりマシだけど、会社が閉鎖しても何年も動くローカルアプリほど良くはないね。
良い質問だね。俺は弁護士じゃないけど、それが契約のポイントだろ？会社閉鎖時、契約は負債の一部になるんだ。例えば”閉鎖したら各顧客に1000ドル払う”って契約なら、顧客は破産手続きの債権者になる。全額もらえる保証はないけど、利益は破産管財人が交渉する。”閉鎖したら全ソフトウェアはオープンソース”っていう契約も想像できる。これも破産管財人が管理する。あとは法的信託作って、一定期間サーバーを最低限動かす資金を入れる可能性もあるかな。
＞ データポータビリティ保証: ベンダーはデータ移行方法を明示し、全てのフォーマットはオープンか、少なくとも完全に文書化されているべき。
これはサイズが大きいデータには実用的じゃない。プロダクション環境のDB移行は、スムーズに行っても数ヶ月、何年もかかる。危機的状況なら数週間でできるけど、すごく大変だ。オープンソースDBでも、クラウドサービスによってかなり違うからね。最適な解決策は最初から自分の環境にデータ置いて、電源抜くだけにすること。Bring-Your-Own-Cloud (BYOC) とオープンソース組み合わせれば可能だよ。俺の会社はBYOCデータ製品やってるから、このアプローチに経済的利益あるけど、実際にうまくいくの見てるから可能だと知ってる。
100%同意だね、本当に。技術的な解決策があれば、それが通常はより良いアプローチだ。データポータビリティみたいなことー別のプロバイダーにデータを持って行けることーそれはおそらく技術的な解決策が必要だ。でも、enshittification（エンシッティフィケーション）みたいな他の問題は、技術的には解決できない。クラウドベンダーが料金変更するのを技術的にどう防ぐ？解決策の空間は技術的な限界で制約されるって君の言う通りだ。他のユーザーとデータ共有したいなら、中央の権威を信用するか、ブロックチェーンみたいな分散プロトコル使うか。前者なら中央プロバイダーを信用する必要がある。後者なら自分でkey-management（鍵管理）する必要がある（ウォレットの鍵忘れていくらお金失われたか！）。中央集権の良いとこ取りとローカルファーストの良いとこ取りを両方できる技術的解決策はない。常にトレードオフがある。
データポータビリティは、サービス終了前でも有用だと思うよ。Googleのクラウドサービス使ってて、簡単に全データを競合サービスに移せるなら、俺のビジネスに競争が生まれる。クラウドプラットフォームが証券会社みたいだったらどう？UBSからFidelityに株を移すのは書類いくつかで（ある程度）スムーズ。俺のデータも同じであるべきだ。GoogleからMicrosoftに、数クリックで書類やフォルダ構造も失わず全データを移せるべきなんだ。（免責: もしかしたら可能で俺が知らないだけかも。だとしたら、全SaaSベンダーと全データに広げてほしい。）
良い契約は、不正行為が行われた場合に、それに気づき、証明できれば、ある程度の賠償を求める助けになるよ。それは不正行為そのものが起こるのを機械的に防ぐものではない。
＞ これはビジネス問題を（クラウドプロバイダーを信用できない）技術的なトレードオフ（集中型アーキテクチャを避ける）で解決しようとしてる。
これは全然正確じゃないと思う。著者たちは、ローカルファーストのビジネスケースは完全に解決されてなくて、関連した問題だと十分に認めてるよ。これらの問題はビジネスと技術の両方の解決策が必要で、論文は解決策の特性を提案してる。ローカルファーストが分散化の議論だと言うのも不正確。Martin Kleppmannは分散型技術がマスマーケットになる形で問題を解決するとは思ってないとはっきり言ってる。彼はローカルファーストの理想を可能にする、集中型の標準化された同期エンジンの提唱者だ。去年のLocal-first confでの彼の講演を見て。https://youtu.be/NMq0vncHJvU?si=ilsQqIAncq0sBW95
規制だけじゃダメで、Open Sourceみたいに古いやり方に対抗できるビジネスモデルが必要ってのは同意！Open Sourceは技術じゃなくビジネスモデルだしね。Cloudでもできるはずだよ。でもLocal-Firstは普通のユーザーには無理だから行き止まりだと思うな。
BYOCについてもっと知りたいな。あれってデータだけ？それともアプリ全部？Cloudベンダーの問題を避けるには後者が必要っぽいけど、よく分かってないんだ。
”会社の機密保持の信頼”ってのは、やっぱビジネスの問題だと思うよ（そう捉えるのはアリ）。技術より、責任の所在をハッキリさせる方が問題全部カバーできるしね。”賢い数学で magically 問題解決！”ってのは違うと思うな。
この10年くらい、有名なSaaS企業で digital forensics と incident response をやってるんだけど、その経験から self hosting の大ファンになったよ。
＞データ移行方法やフォーマットは公開または完全に文書化すべし
経験上、コード内の schema 以外でデータフォーマットが文書化されてるとこなんて、一度も働いたことないけどね。
HNでは多くの人が違う見方をしてると思う（私もそう）。”confidentiality”の数学的な証明がある方が、安くて信頼できるって見方だね。人間の breakdown （従業員がデータ盗むとか）は見てきたし経験してきたから、法律で責任追及するより技術的な解決策の方が engineers には魅力的かな。基本的には両方必要だけどね。
いろいろ見落としてるかもだけど、論文は CRDTs を解決策として提案してるんだね。あれは分散型だよ、集中型じゃない（中央サーバーあるなら CRDTs は不要）。技術的な解決策としての CRDTs に時間かけてるけど、ビジネスモデルの提案は見てないな。データが特定の cloud-vendor に縛られないビジネスモデルがあれば、 decentralization はいらないはず。 latency や offline support を CRDTs で解決しようとしてるのは分かるけど、私の経験（Groove）だと average users には trade-offs が大きすぎるんだ。今回はうまくいくかもね。
エスクローサービスを使うのが普通のやり方だよ。サービスに前払い（次の3ヶ月分とか）しといて、その間にデータを取り出すんだ。うちの会社は source code で小さいベンダー数社とそうしてるよ。
これって Cloud ベンダーを銀行みたいにするってこと？ベンダーがユーザーの財産を預かってて、ユーザーはそれを引き出す権利がある、みたいな。銀行ならお金を受け取るけど、 Cloud ならデカい Zip ファイル受け取る感じかな。でもそれ practical じゃないし。口座を他のベンダーに移す方が役に立つけど、ここが難しいとこ。移植性だよ。Facebook の友達を physical に受け取るってどういう意味？ Facebook アカウントを他の場所に移すってどういう意味？
いや、全然違うってば。Chapter 11 （や海外の似た破産法）の entire point は、会社が契約から逃れられるようにして、事業を再構築して続けられるようにすることなんだよ。
