ハクソク

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

絡まった – 鍛冶場の連邦が必要です

11日前原文(blog.tangled.org)

概要

  • OSSの90%が GitHub依存 状態に対する懸念
  • 中央集権型システム の脆弱性の指摘
  • Tangledは 分散型コード協業 の新提案
  • git + ATプロトコル で協業・コミュニケーションを実現
  • コード移動・ソーシャル機能も 分散的 に提供

GitHub依存の問題と分散型の必要性

  • 近年、 GitHubの不安定さ が増加傾向
  • 世界のOSSの約 90%が単一プロバイダー に依存するリスク
  • 中央集権型システム は長期的に脆弱性が露呈
  • 歴史的に email, git, IRC など分散型プロトコルが長寿命
  • OSSコミュニティにおける 多様性と自律性 の重要性

コード協業プロトコルの変遷

  • 初期： git（コード転送）＋email（コミュニケーション）
  • GitHub時代： git（コード転送）＋GitHubウェブサイト（コミュニケーション）
  • ForgeFed： git（コード転送）＋ActivityPub（コミュニケーション）
  • Tangled： git（コード転送）＋ATプロトコル（コミュニケーション）

Tangledの特徴

  • 複数の gitサーバー間でイベントを連携 （"knots"と呼称）
  • 任意サーバー上のリポジトリ でコラボレーション可能
  • サーバーを跨いだ フォークやプルリクエスト の実現
  • 自分のサーバー から別サーバーのリポジトリへプルリクエスト送信
  • cgit＋メールパッチ送信に近い 分散型運用 の実現

ATプロトコルによるイベント連携とソーシャル機能

  • ATプロトコル でコード関連イベント（イシュー、プルリクエスト等）を認証付きで転送
  • イベントタイムライン、フォロー、スター などのソーシャル機能
  • コラボレーター招待やSSH公開鍵 の共有にもATプロトコルを利用
  • コード自体の転送は 従来通りgit を使用

OSSコミュニティへの提案

  • OSSは GitHubのようなモノカルチャー から脱却すべき
  • しかし、 コード協業の楽しさやソーシャル性 は維持が重要
  • Tangledは 分散性と楽しさ の両立を目指す新しい選択肢

Hackerたちの意見

フェデレーテッドソリューションが未来の形になりそうだね。かつては愛されていたプロバイダーが崩れかけの独占状態になってるし。

└

これは一方通行の旅ってわけじゃないよね。2000年代の「オリジナル」ブログ界は、MovableTypeがトラバックをサポートしてて、その後はピンバックで自動化が進んでた。でも結局、スパムやホスティングの複雑さにやられちゃって、今ではほとんどのブログが数少ない中央集権的なホストに戻っちゃった。分散型のフォージを進めるには、スパムやモデレーションが一番の壁になると思う。結局、ウェブ・オブ・トラストやバウチングシステムみたいなものに落ち着くんじゃないかな。でも、アクセスのしやすさとスパム管理の手間をうまくバランス取るのが難しいんだよね。

本当に、git用のBitTorrentみたいなものはないの？それともGitHubのネットワーク効果で知られてないだけ？バイナリの問題はずっと前に解決されてた気がするんだけど。

└

Radicleがまさにそれかもね。

└

gittorrentsは少なくとも15年、下手したら20年前に話題になってたよ。データのミラーリングはもう解決済みの問題なんだ。他のフォージがやること、例えば課題追跡、PR、レビュー、CI/CD、認証、権限管理、秘密、監査トレイルとかが問題なんだよね。

└

あるよ！https://radicle.dev :)

└

gitはすでに分散型なんだよね。足りないのは管理部分（マージリクエスト、権限、課題など）で、これが本当に必要かどうかは疑問だし、あったらいいな程度のものかもしれない。

「この問題を解決しようとする基準が4つあるけど、多すぎる。全てを統一して、問題を根本から解決する基準が必要だ」って。「基準が5つあるけど…」冗談はさておき、活動の公表がこの問題を解決するには十分じゃない理由をもっと強く主張する必要があると思う。新しい「分散型コミュニケーション」の解決策を考えるよりもね。

└

元の投稿にもリンクされてるけど、ForgeFedの著者たちが活動の公表がこの問題に合わない理由を説明してるよ：https://forgefed.org/blog/actor-programming/

└

うーん、わからないな。Tangledは資金調達前からATProtoの上で出荷できたのに、ForgeFedは何年も待機してるのはどうしてなんだろう？

└

ActivityPubとatprotoは形が違うんだよね。お互いを比べるのは「メールがあるのにウェブは必要？」って聞いてるようなもん。ActivityPubはメール型。サーバーはお互いにメッセージを送る受信箱みたいなもんだ。atprotoはウェブ型。ユーザーのリポジトリがデータをホストして（個人サイトやgit/RSSみたいな）、アプリがリポジトリから集約する（Googleリーダーみたいに）。異なるトポロジーは異なる特性を生むんだ。例えば、atprotoはユーザーがホスティングを変更してもアプリの体験に影響がないんだ。atprotoは誰でも既存のデータを集約する新しいアプリを作れるけど、ActivityPubはそれを許可してない。要するに、いくつかの小さな中央集権的なホスティング＋アプリサービスが互いにメッセージをやり取りしてるだけなんだよね。

TangledはVCの支援を受けてるけど、安定性があるとは思えないな。「何が何でも成長しなきゃ」って感じ。魅力を感じないよ。連合型だけど、開発が止まったら、誰がバグを直したりメンテナンスをするの？

└

Tangledは完全にオープンで作られてるよ：https://tangled.org/tangled.org/core。私たちの主な目標は「永久的なソフトウェア」を作ること、つまり完全に再現可能で、最低限のコストで完全にセルフホスト可能なものを目指してる。VCのお金は目的達成の手段に過ぎないんだ。私たちはヨーロッパにいるインド人の創業者で、助成金を見つけるのはほぼ不可能（何かが実現するまで4〜12ヶ月かかることもある）。VCはチームを作り、インフラを整え、開発を加速させるための最も早い方法なんだ。投資家との目標もすごく一致してるし、完璧なパートナーを見つけるのに6ヶ月以上かかったよ。

└

誰がバグを直したりメンテナンスをするの？ それは使ってる私たちだよ。Tangledは面白いプロジェクトで、アーキテクチャ的にも興味深い選択がされてるけど、コード的には比較的シンプルで、私の個人的な経験から言うと、メンテナンスはかなり簡単だと思う。コードベースの大部分はゆるく関連したGoモジュールだし、静的なHTML+CSSも少し。最後に、物事をまとめるための少しのTypeScriptと、オーケストレーション用のNixも使われてる。確か、すべては一人でもホストできるようなかなりトリビアルなハードウェアで動いてるよ。ユーザーのノット、スピンドル、PDS（そしてatproto全体）が、実際のインフラの重い作業を担ってるんだ。

└

プロジェクトがVCに資金提供されるとき、俺は疑問に思うんだ。「なんでVCが必要なの？」Ladybirdみたいに企業スポンサーシップじゃダメなの？VCが10倍のリターンを期待してるのに、どうして将来的にクソ化する可能性のある開発ツールに時間を費やさなきゃいけないの？

└

YCから資金提供されていない限り、VCファンディングは気にしないよ。

└

あなたはVC資金提供を受けたニュース集約サイトにこのコメントを書いたので、誰が何を言えるっていうの？

連合型のソリューションで感じる問題は、基本的に「コールドスタート」問題だね。連合ネットワークに参加したいとき、選択肢は二つ。既存のサーバーに参加するか、自分でサーバーを立てるか。前者だと、結局逃げ出したい大きなサーバーに縛られることになるけど、最初から大きなネットワークがあるのは確か。後者だと、ネットワークはゼロ、発見されることもゼロ、フィードは空っぽで、他のサイトに連合してもらったり、1人サーバーって理由でブロックされないように説得しなきゃならない。これって私だけの感覚なのかな？それとも連合型の使い方を間違えてる？（でも、これってMastodonの特有の問題かも）

└

そうそう、だからTangledはActivityPub（Mastodonプロトコル）じゃなくて、ATprotoを選んだんだよね。このプロトコルはその問題を解決するために特別に作られてるから、個々のサーバーが中央集権的なAppViewsに集約されて、まるで中央集権ネットワークのように一つの統一された「ビュー」を提供するんだ。

└

ここでの魅力は、セルフホスティングもできるし、大きなプロバイダー間で移動することもできる点だと思う。フロントエンドのサーバーコストは非常に低く抑えられるから、基本的に永遠に運営できるし、他のホストから供給されるんだよね。

└

これはもっとMastodonの話だね。atprotoは、各サーバーがそれぞれ半分隔離されたゾーンのようには機能しない。これについてはよく説明されてるよ：https://atproto.com/articles/atproto-for-distsys-engineers

└

それが今まで私の経験そのものだったし、少なくとも私が今まで避けてきた理由でもある。でも数日前にこのプロジェクトを見て、「これなら実際にうまくいくかも」と思った。ここでの違いは、ターゲットオーディエンスが自己ホスティングサービスに慣れている社会の一部とかなり重なっていること。これが役立つためには、私の全ネットワークは必要なくて、実際に参加する可能性が高いそのサブセットだけで十分なんだ。

なんで？Gitリポジトリの連合の目的が全然見えないんだけど。Gitはすでに完全に分散型だし、99%のプロジェクトは少数のコミッターしかいない。Tangledは実際の問題を解決してるわけじゃないと思う。Githubが使われてるのは、コードを保存して共有するのが簡単で無料な場所だったからで、ソースビューもあってSourceForgeより一歩進んでたから。複数の解決策があってこれが簡単にできるなら、何かを連合する必要はないよ。Githubの一般ユーザーアカウント部分はそんなに重要じゃない。

└

GitHubにはgit部分だけじゃなくて、もっといろんな機能があるからね。イシューやPRとか。

もしatprotoのデータモデルに興味がある人がいたら、ここに紹介を書いたよ：https://overreacted.io/a-social-filesystem/ ちょっと長いけど、すごくわかりやすいと思う。

└

このブログ投稿がどれだけ好きだったかをシェアしたかっただけ :)

コメントにはネガティブな意見が多いけど、俺もVCファンディングには懐疑的だけど、この分野での競争は応援すべきだと思う。今の時点でそれを立ち上げるのは難しいし、ほぼ不可能だよね。昨日HNのトップに上がったGitHubを嫌う投稿とタイミングが良かったのは明らかだけど、ここでの試みは評価するよ。意味のある形で成功することを願ってる。

└

それを立ち上げるのは今の時点では難しいか不可能だ。 何が立ち上げが不可能だと示唆してるの？確かに難しいけど、それは名前からしても理解できるし、でも不可能？特に連合の方向を目指しているなら、もっと安価なインフラを構築できるはずだよ、同じかそれ以上のコストではなく。

フォージ連合はあまり良いアイデアじゃないと思う。もし分散型プロジェクト管理を目指すなら（gitはその目的のためにすでに分散型のVCSツールだし）、むしろgit-over-emailのワークフローを現代化した方がずっといいと思う。コードを分散させるのは問題じゃないし、サーバー間でリポジトリをクローンするのは標準的なことだから、どのフォージでも他のフォージからコードリポジトリをインポートできる。難しいのは、課題トラッカーやウィキ、MRなどの付随的なものだけど、それに対して連合プロトコルを使うのはスパムに対する保護がずっと弱いからあまり賢明じゃないと思う。メーリングリストにはスパム対策に関する豊富な実績があるし、ミラーリングやアーカイブの確立された方法もある。（ほとんどのgitウィキは、異なるレンダラーを使ったgitリポジトリに過ぎない。）git-over-emailを嫌がる主な理由は、設定が非常にユーザーフレンドリーじゃないからだと思う（現代のメールクライアントは通常、正しく設定されてないから）。これは最悪な形で開発者向けのワークフローだよ。メールの再フォーマットやメールアドレスの漏洩を防ぐようなことを自動で処理してくれる現代的なメーリングリストプログラムがあれば、もっと扱いやすくなると思う。

先に言っておくけど、私はatprotocolエコシステムにかなりアクティブに参加してるから、ちょっと偏った意見かもしれないけど、tangledの大ファンとしていくつかの考えをシェアしたいと思った。Tangledは本当に楽しんでる。GitHubの代替として今まで求めていたものが実現されていて、シンプルで機能はあまり多くないけど、個人のオープンソースプロジェクトで約1年間メインのソーシャル/gitプロバイダーとして使ってる（これが私のリンクね https://tangled.org/did:plc:rnpkyqnmsw4ipey6eotbdnnf）。私が使っているソーシャルメディア（Bluesky）からのソーシャルグラフがつながっていて、見たことのある顔や名前をコミットやPR、課題に結びつけられるのがいいね。ログインが他のサービスと同じなのも便利だし、最近は静的サイトのサポートも追加されたから、クライアントサイドのウェブサイトやシンプルなindex.htmlをgitリポジトリから直接ホスティングできるのがいい。Spindlesは彼らのビルドシステム/アクションで、nixファンじゃないけど、いろいろなニーズに応えてくれてる。共有スタンダード（atproto）に基づいて構築されたオープンAPIがあって、情報を簡単にレンダリングできるのも助かってる。ボットを作ったり、tangledのいろんな機能を使ってnpmx.devにいくつかの機能を追加したりしてる。自分のknot（gitサーバー）やrunner（spindles）を運営したり、彼らがホストしているものを簡単に使ったりできるけど、面白いのはソーシャル機能が別になっているから、別のgitサーバーを持っていても、課題やPRなどはその共有されたソーシャルレイヤーから来るってこと。会話に参加するためにアカウントを作る必要がないのがいいね。完璧ではないけど、ナビバーにアルファと書いてあって、時々そう感じることもある。いくつかの機能が足りないけど、全体的にはオープンソースの作業に使うのが本当に楽しいし、これからも使い続けると思う。