ihm_client/docs/FONCTIONNEL.md

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).