ブラウザ ピアツーピア
Bitsocial のウェブアプリは、誰かのサーバーのクライアントである必要はありません。ブラウザのタブの中で Helia ノードを動かし、デスクトップや CLI のノードと同じピアツーピアネットワークに参加して、コミュニティのコンテンツをピアから取得し、pubsub 経由で投稿を公開できます。
このページでは、それが実際には何を意味するのか、どのトランスポートを使うのか、それでもできないことは何か、そしてなぜタブからの公開が 2026 年になってようやく動き出したのかを説明します。
ネットワーク全体の設計については、ピアツーピアプロトコル を参照してください。
タブの中で動いているもの
ブラウザ P2P が有効なとき、ページは本物の libp2p ノードを抱えています。
- セキュアな WebSockets で他のピアにダイヤルします
- IPFS ゲートウェイからではなく、それらのピアからコミュニティのコンテンツを取得して検証します
- gossipsub に参加するため、投稿の公開にホスト型の pubsub プロバイダーを必要としません
- 他のすべての Bitsocial アプリと同じプロトコルクライアントスタック (
pkc-js) を使います
これがもたらす実際の効果は、ウェブの読み手とコミュニティのあいだにゲートウェイ運用者が入らなくなることです。ブラウザ利用者全員に対して一斉にコミュニティの配信を止めるよう圧力をかけられる、単一の HTTPS エンドポイントは存在しません。
ブラウザノードはどうつながるのか
pkc-js は セキュアな WebSockets でピアにダイヤルします。WebRTC と WebTransport によるダイヤルは、コネクションゲーターによって既定で拒否されます。ブラウザではこれらが STUN/ICE のネゴシエーションや certhash のローテーションといった、長くて失敗しがちな接続確立の経路を持ち込んでページの読み込みを遅くする一方、WebSocket なら直接的で信頼できるトランスポートが得られるからです。あえて WebRTC や WebTransport を使いたい呼び出し側は、libp2pJsClientsOptions[].libp2pOptions.connectionGater からゲーターを上書きできます。
その実際の効果として、ブラウザのピアは WSS エンドポイントを公開しているノードに接続することになり、そうしたノードにはドメインと CA 署名済みの証明書が必要になります。それを持たない一般回線の背後にいるピアには、タブから直接ダイヤルするのではなく間接的に到達します。
ブラウザからの公開が 2026 年になって動き始めた理由
ブラウザでのピアツーピアは、新しい発想ではありません。2026 年に変わったのは、ブラウザノードの 投稿 がネットワークの他の部分まで届くようになったことです。
libp2p の pubsub 仕様は、メッセージの seqno が線形に増加する 64 ビットのビッグエンディアン整数であることを求めています。ところが js-libp2p-gossipsub は、その代わりに 8 バイトのランダム値を生成していました。go-libp2p-pubsub と rust-libp2p はどちらもカウンターを使っていたのに対してです。Kubo 0.40 以降は BasicSeqnoValidator を既定で有効にしており、そのピアからすでに受け取った最大値を上回らない seqno のメッセージをすべて拒否します。
その結果、JavaScript ノード（ブラウザノードを含む）が公開したメッセージのほとんどは、Kubo のピアに黙って捨てられていました。ある再現コードでは、30 件のうち届いたのは 2 件から 8 件でした。
この問題は js-libp2p-gossipsub#545 で原因が特定され、2026 年 5 月に @libp2p/gossipsub 15.0.21 で修正されました。それが取り込まれるまで、ブラウザノードは接続して読むことはできても、その投稿は Go のピアに届く途中でほとんど消えていました。pkc-js は、この修正より後の @libp2p/gossipsub 16.0.4 を同梱しています。
ブラウザノードに今もできないこと
ブラウザノードはサーバーではなく、あくまで本物のピアの一つです。デスクトップや常時稼働のノードとは制約が異なります。
- 公開インターネットからの任意の受信接続は、通常は受け付けられません
- タブが開いているあいだしか動かないため、コミュニティのデータを長く預かるホストにはなりません
- libp2p の DHT に参加できないため、ディスカバリは HTTP ルーター経由になります
- 大規模なシード配信には向きません
コミュニティを本格的にホストするなら、今もデスクトップアプリ、bitsocial-cli、あるいは別の常時稼働ノードが適しています。ブラウザ P2P が変えるのは、ゲートウェイなしで 読んで投稿できる のは誰かという点であって、オンラインであり続けるピアが不要になるわけではありません。
HTTP ルーターはゲートウェイではありません
ブラウザのクライアントは、あるコミュニティのアドレスを現在どのピアが提供しているのかを知るために、今も HTTP ルーター へ問い合わせます。これは「ブラウザにおける純粋なピアツーピア」に付く正直な但し書きであり、正確に述べておく価値があります。
- ルーターが保存するのは、あるコンテンツアドレスに対応するピアのアドレスだけです
- コミュニティのコンテンツを保存も配信もせず、そもそも中身を知りません
- クライアントは複数のルーターへ並行して問い合わせ、その結果をまとめます
- 誰でも自分で運用でき、ルーターの乗り換えはデータ移行を伴わない設定変更で済みます
ディスカバリが済んだあとは、コンテンツの転送も pubsub のトラフィックもピアツーピアで流れます。ルーターが消えて失われるのはルックアップの経路であって、データではありません。対照的に、IPFS ゲートウェイはコンテンツそのものの経路上にあります。
現在どこで動いているのか
ゲートウェイフォールバック
ゲートウェイ経由のアクセスも、直接参加できないブラウザやネットワークのための互換経路として残っています。ゲートウェイフォールバック を参照してください。目指すアーキテクチャは、まずブラウザ P2P があり、ゲートウェイは既定のボトルネックではなく任意のフォールバックとして置かれる形です。