Migrazione da strfry

A colpo d’occhio

nostrfy migrate-strfry legge il formato di export proprio di strfry (JSONL, un evento NIP-01 per riga), quindi funziona tra versioni del database strfry e non dipende dallo schema LMDB interno di strfry. Non scrive mai nel database strfry.

Skip attesi nel riepilogo: eventi effimeri (kind 20000-29999, che nostrfy non memorizza mai) ed eventi già scaduti.

Avvio rapido

# 1. ferma il relay nostrfy (la migrazione richiede la directory del database)
nostrfy --config /etc/nostrfy/nostrfy.toml stop

# 2. dry-run — analizza e verifica ogni evento, non scrive nulla
nostrfy --config /etc/nostrfy/nostrfy.toml migrate-strfry \
    --strfry-db /var/lib/strfry-db --dry-run

# 3. importazione
nostrfy --config /etc/nostrfy/nostrfy.toml migrate-strfry \
    --strfry-db /var/lib/strfry-db

# 4. avvia — i gruppi NIP-29 e i ruoli NIP-43 vengono ricostruiti dagli eventi importati
nostrfy --config /etc/nostrfy/nostrfy.toml start

Requisiti

• Il binario strfry (per --strfry-db), o un file JSONL esportato da te.
• nostrfy v0.1.15 o superiore (sottocomando migrate-strfry).
• La config nostrfy del relay di destinazione, con database.path, public_url e private_key impostati.
• Spazio libero: circa la dimensione dell’export strfry più i suoi indici. L’indice parole NIP-50 aggiunge altro; su disco molto stretto puoi disabilitarlo (database.search_index = false), migrare e riabilitarlo dopo (l’indice è ricostruito all’avvio).
• Nessuna istanza nostrfy in esecuzione sul database.path di destinazione.

Preparare la config

[relay]
name = "My Relay"
public_url = "wss://relay.example.com"   # necessario per NIP-42/62/98 e i metadati NIP-29
private_key = "..."                       # necessario per i metadati NIP-29/43 firmati dal relay

[server]
host = "0.0.0.0"
port = 8080

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

Genera la chiave del relay con nostrfy genkey se non ne hai una, poi valida:

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

Merge delle impostazioni strfry (opzionale)

Prima di aprire il database, migrate-strfry cerca la config di strfry (--strfry-config, poi $STRFRY_CONFIG, /etc/strfry.conf, ./strfry.conf), stampa le impostazioni che hanno un equivalente nostrfy e differiscono dal tuo nostrfy.toml, e chiede se unirle. Solo le chiavi elencate vengono riscritte — commenti e ogni altra riga preservati, e un valore che renderebbe la config invalida viene saltato con motivo mentre il resto viene unito.

• --merge-config applica senza chiedere (per script); --no-merge-config salta il passo.
• Senza terminale, le proposte sono stampate e il merge è saltato a meno che non venga passato --merge-config.
• --dry-run stampa le proposte ma non scrive mai.

Dry run

Guarda prima di saltare — un dry run analizza e verifica l’intero export senza toccare il database:

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

Un conteggio bad signature diverso da zero significa che l’export contiene eventi accettati da strfry senza verifica; saranno saltati. Se ti fidi, passa --no-verify per importarli comunque.

Un conteggio bad delegation diverso da zero significa che l’export contiene eventi NIP-26 il cui token di delega non verifica. Il relay indicizza un evento delegato anche sotto la pubkey del delegante, quindi memorizzare un token falsificato lo pubblicherebbe nel feed di un altro autore — tali eventi vengono sempre saltati (anche con --no-verify, che allenta solo la verifica della firma dell’evento).

Migrazione

Scegli una delle tre modalità di input — producono tutte lo stesso risultato:

# Opzione A — nostrfy esegue `strfry export` direttamente (strfry in PATH)
nostrfy migrate-strfry --strfry-db /var/lib/strfry-db

# Opzione B — hai già esportato in un file
strfry export > /tmp/strfry-export.jsonl
nostrfy migrate-strfry --input /tmp/strfry-export.jsonl

# Opzione C — pipe (stdin è l'input predefinito)
strfry export | nostrfy migrate-strfry

La migrazione è sicura da rieseguire: i duplicati vengono saltati e gli effetti di cancellazione riapplicati, quindi un’esecuzione interrotta può essere semplicemente ripetuta (o ripresa con --since).

Avvio e verifica

Il primo avvio ricostruisce lo store gruppi NIP-29 e lo store ruoli NIP-43 dagli eventi importati e ripubblica i metadati firmati dal relay (39000/39001/39002/39005 per gruppo, la lista membri 13534). Su un database grande può volerci un momento; guarda il log.

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

nak relay "$R"                              # il relay risponde e annuncia i suoi NIP
curl -s "$H/api/v1/query?limit=1"           # gli eventi vengono serviti
nak req -i <deleted-event-id> "$R"          # un evento eliminato resta eliminato
nak req -k 39000 "$R"                       # metadati dei gruppi NIP-29 (se migrati)
nak req --auth --force-pre-auth --sec <nsec> -k 13534 "$R"   # appartenenza NIP-43 (AUTH)

Per un confronto esatto, strfry scan '{}' | wc -l meno gli eventi effimeri/scaduti riportati dal riepilogo dovrebbe eguagliare ciò che i client possono recuperare.

Riprendere una migrazione interrotta

• Esportato su file / via pipe: riesegui lo stesso comando. I duplicati vengono saltati e i blocchi di cancellazione riapplicati.
• Usato --strfry-db: il riepilogo stampa un suggerimento di ripresa; riesegui con quel --since (inclusivo, il secondo al confine è reimportato e deduplicato).
• Se fallisce con database writer unavailable, controlla spazio libero e database.map_size, poi riesegui.

Rollback

La migrazione scrive solo nel database nostrfy. Per tornare indietro, ferma il relay e ripristina il database pre-migrazione o rimuovilo:

nostrfy --config /etc/nostrfy/nostrfy.toml stop
rm -rf /var/lib/nostrfy            # o ripristina il backup pre-migrazione

Risoluzione dei problemi

Checklist

• Relay nostrfy fermato
• Database strfry e config nostrfy salvati
• nostrfy check passa
• Impostazioni strfry unite (o report revisionato)
• Dry run revisionato (nessuna bad signature o delega inattesa)
• Migrazione completata senza errori
• Relay avviato; rebuild gruppi/ruoli loggato
• Conteggi eventi corrispondono (meno effimeri/scaduti)
• Eventi cancellati restano via (ripubblicazione rifiutata)
• Visibilità gruppi privati verificata anonimamente e come membro
• Reverse proxy / DNS / liste relay client aggiornati