Migrer depuis strfry

En un coup d'œil

nostrfy migrate-strfry lit le format d’export propre de strfry (JSONL, un événement NIP-01 par ligne), et fonctionne donc avec différentes versions de la base strfry sans dépendre du schéma LMDB interne de strfry. Il n’écrit jamais dans la base strfry.

Ignorés attendus dans le résumé : événements éphémères (kinds 20000-29999, que nostrfy ne stocke jamais) et événements déjà expirés.

Démarrage rapide

# 1. Arrêtez le relais nostrfy (la migration nécessite le répertoire de la base)
nostrfy --config /etc/nostrfy/nostrfy.toml stop

# 2. dry-run — vérifie chaque événement sans rien écrire
nostrfy --config /etc/nostrfy/nostrfy.toml migrate-strfry \
    --strfry-db /var/lib/strfry-db --dry-run

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

# 4. démarrez — les groupes NIP-29 et les rôles NIP-43 sont reconstruits depuis les événements importés
nostrfy --config /etc/nostrfy/nostrfy.toml start

Prérequis

• Le binaire strfry (pour --strfry-db), ou un fichier JSONL exporté vous-même.
• nostrfy v0.1.15 ou plus récent (sous-commande migrate-strfry).
• La config nostrfy du relais cible, avec database.path, public_url et private_key définis.
• Espace disque libre : environ la taille de l’export strfry plus ses index. L’index de mots NIP-50 ajoute un peu ; sur disque très juste vous pouvez le désactiver (database.search_index = false), migrer, puis le réactiver (l’index est reconstruit au démarrage).
• Aucune instance nostrfy en cours sur le database.path cible.

Préparer la config

[relay]
name = "My Relay"
public_url = "wss://relay.example.com"   # requis pour NIP-42/62/98 et les métadonnées NIP-29
private_key = "..."                       # requis pour les métadonnées NIP-29/43 signées par le relais

[server]
host = "0.0.0.0"
port = 8080

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

Générez la clé du relais avec nostrfy genkey si vous n’en avez pas, puis validez :

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

Fusionner les réglages strfry (optionnel)

Avant d’ouvrir la base, migrate-strfry cherche la config de strfry (--strfry-config, puis $STRFRY_CONFIG, /etc/strfry.conf, ./strfry.conf), affiche les réglages qui ont un équivalent nostrfy et diffèrent de votre nostrfy.toml, et demande s’il faut les fusionner. Seules les clés listées sont réécrites — commentaires et toutes autres lignes préservés, et une valeur qui rendrait la config invalide est ignorée avec son motif pendant que le reste fusionne.

• --merge-config applique sans demander (pour scripts) ; --no-merge-config saute l’étape.
• Sans terminal, les propositions sont affichées et la fusion est sautée sauf si --merge-config est donné.
• --dry-run affiche les propositions mais n’écrit jamais.

Essai à blanc

Regardez avant de sauter — un essai à blanc analyse et vérifie tout l’export sans toucher la base :

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

Un compteur bad signature non nul signifie que l’export contient des événements acceptés par strfry sans vérification ; ils seront ignorés. Si vous leur faites confiance, passez --no-verify pour les importer quand même.

Un compteur bad delegation non nul signifie que l’export contient des événements NIP-26 dont le jeton de délégation ne se vérifie pas. Le relais indexe aussi un événement délégué sous la pubkey du délégant, donc stocker un jeton forgé le publierait dans le fil d’un autre auteur — ces événements sont toujours ignorés (même avec --no-verify, qui ne relâche que la vérification de signature de l’événement).

Migrer

Choisissez un des trois modes d’entrée — tous produisent le même résultat :

# Option A — nostrfy exécute `strfry export` lui-même (strfry dans le PATH)
nostrfy migrate-strfry --strfry-db /var/lib/strfry-db

# Option B — vous avez exporté vers un fichier
strfry export > /tmp/strfry-export.jsonl
nostrfy migrate-strfry --input /tmp/strfry-export.jsonl

# Option C — pipe (stdin est l’entrée par défaut)
strfry export | nostrfy migrate-strfry

La migration est sûre à relancer : les doublons sont ignorés et les effets de suppression sont réappliqués, donc une exécution interrompue peut simplement être répétée (ou reprise avec --since).

Démarrer et vérifier

Le premier démarrage reconstruit le store de groupes NIP-29 et le store de rôles NIP-43 depuis les événements importés et republie les métadonnées signées par le relais (39000/39001/39002/39005 par groupe, la liste de membres 13534). Sur une grosse base cela peut prendre un moment ; surveillez le log.

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

nak relay "$R"                              # le relais répond et annonce ses NIP
curl -s "$H/api/v1/query?limit=1"           # les événements sont servis
nak req -i <deleted-event-id> "$R"          # un événement supprimé reste supprimé
nak req -k 39000 "$R"                       # métadonnées de groupe NIP-29 (si migrées)
nak req --auth --force-pre-auth --sec <nsec> -k 13534 "$R"   # appartenance NIP-43 (AUTH)

Pour une comparaison exacte, strfry scan '{}' | wc -l moins les événements éphémères/expirés signalés par le résumé devrait égaler ce que les clients peuvent récupérer.

Reprendre une migration interrompue

• Exporté vers fichier / pipé : relancez la même commande. Les doublons sont ignorés et les blocs de suppression sont réappliqués.
• Utilisé --strfry-db : le résumé affiche une astuce de reprise ; relancez avec ce --since (inclusif, la seconde frontière est réimportée et dédupliquée).
• Si l’exécution a échoué avec database writer unavailable, vérifiez l’espace libre et database.map_size, puis relancez.

Retour en arrière

La migration n’écrit que dans la base nostrfy. Pour revenir en arrière, arrêtez le relais et restaurez la base pré-migration ou supprimez-la :

nostrfy --config /etc/nostrfy/nostrfy.toml stop
rm -rf /var/lib/nostrfy            # ou restaurez la sauvegarde pré-migration

Dépannage

Liste de contrôle

• Relais nostrfy arrêté
• Base strfry et config nostrfy sauvegardées
• nostrfy check passe
• Réglages strfry fusionnés (ou rapport relu)
• Essai à blanc relu (pas de bad signatures ni de délégations inattendues)
• Migration terminée sans erreurs
• Relais démarré ; reconstruction groupes/rôles journalisée
• Comptes d’événements concordent (moins éphémères/expirés)
• Événements supprimés restent partis (republication rejetée)
• Visibilité des groupes privés vérifiée anonymement et comme membre
• Reverse proxy / DNS / listes de relais clients mis à jour