Developer and self-hosted
Nostr
Nostr es un plugin de canal descargable (@openclaw/nostr) que permite a OpenClaw recibir y responder mensajes directos cifrados con NIP-04 a través de relés de Nostr. Una cuenta por Gateway; solo mensajes directos.
Instalación
openclaw plugins install @openclaw/nostrUse la especificación de paquete sin versión para seguir la etiqueta de la versión oficial actual. Fije una versión exacta solo cuando necesite una instalación reproducible.
Desde un repositorio local (flujos de desarrollo):
openclaw plugins install --link <path-to-local-nostr-plugin>Reinicie el Gateway después de instalar o habilitar plugins. La incorporación (openclaw onboard) y openclaw channels add muestran Nostr desde el catálogo de canales compartido una vez instalado el plugin.
Configuración no interactiva
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"Use --use-env para mantener NOSTR_PRIVATE_KEY en el entorno en lugar de almacenar la clave en la configuración (solo para la cuenta predeterminada).
Configuración rápida
- Genere un par de claves de Nostr (si es necesario):
# Con naknak key generate- Añádalo a la configuración:
{ channels: { nostr: { privateKey: "${NOSTR_PRIVATE_KEY}", }, },}- Exporte la clave:
export NOSTR_PRIVATE_KEY="nsec1..."- Reinicie el Gateway.
Referencia de configuración
| Clave | Tipo | Valor predeterminado | Descripción |
|---|---|---|---|
privateKey |
string | obligatorio | Clave privada en formato nsec o hexadecimal; admite refs de secretos |
relays |
string[] | ['wss://relay.damus.io', 'wss://nos.lol'] |
URL de relés (WebSocket) |
dmPolicy |
string | pairing |
Política de acceso a mensajes directos |
allowFrom |
string[] | [] |
Claves públicas de remitentes permitidos |
enabled |
boolean | true |
Habilitar o deshabilitar el canal |
name |
string | - | Nombre para mostrar |
profile |
object | - | Metadatos de perfil NIP-01 |
Metadatos del perfil
Los datos del perfil se publican como un evento NIP-01 kind:0. Puede administrarlos desde la interfaz de control (Channels -> Nostr -> Profile) o establecerlos directamente en la configuración.
Ejemplo:
{ channels: { nostr: { privateKey: "${NOSTR_PRIVATE_KEY}", profile: { name: "openclaw", displayName: "OpenClaw", about: "Bot de asistente personal por mensaje directo", picture: "https://example.com/avatar.png", banner: "https://example.com/banner.png", website: "https://example.com", nip05: "openclaw@example.com", lud16: "openclaw@example.com", }, }, },}Notas:
- Las URL de perfil deben usar
https://. - Al importar desde relés, se combinan los campos y se conservan las modificaciones locales.
Control de acceso
Políticas de mensajes directos
- emparejamiento (predeterminado): los remitentes desconocidos reciben un código de emparejamiento.
- lista de permitidos: solo las claves públicas de
allowFrompueden enviar mensajes directos. - abierto: mensajes directos entrantes públicos (requiere
allowFrom: ["*"]). - deshabilitado: ignora los mensajes directos entrantes.
Notas sobre la aplicación:
- Las firmas de los eventos entrantes se verifican antes de aplicar la política del remitente y descifrar mediante NIP-04, por lo que los eventos falsificados se rechazan de forma temprana.
- Las respuestas de emparejamiento se envían sin descifrar ni procesar el contenido del mensaje directo original.
- Los mensajes directos entrantes tienen límites de frecuencia (globales y por remitente), y las cargas que exceden el tamaño permitido se descartan antes de descifrarlas.
Ejemplo de lista de permitidos
{ channels: { nostr: { privateKey: "${NOSTR_PRIVATE_KEY}", dmPolicy: "allowlist", allowFrom: ["npub1abc...", "npub1xyz..."], }, },}Formatos de claves
Formatos aceptados:
- Clave privada:
nsec...o hexadecimal de 64 caracteres - Claves públicas (
allowFrom):npub...o hexadecimal
Relés
Valores predeterminados: relay.damus.io y nos.lol.
{ channels: { nostr: { privateKey: "${NOSTR_PRIVATE_KEY}", relays: ["wss://relay.damus.io", "wss://relay.primal.net", "wss://nostr.wine"], }, },}Consejos:
- Use entre 2 y 3 relés para disponer de redundancia.
- Evite usar demasiados relés (latencia y duplicación).
- Los relés de pago pueden mejorar la fiabilidad.
- Los relés locales son adecuados para las pruebas (
ws://localhost:7777).
Compatibilidad con protocolos
| NIP | Estado | Descripción |
|---|---|---|
| NIP-01 | Compatible | Formato básico de eventos y metadatos de perfil |
| NIP-04 | Compatible | Mensajes directos cifrados (kind:4) |
| NIP-17 | Planificado | Mensajes directos envueltos como obsequio |
| NIP-44 | Planificado | Cifrado con versiones |
Pruebas
Relé local
# Iniciar strfrydocker run -p 7777:7777 ghcr.io/hoytech/strfry{ channels: { nostr: { privateKey: "${NOSTR_PRIVATE_KEY}", relays: ["ws://localhost:7777"], }, },}Prueba manual
- Anote la clave pública del bot desde los registros del Gateway o mediante
openclaw channels status(en hexadecimal; conviértala a npub en su cliente si es necesario). - Abra un cliente de Nostr (Amethyst, Damus, etc.).
- Envíe un mensaje directo a la clave pública del bot.
- Verifique la respuesta.
Solución de problemas
No se reciben mensajes
- Verifique que la clave privada sea válida.
- Asegúrese de que las URL de los relés sean accesibles y usen
wss://(ows://para conexiones locales). - Confirme que
enabledno seafalse. - Revise los registros del Gateway para detectar errores de conexión con los relés.
No se envían respuestas
- Compruebe que el relé acepte escrituras.
- Verifique la conectividad saliente.
- Compruebe si existen límites de frecuencia del relé.
Respuestas duplicadas
- Es lo esperado cuando se utilizan varios relés.
- Los mensajes se desduplican mediante el identificador del evento; solo la primera entrega activa una respuesta.
Seguridad
- Nunca confirme claves privadas en el repositorio.
- Use variables de entorno para las claves.
- Considere usar
allowlistpara bots de producción. - Las firmas se verifican antes de aplicar la política del remitente, y esta se aplica antes del descifrado; por ello, los eventos falsificados se rechazan de forma temprana y los remitentes desconocidos no pueden forzar la ejecución completa de operaciones criptográficas.
Limitaciones (producto mínimo viable)
- Solo mensajes directos (sin chats de grupo).
- Sin archivos multimedia adjuntos.
- Solo NIP-04 (se ha planificado el envoltorio de obsequio de NIP-17).
Contenido relacionado
- Resumen de canales — todos los canales compatibles
- Emparejamiento — autenticación de mensajes directos y flujo de emparejamiento
- Grupos — comportamiento de los chats de grupo y control mediante menciones
- Enrutamiento de canales — enrutamiento de sesiones para mensajes
- Seguridad — modelo de acceso y refuerzo de la seguridad