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

Еволюція Nostr відбувається через NIPs, короткі документи специфікації, які може запропонувати будь-хто. Якщо ви хочете зрозуміти, як нові функції, такі як zaps або зашифровані DM, потрапляють в протокол, NIPs — це відповідь.

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

NIPs — це короткі markdown-документи на GitHub, які пропонують, як реалізувати функції Nostr. Розробники клієнтів вибирають, які підтримувати. NIP стає "реальним", коли його впровадить достатньо реалізацій. Основний набір широко використовуваних NIPs складає близько 30; повний список ближче до 100.

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

Що насправді таке NIP

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

Розмір варіюється. Найкоротші NIPs менші за сторінку; найдовші — кілька тисяч слів. Більшість розташовані близько 500–2000 слів. Вони написані так, щоб їх можна було реалізувати лише зі специфікації, тому вони включають формати повідомлень, обов'язкові поля та приклади events.

Конвенція іменування — NIP-XX, де XX — це число. Номери призначаються під час об'єднання; вони не відображають пріоритет або важливість. NIP-05 стосується верифікованих ідентифікаторів; NIP-04 — це старіший стандарт DM; NIP-01 — це основний протокол. Числа відстежують порядок пропозиції, а не значущість функції.

Чому "Можливості впровадження"

Назва — це навмисний вибір. Порівняйте з іншими традиціями специфікації.

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

Це означає, що NIPs ніколи не "ламають" існуючі реалізації. Новий NIP для якоїсь функції не змушує старіші клієнти змінюватися. Протокол зростає по краях, поки ядро залишається стабільним.

Життєвий цикл NIP

Як з'являється новий NIP:

1. Хтось помічає прогалину або потребу. "У нас немає стандартного способу робити X." Могли б бути розробник клієнта, оператор relay або користувач, розчарований конкретною проблемою.
2. Вони пишуть чернетку. Формат відповідає існуючим NIPs: заголовок, мета, специфікація, приклади.
3. Вони подають pull request до репозиторію NIPs.
4. Спільнота огляд. Розробники, оператори relay та зацікавлені користувачі коментують. Чернетка переробляється на основі зворотного зв'язку.
5. Об'єднання або відмова. Об'єднані NIPs отримують номер і стають частиною репозиторію. Відкинуті чернетки залишаються в історії pull request.
6. Впровадження слідує (або ні). Деякі NIPs впроваджуються протягом тижнів. Деякі чекають роки. Деякі ніколи не впроваджуються широко.

Процес легкий. Без голосування комітету, без формального затвердження. Якщо pull request отримує широко позитивний зворотний зв'язок і вирішує очевидну потребу, він об'єднується.

NIPs, які мають значення, якщо ви користувач

Більшість NIPs невидимі для користувачів. Кілька впливають на ваш щоденний досвід:

• NIP-01: Основний протокол. Як структуровані та підписані events. Ви цього ніколи не бачите, але всі інші залежать від цього.
• NIP-05: Верифіковані ідентифікатори. Дає вам читаємі імена you@domain.com. Наш посібник NIP-05 це охоплює.
• NIP-07: Підписування розширення браузера. Дозволяє веб-клієнтам підписувати без перегляду вашого приватного ключа.
• NIP-19: Кодування Bech32. Чому ваш публічний ключ виглядає як npub1... замість сирого hex.
• NIP-23: Статті довгої форми. Дозволяє блог-подібні пости на Nostr.
• NIP-44: Зашифровані DM. Сучасний стандарт прямого обміну повідомленнями (краще ніж старіший NIP-04).
• NIP-57: Zaps. Lightning чайові з публічними квитанціями.
• NIP-98: Автентифікація HTTP. Дозволяє ідентичностям Nostr автентифікуватися до звичайних веб-сайтів.

Як користувач, ви отримуєте користь від всього цього без взаємодії з ними. Клієнти обробляють деталі протоколу.

NIPs, які мають значення, якщо ви розробник

Якщо ви пишете або обслуговуєте клієнт Nostr, NIPs, які варто прочитати, зростають до десятків:

• NIP-01 до NIP-10 (основна механіка).
• NIP-11 (документи інформації relay).
• NIP-13 (доказ роботи для стійкості до спаму).
• NIP-17 (подарункові обгорнуті DM для приховування метаданих).
• NIP-22 (закінчення event).
• NIP-27 (посилання текстових нотаток).
• NIP-30 (користувацькі emoji).
• NIP-31 (типи event).
• NIP-33 (параметризовані змінні events).
• NIP-42 (автентифікація підключень до relay).
• NIP-47 (Nostr Wallet Connect).
• NIP-50 (можливість пошуку).
• NIP-65 (метаданих списку relay).
• NIP-78 (довільні користувацькі дані додатку).

Це ті, які впроваджує більшість основних клієнтів. Клієнт, який підтримує цей набір плюс користувацькі NIPs вище, охоплює 95% типового використання.

Читання NIP

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

• Заголовок та опис. Що пропонує NIP.
• Мотивація. Чому потрібна функція.
• Специфікація. Точний формат повідомлення, обов'язкові поля, правила валідації.
• Приклади events. Конкретний JSON, що показує, як виглядає відповідний event.
• Поведінка клієнта/relay. Як реалізації повинні обробляти events.

NIPs написані для читання розробниками, які їх впроваджують. Розділ специфікація — найважливіший; тут живе фактичний протокол.

NIPs з частковим впровадженням

Деякі NIPs існують, але непослідовно впроваджуються у клієнтах. Це створює граничні випадки, де ваш досвід варіюється залежно від клієнта.

NIP-44 (зашифровані DM). Прийнятий Damus, Primal, Amethyst та більшістю основних клієнтів у 2024–2025. Деякі старіші клієнти досі підтримують лише NIP-04. Якщо ви надішлете DM комусь, чий клієнт підтримує лише NIP-04, ваші повідомлення NIP-44 їм не дійдуть. Практична відповідь: використовуйте сучасний клієнт і сподівайтесь, що ваш кореспондент теж.

NIP-17 (подарункові обгорнуті DM). DM, що приховують метаданих. Впровадження у 2026 році зростає, але не універсально. Функція чудова, де обидва клієнти обох сторін її підтримують; інакше вона мовчазно повертається до менш приватних DM.

NIP-46 (віддалені підписувальники). Дозволяє апаратному підписувальнику або програмі бункера підписувати events від імені клієнта. Підтримується в Amethyst, частково в інших місцях.

NIP-65 (список relay користувача). Дозволяє користувачам опублікувати свої переважні relay, щоб клієнти автоматично маршрутизували до правильних місць. Впровадження поліпшується; старіші клієнти це ігнорують.

NIP-50 (пошук). Дозволяє клієнтам запитувати relay для текстових збігів. Деякі relay це підтримують; багато хто — ні. Якість пошуку непослідовна внаслідок цього.

Перевірка того, які NIPs підтримує даний клієнт, є корисною діагностикою, коли щось не працює як очікується. Більшість клієнтів публікують свою матрицю підтримки NIP у своїй документації.

Як процес 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 залишається узгодженим без того, щоб бути від верху вниз.