Nostr — відкритий протокол підписаних подій, якими клієнти обмінюються через незалежні ретранслятори. Соціальні мережі — одне із застосувань; протокол не має власного блокчейну чи спільного консенсусу всіх ретрансляторів.
Подія містить pubkey, created_at, kind, tags, content, id і sig. NIP-01 отримує id через SHA-256 із точно визначеної серіалізації та використовує BIP340 на secp256k1. Клієнт перевіряє цілісність і авторизацію ключем. created_at указує автор; це не незалежна позначка часу й не доказ правдивості. [Nostr — NIP-01: Basic protocol] [fiatjaf — Original Nostr description]
Клієнт публікує EVENT і підписується через REQ за WebSocket. OK повідомляє про прийняття чи відхилення саме цим ретранслятором. EOSE завершує перелік збережених подій, але не обов’язково підписку на нові. Жодне повідомлення не підтверджує одержання адресатом, загальну реплікацію чи постійне зберігання. [Nostr — NIP-01: Basic protocol]
В одному фільтрі подія має виконувати всі умови: автор і тип означають AND. Кілька фільтрів у REQ поєднуються через OR; досить одного. limit обмежує початковий перелік, а не число майбутніх подій. Відсутність результату може означати обмежену історію ретранслятора, а не неіснування події. [Nostr — NIP-01: Basic protocol]
Замінювані події порівнюють за pubkey і kind, адресовані — також за тегом d. Новіша версія може замінити стару; за однакового часу перемагає лексикографічно менший id. Ефемерні події не передбачають зберігання. Це правила ретранслятора, а не незмінний світовий архів; реалізації можуть відрізнятися. [Nostr — NIP-01: Basic protocol]
NIP-19 використовує Bech32 для відображення: npub — відкритий ключ, nsec — приватний. Кодування не є шифруванням. Передати nsec означає передати таємний ключ, а не просто посилання на профіль. Події й фільтри NIP-01 використовують шістнадцяткові відкриті ключі, а не форму npub. [Nostr — NIP-19: Encoded entities]
NIP-05 пов’язує ім’я, схоже на електронну адресу, з відкритим ключем за відповіддю домену. Це підтверджує зв’язок, а не справжню особу чи чесність. Клієнт має стежити за початковим ключем: коли домен прив’язує ім’я до іншого ключа, він не повинен автоматично замінити ним раніше обраний профіль. [Nostr — NIP-05: Internet identifiers]
NIP-09 визначає прохання автора видалити його події. Перед приховуванням клієнт має перевірити однаковий відкритий ключ оригіналу й запиту. Ретранслятори та клієнти можуть виконати запит, але протокол не видалить кожну завантажену чи збережену копію. Видалення в одному інтерфейсі не доводить глобального стирання. [Nostr — NIP-09: Deletion requests]
NIP-44 визначає зашифрований payload, а не повну систему приватних повідомлень; NIP-17 додає обгортки й правила доставлення. Саме NIP-44 не забезпечує forward secrecy після пізнішого витоку ключа. Мережеві адреси, час і поведінка клієнта залишаються важливими. Підтримку окремих NIP треба розрізняти за застосунком. [Nostr — NIP-44: Encrypted payloads] [Nostr — NIP-17: Private messages]
Для повної картини прочитайте також Nostr Wallet Connect, Schnorr signature, Приватний ключ, Приватність у Bitcoin, Псевдонімність. На цю статтю також посилаються Nostr Wallet Connect, Network Effect.