フォージの連合が必要だ
(blog.tangled.org)- オープンソース協業は、単一プロバイダに大きく依存する構造よりも、コード転送とコミュニケーションを分担する分散型プロトコルの組み合わせのほうが望ましい、という問題意識の上に成り立っている
- コード協業はもともとgitとメールの組み合わせで行われ、その後gitとGitHubウェブサイトの組み合わせへ移り、ForgeFedはgitとActivityPub、TangledはgitとAT protocolの組み合わせへと続いている
- Tangledはgitサーバー間のイベントを連合する構造で、各サーバーをknotと呼び、サーバーが異なってもリポジトリ協業、サーバー間fork、他サーバー上のリポジトリへのpull requestをサポートする
- コード周辺のAuthenticated TransferにはATを使い、issues、pull requests、イベントタイムライン、follows、starsをあわせて扱い、協業者の招待やSSH公開鍵の共有にも活用する
- 直接cgitインスタンスを運用してメールでパッチを送る流れに似ていながら、GitHubモノカルチャーから離れ、協業の社会性と楽しさを維持しようとする方向性が見て取れる
フォージ連合の必要性
- オープンソース協業のかなりの部分を単一プロバイダに依存する構造は望ましくなく、中央集権型システムよりも分散型プロトコルのほうが長く持ちこたえる、という見方を土台にしている
- コード協業は常に2つのプロトコルを併用してきており、1つはコード転送、もう1つはコミュニケーションを担ってきた
- 初期の流れはgitとメールの組み合わせだった
- その後はgitとGitHubウェブサイトの組み合わせに変わった
- ForgeFedはgitとActivityPubの組み合わせの可能性を見据えている
- TangledはgitとAT protocolの組み合わせで構築中である
- Tangledはgitサーバー同士のイベントを連合し、各サーバーをknotと呼ぶ
- どのサーバーにあってもリポジトリ協業が可能
- サーバーをまたぐforkをサポートする
- 自分のサーバーのリポジトリにpushした後、まったく別のサーバーにホストされたリポジトリにpull requestを開ける
- この方式は、直接cgitインスタンスを運用しながらメールでパッチを送る流れと多くの面で似ている
Tangledが担う役割
- Tangledはコード周辺イベントのAuthenticated TransferにATを使用する
- issuesやpull requestsのようなイベント伝達に使われる
- イベントタイムライン、follows、starsのようなソーシャル機能もあわせて扱う
- vouchesもまもなく追加される予定
- ATは協業者の招待やSSH公開鍵の共有にも使われ、それ以外の部分は既存のgitをそのまま使う
- オープンソースはGitHubのようなモノカルチャーから離れる必要があり、同時にコード協業の社会性と楽しさも維持しなければならない
- tangled alpha
- docs
- source
- discord
- bluesky
- twitter (x)
- feed
1件のコメント
Hacker News のコメント
これが Mastodon よりどれだけ優れているのか、いまひとつ分からない
アプリとは独立したホスティング層があり、誰でも自分のデータをホストでき、その上でアプリがすべてのホストのデータを集めて表示する
だから Mastodon 的な defederation という概念そのものがない
もっと知りたければ https://overreacted.io/open-social/ と https://overreacted.io/a-social-filesystem/ を見るとよい
アカウントは PDS にホストされ、記録もそこに保存されるが、アプリに表示される内容は複数の PDS のデータを集めた AppView が提供する
そのため、どの PDS にいてもアプリ体験は中央集権型サービスのように感じられ、AppView も複数置けるし自分でホストすることもできる
今のように事実上グローバルな発見可能性が生まれるコストは少し気になるが、だからといってこれを単なる別の Mastodon と見るのは難しい
単に立場を決めないとか、自分で正しいと思う方へ行けばいいのではないかと思う
atprotocol 側でかなり積極的に使っているので偏っているかもしれないが、Tangled は本当に満足して使っている
GitHub 代替として自分が望んでいた姿に最も近く、機能はよりシンプルだが、この1年間は個人のオープンソースプロジェクトの主力 social/git サービスだった
私のアカウントは https://tangled.org/did:plc:rnpkyqnmsw4ipey6eotbdnnf だ
Bluesky で築いていたソーシャルグラフがそのまま続くので、コミット、PR、イシューの背後にいる人たちを感覚的につなげて見られる点がよく、ログインも他の atproto サービスと同じなので楽だ
最近は静的サイトの内蔵サポートも入って、クライアントサイドのウェブサイトや簡単な index.html をリポジトリから直接ホストするのにも向いている
Spindles がビルドシステム/アクションの役割を果たしていて、私は Nix の熱心なファンではないが、必要な用途にはかなり合っていた
open API も良く、atproto ベースの標準を活用して簡単に情報レンダラーを作れたし、ボットも作って npmx.dev の機能もいくつか追加した
knot（git サーバー）や runner（Spindles）を自分で運用することもできるし、ホスト版を使うこともできるが、重要なのはソーシャル機能が分離されているので git サーバーが別でもイシューや PR の会話は共通のソーシャルレイヤーで続くという点だ
完璧ではないし、ナビバーに付いている alpha 表示が伊達ではないが、オープンソース作業用としては今後も使い続ける可能性が高い
それが妥当な不安なのかは、まだよく分からない
コメント欄の雰囲気はかなり否定的だが、私も VC 資金には警戒的でありつつ、この分野での競争は促すべきだと思う
今の時点でこういうものを bootstrap で始めるのは非常に難しい、あるいは事実上不可能に見えるし、昨日 HN 上位にあった GitHub 批判の記事とタイミングをうまく合わせたのも事実だが、それでもこうした試み自体は応援したい
意味のある規模まで育ってほしい
タイトルだけ見た時は期待したが、VC 資金が入っていると知った瞬間に検討対象から外れた
収益も出ていない自分の愛着あるプロジェクトをプラットフォームに載せるなら、5年後くらいに rug pull が起きる可能性の低い場所を選びたい
VC プロジェクトは投資資金を回収しなければならないので、結局は何らかの形で rug pull が来ると思っている
だから今は、料金を払う顧客として使うか、あるいは組合員のように会費を払って意思決定への投票権があるサービスの方を好む
だからユーザーとしてはその可能性を前もって知っておくべきだ
そういう現実が目前にあるのに、過度に理想主義を掲げるサービスはあまり好きではない
むしろサービス料金を取るか、本当に理想を追うなら non-profit として始めるか、少なくとも収益化計画は明確に示すべきだ
難しいのは当然としても、特に federation を目指すのなら、同じコストかそれ以上ではなく、むしろもっと安いインフラでも作れるべきではないかと思う
atproto データモデル が気になるなら、https://overreacted.io/a-social-filesystem/ に入門向けの記事を書いてある
少し長いが、全体像をかなり鮮明につかめる
これまで見た ATProto 入門記事の中でいちばん良かった
こうした記事を一か所にまとめたタグや一覧が別にあるのか気になる
私が必要だと思うのは forge federation ではなく、もっと豊かな git repo そのものだ
Fossil はチケット、フォーラム、Wiki をリポジトリの一部として統合していて、ほぼ 90% くらいまで来ているし、clone するとそれらも一緒に取得できてオフラインでも見られる
飛行機の中でも返信を書いておけるし、権限さえあればその場ですぐ、あるいは後で接続が戻った時に同期できる
ただ、特定のアーティファクト種別を VCS にハードコードする代わりに、repo の中にアプリを含めて、そのアプリがどんなアーティファクトを許可するか、どんなルールに従うか、誰がいつアップロード/ダウンロードできるかを決める方向の方がよさそうだ
forge はそのポリシーを実行し、ウェブユーザーに望む形でレンダリングするだけでよい
こうなれば、別の forge へ移るのも結局は repo を push する程度で済む
最近、チケットシステムやエージェントのようなものを git repo 内の flat files で作っていたのだが、今度はそれを repo 管理そのものまで拡張すべきだと思えてきた
ものすごく良くなりそうだ
私が感じる federated solution の核心的な問題は、結局 cold start だ
既存の大規模サーバーに入れば、逃れたかったはずの中央集権問題を再び抱え込むことになるが、その代わり最初から大きなネットワークは得られる
一方で自分でサーバーを立てると、ネットワークは 0、発見可能性も 0、フィードは空で、他サイトに連合してもらうか、1人用サーバーだからといってブロックしないよう説得しなければならない
こんなふうに感じるのは自分だけなのか、それとも federation を誤解しているのか分からない
もしかすると、これは単に Mastodon 特有の問題なのかもしれない
個別サーバーを中央の AppView が一つにまとめ、中央集権的ネットワークのような一貫した単一ビューを与えるよう設計されているからだ
AppView は誰でもホストできる
atproto では各サーバーが半ば孤立した区画のようには動かない
分散システム観点の説明なら https://atproto.com/articles/atproto-for-distsys-engineers がうまく整理している
大規模サーバーが moderation、ポリシー、コンテンツ、技術的問題で怪しくなったら、比較的簡単に離脱して別のかなり大きいサーバーを育てたり移ったりできる
つまり、最初からある程度の評判と規模を持つ避難先を作れるということだ
すでに GitLab、Codeberg、freedesktop、Fedora、Debian のような代替 forge があるので、プロジェクトの可視性と発見可能性さえ維持できれば、十分安全な避難先になりうる
でも数日前にこのプロジェクトを見て、これは本当にうまくいくかもしれないと思った
想定ユーザーが self-hosting に慣れた層とかなり重なっているからだ
自分のネットワーク全体が来る必要はなく、実際にここへ来そうなその下位集団だけでも十分に有用だ
フロントエンドサーバーのコストは非常に低いだろうから、ほぼ恒久的に運用できそうだし、実際のデータは別のホストが供給する
Tangled が VC 支援を受けている点は、安心感よりも とにかく成長しなければならない という圧力に聞こえる
魅力がよく分からない
たとえ federated だとしても、開発が止まったらバグ修正や保守を誰がやるのかと思ってしまう
つまり、完全に再現可能で、最小コストで全体を self-host できるようにすることを目指している
VC 資金は目的ではなく手段にすぎず、欧州にいるインド人創業者2人にとっては、助成金は実際に出るまで 4〜12 か月以上かかり、ほとんど現実的ではなかったという
チームを組み、インフラを整え、開発を加速させる最も速い道が VC で、投資家との目標整合も強く合わせ、そのパートナー探しに 6 か月以上かけたとのことだ
Tangled には構造的に興味深い選択が多いが、コード自体は比較的シンプルで、実際に見た限りでも保守難易度は高くなさそうだった
ほとんどは疎結合な Go modules で、そこに静的な HTML+CSS と少量の TypeScript、そしてオーケストレーション用の Nix が載っている程度だ
記憶が正しければハードウェア要件も非常に小さく、今の規模なら個人1人でホストできる
実際のインフラ負担の大きな部分は、ユーザーの knots、spindles、PDS、そして atproto 全体が担っている
なぜ必ず VC が必要なのか、なぜ Ladybird のように企業スポンサーを受けないのか
そして投資家が 10倍のリターン を期待しているのに、最終的に enshittification される開発者向けツールに、なぜ時間を使うべきなのか
標準が4つあるから1つに統一しようとして新しい標準を作ると、結局 標準が5つ になるというジョークを思い出す
冗談はさておき、なぜ ActivityPub では不十分なのか、もっと強い根拠が必要だと思う
分散コミュニケーションの問題を、また別の方式で解こうとする前に
これを対立させるのは、メールがあるのになぜウェブが必要なのかと問うのに近い
ActivityPub はメールのようにサーバーが受信箱の役割を果たし、互いにメッセージをやり取りする構造だ
一方 atproto はウェブのようにユーザーリポジトリがデータをホストし、アプリがそれらのリポジトリからデータを集めて表示する
この topology の違いによって性質も変わり、atproto ではユーザーのホスティング先を変えてもアプリ体験が途切れず、既存データをもとに誰でも新しいアプリを作れる
ActivityPub ではそれができず、結局はホスティングとアプリが結びついた小さな中央集権サービス同士がメッセージをやり取りする形に近い
Nostr 上で動く比較的成熟した GitHub 代替として https://gitworkshop.dev/ もある
中核アイデアは、リポジトリを複数の GRASP 互換 nostr relay に載せられる点で、1台のサーバーが落ちても別の場所を通じて透過的に同期できる
だから信頼できるサーバーを選べば、実質的に 100% 稼働に近く、リポジトリや活動、イシューなども暗号学的に署名される
名前の時点で git の商標ポリシーに違反しているように思える
https://git-scm.com/about/trademark
あるものはブラウザが ssh や https URL をサポートしていないと言い、別のものは
Failed to load file treeと出て無限ロードになるだけだっただから fairly mature という評価にはあまり納得できない
私は federation を強く支持しているが、federation of forges の用途はずっとよく分からなかった
forge 同士でいったい何のデータを交換する必要があるのか
Blender 用の forge がなぜ Ubuntu 用の forge とつながる必要があるのかと思っていた
私が GitHub に最も価値を感じるのは、プロジェクトを渡り歩ける 単一ログイン であって、独立 forge でも複雑な forge federation なしに social login だけ対応すれば、その価値のかなりの部分は提供できると思う
自分で forge をホストすると、Blender のようにすでに大きな名前でもない限り、誰にもそのソフトウェアを見つけてもらえない
だからコードが虚空に消えないようにするには、少なくとも GitHub へのミラーリングがほぼ必須になる
これを避けつつ、より小さな forge たちが一つの集合として競争力を持つには、どのホストにあってもソフトウェアを見つけられる単一ネットワークが必要で、ForgeFed はまさにそれを狙っている
初心者コントリビューターに毎回専用の forge ログインを要求する摩擦も減らせるが、それは副次的でありつつつながった問題でもある
GitHub は UI、イシュー、PR をうまく解決して、初心者でも画面上で作業できるようにしたが、その過程で中央集権化した
federation は Git の思想により近いが、どこかのノードが落ちたら upstream が消えたり、そもそも見つけられなくなったりするほど極端に分散する必要はない
Git は可用性を解決できず、federation は分散の思想を保ちながらその可用性を補えると思う
散在するサーバー上のオープンソースプロジェクトを簡単に見つける方法が必要だ
GitHub のプロジェクト検索は GitHub の中でしか通用しない
それに加えて、プロジェクトホストが消えたり、方針を変えたり、政府によって遮断されたりした場合にも、より resilient になれる
そして AppView が複数の PDS のデータを一つの画面に集めて表示する
もし tangled.org が enshittify しても、他のどの AppView でもまったく同じように使い続けられ、tangled.org 自体が特権的な地位を持たない
独立 forge の social login も役には立つが、個人的には管理するアカウントは1つの方がよく、AT protocol のおかげで個別 forge が消えてもデータには別の AppView 経由で引き続きアクセスできる