Iroh 1.0 - IPではなくキーで接続 - 任意のデバイス接続向けネットワーキングライブラリ
(iroh.computer)- Iroh 1.0 は最初の安定リリースであり、wire protocol と言語 API の安定性を保証することで、iroh v1 endpoint 同士なら minor version や言語に関係なく通信可能
- Rust crate に加えて Python, Node.js, Swift, Kotlin を公式サポートし、Swift の iOS アプリケーションや Kotlin の Android アプリに iroh を組み込める
- wire の安定性に影響する変更は常に major release とともに発生し、今後は言語 API バージョンと wire 互換性を独立してバージョン管理できる可能性がある
- 1.0 以降の major および minor version は サポートスケジュール に従ってサポートされ、0.35 minor version は追加リリースを受けない
- Public relay サポートは v1.0 が End of Life まで、v0.35x は 2026年12月31日まで、v0.9x と v1.0.0-rcX は 2026年9月30日まで運用される
- public relay は各リリース直後、通常24時間以内に最新バージョンへ更新され、wire-breaking な relay 変更では既存クライアントが継続動作できるよう新しい URL を使用する
- 接続機能には QUIC multipath、QUIC NAT traversal、local-first 構成、WASM およびブラウザ実行、接続制御 hook、custom transport サポートが含まれる
- 接続ではデータの95%がデバイス間で直接転送されるのが一般的で、直接接続はクラウド経由の hop と egress コストを削減するという説明 {p:95}
- public relay の relayed traffic には rate limit があり、この制限はいつでも変更される可能性がある
2件のコメント
Hacker Newsのコメント
Irohを初めて見るなら、だいたい ネットワーク層ではなくアプリケーション層のTailscale と考えるとよい
「じゃあTailscaleを使えばいいのでは？」という話は、アプリ開発者の視点だと少し違う。アプリのインスタンス同士を簡単につなげるには、理論上はTailscaleの機能をアプリに組み込めるが、そうするとユーザーにTailscaleアカウントが必要になり、アプリもTailscaleに依存することになる
Irohならこの機能を直接組み込めて、公開の予備リレーも提供される。アプリが公開リレーでは支えきれないほど大きくなったら、自前のリレーへ切り替えるのもほぼスイッチ一つで済む
特にIrohが正しいやり方をこんなに簡単かつ優れた形で実現してくれるならなおさらだ
ユーザーがローカルインスタンスにアクセスする必要がある環境では、Irohは ゲームチェンジャー になり得ると思う。私たちにとっては、スマートフォンや他のデバイスからソフトウェアを簡単に操作できるようにする用途だ
以前なら同じLAN上にいることを確認する必要があったかもしれないが、Irohを使えばどんな環境でも動作する
IrohとOpenZitiはどちらもアプリに組み込めるし、サービスに組み込みたいアプリ開発者にとってどちらも有力なユースケースになる
OpenZitiは規模とセキュリティが重要なサービスで使われ、Irohは事前の関係がない参加者でも参加できるようにするため、非常に便利になり得る
Iroh開発者の一人です
よくある質問として、IrohがいつWebRTC、BLE、LoRaなどをサポートするのか、というものがある
現在のIrohは、デフォルトではIPv4、IPv6、リレー転送のみをサポートしている。興味深い転送方式は多すぎるので、全部をサポートしようとするとコードベースが保守不可能な機能フラグの迷路になってしまう
その代わり、カスタムトランスポート を実装できるようにしてあり、トランスポート実装は完全に別クレートに置ける
既存の実験的なカスタムトランスポートにはTor、Nym、BLEがある。https://github.com/mcginty/iroh-ble-transport
内部でどう動いているかはここで見られる: https://www.iroh.computer/blog/iroh-0-97-0-custom-transports...
これでP2Pのクライアント/サーバー構成や2つのピアマシンを作る場合、2つのアプリケーション間接続のために追加で何を設定する必要があるのか、その限界が気になる
たとえばスマートフォンで動くアプリとノートPCで動くアプリを作ったとして、その間に直接的で安全な接続を実際に得られるのか、それとも別の問題を解いているのかを知りたい
-[0]: p2p chat, in rust, from scratch: https://www.youtube.com/watch?v=ogN_mBkWu7o
去年はどちらかを選ぶ際に慣れているほうを選んだが、今は Irohのほうに明確な勢い があるように感じる
ここではTorデーモンを使っている。TorにはRust実装があり、Rustから使うとストリームオブジェクトのような形で利用できる
使用例は https://gitlab.torproject.org/tpo/core/oniux で見られる
ストラテジーパターンと集中管理された機能管理がよい
「Dial keys」が動画内に出ていたのかは分からないが、最初の段落でそれがどんな種類のキーで、なぜ必要なのかを明確にすべきだと思う。
暗号学的キーなのか、非対称鍵なのか、少なくとも最も基本的なレベルでどう動くのかの説明がない。いきなり抽象的な優位性の主張と利用統計に入っている。
リレーが関係しているようだが、HNの議論を掘って見つけさせるのではなく、最初から書いておいたほうがよい。
まず https://docs.iroh.computer/what-is-iroh があり、その後に仕組みのセクションがある。今のところ見る限り、ドキュメントは実際かなり良く、出てきた質問にもかなり素早く答えているようだ。
分散型かもしれないし、無料かもしれないし、単一体ではないかもしれないが、大きく見れば同じカテゴリーだ。
.ssh/configの名前付きホストのように、キーでアクセスする「名前」だと思った。だが、さらに読むと、QUIC上でネットワーキングする新しい方法のように聞こえる。
専門家ではなく、今日初めて見たプロジェクトだという点を踏まえたLobste.rsでの要約はこうだ。これは、クライアントに永続IDを割り当てる、強い意見を持ったWebRTCセットアップに近い。シグナリングサーバーを作る作業は処理済みで、解決策は十分に汎用的かつ低コストなので、コミュニティホストのサーバーを使ってもよい。Steamの独自P2P gamenetworkingsocketインフラで得られるものに少し似ている。
https://lobste.rs/s/cslljn/iroh_1_0_dial_keys_not_ips#c_s3na...
そもそも何の問題を解こうとしているのか分からない。IPとDNSはうまく動いている。
すでに IPv6とQUIC があり、この分野で意味のある牽引力を得るにはベンダーと主要ソフトウェアが必要だ。
具体的には、自宅WLANのNATの背後にある1台の機器と、4Gネットワークや会社の別のNATの背後にある別の機器があるとしよう。
ほとんどの場合、ホールパンチングによって2台の間に非常に高速に直接接続を作れ、可能な限り高い帯域幅と低い遅延を得られる。
この問題は、これまで解決済みの問題ではなかった。
TCP/IPには本当のセッション層がないため、vMotionは通常、単一のブロードキャストドメイン内でしか使えない。この状況では、アドレッシングには実質的にMACアドレスだけを使い、vMotion後にMACアドレスが変わってもIPを安定した識別子として使える。マッピングはスイッチのMACアドレステーブルが処理する。
ネットワーキングの未来は 分散化 だ。YggdrasilとI2Pがとても好きだ。
24時間稼働させるミニPCを買って必要なものをホストし、他の人とシームレスにつながれるようであるべきだ。多くの技術者はすでに、ほこりをかぶった古い予備マシンを持っていて、それをサーバーにできる。
長期的には、ドメインやサーバーホスティングを扱うより、ずっと安く維持もしやすい。Irohチームの仕事を心から高く評価している。
Irohは本当に扱いやすく、Discordチャンネルのエンジニアたちもとても親切だった。
P2Pをただ動くようにする実用的なアプローチ は理解しやすく、YouTubeチャンネルのコンテンツも素晴らしい。v1リリースおめでとう。
https://youtube.com/@n0computer
IPアドレスと似た機能をしようとするプロトコルに 価格表 があるのは奇妙に見えないか。何か誤解しているのかもしれない。
ただし開発コストを賄うため、特により大規模または特殊なユースケースで、デプロイと運用を容易にする追加サービスを提供している。
「人々にとってはインフラになりたいが、専門家にとってはビジネスでもありたい」という状態だ。
「運用するには金が必要だ」と「公共財インフラのシステムになりたい」の間に挟まっていて、営利企業の負の側面は「でもオープンソースだから」で片付けられる。
「オープンソース」という但し書きが、完全にカスタムで理解不能なコードベースを伴わない限り、こういうビジネスの発想はある程度は構わないと思う。
ISPやASを運営するには相当なお金がかかるのは確かだ。
会社でIrohを本番運用に使っていて、本当に気に入っている。
主に Rustクレートとして提供されるTailscale風ホールパンチング と説明するだろうが、もちろん基本のQUIC接続の上に多くの優れたP2P機能を載せられる。
うちの会社は本番の 分散機械学習トレーニングシステム にIrohを使っていて、本当に満足している。
エンタープライズサポート契約を結ぶ前から、チームは信じられないほど迅速に対応してくれ、知識も非常に深く、ライブラリ自体も驚くほどよく動いた。libp2pより、いつでもまたこのライブラリを使いたい。
リリースおめでとう
tailscale/netbird/netmaker/zerotier/twingate/openziti と比較する versus ページが早急に必要
ユースケースだけを見ると、現時点では Tailscale でできないことが見当たらない
Lobste.rsの意見
ここでもHNでも、IrohがVPN上に構築するメッシュネットワーク（Tailscale、ZeroTier、Netbird など）とどう違うのか混同している人が多いように見える。自分の理解では、Irohは自分のアプリを動かすデバイス同士でP2P通信をしたいアプリケーション開発者向けで、メッシュネットワークは自分が所有・管理する機器同士を接続したいネットワーク管理者向けということだと思う
たとえばP2Pメッセージングアプリを作るとすると、片方のユーザーはWiFiとモバイルデータを行き来するモバイル端末で安定したアドレスを持たず、もう片方はNATやCGNATの背後にあるノートPCかもしれない。IPアドレスが変わってもこの2者が通信できるようにするには、それを処理する仕組みが必要になる
以前は通常、アプリ開発者が運用する中継サーバーに両方のエンドポイントが接続して状態を共有する方式だったが、Irohはこれを標準化してサービスとして提供しようとしているものに近い
Steamの独自P2P
gamenetworkingsocketインフラから得られるものにも少し似ている何か見落としているかもしれないが、すべてを単一のキーに依存させるのはかなり危険に見える。そのキーを失くしたり盗まれたりしたらどうなるのか気になる
Irohのドキュメントで“key rotation”をざっと検索してみたが見つけられなかった
Irohを使うアプリケーションの中にはキーを永続保存するものもあれば、セッションごとに新しく生成するものもある
秘密鍵が漏えいすると、攻撃者が接続を開始または受信する際に自分になりすませるようになる。キーを失うと、ピアに対して自分の身元を証明できなくなる。自分の理解では、一般的なパスワードや秘密鍵を失ったり盗まれたりしたときと似たリスクだ
似た代替案には何があるだろう？ Host Identity Protocol? https://mkomu.kapsi.fi/hipl/index.php?index=how
プロジェクトを理解しようとしているが、キーとIPの違いがいまいち腑に落ちない。結局どこかの時点で、IPルーティングを使うためにキーがIPアドレスへマッピングされるのではないのか？
キーは、長く維持される識別子をIPアドレスに結び付ける方法として、URLやDNSを置き換えるものなのか？
あるノードを別のノードへキーで接続しようとすると、リレーサーバーのいずれかでそのキーを引き、その後に直接IP接続、ホールパンチング、最終的にはリレーサーバー経由のリレー接続まで、複数の方法を試す
またキーは、QUICによるエンドツーエンド暗号化にも使われる
特定アプリケーション向けに独自のリレーサーバーをホスティングする方法はあるのか？ 可能そうではある。ただ、専用リレーの価格ページがあるのを見ると少し奇妙にも感じる
ホステッドリレーは、自分でサーバーを管理する手間なしにこれを提供し、ネットワークについてより高い可視性を得られるようにするのが目的だ
これはYggdrasilやNetbirdよりもReticulumに近い感じがする
これが何なのか理解するのが難しい。Yggdrasilを思い出すが、両者をどう比較すればいいのかはよく分からない