मुख्य सामग्रीवर जा

ब्राउझर पीअर-टू-पीअर

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 मध्ये @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, आणि गेटवे हे मूलभूत अडथळा नसून पर्यायी फॉलबॅक.