# 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`.