Protokół Nostr, wyjaśniony w prosty sposób

Protokół to zestaw reguł określających, jak programy rozmawiają ze sobą. Platforma to firma, która uruchamia te programy w Twoim imieniu. Twitter to platforma. Email to protokół. Nostr to protokół.

To rozróżnienie ma znaczenie, ponieważ protokoły i platformy mają różne tryby awarii, różne struktury kosztów i różne przyszłości. Ten przewodnik wyjaśnia, co czyni Nostr specjalnie protokołem, co to oznacza w praktyce i dlaczego projektowanie celowo pozostaje małe.

TL;DR. Nostr to protokół pub/sub do przesyłania wiadomości z podpisami kryptograficznymi. Definiuje mały format zdarzeń i prosty sposób na wysyłanie i odbieranie tych zdarzeń przez klientów poprzez relaye. Żadna firma go nie posiada. Każdy może napisać klienta, uruchomić relay lub zaproponować rozszerzenia. Podstawowa specyfikacja mieści się na kilku stronach.

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

Co protokół naprawdę jest

Email to dobra porównanie. Gdy wysyłasz wiadomość e-mail z Gmaila na Outlook, Gmail nie potrzebuje pozwolenia Outlooka. Obie usługi mówią w SMTP (protokół e-mail), a SMTP definiuje wszystko, co jest wymagane, aby jeden serwer pocztowy przekazał wiadomość drugiemu. Serwery są od różnych firm. Protokół to neutralna umowa.

Nostr działa w taki sam sposób. Zdarzenie Nostr (post, polubienie, obserwowanie) to obiekt JSON o określonym kształcie zdefiniowanym w protokole. Relay to każdy serwer, który zgadza się na akceptowanie, przechowywanie i przesyłanie dalej zdarzeń zgodnych z tym kształtem. Dowolni dwaj klienci mówią w Nostr i mogą wchodzić w interakcję poprzez każdy relay, który mówi w Nostr, niezależnie od tego, kto stworzył którąkolwiek z tych trzech rzeczy.

Protokół to neutralna umowa. Implementacje mogą być czymkolwiek.

Specyfikacja Nostr, w najmniejszej liczbie zdań

Trzy reguły obejmują prawie wszystko.

1. Zdarzenie to obiekt JSON z id, pubkey, created_at, kind, tags, content, sig. id to skrót innych pól; sig to podpis Schnorra nad id przy użyciu prywatnego odpowiednika pubkey.
2. Relay akceptuje ważne zdarzenia poprzez WebSocket i obsługuje subskrypcje, które filtrują zdarzenia według autora, rodzaju, tagu lub czasu.
3. Klient podpisuje zdarzenia i publikuje je na relayach; czyta zdarzenia poprzez subskrypcję relayów z filtrami.

To jest podstawowy protokół. Każda zaawansowana funkcja (artykuły długoformowe, zapy, prywatne wiadomości, społeczności, listy) to rozszerzenie, które pasuje do tej struktury bez jej zmiany.

Dlaczego protokół pozostaje mały

Większość protokołów rośnie poprzez akumulację. Każdy przypadek użycia dodaje do specyfikacji; każdą dekadę specyfikacja jest większa niż w poprzedniej dekadzie. HTTP ma teraz setki stron. Email rozrósł się z kilku RFC-ów w gąszcz. Nostr uniknął tego celowo.

Mechanizmem są NIP-y (Nostr Implementation Possibilities). Nowe funkcje nie są dodawane do podstawowej specyfikacji; są proponowane jako opcjonalne NIP-y. Klienty wdrażają te NIP-y, na których im zależy. Inne klienty je ignorują. Popularny NIP staje się częścią praktycznego protokołu, ponieważ wystarczająco wiele implementacji go mówi; niepopularny NIP znika bez ceremonii.

To oznacza, że rdzeń jest zawsze mały (ważne niezmienniki: podpisane zdarzenia, otwarte relaye, przenośna tożsamość) a krawędzie są zawsze elastyczne (nowe funkcje ewoluują bez łamania istniejących klientów). Klient Nostr z 2022 roku wciąż działa w 2026 roku, ponieważ rdzeń się nie zmienił; po prostu robi mniej rzeczy niż nowsze klienty.

Protokół vs platforma, konkretnie

Pięć praktycznych różnic, które możesz czuć jako użytkownik.

Tożsamość. Na platformie Twoje konto jest własnością firmy. Na protokole Twoje konto to tożsamość kryptograficzna, którą posiadasz. Nikt nie może jej ci odebrać.

Dane. Na platformie Twoje posty żyją w ich bazie danych. Na protokole Twoje posty żyją na wielu niezależnych relayach. Jeśli jeden znika, pozostałe je mają.

Szybkość funkcji. Na platformie funkcje są wdrażane, gdy firma to zdecyduje. Na protokole funkcje są wdrażane, gdy każdy implementer je napisze. To jest wolniejsze w niektórych aspektach (brak centralnego planu) i szybsze w innych (wiele eksperymentów równolegle).

Monetyzacja. Na platformie firma przechwytuje całą monetyzację. Na protokole monetyzacja to cokolwiek, na co użytkownicy i implementerzy się zgodzą. Nostr ma zapy (porady między użytkownikami przez Lightning) ponieważ pasowało do kultury; inna społeczność protokołu mogłaby dojść do innych norm.

Tryb awarii. Platforma może całkowicie zniknąć. Protokół nie może; dopóki jeden implementer pozostaje aktywny, protokół żyje. Nostr jest projektowany tak, aby nawet gdyby fiatjaf (oryginalny autor) zniknął jutro, sieć pracowałaby bez zmian.

Co protokół celowo nie robi

Pięć rzeczy pominięte ze specyfikacji celowo.

Moderacja. Protokół nie decyduje, jaka zawartość jest akceptowalna. Każdy relay ma swoje zasady; każdy klient ma swoje filtry; każdy użytkownik ma swoją listę wyciszonych. Moderacja odbywa się na krawędziach, nie w rdzeniu.

Wyszukiwanie. Nie ma zdefiniowanego w protokole wyszukiwania. Niektóre relaye indeksują tekst; inne nie. Klienty, które chcą wyszukiwania, polegają albo na relayach zdolnych do wyszukiwania, albo uruchamiają własne indeksowanie. Brak jest celowy; utrzymuje protokół neutralnym na temat tego, co zostaje znalezione.

Ranking. Brak kanału "Dla Ciebie". Brak ważenia zaangażowania. Klienty wyświetlają zdarzenia według znacznika czasu domyślnie; każde inne porządkowanie to decyzja na poziomie klienta, nie protokołu.

Odkrywanie. Brak silnika rekomendacji. Znalezienie nowych kont do obserwowania to funkcja klienta, nie funkcja protokołu. Niektóre klienty dużo w to inwestują (Primal); inne pozostawiają to użytkownikom (Damus).

Odzyskiwanie. Brak resetowania konta. Stracisz klucz prywatny, tracisz konto. Protokół mógłby zawierać rotację klucza, ale nie zawiera, ponieważ kompromisy są rzeczywiste a społeczność nie uzgodniła konkretnego mechanizmu. To jest trwający obszar (wersje robocze NIP-26, NIP-41).

Każda pominięcia to wybór. Protokoły pozostają małe poprzez odmowę rozwiązywania każdego problemu na poziomie protokołu.

Kto decyduje, czym Nostr się stanie

Nikt i wszyscy.

Nie ma Fundacji Nostr. Żadna korporacyjna grupa robocza. Żaden komitet sterujący. Najbardziej skoncentrowana władza gdziekolwiek w ekosystemie to repozytorium GitHub fiatjafa, gdzie proponowane są NIP-y, a nawet to jest tylko punktem koordynacji, a nie strażnikiem.

Proponowane NIP-y są czytane przez deweloperów klientów. Popularne są wdrażane. NIP, który trzy główne klienty wdrażają, jest praktycznie częścią protokołu; NIP, który jeden deweloper napisał, ale nikt inny się nie interesuje, to po prostu dokument na GitHubie.

Ten proces jest bałaganiarny. Są problemy koordynacji, zduplikowane propozycje i okazjonalna polityka. Jest również odporny w specyficzny sposób: żadna strona nie może go zepsuć przez podjęcie złej decyzji, ponieważ złe decyzje po prostu nie zostają przyjęte. Protokół ewoluuje w przybliżonych kierunkach poprzez wagę wyborów deweloperów, a nie na mocy dekretu.

Kiedy model protokołu wygrywa

Protokoły pokonują platformy w specyficznych warunkach:

• Kiedy własność ma znaczenie więcej niż finezja. Protokoły są zwykle mniej wyrafinowane niż platformy. Wygrywają, gdy zależy ci na czymś, czego finezja nie może ci dać (trwała tożsamość, odporność na cenzurę, otwarta interoperacyjność).
• Kiedy efekt sieciowy jest funkcją. Wartość protokołu rośnie z przyjęciem przez implementerów, a nie tylko użytkowników. Więcej klientów i relayów wzmacnia sieć w sposób, którego platforma nie może skopiować.
• Kiedy horyzont długoterminowy ma znaczenie. Platformy są kupowane, sprzedawane, zamykane lub przekierowywane. Protokoły przeżywają każdego implementera. Email jest starszy niż większość firm; Nostr stawia na tę samą dynamikę.

Jeśli Twój przypadek użycia nie pasuje do żadnego z nich, platforma jest zwykle szybsza i łatwiejsza. To uczciwe. Nostr nie jest wszechstronnie lepszy od Twittera dla każdego możliwego zastosowania. Jest lepszy w specyficznych sposobach, w jakie protokół pokonuje platformę.

Czytanie rzeczywistej specyfikacji

Jeśli ten przewodnik sprawił, że chcesz czytać protokół bezpośrednio, repozytorium NIPs ma pełną listę. NIP-01 to rdzeń; ponumerowane NIP-y po nim to rozszerzenia. Nie musisz rozumieć żadnego z tego, aby użytkować Nostr, ale przeczytanie NIP-01 zajmuje około dziesięciu minut i wiele wyjaśnia.