Radicle: 自律的なコードフォージ

 (radicle.xyz)
1 ポイント 投稿者 GN⁺ 2026-01-25 | 1件のコメント | WhatsAppで共有
  • Radicle は Git 上に構築された 分散型オープンソースコード協業ネットワーク であり、中央サーバーなしにピア間でリポジトリを直接複製・管理する
  • すべてのデータと ソーシャルアーティファクト は公開鍵暗号で署名され、真正性と作成者の検証 が可能
  • ユーザーは自分のノードを運用して 検閲耐性のある協業環境 を維持し、インターネット接続がなくても ローカルファースト(local-first) 方式で作業できる
  • Collaborative Objects(COBs) によって、イシュー、議論、コードレビューなどの協業機能を Git オブジェクトとして実装し、開発者が機能を自由に拡張できる
  • CLI、Web、TUI などの モジュール型構造 で構成されており、多様なクライアントの開発と置き換えが可能な 拡張性の高いコードフォージプラットフォーム である

概要(Synopsis)

  • Radicle は Git ベースのピアツーピアコード協業スタック であり、中央集権的なコードホスティングプラットフォームとは異なり、単一の支配主体を持たない
    • リポジトリはピア間で分散複製され、ユーザーが自分のデータとワークフローを完全に制御する
  • オープンソースとして提供され、MIT および Apache 2.0 ライセンス の下で自由に利用可能
  • 主要リポジトリは rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5 識別子を持つ

インストールと開始

  • インストールはシェルで次のコマンドにより可能:
    curl -sSLf https://radicle.xyz/install | sh
  • または ソースコード から直接ビルド可能
  • 現在は Linux, macOS, BSD 系 でのみ動作
  • Radicle Desktop クライアントを通じてグラフィカルな協業環境も提供

仕組み(How it works)

  • 暗号学的アイデンティティ体系 を用いて、コードおよびソーシャルデータの完全性と作成者認証を保証
  • Git を利用してピア間で効率的なデータ転送を実行
  • カスタムゴシッププロトコル を通じてリポジトリメタデータを交換

データセキュリティと永続性

  • すべてのソーシャルアーティファクトは Git に保存され、公開鍵暗号で署名 される
  • Radicle はデータの 真正性と作成者の身元 を自動検証する

自律性と検閲耐性

  • ユーザーが自分のノードを直接運用できるため、第三者に依存しない協業環境 を維持
  • ネットワークは 回復力が高く、検閲に強い構造 として設計されている

ローカルファースト(Local-first)

  • インターネット接続がなくても 常にアクセス可能な機能 を提供
  • ユーザーがデータの所有権を持ち、移動・バックアップ・アクセス が容易

拡張性と進化可能性

  • Collaborative Objects(COBs) によって、イシュー、議論、コードレビューなどの協業機能を Git オブジェクトとして実装
  • 開発者は COBs を拡張して 新しい協業フロー を構築可能

モジュール型設計(Modular by Design)

  • Radicle Stack は CLI、Web インターフェース、TUI で構成
    • これらは Radicle Node と HTTP Daemon によって支えられている
  • 各構成要素は置き換え可能で、別のクライアント開発 も可能

コミュニティと参加

  • Radicle は 自由・オープンソースソフトウェア であり、誰でもコードに貢献できる
  • コミュニティは Zulip、Mastodon、Bluesky、Twitter などで活動
  • フィードバックは feedback@radicle.xyz に送信可能で、自動的に Zulip の #feedback チャンネルへ投稿される

関連記事

1件のコメント

 
GN⁺ 2026-01-25
Hacker Newsのコメント

  • Radicleの紹介文が、セルフホスト型Gitとどう違うのか明確ではないと感じた
    GiteaやForgejoのような代替なら、Gitの上にどんな機能を追加しているのか簡単に説明したほうがよい

    • 紹介を読んだあとは、「チーム向けのlocal-first Git」のような印象を受けた
      メールパッチ共有の混乱なしに協業できるツールだと理解した
      GiteaやForgejoを知らないので、そうした比較はむしろ助けにならない
    • 既存の要約で十分よいと思う
      最初の文でGitを明示している点がわかりやすい
      一方でForgejoのランディングページはGitやソース管理への言及を避けていて、かえって混乱する
    • RadicleはGitHubの分散型代替である
      Forgejo/Gitea/GitLabのようにローカルホスティング機能を提供するが、P2Pネットワーク上で動作するため障害に強く、分散化された公開プロジェクトのホスティングが可能になる
    • AD: 私たちはオープンソースプロジェクトなので、提案やパッチを歓迎している
      どう書けばよりよくなるか、直接提案してもらえるとうれしい
    • ページを見た印象では、企業がコードにアクセスしなくてもチームで協業できる分散型GitHubのように見えた

  • 新しいソーシャルForgeを作ろうとする試みは歓迎したい
    こうしたプロジェクトがGitHubやGitLabに改善の圧力をかけるだけでも意味がある
    FAQを見ると、RadicleはGitの信頼の問題をPKIベースのアイデンティティシステムで解決しようとしている
    ただ結局のところ、「誰の身元を信頼するか」という問題はなお残ると感じる

    • AD: 各リポジトリはdelegateによる署名付きアイデンティティ文書で管理される
      現在はSSHキーと1対1で対応しているが、グループアイデンティティへ拡張中である
      完璧な解決策ではないが、暗号学的アイデンティティによって「一部からより大きな信頼へと広がる」構造を提供する
      結局のところ信頼は、人間関係のように社会的つながりを通じて分配される
    • 信頼は別のチャネルやコードレビューを通じて形成されるべきだ
      いったん信頼が生まれれば、同じDIDを持つ別のリポジトリを探せる
      複数の版がある場合は、信頼できる出所や活動が活発なリポジトリを選べばよい

  • 古いインターネットサービス（IRC、Gopherなど）を運用する小規模なsysadminグループと付き合う中で、P2Pシステムの削除不能性について考えさせられる
    誤って個人情報を上げてしまったり、法律の変更で問題になるコンテンツを投稿してしまったりしたとき、どうすべきか疑問だ
    ベラルーシのアマチュア無線家逮捕事例のように危険な状況もある
    こうした理由でP2Pが悪いと言いたいわけではないが、削除の問題はいまなお解決が難しい

    • 昔のUsenet投稿の大半も、今なお残っている
      GitHubでも秘密鍵を含むコードがアップロードされれば、すでに手遅れなことが多い
      P2Pが新しい問題を作るというより、既存の問題をそのまま露わにしているだけだ
    • 公開されたコンテンツは事実上永続的だという現実を認めるべきだ
      メールのように一定時間内であれば公開を取り消せる遅延公開機能があるとよい
    • AD: この問題は認識しており、デフォルト設定をより安全にする作業を進めている
      ネットワークレベルでのコンテンツ破棄機能も議論中だ
    • 中央集権型システムも完全に安全ではない
      運営者が削除可否を操作したり、政府に通報したりする可能性もある
      法的問題は結局、政治体制の公正さに左右される
    • 中央集権型サービスでもコンテンツはダウンロードできるのだから、完全な削除は不可能だ

  • Tangledとの違いを尋ねる質問

    • Radicleはlocal-firstアーキテクチャで、ユーザーが自分のノードを直接運用する
      すべての作業（Issue、パッチレビューなど）はローカルのデータストアで行われ、サーバーとの往復がない
      ネットワークが関与するのは同期時だけである
      一方TangledはAT Protocolベースの連合型構造で、実際には中央化されたサーバー（AppView）に依存している
      構造としてはクライアント・サーバー型である
    • Tangledは複数のGitサーバー（knots）間の通信をAT Protocolで仲介する
      Radicleにはサーバーという概念がなく、すべてのノードが対等である
      ただし一部のノードがHTTPサーバーとして動作し、ブラウザアクセスを助けることはある

  • FAQを見ると、Radicleは濫用・違法コンテンツについて各ノードが独自ポリシーで遮断できる
    また、信頼されたピア間のプライベートリポジトリをサポートしている
    データは暗号化されないが、選択的レプリケーションによりネットワーク全体へは露出しない
    FAQリンク

  • ホームページには公開リポジトリのインデックスにアクセスできるゲートウェイが必要だと感じる
    そうすればネットワーク全体を探索できる
    こうしたインデックスがあれば、GitHubを代替する潜在力がある

    • search.radicle.xyzで公開リポジトリを検索できる
      ただ、ホームページから明示的にリンクされているかはわからない

  • Radicleは本当に素晴らしいプロジェクトだ
    数か月にわたってノードを動かしているが、まだメインでは使っていない
    P2P ForgeこそWebの未来だと信じている

    • AD: 参加してくれてありがとう、私も寛容なシードノードを運用している
      参加そのものが投票だ
    • AD: メインで使っていない理由が気になる

  • GitHubでプロジェクトが停止されるたびに、「Radicleを使うべきだった」と思う
    Torの背後でノードを運用すれば、法的圧力も避けられる

    • 複数のネットワーク（Tor、i2p、clearnet、yggdrasilなど）に同時にノードを公開できるのか気になる
      過去には一部プロジェクトでこうした設定に問題があった

  • 寛容なシーダーが大容量バイナリアップロードからどう保護されるのか気になる
    すべてのIssueや議論が保存されるなら、リポジトリサイズが大きくなりすぎる可能性もある
    Gitのshallow cloneのような部分レプリケーション機能が必要に見える

  • Forgejo（ForgeFedプロトコル）との違いを尋ねる質問

    • Radicleは完全なP2P構造で、サーバーやインスタンスの概念がない
      各ノードは同じプロセスとして動作し、ユーザーアカウントは自己認証型（self-certifying）である
      一方ForgejoはActivityPubを通じてサーバー間通信を行う      連合型構造      である
      GitHub : Forgejo = Twitter : Mastodon、そしてファイル共有 : BitTorrent = ソフトウェア開発 : Radicle、という比喩ができる
      Radicleは中央サーバーではなく、プロジェクト単位の暗号学的ネームスペースで参照を管理する
      アクセス制御もサーバーではなくユーザーアイデンティティに基づいている