Перейти к основному содержанию

Одноранговая сеть в браузере

Веб-приложение Bitsocial не обязано быть клиентом чьего-то сервера. Оно может запустить узел Helia прямо во вкладке браузера, подключиться к той же одноранговой сети, что и десктопные и CLI-узлы, получать контент сообществ от других участников и публиковать записи через pubsub.

На этой странице разобрано, что это означает на практике, какие транспорты при этом используются, чего браузерный узел по-прежнему не умеет и почему публикация из вкладки заработала только в 2026 году.

Об устройстве сети в целом читайте Одноранговый протокол.

Что работает во вкладке​

Когда браузерный P2P включён, страница держит настоящий узел libp2p:

  • он соединяется с другими узлами по защищённым WebSockets
  • он получает и проверяет контент сообществ у самих узлов, а не через IPFS-шлюз
  • он участвует в gossipsub, поэтому для публикации записи не нужен размещённый где-то pubsub-провайдер
  • он использует тот же клиентский стек протокола (pkc-js), что и любое другое приложение Bitsocial

Практическое следствие: между читателем в браузере и сообществом больше нет оператора шлюза. Нет и единственной HTTPS-точки входа, на которую можно надавить, чтобы сообщество разом исчезло для всех браузерных пользователей.

Как соединяются браузерные узлы​

pkc-js соединяется с узлами по защищённым WebSockets. Соединения через WebRTC и WebTransport по умолчанию запрещены на уровне connection gater: в браузере они добавляют долгие и часто неудачные этапы установления связи — согласование STUN/ICE, ротацию certhash, — которые замедляют загрузку страницы, тогда как WebSocket даёт прямой и надёжный транспорт. Тот, кому WebRTC или WebTransport нужны намеренно, может переопределить gater через libp2pJsClientsOptions[].libp2pOptions.connectionGater.

На практике это значит, что браузерный узел подключается к узлам с открытой WSS-точкой входа, а значит таким узлам нужны домен и сертификат, подписанный удостоверяющим центром. До узлов на обычных домашних подключениях, у которых этого нет, добираются не напрямую из вкладки, а окольным путём.

Почему публикация из браузера заработала только в 2026 году​

Одноранговая сеть в браузере — не новая идея. В 2026 году изменилось другое: записи браузерного узла наконец стали доходить до остальной сети.

Спецификация pubsub в libp2p требует, чтобы seqno сообщения был линейно возрастающим 64-битным целым числом с порядком байтов big-endian. Вместо этого js-libp2p-gossipsub генерировал 8 случайных байтов, тогда как go-libp2p-pubsub и rust-libp2p использовали счётчик. Kubo 0.40+ по умолчанию включает BasicSeqnoValidator, который отбрасывает любое сообщение, чей seqno не больше наибольшего уже полученного от этого узла.

В результате большинство сообщений, опубликованных JavaScript-узлом — в том числе браузерным, — молча отбрасывалось узлами Kubo. В воспроизводимом тесте доходило от 2 до 8 сообщений из 30.

Причину нашли в js-libp2p-gossipsub#545 и исправили в @libp2p/gossipsub 15.0.21 в мае 2026 года. Пока это исправление не вышло, браузерный узел мог подключаться и читать, но его записи по большей части терялись по дороге к Go-узлам. pkc-js поставляется с @libp2p/gossipsub 16.0.4, то есть уже с этим исправлением.

Чего браузерный узел всё ещё не умеет​

Браузерный узел — полноценный участник сети, но не сервер. Ограничения у него другие, чем у десктопного или постоянно работающего узла:

  • он обычно не может принимать произвольные входящие соединения из публичного интернета
  • он работает, только пока открыта вкладка, поэтому не годится на роль долговременного хранилища данных сообщества
  • он не может участвовать в DHT libp2p — именно поэтому обнаружение идёт через HTTP-роутеры
  • он плохо подходит для раздачи данных в больших объёмах

Полноценный хостинг сообщества по-прежнему лучше доверить десктопному приложению, bitsocial-cli или другому постоянно работающему узлу. Браузерный P2P меняет то, кто может читать и публиковать без шлюза; он не отменяет потребности в узлах, которые остаются онлайн.

HTTP-роутеры — это не шлюзы​

Браузерные клиенты по-прежнему обращаются к HTTP-роутерам, чтобы узнать, какие узлы сейчас раздают адрес сообщества. Это честная оговорка к формулировке «чистая одноранговая сеть в браузере», и о ней стоит сказать точно:

  • роутер хранит только адреса узлов для адреса контента
  • он не хранит и не отдаёт содержимое сообщества и вообще о нём не знает
  • клиенты опрашивают несколько роутеров параллельно и объединяют результаты
  • запустить свой роутер может кто угодно, а смена роутера — это правка конфигурации без миграции данных

После обнаружения передача контента и трафик pubsub идут напрямую между узлами. Исчезнувший роутер стоит вам одного пути поиска, а не ваших данных. IPFS-шлюз, напротив, стоит на пути самого контента.

Где это уже работает​

  • 5chan по умолчанию работает как чистый браузерный P2P в веб-приложении на 5chan.app.

Резервный путь через шлюз​

Доступ через шлюз сохраняется как путь совместимости для браузеров и сетей, которые не могут подключиться напрямую. См. Резервный путь через шлюз. Целевая архитектура — сначала браузерный P2P, а шлюзы как необязательный запасной вариант, а не узкое место по умолчанию.