Nostr to otwarty protokół podpisanych zdarzeń wymienianych przez klientów za pośrednictwem niezależnych przekaźników. Sieci społecznościowe są jednym zastosowaniem; protokół nie ma własnego blockchaina ani wspólnego konsensusu wszystkich przekaźników.
Zdarzenie zawiera pubkey, created_at, kind, tags, content, id i sig. NIP-01 wyprowadza id przez SHA-256 z dokładnie określonej serializacji i używa BIP340 na secp256k1. Klient sprawdza integralność i autoryzację kluczem. created_at podaje autor; nie jest to niezależny znacznik czasu ani dowód prawdziwości treści. [Nostr — NIP-01: Basic protocol] [fiatjaf — Original Nostr description]
Klient publikuje EVENT i subskrybuje przez REQ po WebSocket. OK oznacza przyjęcie lub odrzucenie przez ten przekaźnik. EOSE kończy listę zapisanych zdarzeń, niekoniecznie subskrypcję nowych. Żaden komunikat nie potwierdza odbioru przez adresata, replikacji w całej sieci ani trwałego przechowania. [Nostr — NIP-01: Basic protocol]
W jednym filtrze zdarzenie musi spełnić wszystkie warunki: autor i rodzaj oznaczają AND. Wiele filtrów jednego REQ łączy OR; wystarczy jeden. limit ogranicza początkową listę, nie liczbę przyszłych zdarzeń. Brak wyniku może oznaczać ograniczoną historię przekaźnika, nie nieistnienie zdarzenia. [Nostr — NIP-01: Basic protocol]
Zdarzenia zastępowalne porównuje się według pubkey i kind, adresowalne także według znacznika d. Nowsza wersja może zastąpić starszą; przy równym czasie wygrywa leksykograficznie niższe id. Zdarzeń ulotnych nie przewiduje się przechowywać. Reguły opisują przekaźniki, nie niezmienne globalne archiwum; implementacje mogą się różnić. [Nostr — NIP-01: Basic protocol]
NIP-19 używa Bech32 do prezentacji użytkownikowi: npub oznacza klucz publiczny, nsec prywatny. Kodowanie nie jest szyfrowaniem. Udostępnienie nsec przekazuje więc tajny klucz, nie tylko link do profilu. Zdarzenia i filtry NIP-01 używają szesnastkowych kluczy publicznych, nie ich zapisu npub. [Nostr — NIP-19: Encoded entities]
NIP-05 wiąże nazwę podobną do adresu e-mail z kluczem publicznym na podstawie odpowiedzi domeny. Potwierdza powiązanie, nie rzeczywistą tożsamość ani uczciwość. Klient powinien śledzić pierwotny klucz: zmiana przypisania nazwy w domenie nie może automatycznie zastąpić obserwowanego profilu nowym kluczem. [Nostr — NIP-05: Internet identifiers]
NIP-09 definiuje prośbę autora o usunięcie jego zdarzeń. Przed ukryciem klient powinien sprawdzić zgodność kluczy publicznych oryginału i żądania. Przekaźniki i klienci mogą je przetworzyć, lecz protokół nie usunie każdej pobranej lub zachowanej kopii. Usunięcie w jednym interfejsie nie dowodzi globalnego wymazania. [Nostr — NIP-09: Deletion requests]
NIP-44 definiuje zaszyfrowany payload, nie cały system prywatnych wiadomości; NIP-17 dodaje opakowania i reguły doręczania. Samo NIP-44 nie zapewnia forward secrecy po późniejszym wycieku klucza. Adresy sieciowe, czas i zachowanie klienta pozostają istotne nawet przy szyfrowaniu. Obsługę NIP trzeba rozróżniać według aplikacji. [Nostr — NIP-44: Encrypted payloads] [Nostr — NIP-17: Private messages]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Nostr Wallet Connect, Schnorr signature, Klucz prywatny, Prywatność w Bitcoinie, Pseudonimowość. Do tego hasła prowadzą również odsyłacze z Nostr Wallet Connect, Network Effect.