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ěží
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.