Nostr NIPs объяснены: документы спецификации протокола

Эволюция Nostr происходит через NIPs — короткие документы спецификации, которые может предложить кто угодно. Если вы хотите понять, как новые функции, такие как zaps или шифрованные ДМ, попадают в протокол, NIPs — это ответ.

Это руководство охватывает, что такое NIPs, как они работают как механизм управления и какие из них стоит прочитать, если вы углубляетесь в техническую часть.

NIPs — это короткие markdown документы на GitHub, которые предлагают, как реализовать функции Nostr. Разработчики клиентов выбирают, какие из них поддерживать. NIP становится «реальным», когда его принимают достаточно реализаторов. Базовый набор широко используемых NIPs — около 30; полный список ближе к 100.

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

Что на самом деле такое NIP

NIP — это файл markdown в репозитории github.com/nostr-protocol/nips. Каждый файл описывает конкретную функцию, формат или соглашение: как подписывать события, как выглядит событие метаданных профиля, как отправлять прямое сообщение, какой формат используют запросы Lightning zap.

Размер варьируется. Самые короткие NIPs — менее одной страницы; самые длинные — несколько тысяч слов. Большинство находятся в диапазоне 500-2000 слов. Они написаны так, чтобы их можно было реализовать только из спецификации, поэтому они включают форматы сообщений, обязательные поля и примеры событий.

Соглашение об именовании: NIP-XX, где XX — это номер. Номера назначаются при объединении NIP; они не отражают приоритет или важность. NIP-05 касается проверенных идентификаторов; NIP-04 — это более старый стандарт ДМ; NIP-01 — это основной протокол. Номера отслеживают порядок предложения, а не значимость функции.

Почему «Implementation Possibilities»

Название выбрано намеренно. Сравните с другими традициями спецификации.

• RFCs (Requests for Comments) в интернет-протоколах часто становятся обязательными для взаимодействия.
• EIPs (Ethereum Improvement Proposals) часто становятся обязательными через обновление сети.
• NIPs постоянно опциональны. Клиент, который реализует 40 NIPs, и клиент, который реализует 10, — оба являются допустимыми клиентами Nostr; они просто делают разные подмножества вещей.

Это означает, что NIPs никогда не «разрушают» существующие реализации. Новый NIP для какой-то функции не заставляет старые клиенты изменяться. Протокол растёт на краях, пока ядро остаётся стабильным.

Жизненный цикл NIP

Как появляется новый NIP:

1. Кто-то заметил пробел или необходимость. «У нас нет стандартного способа сделать X.» Это может быть разработчик клиента, оператор реле или пользователь, расстроенный конкретной проблемой.
2. Они пишут черновик. Формат следует существующим NIPs: название, назначение, спецификация, примеры.
3. Они отправляют pull request в репозиторий NIPs.
4. Сообщество проверяет. Разработчики, операторы реле и заинтересованные пользователи комментируют. Черновик пересматривается на основе отзывов.
5. Объединение или отклонение. Объединённые NIPs получают номер и становятся частью репозитория. Отклонённые черновики остаются в истории pull requests.
6. Реализация следует (или нет). Некоторые NIPs реализуются в течение недель. Некоторые ждут годы. Некоторые никогда не реализуются широко.

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

NIPs, которые важны, если вы пользователь

Большинство NIPs невидимы для пользователей. Несколько влияют на ваш повседневный опыт:

• NIP-01: Основной протокол. Как структурируются и подписываются события. Вы его никогда не видите, но всё остальное от него зависит.
• NIP-05: Проверенные идентификаторы. Дает вам читаемые имена вы@домен.com. Наше руководство по NIP-05 его охватывает.
• NIP-07: Подпись расширения браузера. Позволяет веб-клиентам подписывать без просмотра вашего приватного ключа.
• NIP-19: Кодирование Bech32. Почему ваш публичный ключ выглядит как npub1... вместо сырого hex.
• NIP-23: Длинные статьи. Включает посты в стиле блога на Nostr.
• NIP-44: Шифрованные ДМ. Современный стандарт прямых сообщений (лучше, чем более старый NIP-04).
• NIP-57: Zaps. Советы Lightning с публичными квитанциями.
• NIP-98: HTTP аутентификация. Позволяет идентификаторам Nostr аутентифицироваться на обычных веб-сайтах.

Как пользователь вы получаете пользу от всех этих без взаимодействия с ними. Клиенты обрабатывают детали протокола.

NIPs, которые важны, если вы разработчик

Если вы пишете или поддерживаете клиент Nostr, NIPs, которые стоит читать, растут в десятки:

• NIP-01 через NIP-10 (основная механика).
• NIP-11 (информационные документы реле).
• NIP-13 (proof of work для сопротивления спаму).
• NIP-17 (gift-wrapped ДМ для скрытия метаданных).
• NIP-22 (истечение события).
• NIP-27 (ссылки на текстовые заметки).
• NIP-30 (пользовательский emoji).
• NIP-31 (виды событий).
• NIP-33 (параметризованные заменяемые события).
• NIP-42 (аутентификация подключений к реле).
• NIP-47 (Nostr Wallet Connect).
• NIP-50 (возможность поиска).
• NIP-65 (метаданные списка реле).
• NIP-78 (произвольные пользовательские данные приложения).

Это те, которые реализуют большинство основных клиентов. Клиент, который поддерживает этот набор плюс пользовательские NIPs выше, охватывает 95% типичного использования.

Чтение NIP

Если вы хотите прочитать один напрямую, репозиторий находится в github.com/nostr-protocol/nips. Структура большинства NIPs:

• Название и описание. Что предлагает NIP.
• Обоснование. Почему функция нужна.
• Спецификация. Точный формат сообщения, обязательные поля, правила валидации.
• Примеры событий. Конкретный JSON, показывающий, как выглядит соответствующее событие.
• Поведение клиента/реле. Как реализации должны обрабатывать события.

NIPs написаны так, чтобы их могли читать разработчики, реализующие их. Раздел спецификации — самый важный; именно там живёт фактический протокол.

NIPs с частичным внедрением

Некоторые NIPs существуют, но непоследовательно реализованы на разных клиентах. Это создаёт пограничные случаи, когда ваш опыт зависит от клиента.

NIP-44 (шифрованные ДМ). Принят Damus, Primal, Amethyst и большинством основных клиентов в 2024-2025 годах. Некоторые старые клиенты по-прежнему поддерживают только NIP-04. Если вы отправляете ДМ кому-то, клиент которого поддерживает только NIP-04, ваши NIP-44 сообщения для них молча не работают. Практический ответ: используйте современный клиент и надеейтесь, что ваш корреспондент тоже.

NIP-17 (gift-wrapped ДМ). ДМ, скрывающие метаданные. Внедрение в 2026 году растёт, но не универсально. Функция отличная, где оба клиента обеих сторон её поддерживают; в противном случае молча возвращается к менее приватным ДМ.

NIP-46 (удалённые подписывающие). Позволяет приложению аппаратного подписания или bunker приложению подписывать события от имени клиента. Поддерживается в Amethyst, частично в других местах.

NIP-65 (список реле пользователя). Позволяет пользователям публиковать свои предпочтительные реле, так что клиенты могут автоматически маршрутизировать на правильные места. Внедрение улучшается; старые клиенты его игнорируют.

NIP-50 (поиск). Позволяет клиентам запрашивать реле для текстовых совпадений. Некоторые реле его поддерживают; многие нет. Качество поиска непоследовательно в результате.

Проверка, какие NIPs поддерживает данный клиент, — это полезная диагностика, когда что-то не работает как ожидается. Большинство клиентов публикуют матрицу поддержки NIPs в своей документации.

Как процесс NIP поддерживает протокол связным

Нет центрального органа, поэтому связность исходит из социальной динамики. Несколько наблюдений:

Плохие NIPs не распространяются. Предложение, которое дублирует существующий NIP или решает неправильную проблему, получает минимальное внедрение и тихо умирает. Сообщество не формальное, но авторитетное.

Хорошие NIPs реализуются независимо. Несколько разработчиков клиентов читают предложения и независимо решают. Хорошие идеи накапливают внедрителей; плохие идеи нет.

Конкурирующие NIPs иногда появляются. Два разных предложения для одной и той же функции могут какое-то время сосуществовать. Обычно один побеждает на практике, потому что более клиентов его реализуют; иногда они объединяются.

Fork-совместимая эволюция. Потому что NIPs опциональны, клиент может реализовать NIP-X-v1 и позже обновиться на NIP-X-v2 без разрыва с теми, кто поддерживает только v1. Протокол не разделяется.

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

Предложение собственного NIP

Если у вас есть идея для новой функции Nostr:

1. Сначала проверьте репозиторий NIPs. Кто-то мог её уже предложить.
2. Если нет, откройте GitHub issue с описанием проблемы, которую вы решаете.
3. На основе отзывов напишите полный NIP в соответствии с существующим форматом.
4. Отправьте pull request.
5. Участвуйте в обсуждении. Будьте готовы пересмотреть.
6. Если он объединится, отлично. Если нет, проблема может иметь лучшее решение; рассмотрите почему.

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