NIP-17: Prywatne Wiadomości Bezpośrednie - Kompletny Przewodnik
Dowiedz się o NIP-17, bezpiecznym zamienniku dla NIP-04, i jak migrować swoje prywatne wiadomości w Nostr
NIP-17 reprezentuje znaczącą aktualizację bezpieczeństwa dla prywatnych wiadomości w Nostr. Ten przewodnik wyjaśnia dlaczego powinieneś dbać o tę poprawę protokołu, jak migrować ze starego standardu NIP-04 oraz praktyczne kroki do zabezpieczenia swojej komunikacji.
Czym jest NIP-17?
NIP-17 to specyfikacja protokołu Nostr, która definiuje Prywatne Wiadomości Bezpośrednie używając dwuwarstwowego systemu szyfrowania zwanego “seal + gift wrap”. Została stworzona, aby rozwiązać fundamentalne luki bezpieczeństwa w poprzedniej metodzie szyfrowania NIP-04.
W przeciwieństwie do NIP-04, który używał pojedynczej warstwy szyfrowania AES-256-CBC, NIP-17 używa:
- Seal (kind 13): wewnętrzna warstwa podpisana Twoim prawdziwym kluczem, dzięki czemu osoba, do której piszesz, wie, że wiadomość naprawdę jest od Ciebie
- Gift wrap (kind 1059): zewnętrzna koperta podpisana kluczem jednorazowym. Ukrywa seala, więc Twoja prawdziwa tożsamość nigdy nie pojawia się w evencie przechowywanym przez relaye
To rozwarstwienie oznacza, że:
- Treść wiadomości pozostaje prywatna
- Relaye nie widzą, kto wysłał wiadomość. Gift wrap jest podpisany losowym kluczem jednorazowym, nie Twoim
- Timestampy są losowane, więc trudniej skorelować momenty wysyłki
Relaye nadal widzą, do kogo piszesz
Gift wrap niesie klucz publiczny odbiorcy w jawnym tagu p. Musi go nieść, bo
inaczej relay odbiorcy nie wiedziałby, komu dostarczyć wiadomość. NIP-17
ukrywa nadawcę, a nie odbiorcę.
Każdy, kto czyta strumień relaya, widzi, że ktoś wysłał Ci wiadomość i kiedy. Nie widzi tylko kto i co. Jeśli Twój model zagrożeń wymaga ukrycia samego faktu, że cokolwiek dostałeś, sam NIP-17 nie wystarczy.
Dlaczego NIP-17 Ma Znaczenie: Problem Bezpieczeństwa NIP-04
NIP-04 był oryginalnym protokołem wiadomości bezpośrednich w Nostr, ale ma kilka krytycznych problemów bezpieczeństwa, które czynią go nieodpowiednim dla naprawdę prywatnej komunikacji.
Porównanie: NIP-04 vs NIP-17
| Cecha | NIP-04 | NIP-17 |
|---|---|---|
| Szyfrowanie | Pojedyncza warstwa AES-256-CBC | Dwuwarstwowe (seal + gift wrap) |
| Metadane Nadawcy | Widoczne dla relayów | Ukryte (klucz jednorazowy) |
| Metadane Odbiorcy | Widoczne dla relayów | Nadal widoczne w jawnym tagu p |
| Treść Wiadomości | Zaszyfrowana | Zaszyfrowana |
| Metadane czasowe | Prawdziwe timestampy widoczne | Losowane, cofane nawet o dwa dni |
| Forward Secrecy | Nie | Nie (NIP-44 tego nie zapewnia) |
| Status Bezpieczeństwa | Przestarzały | Zalecany |
| Interoperacyjność | Powszechnie wspierany | Rosnące wsparcie |
Podstawowy Problem z NIP-04
Wiadomości NIP-04 ujawniają kto z kim rozmawia każdemu relayowi, który je przechowuje. (Nostr nie ma żadnego blockchaina. Eventy po prostu leżą na relayach, a czytać z relaya może każdy.) Podczas gdy treść wiadomości jest zaszyfrowana, koperta zawiera:
# Struktura Eventu NIP-04 (uproszczona)
{
"pubkey": "<sender_public_key>", # Każdy może zobaczyć kto to wysłał
"tags": [["p", "<recipient_pubkey>"]], # Każdy może zobaczyć kto to otrzymał
"content": "<encrypted_content>" # Tylko treść jest ukryta
}
Oznacza to, że operatorzy relayów, obserwatorzy sieci i scrapery danych mogą:
- Budować grafy społeczne pokazujące kto z kim komunikuje się
- Śledzić wzorce i częstotliwość komunikacji
- Wnioskować o relacjach z timingów wiadomości
NIP-17 domyka większość tej luki, owijając całą wiadomość w zewnętrzną kopertę podpisaną kluczem jednorazowym, więc relay nie potrafi stwierdzić, kto ją wysłał. Jedno zostaje jawne z założenia: klucz publiczny odbiorcy jedzie na kopercie w zwykłym tagu, bo relay musi wiedzieć, komu wiadomość wydać. NIP-17 ukrywa więc nadawcę, a nie odbiorcę.
Jak Działa NIP-17: Seal + Gift Wrap
Zrozumienie implementacji technicznej pomaga docenić ulepszenia bezpieczeństwa.
Warstwa Gift Wrap (Zewnętrzna)
Gift wrap to koperta, którą relay faktycznie przechowuje. Twój klient generuje zupełnie nowy klucz na tę jedną wiadomość, podpisuje nim kopertę i klucz wyrzuca. Zawartość jest zaszyfrowana tak, że otworzy ją tylko odbiorca. Ta warstwa niesie:
- Losowy klucz publiczny jednorazowego użytku, bez niczego, co prowadziłoby do Ciebie
- Klucz publiczny odbiorcy, w jawnym tagu, który relay może odczytać
- Losowany timestamp
- Zapieczętowaną wiadomość wewnętrzną
Warstwa Seal (Wewnętrzna)
Wewnątrz gift wrapa znajduje się seal. To tutaj mieszka autorstwo i tego relay nie zobaczy nigdy. Ta warstwa:
- Jest podpisana Twoim prawdziwym kluczem, po tym odbiorca wie, że wiadomość jest od Ciebie
- Jest zaszyfrowana kluczem wyprowadzonym z Twojego klucza prywatnego i klucza publicznego odbiorcy, więc odczytacie ją tylko wy dwoje
- Niesie treść wiadomości
- Niesie timestamp, który Twój klient celowo cofa nawet o dwa dni, żeby nikt nie grupował wiadomości po czasie wysyłki
Gift wrap (warstwa zewnętrzna)
Losowy pubkey i wskazówka odbiorcy: tylko tyle widzi relay
Seal (warstwa wewnętrzna)
Podpisany prawdziwym kluczem nadawcy, czytelny tylko dla odbiorcy
Faktyczna treść wiadomości
Nadawca: prawdziwy pubkey · Timestamp: 1234567890
Kluczowe Korzyści
- Prywatność nadawcy: Nikt poza odbiorcą nie ustali, kto wysłał wiadomość.
Odbiorca jest jednak wskazany w jawnym tagu
p, który relaye muszą móc odczytać. - Niepowiązywalność: Każda wiadomość jest podpisana świeżym kluczem jednorazowym, więc wiadomości od tego samego nadawcy nie układają się w oczywisty zbiór.
- Brak forward secrecy: NIP-44 wyprowadza klucz rozmowy z dwóch statycznych
kluczy, więc atakujący, który później zdobędzie Twój
nsec, odszyfruje każdą zapisaną wiadomość. Klucze jednorazowe ukrywają, kto wysłał wiadomość; nie chronią starych wiadomości. Jeśli to dla Ciebie istotne, usuwaj stare rozmowy.
Dostarczanie: Lista Relayów DM (Kind 10050)
Seal i gift wrap opisują, jak wiadomość jest zapakowana. O tym, dokąd trafia, decyduje trzeci element: event kind 10050. To mała, publiczna lista relayów, które przyjmują Twoje prywatne wiadomości.
Specyfikacja jest w tej kwestii rygorystyczna: nadawcy MUSZĄ publikować gift wrapy wyłącznie na relaye z listy kind 10050 odbiorcy. Jeśli nigdy jej nie opublikowałeś, specyfikacja traktuje Cię jako “niegotowego na odbieranie wiadomości” i klienci nie powinni nawet próbować. DM-y adresowane do Ciebie po cichu nigdy nie są dostarczane. Po żadnej stronie nie ma błędu.
Dwie praktyczne zasady:
- Opublikuj ją, zanim zaczniesz oczekiwać jakichkolwiek DM-ów NIP-17 (zobacz Krok 3 przewodnika migracji poniżej)
- Trzymaj ją małą. Specyfikacja zaleca 1-3 relaye, a każdy relay na liście widzi, kto wysyła Ci wiadomości
Przewodnik Migracji: Przełączanie z NIP-04 na NIP-17
Migrowanie do NIP-17 jest proste z nowoczesnymi klientami Nostr. Oto jak dokonać zmiany.
Krok 1: Sprawdź Wsparcie Swojego Klienta
NIP-17 pomaga tylko wtedy, gdy mówi nim klient po obu stronach rozmowy. Te cztery deklarują to we własnej dokumentacji albo we własnym kodzie źródłowym:
| Klient | NIP-17 | Gdzie działa |
|---|---|---|
| Amethyst | Tak | Android |
| 0xchat | Tak | Android, iOS |
| Coracle | Tak | Web |
| Snort | Tak | Web |
Damus wymaga osobnego ostrzeżenia. Na wrzesień 2026 lista specyfikacji, którą publikuje Damus, wciąż nie zawiera NIP-17, tylko stary NIP-04. Wynikają z tego dwie rzeczy i obie są istotne. Wiadomość w gift wrapie, którą wyślesz, w ogóle się komuś na Damusie nie pokaże. A to, co on wyśle Tobie, wyjdzie jako zwykły event kind 4 z waszymi dwoma kluczami publicznymi na wierzchu, gdzie odczyta je każdy relay, który go przechowa. Jeśli rozmowa jest wrażliwa, przenieście ją do któregoś z klientów powyżej.
Primal, Iris i Nos siedzą w nierozstrzygniętym środku. Primal nie mówi publicznie ani tak, ani nie, więc traktuj go jako niewiadomą. Iris szyfruje swoje prywatne czaty własnym schematem z podwójną zapadką, a nie zwykłym NIP-17, co jest w porządku wewnątrz Irisa i niczego nie gwarantuje poza nim. Nos nie wymienia ani NIP-17, ani dwóch specyfikacji, na których ten stoi, a w projekcie cicho od początku 2025 roku.
Listy funkcji w klientach zmieniają się szybciej niż poradniki. Jeśli Twojego tu nie ma, test z Kroku 5 rozstrzygnie sprawę szybciej niż czytanie changelogów.
Krok 2: Zwykle Nie Ma Czego Włączać
Ten krok jest krótszy, niż się spodziewasz. Żaden z powyższych klientów nie opisuje przełącznika „włącz NIP-17”, bo nie ma czego szukać. Używają gift wrapów automatycznie w momencie, w którym druga strona jest w stanie je odebrać.
Przeskocz więc do Kroku 3, bo to ta część naprawdę Cię potrzebuje. Twoje dotychczasowe rozmowy w NIP-04 zostają na miejscu i pozostają czytelne, nic ich nie konwertuje.
Krok 3: Opublikuj Swoją Listę Relayów DM (Kind 10050)
Nadawcy NIP-17 dostarczają wyłącznie na relaye wymienione w Twoim evencie kind 10050. Bez niego wiadomości do Ciebie są po cichu porzucane (zobacz Dostarczanie: Lista Relayów DM powyżej).
- W swoim kliencie poszukaj ustawienia relayów DM, wiadomości prywatnych lub wiadomości bezpośrednich
- Dodaj od jednego do trzech relayów, które przyjmują gift wrapy (kind 1059). Niektóre relaye je odrzucają
- Zapisz. Twój klient opublikuje listę kind 10050 za Ciebie
Niektórzy klienci publikują tę listę za Ciebie przy pierwszym otwarciu prywatnego czatu. Nie zakładaj, że Twój to zrobił: zweryfikuj dostarczanie w Kroku 5, zanim na tym polegasz.
Krok 4: Skomunikuj się ze Swoimi Kontaktami
NIP-17 działa tylko jeśli obie strony mają wsparcie NIP-17. Wyślij wiadomość do częstych kontaktów:
"Hej! Aktualizuję do NIP-17 dla lepszej prywatności w naszych DM-ach.
Proszę zaktualizuj swojego klienta Nostr, jeśli jeszcze tego nie zrobiłeś.
Nasze przyszłe wiadomości będą bezpieczniejsze!"
Krok 5: Sprawdź, Czy To Naprawdę Działa
Sprawdzian, który się liczy, nie wymaga żadnej wiedzy technicznej. Poproś kogoś używającego klienta z Kroku 1, żeby do Ciebie napisał, i odpisz. Jeśli obie strony dochodzą, Twoja lista kind 10050 jest opublikowana, a gift wrapy do Ciebie docierają. Jeśli Twoja wiadomość znika i żadne z was nie widzi błędu, to klasyczny objaw braku listy relayów, a wracasz wtedy do Kroku 3.
Ten sam test zrobisz w pojedynkę: zaloguj się na swoje konto w drugim kliencie albo napisz do samego siebie, jeśli Twój klient na to pozwala.
Jeśli ciekawi Cię, co naprawdę leci w eter, przeglądarka eventów Nostr, na przykład njump.me, pokaże Ci surowe eventy. Działający gift wrap wygląda mniej więcej tak:
// Przykładowy event NIP-17 (uproszczony)
{
"kind": 1059, // Event gift wrap
"pubkey": "<random_ephemeral_key>", // Nie prawdziwy nadawca!
"tags": [["p", "<recipient_pubkey>"]],
"content": "<encrypted_seal_content>"
}
Dwie rzeczy warto tam odczytać. pubkey to klucz jednorazowy, którego nie
rozpoznasz, i to właśnie jest ukryty nadawca, dokładnie o to chodzi. Tag p
pokazuje za to prawdziwy klucz odbiorcy. To nie usterka Twojej konfiguracji,
relay potrzebuje go, żeby wiedzieć, dokąd wiadomość trafia.
Najlepsze Praktyki Bezpieczeństwa
Maksymalizuj swoją prywatność używając NIP-17:
1. Weryfikuj Wsparcie Klienta Przed Wrażliwą Komunikacją
Zawsze potwierdzaj, że Twój kontakt używa klienta wspierającego NIP-17, zanim wyślesz cokolwiek wrażliwego. Gift wrap wysłany do kogoś, czyj klient mówi wyłącznie NIP-04, nie dociera jako bełkot. Nie dociera wcale: jego klient nigdy nie szuka eventów kind 1059 i żadne z was nie zobaczy błędu.
2. Zejście z Powrotem na NIP-04 To Prawdziwa Decyzja
Część klientów pozwoli Ci ciągnąć stary wątek na NIP-04. Bywa to praktyczny wybór, ale wiedz, ile kosztuje: wiadomość NIP-04 kładzie oba klucze publiczne, jawnie, na evencie, który przechowa każdy relay. Zostaw to dla rozmów, których publiczne powiązanie z Tobą Ci nie przeszkadza, a wszystko wrażliwe zaczynaj jako nową rozmowę na NIP-17.
3. Używaj Świeżych Kluczy dla Rozmów o Wysokim Bezpieczeństwie
Dla maksymalnego bezpieczeństwa:
- Utwórz dedykowaną parę kluczy dla wrażliwej komunikacji
- Udostępnij klucz publiczny przez bezpieczny kanał poza pasmem
- Rotuj klucze okresowo
4. Bądź Świadomy Metadanych w Innych Typach Eventów
NIP-17 chroni tylko wiadomości bezpośrednie. Inne typy eventów (notatki, reakcje, obserwacje) nadal ujawniają dane grafu społecznego. Używaj wielu tożsamości dla kompartmentalizacji.
5. Wybieraj Relaye Skupione na Prywatności
Nawet z NIP-17, Twoje wzorce ruchu są widoczne dla relayów. Używaj:
- Tor lub VPN dla dodatkowej prywatności na poziomie sieci
- Relayów, które nie logują lub nie zachowują metadanych wiadomości
- Wielu relayów do rozproszenia Twojego ruchu
6. Zrozum Ograniczenia
NIP-17 to realna poprawa i nie jest peleryną niewidką:
- Relaye nadal widzą Twój adres IP (używaj VPN albo Tora)
- Analiza czasów nadal może ujawnić wzorce komunikacji
- Klucz odbiorcy jest na kopercie jawnie, z założenia
- Przejęty telefon albo klient wycieka wszystko, cokolwiek robi protokół
Rozwiązywanie Powszechnych Problemów
„Moje wiadomości nigdy nie docierają”: najpierw sprawdź listę relayów DM
To najczęstsza awaria NIP-17 i prawie nigdy nie chodzi o szyfrowanie.
Nadawcy NIP-17 nie dostarczają na Twoje zwykłe relaye. Szukają eventu kind 10050, czyli Twojej opublikowanej listy relayów przyjmujących wiadomości bezpośrednie, i wysyłają gift wrap wyłącznie tam. Jeśli nigdy jej nie opublikowałeś, klient nadawcy nie ma dokąd dostarczyć i wiadomość znika po cichu. Żaden z interfejsów nic nie pokaże.
Naprawa: w kliencie obsługującym NIP-17 znajdź ustawienie relayów dla wiadomości prywatnych i zapisz przynajmniej jeden relay. To publikuje Twoją listę kind 10050. Wybierz relay, który faktycznie przyjmuje gift wrapy, bo część odrzuca kind 1059. (To jest Krok 3 przewodnika migracji. Jeśli go pominąłeś, zacznij od niego.)
Trzymaj listę krótką. Każdy relay na niej to relay, który widzi, kto Ci pisze.
„Jeden konkretny kontakt nigdy nie dostaje tego, co wysyłam”
Jeśli wszyscy inni Cię słyszą, a jedna osoba nie, problem jest po jej stronie, nie w Twoim szyfrowaniu. Jej klient prawie na pewno nie obsługuje NIP-17, więc nigdy nie subskrybuje gift wrapów i nigdy nie widzi Twojej wiadomości. Nic nie wyświetla się jako bełkot, bo nic się nie wyświetla w ogóle.
Naprawa: poproś ją o przejście na klienta z Kroku 1. Jeśli nie może, a rozmawiać da wam się tylko po staremu, na NIP-04, przeczytaj najpierw ostrzeżenie w Najlepszych Praktykach Bezpieczeństwa: NIP-04 wręcza wasze oba klucze publiczne każdemu relayowi, jawnie.
”Nie widzę, czy ktoś przeczytał moją wiadomość NIP-17”
Przyczyna: Potwierdzenia przeczytania nie są jeszcze standaryzowane dla NIP-17 Rozwiązanie: To oczekiwane zachowanie. NIP-17 priorytetyzuje prywatność nad potwierdzeniem dostarczenia.
”Wiadomości pojawiają się poza kolejnością”
Przyczyna: Różnica czasu między urządzeniami Rozwiązanie: Upewnij się, że czas Twojego urządzenia jest zsynchronizowany (włącz automatyczną synchronizację czasu)
“Relay odrzuca eventy NIP-17”
Przyczyna: relay chodzi na starym oprogramowaniu albo po prostu odmawia przechowywania eventów kind 1059 Rozwiązanie: wymień go na inny na swojej liście relayów DM. Część klientów pokazuje na ekranie relaya, co on obsługuje; jeśli Twój tego nie robi, spróbowanie innego relaya i sprawdzenie, czy wiadomości zaczną przychodzić, pójdzie szybciej niż dochodzenie. Powiadomienie operatora też jest warte minuty.
„Mój klient daje mi wybór typu wiadomości”
Zachowanie oczekiwane: część klientów wciąż czyta i pisze oba formaty, dopóki sieć nie skończy się przenosić, i pozwala wybierać osobno dla każdej rozmowy. Wybieraj NIP-17, kiedy tylko jest w ofercie.
Przyszłość Prywatnych Wiadomości w Nostr
NIP-17 jest obecnym standardem prywatnych wiadomości jeden na jeden w Nostr i to jego powinieneś dziś używać. Nie jest jednak końcem drogi, a jego dwie prawdziwe luki to dokładnie te, nad którymi ludzie pracują: brak forward secrecy i brak porządnych rozmów grupowych.
Najpoważniejszą jak dotąd odpowiedzią jest protokół Marmot, który kładzie MLS (standard rozmów grupowych stojący za czatami grupowymi w stylu Signala) na Nostrze, zachowując klucze Nostr jako tożsamość. Repozytorium Marmota podaje specyfikację jako przyjętą, a White Noise to zbudowana na niej aplikacja do czatu. To podejście faktycznie daje forward secrecy i faktycznie ogarnia grupy, czyli dokładnie to, czego NIP-17 nie robi.
Jedno wyjaśnienie, bo same numery aż o nie proszą. NIP-44 nie jest konkurentem NIP-17 i go nie zastąpi. NIP-44 to szyfrowanie, którego NIP-17 już używa w obu swoich warstwach. To części tej samej rzeczy.
Podsumowanie
NIP-17 to realna poprawa względem NIP-04 i to jego powinieneś używać. Miej tylko jasność, co dostajesz. Twoje słowa są zaszyfrowane, a relay nie potrafi powiedzieć, kto wysłał wiadomość. Wciąż widzi natomiast, na które konto ona idzie, a ktoś obserwujący oba końce nadal wyczyta sporo z samych czasów. Traktuj to jak prywatną korespondencję, a nie jak przesyłkę nie do wyśledzenia.
Przeprowadzka to głównie kwestia wybrania właściwego klienta i opublikowania jednej małej listy. Wsparcie jest realne, ale nierówne, a Damus, jeden z najczęściej używanych klientów na iPhonie, wciąż go nie ma, więc sprawdzenie drugiego końca rozmowy nie jest krokiem opcjonalnym.
Zadania do wykonania:
- ✅ Używaj klienta, który obsługuje NIP-17 (Amethyst, 0xchat, Coracle, Snort)
- ✅ Opublikuj swoją listę relayów DM (kind 10050), bo bez niej nic nie dociera
- ✅ Wyślij z kontaktem wiadomość testową w obie strony, żeby wiedzieć, że dostarczanie działa
- ✅ Przed czymkolwiek wrażliwym sprawdź, na jakim kliencie jest druga osoba
Pamiętaj: prywatność to praktyka, nie produkt. NIP-17 daje Ci narzędzia, dobre ich użycie nadal zależy od Ciebie.
Przetestuj Swoją Wiedzę o NIP-17
Gotowy sprawdzić swoje zrozumienie bezpiecznych wiadomości?
Cel NIP-17
0/5 odpowiedziano
Ostatnia aktualizacja: 2 września 2026
Masz pytania? Dołącz do dyskusji na Nostr lub otwórz issue w tym repozytorium dokumentacji.
Czytaj dalej
- Prywatność i Bezpieczeństwo: Dogłębna Analiza. Szerszy model zagrożeń, w którym te wiadomości siedzą.
- Twoje Klucze, Twoja Tożsamość. Utrata klucza to utrata rozmowy, bezpowrotnie.