Nostr je otevřený protokol podepsaných událostí pro komunikaci klientů přes nezávislé relay servery. Sociální síť je jedním použitím; protokol nemá vlastní blockchain ani společný konsenzus všech relay serverů.
Událost obsahuje pubkey, created_at, kind, tags, content, id a sig. NIP-01 odvozuje id pomocí SHA-256 z přesně určené serializace a podpis používá BIP340 na secp256k1. Klient ověřuje integritu a autorizaci klíčem. Čas created_at uvádí autor; není nezávislým časovým razítkem ani důkazem pravdivosti obsahu. [Nostr — NIP-01: Basic protocol] [fiatjaf — Original Nostr description]
Klient přes WebSocket publikuje EVENT a odebírá události pomocí REQ. Odpověď OK oznamuje přijetí či odmítnutí konkrétním relay. EOSE ukončuje výpis uložených událostí, nikoli nutně odběr nových. Žádná z těchto zpráv nepotvrzuje doručení příjemci, replikaci celé sítě či trvalé uložení. [Nostr — NIP-01: Basic protocol]
V jednom filtru musí událost splnit všechny uvedené podmínky: autor a druh znamenají AND. Více filtrů v jednom REQ se spojuje jako OR; stačí jeden. limit omezuje počáteční výpis, nikoli počet budoucích událostí. Chybějící výsledek může znamenat omezenou historii relay, nikoli neexistenci události. [Nostr — NIP-01: Basic protocol]
Nahraditelné události se porovnávají podle pubkey a kind, adresovatelné navíc podle značky d. Novější verze může nahradit starší; při shodném čase rozhoduje lexikograficky nižší id. Pomíjivé události se neočekává ukládat. Tato pravidla popisují chování relay, nikoli neměnný globální archiv; implementace se mohou lišit. [Nostr — NIP-01: Basic protocol]
NIP-19 používá Bech32 pro uživatelský zápis: npub označuje veřejný klíč, nsec soukromý. Kódování není šifrování. Sdílení nsec tedy předává tajný klíč, nikoli pouhý odkaz na profil. Vlastní události a filtry NIP-01 používají hexadecimální podobu veřejných klíčů, ne jejich zobrazení npub. [Nostr — NIP-19: Encoded entities]
NIP-05 spojuje jméno podobné e-mailové adrese s veřejným klíčem podle odpovědi domény. Dokládá tuto vazbu, nikoli skutečnou totožnost či poctivost osoby. Klient má sledovat původní klíč: změní-li doména mapování jména na jiný klíč, nemá jej automaticky podstrčit místo dříve sledovaného profilu. [Nostr — NIP-05: Internet identifiers]
NIP-09 definuje žádost autora o odstranění jeho událostí. Klient má před skrytím ověřit shodu veřejného klíče původní události a žádosti. Relay a klienti mohou požadavek zpracovat, ale protokol nedokáže odstranit všechny dříve stažené či jinak uchované kopie. Smazání v jednom rozhraní není důkazem globálního vymazání. [Nostr — NIP-09: Deletion requests]
NIP-44 definuje šifrovaný payload, nikoli celý systém soukromých zpráv; NIP-17 přidává obálky a pravidla doručování. Samotné NIP-44 neposkytuje forward secrecy při pozdějším úniku klíče. Síťové adresy, časování a chování klienta zůstávají důležité i se šifrovaným obsahem. Podporu konkrétních NIP je nutné rozlišovat podle aplikace. [Nostr — NIP-44: Encrypted payloads] [Nostr — NIP-17: Private messages]
Pro nejúplnější obraz čtěte toto heslo společně s Nostr Wallet Connect, Schnorrův podpis, Privátní klíč, Soukromí v Bitcoinu, Pseudonymita. Opačným směrem na něj odkazují také Nostr Wallet Connect.