Як насправді працює Nostr: протокол без жаргону

Більшість пояснень Nostr зупиняються на "це децентралізований протокол соціальної мережі" і залишають цікавої частини невисловленою. Цікава частина у тому, що весь протокол входить у коротку документацію. Ніяких хитрих трюків, ніякої прихованої складності. Просто кілька примітивів, які працюють разом.

Цей посібник проходить через ці примітиви в порядку, в якому вони з'являються, коли ви насправді використовуєте Nostr: як будується событие, як воно підписується, як воно потрапляє до реле, як клієнти підписуються, і як виглядає потік, коли ви лайкаєте пост, отримуєте відповідь або отримуєте zap. Без порівнянь блокчейну, без великої розповіді. Просто механіка.

TL;DR. Nostr — це pub/sub над WebSockets з криптографічними підписами. Клієнти публікують підписані JSON об'єкти (события) до реле (невеликих серверів), а інші клієнти підписуються на реле з фільтрами, які відповідають события, які вони хочуть. Підписи запобігають підробці; кілька реле запобігають єдиним точкам відмови. Це весь протокол; усе інше — конвенції форматування для різних типів вмісту.

Коли будете готові, заберіть адресу @nostr.blog →

Основний елемент: событие

Все на Nostr — це событие. Пост — це событие. Реакція — це событие. Оновлення профілю — це событие. Прямі повідомлення — це событие. Квитанція zap — це событие.

Событие — це JSON об'єкт з точно такою структурою:

{
  "id": "abc123...",
  "pubkey": "0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88",
  "created_at": 1776329035,
  "kind": 1,
  "tags": [
    ["t", "nostr"],
    ["p", "3bf0c63f..."]
  ],
  "content": "hello nostr",
  "sig": "def456..."
}

Шість полів виконують змістовну роботу. id — це хеш власного вмісту события; він однозначно ідентифікує событие. pubkey — це автор (64-символьний шістнадцятковий публічний ключ). created_at — це мітка часу Unix. kind — це ціле число, яке описує, що представляє событие (більше про це нижче). tags — це список структурованих анотацій, таких як хештеги (t), згадування (p для pubkey, e для события), та десятки інших. content — це вільний корисний навантаження, зазвичай текст.

sig — це підпис Schnorr, зроблений з приватним ключем автора, над хешем у id. Це поле, яке запобігає підробці: будь-хто може обчислити хеш, але тільки власник приватного ключа може створити валідний підпис на ньому.

Що таке "kind"

Поле kind говорить клієнтам, як інтерпретувати событие. Число — це весь семантичний тип.

Кілька種종у активному використанні:

Нові kinds пропонуються та стандартизуються через NIPs (Nostr Implementation Possibilities). Будь-хто може запропонувати один. Ті, що отримають широке поширення, стають de facto частинами протоколу; ті, які цього не роблять, просто залишаються нішевими без порушення чогось.

Як событие публікується

Коли ви натискаєте "опубліковувати" у клієнтові Nostr, виконується така послідовність:

1. Клієнт складає JSON. Заповнює pubkey, created_at, kind, tags, content.
2. Клієнт обчислює id. Запускає SHA-256 над канонічною серіалізацією цих полів. Це хеш, який підпис покриває.
3. Клієнт підписує id приватним ключем. Підпис Schnorr над secp256k1, тою ж кривою, яку використовує Bitcoin. 64-байтовий підпис стає полем sig.
4. Клієнт відкриває з'єднання WebSocket до кожного налаштованого реле. Або повторно використовує існуючі відкриті, якщо вони активні.
5. Клієнт надсилає событие як повідомлення. Формат на дроті — це масив JSON: ["EVENT", {...event...}].
6. Кожне реле валідує підпис. Відхиляє событие, якщо підпис не перевіряється щодо заявленого pubkey. В іншому випадку приймає та зберігає.
7. Кожне реле штовхає событие до підписників. Будь-який клієнт з відкритою підпискою, чий фільтр відповідає цьому подіїї, отримує событие в реальному часі.

Весь раунд-трип займає від 50 до 300 мілісекунд залежно від місцеположення реле. Якщо якесь реле повільне або офлайн, інші реле все одно публікують событие. Вам потрібне тільки одне реле, щоб прийняти його, щоб событие існувало в мережі.

Як клієнт отримує пости

Читання — це дзеркало публікування.

Ваш клієнт відкриває з'єднання WebSocket до списку реле. Для кожного він надсилає повідомлення підписки:

["REQ", "sub_id_1", { "authors": ["pubkey1", "pubkey2", ...], "kinds": [1, 6], "limit": 50 }]

Це просить реле до 50 событий від авторів у списку, kind 1 (коротка нотатка) або kind 6 (репост). Реле:

1. Запитує свою локальну базу даних для відповідних событій, надсилає їх (від найстарішого до найновішого за замовчуванням, до ліміту) як EVENT повідомлення назад клієнтові.
2. Надсилає EOSE (кінець збережених событій) повідомлення, щоб клієнт знав, що історичний дамп завершений.
3. Тримає підписку відкритою. Будь-яке нове событие, яке відповідає фільтру (опубліковане кимось іншим пізніше), штовхається клієнтові в реальному часі.

Так ваша стрічка стає живою. Ви не опитуєте; реле передає.

Ваш клієнт робить це паралельно через кожне налаштоване реле. Об'єднання відповідей — це ваша стрічка часу. Дублювання событій через реле видаляються за id.

Як підписи насправді запобігають підробці

Це частина, яку більшість пояснень обходять.

Коли клієнт отримує событие, він перерахує хеш над канонічною серіалізацією (тим же способом, що й видавець) і запускає верифікацію Schnorr: з урахуванням pubkey, id та sig, чи криптографічно перевіряється підпис?

Якщо так, событие автентичне. Автор цього события був власником цього pubkey в момент підписання. Кожен клієнт запускає цю перевірку на кожному событії. Реле, яке постачає підроблене событие з невірною підписом, просто видаляється мовчазно кожним клієнтом, який його бачить.

Це має значення, тому що це означає, що реле ненадійні. Зловмисне реле не може вкладати слова вам у рот. Це може відмовитися служити вашим постам, може впроваджувати чужі (легітимні) пости у вашу стрічку, але воно не може створити валідний пост, підписаний вами, без вашого приватного ключа, і не може змінити один із ваших існуючих постів без порушення підпису.

Вартість цієї властивості — це точно одна верифікація Schnorr на событие, яка достатньо швидка, щоб навіть мобільні клієнти обробляли десятки тисяч событій на секунду.

Що насправді роблять реле

Реле — це тупа, швидка труба з трьома завданнями:

1. Приймайте события та валідуйте підписи. Відхиляйте все, що не перевіряється або не задовольняє перевірки політики (фільтри спаму, обмеження розміру, заблоковані pubkey).
2. Зберігайте события. Зазвичай у базі даних SQLite або PostgreSQL, індексованої за id, pubkey, kind та значеннями тегів.
3. Служіть підискам. Відповідайте вхідним фільтрам REQ щодо бази даних (для історичного) та щодо живих событій (для реального часу).

Це все. Реле не ранжує, не рекомендує, не курує, не монетизує, не показує рекламу, не застосовує алгоритм та нічого більше, що робила б платформа. Воно передає підписані байти.

Відсутність цих інших завдань — це чому реле можуть бути крихітними. Один VPS за $5 на місяць може запустити реле, що служить сотням активних користувачів. Та ж функція в масштабі Twitter коштує мільярди, тому що Twitter робить усі інші речі.

Політики реле відрізняються. Деякі – безпроблемні та служать будь-якому підписаному событіїю. Деякі потребують платежу (модель "платного реле"), інші обмежуються певною спільнотою (працівники компанії, члени Discord сервера), і ще інші активно фільтрують спам. Ви вибираєте, які реле використовувати; ваш вибір впливає на те, які пости ви бачите та які досягають ваших послідовників.

Повний приклад: комусь подобається ваш пост

Поєднуючи це, ось що відбувається наскрізь, коли Аліса подобається пост Боба.

1. Боб публікує. Клієнт Боба будує событие kind:1 з вмістом "hello world," підписує його, надсилає його п'яти налаштованим реле Боба. Кожне реле приймає та зберігає.
2. Аліса підписується. Клієнт Аліси має відкриту підписку на двох з цих реле з фільтром, який включає pubkey Боба в authors. Реле штовхають событие Боба вниз по підписці. Клієнт Аліси показує пост в її стрічці часу.
3. Аліса натискає лайк. Клієнт Аліси будує событие kind:7 з вмістом "+" (конвенція Nostr "лайку"), позначає пост, на який вона реагує (["e", "bob_post_id"]) та автора (["p", "bob_pubkey"]). Підписує та публікує на п'ять налаштованих реле Аліси.
4. Реакція поширюється. Будь-яке реле, яке має активну підписку, відповідну фільтру { "#e": ["bob_post_id"], "kinds": [7] } (що використовує клієнт Боба для спостереження за реакціями на його власні пости), штовхає реакцію до Боба. Клієнт Боба агрегує лайки та показує кількість під постом.

Зверніть увагу на те, що не сталося. Жоден централізований сервіс "кнопки лайку" не був запущений. Жоден backend не вирішував, чи лайкується. Лайк — це просто підписане событие, оголошене на тих же каналах, що й сам пост.

Що Nostr свідомо не робить

П'ять речей, виключених з базового протоколу навмисне, тому що вони належать до клієнта або реле, а не до спільного формату дроту.

• Верифікація ідентичності. Nostr тільки доводить "цей pubkey підписав цей пост." Чи належить pubkey конкретній людині — це окреме питання, на яке відповідає NIP-05 та позаланцюжковий контекст.
• Модерація вмісту. Протокол не вирішує, що видимо. Клієнти фільтрують, реле фільтрують, користувачі фільтрують. Кожен рівень незалежно.
• Пошук. Немає глобальної кінцевої точки пошуку. Деякі реле підтримують текстовий пошук по своєму локальному пулу событій; немає гарантії протоколу, що будь-яке реле може знайти будь-який пост.
• Ранжування алгоритмом. Немає стрічки "для вас" у протоколі. Ранжування відбувається в клієнтові, якщо взагалі.
• Відновлення облікового запису. Немає скидання електронної пошти, немає скидання телефону, немає централізованої системи спорів. Втратили приватний ключ, втратили ідентичність. Це компроміс, не помилка.

Ці відсутності — це те, що робить протокол малим. Вони також те, що робить розробку поліруваного користувацького досвіду на вершині складнішою, ніж будівництво на централізованій платформі, що є чесною вартістю.

Чому дизайн взагалі працює

Дизайн спирається на одну просту властивість: підписи дешеві для верифікації, підробка неможлива без приватного ключа, і реле можна вільно замінити.

Ці три факти складаються разом. Дешева верифікація означає, що кожен клієнт може перевірити кожне событие. Неможлива підробка означає, що реле не потрібно довіряти. Вільна заміна означає, що жодне реле не має влади над кимось.

Разом у вас є соціальна мережа, де рівень платформи є взаємозамінюваним, а рівень ідентичності належить користувачеві. Що насправді означає "децентралізований" на практиці, на відміну від того, як маркетинг зазвичай використовує слово.

Якщо ви хочете побачити весь потік з боку користувача (пару ключів, ідентичність NIP-05, список реле, гаманець, готовий до публікації), реєстрація nostr.blog об'єднує ці кроки на одну сторінку. Механіка, описана тут, — це те, що насправді працює під цим потоком.