浏览器点对点网络
Bitsocial 网页应用不必充当某个人服务器的客户端。它可以在浏览器标签页内运行一个 Helia 节点，加入与桌面端和 CLI 节点相同的点对点网络，从其他对等节点获取社区内容，并通过 pubsub 发布内容。
本页说明这在实践中意味着什么、它使用哪些传输方式、它目前仍然做不到什么，以及为什么从标签页发帖直到 2026 年才开始正常工作。
关于更宏观的网络设计，请参阅点对点协议。
标签页里运行着什么
浏览器 P2P 启用后，页面中持有一个真正的 libp2p 节点：
- 它通过安全 WebSockets 拨号连接其他对等节点
- 它从这些对等节点获取并验证社区内容，而不是从 IPFS 网关获取
- 它参与 gossipsub，因此发布帖子不需要托管的 pubsub 提供方
- 它使用与其他每一个 Bitsocial 应用相同的协议客户端栈（
pkc-js）
由此带来的实际结果是，网页读者与社区之间不再夹着任何网关运营方。不存在某一个 HTTPS 端点，可以在被施压之后一次性让所有浏览器用户都读不到某个社区。
浏览器节点如何建立连接
pkc-js 通过安全 WebSockets 拨号连接对等节点。WebRTC 和 WebTransport 拨号默认由连接门控（connection gater）拒绝，因为在浏览器中它们会引入漫长且经常失败的连接建立流程——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 优先，把网关当作可选的回退路径，而不是默认的瓶颈。