پرش به مطلب اصلی

همتا به همتا در مرورگر

یک وب‌اپ Bitsocial لازم نیست کلاینتِ سرورِ کسی باشد. می‌تواند یک گره Helia را داخل زبانه مرورگر اجرا کند، به همان شبکه همتا به همتای گره‌های دسکتاپ و CLI بپیوندد، محتوای انجمن‌ها را از همتایان بگیرد و روی pubsub منتشر کند.

این صفحه توضیح می‌دهد که این کار در عمل چه معنایی دارد، از چه ترابری‌هایی استفاده می‌کند، هنوز چه کاری از آن برنمی‌آید، و چرا انتشار از داخل زبانه تازه از 2026 کار می‌کند.

برای آشنایی با طراحی کلی شبکه، پروتکل همتا به همتا را ببینید.

آنچه در زبانه اجرا می‌شود​

وقتی P2P مرورگر فعال است، صفحه یک گره واقعی libp2p را در خود دارد:

  • با WebSockets امن به همتایان دیگر وصل می‌شود
  • محتوای انجمن‌ها را از همان همتایان می‌گیرد و راستی‌آزمایی می‌کند، نه از یک دروازه IPFS
  • در gossipsub مشارکت می‌کند، پس انتشار یک پست به ارائه‌دهنده pubsub میزبانی‌شده نیاز ندارد
  • از همان پشته کلاینت پروتکل (pkc-js) استفاده می‌کند که هر اپ دیگر Bitsocial استفاده می‌کند

نتیجه عملی این است که هیچ اپراتور دروازه‌ای میان خواننده وب و یک انجمن نمی‌ایستد. هیچ نقطه پایانی واحد HTTPS وجود ندارد که بتوان با فشار آوردن به آن، دسترسی همه کاربران مرورگر به یک انجمن را یکجا قطع کرد.

گره‌های مرورگر چگونه وصل می‌شوند​

pkc-js با WebSockets امن به همتایان وصل می‌شود. اتصال‌های WebRTC و WebTransport به‌طور پیش‌فرض توسط یک connection gater رد می‌شوند، چون در مرورگر مسیرهای طولانی و اغلب ناموفقی برای برقراری اتصال می‌سازند — مذاکره STUN/ICE، چرخش certhash — که بارگذاری صفحه را کند می‌کند، در حالی که WebSocket ترابری مستقیم و قابل‌اتکایی می‌دهد. فراخوانندگانی که مشخصاً WebRTC یا WebTransport می‌خواهند، می‌توانند gater را از طریق libp2pJsClientsOptions[].libp2pOptions.connectionGater بازنویسی کنند.

نتیجه عملی این است که یک همتای مرورگر به گره‌هایی وصل می‌شود که نقطه پایانی WSS ارائه می‌کنند، و این یعنی آن گره‌ها به یک دامنه و گواهی امضاشده توسط CA نیاز دارند. همتایانی که پشت اتصال‌های خانگی و بدون چنین چیزی هستند، به‌جای اتصال مستقیم از زبانه، غیرمستقیم در دسترس قرار می‌گیرند.

چرا انتشار از مرورگر تازه از 2026 کار می‌کند​

همتا به همتا در مرورگر ایده تازه‌ای نیست. آنچه در 2026 عوض شد این است که حالا پست‌های یک گره مرورگر به بقیه شبکه می‌رسند.

مشخصات pubsub در libp2p ایجاب می‌کند که seqno هر پیام یک عدد صحیح 64 بیتیِ big-endian با رشد خطی باشد. js-libp2p-gossipsub به‌جای آن 8 بایت تصادفی تولید می‌کرد، در حالی که go-libp2p-pubsub و rust-libp2p هر دو از یک شمارنده استفاده می‌کردند. Kubo نسخه 0.40 به بعد BasicSeqnoValidator را به‌طور پیش‌فرض فعال می‌کند، که هر پیامی را که seqno آن بزرگ‌تر از بیشترین مقدار دیده‌شده از آن همتا نباشد رد می‌کند.

نتیجه این بود که بیشتر پیام‌های منتشرشده توسط یک گره جاوااسکریپتی — از جمله یک گره مرورگر — بی‌سروصدا توسط همتایان Kubo دور ریخته می‌شد. یک نمونه بازتولید نشان داد که از هر 30 پیام تنها 2 تا 8 پیام می‌رسد.

این مشکل در js-libp2p-gossipsub#545 تشخیص داده شد و در @libp2p/gossipsub 15.0.21 در ماه مه 2026 برطرف شد. تا پیش از آن، یک گره مرورگر می‌توانست وصل شود و بخواند، اما پست‌هایش در راه رسیدن به همتایان Go عمدتاً ناپدید می‌شد. pkc-js نسخه 16.0.4 از @libp2p/gossipsub را عرضه می‌کند که پس از آن اصلاح است.

کاری که یک گره مرورگر همچنان نمی‌تواند بکند​

یک گره مرورگر یک همتای واقعی است، نه یک سرور. محدودیت‌هایش با گره دسکتاپ یا گره همیشه‌روشن فرق دارد:

  • معمولاً نمی‌تواند اتصال‌های ورودی دلخواه از اینترنت عمومی را بپذیرد
  • فقط تا وقتی زبانه باز است کار می‌کند، پس میزبان بلندمدتی برای داده‌های یک انجمن نیست
  • نمی‌تواند به DHT شبکه libp2p بپیوندد، و به همین دلیل کشف از راه مسیریاب‌های HTTP انجام می‌شود
  • برای seeding در مقیاس بزرگ گزینه خوبی نیست

میزبانی کامل یک انجمن همچنان بهتر است بر عهده یک اپ دسکتاپ، bitsocial-cli یا گره همیشه‌روشن دیگری باشد. P2P مرورگر تعیین می‌کند چه کسی می‌تواند بدون دروازه بخواند و پست بگذارد؛ نیاز به همتایانی که آنلاین می‌مانند را از میان برنمی‌دارد.

مسیریاب‌های HTTP دروازه نیستند​

کلاینت‌های مرورگر همچنان از مسیریاب‌های HTTP می‌پرسند که در حال حاضر کدام همتایان آدرس یک انجمن را ارائه می‌کنند. این همان ستاره کنارِ عبارت «همتا به همتای خالص در مرورگر» است و ارزش دارد دقیق درباره‌اش حرف بزنیم:

  • یک مسیریاب فقط آدرس همتایان را برای یک آدرس محتوا نگه می‌دارد
  • محتوای انجمن را ذخیره نمی‌کند، ارائه نمی‌دهد و اصلاً از آن خبر ندارد
  • کلاینت‌ها چند مسیریاب را به‌موازات پرس‌وجو می‌کنند و نتایج را با هم ادغام می‌کنند
  • هر کسی می‌تواند یکی راه بیندازد، و عوض کردن مسیریاب فقط یک تغییر پیکربندی است، بدون مهاجرت داده

پس از کشف، انتقال محتوا و ترافیک pubsub همتا به همتا جابه‌جا می‌شوند. مسیریابی که ناپدید شود یک مسیر جست‌وجو را از شما می‌گیرد، نه داده‌هایتان را. در مقابل، یک دروازه IPFS خودش در مسیر محتوا قرار دارد.

امروز کجا اجرا می‌شود​

  • 5chan در وب‌اپ 5chan.app به‌طور پیش‌فرض P2P مرورگر خالص را اجرا می‌کند.

پشتیبان دروازه‌ای​

دسترسی از راه دروازه همچنان به‌عنوان مسیر سازگاری برای مرورگرها یا شبکه‌هایی که نمی‌توانند مستقیم بپیوندند وجود دارد. پشتیبان دروازه‌ای را ببینید. معماری هدف این است که اول P2P مرورگر باشد و دروازه‌ها به‌جای گلوگاه پیش‌فرض، یک پشتیبان اختیاری باشند.