Tangled Code Forge: AT Protocol上での連合型Gitコラボレーション

分散型コードコラボレーション

Tangledは、GitHubやGitLabのような中央集権的なコードホスティングサービスの連合型代替プラットフォームとしての地位を確立しようとしています。AT Protocolを活用することで、Tangledは開発者が独自のコード、CIランナー、APIサーバーをホストしながら、統一された相互運用可能なネットワークの一部であり続けることを可能にします。このアプローチは、プロジェクトのデータ（イシュー、プルリクエスト、コメントなど）がポータブルであり、リポジトリ所有者の管理下にあることを保証することで、ベンダーロックインの問題を解決することを目的としています。

アーキテクチャの刷新とパフォーマンス

最新のリリースでは、グローバルなパフォーマンスを向上させるために大幅なアーキテクチャの変更が導入されました。以前のTangledは、バックエンドとUIの両方を処理するGoベースのモノリスに依存していました。新しいアーキテクチャでは、これらのコンポーネントが分離されています。

フロントエンド: エッジにデプロイされた新しいSvelteベースのフロントエンド。
インデクサー: bobbinと呼ばれるRustで書かれたディスクレスのインメモリインデクサーサービス。レイテンシを削減するために11以上のグローバルリージョンにデプロイされています。
Knot2: カスタムGitサーバーとSSHサーバーをバンドルした、Rustベースの書き直されたサーバー。リポジトリの主要なホストとして機能します。

コラボレーティブ・オブジェクト (COBs)

Tangledは、イシュー、プルリクエスト、コメント、リアクションがGitリポジトリ内に直接Collaborative Objects (COBs)として保存される新しいデータモデルを導入しました。これらのレコードはGitオブジェクトのチェーンとして保存され、プロジェクトのメタデータがソースコードと密接にリンクされることを保証します。データの整合性を確保し、不正な変更を防ぐために、システムはorg.tangled.graph.attestationレコードを使用しており、これによりKnotサーバーとユーザーのPersonal Data Server (PDS)間での双方向検証が可能になります。

組織とワークフローの更新

組織がAT Protocol上のファーストクラスのエンティティとしてサポートされるようになりました。各組織は独自のDIDとハンドルを取得し、委任されたパスワードレスのアクセス管理が可能になります。さらに、プラットフォームはプルリクエストフローを刷新し、GitユーザーとJujutsuユーザーの両方に対してスタック型PRをサポートしました。これには、バージョン間の変更をレビューするためのinterdiffサポートも含まれます。

コミュニティのフィードバックと議論

コミュニティはこのプロジェクトの目標に対して熱意を示していますが、初期のフィードバックでは改善が必要な領域や技術的な懸念がいくつか指摘されています。

UXの課題: 一部のユーザーは、UIは改善されたものの、明示的な「コメント」ボタンのような標準的なアフォーダンスが欠けており、コードレビュー中に混乱が生じると指摘しています。
連合の信頼性: 一般的な懸念として、セルフホストノードのダウンタイムが発見可能性に与える影響が挙げられます。コンテンツがインスタンス間で複製されることが多いActivityPubとは異なり、特定の「Knot」サーバーがオフラインになると、関連するコードやイシューが一時的にアクセス不能になる可能性があるとユーザーは指摘しています。
技術的なハードル: 初期のテスターからは、リポジトリのクローンやパスの検証に関する問題が報告されました。さらに、業界が徐々にSHA1から移行していることを踏まえ、SHA256 Gitリポジトリのサポートを求める声も上がっています。

プロトコルの選択に関して、一部のコミュニティメンバーはなぜActivityPubではなくAT Protocolが選ばれたのかを疑問視していますが、支持者は既存のAT Protocolエコシステムがソーシャルおよびコラボレーティブなデータのための強固な基盤を提供していると主張しています。