Біткоїнери переходять у Nostr, але чим він відрізняється від Twitter?

Nostr привернув до себе чимало уваги з моменту його додавання до списку альтернативних соціальних платформ, реклама яких у Twitter заборонена. Його популярність збільшується, оскільки стало зрозуміло, що покупка Twitter Ілоном Маском нічого принципово не змінила в плані свободи висловлення думок на платформі – користувачів, як і раніше, блокують з непослідовних і довільних причин, і люди шукають децентралізовану альтернативу, яка відрізнялася б від Mastodon, де оператор сервера все ще має можливість контролювати ваші особисті дані.

Протокол Nostr та перша реалізація сервера ретрансляції були створені ще наприкінці 2020 року розробником fiatjaf. До нинішнього хайпу це був просто нішевий протокол, який планувався як легке розв'язання проблем Twitter і Mastodon. В обох системах ваша особа/ім'я користувача просто контролюється тим, хто керує сервером. Mastodon, федеративна система з безліччю різних серверів, які комунікують один з одним, принципово це не змінює. Чий би сервер ви не використовували для розміщення облікового запису, він повністю контролює, чи можете його використовувати, чи ні. Навіть якщо у вас є власний сервер, інші оператори серверів можуть внести до чорного або білого списку сервери, яким буде дозволено комунікувати з ними. Це призвело до виникнення у Федіверс різних серверів Mastodon і робить ідею запуску власного сервера безглуздою. Зрештою, ви можете піддатися цензурі з боку інших операторів серверів, що не дозволить їхнім користувачам побачити ваш контент у стрічці.

Основна відмінність між Nostr і чимось на зразок Mastodon полягає в тому, що замість використання імені користувача, що належить оператору сервера, кожен користувач використовує пару відкритого/закритого ключів для виконання цієї функції. Це те, що оператор сервера не може просто забрати у вас чи заблокувати. Це один з основних блоків, на якому будується загальний протокол Nostr.

Наступне – «події» (англ. events). Це основний тип об'єкта/даних, що використовується клієнтами та серверами ретрансляції, до яких підключаються клієнти для надсилання та отримання повідомлень. Загальна ідея протоколу полягає в тому, що клієнти надсилають події на сервери ретрансляції, які потім, своєю чергою, зберігають та індексують їх, а інші клієнти можуть зв'язуватися з серверами ретрансляції для запиту подій, які вони отримали та зберегли. У вихідному NIP 01 визначено три різні типи подій:

• 0: Відправляє метадані про користувача, такі як ім'я користувача, зображення, біографія і т.д.
• 1: Надсилає текстові повідомлення та основний контент
• 2: Рекомендує сервери ретрансляції для людей, які стежать за творцем події для підключення.

Усі події структуровані строго певним чином. Вони включають відкритий ключ творця, часову мітку, коли вони були створені, їхній тип (або вид у специфікації), корисне навантаження вмісту і підпис творця події. Вони також можуть містити теги, що посилаються на інші події або користувачів, і мати значення ID, яке є хешем всього, крім підпису творця (аналогічно TXID для Біткоїн-транзакцій). Це гарантує вам, що повідомлення дійсно було створене власником відкритого ключа через перевірку підпису (і особи, якій належить цей ключ, якщо воно не скомпрометоване), та що повідомлення не було змінено після підпису. Так само як ви не можете змінити Біткоїн-транзакцію після того, як вона була підписана, не анулюючи її, ви не можете змінити подію Nostr після того, як її підписав творець, без використання шахрайства.

Система видів подій була значно розширена у порівнянні з вихідним NIP. Існує тип події для зашифрованих прямих повідомлень, що встановлює спільний ключ шляхом об'єднання закритого ключа відправника з відкритим ключем одержувача, в результаті чого виходить той самий ключ, який ви отримали б, об'єднавши відкритий ключ відправника із закритим ключем одержувача (так працюють BIP 47 та Silent Payments). Існують також типи замінних подій та ефемерних подій. Замінна подія (очевидно) розроблена таким чином, щоб початковий творець події міг підписати нову на заміну старої. Сервери ретрансляції на основі специфікації автоматично видалять стару подію зі свого сховища і почнуть надавати нові версії клієнтам. Ефемерні події спроєктовані таким чином, що вони будуть транслюватися всім, хто підпишеться на їхнього творця, під час надсилання на ретранслятор, але сервери ретрансляції не будуть їх зберігати. Таким чином, повідомлення буде видно тільки людям, які знаходяться в мережі під час їхньої трансляції. Існує навіть тип події, щоб показувати реакцію (наприклад, лайки чи смайлики) на події інших людей.

Щодо останнього, події також можуть містити теги. Зараз існують типи тегів для подій (для посилання на конкретну подію Nostr), відкритих ключів (щоб тегнути або зробити посилання на інших користувачів) та тем (для імітації функціональності, наприклад мейлів). Всі вони можуть включати вказівники на певні сервери ретрансляції, з яких можна отримати дані, щоб користувачі могли фактично взаємодіяти між серверами. Тобто користувач, який розміщує свій контент на одному сервері ретрансляції, може взаємодіяти та посилатися на контент, створений іншим користувачем, який публікує його на іншому сервері ретрансляції, так що будь-який користувач може когерентно отримувати весь ланцюжок взаємодій у правильному порядку і без великих складнощів у визначенні, де знайти відповідні дані.

Всередині вихідного NIP дається специфікація того, як клієнти повинні взаємодіяти з серверами ретрансляції через структуру повідомлень/даних підписки, яка включає фільтри для того, які події клієнт зацікавлений отримати. Ці фільтри можуть визначати відкриті ключі користувачів, точні події, типи подій і навіть конкретні часові рамки для них на основі попередніх критеріїв. Ви навіть можете надсилати префікси відкритих ключів або ідентифікаторів подій, наприклад «1xjisj…» і отримувати будь-яку подію або події з відкритого ключа, які починаються з цього короткого рядка (це може бути корисним, щоб приховати від сервера ретрансляції те, що ви дійсно хочете переглянути).

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

Сервери ретрансляції можуть працювати так, як вони хочуть. Вони можуть працювати безплатно, можуть стягувати мікроплатежі за публікацію або завантаження повідомлень і навіть є NIP для вимоги підтвердження роботи в стилі hashcash для надсилання повідомлення. Вони можуть бути єдиним сервером ретрансляції для хостингу та надання іншим користувачам тільки ваших постів, або бути сервером, що працює у великих масштабах, як Twitter або Reddit (клієнти можуть відображати та організовувати інформацію так, як вони хочуть, що дозволяє емулювати практично будь-яку соціальну мережу, що існує сьогодні). Все це може безперешкодно взаємодіяти без змоги заблокувати користувача. Ви можете заборонити розміщувати контент на сервері ретрансляції, але в кінцевому підсумку ви не можете заборонити переглядати контент, який ви розміщуєте на своєму сервері ретрансляції, або заборонити іншим користувачам знаходити контент на інших серверах.

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

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

Це гостьовий пост Шинобі. Висловлені погляди є його власними і не обов’язково збігаються з точкою зору BTC Inc. або Bitcoin Magazine.