मुख्य कंटेंट तक स्किप करें

ब्राउज़र पीयर-टू-पीयर

किसी Bitsocial वेब ऐप को किसी और के सर्वर का क्लाइंट होना ज़रूरी नहीं है। वह ब्राउज़र टैब के भीतर ही एक Helia नोड चला सकता है, डेस्कटॉप और CLI नोड्स वाले उसी पीयर-टू-पीयर नेटवर्क में शामिल हो सकता है, पीयर्स से समुदाय की सामग्री ला सकता है, और pubsub के ज़रिए प्रकाशित कर सकता है।

यह पृष्ठ बताता है कि व्यवहार में इसका क्या अर्थ है, यह किन ट्रांसपोर्ट का उपयोग करता है, यह अब भी क्या नहीं कर सकता, और टैब से प्रकाशन 2026 में ही क्यों काम करने लगा।

व्यापक नेटवर्क डिज़ाइन के लिए पीयर-टू-पीयर प्रोटोकॉल देखें।

टैब में क्या चलता है​

जब ब्राउज़र P2P सक्रिय होता है, तब पेज के भीतर एक असली libp2p नोड चलता रहता है:

  • यह सुरक्षित WebSockets के ज़रिए दूसरे पीयर्स से जुड़ता है
  • यह समुदाय की सामग्री उन्हीं पीयर्स से लाता और सत्यापित करता है, किसी IPFS गेटवे से नहीं
  • यह gossipsub में भाग लेता है, इसलिए पोस्ट प्रकाशित करने के लिए होस्ट किए गए pubsub प्रोवाइडर की ज़रूरत नहीं पड़ती
  • यह वही प्रोटोकॉल क्लाइंट स्टैक (pkc-js) उपयोग करता है जो हर दूसरा Bitsocial ऐप उपयोग करता है

व्यावहारिक नतीजा यह है कि किसी वेब पाठक और समुदाय के बीच कोई गेटवे ऑपरेटर नहीं रहता। ऐसा कोई एक 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 में @libp2p/gossipsub 15.0.21 में इसे ठीक किया गया। वह आने तक ब्राउज़र नोड जुड़ और पढ़ तो सकता था, पर उसकी पोस्ट Go पीयर्स तक पहुँचते-पहुँचते ज़्यादातर ग़ायब हो जाती थीं। pkc-js में @libp2p/gossipsub 16.0.4 शामिल है, यानी उस फ़िक्स के बाद का संस्करण।

ब्राउज़र नोड अब भी क्या नहीं कर सकता​

ब्राउज़र नोड एक असली पीयर है, सर्वर नहीं। किसी डेस्कटॉप या हमेशा-चालू नोड के मुक़ाबले इसकी सीमाएँ अलग हैं:

  • यह आमतौर पर सार्वजनिक इंटरनेट से आने वाले मनमाने इनबाउंड कनेक्शन स्वीकार नहीं कर सकता
  • यह केवल तभी काम करता है जब तक टैब खुला है, इसलिए यह किसी समुदाय के डेटा का दीर्घकालिक होस्ट नहीं है
  • यह libp2p DHT में शामिल नहीं हो सकता, इसीलिए खोज HTTP राउटर्स के ज़रिए होती है
  • बड़े पैमाने पर सीडिंग के लिए यह उपयुक्त नहीं है

पूरे समुदाय की होस्टिंग अब भी किसी डेस्कटॉप ऐप, bitsocial-cli, या किसी अन्य हमेशा-चालू नोड से ही सबसे अच्छी तरह होती है। ब्राउज़र P2P यह बदलता है कि गेटवे के बिना कौन पढ़ और पोस्ट कर सकता है; यह ऑनलाइन बने रहने वाले पीयर्स की ज़रूरत ख़त्म नहीं करता।

HTTP राउटर गेटवे नहीं हैं​

यह जानने के लिए कि इस समय कौन-से पीयर्स किसी समुदाय का पता उपलब्ध करा रहे हैं, ब्राउज़र क्लाइंट अब भी HTTP राउटर से पूछते हैं। "ब्राउज़र में शुद्ध पीयर-टू-पीयर" वाली बात पर यही ईमानदार तारांकन है, और इस बारे में सटीक रहना ज़रूरी है:

  • राउटर किसी सामग्री-पते के लिए सिर्फ़ पीयर पते रखता है
  • वह समुदाय की सामग्री न रखता है, न परोसता है, और न ही उसके बारे में जानता है
  • क्लाइंट कई राउटर्स से समानांतर में पूछते हैं और परिणामों को मिला लेते हैं
  • कोई भी राउटर चला सकता है, और राउटर बदलना बिना किसी डेटा माइग्रेशन के केवल कॉन्फ़िग बदलने जितना काम है

खोज हो जाने के बाद सामग्री का स्थानांतरण और pubsub ट्रैफ़िक पीयर-टू-पीयर चलते हैं। कोई राउटर ग़ायब हो जाए तो आपका एक लुकअप रास्ता जाता है, आपका डेटा नहीं। इसके उलट, IPFS गेटवे सामग्री के रास्ते में ही बैठा होता है।

यह आज कहाँ चल रहा है​

  • 5chan 5chan.app पर मौजूद वेब ऐप में डिफ़ॉल्ट रूप से शुद्ध ब्राउज़र P2P चलाता है।

गेटवे फ़ॉलबैक​

जो ब्राउज़र या नेटवर्क सीधे शामिल नहीं हो सकते, उनके लिए गेटवे-आधारित पहुँच अब भी एक संगतता रास्ते के रूप में मौजूद है। देखें गेटवे फ़ॉलबैक। लक्षित आर्किटेक्चर पहले ब्राउज़र P2P है, जिसमें गेटवे डिफ़ॉल्ट अड़चन के बजाय एक वैकल्पिक फ़ॉलबैक हैं।