Migrar desde strfry

De un vistazo

nostrfy migrate-strfry lee el formato de exportación propio de strfry (JSONL, un evento NIP-01 por línea), así funciona entre versiones de base de datos de strfry y no depende del esquema LMDB interno de strfry. Nunca escribe en la base de datos de strfry.

Omitidos esperados en el resumen: eventos efímeros (kinds 20000-29999, que nostrfy nunca almacena) y eventos ya caducados.

Inicio rápido

# 1. detén el relé nostrfy (la migración necesita el directorio de la base)
nostrfy --config /etc/nostrfy/nostrfy.toml stop

# 2. dry-run — analiza y verifica cada evento, no escribe nada
nostrfy --config /etc/nostrfy/nostrfy.toml migrate-strfry \
    --strfry-db /var/lib/strfry-db --dry-run

# 3. importación
nostrfy --config /etc/nostrfy/nostrfy.toml migrate-strfry \
    --strfry-db /var/lib/strfry-db

# 4. arranca — los grupos NIP-29 y los roles NIP-43 se reconstruyen desde los eventos importados
nostrfy --config /etc/nostrfy/nostrfy.toml start

Requisitos

• El binario strfry (para --strfry-db), o un archivo JSONL exportado por ti.
• nostrfy v0.1.15 o superior (subcomando migrate-strfry).
• La config nostrfy del relé destino, con database.path, public_url y private_key definidos.
• Espacio libre: aproximadamente el tamaño del export de strfry más sus índices. El índice de palabras NIP-50 suma algo más; con disco muy justo puedes desactivarlo (database.search_index = false), migrar y reactivarlo después (el índice se reconstruye al arrancar).
• Ninguna instancia nostrfy en ejecución sobre el database.path destino.

Preparar la config

[relay]
name = "My Relay"
public_url = "wss://relay.example.com"   # necesario para NIP-42/62/98 y metadatos NIP-29
private_key = "..."                       # necesario para metadatos NIP-29/43 firmados por el relé

[server]
host = "0.0.0.0"
port = 8080

[database]
path = "/var/lib/nostrfy"
map_size = 1073741824

Genera la clave del relé con nostrfy genkey si no tienes una, luego valida:

nostrfy --config /etc/nostrfy/nostrfy.toml check

Fusionar los ajustes de strfry (opcional)

Antes de abrir la base, migrate-strfry busca la config de strfry (--strfry-config, luego $STRFRY_CONFIG, /etc/strfry.conf, ./strfry.conf), muestra los ajustes que tienen equivalente en nostrfy y difieren de tu nostrfy.toml, y pregunta si fusionarlos. Solo se reescriben las claves listadas — comentarios y demás líneas se preservan, y un valor que invalidaría la config se omite con su motivo mientras el resto sí se fusiona.

• --merge-config aplica sin preguntar (para scripts); --no-merge-config omite el paso.
• Sin terminal, las propuestas se imprimen y la fusión se omite salvo que se dé --merge-config.
• --dry-run muestra las propuestas pero nunca escribe.

Simulacro

Mira antes de saltar — un simulacro analiza y verifica todo el export sin tocar la base:

nostrfy migrate-strfry --strfry-db /var/lib/strfry-db --dry-run

Un conteo bad signature distinto de cero significa que el export contiene eventos que strfry aceptó sin verificación; se omitirán. Si confías en ellos, pasa --no-verify para importarlos igualmente.

Un recuento bad delegation distinto de cero significa que la exportación contiene eventos NIP-26 cuyo token de delegación no se verifica. El relé también indexa un evento delegado bajo la pubkey del delegador, así que almacenar un token falsificado lo publicaría en el feed de otro autor — esos eventos siempre se omiten (incluso con --no-verify, que solo relaja la verificación de firma del evento).

Migrar

Elige uno de tres modos de entrada — todos producen el mismo resultado:

# Opción A — nostrfy ejecuta `strfry export` (strfry en PATH)
nostrfy migrate-strfry --strfry-db /var/lib/strfry-db

# Opción B — exportaste a un archivo
strfry export > /tmp/strfry-export.jsonl
nostrfy migrate-strfry --input /tmp/strfry-export.jsonl

# Opción C — pipe (stdin es la entrada por defecto)
strfry export | nostrfy migrate-strfry

La migración es segura de reejecutar: los duplicados se omiten y los efectos de borrado se reaplican, así una ejecución interrumpida puede simplemente repetirse (o reanudarse con --since).

Iniciar y verificar

El primer arranque reconstruye el almacén de grupos NIP-29 y el almacén de roles NIP-43 desde los eventos importados y republica los metadatos firmados por el relé (39000/39001/39002/39005 por grupo, la lista de miembros 13534). En una base grande puede tardar; observa el log.

R=wss://relay.example.com      # para nak (WebSocket)
H=https://relay.example.com    # para curl (HTTP)

nak relay "$R"                              # el relé responde y anuncia sus NIPs
curl -s "$H/api/v1/query?limit=1"           # los eventos se sirven
nak req -i <deleted-event-id> "$R"          # un evento borrado sigue fuera
nak req -k 39000 "$R"                       # metadatos de grupo NIP-29 (si se migró)
nak req --auth --force-pre-auth --sec <nsec> -k 13534 "$R"   # membresía NIP-43 (AUTH)

Para comparación exacta, strfry scan '{}' | wc -l menos los eventos efímeros/caducados reportados por el resumen debería igualar lo que los clientes pueden recuperar.

Reanudar una migración interrumpida

• Exportado a archivo / por pipe: reejecuta el mismo comando. Los duplicados se omiten y los bloqueos de borrado se reaplican.
• Usaste --strfry-db: el resumen imprime una pista de reanudación; reejecuta con ese --since (inclusivo, el segundo límite se reimporta y deduplica).
• Si falló con database writer unavailable, revisa espacio libre y database.map_size, luego reejecuta.

Reversión

La migración solo escribe en la base nostrfy. Para revertir, detén el relé y restaura la base pre-migración o elimínala:

nostrfy --config /etc/nostrfy/nostrfy.toml stop
rm -rf /var/lib/nostrfy            # o restaura la copia pre-migración

Solución de problemas

Lista de verificación

• Relé nostrfy detenido
• Base strfry y config nostrfy respaldadas
• nostrfy check pasa
• Ajustes strfry fusionados (o informe revisado)
• Simulacro revisado (sin bad signatures ni delegaciones inesperadas)
• Migración completada sin errores
• El relé arranca; reconstrucción de grupos/roles registrada
• Conteos coinciden (menos efímeros/caducados)
• Eventos borrados siguen fuera (republicación rechazada)
• Visibilidad de grupos privados comprobada anónimamente y como miembro
• Proxy inverso, DNS y listas de relés de clientes actualizados