Migrer depuis strfry

Déplacez les événements d’un relais strfry existant vers nostrfy en une commande — préparation, essai à blanc, migration, vérification et retour en arrière.

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.

MigréNon migré
Chaque événement stocké (sémantique remplaçable/adressable appliquée)Réglages strfry sans équivalent nostrfy (le rapport de fusion liste chacun avec un motif)
Expiration NIP-40 — les événements déjà expirés sont ignorésMédias Blossom et mappings de propriétaires (strfry n’a pas de serveur Blossom)
Suppressions NIP-09, y compris blocs de republication pour événements déjà supprimés par strfryListes d’accès (bans NIP-86, listes de pubkeys du relais, allowlist Blossom)
Effets de modération NIP-29 9005/9008Codes d’invitation NIP-43 (émettez-en de nouveaux avec createclaim)
Horodatages first-seen (quand le filtre nouvelles pubkeys est configuré)Requêtes vanish NIP-62 sauf si --apply-vanish est donné
Groupes NIP-29, rôles NIP-43 et leurs métadonnées signées par le relais, reconstruits au premier démarrageIdentité/clés propres du relais (elles vivent dans nostrfy.toml)
Les réglages strfry équivalents, proposés pour fusion dans nostrfy.toml (optionnel)

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

sh
# 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
La migration est hors ligne
Elle écrit directement dans database.path et refuse de tourner tant qu’un démon nostrfy (ou une autre migration) tient le répertoire de base. Arrêtez d’abord le relais. strfry lui-même peut rester lancé — strfry export lit un snapshot cohérent.

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

toml
[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 :

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

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

Migrer

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

sh
# 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
OptionPourquoi
--strfry-bin <PATH>strfry n’est pas dans PATH
--since <UNIX>Reprise/rattrapage : événements avec ce created_at ou plus récents (inclus)
--apply-vanishHonorer les requêtes vanish NIP-62 trouvées dans l’export (désactivé par défaut)
--no-verifyIgnorer la vérification de signature pour dumps de confiance (plus rapide)
--batch <N>Événements par transaction base (défaut 512)
--dry-runAnalyser et vérifier seulement

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.

sh
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

Ne démarrez pas le relais avant de relancer
Les effets de groupe NIP-29 (9005/9008) sont appliqués après l’import ; une exécution interrompue a stocké ces événements mais pas encore leurs suppressions, donc le premier démarrage pourrait servir l’historique que la suppression devait retirer. Relancez d’abord la migration — elle complète les effets (la purge est idempotente) — puis démarrez le relais.
  • 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 :

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

Dépannage

MessageCause / correction
cannot lock the database directory ...; stop the relay before migratingUn démon nostrfy (ou une autre migration) tient le répertoire : nostrfy stop d’abord
strfry database directory ... does not exist--strfry-db doit nommer le répertoire contenant data.mdb
cannot run 'strfry': ...Installez strfry, définissez --strfry-bin, ou utilisez --input
database writer unavailable; the migration did not completeLe thread d’écriture s’est arrêté ou la file est surchargée : vérifiez disque/taille map, relancez (sûr)
group purge for <id> did not completeLa purge a été interrompue : relancez la migration
Compteur bad signature élevéLa BD strfry contient des événements non vérifiés : inspectez-les ; importez avec --no-verify seulement si vous faites confiance à la source
Métadonnées NIP-29 manquantes après démarragePas de relay.private_key : lancez nostrfy genkey et redémarrez
La fusion des réglages n’est pas proposéeConfig strfry introuvable : passez --strfry-config /etc/strfry.conf

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 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
strfry tourne encore ?
Si strfry est resté live pendant l’export, faites une passe de rattrapage quand vous êtes prêt à basculer : arrêtez nostrfy, relancez la migration avec --since <last created_at>, puis redémarrez.