Nostr

Анна знаходить у Nostr авторів, за якими хоче стежити. Згодом застосунок перестає їй подобатися. Якщо безпечно використати той самий приватний ключ або під’єднаний пристрій підписування в іншому застосунку, ідентичність можна зберегти. Публічний ключ дає іншим змогу впізнавати Анну й перевіряти підписи; приватний — підписувати від її імені. Саме тому npub і nsec принципово різняться. За NIP-19 це записи публічного та приватного ключів у кодуванні Bech32. NIP — пронумеровані документи, які описують правила й розширення Nostr. Кодування — не шифрування: nsec не є безпечним посиланням на профіль, яке можна надсилати будь-кому. Збереження ідентичності також не гарантує, що новий застосунок знайде всі старі дописи чи перенесе кожне налаштування. [2] [7]

Застосунок, який називають клієнтом, підписує допис і надсилає його вибраним relay. Relay — сервер, що приймає повідомлення та зберігає або передає їх за власними правилами. Застосунок Петра під’єднується до таких серверів і запитує цікаві йому дописи. Немає єдиного центрального сервера чи обов’язку копіювати все на кожен сервер. Технічно обмін відбувається через WebSocket, з’єднання, яке залишається відкритим: EVENT передає повідомлення, REQ створює підписку, а OK повідомляє про прийняття чи відхилення. Навіть позитивне OK не підтверджує доставлення Петрові або постійне зберігання. EOSE позначає кінець збережених результатів запиту; після цього підписка може й далі отримувати нові повідомлення. [1] [7]

Коли Петро отримує повідомлення, застосунок перевіряє відповідність підпису зазначеному публічному ключу та незмінність підписаних даних. Це не доводить правдивості тексту чи особи автора поза мережею. Час створення також указує автор, тому він не є незалежною часовою позначкою. Для тих, хто цікавиться технікою: запис event містить pubkey, created_at, kind, tags і content — ключ, час, тип, мітки та вміст. SHA-256 обчислює з точно визначеного запису цих даних коротке контрольне значення id. Воно дає змогу виявити зміну підписаних даних. Поле sig містить Schnorr Signature за BIP340 на кривій secp256k1. Такий підпис означає «ці дані підписав власник відповідного ключа», а не «цьому твердженню можна довіряти». [1]

Довгий публічний ключ важко запам’ятати. NIP-05 дозволяє пов’язати його з ідентифікатором, схожим на адресу електронної пошти. Застосунок запитує у відповідного домену, який ключ належить імені, й порівнює відповідь із ключем профілю. Він перевіряє конкретний зв’язок із доменом, а не автоматично справжнє ім’я, репутацію чи надійність людини. Оператор домену може змінити відповідність. Якщо Анна вже стежить за кимось, визначальним має залишатися початковий публічний ключ; призначення тому самому імені іншого ключа не повинно непомітно змінювати людину, за якою вона стежить. Псевдонімність означає постійне позначення замість справжнього імені, а не гарантію анонімності. [3]

Петрові не потрібно завантажувати всі повідомлення. Він надсилає фільтр, наприклад для певних авторів і типу дописів. Різні умови одного фільтра поєднуються через AND: усі мають виконуватися. Кілька дозволених значень однієї умови — альтернативи OR; так само поєднуються кілька фільтрів у одному REQ. Достатньо відповідати будь-якому з них. limit обмежує початкову порцію збережених результатів, а не автоматично майбутні повідомлення підписки. NIP-01 використовує в подіях і фільтрах шістнадцятковий запис ключів, а не користувацький формат npub. Порожня видача може бути наслідком фільтра, вибору сервера або його архіву; вона не доводить, що допису немає ніде. [1]

Анна змінює опис профілю й хоче, щоб інші бачили новий. Тому Nostr розрізняє, що саме сервери мають зберігати. Для замінюваних подій вони обирають найновіший запис із тією самою парою pubkey і kind. Адресовані події додатково використовують значення мітки d, що розрізняє, наприклад, документи одного автора. Якщо замінювані записи мають однаковий час, рекомендовано залишати лексикографічно менший id — перший за порядком його написання. Тимчасові події, які називають ephemeral, узагалі не передбачають зберігання. Це домовленості, і поведінка серверів може відрізнятися. Отже, Nostr не є реєстром, у якому вся мережа погоджує єдину незмінну історію. [1]

Анна помічає, що оприлюднила те, що мало залишитися приватним. NIP-09 дозволяє надіслати підписаний запит на видалення. Перш ніж виконати його, клієнт має перевірити, що запит і початковий допис належать тому самому публічному ключу. Стороння людина не може видалити допис Анни, лише пославшись на нього. Сервери й застосунки, які співпрацюють, можуть прибрати вміст або припинити його показувати. Проте запит не видалить усі копії, знімки екрана чи незалежні архіви. Прихований в одному застосунку допис може залишатися доступним на іншому сервері. Тому важливіше те, що ви публікуєте, ніж сама наявність кнопки «Видалити». [4]

Публічний допис може прочитати кожен, хто його отримає; сам підпис не приховує вміст. Для приватних повідомлень є додаткові правила. NIP-44 описує шифрування вмісту, а NIP-17 — обгортання й доставлення повідомлень із додатковими шарами захисту. Це не автоматична анонімність: мережеві адреси, час і поведінка застосунку можуть далі розкривати інформацію. Таке шифрування також не забезпечує forward secrecy — захисту давніх розмов у разі пізнішого витоку довготривалого ключа. Хто отримає потрібний приватний ключ і раніше записані зашифровані повідомлення, зможе прочитати й минуле листування. Перевіряйте, які розширення справді підтримує застосунок: назва «Nostr» сама собою не описує його рівня приватності. [5] [6]