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.

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 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