Přeskočit na hlavní obsah

Peer-to-Peer v prohlížeči

Webová aplikace Bitsocial nemusí být jen klientem cizího serveru. Může přímo v záložce prohlížeče provozovat uzel Helia, připojit se ke stejné peer-to-peer síti jako desktopové a CLI uzly, stahovat obsah komunit od peerů a publikovat přes pubsub.

Tato stránka vysvětluje, co to prakticky znamená, které transporty se přitom používají, co takový uzel stále neumí a proč publikování ze záložky začalo fungovat až v roce 2026.

Širší návrh sítě popisuje Protokol Peer-to-Peer.

Co běží v záložce

Když je P2P v prohlížeči aktivní, drží stránka skutečný uzel libp2p:

  • navazuje spojení s dalšími peery přes zabezpečené WebSockets
  • stahuje a ověřuje obsah komunit přímo od těchto peerů, nikoli z IPFS gateway
  • účastní se gossipsubu, takže publikování příspěvku nepotřebuje hostovaného poskytovatele pubsub
  • používá stejný klientský stack protokolu (pkc-js) jako každá další aplikace Bitsocial

Praktickým důsledkem je, že mezi čtenářem na webu a komunitou nestojí žádný provozovatel gateway. Neexistuje jediný HTTPS endpoint, na který by stačilo zatlačit, aby komunita naráz zmizela všem uživatelům v prohlížeči.

Jak se uzly v prohlížeči připojují

pkc-js navazuje spojení s peery přes zabezpečené WebSockets. Spojení přes WebRTC a WebTransport jsou ve výchozím nastavení zamítána connection gaterem, protože v prohlížeči přidávají dlouhé a často neúspěšné cesty k navázání spojení — vyjednávání STUN/ICE, rotaci certhashů —, které zpomalují načítání stránky, zatímco WebSocket nabízí přímý a spolehlivý transport. Volající, kteří WebRTC nebo WebTransport výslovně chtějí, mohou gater přepsat přes libp2pJsClientsOptions[].libp2pOptions.connectionGater.

Praktickým důsledkem je, že peer v prohlížeči se připojuje k uzlům vystavujícím WSS endpoint, a takové uzly tedy potřebují doménu a certifikát podepsaný certifikační autoritou. Peery za běžnými domácími připojeními, které nic z toho nemají, se dosahuje nepřímo, ne přímým spojením ze záložky.

Proč publikování z prohlížeče začalo fungovat až v roce 2026

Peer-to-peer v prohlížeči není nová myšlenka. V roce 2026 se změnilo to, že příspěvky uzlu běžícího v prohlížeči se konečně dostanou ke zbytku sítě.

Specifikace pubsub v libp2p vyžaduje, aby seqno zprávy bylo lineárně rostoucí 64bitové celé číslo v pořadí big-endian. js-libp2p-gossipsub místo toho generoval osm náhodných bajtů, zatímco go-libp2p-pubsub i rust-libp2p používaly čítač. Kubo 0.40+ zapíná ve výchozím nastavení BasicSeqnoValidator, který zamítne každou zprávu, jejíž seqno není vyšší než dosud nejvyšší viděné od daného peeru.

Důsledkem bylo, že většinu zpráv publikovaných uzlem v JavaScriptu — včetně uzlu v prohlížeči — peery s Kubo tiše zahodily. Reprodukční test naměřil, že z 30 zpráv dorazily 2 až 8.

Problém byl popsán v js-libp2p-gossipsub#545 a opraven ve verzi @libp2p/gossipsub 15.0.21 v květnu 2026. Do té doby se uzel v prohlížeči dokázal připojit a číst, ale jeho příspěvky se cestou ke Go peerům většinou ztratily. pkc-js dodává @libp2p/gossipsub ve verzi 16.0.4, tedy až za touto opravou.

Co uzel v prohlížeči stále neumí

Uzel v prohlížeči je skutečný peer, ne server. Má jiné limity než desktopový nebo trvale běžící uzel:

  • obvykle nedokáže přijímat libovolná příchozí spojení z veřejného internetu
  • funguje jen po dobu, kdy je záložka otevřená, takže není dlouhodobým hostitelem dat komunity
  • nemůže se připojit k DHT v libp2p, a proto zjišťování probíhá přes HTTP routery
  • pro seedování ve větším měřítku se hodí špatně

Plnohodnotné hostování komunity nadále nejlépe zvládne desktopová aplikace, bitsocial-cli nebo jiný trvale běžící uzel. P2P v prohlížeči mění to, kdo může číst a přispívat bez gateway; neodstraňuje potřebu peerů, kteří zůstávají online.

HTTP routery nejsou gateways

Klienti v prohlížeči se stále dotazují HTTP routerů, aby zjistili, kteří peeři právě poskytují adresu dané komunity. To je poctivá hvězdička u tvrzení „čisté peer-to-peer v prohlížeči“ a stojí za to být v tom přesný:

  • router uchovává jen adresy peerů k dané adrese obsahu
  • obsah komunity neukládá, neposkytuje a ani ho nezná
  • klienti se dotazují několika routerů paralelně a výsledky slučují
  • provozovat ho může kdokoli a výměna routeru je změna konfigurace bez migrace dat

Po zjištění peerů probíhá přenos obsahu i provoz pubsub peer-to-peer. Router, který zmizí, vás připraví o jednu vyhledávací cestu, ne o data. IPFS gateway naproti tomu leží přímo v cestě obsahu.

Kde to dnes běží

  • 5chan běží ve výchozím nastavení jako čisté P2P v prohlížeči ve webové aplikaci na 5chan.app.

Záložní gateway

Přístup přes gateway existuje dál jako cesta kompatibility pro prohlížeče nebo sítě, které se nemohou připojit přímo. Viz Záložní gateway. Cílovou architekturou je P2P v prohlížeči na prvním místě a gateways jako volitelná záloha, ne jako výchozí úzké hrdlo.