עמית לעמית בדפדפן
אפליקציית ווב של 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, כלומר לצמתים האלה נדרשים דומיין ותעודה חתומה בידי רשות אישורים. עמיתים שנמצאים מאחורי חיבורים ביתיים ללא תעודה כזו נגישים בעקיפין במקום בחיבור ישיר מהלשונית.
מדוע פרסום מהדפדפן התחיל לעבוד רק ב-2026
עמית לעמית בדפדפן אינו רעיון חדש. מה שהשתנה ב-2026 הוא שכעת הפוסטים של צומת דפדפן מגיעים לשאר הרשת.
מפרט ה-pubsub של libp2p דורש ש-seqno של הודעה יהיה מספר שלם בן 64 סיביות בסדר big-endian שעולה
באופן ליניארי. במקום זאת, js-libp2p-gossipsub ייצר 8 בתים אקראיים, בעוד ש-go-libp2p-pubsub
ו-rust-libp2p השתמשו שניהם במונה. Kubo 0.40 ומעלה מפעיל את BasicSeqnoValidator כברירת מחדל, והוא
דוחה כל הודעה שה-seqno שלה אינו גדול מהערך הגבוה ביותר שכבר נראה מאותו עמית.
התוצאה הייתה שרוב ההודעות שפורסמו בידי צומת JavaScript — כולל צומת דפדפן — נזרקו בשקט על ידי עמיתי Kubo. שחזור מדוד הראה שרק 2 עד 8 מתוך 30 הודעות הגיעו ליעדן.
הבעיה אובחנה ב-js-libp2p-gossipsub#545
ותוקנה ב-@libp2p/gossipsub 15.0.21 במאי 2026. עד שהתיקון נכנס, צומת דפדפן יכול היה להתחבר
ולקרוא, אבל הפוסטים שלו נעלמו ברובם בדרך לעמיתי Go. pkc-js נשלח עם @libp2p/gossipsub 16.0.4,
שכבר כולל את התיקון.
מה צומת דפדפן עדיין לא יכול לעשות
צומת דפדפן הוא עמית אמיתי, לא שרת. יש לו מגבלות שונות מאלה של צומת שולחן עבודה או צומת שפועל תמיד:
- בדרך כלל הוא אינו יכול לקבל חיבורים נכנסים שרירותיים מהאינטרנט הציבורי
- הוא פועל רק כל עוד הלשונית פתוחה, ולכן הוא אינו מארח לטווח ארוך של נתוני קהילה
- הוא אינו יכול להצטרף ל-DHT של libp2p, ולכן הגילוי עובר דרך נתבי HTTP
- הוא אינו מתאים לשמש מקור הפצה בקנה מידה גדול
אירוח מלא של קהילה עדיין נעשה בצורה הטובה ביותר באמצעות אפליקציית שולחן עבודה, bitsocial-cli או
צומת אחר שפועל תמיד. P2P בדפדפן משנה מי יכול לקרוא ולפרסם בלי שער; הוא אינו מבטל את הצורך בעמיתים
שנשארים מחוברים.
נתבי HTTP אינם שערים
לקוחות דפדפן עדיין שולחים שאילתות לנתבי HTTP כדי לגלות אילו עמיתים מספקים כרגע את כתובת הקהילה. זו הכוכבית הכנה שיש להוסיף לאמירה "עמית לעמית טהור בדפדפן", וכדאי לדייק בה:
- נתב מאחסן רק כתובות של עמיתים עבור כתובת תוכן
- הוא אינו מאחסן, אינו משרת ואף אינו מכיר את תוכן הקהילה
- לקוחות שולחים שאילתות למספר נתבים במקביל וממזגים את התוצאות
- כל אחד יכול להפעיל נתב, והחלפת נתבים היא שינוי הגדרות בלבד ללא הגירת נתונים
אחרי הגילוי, העברת התוכן ותעבורת ה-pubsub זורמות עמית לעמית. נתב שנעלם עולה לכם במסלול חיפוש אחד, לא בנתונים עצמם. שער IPFS, לעומת זאת, נמצא בתוך מסלול התוכן.
איפה זה פועל היום
גיבוי דרך שער
גישה מגובה בשער עדיין קיימת כמסלול תאימות עבור דפדפנים או רשתות שאינם יכולים להצטרף ישירות. ראו גיבוי דרך שער. ארכיטקטורת היעד היא P2P בדפדפן תחילה, כאשר שערים משמשים כגיבוי אופציונלי ולא כצוואר בקבוק שהוא ברירת המחדל.