// dokumentacja openclaw

Integracja OpenClaw z Nostr — zdecentralizowana komunikacja

Wprowadzenie

Nostr to opcjonalna, wbudowana wtyczka OpenClaw umożliwiająca odbiór i odpowiadanie na szyfrowane wiadomości bezpośrednie za pośrednictwem protokołu NIP-04 w zdecentralizowanej sieci Nostr. Dzięki tej integracji Twój agent AI może komunikować się przez w pełni zdecentralizowaną infrastrukturę.

Instalacja

Wtyczka jest dołączona do standardowych wydań. Dla niestandardowych buildów:

openclaw plugins install @openclaw/nostr

Generowanie kluczy

Potrzebujesz pary kluczy Nostr. Wygeneruj je narzędziem nak:

nak key generate

Akceptowane formaty kluczy: nsec... (bech32) i 64-znakowy hex. Klucze publiczne obsługują format npub... (bech32) i hex.

Konfiguracja

Podstawowa konfiguracja obejmuje trzy kroki:

  1. Wygeneruj parę kluczy (jeśli jeszcze nie masz)
  2. Dodaj klucz prywatny do konfiguracji
  3. Zrestartuj Gateway
{
  channels: {
    nostr: {
      privateKey: "nsec1...",
      relays: ["wss://relay.damus.io", "wss://nos.lol"],
      dmPolicy: "pairing",
      allowFrom: []
    }
  }
}

Eksport klucza jako zmienna środowiskowa jest również obsługiwany.

Konfiguracja relay

Domyślne relay to relay.damus.io i nos.lol. Zalecamy 2-3 relay dla redundancji. Płatne relay mogą poprawić niezawodność. Duplikaty odpowiedzi między wieloma relay są oczekiwane i deduplikowane po ID zdarzenia.

Profil (metadane)

Dane profilowe publikowane są jako zdarzenie NIP-01 kind:0. Konfigurowalne pola:

  • name — nazwa użytkownika
  • display_name — nazwa wyświetlana
  • about — biografia
  • picture — URL awatara (wymaga HTTPS)
  • banner — baner profilowy
  • website — strona internetowa
  • nip05 — identyfikator kontaktowy

Kontrola dostępu

Cztery tryby polityki DM:

  • pairing — nieznani nadawcy otrzymują kody weryfikacyjne
  • allowlist — ograniczone do wskazanych kluczy publicznych
  • open — publiczny odbiór (wymaga wildcard w allowFrom)
  • disabled — ignoruje przychodzące wiadomości

Podpisy zdarzeń przychodzących są weryfikowane przed sprawdzeniem polityki nadawcy, co zapewnia wczesne odrzucanie sfałszowanych wiadomości.

Obsługiwane protokoły

  • NIP-01 (obsługiwany) — podstawowe zdarzenia i profile
  • NIP-04 (obsługiwany) — szyfrowane wiadomości bezpośrednie
  • NIP-17 (planowany) — wiadomości w kopertach (gift-wrapped)
  • NIP-44 (planowany) — ulepszone szyfrowanie

Testowanie lokalne

Do testów lokalnych użyj relay strfry hostowanego w Dockerze. Testowanie ręczne polega na pobraniu klucza publicznego bota z logów, a następnie wysłaniu wiadomości przez standardowego klienta Nostr.

Bezpieczeństwo

  • Klucze prywatne nigdy nie powinny trafiać do systemu kontroli wersji
  • Zmienne środowiskowe chronią sekrety
  • W środowisku produkcyjnym używaj polityki allowlist
  • Architektura waliduje podpisy przed przetwarzaniem, uniemożliwiając nieautoryzowanym nadawcom wymuszenie operacji kryptograficznych

Rozwiązywanie problemów

  • Nieprawidłowe klucze — sprawdź format (nsec/hex) i poprawność klucza
  • Nieosiągalne relay — zweryfikuj adresy WebSocket i połączenie sieciowe
  • Limitowanie relay — niektóre relay mogą limitować częstotliwość; dodaj więcej relay dla redundancji
  • Brak odpowiedzi — sprawdź politykę DM, listę dozwolonych i logi Gateway
Wróc do dokumentacji