Tangled - atprotoベースのGitコラボレーションプラットフォーム

• Tangled は AT Protocol ベースの ソーシャル機能を備えたGitコラボレーションプラットフォーム であり、開発者がコードに対する完全な所有権を維持しつつ、オープンソースコミュニティが 自律的に運営 できるよう設計されている
• 既存の ActivityPub(Forgejo) 中心の連合型モデルと Radicle の完全P2Pモデルの長所を組み合わせた 分散型コードコラボレーション構造 を採用
• 中核概念である 「Knot」 は軽量なヘッドレスGitサーバーで、個人の セルフホスティング とコミュニティ単位の マルチテナント環境 の両方をサポート
• App View(tangled.sh) はネットワーク全体のリポジトリを統合ビューとして提供し、異なるKnot上にあるリポジトリを シームレスに探索・複製・貢献 できるようにする
• 現在はベータ段階で、データ所有権・低い参入障壁・ユーザー体験の維持 を中核原則とし、今後 完全公開型の分散Gitエコシステム の構築を目指している

---

Tangled の概要

• Tangled は、開発者がコードとアイデンティティの所有権を維持しながら 社会的相互作用が可能なGitコラボレーション環境 を提供する新しいプラットフォーム
• AT Protocol を基盤とし、分散型ソーシャルアプリのアーキテクチャをGitコラボレーションに適用している
• 目標は、コードコラボレーションを オープンで楽しいプロセス に取り戻すこと

分散モデルとAT Protocol

• 既存の分散型コードコラボレーションモデルには、次のようなアプローチがある
  • Forgejo(ActivityPub): サーバー間の連合(federation)によるコラボレーション
  • Radicle: 完全な P2P(peer-to-peer) 構造
• Tangled は両モデルの長所を組み合わせ、中央のID管理が可能な atproto を採用している
• これにより、ユーザーは分散ネットワーク内でも 一貫したIDと認証構造 を維持できる

Knot の構造

• Knot は Tangled の中核構成要素で、ユーザーが直接 Gitリポジトリをホスティング できるようにする軽量サーバー
  • シングルテナント構成またはマルチテナント構成 の両方をサポート
  • Raspberry Pi などの小型機器でもセルフホスティングが可能
• Tangled は基本的に 無料のマネージドKnotサービス を提供している
• この構造により、ユーザーの個人サーバーとコミュニティサーバーが自然につながる 分散Gitネットワーク が形成される

App View と統合ネットワーク

• tangled.sh で提供される App View は、ネットワーク全体のリポジトリをひとつの 統合ビュー として表示する役割を担う
• ユーザーは他のKnotにあるリポジトリでも、複製(clone) や 貢献(contribute) を容易に行える
• この設計により、Git の既存ワークフローをそのまま維持しつつ、分散型環境の障壁を取り除く ことができる

開発原則

• Tangled チームは開発方針として次の 3つの原則 を定めている
  • 1. データ所有権 — すべてのユーザーが、自分の作成したコードとメタデータを直接所有する
  • 2. 低い参入障壁 — 誰でも簡単に参加できるよう、シンプルな構造とインターフェースを提供する
  • 3. ユーザー体験の一貫性 — 分散構造であっても中央集権型サービス水準のUXを保証する
• これらの原則は、Tangled の技術的選択と UI/UX 設計全般に反映されている

アクセスとコミュニティ

• 初期は 招待制アクセス(invite-only) で運営され、開発者は #tangled IRC チャンネル(libera.chat)を通じて参加できた
• 現在は 公開ログイン開放 状態で、誰でも tangled.sh/login から利用可能
• Tangled はまだ初期段階だが、内部での自家利用(dogfooding)を通じて機能を検証しながら成長している

結論

• Tangled は、Git コラボレーションを ソーシャルネットワークのようにつながった体験 へと拡張しようとする試み
• 自律性、アクセスしやすさ、そして楽しい開発文化 を組み合わせた新しい 分散Gitプラットフォームのエコシステム として注目されている

[lamanus]

公式コンテナがないため、初期設定が少し面倒でした。

[GN⁺]

Hacker Newsの意見

• Tangledの共同創業者として、最近OAuthライブラリを置き換えた際に、新規ユーザーがデフォルトのknotおよびspindle（内部gitホスティングサーバーとCIランナー）に追加されない問題がありましたが、たった今修正パッチを適用しました。ログアウト後に再ログインすれば、正常にリポジトリを作成できます。質問があればいつでもお答えします。
  • 1つ目の質問は、tngl.sh PDSでハンドルを変更したりアカウントを削除したりできるかどうかです。2つ目は、AppViewを新しく作成して運用する際に必要なリソースについてです。たとえば、Cloudflare Pagesのように静的ウェブサイトのフォルダをアップロードしてそのまま配信する、PDSベースのAppViewを作った場合、AppView運営者が大量トラフィックのコストをすべて負担する必要があるのかが気になります。この構造で運用負担がどうなるのか知りたいです。
  • Tangledは“social-enabled”という表現を使っていましたが、ATプロトコルに関連しているように思います。今後Tangledでより多様なソーシャル機能を計画しているのか、それとも単にATプロトコル対応という意味なのか気になります。
• このプロジェクトは本当に素晴らしいと思います。既存のコードフォージサービスの独占的な構造を解体しようとする試みが気に入っています。私がこの分野に関心を持つ理由は、コードフォージが複数の問題を一度に解決しようとするあまり、かえって非効率だと感じるからです。ほとんどのフォージは、gitリポジトリ、ウェブビューア、協業ツール、CI/CDパイプライン、業務管理など、さまざまな機能をひとまとめにしています。しかし、こうした機能は必ずしも1つに束ねる必要はないと思います。たとえば、gitストレージに直接アクセスする必要がないなら、https://pgit.pico.shのような完全に静的なウェブビューアを提供したり、協業はパッチを分けてローカルでレビュー・管理する専用サーバー(https://pr.pico.sh)を別に用意したりできます。VPSにbare gitリポジトリだけを置いても十分で、しかもそれはとても簡単です。Gitはすでに分散システムなのに、別の付加サービスのために中央集権化されるのはアンチパターンだと思います。
  • 「Gitはすでに分散されている」と人はよく言いますが、実際には分散という概念には曖昧な部分があります。Git自体が分散に特化しているというより、通常はマスター・スレーブ型のプロトコル基盤（HTTPなど）なので、結局は中央集権化が繰り返される傾向があります。
  • サービスが複数ある場合、信頼の問題が生じます。80%の要件を満たす1つのサービスを検証するのか、それともそれぞれ別個に10個のサービスを検証するのか、考える必要があります。また、インフラにおける規模の経済や、複数機能を統合することで得られる利点も無視できません。だからこそ、今でもモノリシックな構成を好む人が多いのでしょう。そのぶん、開発者体験におけるトレードオフを考えさせられます。
  • VPSにgitリモートリポジトリを設定するのは本当に簡単です。sshでアクセスできればすぐに動きます。実際の核心的な問題は『lock-in』（サービス依存）だと思います。なぜGithubなどは、サービス提供そのものよりlock-inに注力するのでしょうか。その背後には資金調達とビジネスモデルがあります。中央集権化→lock-in→収益という連鎖は、多くのサービスで繰り返し現れます。もしサービスそのもので収益を上げる構造がなければ、こうした現象は避けられないのだと感じました。
  • 技術的に機能分離が不可能というわけではありませんが、経済性（各機能が個別に維持されるだけの収益構造にならない）と、使い勝手（人々は「全部入り」の便利さを求める）という問題もあります。オープンソースも同様で、経済性を無視する例は多いものの、結局その多くは1人のメンテナーが燃え尽きて消えていきます。最も成功したオープンソースプロジェクトでさえ、たいていは企業スポンサーやエンジニアの支援によって成り立っています。
  • 分離する必要はないとしても、やはり統合されているほうがずっと便利です。
• 最近Jujutsu対応の知らせをJJ Conで知りました。関連内容はhttps://blog.tangled.org/stackingで確認できます。
  • このサービスは実際にstacked PRをサポートしています。Githubは何十年もこれを実現できていません。もし社内でプライベートに使う必要があるなら、Tangledインスタンスが外部ネットワークに接続されないようにする設定方法がはっきりしないのは残念です。
• Githubはもはや信頼できないと思います。少なくともOSSスタックだけでもATプロトコルや他のオープンネットワークへ移すことは、大企業や検閲などのリスクから守る良い方法だと思います。こうした試みは歓迎です。
  • ただし、ほとんどの人は自分でサーバーを運用したがりません。大規模なOSS団体くらいしか担えないでしょう。しかも、メール以外ではPRすら提供しにくい状況です。
• tangledに登録した最初の100人のうちの1人です。stacked patch方式のPRレビューのロードマップと機能改善の速度が印象的で、コミュニティの熱気にも前向きなエネルギーを感じました。今後どう発展していくのかとても楽しみです。このやり方で着実に進んでいけば、はるかに良い体験と根本的なコントロール、長期的な持続可能性も実現できると思います。
• より分散したgit協業のやり方に強い関心があります。こうした方式が広まるうえで最大の障害は何だと考えていますか。サーバー運用や秘密鍵管理、それとも結局はネットワーク効果なのか、意見を聞きたいです。
  • 最大の障壁はスパム、違法コンテンツ、全般的なモデレーションの問題です。PDSが任意のドメインになり得て、1つのPDSが無制限のユーザーを収容できるという点で、信頼が崩れる体験が多くあります。人々がgitリポジトリにebookやテレビ番組を大量にアップロードしたらどうするのか、あるいはプロジェクトが政治的な争点のためにスパム攻撃を受けた場合にも、解決策を考えなければなりません。AppViewという概念の良い点は、BlueSkyのように中央モデレーションチームが一貫したポリシーを適用できることです。各自が何でも投稿できたとしても、最終的にはフロントエンドで選択的にキュレーションできます。しかし、中央モデレーションの判断も常に論争の的です。これが、完全に分散したネットワークの負担と責任を引き受けたくない理由です。ATプロトコルの開放性はTwitterのようなサービスと比べて利点ですが、その代わりに日常的な管理や権限付与が集中した仕組みも必要です。個人的には今、「寛容な」radicle seed node（匿名gitアップロードを許可するもの）の運営を志願する人がいるのか気になります。
  • Githubは無料で、分散化にはコストがかかります。
  • Tangledは自分でサーバーを運用しなくてもgitを独立して使えるので、とても満足しています。最大の欠点は、まだあまりにも新しいサービスだということです。まだ一般的な認知度がなく、BskyやPDSが何を提供するのか知らない人も多いです。もう少し多くの機能やalternate clientがあるとよいと思います。それでも、初期ユーザーはすでに十分に良い体験を得ていると思います。より多くの開発者がこの体験に出会える日を待っています。
• CIパイプライン対応があるのはうれしかったですが、見た目がGitHub Actionsに似ているようで残念でした。単純な逐次実行のためにわざわざYAMLを使う必要はないと思います。bash scriptで十分です。パイプラインYAMLは、プログラムの流れではなく依存関係（DAG）を表現するときに意味があると考えています。Buildkiteはこの点ではるかに優れています。
• 明日には「Spaghetti」という名前のノーコードビジネスプラットフォームと、「Lock-in」という重要データ保管庫サービスが登場する予定です。
• 会社でやむを得ずGitHubのパブリックorgを使わなければならない状況です。コードレビュー（CR）はtangledで行い、その後GitHubと同期することは可能でしょうか。jjツールのレビュー体験をそのまま活かせるのか気になります。
  • ミラーリングできますし、マージ時にGithubへpushするspindle pipelineも作れます。参考文書: https://tangled.org/@tangled.org/core/blob/master/docs/spindle/pipeline.md
• エンタープライズ／プライベート用途でTangledを導入できるのか気になります。stacked diffレビューのフローは企業業務に非常によく合っているように見えます。
  • 可能性はあります。完全にairgappedでATから分離されたTangledバージョンについて議論中です。かなり大きな作業なので、すぐに進めるのは難しいです。
  • 現時点では、専用の企業向けソリューションが明確に存在する状態ではありません。関連するイシューの議論はhttps://tangled.org/@tangled.org/core/issues/60で見られます。