Nostr

Nostr

Statut : Plugin optionnel (désactivé par défaut).

Nostr est un protocole décentralisé pour les réseaux sociaux. Ce canal permet à OpenClaw de recevoir et de répondre aux messages directs (DMs) chiffrés via NIP-04.

Installation (à la demande)

Onboarding (recommandé)

• Onboarding (openclaw onboard) et openclaw channels add listent les plugins de canal optionnels.
• Sélectionner Nostr vous invite à installer le plugin à la demande.

Paramètres d’installation par défaut :

• Canal Dev + git checkout disponible : utilise le chemin du plugin local.
• Stable/Bêta : télécharge depuis npm.

Vous pouvez toujours remplacer le choix dans l’invite.

Installation manuelle

openclaw plugins install @openclaw/nostr

Utiliser un checkout local (flux de travail dev) :

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

Redémarrez la passerelle après avoir installé ou activé les plugins.

Configuration non interactive

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"

Utilisez --use-env pour conserver NOSTR_PRIVATE_KEY dans l’environnement au lieu de stocker la clé dans la configuration.

Configuration rapide

1. Générer une paire de clés Nostr (si nécessaire) :

# Using nak
nak key generate

2. Ajouter à la configuration :

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

3. Exporter la clé :

export NOSTR_PRIVATE_KEY="nsec1..."

4. Redémarrez le Gateway.

Référence de configuration

Clé	Type	Par défaut	Description
privateKey	string	requis	Clé privée au format nsec ou hexadécimal
relays	string[]	['wss://relay.damus.io', 'wss://nos.lol']	URLs de relais (WebSocket)
dmPolicy	string	pairing	Politique d’accès DM
allowFrom	string[]	[]	Clés publiques d’expéditeurs autorisées
enabled	boolean	true	Activer/désactiver le canal
name	string	-	Nom d’affichage
profile	object	-	Métadonnées de profil NIP-01

Métadonnées du profil

Les données du profil sont publiées en tant qu’événement NIP-01 kind:0. Vous pouvez les gérer depuis l’interface de contrôle (Canaux -> Nostr -> Profil) ou les définir directement dans la configuration.

Exemple :

{
  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: "[email protected]",
        lud16: "[email protected]",
      },
    },
  },
}

Notes :

• Les URLs de profil doivent utiliser https://.
• L’importation depuis les relais fusionne les champs et conserve les substitutions locales.

Contrôle d’accès

Politiques DM

• pairing (par défaut) : les expéditeurs inconnus reçoivent un code d’appariement.
• allowlist : seules les clés publiques dans allowFrom peuvent envoyer des DMs.
• open : DMs entrants publics (nécessite allowFrom: ["*"]).
• disabled : ignorer les DMs entrants.

Notes sur l’application :

• La stratégie de l’expéditeur est vérifiée avant la vérification de la signature et le déchiffrement NIP-04.
• Les réponses d’appariement sont envoyées sans traiter le corps du DM d’origine.
• Les DM entrants sont soumis à une limitation de débit et les charges utiles trop volumineuses sont supprimées avant le déchiffrement.

Exemple de liste d’autorisation

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

Formats de clés

Formats acceptés :

• Clé privée : nsec... ou hexadécimal de 64 caractères
• Clés publiques (allowFrom) : npub... ou hexadécimal

Relais

Par défaut : relay.damus.io et nos.lol.

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

Conseils :

• Utilisez 2 à 3 relais pour la redondance.
• Évitez d’utiliser trop de relais (latence, duplication).
• Les relais payants peuvent améliorer la fiabilité.
• Les relais locaux conviennent pour les tests (ws://localhost:7777).

Prise en charge du protocole

NIP	Statut	Description
NIP-01	Pris en charge	Format d’événement de base + métadonnées de profil
NIP-04	Pris en charge	DM chiffrés (kind:4)
NIP-17	Prévu	DM emballés (gift-wrapped)
NIP-44	Prévu	Chiffrement versionné

Tests

Relais local

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

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

Test manuel

1. Notez la clé publique du bot (npub) dans les journaux.
2. Ouvrez un client Nostr (Damus, Amethyst, etc.).
3. Envoyez un DM à la clé publique du bot.
4. Vérifiez la réponse.

Dépannage

Non-réception de messages

• Vérifiez que la clé privée est valide.
• Assurez-vous que les URL des relais sont accessibles et utilisent wss:// (ou ws:// en local).
• Confirmez que enabled n’est pas false.
• Vérifiez les journaux du Gateway pour les erreurs de connexion aux relais.

Absence d’envoi de réponses

• Vérifiez que le relais accepte les écritures.
• Vérifiez la connectivité sortante.
• Surveillez les limites de débit des relais.

Réponses en double

• Attendu lors de l’utilisation de plusieurs relais.
• Les messages sont dédoublonnés par ID d’événement ; seule la première livraison déclenche une réponse.

Sécurité

• Ne commettez jamais de clés privées.
• Utilisez des variables d’environnement pour les clés.
• Envisagez allowlist pour les bots de production.
• La stratégie d’appariement et de liste d’autorisation est appliquée avant le déchiffrement, les expéditeurs inconnus ne peuvent donc pas forcer une charge cryptographique complète.

Limitations (MVP)

• Messages directs uniquement (pas de discussions de groupe).
• Pas de pièces jointes multimédias.
• NIP-04 uniquement (NIP-17 gift-wrap prévu).

Connexes

• Vue d’ensemble des canaux — tous les canaux pris en charge
• Appairage — authentification DM et flux d’appairage
• Groupes — comportement du chat de groupe et filtrage des mentions
• Routage de canal — routage de session pour les messages
• Sécurité — modèle d’accès et durcissement