Nostr

​

Plugin in bundle

​

Installazioni precedenti/personalizzate

• L’onboarding (openclaw onboard) e openclaw channels add mostrano ancora Nostr dal catalogo dei canali condiviso.
• Se la tua build esclude Nostr in bundle, installa direttamente il pacchetto npm.

openclaw plugins install @openclaw/nostr

openclaw plugins install --link <path-to-local-nostr-plugin>

​

Configurazione non interattiva

openclaw channels add --channel nostr --private-key "$NOSTR_PRIVATE_KEY"
openclaw channels add --channel nostr --private-key "$NOSTR_PRIVATE_KEY" --relay-urls "wss://relay.damus.io,wss://relay.primal.net"

​

Configurazione rapida

1. Genera una coppia di chiavi Nostr (se necessario):

# Using nak
nak key generate

2. Aggiungi alla configurazione:

{
  channels: {
    nostr: {
      privateKey: "${NOSTR_PRIVATE_KEY}",
    },
  },
}

3. Esporta la chiave:

export NOSTR_PRIVATE_KEY="nsec1..."

4. Riavvia il Gateway.

​

Riferimento della configurazione

​

Metadati del profilo

{
  channels: {
    nostr: {
      privateKey: "${NOSTR_PRIVATE_KEY}",
      profile: {
        name: "openclaw",
        displayName: "OpenClaw",
        about: "Personal assistant DM bot",
        picture: "https://example.com/avatar.png",
        banner: "https://example.com/banner.png",
        website: "https://example.com",
        nip05: "openclaw@example.com",
        lud16: "openclaw@example.com",
      },
    },
  },
}

• Gli URL del profilo devono usare https://.
• L’importazione dai relay unisce i campi e conserva le sovrascritture locali.

​

Controllo degli accessi

​

Criteri DM

• pairing (predefinito): i mittenti sconosciuti ricevono un codice di abbinamento.
• allowlist: solo le pubkey in allowFrom possono inviare DM.
• open: DM in ingresso pubblici (richiede allowFrom: ["*"]).
• disabled: ignora i DM in ingresso.

• Le firme degli eventi in ingresso vengono verificate prima della policy del mittente e della decrittazione NIP-04, quindi gli eventi falsificati vengono rifiutati in anticipo.
• Le risposte di pairing vengono inviate senza elaborare il corpo del DM originale.
• I DM in ingresso sono soggetti a rate limit e i payload sovradimensionati vengono scartati prima della decrittazione.

​

Esempio di allowlist

{
  channels: {
    nostr: {
      privateKey: "${NOSTR_PRIVATE_KEY}",
      dmPolicy: "allowlist",
      allowFrom: ["npub1abc...", "npub1xyz..."],
    },
  },
}

​

Formati delle chiavi

• Chiave privata: nsec... o esadecimale di 64 caratteri
• Chiavi pubbliche (allowFrom): npub... o esadecimale

​

Relay

{
  channels: {
    nostr: {
      privateKey: "${NOSTR_PRIVATE_KEY}",
      relays: ["wss://relay.damus.io", "wss://relay.primal.net", "wss://nostr.wine"],
    },
  },
}

• Usa 2-3 relay per la ridondanza.
• Evita troppi relay (latenza, duplicazione).
• I relay a pagamento possono migliorare l’affidabilità.
• I relay locali vanno bene per i test (ws://localhost:7777).

​

Supporto del protocollo

​

Test

​

Relay locale

# Start strfry
docker run -p 7777:7777 ghcr.io/hoytech/strfry

{
  channels: {
    nostr: {
      privateKey: "${NOSTR_PRIVATE_KEY}",
      relays: ["ws://localhost:7777"],
    },
  },
}

​

Test manuale

1. Prendi nota della chiave pubblica del bot (npub) dai log.
2. Apri un client Nostr (Damus, Amethyst, ecc.).
3. Invia un DM alla chiave pubblica del bot.
4. Verifica la risposta.

​

Risoluzione dei problemi

​

Messaggi non ricevuti

• Verifica che la chiave privata sia valida.
• Assicurati che gli URL dei relay siano raggiungibili e usino wss:// (o ws:// per locale).
• Conferma che enabled non sia false.
• Controlla nei log del Gateway la presenza di errori di connessione ai relay.

​

Risposte non inviate

• Controlla che il relay accetti le scritture.
• Verifica la connettività in uscita.
• Fai attenzione ai rate limit dei relay.

​

Risposte duplicate

• Previsto quando si usano più relay.
• I messaggi vengono deduplicati per ID evento; solo la prima consegna attiva una risposta.

​

Sicurezza

• Non committare mai chiavi private.
• Usa variabili d’ambiente per le chiavi.
• Considera allowlist per i bot di produzione.
• Le firme vengono verificate prima della policy del mittente, e la policy del mittente viene applicata prima della decrittazione, quindi gli eventi falsificati vengono rifiutati in anticipo e i mittenti sconosciuti non possono forzare il lavoro crittografico completo.

​

Limitazioni (MVP)

• Solo messaggi diretti (nessuna chat di gruppo).
• Nessun allegato multimediale.
• Solo NIP-04 (gift-wrap NIP-17 pianificato).

​

Correlati

• Panoramica dei canali — tutti i canali supportati
• Pairing — autenticazione DM e flusso di pairing
• Gruppi — comportamento delle chat di gruppo e gating delle menzioni
• Instradamento dei canali — instradamento delle sessioni per i messaggi
• Sicurezza — modello di accesso e hardening