ハクソク

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

Iroh: ピア間の直接接続を確立するためのライブラリ

334日前原文(github.com)

概要

iroh は、公開鍵でダイヤルできるAPIを提供するネットワーク接続ライブラリ。 QUIC プロトコルを活用し、高速かつ安全な通信を実現。 ホールパンチング やリレーサーバーで、どこからでも最速経路を維持。 Rustライブラリ として簡単に導入可能。 複数のプロトコルを組み合わせて柔軟なネットワーク構築が可能。

irohとは何か

  • iroh は、公開鍵を使ってノード間接続を簡単に実現するAPI
  • 「その電話につないで」と指定するだけで、 最速の通信経路 を自動確立
  • ノードの所在地に関係なく、 最速の接続 を維持する設計

ホールパンチングとリレー

  • 最速経路は 直接接続 であり、必要に応じて ホールパンチング を試行
  • 直接接続が失敗した場合、 公開リレーサーバー に自動でフォールバック
  • 常に 通信速度を計測 し、最適な経路を選択

QUICベースの設計

  • Quinn ライブラリを利用し、 QUIC プロトコルでノード間通信を確立
  • 認証付き暗号化、 並列ストリーム、ストリーム優先度、 ヘッドオブラインブロッキング回避 などを標準サポート
  • データグラム転送 にも対応

プロトコルの組み合わせ

  • 独自プロトコルを作る必要なく、 既存プロトコル を利用可能
    • iroh-blobs ：BLAKE3ベースのコンテンツアドレス化されたblob転送（KB〜TB対応）
    • iroh-gossip ：スマートフォンでも動作するスケーラブルなPub/Subオーバーレイネットワーク
    • iroh-docs ：iroh-blobsを使った最終的整合性を持つKey-Valueストア
    • iroh-willow ：Willowプロトコル実装（開発中）

Rustによる導入手順

  • Rust からの利用が最も簡単で、 cargo add iroh でインストール可能
  • 接続側サンプルコード
    • Endpoint 作成・バインド
    • 接続確立 とバイディレクショナルQUICストリームのオープン
    • データ送信・受信・接続終了
  • 受信側サンプルコード
    • Router 作成・ALPNプロトコル受け入れ
    • Echoプロトコル の定義と実装
  • 詳細なサンプルコードは echo.rs にて提供

他言語からの利用

  • 他言語から利用したい場合、 iroh-ffi （FFIバインディング用リポジトリ）を参照

リンク・ドキュメント

  • Introducing Iroh（動画）
  • Iroh Documentation
  • Iroh Examples
  • Iroh Experiments

リポジトリ構成

  • iroh ：ホールパンチ・リレー通信のコアライブラリ
  • iroh-relay ：リレーサーバー実装（本番運用・自分でも運用可能）
  • iroh-base ：Hashや鍵型、RelayUrlなど共通型
  • iroh-dns-server ：NodeId用n0_discoveryを提供するDNSサーバー
  • iroh-net-report ：ホストのネットワーク能力やNAT解析

ライセンスと貢献

  • Apache License 2.0 または MIT License のデュアルライセンス
  • 貢献内容は特別な記載がない限り、両ライセンスで提供される方針

Hackerたちの意見

あなたに対して怒ってたわけじゃないよ。悲しかったんだ、あなたが道を見失ったんじゃないかって怖かったから。

└

魅力的な見知らぬ人とお茶を分け合うのは、人生の本当の喜びの一つだね。

└

これで今日が良い日になった！

└

失敗は再スタートのチャンスだよ。ただし、今回はもっと賢くね。

└

これ見るたびに泣いちゃう。

└

これ、世界で最も完璧なコメントかも。ブラボー！

└

これを求めて来た。ありがとう！

irohはすごくクールだし、YouTubeの解説もかなり良いよね: https://youtube.com/@n0computer 今は良いFFIが必要なんだけど、それはロードマップにあるみたい！

└

GoやPythonで使えるようになるのが待ちきれないよ :)

しばらく前にirohのワークショップに参加したんだけど、すごく楽しかったよ。Discordサーバーを見る限り、開発してる人たちは1.0リリースに向けて準備してるみたい。Dumb PipeやSendMeもデモ（だと思う）で、irohのいくつかの使い方を紹介してるんだ。ワークショップでは、irohを使ってゲームストリーミングをしているスタートアップの動画も見せてもらったよ（昔のOnLiveみたいな感じ）。私のネットワーキングの知識が乏しいけど、理解した限りでは、クライアントは同じリレーにいる必要があるみたい（ヨーロッパ用と北アメリカ用があると思う）。発見にはBittorrent DHT Mainlineを使ってるみたいで、正確な名前を忘れちゃったからirohのブログをググったよ。BGPについても少し話があったけど、残念ながら理解できなかった。もっと詳しい人が参加してくれるといいな。irohは本当にワクワクするし、p2pアプリケーションを作るのも難しくなさそうだよ。

└

（開示: 私はirohに関わってる）: 自分を過小評価してるよ！これ全部正確だけど、BGPの部分はちょっと違うかも :) Dumb PipeとSendMeは確かにデモだし、無料で使えるデフォルトの公開リレーも提供してるよ。リレーのコードもオープンソースだし、もしお金を払ってくれればネットワークを運営することもできるよ。発見のためにいくつかの選択肢を提供しようとしていて、一般的に便利だと思うのはカスタムDNSサーバーだけど、ローカルmDNSやBittorrent Mainlineもプラグイン可能なオプションだよ。

└

ワークショップは録画されてたの？

これに関わってるよ！何でも聞いて！

└

これって、古い生のUDPマルチプレイヤーゲームをランダムな見知らぬ人と遊ぶためのアダプターとして使えるようにできる？例えば、Twitchチャットで「兄弟、CS1.6で1v1しよう、これが私のIrohチケットだよ」と言って、相手がそれを「InstaFrag NetDriver」のWindowsクライアントに入れて、二人でCS1.6を立ち上げて即席のp2pロビーで遊び始めるみたいな。Tailscaleだとこの使い方はすごく面倒で、相手をtailnetに追加してアクセス制御を設定しないといけないから、一時的な接続にするのが大変なんだよね。

└

鍵には定義されたプレフィックスや識別子があるの？例えば、Veilidはvld0を使ってるけど、pkarrはpk:?を使ってるよね。

Irohは面白いね。Dumbpipeは魔法みたいで、実装もわかりやすい。毎日dumbpipeを使って、別のサーバーで動かしてるcross-streamのストアをローカルのノートパソコンのxsクライアントに見せてるよ。

└

ちょっと話がそれるけど、xsの使い方ってどうしてる？ウェブサイトを読んで、なんとなく理解できた気がするし、面白そうだなと思ったんだけど、実際に何に使うのかはよく分からないんだよね。

これ、Rustで書かれてるんだ。CANトランスポートを使ってRust（Embassy）で組み込みシステムで使いたかったんだけど、残念ながらno_std版もCANプラグインもないんだよね。まあ、見た目はいい感じだけど。

└

うん、no_stdはかなり難しそうだね。まずは普通の人でも使えるQUICのno_std実装が必要なんだけど、それに着手できるのは少なくとも1年後だと思う。今のところ、ESP32に落とし込むことができそうで、これがいいスタートだと思ってる。

└

これがあればすごくいいけど、quicに依存してるから、まずはno_stdのquic実装が必要なんだ。これが今の最大の課題だね。

数年前、"iroh"はipfsの代替になる予定だったんだ。でもそれ以来、彼らは（個人的には賢いと思うけど）その野望を捨てて、P2Pアプリを書く人たちのための高品質なライブラリに集中してるんだよね。プロジェクトがあらゆる問題を解決するユニバーサルツールを目指そうとするのをよく見るけど、irohの人たちはスケールダウンして焦点を絞ったのは賢明だったと思う。

└

フィードバックありがとう。決断するのは大変だったけど、あれから毎日正しかったって感じてるよ。

connetで働いてるんだけど、irohは結構クールに見えるよ。プレゼンを見たりドキュメントを読んだりして思ったことをいくつか挙げるね。* リレーは発見とリレーの両方に使われるんだ。connetではこれが別々の役割になってて、発見用のコントロールサーバーと接続を中継するためのリレーサーバーがある。* irohのリレーへの接続はTCPっぽい（少なくとも動画の一つでそう言ってた）、でもconnetは全てのケースでQUICを使ってる。これでirohは耐障害性が高くなるかもしれないけど、TCPの上での多重化は先頭のラインブロッキングに悩まされるかも。* irohがリレーから直接接続にシームレスにアップグレードできるのはすごいね。connetは接続レベルではそれをやってないけど、次の仮想接続では直接接続を使うよ。* プロトコル選択にALPNを使うのはいいアイデアだね。connetは「仮想接続」プロトコルしか提供してなくて、一方のピアが「サーバー」で、もう一方が「クライアント」って感じ。* 別の発見サーバー（認証付き）があるから、connetではエンドポイントが論理名で別々に名前付けされてて、必ずしもピアを表してるわけじゃない。だから「サーバー」役と「クライアント」役のピアを複数持つことができるんだ。とにかく、これを投稿してくれてありがとう。irohは素晴らしいし、インスピレーションをもらえること間違いなしだね。[1] https://github.com/connet-dev/connet

└

「リレーは発見と中継の両方に使われる。Connetでは、これらは別々の役割だ。例えば、発見用のコントロールサーバーと接続を中継するためのリレーサーバーがある。この2つの戦略の相対的な利点と欠点は何？」

これ、libP2Pと比べてどうなの？ https://libp2p.io/

└

設定が少なくて、信頼性が高い。純粋なp2pではない（irohはリレーを使ってる）。

Syncthingみたいなピア発見の機能がずっと欲しかったんだよね、こういうの。低レベルな言語で書かれてるのが残念。