6e8f554371
**Motivations:** - Finaliser l'implémentation du pairing avec mots uniquement - Mettre à jour la documentation du pairing connecté **Root causes:** - N/A (évolution fonctionnelle) **Correctifs:** - N/A **Evolutions:** - Finalisation du pairing avec mots uniquement - Mise à jour de la documentation **Pages affectées:** - features/userwallet-pairing-words-only-finalise.md - userwallet/features/userwallet-pairing-connecte.md
53 lines
3.5 KiB
Markdown
53 lines
3.5 KiB
Markdown
# 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", validateurs, signatures multiples (les deux devices signent le même message).
|
||
- **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. **Pairing** : uniquement par 8 mots (BIP32-style) ; pas d'échange de clé publique dans les formulaires. **Chiffrement** : si `PairConfig.publicKey` est fourni (optionnel), ECDH `encryptWithECDH` / POST `MsgCle` ; sinon message en clair (base64). **Export/import** : `pairing_confirm` inclus dans l’export, restauré à l’import ; suppression (« Supprimer ») vide aussi `userwallet_pairing_confirm`.
|