Bitsocial و Nostr
Nostr به‌روشنی نه در دستهٔ سامانه‌های فدرال می‌گنجد و نه در دستهٔ سامانه‌های بلاک‌چینی. کاربران حسابشان را از نمونه‌ها نمی‌گیرند و هیچ زنجیره، اجماع، گس یا ترتیب سراسری‌ای در کار نیست. توصیف بهتر Nostr رسانهٔ اجتماعی مبتنی بر رله است: کاربران جفت‌کلید دارند، رویدادها را امضا می‌کنند و آن‌ها را روی رله‌ها منتشر می‌کنند؛ رله‌ها سرورهای معمولی‌ای هستند که این رویدادها را ذخیره و ارائه می‌کنند (NIP-01). README خود Nostr می‌گوید که به تکنیک‌های همتا به همتا متکی نیست.
همین از یک جهت مهم Nostr را به Bitsocial نزدیک‌تر می‌کند تا به سامانه‌های فدرال یا بلاک‌چینی: هویت رمزنگارانه و قابل‌حمل است. تفاوت‌ها در لایهٔ داده است و در اینکه دروازه در دست چه کسی است.
Nostr چگونه کار می‌کند
- رویدادها و رله‌ها. هر پست، پروفایل یا واکنش یک رویداد JSON امضاشده است. کلاینت‌ها رویدادها را از طریق WebSocket روی رله‌ها منتشر می‌کنند و با فیلترها مشترک می‌شوند؛ رله‌ها رویدادها را ذخیره می‌کنند و دوباره ارائه می‌دهند. رله‌ها با یکدیگر ارتباط ندارند.
- تکثیر. کاربران معمولاً روی چند رله منتشر می‌کنند. پژوهشی دربارهٔ 712 رله در سال 2023 نشان داد که هر پست به‌طور میانگین روی 34.6 رله وجود دارد (Wei و Tyson).
- یافتن پست‌های یک نفر. کاربران فهرستی از رله‌هایی را که روی آن‌ها می‌نویسند و از آن‌ها می‌خوانند منتشر می‌کنند (NIP-65)، و کلاینت‌ها پست‌های هر کاربر را از رله‌های نوشتنِ همان کاربر می‌گیرند.
- هویت. هر کاربر یک کلید secp256k1 است که با امضاهای Schnorr امضا می‌کند. مشخصات فنی هیچ چرخش یا
بازیابی کلیدی تعریف نمی‌کنند، پس گم شدن کلید یعنی از دست رفتن حساب. شناسه‌های اختیاری
name@domain(NIP-05) با فایلی روی وب‌سرورِ همان دامنه بررسی می‌شوند. - گروه‌ها. سازوکار پیشنهادی برای انجمن‌ها گروه‌های مبتنی بر رله است (NIP-29): یک رله میزبان گروه است، پیش از پذیرفتن هر پست قواعد عضویت و پست‌گذاری گروه را اعمال می‌کند و فرادادهٔ گروه را امضا می‌کند. انجمن‌های قدیمی‌ترِ تأییدشده توسط ناظر (NIP-72) اکنون به نفع NIP-29 «توصیه‌نشده» علامت خورده‌اند.
- مهار اسپم. هر رله دروازهٔ خودش را انتخاب می‌کند: اثبات کار (NIP-13)، احراز هویت و فهرست‌های مجاز (NIP-42)، پرداخت یا محدودیت نرخ. کلاینت‌ها فهرست‌های بی‌صداسازی و امتیازهای اعتماد را به این‌ها اضافه می‌کنند.
- رسانه. تصاویر و ویدیوها روی سرورهای فایل HTTP جداگانه بارگذاری می‌شوند.
تفاوت‌ها کجاست
چه کسی پست‌ها را ذخیره و ارائه می‌کند
در Nostr، رله‌ها لایهٔ ذخیره‌سازی و تحویل‌اند: یک سرور باید هر پست را آنلاین نگه دارد. در Bitsocial، روترهای HTTP فقط به کلاینت‌ها کمک می‌کنند همتاها را پیدا کنند. آن‌ها پست، پروفایل، فرادادهٔ انجمن یا وضعیت نظارت را ذخیره نمی‌کنند؛ کلاینت‌ها محتوا را از گرهٔ انجمن و همتاهایی که آن را seed می‌کنند می‌گیرند. پروتکل همتا به همتا را ببینید.
دروازه در دست کیست
در Nostr، دروازه‌های نوشتن در اختیار گردانندگان رله‌هاست. بیرون از گروه‌های NIP-29، کلیدی که یک رله ردش کرده می‌تواند همان رویداد را روی هر رلهٔ دیگری که آن را بپذیرد منتشر کند، و آنچه خوانندگان می‌بینند به این بستگی دارد که کلاینتشان کدام رله‌ها را می‌خواند. گروه NIP-29 به انجمن Bitsocial نزدیک‌تر است: رلهٔ میزبانش پست‌ها را می‌پذیرد یا رد می‌کند. با این حال، رله همچنان تعیین می‌کند که نقش‌های گروه چه کارهایی می‌توانند بکنند، و تاریخچهٔ گروه به همان رله گره خورده می‌ماند، مگر اینکه رلهٔ دیگری بپذیرد آن را تحویل بگیرد.
در Bitsocial، انجمن یک شیء رمزنگارانه با جفت‌کلید خودش است. گرهٔ انجمن هر چالشی را که مالک انتخاب کند اجرا می‌کند و وضعیت پذیرفته‌شده را در شبکهٔ همتا به همتا منتشر می‌کند. چالش‌های ضد اسپم سفارشی را ببینید.
اداره کردن زیرساخت
رله سروری است با یک دامنه و یک نقطهٔ پایانی WebSocket، و رله‌های پرطرفدار هزینهٔ ذخیره‌سازی و پهنای باندِ هر آنچه ارائه می‌کنند را به دوش می‌کشند. پژوهش سال 2023 برآورد کرد که حدود 95 درصد از رله‌های رایگان نمی‌توانستند هزینه‌هایشان را از محل کمک‌های مالی تأمین کنند. گرهٔ انجمن Bitsocial روی سخت‌افزار معمولی اجرا می‌شود، و همتاهایی که یک انجمن را می‌خوانند می‌توانند در پخش آن کمک کنند.
مرورگر
کلاینت وب Nostr اتصال‌های WebSocket را مستقیماً با رله‌ها برقرار می‌کند، پس به سرور برنامه نیازی نیست. اپ وب Bitsocial یک گرهٔ همتا به همتا را در خود زبانه اجرا می‌کند و محتوا را از همتاها می‌گیرد. همتا به همتا در مرورگر را ببینید.
محتوای قدیمی
پست‌های Nostr به‌طور گسترده روی رله‌ها تکثیر می‌شوند و همین به ماندگاری پست‌های قدیمی کمک می‌کند. Bitsocial آخرین وضعیت انجمن را نگه می‌دارد و ماندگاری همیشگی محتوای قدیمی را تضمین نمی‌کند.
مقایسه
| پرسش | Nostr | Bitsocial |
|---|---|---|
| دسته | پروتکل مبتنی بر رله | شبکهٔ انجمنی همتا به همتا |
| هویت | کلید کاربری secp256k1، بدون چرخش کلید در مشخصات فنی | جفت‌کلیدهای Ed25519 برای کاربران و انجمن‌ها |
| پست‌ها کجا نگهداری می‌شوند | رله‌هایی که نویسنده انتخاب می‌کند، اغلب چندین رله | گرهٔ مالک انجمن و همتاهایی که آن را می‌خوانند و seed می‌کنند |
| چه کسی آنلاین نگهش می‌دارد | گردانندگان رله‌ها | گرهٔ مالک انجمن به‌علاوهٔ seederهای کمکی |
| انجمن‌ها | گروه‌های میزبانی‌شده روی رله (NIP-29) | اشیای درجه‌یک که گره‌شان پست‌ها را می‌پذیرد یا رد می‌کند |
| مهار اسپم | سیاست هر رله: اثبات کار، احراز هویت، پرداخت، فهرست‌های مجاز، محدودیت نرخ | چالش هر انجمن پیش از پذیرفته شدن یک پست |
| نظارت بر محتوا | سیاست‌های رله، فهرست‌های بی‌صداسازی در کلاینت، برچسب‌ها و گزارش‌ها | مالکان انجمن بر انجمن خود نظارت می‌کنند؛ اپ‌ها انتخاب می‌کنند چه چیزی را نشان دهند |
| نام‌ها | شناسه‌های اختیاری name@domain که از طریق HTTPS بررسی می‌شوند | نام‌های .bso و .eth که به کلید نگاشت می‌شوند |
| مرورگر | کلاینت WebSocket رله‌ها | گرهٔ همتا به همتا درون یک زبانهٔ معمولی مرورگر |
| معاوضهٔ اصلی | هویت قابل‌حمل و تکثیر گسترده، اما دسترس‌پذیری و سیاستِ وابسته به رله | وابستگی کمتر به رله، اما محتوای قدیمی برای همیشه تضمین نمی‌شود |