le0nardomartins/ClaudeMemorySync-Server

Claude Memory Sync : serveur

Dépôts :

• Serveur (celui-ci) : https://github.com/le0nardomartins/ClaudeMemorySync-Server
• Client (un par PC) : https://github.com/le0nardomartins/ClaudeMemorySync. Il possède la compétence claude-memory-sync, effectue une fusion à trois, chiffre tout avec la SYNC_KEY et supporte également un mode sans serveur, via un dépôt Git privé.

Le serveur ne fait pas de fusion et ne lit pas le contenu. Il stocke des manifestes et des blocs scellés et n'accepte une nouvelle version que si elle part de la plus récente (409 conflict dans le cas contraire).

Lisez à la demande, dans ce dossier :

• deploy.md : déploiement sur Railway ou autre fournisseur, mise à jour
• api.md : protocole, pour déboguer les requêtes
• operations.md : requêtes SQL de consultation et maintenance, sauvegarde, révocation, diagnostic

Règles qui s'appliquent toujours

1. Données. Avec SYNC_KEY sur les PC, la base de données ne contient que des données chiffrées. Sans elle, elle contient des clés API de l'utilisateur. Dans tous les cas, n'exposez jamais Postgres publiquement et ne partagez jamais DATABASE_URL.
2. Clés. CLIENT_PUBLIC_KEYS ne contient que des clés publiques, qui peuvent apparaître. CLIENT_PRIVATE_KEY et SYNC_KEY ne vont jamais sur le serveur ni dans le chat.
3. Confirmez avant le déploiement, le push, la modification de variable sur Railway, TRUNCATE, DELETE ou toute autre action irréversible. Faites une sauvegarde (pg_dump, voir operations.md) avant de toucher aux données.
4. Protocole apparié. Le client et le serveur doivent être sur la même version du protocole. Lors de la mise à jour de l'un, rappelez à l'utilisateur de mettre à jour l'autre sur tous les PC.
5. Réinitialiser le serveur n'efface rien sur les PC. Chaque PC conserve sa base localement et renvoie tout lors de la session suivante. Pour supprimer un fichier de tous les PC, il suffit de le supprimer sur un seul PC : ne touchez pas au serveur pour cela.

Tâches

Déploiement initial

Suivez deploy.md → « Railway ». L'utilisateur doit :

• créer le projet et Postgres dans le tableau de bord, ou autoriser l'utilisation de la CLI Railway ;
• coller les clés publiques.

À la fin, vérifiez dans le log la ligne memory server sur le port ... | PCs autorisés : ....

Autoriser un PC

1. Sur le PC, générez les clés : python src/components/remote_client.py keygen <nom> (client) ou npm run keygen -- <nom> (ici).
2. Ajoutez <nom>:<base64> dans CLIENT_PUBLIC_KEYS, séparé par une virgule, sans effacer les autres.
3. Railway redémarre automatiquement. Vérifiez le nom dans PCs autorisés dans le log.

Révoquer un PC

Supprimez son entrée de CLIENT_PUBLIC_KEYS. Si la machine a été compromise, orientez vers le changement de SYNC_KEY sur tous les PC (dépannage du client) et réinitialisez l'historique (operations.md).

Diagnostiquer

Lisez les logs du service (tableau de bord Railway ou railway logs) et comparez avec operations.md → « Diagnostic ». Côté client, le fichier est sync.log. 409 suivi de 201 est normal.

Consulter ou maintenir la base de données

Utilisez les requêtes de operations.md. Pour un accès ponctuel, utilisez railway connect Postgres. Privilégiez les requêtes en lecture seule et confirmez toute écriture.

Mettre à jour le serveur

1. Effectuez un push sur le dépôt : Railway déploie via le Dockerfile. Les migrations s'exécutent automatiquement au démarrage (db.migrate).
2. Ensuite, demandez la mise à jour des clients.