Bitsocial і Nostr
Nostr не вкладається чітко ні у федеративну, ні в блокчейн-категорію. Облікові записи користувачам не видають інстанси, і тут немає ані ланцюжка, ані консенсусу, ані газу, ані глобального впорядкування. Nostr краще описувати як соціальні медіа на основі реле: користувачі тримають пари ключів, підписують події та публікують їх на реле — звичайні сервери, які ці події зберігають і віддають (NIP-01). Власний README Nostr каже, що протокол не спирається на однорангові методи.
Це робить Nostr ближчим до Bitsocial, ніж федеративні чи блокчейн-системи, в одному важливому аспекті: ідентичність криптографічна й переносна. Відмінності — у рівні даних і в тому, хто контролює вхід.
Як працює Nostr
- Події та реле. Кожен допис, профіль чи реакція — це підписана JSON-подія. Клієнти публікують події на реле через WebSockets і підписуються на них за фільтрами; реле зберігають події та віддають їх назад. Реле не спілкуються між собою.
- Реплікація. Користувачі зазвичай публікують на кілька реле. Дослідження 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-маршрутизатори лише допомагають клієнтам знайти вузли. Вони не зберігають ані дописів, ані профілів, ані метаданих спільнот, ані стану модерації; клієнти отримують вміст від вузла спільноти та вузлів, які її роздають. Див. Одноранговий протокол.
Хто контролює вхід
У Nostr контроль запису належить операторам реле. Поза групами NIP-29 ключ, який відхилило одне реле, може опублікувати ту саму подію на будь-якому реле, що її прийме, а те, що бачать читачі, залежить від того, з яких реле читає їхній клієнт. Група NIP-29 ближча до спільноти Bitsocial: дописи приймає чи відхиляє її реле-хост. Проте реле все одно визначає, що можуть робити ролі в групі, а історія групи лишається прив’язаною до цього реле, якщо інше реле не погодиться її перебрати.
У Bitsocial спільнота — це криптографічний об’єкт із власною парою ключів. Вузол спільноти запускає ту перевірку, яку обере власник, і публікує прийнятий стан в однорангову мережу. Див. Спеціальні виклики захисту від спаму.
Утримання інфраструктури
Реле — це сервер із доменом і точкою доступу WebSocket, а популярні реле несуть витрати на сховище й трафік для всього, що віддають. Дослідження 2023 року оцінило, що близько 95% безкоштовних реле не можуть покрити свої витрати з пожертв. Вузол спільноти Bitsocial працює на споживчому обладнанні, а вузли, які читають спільноту, можуть допомагати її поширювати.
Браузер
Вебклієнт Nostr відкриває WebSocket-з’єднання безпосередньо з реле, тож сервер застосунку не потрібен. Вебзастосунок Bitsocial запускає одноранговий вузол у вкладці та отримує вміст від інших вузлів. Див. Одноранговий зв’язок у браузері.
Старий вміст
Дописи Nostr широко реплікуються між реле, що допомагає старим дописам вціліти. Bitsocial зберігає останній стан спільноти й не гарантує збереження старого вмісту назавжди.
Порівняння
| Питання | Nostr | Bitsocial |
|---|---|---|
| Категорія | Протокол на основі реле | Однорангова мережа спільнот |
| Ідентичність | Ключ користувача secp256k1, без ротації в специфікаціях | Пари ключів Ed25519 для користувачів і спільнот |
| Де зберігаються дописи | Реле, обрані автором, часто численні | Вузол власника спільноти та вузли, які її читають і роздають |
| Хто тримає це онлайн | Оператори реле | Вузол власника спільноти плюс допоміжні сідери |
| Спільноти | Групи, розміщені на реле (NIP-29) | Повноцінні об’єкти, чий вузол приймає або відхиляє дописи |
| Захист від спаму | Політика кожного реле: доказ виконаної роботи, автентифікація, оплата, списки дозволених, обмеження частоти | Антиспам-перевірка кожної спільноти перед прийняттям допису |
| Модерація | Політики реле, клієнтські списки ігнорування, мітки та скарги | Власники спільнот модерують свої спільноти; застосунки вирішують, що показувати |
| Імена | Необов’язкові ідентифікатори name@domain, які перевіряються через HTTPS | Імена .bso і .eth, які вказують на ключі |
| Браузер | WebSocket-клієнт реле | Одноранговий вузол у звичайній вкладці браузера |
| Головний компроміс | Переносна ідентичність і широка реплікація, але доступність і політика залежать від реле | Менша залежність від реле, але старий вміст не гарантований назавжди |