4nk/anchorage_layer_simple
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
anchorage_layer_simple/userwallet/features/userwallet-pairing-connecte.md
ncantu 46bf9676a0 Install and enable all missing systemd services 
**Motivations:**
- Ensure all application directories have systemd services enabled at boot
- Complete service installation for api-relay, filigrane-api, and clamav-api
- Fix dependencies and import issues preventing clamav-api from starting

**Root causes:**
- Three services (api-relay, filigrane-api, clamav-api) had service files but were not installed in systemd
- api-clamav had incorrect node-clamav version (0.12.1) that doesn't exist
- api-clamav dependencies were not installed (node_modules missing)
- ES module import syntax incompatible with CommonJS node-clamav package

**Correctifs:**
- Installed api-relay.service, filigrane-api.service, and clamav-api.service in /etc/systemd/system/
- Enabled all three services for automatic startup at boot
- Updated api-clamav/package.json: changed node-clamav version from ^0.12.1 to ^1.0.11
- Installed npm dependencies for api-clamav
- Fixed ES module import in api-clamav/src/routes/scan.js to use CommonJS-compatible syntax

**Evolutions:**
- All 7 application services now have systemd services enabled at boot
- Complete service coverage: anchorage-api, faucet-api, signet-dashboard, userwallet, api-relay, filigrane-api, clamav-api
- All services verified active and listening on their respective ports

**Pages affectées:**
- api-clamav/package.json
- api-clamav/src/routes/scan.js
- api-clamav/node_modules/ (new)
- api-clamav/package-lock.json (new)
- /etc/systemd/system/api-relay.service (new)
- /etc/systemd/system/filigrane-api.service (new)
- /etc/systemd/system/clamav-api.service (new)
2026-01-26 12:56:11 +01:00

3.6 KiB
Raw Blame History

Pairing "Connecté" — confirmation croisée et affichage

Objectif

Afficher "Connecté" sur chaque device une fois que le flux de confirmation signé de l’autre device a été reçu et traité. La confirmation repose sur un message "membre finaliser" signé par les deux devices, publié sur le relais avec version incrémentée, et stockée en IndexedDB.

Rappel

Les messages sont envoyés essentiellement chiffrés. Il faut avoir reçu des messages de clé (Diffie-Hellman) pour déchiffrer la clé de chiffrement et, via le hash, récupérer sur le relais le message qui nous concerne.

Flux attendu

Premier device

  1. Après "Associer le pair", le 1er device a ajouté le pair distant (8 mots BIP32-style du 2e).
  2. Le 1er device envoie un message "membre finaliser" qu’il signe.
  3. Ce message doit aussi être signé par le 2e device.
  4. Le 1er device attend la signature du 2e device sur ce contrat.
  5. Une fois reçue, il l’ajoute aux signatures du contrat, vérifie que toutes les signatures attendues sont présentes, puis publie le contrat sur le relais (à nouveau), avec une version incrémentée.
  6. Il garde la version (et le contrat) dans IndexedDB.
  7. Quand tout est OK (flux signé du 2e reçu et traité) → afficher "Connecté" sur le 1er device.

Deuxième device

  1. Après "Associer le pair", le 2e device a ajouté le pair distant (8 mots BIP32-style du 1er).
  2. Le 2e device envoie un message "membre finaliser" qu’il signe.
  3. Il envoie sa signature au 1er device (via relais : message/clé/signature).
  4. Il complète le contrat avec sa signature, incrémente la version, et le garde dans IndexedDB.
  5. Quand tout est OK (flux signé du 1er reçu et traité) → afficher "Connecté" sur le 2e device.

Impacts

  • Contrats : format "membre finaliser" / "membre finalisé", validateurs, signatures multiples.
  • Relais : publication message + signatures + clés (chiffrement, DH).
  • IndexedDB : stockage des versions et des contrats signés.
  • Sync : récupération des messages chiffrés, clés DH, déchiffrement, mise à jour du graphe et détection des confirmations croisées.

Modalités de déploiement

  • Déploiement classique du front userwallet.
  • Les relais doivent exposer POST message, POST signatures, POST keys (déjà prévus).
  • Aucune migration IndexedDB imposée pour l’existant tant que le protocole n’est pas implémenté.

Modalités d’analyse

  • Vérifier les logs (console) pour les pairs et contrats.
  • Tester le parcours "Associer le pair" sur les deux devices puis vérifier l’affichage "Connecté" une fois les signatures croisées reçues et le contrat publié.

Statut

  • Documentation : présente.
  • Implémentation : faite (message "membre finaliser", échange de signatures, publication relais, stockage IndexedDB, affichage "Connecté"). Version incrémentée : device 1 re-publie M2 (version "2") après réception de la signature du 2e. Détection au Sync : si device 1 a timeout au poll, un « Synchroniser maintenant » vérifie messages + signatures et enregistre la confirmation. Chiffrement ECDH : échange de clés publiques (QR/URL pubkey, formulaire « Clé du 2e »), PairConfig.publicKey, chiffrement encryptWithECDH, POST MsgCle (algo AES-GCM-ECDH, df_ecdh_scannable = clé du signataire), déchiffrement au fetch. Type "membre finalisé" (device 2) : non implémenté, les deux signent le même "membre finaliser". Export/import : pairing_confirm inclus dans l’export, restauré à l’import ; suppression (« Supprimer ») vide aussi userwallet_pairing_confirm.