স্কিপ করে মূল কন্টেন্ট এ যান

ব্রাউজার পিয়ার-টু-পিয়ার

একটি 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, আর গেটওয়ে ডিফল্ট বাধা না হয়ে ঐচ্ছিক ফলব্যাক।