100 lines
5.0 KiB
Markdown
100 lines
5.0 KiB
Markdown
# Documentation fonctionnelle - ihm_client
|
||
|
||
Cette documentation décrit ce que fait fonctionnellement l’interface `ihm_client`, les parcours utilisateurs, les règles de gestion et les contraintes associées. Aucun exemple de code applicatif n’est inclus.
|
||
|
||
## Objectif produit
|
||
|
||
- Proposer une interface moderne pour la gestion de processus collaboratifs autour des Silent Payments.
|
||
- Faciliter le pairing sécurisé entre appareils/utilisateurs et la gestion des transactions associées.
|
||
- Offrir un espace unifié pour la gestion des membres, documents, signatures et échanges (chat/notifications).
|
||
|
||
## Personas et rôles
|
||
|
||
- Utilisateur standard: initie/participe à des processus, signe des documents, échange des messages.
|
||
- Administrateur de processus: configure les rôles, vérifie les validations, déclenche des mises à jour.
|
||
- Observateur (lecture seule): consulte les informations publiques/partagées sans intervenir.
|
||
|
||
## Parcours principaux
|
||
|
||
### Accueil
|
||
- Accès rapide aux sections clés (Compte, Processus, Signature, Chat, Pairing).
|
||
- Indicateurs d’activité: processus actifs, notifications récentes, métriques succinctes.
|
||
|
||
### Pairing (mise en relation)
|
||
- Objectif: établir une relation de confiance entre appareils via adresse Silent Payment.
|
||
- Étapes:
|
||
1. Saisir ou scanner l’adresse SP distante (ou URL contenant `sp_address`).
|
||
2. Vérifier l’empreinte visuelle (emojis) dérivée de l’adresse pour confirmer l’identité.
|
||
3. Créer et confirmer le processus de pairing (flux guidé, confirmation finale).
|
||
- Résultat: l’appareil local est appairé; les échanges sécurisés sont possibles.
|
||
|
||
### Wallet et relays
|
||
- Visualiser l’état du wallet (montant disponible, synchro via relays).
|
||
- Interagir avec le réseau via relays (mise à jour des membres/états, échange de messages techniques).
|
||
- Disposer d’un mécanisme de “faucet” en environnement de test pour provisionner le wallet.
|
||
|
||
### Processus
|
||
- Créer un nouveau processus (données publiques et privées, rôles, règles de validation).
|
||
- Mettre à jour un processus existant (évolution des états, validations, preuves).
|
||
- Consulter l’historique (états validés, états en attente/non committés).
|
||
|
||
### Membres et rôles
|
||
- Gérer les membres impliqués (par adresse SP).
|
||
- Définir des rôles et règles de validation (quorum, champs soumis à contrôle, seuils).
|
||
- Vérifier l’appartenance de l’utilisateur à un rôle (autorisation implicite des actions).
|
||
|
||
### Documents et signatures
|
||
- Associer des documents aux processus (hashés et stockés via mécanismes dédiés).
|
||
- Déclencher des demandes de signature, suivre leur statut (en attente, signé, expiré).
|
||
- Vérifier/valider les preuves (ex. Merkle) liées aux documents échangés.
|
||
|
||
### Chat et notifications
|
||
- Échanger des messages dans le contexte des processus.
|
||
- Recevoir des notifications liées aux événements (nouvelle transaction, demande de signature, mise à jour de processus).
|
||
|
||
## Règles de gestion clés
|
||
|
||
- Pairing
|
||
- Une empreinte visuelle (emojis) dérivée de l’adresse SP aide à la confirmation utilisateur.
|
||
- Un processus de pairing doit inclure l’adresse de l’appareil local.
|
||
- Validation
|
||
- Les règles de validation (quorum, seuils) s’appliquent aux champs déclarés.
|
||
- Une mise à jour de processus peut être refusée si les preuves/validations sont insuffisantes.
|
||
- Données
|
||
- Les données volumineuses (blobs) sont stockées séparément et référencées par hash.
|
||
- Les attributs chiffrés nécessitent clés/permissions pour être déchiffrés.
|
||
- Sécurité
|
||
- Les échanges sont consolidés via relays; l’appairage conditionne l’accès aux données privées.
|
||
- Les tokens de session sont temporaires et régénérables (Access/Refresh).
|
||
|
||
## Contraintes et limites
|
||
|
||
- Dépendance au module WASM pour les opérations de bas niveau (Silent Payments, encodages, preuves).
|
||
- Nécessité d’un ou plusieurs relays disponibles pour la synchronisation et l’échange d’informations.
|
||
- Performance dépendant du contexte (navigateur, réseau, taille des données).
|
||
|
||
## Indicateurs et métriques
|
||
|
||
- Disponibilité des relays et latence observée.
|
||
- État de synchronisation (hauteur de bloc, mises à jour reçues).
|
||
- Taille et temps de manipulation des documents.
|
||
- Taux de succès des signatures et validations.
|
||
|
||
## Gestion des erreurs et non-régression
|
||
|
||
- Messages d’erreur explicites pour états manquants, adresses invalides, clés indisponibles, connexions relays.
|
||
- Tests unitaires couvrant conversions (hex/blob), DOM utilitaire et tokens.
|
||
- Stratégie de test documentée (voir `docs/TESTING.md`).
|
||
|
||
## Confidentialité et conformité
|
||
|
||
- Pas de stockage permanent de secrets en clair côté client.
|
||
- Utilisation stricte de variables d’environnement pour les secrets runtime.
|
||
- Revue régulière des dépendances et audits sécurité (voir `docs/SECURITY_AUDIT.md`).
|
||
|
||
## Support et usage
|
||
|
||
- Guides d’installation et d’utilisation (voir `docs/INSTALLATION.md`, `docs/USAGE.md`).
|
||
- Référentiel contractuel des API (voir `docs/API.md`).
|
||
- Intégration dans un site via iframe (voir `docs/INTEGRATION_IFRAME.md`).
|