Nostr

Anna si v Nostr najde autory, které chce sledovat. Později jí přestane vyhovovat aplikace. Pokud v jiné aplikaci bezpečně použije stejný soukromý klíč nebo připojené podepisovací zařízení, může dál vystupovat pod stejnou identitou. Veřejný klíč slouží ostatním k jejímu rozpoznání a ověřování podpisů; soukromý klíč dovoluje podepisovat jako ona. Proto je důležitý rozdíl mezi npub a nsec. Podle NIP-19 jsou to zápisy veřejného a soukromého klíče v kódování Bech32. NIP jsou číslované dokumenty popisující pravidla a rozšíření Nostr. Kódování není šifrování: nsec není bezpečný odkaz na profil, který lze poslat komukoli. Přenos identity také automaticky nezaručuje, že nová aplikace najde všechny staré příspěvky nebo převezme každé nastavení. [2] [7]

Aplikace, které se říká klient, příspěvek podepíše a pošle vybraným relays. Relay je server, který zprávy přijímá a podle svých pravidel ukládá nebo předává. Petrova aplikace se připojuje k relays a žádá o příspěvky, které ho zajímají. Není tu jediný centrální server ani povinná kopie všeho na každém serveru. Technicky spolu klient a relay mluví přes WebSocket, průběžně otevřené spojení: EVENT přenáší zprávu, REQ vytváří odběr a OK oznamuje přijetí nebo odmítnutí. Ani kladné OK nepotvrzuje doručení Petrovi nebo trvalou archivaci. EOSE znamená konec odesílání uložených výsledků daného dotazu; odběr pak může pokračovat novými zprávami. [1] [7]

Když Petr obdrží zprávu, aplikace ověří, zda podpis odpovídá uvedenému veřejnému klíči a zda podepsaná data nebyla změněna. Takový podpis ale nepotvrzuje pravdivost zprávy ani občanskou totožnost autora. Také čas vytvoření vyplňuje autor, takže není nezávislým časovým razítkem. Pro zájemce o techniku: záznam zvaný event obsahuje pubkey, created_at, kind, tags a content, tedy klíč, čas, druh, značky a obsah. Z jejich přesně předepsaného zápisu vytvoří SHA-256 krátký kontrolní údaj nazvaný id. Ten umožňuje rozpoznat změnu podepsaných dat. Pole sig nese Schnorr Signature, podpis podle BIP340 na křivce secp256k1. Výsledek říká „tato data podepsal držitel odpovídajícího klíče“, nikoli „tomuto tvrzení lze věřit“. [1]

Dlouhý veřejný klíč se špatně pamatuje. NIP-05 dovoluje spojit jej s identifikátorem ve tvaru podobném e-mailové adrese. Aplikace se zeptá příslušné domény, ke kterému klíči jméno patří, a porovná odpověď s klíčem profilu. Tím ověřuje konkrétní vazbu na doménu, nikoli automaticky skutečné jméno, pověst nebo spolehlivost člověka. Provozovatel domény může přiřazení později změnit. Když už Anna někoho sleduje, rozhodující má zůstat původní veřejný klíč; nové přiřazení stejného jména nemá potichu změnit sledovanou osobu. Pseudonymita znamená možnost vystupovat pod trvalým označením místo občanského jména, ne záruku anonymity. [3]

Petr nemusí chtít stahovat všechny zprávy. Pošle filtr, například příspěvky určitých autorů a určitého druhu. Uvnitř jednoho filtru se různé podmínky spojují pravidlem AND: všechny musí platit současně. Více povolených hodnot jedné podmínky se bere jako možnosti OR; stejně se spojí i více filtrů v jednom REQ. Stačí vyhovět jednomu z těchto filtrů. limit omezuje počáteční dávku uložených výsledků, nikoli automaticky budoucí zprávy v odběru. NIP-01 přitom v událostech a filtrech používá hexadecimální zápis klíčů, nikoli uživatelský formát npub. Když hledání nic nevrátí, může být problém ve filtru, zvoleném serveru nebo jeho historii; není to důkaz, že příspěvek nikde neexistuje. [1]

Anna změní popis profilu a chce, aby ostatní viděli nový. Nostr proto rozlišuje, co mají relays uchovávat. U nahraditelných událostí vybírají nejnovější záznam pro stejnou dvojici pubkey a kind. U adresovatelných událostí se přidává hodnota značky d, která rozlišuje například jednotlivé dokumenty stejného autora. Při shodném čase se u nahraditelných záznamů doporučuje ponechat lexikograficky nižší id, tedy první podle pořadí jeho zápisu. Dočasné, takzvané ephemeral události se ani neočekává trvale ukládat. Jde o konvence a chování relays se může lišit. Nostr tedy není účetní kniha, v níž se celá síť shodne na jediné neměnné historii. [1]

Anna si všimne, že zveřejnila něco, co zveřejnit nechtěla. NIP-09 umožňuje poslat podepsanou žádost o smazání. Klient má před jejím uplatněním ověřit, že žádost i původní příspěvek patří stejnému veřejnému klíči; cizí člověk nesmí smazat Annin příspěvek jen tím, že na něj odkáže. Spolupracující servery a aplikace mohou obsah odstranit nebo přestat zobrazovat. Žádost ale nedokáže odstranit všechny kopie, snímky obrazovky nebo nezávislé archivy. A skrytí příspěvku v jedné aplikaci neříká nic o tom, zda ho jiný server stále nabízí. Při publikování proto záleží hlavně na tom, co odesíláte, nejen na přítomnosti tlačítka Smazat. [4]

Veřejné příspěvky může číst každý, kdo se k nim dostane; samotný podpis jejich obsah neskryje. Pro soukromé zprávy existují další pravidla. NIP-44 popisuje šifrování obsahu, zatímco NIP-17 řeší způsob zabalení a doručení zpráv s dalšími vrstvami ochrany. To není totéž jako automatická anonymita: síťové adresy, načasování a chování aplikace mohou dál něco prozrazovat. U tohoto způsobu šifrování navíc chybí forward secrecy, ochrana staré komunikace při pozdějším úniku dlouhodobého klíče. Kdo získá potřebný soukromý klíč a dříve zachycené šifrované zprávy, může číst i minulou komunikaci. Ověřte proto, která rozšíření konkrétní aplikace skutečně podporuje; označení „Nostr“ samo nepopisuje její úroveň soukromí. [5] [6]