pkv-sync

PKV Sync vous permet d’exécuter votre propre service de synchronisation pour les coffres-forts Obsidian au lieu de dépendre d’un cloud géré. Il est distribué sous la forme d’un binaire unique qui stocke les métadonnées dans une base de données SQLite et conserve chaque coffre-fort sous la forme d’un dépôt git nu, de sorte qu’aucun cluster, stockage d’objets ou service géré n’est requis. Le README est écrit en anglais et le projet est sous licence AGPL-3.0-only. Fonctionnalités principales décrites dans le README : - Synchronisation multi-utilisateurs, multi-coffres-forts sur des appareils authentifiés, avec des verrous de poussée par coffre-fort et des tentatives idempotentes. - Poussée en temps réel : les petites modifications arrivent en moins d’une seconde via Server-Sent Events, avec un polling conservé en secours. - Git comme source de vérité : chaque coffre-fort est un dépôt git nu, offrant un historique par fichier, un diff unifié et une restauration de fichier unique dans le plugin et le panneau d’administration. - Gestion des conflits : le plugin n’écrase pas silencieusement les modifications locales ; les conflits apparaissent comme des fichiers .conflict-* avec un résolveur en un clic. - Panneau d’administration disponible en cinq langues (anglais, chinois simplifié, chinois traditionnel, japonais, coréen) pour les utilisateurs, les jetons d’appareil, les coffres-forts, les invitations, l’activité et le nettoyage des blobs, avec des boîtes de dialogue de confirmation pour les actions destructives. - Outils de lecture/écriture MCP exposés via stdio, HTTP Streamable autonome ou une route /mcp intégrée sur le processus serveur, destinés aux coffres-forts lisibles par IA. - Paramètres de sécurité par défaut : politique de mot de passe de niveau configuration pour les mots de passe créés par l’administrateur, secrets de jeton à usage unique, limites de taille sur les téléchargements et les réponses MCP, et revalidation des jetons révoqués sur les flux SSE en direct. Déploiement : la voie recommandée est Docker Compose avec Caddy dans deploy/caddy/ terminant HTTPS via Let’s Encrypt, tandis que le serveur écoute sur 127.0.0.1:6710 à l’intérieur du réseau compose. La configuration nécessite un domaine avec des enregistrements A/AAAA et les ports 80 et 443 accessibles. Les étapes incluent la génération d’une clé de déploiement avec la commande genkey, la création de config.toml avec les sections serveur, stockage, réseau et MCP, l’édition du Caddyfile pour votre domaine, l’exécution de docker compose up -d, puis la création du premier administrateur à l’URL /setup et l’installation du fichier zip du plugin dans le dossier .obsidian/plugins/pkv-sync/ du coffre-fort. Les installations natives, le réglage du proxy inverse (Caddy, Nginx, Traefik), la sémantique public_host, la sauvegarde/restauration et le chiffrement du disque sont couverts dans un guide de durcissement du déploiement. Modes MCP : le mode intégré est activé via un drapeau de configuration qui monte /mcp sur le port principal du serveur, partageant la terminaison TLS, le proxy inverse, la clé de déploiement et l’application du jeton bearer ; le mode autonome exécute un processus séparé lié à une adresse choisie, décrit comme utile pour les configurations air-gapped ou l’évolutivité indépendante. Plugin Obsidian : les fichiers locaux restent la source de vérité, et le plugin lit et écrit le coffre-fort normal sur le disque. Les paramètres non sensibles et les index de synchronisation sont stockés dans data.json du plugin à l’intérieur du coffre-fort, tandis que l’état de connexion, le jeton d’appareil bearer actif, la clé de déploiement et l’identité de l’appareil résident dans le stockage local de l’appareil d’Obsidian. Les jetons d’appareil se renouvellent à l’utilisation, expirent après 90 jours d’inactivité et ont une durée de vie absolue de 365 jours ; se reconnecter sur le même appareil fait tourner le jeton actif. Les fonctionnalités quotidiennes incluent une palette de commandes, un historique des fichiers, un diff côte à côte, une résolution des conflits, une synchronisation sélective de .obsidian, une gestion des appareils et une mise à jour automatique, documentées dans un manuel d’utilisation. Statut du chiffrement : le README indique que la version 1.0 n’expédie pas encore de chiffrement de bout en bout natif et que le serveur peut lire le contenu du coffre-fort. Le chiffrement natif par coffre-fort est prévu comme un mode optionnel sur la feuille de route 1.x, car le chiffrement échange des fonctionnalités côté serveur telles que le diff historique, la fusion automatique à trois voies, les charges utiles SSE en ligne et la lecture/écriture MCP. En guise de contournement, git-crypt peut être superposé au coffre-fort de sorte que les chemins marqués atteignent le serveur sous forme de blobs chiffrés, tandis que les noms de fichiers restent en clair sur le serveur ; le clonage git standard et la commande materialize fonctionnent toujours pour les clients possédant la clé. Le README recommande également HTTPS, des trusted_proxies restreints, des disques de données chiffrés et des sauvegardes chiffrées pour les déploiements réels. Versions et statut : le README liste la documentation pour l’utilisation du plugin, l’administration du serveur, la référence CLI, les notes de mise à niveau, le durcissement du déploiement, une spécification OpenAPI, la configuration MCP, un workflow de wiki maintenu par LLM et la migration depuis Obsidian Sync. Chaque version GitHub publie des binaires Linux amd64/arm64, un binaire Windows x64, une image Docker GHCR multi-architecture, le fichier zip du plugin Obsidian et SHA256SUMS. La version 1.5.1 est décrite comme une refonte visuelle du panneau d’administration et du plugin plus une passe d’alignement de la documentation avec un garde de documentation CI ; 1.5.0 couvre une remédiation d’audit et un travail de performance incluant la rétention de blobs liée à la vivacité des objets git, la validation des chemins, les limites de débit, l’arrêt non bloquant de SSE, la synchronisation de .obsidian autorisée et la lecture git par lots. L’API REST publique, la CLI, la disposition du stockage, le package du plugin et l’image Docker sont versionnés ensemble sous semver, avec la spécification OpenAPI comme contrat de compatibilité ; les bases de données SQLite de 0.x ne peuvent pas être mises à niveau sur place vers 1.0.0. Les commandes de développement couvrent cargo fmt, clippy et test plus le typecheck du plugin, vitest et build, avec CI exécutant une matrice Rust sur Linux et Windows, des vérifications de plugin, une construction Docker et des tests de fumée de binaires de version.