Nostr: протокол социальных сетей на ключах и реле

Nostr расшифровывается как «Notes and Other Stuff Transmitted by Relays» — «заметки и прочее, передаваемое через реле». Это открытый протокол для социальных приложений, придуманный разработчиком под псевдонимом fiatjaf. Его отправная идея проста до дерзости: чтобы построить социальную сеть, которую нельзя забанить, не нужны ни серверы с аккаунтами, ни сложная P2P-механика. Достаточно двух вещей — криптографических ключей и «глупых» серверов-ретрансляторов, которые только принимают подписанные сообщения и раздают их дальше.¹

Ниже — как устроен протокол, как им пользоваться, какие есть клиенты, в чём его реальные преимущества и, что важнее, на какие ограничения стоит смотреть трезво. Последнее — не придирки: у Nostr есть системные слабости, которые признаёт даже его создатель.

Как устроен протокол

В Nostr есть ровно два типа участников и один тип данных.

Клиенты — это приложения (мобильные, веб, десктоп), с которыми работает пользователь. Реле (relays) — простые серверы на WebSocket, которые хранят и пересылают сообщения. Сам создатель описывает реле нарочито уничижительно: «Реле очень простое и глупое. Оно не делает ничего, кроме приёма постов от одних и пересылки другим. Реле не обязаны быть доверенными».¹ Вся логика — фильтрация, лента, шифрование — живёт в клиенте, а не на сервере.

Единственный объект в сети — событие (event). Это JSON фиксированной формы с полями id, pubkey, created_at, kind, tags, content и sig.² Поле id — это SHA-256-хеш от канонической сериализации массива [0, pubkey, created_at, kind, tags, content] с жёсткими правилами форматирования (UTF-8, без лишних пробелов).² Подпись sig считается по стандарту Schnorr-подписей на кривой secp256k1 — той же, что в Bitcoin.² Спецификация формулирует это дословно: «Подписи, публичный ключ и кодировки выполняются согласно стандарту Schnorr-подписей для кривой secp256k1».²

Из этого следует главное свойство протокола: личность пользователя — это пара ключей, а не запись на сервере. Публичный ключ и есть аккаунт. Кто угодно может проверить подпись события и убедиться, что его создал владелец приватного ключа. Никакой центральный сервер для этого не нужен.

Тип события задаёт поле kind. Базовый набор описан в реестре NIP: 0 — метаданные профиля, 1 — короткая текстовая заметка (аналог твита), 3 — список подписок, 5 — запрос на удаление, 10002 — список реле пользователя.³ Обмен между клиентом и реле идёт короткими сообщениями: клиент шлёт EVENT (опубликовать), REQ (подписаться на события по фильтру) и CLOSE; реле отвечает EVENT, OK, EOSE (конец сохранённых событий), CLOSED и NOTICE.²

NIP — как протокол растёт

Расширения Nostr описываются документами NIP (Nostr Implementation Possibilities) в общем репозитории. Важная оговорка из README реестра: «Перечисленные здесь NIP — не чеклист протокола. Ничто не заставляет ПО реализовывать какой-либо NIP».³ Клиент реализует те расширения, которые ему нужны, и это одновременно сила (гибкость) и слабость (фрагментация — о ней ниже).

Несколько NIP полезно знать сразу:

• NIP-19 вводит человекочитаемые идентификаторы в кодировке bech32: npub для публичного ключа, nsec для приватного, note для id события.⁴ Именно npub... и nsec... видит пользователь. При этом спецификация подчёркивает, что эти кодировки — только для отображения и ввода, внутри самих событий и фильтров используется «сырой» hex-ключ.⁴
• NIP-05 сопоставляет ключу человекочитаемый адрес вида имя@домен через DNS.⁵ Проверка идёт запросом к https://<домен>/.well-known/nostr.json?name=<имя>. Ключевое: «Клиенты всегда должны следовать за публичными ключами, а не за NIP-05-адресами».⁵ То есть NIP-05 — это удобное имя, а не удостоверение личности.
• NIP-65 описывает список реле пользователя (событие kind:10002 с тегами r, помеченными read/write). Это основа «модели outbox»: клиент узнаёт, куда автор публикует свои записи (write-реле) и где искать упоминания и ответы (read-реле).⁶

Как начать пользоваться

Онбординг в Nostr ведёт клиент, а не сайт-регистратор. В приложении (Primal, Damus, Amethyst) нажимаете «Создать аккаунт» — и клиент прямо на устройстве генерирует пару ключей.⁷ Никакого email, телефона или пароля.

Отсюда — первое и самое важное правило: сразу сохраните nsec в надёжном месте. Потеря приватного ключа означает безвозвратную потерю аккаунта. Гайд по управлению ключами формулирует без обиняков: «Восстановления нет и сброса пароля нет. Если вы потеряете nsec, вы навсегда теряете доступ к этой личности».⁷ Рекомендуемая схема резервной копии — «3-2-1»: менеджер паролей плюс две физические копии, с обязательной проверкой восстановления до того, как на неё полагаться.⁸

Реле настраиваются в клиенте. По умолчанию приложение подключит вас к нескольким популярным реле; при желании список правится вручную. По модели outbox чтение маршрутизируется по спискам реле авторов (NIP-65), а запись идёт только на ваши собственные write-реле.⁶ Сколько держать реле — вопрос реализации клиента, а не протокола; на практике это обычно несколько штук.⁶

NIP-05-адрес (имя@домен) стоит настроить, если хотите узнаваемое имя вместо строки npub1.... Это либо услуга хостинг-провайдера, либо файл .well-known/nostr.json на своём домене.⁹

Zaps — встроенные микроплатежи через Lightning Network — то, чего нет в других соцсетях. Чтобы отправлять и получать «запы», нужны Lightning-кошелёк с поддержкой Zaps (Alby, Wallet of Satoshi) и клиент, который это умеет (Primal, Damus, Amethyst).¹⁰ Механика описана в NIP-57: клиент формирует запрос на «зап» (событие kind:9734), кошелёк получателя после оплаты создаёт квитанцию (kind:9735) и публикует её в реле, а клиенты сверяют квитанцию с заявленным nostrPubkey провайдера.¹¹

Управление ключами: главное, на чём легко обжечься

Поскольку nsec = аккаунт, вставлять его в каждый клиент и веб-сайт опасно. Практическая «лестница риска» выглядит так:¹²

1. Сырой nsec в поле ввода — максимальный риск, только для одноразовых ключей.
2. Браузерное расширение (NIP-07) — nos2x, Alby. Клиент через window.nostr просит подписать событие, не получая сам ключ.¹³ Расширение становится вашей доверенной точкой.
3. Удалённый подписант / bunker (NIP-46) — приватный ключ живёт в одном месте и не копируется в клиенты; скомпрометированный клиент никогда не видит nsec.¹⁴
4. Аппаратный / air-gapped подписант — ключ на устройстве, не касающемся сети; поддержка неровная, надо проверять до того, как полагаться.¹²

Смена клиента, кстати, тривиальна: тот же nsec в другом приложении — та же личность, те же подписки. Экспорт-импорт не нужен, потому что данные лежат в реле, а не в приложении.

Клиенты

Экосистема Nostr богата приложениями под все платформы. Ниже — заметные, сгруппированные по назначению.

Микроблогинг (аналоги Twitter/X):

• Damus — клиент для iPhone, iPad и macOS со встроенными Zaps и шифрованными личными сообщениями; активно развивается.¹⁵
• Amethyst — нативный Android-клиент на Kotlin/Jetpack Compose с широким покрытием NIP (запы, шифрованные DM, сообщества, маркетплейс) и очень активной разработкой.¹⁶
• Primal — кросс-платформенный (веб, iOS, Android) с собственным кэширующим слоем ради скорости, встроенным Lightning-кошельком и поддержкой удалённой (NIP-46) и локальной (NIP-55) подписи.¹⁷
• Snort — веб-клиент на React (плюс десктоп-сборка на Tauri), покрывает 40+ NIP: DM, длинные тексты, запы, метаданные реле, файловое хранилище.¹⁸
• Coracle — веб-клиент (PWA + Android) с упором на выбор и управление реле, модерацию на основе web-of-trust и приватность.¹⁹
• noStrudel — веб-клиент для тех, кто хочет копаться во внутренностях протокола; автор прямо называет его личным экспериментальным проектом, а не мейнстрим-приложением.²⁰
• Gossip — десктопный клиент на Rust/egui с умным выбором реле; оригинальный репозиторий с 2025 года почти не развивается, но активный форк ведёт сообщество YGGverse.²¹

Нишевые:

• Habla.news — платформа для длинных текстов (NIP-23): читать, писать, курировать и монетизировать статьи.²²
• zap.stream — децентрализованные видеотрансляции (NIP-53) с монетизацией через Lightning.²³
• Nostr Nests — веб-сервис аудио-комнат для разговоров, дебатов и микро-конференций.²⁴
• Olas — приложение в духе Instagram для фото и видео (события kind:20), с «зап-свайпом».²⁵
• 0xchat — кросс-платформенный (Flutter) мессенджер на Nostr с приватными и групповыми DM по NIP-17 и «gift-wrap»-шифрованием.²⁶

Общий принцип выбора: клиент определяет удобство и набор функций, но не владеет вашей личностью или данными. Не понравился — переходите в другой с тем же ключом.

Особенность и преимущества

Главная особенность Nostr, из которой растёт всё остальное: это не «соцсеть», а универсальный минималистичный субстрат — «подписанное событие плюс произвольный kind». Протокол не знает, что такое лента, статья или стрим; он знает только события. Всё остальное лепят клиенты поверх одного и того же формата. Отсюда и разнообразие приложений из раздела выше: микроблог, длинные тексты, аудио-комнаты, видеотрансляции и фотосеть — это не разные протоколы, а разные kind в одной сети с одной личностью. Из этой особенности вытекают конкретные преимущества.

Личность, которую нельзя отнять. Аккаунт — это пара ключей, а не запись на конкретном сервере. Здесь важно сравнение с соседями по «децентрализованному соцвебу»:

• В ActivityPub (протокол Mastodon) личность привязана к серверу. Спецификация W3C прямо говорит: «Аккаунты пользователя на разных серверах соответствуют разным акторам».²⁷ Отсюда известная боль Mastodon — миграция между инстансами и потеря контекста при падении сервера.
• В AT Protocol (Bluesky) личность держится на DID — переносимом идентификаторе, отвязанном от конкретного сервера-хранилища (PDS), что позволяет менять провайдера без потери аккаунта и подписчиков.²⁸ Архитектура при этом сложнее: данные, агрегатор-firehose и слой представления (AppView) разнесены по разным ролям.²⁹
• В Nostr переносимость встроена в саму модель: личность — это ключ, а не handle на сервере. Независимый разбор трёх протоколов отмечает, что при падении реле «пользователь, скорее всего, даже не заметит», потому что клиент уже работает с несколькими реле параллельно.³⁰

Простота протокола. Ядро — одно событие в JSON и горстка WebSocket-сообщений. Написать реле или клиент под силу одному разработчику. Это снижает порог входа для новых приложений.

Отсутствие единой точки отказа — по замыслу. Забаненный на одном реле пользователь просто публикует на другом. Формулировка создателя: «Реле может запретить пользователю что-либо публиковать, но на него это не влияет — он всё ещё может публиковать на другие реле».¹

Встроенные микроплатежи. Zaps через Lightning — то, чего структурно нет ни в Mastodon, ни в Bluesky. NIP-57 делает Lightning-платёж первоклассным, проверяемым событием сети, прикреплённым к посту или профилю.¹¹ Это открывает прямую монетизацию контента без посредника-платформы.

На что обратить внимание

Многие преимущества Nostr — свойства по замыслу, которые на практике работают хуже, чем в теории. Об этом стоит знать до того, как строить на Nostr что-то серьёзное.

Управление ключами не прощает ошибок. Обратная сторона «личности, которую нельзя отнять» — отсутствие какого-либо восстановления. «В Nostr нет сброса пароля, восстановления по email, службы поддержки или бэкдора. Потеряли приватный ключ — личность утрачена навсегда… Если ключ скомпрометирован, ущерб необратим».³¹ Ротации ключа в протоколе нет. Для массового пользователя это, по оценке одного из критиков, «до сих пор нерешённая на практике проблема».³²

Заявленная устойчивость к цензуре на практике слабее. Здесь надо аккуратно разделять два измерения, потому что данные не так однозначны, как удобно было бы для критики.

На уровне хранения сеть децентрализована неплохо. Академический анализ Nostr (Yiluo Wei, Gareth Tyson, arXiv, сентябрь 2025) по выборке из 100+ млн постов приходит к выводу, что «Nostr достигает лучшей децентрализации, чем традиционные приложения Fediverse»: хотя на топовое реле приходится 73% постов, каждый пост в среднем реплицируется на 34,6 реле, то есть работает как распределённый бэкап, а не как единая точка хранения.³³

Проблема в другом — в экономике и в том, как реально ведут себя клиенты и люди. Тот же анализ фиксирует: 95% бесплатных реле не окупают операционных расходов, 132 реле ушли в оффлайн навсегда, а расплата за массовую репликацию — расточительность: 98,2% скачиваемого трафика тратится впустую, суммарно 144 ТиБ избыточных загрузок.³³ Главное же — пользователи концентрируются на горстке крупных реле, потому что каждый крупный клиент (Damus, Primal, Amethyst) поставляется с зашитым списком реле по умолчанию, и сеть слежалась вокруг 10-15 известных серверов.³⁴ Показательно, что сам fiatjaf ещё в 2024 году написал текст с заголовком «Nostr не децентрализован и не устойчив к цензуре», где признаёт: «Nostr сегодня действительно централизован».³⁵ Он считает это client-side проблемой (клиенты плохо реализуют модель outbox), а не архитектурным дефектом — но для пользователя итог тот же: устойчивость к цензуре в текущем виде слабее заявленной.

Nostr — это не протокол приватности. Формулировка Bitcoin Magazine точна: «Nostr не является протоколом приватности как таковым — среди прочего, клиенты по умолчанию раскрывают реле IP-адреса пользователей».³⁶ Социальный граф публичен (список подписок — это открытое событие kind:3). Старый механизм личных сообщений NIP-04 признан устаревшим самой спецификацией: он утекает метаданные о том, кто с кем и когда переписывается, и его криптография, по признанию спецификации, «даже близко не соответствует тому, что считается state-of-the-art».³⁷ Замена — связка NIP-17 (формат приватных сообщений), NIP-44 (версионированное шифрование) и NIP-59 («gift-wrap»-обёртка) — лучше, но и она имеет ограничения: групповые чаты больше ~10 участников непрактичны, наивная реализация уязвима к спаму, а реальная защита требует, чтобы и клиенты, и реле поддерживали нужные механизмы.³⁸

Спам и модерация без встроенного решения. Открытая, беспермиссионная модель публикации уже эксплуатируется спамерами, а два очевидных лекарства взаимно противоречивы: централизованная фильтрация противоречит духу Nostr, а платные реле отсекают массовое бесплатное участие.³⁹ Частичные ответы есть — Proof-of-Work на события (NIP-13) удорожает массовый спам, а модерация на основе web-of-trust (как в клиенте Coracle) отсеивает записи за пределами вашего круга доверия — но всё это живёт на уровне клиента и отдельных реле, а не в самом протоколе. С незаконным контентом (CSAM, копирайт) сложнее: модерацию нельзя обеспечить только на стороне клиента — «те, кто хочет использовать Nostr для этих целей, просто возьмут клиенты, которые не блокируют».⁴⁰ При этом операторы реле несут реальные юридические риски.

Экономика реле и масштаб. Открытый вопрос: какой стимул у оператора держать бесплатное публичное реле в масштабе Twitter?⁴¹ А если реле начнут индексировать данные ради глобальной ленты и поиска — не превратится ли это в ту самую централизованную модель «клиент-сервер-база», от которой Nostr уходил?⁴¹

Фрагментация NIP. Гибкость расширений оборачивается тем, что реализовать «полный» Nostr всё сложнее: набор NIP разрастается, и клиенты поддерживают разные подмножества. То, что задумывалось предельно простым, на краях усложняется.⁴²

Итог

Nostr стоит понимать таким, какой он есть: это протокол устойчивости к цензуре, а не приватности и не готовая замена Twitter. Его сильная сторона — предельно простая модель, где личность равна паре ключей, данные подписаны криптографически, а серверы взаимозаменяемы и «глупы». Отсюда реальные плюсы: аккаунт нельзя отнять привязкой к серверу, встроены Lightning-микроплатежи, а порог для создания новых приложений низкий.

Но заявленная устойчивость к цензуре сегодня работает хуже теории: на уровне хранения сеть децентрализована неплохо, а вот пользователи и клиенты концентрируются на нескольких крупных реле — и это признаёт сам автор. Управление ключами беспощадно к ошибкам, приватность требует внешних усилий, а спам и модерация не имеют встроенного ответа. Для энтузиаста, готового отвечать за свои ключи и терпеть шероховатости, Nostr даёт то, чего не даёт ни одна централизованная платформа — цифровую личность, которую никто не может отобрать. Для массового пользователя барьеры пока высоки.

Практический совет, если решите попробовать: начните с готового клиента (Primal или Damus), сразу и надёжно сохраните nsec, для всего серьёзнее одноразового аккаунта используйте подписант (NIP-07 или NIP-46), а к обещаниям «полной анонимности» относитесь скептически — это не про Nostr.

Quality Metrics