Одноранговий зв’язок у браузері
Вебзастосунок Bitsocial не мусить бути клієнтом чийогось сервера. Він може запустити вузол Helia просто у вкладці браузера, приєднатися до тієї самої однорангової мережі, що й десктопні та CLI-вузли, отримувати вміст спільнот від інших вузлів і публікувати через pubsub.
Ця сторінка пояснює, що це означає на практиці, які транспорти використовуються, чого браузерний вузол досі не вміє і чому публікація з вкладки запрацювала лише у 2026 році.
Про ширшу архітектуру мережі читайте в розділі Одноранговий протокол.
Що працює у вкладці
Коли одноранговий режим у браузері увімкнено, сторінка тримає справжній вузол libp2p:
- він з’єднується з іншими вузлами через захищені WebSockets
- він отримує та перевіряє вміст спільнот безпосередньо від цих вузлів, а не зі шлюзу IPFS
- він бере участь у gossipsub, тож для публікації допису не потрібен розміщений постачальник pubsub
- він використовує той самий стек клієнта протоколу (
pkc-js), що й будь-який інший застосунок Bitsocial
Практичний наслідок у тому, що між читачем у браузері та спільнотою більше не стоїть оператор шлюзу. Немає єдиної точки входу HTTPS, на яку можна натиснути, щоб вона одночасно перестала обслуговувати спільноту для всіх користувачів браузера.
Як з’єднуються браузерні вузли
pkc-js з’єднується з іншими вузлами через захищені WebSockets. З’єднання через WebRTC і
WebTransport типово заборонені фільтром з’єднань (connection gater), бо в браузері вони додають довгі
й часто невдалі шляхи встановлення з’єднання — узгодження STUN/ICE, ротацію certhash, — які
сповільнюють завантаження сторінки, тоді як WebSocket дає прямий і надійний транспорт. Ті, кому
потрібен саме WebRTC або WebTransport, можуть перевизначити цей фільтр через
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 або
іншому постійно ввімкненому вузлу. Одноранговий режим у браузері змінює те, хто може читати й
публікувати без шлюзу; він не усуває потреби у вузлах, які лишаються онлайн.
Маршрутизатори HTTP — це не шлюзи
Браузерні клієнти й далі звертаються до маршрутизаторів HTTP, щоб дізнатися, які вузли зараз надають адресу спільноти. Це чесна примітка до формулювання «чистий одноранговий зв’язок у браузері», і про неї варто сказати точно:
- маршрутизатор зберігає лише адреси вузлів для адреси вмісту
- він не зберігає, не роздає і навіть не знає вмісту спільноти
- клієнти опитують кілька маршрутизаторів паралельно й об’єднують результати
- запустити такий маршрутизатор може будь-хто, а його заміна — це зміна конфігурації без міграції даних
Після виявлення передавання вмісту й трафік pubsub ідуть напряму між вузлами. Зникнення маршрутизатора коштує вам одного шляху пошуку, а не ваших даних. Шлюз IPFS, навпаки, стоїть на шляху самого вмісту.
Де це працює вже сьогодні
Резервний шлюз
Доступ через шлюз залишається як шлях сумісності для браузерів або мереж, які не можуть приєднатися напряму. Див. Резервний шлюз. Цільова архітектура — це насамперед одноранговий зв’язок у браузері, а шлюзи як необов’язковий запасний варіант, а не як типове вузьке місце.