براؤزر پیئر ٹو پیئر
ایک 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-bit big-endian عدد ہونا چاہیے۔
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 گیٹ وے مواد کے راستے میں ہی ہوتا ہے۔
آج یہ کہاں چل رہا ہے
گیٹ وے فال بیک
گیٹ وے پر مبنی رسائی ان براؤزرز یا نیٹ ورکس کے لیے مطابقت کے راستے کے طور پر اب بھی موجود ہے جو براہِ راست شامل نہیں ہو سکتے۔ دیکھیں گیٹ وے فال بیک۔ ہدف فنِ تعمیر یہ ہے کہ پہلے براؤزر P2P ہو، اور گیٹ ویز طے شدہ رکاوٹ کے بجائے ایک اختیاری فال بیک رہیں۔