Synchronisation et stockage
La synchronisation a trois parties : le paquet @vaultkeepr/sync fusionne les modifications entre appareils, le paquet @vaultkeepr/ipfs stocke et récupère le chiffré, et le contrat VaultKeeperCidRegistry sur Base L2 enregistre quel chiffré est courant pour une adresse.
Synchronisation CRDT
Section intitulée « Synchronisation CRDT »@vaultkeepr/sync s’appuie sur les CRDT Automerge. Chaque appareil modifie sa copie du document du coffre, et la fusion est sans conflit : deux appareils qui ajoutent ou éditent des entrées convergent vers le même résultat, quel que soit l’ordre de fusion. Les suppressions se propagent par tombstones : une entrée supprimée sur un appareil disparaît sur les autres ; purgeTombstones et countTombstones gèrent le journal. Les coffres dans l’ancien format non-CRDT peuvent être migrés avec migrateLegacyPayload.
La surface d’import binaire du CRDT est fuzzée en CI (fuzz/harness/sync.fuzz.js). Une entrée Automerge malformée doit échouer avec une erreur propre, jamais par un crash.
Stockage IPFS
Section intitulée « Stockage IPFS »Le blob du coffre est chiffré sur le client avant l’envoi, donc IPFS stocke et adresse du chiffré uniquement. @vaultkeepr/ipfs valide et normalise les CID et récupère depuis plusieurs passerelles avec failover :
import { fetchFromIpfs, isIpfsCid, setIpfsGateways } from "@vaultkeepr/ipfs";
setIpfsGateways(["https://ipfs.io", "https://cloudflare-ipfs.com", "https://gateway.pinata.cloud"]);if (isIpfsCid(location)) { const blob = await fetchFromIpfs(location);}Vous pouvez définir votre propre priorité de passerelles. Les passerelles peuvent détenir le chiffré, mais elles ne peuvent pas le lire.
Qui voit quoi
Section intitulée « Qui voit quoi »Les passerelles et les observateurs réseau peuvent voir qu’un blob existe, quand il change et quelle est sa taille, et le récupérer s’ils connaissent le CID. Sans vos clés, ils ne peuvent pas lire les mots de passe ni les notes. Le blob est « public » au sens « accessible si on a le CID » ; il ne l’est pas au sens « contenu en clair exposé ».
Une table de correspondance de l’adresse wallet vers le dernier CID existe pour la commodité, dans le contrat registre et dans les API hébergées. Elle ne révèle pas le contenu du coffre, mais c’est une métadonnée publique ; voir le modèle de menaces pour ce que cela implique.
Publication des mises à jour
Section intitulée « Publication des mises à jour »La sync IPFS suppose un wallet lié et des publications signées. La signature prouve le contrôle de l’adresse ; @vaultkeepr/smart-account écrit le pointeur du coffre dans le registre via le compte intelligent de l’utilisateur. Certains clients permettent un mode uniquement local avant liaison wallet, mais la sync multi-appareils exige le pointeur on-chain signé.