- Radicle Heartwoodは Radicle Protocol の3番目の実装であり、中央集権型のコードフォージに依存しない、ピアツーピア方式のコード共同作業・公開スタックを提供する
- リポジトリには、開発者が直接使うコマンドラインツール
rad とネットワークデーモン radicle-node が含まれる
- GitHub・GitLab のようなコードフォージを置き換えることを目指した設計で、セキュリティと分散化、ユーザー主権の維持を中核目標としている
- インストール環境は Linux または Unix 系OS、Git 2.34 以上、
ssh-agent を含む OpenSSH 9.1 以上が必要
- バイナリインストールと Rust ソースからのインストールの両方に対応するが、フィードバックメールは公開 Zulip チャンネルに自動投稿され、名前とメールアドレスが公開される可能性がある
Radicle Heartwood が提供するもの
- Heartwoodは Radicle Protocol の3番目のイテレーションであり、ピアツーピアのコード共同作業と公開のためのフルスタックである
- リポジトリには Heartwood 実装に必要な主要コンポーネントが含まれる
rad: ユーザーフレンドリーなコマンドラインインターフェースradicle-node: ネットワークデーモン
- Radicle は GitHub や GitLab のようなコードフォージの代替として設計されている
- 目標はセキュリティ、分散化、ユーザー主権と自由の維持である
- 一般情報は Radicle home page で確認できる
- プロジェクトに関する会話は Zulip chat で可能
- Radicle の動作方式は Protocol Guide に詳しくまとめられている
インストールと実行
- インストール要件は次のとおり
- Linux または Unix ベースのOS
-
Git 2.34 以上
ssh-agent を含む OpenSSH 9.1 以上- バイナリインストールには
curl と tar が必要で、最新リリースは次のコマンドでインストールする
curl -sSf https://radicle.dev/install | sh
- バイナリは [download](https://radicle.dev/download) ページからも入手できる
- ソースからインストールするには **Rust ツールチェーン**が必要で、リポジトリ内で次のコマンドを実行する
cargo install --path crates/radicle-cli --force --locked --root ~/.radicle
cargo install --path crates/radicle-node --force --locked --root ~/.radicle
cargo install --path crates/radicle-remote-helper --force --locked --root ~/.radicle
- seed node から直接インストールすることもできる
cargo install --force --locked --root ~/.radicle \
--git https://seed.radicle.dev/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \
crates/radicle-cli crates/radicle-node crates/radicle-remote-helper
- ノード用の **systemd unit** ファイルは `/systemd` フォルダにあり、追加カスタマイズの出発点として利用できる
- デバッグモードでの実行は [HACKING.md](https://radicle.network/nodes/iris.radicle.network/rad%3Az3gqcJUoA1n9HaHKufZs5FCSGazv5/tree/HACKING.md) を参照する
フィードバック、コントリビューション、ライセンス
1件のコメント
Hacker Newsの意見
Radicleの共同創業者です。プロトコルの内部動作が気になるなら、まずドキュメントを見るとよいです: https://docs.radicle.xyz/
ドキュメントはまだ作成中です
基本的にP2Pファイル共有アプリだとすれば、悪用はプロトコルのどの部分で扱われるのかが気になります。そうでなければ、映画・音楽・ソフトウェアのような著作権コンテンツを任意に共有していたBitTorrentやWinnyのような前世代のファイル共有アプリと何が違うのか分かりません。少数の悪意ある利用者が台無しにしそうですし、違法なものに関与していないと確信できるように「個人」ネットワークを分離できるのかも気になります
Crunchbaseに1,200万ドルの投資を受けたと載っているので、収益化計画があるのだと思います
私が支援している種類のプロジェクトでは、これは致命的になり得ます。コードはRustに見えますが、MS Windows対応の計画があるのか気になります。Mac OSはUnix系に含まれると見てよいのでしょうか？ 正式なWindows対応でなくても、MSYS2への移植は可能なのか気になります。
背景を少し付け加えると、私はサービスプロバイダーの選定のような決定を下す立場ではなく、GitHubにかなり大きなオープンソースのコードベースを置いている準政府組織に関わっています。ときどき特定のアイデアを提案する機会はありますが、採用するかどうかは私の権限ではありません。この組織は民間プロバイダーの方針に左右されないレジリエンスを備え、持続可能性や幅広いアクセス性といった「良いこと」も実現しようとする動機が大きいです。典型的な欧州の政府組織なので、GitHubはそうした方針と衝突します。
アーカイブやネットワーク支援を担当する別の政府機関もありますが、能力が不足していたり古い方式にとどまっていたりして、プロバイダーが仕掛けた罠にもよくはまります。例えばアーカイブサービスが、DataBricksが商用のクローズドソース製品であることも知らないまま全面採用しました。そのため、その組織がセルフホスティングの解決策をうまく活用するという期待は低く、分散型の解決策が良さそうに見えます。ただし、主要な一般PC環境で動作しないツールは使えません
また、以前と現在それぞれでどの程度の採用を予想していたのか、実際の結果がその期待に合っていたのかも気になります
Radicleがここ5年ほどでどのように進化してきたのかを見守るのは興味深かったです。Protocol Berg 2023のワークショップに参加しましたが、かなり強力で新しいものを作ったと思います。
特に興味深いのは、コラボレーション機能までローカルファーストである点です。インターネットがなくてもパッチやIssueを提出でき、GitHubに問題が起きるたびにチーム全体がHNに張り付く必要がなくなります
目的に対してはよさそうなプロジェクトに見えますが、Git自体もすでにオープンソースでありP2Pだと思います。バイナリを
sh <(curl)で受け取る必要はなく、別のGitサーバーに接続してGitコマンドで直接コードを取得したりマージしたりすればよいです。Gitにないのは、コードのIssue、Wiki、議論、GitHub Pages、そして何より開発者プロフィールのネットワークです。ソースコードのコミットがWikiやIssueと混ざらないように、プロジェクトのメタデータを
.git自体に入れる方法が必要です。git notesのような独立した参照が使えるかもしれません。https://git-scm.com/docs/git-notes
例えば、
git cloneで取得したリポジトリが自分の要求したリポジトリであることを検証する方法がありません。そのため、信頼する出所、つまり既知のサーバーからクローンする必要があります。これは実用的なP2Pとは相性がよくありません。Radicleはローカルで検証可能な安定したリポジトリ識別子[0]を付与することでこの問題を解決し、信頼していない主体がリポジトリを提供できるようにします。
[0]: https://docs.radicle.xyz/guides/protocol#trust-through-self-...
モバイルでは、元リンク下部のボタンを押すとIssueトラッキングのタブやプルリクエストのタブなどを見られます
Gerritは以前、コードレビューをGitに保存していたと記憶しています
ドキュメントには「自分が所有している、またはメンテナーであるリポジトリだけを公開し、他のメンテナーと連絡を取って重複するリポジトリ識別子を作らないようにすることが重要」と書かれている
自分のコードを持っていって GitHub に上げる人たちを見てきたし、製品ドキュメントや途中の UI に「どうか X はしないでください。他のユーザーに問題が起きます」という案内を入れても、誰も読まず、考えず、気にもせず、すぐに X をする場面を何度も見てきた。だから多くの人はドキュメントのこの依頼を守らないだろうと思うし、そもそもホームページはコードをプッシュする方法だけを説明していて、この「重要な」依頼は、ほとんど読まれないユーザーガイドにある
結局、ホームページの指示に従って作業中のオープンソースコードをそのままプッシュするという一見合理的な行動が、プロトコルと保存方式の性質上、時間がたつにつれて何か重要なものを乱したり混乱させたりし得る点がかなり気になる
GitHub ではスター数で追加の信頼を得られるし、Radicle でそれに相当するのは特定リポジトリのシード数だ
普通、1 日のコンピューティング中に目にする案内は何十個もあり、使うツールも何十個もある。その案内をすべて読み、すべてのツールのドキュメントを丁寧に読むのにかかる時間を考えると、あまりにも長い
だから読まずにヒューリスティックを使うほうがずっといい。例えば、保存していない変更がある文書を閉じると、ダイアログは「破棄しますか？」だと分かっているので読む必要がない。これは良いことだ
結論としては、人々がこのように行動するという事実を前提にソフトウェアを設計すべきだということ。たいていは可能だ。具体的な例があれば、「お願いして読んでくれることを期待する」方式より良い解決策を提案できると思う
リリースおめでとう。このプロジェクトを追ってきたが、かなり成熟してきた様子で本当に楽しみだ。現在 GitHub にあるプロジェクトは、どう移行するのが一番よいのか気になる。試せるミラーモードがあるのかも気になる
cronジョブを設定するだけで済むくらい単純なはずだgit pull github mastergit push rad master一般ユーザーにとって、これらのリポジトリがどれほど発見可能なのか気になる。https://app.radicle.xyz/robots.txt はないようなので、検索エンジンが取得してよい状態のようだし、実際に Google と DDG で
site:app.radicle.xyzと検索すると結果が出るまだサイト指定なしで上位に出るわけではないが、順位は改善するかもしれない
CI サポートと統合するツールもあるとよい。究極的には
while true; do wait_repo_update; git pull && ./run_ci.sh; doneのようなループになるだろうが、信頼した識別子からのプッシュだけに制限できる、より良い形が必要だ最後に、成果物リポジトリも必要だ。ただし Radicle がすべてを解決する必要はないのかもしれない。特に大きなバイナリを共有する分散ネットワークは、かなり早く望ましくない用途に使われそうだ
app.radicle.xyzのようなゲートウェイは、クローラーがネットワーク上のリポジトリ全体をインデックスできるようにすべきだと思う「P2P」またはより一般的に言う「分散」が正確に何を意味するのか、人々が明確に定義してくれるとよい。今ではあまりにも曖昧なバズワードになっていて、何にでも使えてしまう
したがって P2P システムとは、すべての参加者が「ネットワーク内で同等の権限」を持つシステムだ。通常は全員が同じソフトウェアを実行しているという意味でもある
[0]: https://en.wikipedia.org/wiki/Peer-to-peer
インストール案内が
curl -sSf [https://radicle.xyz/install](<https://radicle.xyz/install>;) | shだなんて、期待が一瞬で curl-bash のゴミに打ち砕かれたこういうインストール方式は、何も考えていない開発の強いシグナルだ。このプロジェクトが流行ったら、セキュリティ上の惨事が起きるのを目にすることになりそう。いつか、最悪のインストール方式から始まらない「オープンソースのP2P GitHub代替」が出てくることを願う
パイプで渡すインストーラーのリスクは、多くの人がよく理解している。その理屈なら、Homebrew [1]（GitHubのスター3.8万個以上）、PiHole [2]（4.6万個以上）、Chef [3]、RVM [4]、そして
bashにパイプする1ステップの自動インストーラーを使っている無数のオープンソースプロジェクトを捨てなければならないより合理的な対応は、開発者と協力してドキュメントに代替インストール方法を用意してもらうか、リスクをより適切に説明してもらうことであって、ノミを取るために家を焼くようなやり方ではない
[1] https://brew.sh/
[2] https://github.com/pi-hole/pi-hole
[3] https://docs.chef.io/chef_install_script/#run-the-install-sc...
[4] https://rvm.io/rvm/install
転送が中断される問題については、システムに
^(t(e(m(p(d(ir?)?)?)?)?|a(r(g(et?)?)?)?)?|i(n(_(p(a(th?)?)?)?|fo?)?)?|s(u(c(c(e(s?s)?)?)?)?)?|f(a(t(al?)?)?)?|m(a(in?)?)?|w(a(rn?)?)?|u(rl?)?)に一致する危険なコマンドがある場合でなければ、スクリプトは安全だそれを処理した後では、スクリプトだけを提供して実行コマンドは提供しない場合と何が違うのかと思う。確認したいなら、スクリプトをダウンロードして別途実行すればいい。パイプされたスクリプトとダウンロードされたスクリプトを検出する方法があった気がするが、こういう小さなスクリプトでは動作しないだろう
[0] https://files.radicle.xyz/latest/
[1] https://app.radicle.xyz/nodes/seed.radicle.garden/rad:z3gqcJ...
暗号資産市場が上がるたびにRadicleの話を聞く気がする。真面目に使っている人はいるのか？
これはあっという間にダウンボートされたな。真面目に聞いているのだが、Radicleにどれくらいの予算が投入され、何人が作業し、誰が使っているのか知りたい
暗号資産業界で働いているが、自分も同じ印象を持った。Radicleの話を最後に聞いたのは前回の強気相場で、弱気相場では静かだった。みんな 弱気相場は作るための時間 だと言うし、Radicleは明らかに開発者ツールなのに、かなり奇妙だ
特定のノード集合にだけリポジトリを提供するユースケースをサポートする予定があるのか気になる。GitHubには置きたくないが、非公開の共同作業 はしたい人たちがいそうだ
ただし保存時に暗号化されているわけではないので、信頼集合に属さない中間ノードに保存することはできない