La réversibilité et l'export

Cet onglet sert à récupérer votre patrimoine : catalogue, exemplaires, toutes les versions des passeports, preuves et fichiers médias. L'archive est préparée en arrière-plan, parce qu'elle peut peser plusieurs gigaoctets. Le tableau des exports récents montre l'avancement, et un lien de téléchargement apparaît quand l'archive est prête.

#Ce que l'écran affiche

• Un titre « Partir avec tout » et un paragraphe qui rappelle que ces données vous appartiennent, qu'elles sont livrées dans des formats ouverts, et qu'elles embarquent les preuves permettant de revérifier sans SealTrust.
• Une carte « Export complet » qui décrit le contenu de l'archive, annonce un lien de téléchargement privé valable 15 minutes, et une archive supprimée au bout de 7 jours.
• Un tableau « Exports récents » à cinq colonnes : le numéro, « Statut », « Exemplaires / passeports / médias », « Taille », et la colonne d'action.
• Le statut brut de chaque export, en vert pour completed et en rouge pour failed, avec le message d'erreur juste en dessous quand il y en a un.
• Le nombre de médias manquants entre parenthèses, en ambre, quand il y en a.
• La taille formatée en B, KB, MB ou GB.
• Quand rien n'a encore été demandé : « Aucun export demandé pour l'instant. »

#Ce que vous pouvez y faire

• Demander une archive avec « Demander un export complet ». La demande embarque toujours les fichiers médias.
• Actualiser la liste à la main avec « Actualiser ». Tant qu'un export est en attente ou en cours, la liste se recharge d'elle-même toutes les 10 secondes.
• Télécharger une archive terminée avec « Télécharger », qui ouvre un lien signé dans un nouvel onglet.

La demande d'une archive et chaque lien de téléchargement remis laissent une ligne dans le journal d'audit : le compte, la date, l'adresse IP et la marque. Cette trace ne bloque jamais l'export : récupérer votre patrimoine est un droit, et le fichier vous est servi même si la ligne ne peut pas être écrite.

#Ce qui conditionne l'accès

• L'onglet « Réversibilité » est visible pour tous les profils, sans condition d'offre.
• La carte de demande et le tableau ne sont rendus que si une marque est choisie dans la barre du haut. Un export porte toujours sur une seule marque, celle de cette barre.
• Le bouton de téléchargement n'apparaît que sur une ligne téléchargeable, c'est-à-dire terminée et dotée d'un fichier.
• Le lien de téléchargement est signé et valable 900 secondes. Passé ce délai, revenez sur l'écran et redemandez-le.
• L'historique affiche au maximum les 20 exports les plus récents, du plus récent au plus ancien.
• Le contrôle de périmètre du téléchargement porte sur la marque de l'export lui-même.

#Ce que l'écran refuse

• Aucune marque choisie dans la barre du haut : un bloc invite à en choisir une, et ni le bouton de demande ni le tableau ne s'affichent.
• Un export déjà en attente ou en cours pour la même marque : « An export is already {status} for this brand (id ...) ». Attendez qu'il se termine avant d'en redemander un.
• File d'attente indisponible : « Export queue unavailable. » La ligne est alors marquée failed.
• Téléchargement d'un export qui n'est pas terminé : « Export is {status}. »
• Export inexistant : « Export introuvable. »
• Marque hors du périmètre du compte : « Marque introuvable. », le même message que pour une marque qui n'existe pas.

#Ce que contient l'archive, et comment la revérifier sans nous

L'archive est un fichier ZIP. Elle porte un README.md qui reprend ce qui suit, pour qu'il reste lisible même si vous l'ouvrez des années plus tard.

#Le plus simple : lancer le vérificateur livré avec l'archive

L'archive contient verify.py. Il ne demande rien à installer, pas même une bibliothèque de cryptographie : il recalcule tout lui-même. Une archive censée survivre à l'arrêt de notre service ne peut pas dépendre d'un logiciel qu'il faudrait encore pouvoir installer dans dix ans.

python3 verify.py .              depuis le dossier décompressé
python3 verify.py archive.zip    ou directement sur le fichier ZIP
python3 verify.py . --offline    sans interroger la chaîne

Il refait quatre choses : l'empreinte de chaque passeport, son empreinte dans le paquet, la remontée du chemin jusqu'à l'empreinte du paquet, puis la lecture de la transaction d'ancrage pour comparer. Pour cette lecture, il interroge un nœud public de la chaîne que nomme proofs/anchors.json ; l'option --rpc en désigne un autre. Il affiche une ligne par passeport, avec la date qui fait foi, et il sort en erreur si un seul contrôle échoue. S'il n'arrive pas à joindre la chaîne, il le dit et ne se déclare pas vérifié : une archive cohérente avec elle-même ne prouve rien toute seule.

Les explications qui suivent décrivent ce que ce script fait, pour que vous puissiez l'auditer ou écrire le vôtre.

#La preuve d'inclusion, et pourquoi elle est indispensable

Les passeports ne sont pas ancrés un par un. Ils sont regroupés par paquets, et une seule empreinte résumant tout le paquet est inscrite dans le registre public. C'est ce qui rend le coût à peu près identique pour un passeport et pour dix mille.

La conséquence est qu'il ne suffit pas de détenir l'empreinte de votre passeport et l'empreinte inscrite sur la chaîne : il faut aussi le petit chemin de calcul qui relie les deux. Sans lui, vous ne pouvez pas montrer qu'un passeport précis faisait partie du paquet ancré.

Ce chemin est désormais écrit dans l'archive. Pour chaque version ancrée de chaque passeport, proofs/anchors_passports_*.json porte, sous anchored_versions :

• merkle_root, l'empreinte du paquet, celle qui est inscrite sur la chaîne ;
• leaf, l'empreinte de votre passeport dans ce paquet ;
• leaf_index, sa position ;
• proof, le chemin de calcul ;
• tx_hash, la transaction, et block_timestamp, la seule date opposable.

Pour revérifier, donnez leaf et proof à n'importe quel vérificateur Merkle à paires triées, celui de la convention OpenZeppelin, et contrôlez que le résultat est bien merkle_root. Contrôlez ensuite, sur l'explorateur public que nomme proofs/anchors.json (par exemple basescan.org pour Base), que cette empreinte est bien celle que porte la transaction. Aucune adresse de SealTrust n'intervient.

#Un paquet que nous ne savons pas reconstruire est nommé

Si un paquet ne peut pas produire de preuve valable, il n'est pas passé sous silence : il apparaît sous unprovable_batches dans proofs/anchors.json, avec le motif. Une preuve absente et annoncée vaut mieux qu'une preuve fausse, qui ne se découvrirait que le jour où vous en auriez besoin.

#Ce qui survit à SealTrust, exactement

La distinction est importante et nous préférons l'écrire :

• La date est acquise sans condition. Elle est inscrite dans un registre public que personne, nous compris, ne peut retirer.
• Le contenu est à vous de le détenir, et c'est précisément ce que cette archive vous remet.
• La copie IPFS n'est pas une garantie de survie. Ce réseau ne conserve rien de lui-même : un document n'y reste accessible que tant que quelqu'un l'épingle, et aujourd'hui c'est SealTrust. Si vous voulez que cette copie nous survive, épinglez les adresses ipfs_uri de votre côté, chez le prestataire de votre choix.