Nostr

Anna znajduje w Nostr autorów, których chce obserwować. Z czasem aplikacja przestaje jej odpowiadać. Jeśli bezpiecznie użyje tego samego klucza prywatnego lub podłączonego urządzenia podpisującego w innej aplikacji, może zachować tożsamość. Klucz publiczny pozwala innym ją rozpoznać i sprawdzać podpisy; klucz prywatny umożliwia podpisywanie jako Anna. Dlatego npub i nsec tak bardzo się różnią. Zgodnie z NIP-19 oznaczają klucz publiczny i prywatny zapisane w kodowaniu Bech32. NIP to numerowane dokumenty opisujące zasady i rozszerzenia Nostr. Kodowanie nie jest szyfrowaniem: nsec nie jest niewinnym linkiem do profilu, który można wysłać każdemu. Zachowanie tożsamości nie gwarantuje też, że nowa aplikacja znajdzie wszystkie dawne wpisy lub przejmie każde ustawienie. [2] [7]

Aplikacja, nazywana klientem, podpisuje wpis i wysyła go do wybranych relayów. Relay to serwer przyjmujący wiadomości i zapisujący je lub przekazujący zgodnie z własnymi zasadami. Aplikacja Petra łączy się z relayami i prosi o interesujące go wpisy. Nie istnieje jeden centralny serwer ani obowiązek kopiowania wszystkiego na każdym serwerze. Technicznie klient i relay komunikują się przez WebSocket, stale otwarte połączenie: EVENT przesyła wiadomość, REQ rozpoczyna subskrypcję, a OK informuje o przyjęciu lub odrzuceniu. Nawet pozytywne OK nie potwierdza dostarczenia Petrowi ani trwałej archiwizacji. EOSE oznacza koniec zapisanych wyników danego zapytania; subskrypcja może potem nadal dostarczać nowe wiadomości. [1] [7]

Kiedy Petr odbierze wiadomość, aplikacja sprawdza, czy podpis pasuje do podanego klucza publicznego i czy podpisane dane nie zostały zmienione. Nie dowodzi to prawdziwości wiadomości ani tożsamości autora poza siecią. Także czas utworzenia podaje autor, więc nie jest to niezależny znacznik czasu. Dla zainteresowanych techniką: rekord nazywany event zawiera pubkey, created_at, kind, tags oraz content, czyli klucz, czas, rodzaj, znaczniki i treść. SHA-256 oblicza z ich ściśle określonego zapisu krótki skrót kontrolny o nazwie id. Pozwala on wykryć zmianę podpisanych danych. Pole sig zawiera Schnorr Signature, podpis zgodny z BIP340 na krzywej secp256k1. Potwierdza on, że posiadacz odpowiedniego klucza podpisał dane, a nie że zawartemu w nich twierdzeniu należy ufać. [1]

Długi klucz publiczny trudno zapamiętać. NIP-05 pozwala powiązać go z identyfikatorem przypominającym adres e-mail. Aplikacja pyta właściwą domenę, jaki klucz odpowiada nazwie, i porównuje odpowiedź z kluczem profilu. Sprawdza tym samym konkretne powiązanie z domeną, nie automatycznie prawdziwe nazwisko, reputację czy rzetelność człowieka. Operator domeny może później zmienić przypisanie. Jeśli Anna już kogoś obserwuje, decydujący powinien pozostać pierwotny klucz publiczny; nowy klucz pod tą samą nazwą nie powinien po cichu zmienić obserwowanej osoby. Pseudonimowość oznacza trwałe oznaczenie zamiast nazwiska, a nie gwarancję anonimowości. [3]

Petr nie musi pobierać wszystkich wiadomości. Wysyła filtr, na przykład obejmujący określonych autorów i rodzaj wpisu. Różne warunki jednego filtru łączy AND: wszystkie muszą być spełnione. Kilka dozwolonych wartości jednego warunku to alternatywy OR; tak samo łączy się różne filtry w jednym REQ. Wystarczy spełnić jeden z nich. limit ogranicza początkową paczkę zapisanych wyników, nie automatycznie przyszłe wiadomości w subskrypcji. NIP-01 używa w zdarzeniach i filtrach szesnastkowego zapisu kluczy, nie przeznaczonej dla użytkownika postaci npub. Pusty wynik może wynikać z filtru, wyboru serwera lub jego historii; nie dowodzi, że wpis nie istnieje nigdzie. [1]

Anna zmienia opis profilu i chce, żeby inni widzieli nowy. Nostr rozróżnia więc zasady przechowywania danych przez relaye. W przypadku zdarzeń zastępowalnych wybierają one najnowszy rekord dla tej samej pary pubkey i kind. Zdarzenia adresowalne uwzględniają dodatkowo wartość znacznika d, odróżniając na przykład dokumenty tego samego autora. Jeśli zastępowalne rekordy mają ten sam czas, zaleca się zachowanie leksykograficznie mniejszego id, czyli pierwszego według kolejności jego zapisu. Zdarzenia tymczasowe, określane jako ephemeral, nie mają nawet wymogu przechowywania. Są to konwencje i relaye mogą zachowywać się różnie. Nostr nie jest zatem księgą, w której cała sieć uzgadnia jedną niezmienną historię. [1]

Anna zauważa, że opublikowała coś, co miało pozostać prywatne. NIP-09 pozwala wysłać podpisaną prośbę o usunięcie. Przed jej wykonaniem klient musi sprawdzić, czy prośba i pierwotny wpis należą do tego samego klucza publicznego. Obca osoba nie może usunąć wpisu Anny tylko przez wskazanie go. Współpracujące serwery i aplikacje mogą usunąć treść lub przestać ją wyświetlać. Prośba nie usunie jednak wszystkich kopii, zrzutów ekranu ani niezależnych archiwów. Ukrycie wpisu w jednej aplikacji nie mówi też, czy inny serwer nadal go udostępnia. Ważniejsze jest więc to, co publikujesz, niż sama obecność przycisku Usuń. [4]

Publiczny wpis może przeczytać każdy, kto go otrzyma; sam podpis nie ukrywa treści. Prywatne wiadomości korzystają z dodatkowych reguł. NIP-44 opisuje szyfrowanie treści, a NIP-17 sposób opakowania i dostarczania wiadomości z dodatkowymi warstwami ochrony. Nie daje to automatycznej anonimowości: adresy sieciowe, czas komunikacji i zachowanie aplikacji mogą nadal ujawniać informacje. Ten sposób szyfrowania nie zapewnia też forward secrecy, czyli ochrony dawnych rozmów w razie późniejszego wycieku klucza długoterminowego. Kto zdobędzie odpowiedni klucz prywatny i wcześniej zapisane zaszyfrowane wiadomości, może odczytać także starszą komunikację. Sprawdź więc, jakie rozszerzenia rzeczywiście obsługuje aplikacja; samo „Nostr” nie określa jej poziomu prywatności. [5] [6]