브라우저 피어 투 피어
Bitsocial 웹 앱은 누군가의 서버에 매달린 클라이언트일 필요가 없습니다. 브라우저 탭 안에서 Helia 노드를 실행해 데스크톱 및 CLI 노드와 같은 피어 투 피어 네트워크에 참여하고, 피어에게서 커뮤니티 콘텐츠를 가져오며, pubsub으로 게시할 수 있습니다.
이 페이지에서는 그것이 실제로 무엇을 뜻하는지, 어떤 전송 계층을 사용하는지, 아직 할 수 없는 일은 무엇인지, 그리고 탭에서의 게시가 왜 2026년에야 동작하기 시작했는지 설명합니다.
더 넓은 범위의 네트워크 설계는 피어 투 피어 프로토콜을 참고하세요.
탭 안에서 실행되는 것
브라우저 P2P가 활성화되면 페이지는 진짜 libp2p 노드를 품게 됩니다.
- 보안 WebSockets으로 다른 피어에 연결을 시도합니다
- IPFS 게이트웨이가 아니라 그 피어들에게서 커뮤니티 콘텐츠를 가져와 검증합니다
- gossipsub에 참여하므로 게시물을 올릴 때 호스팅된 pubsub 제공자가 필요하지 않습니다
- 다른 모든 Bitsocial 앱과 동일한 프로토콜 클라이언트 스택(
pkc-js)을 사용합니다
그 실질적인 결과로, 웹 독자와 커뮤니티 사이에 게이트웨이 운영자가 끼어들지 않습니다. 모든 브라우저 사용자에게서 한꺼번에 커뮤니티를 내리도록 압박할 수 있는 단일 HTTPS 엔드포인트가 존재하지 않습니다.
브라우저 노드가 연결되는 방식
pkc-js는 보안 WebSockets으로 피어에 연결합니다. WebRTC와 WebTransport 연결은 커넥션 게이터를 통해
기본적으로 거부됩니다. 브라우저에서는 이런 방식이 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를 우선하고, 게이트웨이는 기본 병목이 아니라 선택적 대체 수단으로 두는 것입니다.