Jak naprawdę działa Nostr: protokół bez żargonu

Większość wyjaśnień Nostr zatrzymuje się na „to zdecentralizowany protokół społecznościowy" i nie mówi o interesującej części. Interesująca część to to, że cały protokół zmieści się w krótkim dokumencie. Żaden sprytny trick, żadna ukryta złożoność. Tylko kilka prymitywów, które pracują razem.

Ten przewodnik przechodzi przez te prymitywy w kolejności, w której się pojawiają, gdy naprawdę używasz Nostr: jak budowany jest event, jak jest podpisywany, jak dociera do relayów, jak klienty subskrybują, i jak wygląda przepływ, gdy polubisz post, otrzymasz odpowiedź lub otrzymasz zap. Bez porównań do blockchaina, bez wielkiego narracyju. Po prostu mechanika.

TL;DR. Nostr to pub/sub przez WebSockety z kryptograficznymi podpisami. Klienty publikują podpisane obiekty JSON (eventy) do relayów (małych serwerów), a inni klienci subskrybują relaye za pomocą filtrów pasujących do eventów, które chcą. Podpisy zapobiegają fałszerstwu; wiele relayów zapobiega pojedynczym punktom awarii. To cały protokół; wszystko inne to konwencje formatowania dla różnych rodzajów zawartości.

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

Budujący blok: event

Wszystko na Nostr to event. Post to event. Reakcja to event. Aktualizacja profilu to event. Wiadomość bezpośrednia to event. Pokwitowanie zapa to event.

Event to obiekt JSON o dokładnie tym kształcie:

{
  "id": "abc123...",
  "pubkey": "0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88",
  "created_at": 1776329035,
  "kind": 1,
  "tags": [
    ["t", "nostr"],
    ["p", "3bf0c63f..."]
  ],
  "content": "hello nostr",
  "sig": "def456..."
}

Sześć pól wykonuje znaczącą pracę. id to hash zawartości własnego eventu; jednoznacznie go identyfikuje. pubkey to autor (64-znakowy szesnastkowy klucz publiczny). created_at to znacznik czasu Unix. kind to liczba całkowita opisująca, co reprezentuje event (więcej poniżej). tags to lista strukturalnych adnotacji, takich jak hashtagi (t), wzmianki (p dla pubkey, e dla event) i dziesiątki innych. content to swobodna zawartość, zwykle tekst.

sig to podpis Schnorra, stworzony za pomocą klucza prywatnego autora, nad hashem w id. To jest pole, które zapobiega fałszerstwu: każdy może obliczyć hash, ale tylko posiadacz klucza prywatnego może wytworzyć ważny podpis na nim.

Co to jest „kind"

Pole kind mówi klientom, jak zinterpretować event. Liczba to cały typ semantyczny.

Kilka rodzajów w aktywnym użyciu:

Nowe rodzaje są proponowane i ustandaryzowane przez NIPs (Nostr Implementation Possibilities). Każdy może zaproponować jeden. Te, które są szeroko przyjęte, stają się de facto częścią protokołu; te, które nie są, po prostu pozostają niszowe bez czegoś łamiącego.

Jak event zostaje opublikowany

Gdy klikasz „post" w kliencie Nostr, ta sekwencja się uruchamia:

1. Klient zestawia JSON. Wypełnia pubkey, created_at, kind, tags, content.
2. Klient oblicza id. Uruchamia SHA-256 nad kanoniczną serializacją tych pól. To jest hash, który podpis pokrywa.
3. Klient podpisuje id kluczem prywatnym. Podpis Schnorra nad secp256k1, tą samą krzywą, którą używa Bitcoin. Podpis 64-bajtowy staje się polem sig.
4. Klient otwiera połączenia WebSocket do każdego skonfigurowanego relaya. Lub ponownie używa istniejących otwartych, jeśli są aktywne.
5. Klient wysyła event jako wiadomość. Format on-wire to tablica JSON: ["EVENT", {...event...}].
6. Każdy relay weryfikuje podpis. Odrzuca event, jeśli podpis nie weryfikuje się względem podanego pubkey. W przeciwnym razie akceptuje i przechowuje.
7. Każdy relay push event do subskrybentów. Każdy klient z otwartą subskrypcją, której filtr pasuje do tego eventu, otrzymuje event dostarczony w czasie rzeczywistym.

Całkowita podróż w obie strony zajmuje 50 do 300 milisekund w zależności od lokalizacji relayów. Jeśli jakiś relay jest wolny lub offline, pozostałe relaye nadal publikują event. Potrzebujesz tylko jednego relaya, aby zaakceptował event, aby event istniał w sieci.

Jak klient pobiera posty

Czytanie jest odbiciem publikacji.

Twój klient otwiera połączenia WebSocket do listy relayów. Dla każdego wysyła wiadomość subskrypcji:

["REQ", "sub_id_1", { "authors": ["pubkey1", "pubkey2", ...], "kinds": [1, 6], "limit": 50 }]

To prosi relay o do 50 eventów od autorów na liście, rodzaju 1 (krótka notatka) lub rodzaju 6 (repost). Relay:

1. Odpytuje swoją lokalną bazę danych pod kątem pasujących eventów, wysyła je (od najstarszych do najnowszych domyślnie, do limitu) jako wiadomości EVENT z powrotem do klienta.
2. Wysyła wiadomość EOSE (koniec przechowywanych eventów), aby klient wiedział, że zrzut historyczny jest kompletny.
3. Utrzymuje subskrypcję otwartą. Każdy nowy event pasujący do filtru (opublikowany przez kogoś innego później) jest streaming do klienta w czasie rzeczywistym.

To jest jak twój feed staje się live. Nie pytasz; relay streamuje.

Twój klient robi to równolegle dla każdego skonfigurowanego relaya. Połączenie odpowiedzi to twoja oś czasu. Zduplikowane eventy na relayach są deduplikowane przez id.

Jak podpisy faktycznie zapobiegają fałszerstwu

To jest część, którą większość wyjaśnień pomija.

Gdy klient otrzyma event, przelicza hash nad kanoniczną serializacją (taki sam sposób jak wydawca) i uruchamia weryfikację Schnorra: mając pubkey, id i sig, czy podpis kryptograficznie się sprawdza?

Jeśli tak, event jest autentyczny. Autor tego eventu był posiadaczem tego pubkey w momencie podpisywania. Każdy klient uruchamia tę kontrolę na każdym evencie. Relay, który wysyła sfałszowany event ze złym podpisem, po prostu ma event upuszczony dyskretnie przez każdego klienta, który go widzi.

To ma znaczenie, ponieważ oznacza, że relaye są niezaufane. Złośliwy relay nie może wkładać słów w twoje usta. Może się weigać serwować twoje posty, może wstrzykiwać czyjeś (legalne) posty w twoją ścieżkę, ale nie może wytworzyć ważnego postu podpisanego przez ciebie bez twojego klucza prywatnego, i nie może modyfikować jeden ze swoich istniejących postów bez złamania podpisu.

Koszt tej właściwości to dokładnie jedna weryfikacja Schnorra na event, która jest wystarczająco szybka, aby nawet klienty mobilne obsługiwały ją z dziesiątkami tysięcy eventów na sekundę.

Co relaye faktycznie robią

Relay to głupi, szybki kanał z trzema zadaniami:

1. Akceptuj eventy i weryfikuj podpisy. Odrzuć wszystko, co nie weryfikuje się lub nie przechodzi kontroli polityki (filtry spamu, limity rozmiaru, zablokowane pubkey).
2. Przechowuj eventy. Zwykle w bazie danych SQLite lub PostgreSQL indeksowanej przez id, pubkey, kind i wartości tagów.
3. Serwuj subskrypcje. Dopasuj przychodziące filtry REQ do bazy danych (dla historycznych) i do eventów live (dla real-time).

To wszystko. Relay nie rankuje, nie rekomenduje, nie kuruje, nie zarabia, nie pokazuje reklam, nie stosuje algorytmu i nie robi czegoś, co platforma by zrobiła. Przekazuje podpisane bajty.

Brak tych innych zadań to powód, dla którego relaye mogą być tiny. Pojedyncza VPS za 5 dolarów miesięcznie może uruchamiać relay serwujący setki aktywnych użytkowników. Ta sama funkcja w skali Twittera kosztuje miliardy, ponieważ Twitter robi wszystkie pozostałe rzeczy.

Polityki relayów się różnią. Niektóre są permissionless i serwują każdy podpisany event. Niektóre wymagają płatności (model „paid relay"), inne ograniczają się do określonej społeczności (pracownicy firmy, członkowie serwera Discord), a jeszcze inne są agresywne w filtrowaniu spamu. Wybierasz, które relaye używać; twój wybór wpływa na to, które posty widzisz i które z nich docierają do twoich obserwatorów.

Kompletny przykład: ktoś polubia twój post

Wiążąc to razem, oto co się dzieje od końca do końca, gdy Alice polubia post, który napisał Bob.

1. Bob publikuje. Klient Boba buduje event kind:1 z treścią „hello world", podpisuje go, wysyła do pięciu skonfigurowanych relayów Boba. Każdy relay akceptuje i przechowuje.
2. Alice subskrybuje. Klient Alice ma otwartą subskrypcję na dwóch z tych relayów z filtrem, który zawiera pubkey Boba w authors. Relaye push event Boba w dół subskrypcji. Klient Alice pokazuje post w jej osi czasu.
3. Alice kliknie polubienie. Klient Alice buduje event kind:7 z treścią „+" (konwencja „polubienia" na Nostr), taguje post, do którego reaguje (["e", "bob_post_id"]) i autora (["p", "bob_pubkey"]). Podpisuje i publikuje do pięciu skonfigurowanych relayów Alice.
4. Reakcja się rozprzestrzenia. Każdy relay, który ma otwartą subskrypcję pasującą do filtru { "#e": ["bob_post_id"], "kinds": [7] } (który jest tym, co klient Boba używa do obserwowania reakcji na jego posty) push reakcję do Boba. Klient Boba agreguje polubienia i pokazuje liczbę pod postem.

Zauważ, co się nie stało. Żadna centralizowana usługa „przycisku polubienia" nie została wskazana. Żaden backend nie zdecydował, czy polubienie liczy się. Polubienie to po prostu podpisany event, ogłoszony na tych samych kanałach co sam post.

Co Nostr celowo nie robi

Pięć rzeczy pominięto z protokołu podstawowego celowo, ponieważ należą do klienta lub relaya, a nie do wspólnego formatu przewodu.

• Weryfikacja tożsamości. Nostr tylko dowodzi „ten pubkey podpisał ten post". Czy pubkey należy do konkretnego człowieka, to oddzielne pytanie odpowiedziane przez NIP-05 i kontekst offline.
• Moderacja zawartości. Protokół nie decyduje, co jest widoczne. Klienty filtrują, relaye filtrują, użytkownicy filtrują. Każda warstwa niezależnie.
• Wyszukiwanie. Nie ma globalnego punktu końcowego wyszukiwania. Niektóre relaye wspierają wyszukiwanie tekstu nad swoją lokalną pulą eventów; nie ma gwarancji protokołu, że jakikolwiek relay może znaleźć jakikolwiek post.
• Algorytmiczne rankowanie. Brak feed „dla ciebie" w protokole. Rankowanie następuje w kliencie, jeśli w ogóle.
• Odzyskiwanie konta. Brak resetowania e-mail, brak resetowania telefonu, brak centralnego systemu sporu. Stracisz klucz prywatny, stracisz tożsamość. To jest kompromis, nie błąd.

Te nieobecności to to, co sprawia, że protokół jest mały. To są również to, co sprawia, że budowanie poleranego doświadczenia użytkownika na górze jest trudniejsze niż budowanie jednego na scentralizowanej platformie, co jest uczciwym kosztem.

Dlaczego projekt w ogóle działa

Projekt opiera się na jednej prostej właściwości: podpisy są tanie do weryfikacji, fałszerstwo jest niemożliwe bez klucza prywatnego, a relaye można swobodnie zastępować.

Te trzy fakty się składają. Tania weryfikacja oznacza, że każdy klient może sprawdzić każdy event. Niemożliwe fałszerstwo oznacza, że relaye nie muszą być zaufane. Swobodna wymiana oznacza, że żaden single relay nie ma mocy nad kimkolwiek.

Razem wzięte, masz sieć społeczną, gdzie warstwa platformy jest zamienna, a warstwa tożsamości jest własnością użytkownika. Co to jest „zdecentralizacja" faktycznie w praktyce, w przeciwieństwie do tego, jak marketing zwykle używa tego słowa.

Jeśli chcesz zobaczyć cały przepływ ze strony użytkownika (para kluczy, tożsamość NIP-05, lista relayów, portfel, gotowy do postowania), kolaps rejestracji nostr.blog wciąga te kroki w jedną stronę. Mechanika opisana tutaj to to, co faktycznie przebiega pod tym przepływem.