Протокол Nostr, объяснённый простыми словами

Протокол — это набор правил для того, как программы общаются друг с другом. Платформа — это компания, которая запускает эти программы от вашего имени. Twitter — это платформа. Email — это протокол. Nostr — это протокол.

Это различие важно, потому что протоколы и платформы имеют разные режимы отказа, разные структуры затрат и разные будущее. Это руководство объясняет, что делает Nostr именно протоколом, что это означает на практике и почему дизайн остаётся компактным намеренно.

TL;DR. Nostr — это протокол pub/sub-обмена сообщениями с криптографическими подписями. Он определяет небольшой формат события и простой способ для клиентов отправлять и получать эти события через relay-серверы. Никакая компания им не владеет. Любой может написать клиент, запустить relay или предложить расширения. Основная спецификация занимает несколько страниц.

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

Что на самом деле такое протокол

Email — это хороший пример для сравнения. Когда вы отправляете письмо из Gmail в Outlook, Gmail не нужно разрешение Outlook. Оба сервиса говорят на SMTP (протокол электронной почты), и SMTP определяет всё, что требуется для того, чтобы один почтовый сервер передал сообщение другому. Серверы разных компаний. Протокол — это нейтральное соглашение.

Nostr работает точно так же. Событие Nostr (пост, лайк, подписка) — это объект JSON с конкретной структурой, определённой в протоколе. Relay — это любой сервер, который согласен принимать, хранить и пересылать события, соответствующие этой структуре. Любые два клиента, которые говорят на Nostr, могут взаимодействовать через любой relay, который говорит на Nostr, независимо от того, кто сделал какой из трёх.

Протокол — это нейтральное соглашение. Реализации могут быть чем угодно.

Спецификация Nostr в минимуме предложений

Три правила охватывают почти всё.

1. Событие — это объект JSON с полями id, pubkey, created_at, kind, tags, content, sig. id — это хеш остальных полей; sig — это подпись Шнорра над id, используя приватный ключ pubkey.
2. Relay принимает валидные события через WebSocket и обслуживает подписки, которые фильтруют события по автору, виду, тегу или времени.
3. Клиент подписывает события и публикует их на relay-серверы; читает события, подписываясь на relay-серверы с фильтрами.

Это основной протокол. Каждая продвинутая функция (длинные статьи, zap'ы, личные сообщения, сообщества, списки) — это расширение, которое встраивается в эту структуру без её изменения.

Почему протокол остаётся компактным

Большинство протоколов растут путём наслоения. Каждый вариант использования добавляет к спецификации; каждое десятилетие спецификация больше, чем в предыдущем. HTTP теперь насчитывает сотни страниц. Email вырос из нескольких RFC в запутанный лабиринт. Nostr избежал этого намеренно.

Механизм — это NIP (Nostr Implementation Possibilities). Новые функции не добавляются в основную спецификацию; они предлагаются как опциональные NIP. Клиенты реализуют NIP, которые им нужны. Другие клиенты их игнорируют. Популярный NIP становится частью практического протокола, потому что достаточно реализаций его говорят; непопулярный NIP исчезает без суеты.

Это означает, что основа остаётся навсегда компактной (важные инварианты: подписанные события, открытые relay-серверы, портативная идентичность) и края навсегда гибкие (новые функции развиваются без нарушения существующих клиентов). Клиент Nostr от 2022 года всё ещё работает в 2026, потому что основа не изменилась; он просто делает меньше, чем более новые клиенты.

Протокол против платформы, конкретно

Пять практических различий, которые вы можете почувствовать как пользователь.

Идентичность. На платформе ваш аккаунт принадлежит компании. На протоколе ваш аккаунт — это криптографическая идентичность, которой вы владеете. Никто не может её отобрать.

Данные. На платформе ваши посты находятся в их базе данных. На протоколе ваши посты находятся на нескольких независимых relay-серверах. Если один уходит, остальные их всё ещё имеют.

Скорость функций. На платформе функции выпускаются, когда компания решает. На протоколе функции выпускаются, когда любой разработчик их напишет. Это медленнее в некотором смысле (нет центральной дорожной карты) и быстрее в других (много экспериментов параллельно).

Монетизация. На платформе компания захватывает всю монетизацию. На протоколе монетизация — это то, что согласны пользователи и разработчики. Nostr имеет zap'ы (одноранговые чаевые через Lightning), потому что это соответствовало культуре; другое сообщество протокола может прийти к другим нормам.

Режим отказа. Платформа может исчезнуть полностью. Протокол — нет; пока остаётся активным хотя бы один разработчик, протокол живёт. Nostr разработан так, что даже если бы fiatjaf (первоначальный автор) исчез завтра, сеть продолжала бы работать без изменений.

Что протокол намеренно не делает

Пять вещей, оставленных вне спецификации специально.

Модерация. Протокол не решает, какой контент приемлем. Каждый relay имеет свои правила; каждый клиент имеет свои фильтры; каждый пользователь имеет свой список игнорирования. Модерация происходит на краях, а не в основе.

Поиск. Нет определённого протоколом поиска. Некоторые relay-серверы индексируют текст; другие нет. Клиенты, которым нужен поиск, либо полагаются на relay-серверы с поиском, либо запускают собственное индексирование. Отсутствие преднамеренно; оно держит протокол нейтральным относительно того, что находится.

Ранжирование. Никакой ленты «Для вас». Никакого взвешивания вовлечённости. Клиенты по умолчанию отображают события по временной метке; любой другой порядок — это решение уровня клиента, а не протокола.

Обнаружение. Никакого движка рекомендаций. Поиск новых аккаунтов для подписки — это функция клиента, а не протокола. Некоторые клиенты сильно инвестируют в это (Primal); другие оставляют это пользователям (Damus).

Восстановление. Никакой переустановки аккаунта. Потеряете приватный ключ — потеряете аккаунт. Протокол может включать ротацию ключей, но не включает, потому что компромиссы реальны и сообщество не согласилось на конкретный механизм. Это текущая область (черновики NIP-26, NIP-41).

Каждое опущение — это выбор. Протоколы остаются компактными, отказываясь решать каждую проблему на уровне протокола.

Кто решает, что станет Nostr

Никто и все.

Нет Nostr Foundation. Нет корпоративной рабочей группы. Нет руководящего комитета. Самая сосредоточенная власть где-либо в экосистеме — это репозиторий GitHub у fiatjaf, где предлагаются NIP, и даже это просто точка координации, а не привратник.

Предлагаемые NIP читаются разработчиками клиентов. Популярные реализуются. NIP, который три основных клиента реализуют, эффективно является частью протокола; NIP, который один разработчик написал, но больше никому не нужен, — это просто документ на GitHub.

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

Когда модель протокола побеждает

Протоколы превосходят платформы в специфических условиях:

• Когда владение важнее, чем полировка. Протоколы обычно менее полированы, чем платформы. Они побеждают, когда вам важно то, что полировка не может дать (постоянная идентичность, устойчивость к цензуре, открытая совместимость).
• Когда сетевой эффект — это функция. Ценность протокола растёт с принятием разработчиками, а не только пользователями. Больше клиентов и relay-серверов делают сеть сильнее способами, которые платформа не может скопировать.
• Когда долгосрочный горизонт важен. Платформы покупаются, продаются, закрываются или переориентируются. Протоколы пережидают любого одного разработчика. Email старше большинства компаний; Nostr ставит на ту же динамику.

Если ваш вариант использования не соответствует ни одному из этих, платформа обычно быстрее и проще. Это честно. Nostr не универсально лучше, чем Twitter для каждого возможного использования. Он лучше в конкретных способах, которыми протокол превосходит платформу.

Чтение самой спецификации

Если это руководство побудило вас прочитать протокол напрямую, репозиторий NIP имеет полный список. NIP-01 — это основа; пронумерованные NIP после неё — это расширения. Вам не нужно ничего в этом понимать, чтобы использовать Nostr, но чтение NIP-01 занимает около десяти минут и многое уточняет.