Nostr NIPs wyjaśnione: dokumenty specyfikacji protokołu

Ewolucja Nostr odbywa się poprzez NIPs, krótkie dokumenty specyfikacji, które może zaproponować każdy. Jeśli chcesz zrozumieć, jak nowe funkcje takie jak zappy lub szyfrowane wiadomości trafiają do protokołu, odpowiedzią są NIPs.

Ten przewodnik obejmuje, czym są NIPs, jak działają jako mechanizm zarządzania i które warto czytać, jeśli углębiasz się w techniczne szczegóły.

NIPs to krótkie dokumenty markdown na GitHub, które proponują sposób implementacji funkcji Nostr. Deweloperzy klientów wybierają, które wspierać. NIP staje się "realny", gdy zostanie przyjęty przez wystarczająco wielu implementerów. Podstawowy zestaw szeroko używanych NIPs to około 30; pełna lista to bliżej 100.

Kiedy będziesz gotowy, odbierz adres @nostr.blog →

Czym właściwie jest NIP

NIP to plik markdown w repozytorium github.com/nostr-protocol/nips. Każdy plik opisuje konkretną funkcję, format lub konwencję: jak podpisywać eventy, jak wygląda event metadanych profilu, jak wysłać wiadomość prywatną, jaki format używają żądania zappów Lightning.

Rozmiar się różni. Najkrótsze NIPs zajmują mniej niż stronę; najdłuższe to kilka tysięcy słów. Większość to około 500 do 2000 słów. Są napisane tak, aby można je było zaimplementować wyłącznie na podstawie specyfikacji, więc zawierają formaty wiadomości, pola wymagane i przykładowe eventy.

Konwencja nazewnictwa to NIP-XX, gdzie XX to numer. Numery przydzielane są, gdy NIP jest mergeowany; nie odzwierciedlają priorytetu ani ważności. NIP-05 dotyczy zweryfikowanych identyfikatorów; NIP-04 to starszy standard DM; NIP-01 to protokół jądra. Numery śledzą kolejność propozycji, a nie znaczenie funkcji.

Dlaczego "Implementation Possibilities"

Nazwa to celowy wybór. Porównaj z innymi tradycjami specyfikacji.

• RFC (Requests for Comments) w protokołach internetowych często stają się obowiązkowe dla interoperacyjności.
• EIP (Ethereum Improvement Proposals) często stają się obowiązkowe poprzez aktualizację sieci.
• NIPs są trwale opcjonalne. Klient implementujący 40 NIPs i klient implementujący 10 to oba ważne klienty Nostr; po prostu robią różne podzbiory rzeczy.

To oznacza, że NIPs nigdy nie "łamią" istniejące implementacje. Nowy NIP dla jakiejś funkcji nie zmusza starszych klientów do zmiany. Protokół rozwija się na krawędziach, podczas gdy jądro pozostaje stabilne.

Cykl życia NIP

Jak nowy NIP wchodzi w życie:

1. Ktoś dostrzega lukę lub potrzebę. "Nie mamy standardowego sposobu na zrobienie X." Mogą to być deweloper klienta, operator relay'a lub użytkownik sfrustowany konkretnym problemem.
2. Piszą szkic. Format następuje po istniejących NIPs: tytuł, cel, specyfikacja, przykłady.
3. Zgłaszają pull request do repozytorium NIPs.
4. Społeczność recenzuje. Deweloperzy, operatorzy relayów i zainteresowani użytkownicy komentują. Szkic jest poprawiany na podstawie opinii.
5. Merge lub porzucenie. Mergeowane NIPs otrzymują numer i stają się częścią repozytorium. Porzucone szkice pozostają w historii pull requestów.
6. Implementacja następuje (lub nie). Niektóre NIPs są implementowane w ciągu tygodni. Niektóre czekają lata. Niektóre nigdy nie są szeroko implementowane.

Proces jest lekki. Brak głosów komisji, brak formalnej akceptacji. Jeśli pull request otrzyma szeroko pozytywne opinie i rozwiąże oczywistą potrzebę, zostaje mergeowany.

NIPs, które mają znaczenie dla użytkownika

Większość NIPs jest dla użytkowników niewidoczna. Kilka wpływa na twoje codzienne doświadczenie:

• NIP-01: Protokół jądra. Jak eventy są strukturyzowane i podpisane. Nigdy go nie widzisz, ale wszystko inne od niego zależy.
• NIP-05: Zweryfikowane identyfikatory. Daje ci czytelne nazwy ty@domena.com. Nasz przewodnik NIP-05 go obejmuje.
• NIP-07: Podpisywanie rozszerzenia przeglądarki. Pozwala klientom webowym podpisywać bez widzenia twojego klucza prywatnego.
• NIP-19: Kodowanie Bech32. Dlaczego twój klucz publiczny wygląda jak npub1... zamiast surowego heksu.
• NIP-23: Artykuły długoformowe. Umożliwia posty w stylu bloga na Nostr.
• NIP-44: Szyfrowane DM. Nowoczesny standard wiadomości bezpośrednich (lepszy niż starszy NIP-04).
• NIP-57: Zappy. Tipy Lightning z publicznymi potwierdżeniami.
• NIP-98: Autoryzacja HTTP. Pozwala tożsamościom Nostr na autentykację do zwykłych stron internetowych.

Jako użytkownik korzystasz ze wszystkich tych rzeczy bez wchodzenia w interakcję z nimi. Klienty obsługują szczegóły protokołu.

NIPs, które mają znaczenie dla dewelopera

Jeśli piszesz lub utrzymujesz klienta Nostr, lista NIPs warta przeczytania rośnie do dziesiątek:

• NIP-01 do NIP-10 (mechanika jądra).
• NIP-11 (dokumenty informacyjne relay'a).
• NIP-13 (proof of work, do odporności na spam).
• NIP-17 (gift-wrapped DM do ukrywania metadanych).
• NIP-22 (wygaśnięcie eventy).
• NIP-27 (odwołania do notek tekstowych).
• NIP-30 (niestandardowe emoji).
• NIP-31 (rodzaje eventów).
• NIP-33 (parametryzowane zastępowalne eventy).
• NIP-42 (autentykacja połączeń do relayów).
• NIP-47 (Nostr Wallet Connect).
• NIP-50 (możliwość wyszukiwania).
• NIP-65 (metadane listy relay'ów).
• NIP-78 (arbitralne niestandardowe dane aplikacji).

To są te, które implementują głównie klienty. Klient wspierający ten zestaw plus wymienione powyżej NIPs skierowane do użytkownika obejmuje 95% typowego użytkowania.

Czytanie NIP

Jeśli chcesz przeczytać jeden bezpośrednio, repozytorium znajduje się pod adresem github.com/nostr-protocol/nips. Struktura większości NIPs:

• Tytuł i opis. Co NIP proponuje.
• Motywacja. Dlaczego funkcja jest potrzebna.
• Specyfikacja. Dokładny format wiadomości, pola wymagane, reguły walidacji.
• Przykładowe eventy. Konkretny JSON pokazujący, jak wygląda zgodny event.
• Zachowanie klienta/relay'a. Jak implementacje powinny obsługiwać eventy.

NIPs są napisane w taki sposób, aby były czytelne dla deweloperów je implementujących. Sekcja specyfikacji to ważna; to miejsce, w którym żyje rzeczywisty protokół.

NIPs z częściową adopcją

Niektóre NIPs istnieją, ale są niespójnie implementowane na klientach. To tworzy skrajne przypadki, gdzie twoje doświadczenie różni się w zależności od klienta.

NIP-44 (szyfrowane DM). Adoptowany przez Damus, Primal, Amethyst i większość głównych klientów w 2024-2025. Niektóre starsze klienty wspierają wyłącznie NIP-04. Jeśli wyślesz DM do kogoś, którego klient wspiera tylko NIP-04, twoje wiadomości NIP-44 do nich są dyskretnie failuje. Praktyczna odpowiedź: użyj nowoczesnego klienta i miej nadzieję, że twój rozmówca też.

NIP-17 (gift-wrapped DM). DM ukrywające metadane. Adopcja w 2026 roku rośnie, ale nie jest uniwersalna. Funkcja jest świetna, gdy oba klienty obu stron ją wspierają; w innym przypadku dyskretnie wraca do mniej prywatnych DM.

NIP-46 (zdalni podpisujący). Pozwala sprzętowemu podpisującemu lub aplikacji bunker na podpisywanie eventów w imieniu klienta. Wspierane w Amethyst, częściowo w innych miejscach.

NIP-65 (lista relay'ów użytkownika). Pozwala użytkownikom opublikować swoje preferowane relay'e, aby klienty mogły automatycznie trasować do odpowiednich miejsc. Adopcja się poprawia; starsze klienty ją ignorują.

NIP-50 (wyszukiwanie). Pozwala klientom na zapytanie relay'ów o dopasowania tekstowe. Niektóre relay'e to wspierają; wiele nie. Jakość wyszukiwania jest niespójna w rezultacie.

Sprawdzenie, które NIPs dany klient wspiera, jest użyteczną diagnozą, gdy coś nie działa jak oczekiwane. Większość klientów publikuje swoją macierz wsparcia NIP w swojej dokumentacji.

Jak proces NIP utrzymuje protokół spójnym

Brak centralnego urzędu, więc spójność pochodzi z dynamiki społecznej. Kilka obserwacji:

Złe NIPs się nie rozprzestrzeniają. Propozycja, która duplikuje istniejący NIP lub rozwiązuje zły problem, otrzymuje minimalną adopcję i cicho umiera. Społeczność nie jest formalna, ale jest zdecydowana.

Dobre NIPs są niezależnie implementowane. Wielu deweloperów klientów czyta propozycje i niezależnie decyduje. Dobre pomysły gromadzą adoptujących; złe nie.

Konkurencyjne NIPs czasami się pojawiają. Dwie różne propozycje na tę samą funkcję mogą współistnieć przez pewien czas. Zwykle jedna wygrywa w praktyce, ponieważ więcej klientów ją implementuje; czasami się łączą.

Ewolucja kompatybilna z rozwidleniami. Ponieważ NIPs są opcjonalne, klient może implementować NIP-X-v1 i później uaktualnić do NIP-X-v2 bez łamania nikogo, kto wspiera tylko v1. Protokół się nie dzieli.

To jest chaotyczne, ale funkcjonalne. Protokół znacznie ewoluował w ciągu pięciu lat bez centralnego organu zarządzającego, ponieważ mechanizm społeczny "implementerzy czytają, implementerzy decydują, implementerzy kodują" ma wystarczającą zbieżność do wytworzenia spójności.

Proponowanie własnego NIP

Jeśli masz pomysł na nową funkcję Nostr:

1. Najpierw sprawdź repozytorium NIPs. Ktoś mógł już to zaproponować.
2. Jeśli nie, otwórz GitHub issue opisując problem, który rozwiązujesz.
3. Na podstawie opinii, stwórz pełny NIP zgodnie z istniejącym formatem.
4. Złóż pull request.
5. Angażuj się w dyskusję. Bądź gotów do poprawy.
6. Jeśli zostanie mergeowany, świetnie. Jeśli nie, problem może mieć lepsze rozwiązanie; zastanów się dlaczego.

Nie każdy dobry pomysł staje się NIP. Nie każdy NIP staje się funkcją. Ekosystem ma więcej propozycji, niż jakikolwiek pojedynczy deweloper mógł by śledzić, a filtr to "czy wystarczająco dużo społeczności to implementuje". Ten filtr to jądro tego, jak Nostr pozostaje spójny bez bycia hierarchicznym.