docker – InforSupports

Por qué Nostr

Nostr es un protocolo descentralizado de comunicación: en lugar de depender de un servidor central que controla quién publica y quién no, cualquiera puede correr su propio relay, un nodo que almacena y retransmite mensajes firmados criptográficamente. Quería entender el protocolo desde dentro, no solo leyendo sobre él, así que decidí montar mi propio relay en el homelab.

Primer intento: la imagen oficial

Empecé probando con un docker compose up directo, esperando que la imagen pre-construida funcionara sin más. No fue tan simple. Después de varios intentos de ajustar el config.toml y recrear el contenedor, terminé optando por compilar el proyecto desde el código fuente:

git clone https://github.com/scsibug/nostr-rs-relay.git
cd nostr-rs-relay
docker build -t nostr-rs-relay .

git clone https://github.com/scsibug/nostr-rs-relay.git
cd nostr-rs-relay
docker build -t nostr-rs-relay .

Compilar desde fuente me dio más control sobre la configuración y el Dockerfile, a costa de un par de horas extra de prueba y error con el archivo de configuración y el build.

El docker-compose.yml final

Después de resolver el build, el archivo de composición quedó simple, montando la configuración y la base de datos SQLite como volúmenes:

services:
  nostr:
    image: nostr-rs-relay:latest
    container_name: nostr
    command: ["./nostr-rs-relay", "--config", "/etc/nostr-rs-relay/config.toml"]
    volumes:
      - ./config.toml:/etc/nostr-rs-relay/config.toml
      - ./nostr.db:/app/nostr.db
    ports:
      - "8080:8080"
    restart: unless-stopped

services:
  nostr:
    image: nostr-rs-relay:latest
    container_name: nostr
    command: ["./nostr-rs-relay", "--config", "/etc/nostr-rs-relay/config.toml"]
    volumes:
      - ./config.toml:/etc/nostr-rs-relay/config.toml
      - ./nostr.db:/app/nostr.db
    ports:
      - "8080:8080"
    restart: unless-stopped

El relay guarda los eventos en una base de datos SQLite local (nostr.db), y la configuración del relay (nombre, descripción, límites) vive en config.toml, montado como volumen externo para poder editarlo sin reconstruir la imagen.

Publicando el relay sin abrir puertos

Como con el resto de mis servicios, no quería abrir puertos en el router. Usé Cloudflare Tunnel, dedicado exclusivamente a este servicio:

cloudflared tunnel create nostr-relay
cloudflared tunnel route dns nostr-relay relay.inforsupports.com

cloudflared tunnel create nostr-relay
cloudflared tunnel route dns nostr-relay relay.inforsupports.com

Esto deja el relay accesible desde internet en wss://relay.inforsupports.com, sin exponer la IP del homelab ni el puerto 8080 directamente.

Verificando que funciona de verdad

No basta con que el contenedor corra, hay que confirmar que el relay realmente responde al protocolo y que otros nodos lo pueden descubrir. Un par de comandos útiles:

curl -H "Accept: application/nostr+json" https://relay.inforsupports.com

curl -H "Accept: application/nostr+json" https://relay.inforsupports.com

Esto debe devolver la información del relay en formato NIP-11. También revisé que apareciera listado en directorios públicos como nostr.watch, lo cual confirma que el relay es visible y alcanzable desde la red Nostr en general.

Lo que me llevo de este experimento

Más allá del protocolo en sí, este ejercicio fue un recordatorio de algo que aplica a cualquier infraestructura: lo que importa no es que algo «encienda», sino poder verificar que funciona correctamente desde afuera. Entre compilar desde fuente, depurar el config.toml y confirmar la visibilidad pública, el camino tuvo más curvas de las que esperaba, pero terminó siendo una buena forma de aprender el protocolo de punta a punta.

Si tienes un cliente Nostr y quieres probarlo, el relay sigue activo en wss://relay.inforsupports.com.

Etiqueta: docker