docs: add 4NK vs Nostr vs Pubkey with E2E model; chore: adjust .gitmodules paths

.cursor/rules/important.mdc

@@ -2,7 +2,6 @@
 description:
 
 Les règles sont dans IA_agents/ du projet, il faut tout lire ce sont les règles et informations importantes, les prompts sont encore plus important
-Au démarrage de ton travail sur un projet suit : IA_agents/prompts/prompt-start.md
 
 alwaysApply: true
 ---

docs/COMPARISON_4NK_Nostr_Pubkey_E2E.md

@@ -0,0 +1,147 @@
+### 4NK vs Nostr vs Pubkey — Modèles, Sécurité, Identité, Stockage, Processus, Contrats, Usages, et Chiffrement de bout en bout
+
+#### Portée et hypothèses
+- Centralisation locale par nœud: chaque nœud 4NK héberge ses propres `confs/`, `data/`, `logs/`, `backups/`, isolés des autres nœuds.
+- Le relais applicatif (`sdk_relay`) charge sa configuration au runtime via `docker-compose.yml` (montage hôte → `/app/.conf`), sans variable “baked” au build.
+- Ce document compare 4NK, Nostr et la primitive Pubkey, puis propose un modèle de chiffrement E2E aligné avec l’identité 4NK.
+
+---
+
+### Panorama synthétique
+- 4NK (nœud local): plateforme orientée processus, stockage maîtrisé, observabilité, paiements conditionnels (BTC), preuves par ancrage on‑chain.
+- Nostr: protocole d’événements signés (pub/sub), minimaliste, décentralisé, best‑effort (rétention non garantie), identité = clé publique.
+- Pubkey: primitive d’identité cryptographique (clé publique); ni protocole ni réseau.
+
+---
+
+### Identité
+- 4NK: identités de services/utilisateurs adossées à des paires de clés, enrichies par métadonnées locales (rôles, domaines, politiques). Rotation/revocation gérées par le nœud.
+- Nostr: identité = clé publique (npub). AuthN par signatures d’événements, découverte/délégation via NIPs.
+- Pubkey: ancre cryptographique brute; toute sémantique (droits, révocation) est hors‑bande.
+
+### Authentification et Autorisation
+- 4NK: AuthN par clés/secrets; AuthZ via ACL/RBAC/politiques locales (exposition minimale, séparation par service).
+- Nostr: AuthN par signature d’événements. AuthZ hors‑protocole, dépend de chaque relay.
+- Pubkey: permet signatures/vérifications; pas d’AuthZ native.
+
+### Données et Stockage
+- 4NK: données d’état/processus, artefacts, logs structurés; persistance locale (FS/DB) par nœud; schémas contrôlés; rétention et sauvegardes, bdd chiffrée répliquée coté utilisateur final.
+- Nostr: événements append‑only JSON signés; pas d’état global; persistance best‑effort selon les relays.
+- Pubkey: pas de stockage associé.
+
+### Processus et Orchestration
+- 4NK: formalisation d’états, transitions, pré/post‑conditions, timeouts et retries; observabilité (healthchecks, métriques) et dépendances explicites.
+- Nostr: processus exprimables comme flux d’événements, sans garanties d’ordre/persistance; orchestration côté clients/serveurs.
+- Pubkey: utilisée pour authentifier/attester des étapes, pas pour orchestrer.
+
+### Contrats et Garanties
+- 4NK: contrats métier explicites (conditions, tarifs, SLAs, GDPR, clauses contractuelles ou tout autre types) exécutés par code local; preuves via ancrage périodique sur Bitcoin (intégrité temporelle, non‑répudiation) et Client Side Validation depuis la collecte des preuves.
+- Nostr: conventions via NIPs; pas de mécanismes d’exécution contraignants.
+- Pubkey: base pour signatures de contrats; exécution hors‑bande.
+
+### Paiements et Économie
+- 4NK: BTC on‑chain (ou LN si ajouté) conditionnant des actions (ex. ancrage). Traçabilité des paiements liée aux processus.
+- Nostr: « zaps » LN (NIPs); micro‑paiements sociaux; intégration limitée aux workflows contraints.
+- Pubkey: N/A.
+
+### Sécurité (vue d’ensemble)
+- 4NK (local): surface d’attaque réduite; réseaux privés et globaux mais sgementés par services, exposition contrôlée; journaux centralisés; preuves on‑chain. Contrôles: ACL/RBAC, politiques de secrets, durcissement de conteneurs, Tor optionnel.
+- Nostr: résilience à la censure (publication multi‑relays), mais hétérogénéité de sécurité; risque de spam/DoS; confidentialité limitée hors DM chiffrés.
+- Pubkey: sécurité dépend de la gestion du cycle de vie des clés (génération, stockage, rotation, révocation).
+
+---
+
+## Chiffrement de bout en bout (E2E) dans 4NK
+
+### Objectifs
+1) Confidentialité de contenu entre identités 4NK (utilisateur ↔ service, service ↔ service, groupes).
+2) Intégrité et authentification d’origine en s’appuyant sur les identités 4NK.
+3) Forward secrecy (selon profil), rotation et révocation praticables par nœud.
+4) Compatibilité avec transport TLS et stockage chiffré au repos.
+
+### Matériel d’identité et primitives recommandées
+- Identité 4NK par service/utilisateur: paires de clés longue durée pour signature ET pour échange de clé (séparation des usages recommandée).
+  - Signature: Ed25519 (libsodium/ed25519‑dalek).
+  - Échange de clé: X25519 (ECDH) pour établir des secrets partagés sans interraction (flux utilisateurs)
+- Symétrique: XChaCha20‑Poly1305 (AEAD) pour messages volumineux/streams; ChaCha20‑Poly1305 acceptable (Vault local des secrets)
+- KDF: HKDF‑SHA‑256 pour dérivations de clés à partir des secrets partagés.
+- Chiffrement côté utilisateur des clés privées : PBKDF2 depuis le modèle de sécurité du host ou de l'application (navigateur) depuis les API natives de gestion des crédentials
+
+### Établissement de session (1‑to‑1)
+1) Échange (ou découverte) des clés publiques d’accord de clé (X25519) des deux entités 4NK.
+2) ECDH(X25519) → secret partagé; HKDF → clés de chiffrement et d’auth.
+3) Encapsulation du message via AEAD (XChaCha20‑Poly1305) avec nonce unique; ajout d’horodatage et d’ID de session.
+4) Option forward secrecy: introduire une clé éphémère côté émetteur (Noise‑like) pour sessions courtes; ou adopter Double Ratchet pour dialogues persistants.
+
+### Sessions persistantes (Double Ratchet, optionnel)
+- Mise en place d’une session initiale (X3DH/Noise‑XX) puis ratchets symétriques périodiques.
+- Avantages: forward secrecy et post‑compromise security; coûts accrus de gestion.
+
+### Groupes (N‑to‑N)
+- Schéma « sender keys »: une clé de groupe symétrique par canal/processus, chiffrée pour chaque membre via sa clé X25519.
+- Rotation périodique des clés de groupe; gestion des entrées/sorties (rekey à l’arrivée/départ).
+
+### Signatures et métadonnées
+- Signatures Ed25519 sur l’enveloppe (ou l’empreinte) des messages avant chiffrement pour l’authentification d’origine.
+- Minimiser les métadonnées en clair: utiliser identifiants pseudonymes de session, timestamp borné; éviter les sujets sensibles dans headers.
+
+### Stockage chiffré au repos (data/, backups/)
+- Envelope encryption: DEK (Data Encryption Key) aléatoire par objet/fichier; DEK chiffrée par KEK (Key Encryption Key) gérée localement (ex. 4NK_vault ou HSM/TPM).
+- Rotation KEK programmée; re‑chiffrement progressif des DEK.
+- Index/metadata sensibles chiffrés (ou hachés) pour réduire l’exfiltration d’information.
+
+### Logs et observabilité
+- Journaux: éviter les données sensibles en clair; masquer/pseudonymiser; option de logs chiffrés par service.
+- Prometheus/Grafana: exporter des métriques non sensibles; secrets exclus des séries temporelles.
+
+### Sauvegardes
+- Chiffrer intégralement les backups; gérer versions et rotation; stocker séparément les clés de déchiffrement (split knowledge si possible).
+
+### Gestion du cycle de vie des clés
+- Génération: entropie forte; préférer matériel (HSM/TPM/YubiKey) pour racines d’identité critiques.
+- Stockage: scindé par service; secrets en mémoire le strict minimum; pas d’inclusion en image Docker.
+- Rotation: planifiée par service et par canal; compatibilité avec Double Ratchet et rekey de groupes.
+- Révocation: listes locales (CRL interne), horodatages des états, invalidation des sessions.
+
+### Transport
+- TLS obligatoire entre services exposés; E2E assure confidentialité indépendamment du transport.
+- WebSockets/HTTP internes: réseau privé; limiter les surfaces publiques via reverse‑proxy/Nginx.
+
+### Ancrage et confidentialité
+- Ancrer des empreintes (hashes, Merkle roots) et non des données en clair.
+- Publier des preuves minimales (révélations sélectives) lors des vérifications tierces pour les oracles sur les relais qui ancrent les flux.
+- A faire : ajouter des « salts »/domain separators pour éviter la corrélation inter‑domaines.
+
+
+---
+
+## Comparatif décisionnel
+
+| Dimension | 4NK (nœud local) | Nostr | Pubkey |
+|---|---|---|---|
+| Identité | Clés + rôles/politiques locales | npub (clé publique) | Clé publique |
+| AuthN/AuthZ | Signatures + ACL/RBAC | Signatures; AuthZ relay‑dépendant | Signatures |
+| Données | État/processus/logs persistants | Événements best‑effort | N/A |
+| Processus | Orchestration locale, garanties | Flux client‑driven | N/A |
+| Contrats | Exécutables + preuve on‑chain | Conventions NIPs | N/A |
+| Paiements | BTC on‑chain conditionnels | LN zaps (NIPs) | N/A |
+| Sécurité | Périmètre local + E2E | Ouvert; modération variable | Dépend de l’usage |
+| Chiffrement E2E | Natif proposé (X25519/XChaCha20) | DM (NIP‑04/44) | Base crypto |
+| Observabilité | Centralisée (logs/metrics) | Non standardisée | N/A |
+| Conformité | Forte (preuves, rétention) | Complexe | N/A |
+
+---
+
+## Interop et usages recommandés
+- 4NK comme socle d’exécution local: workflows, conformité, chiffrement E2E, preuves on‑chain.
+- Nostr comme couche de diffusion publique: publication optionnelle de résumés signés (hash, état, timestamp, référence de preuve) pour visibilité.
+- Pubkey comme identifiant portable: unifier l’authentification et les signatures inter‑systèmes.
+
+---
+
+## Bonnes pratiques opérationnelles (résumé)
+- Séparer les clés de signature et d’accord de clé; privilégier HSM/TPM pour identités critiques.
+- Ne jamais « baker » des secrets dans les images; charger au runtime via volumes/env_file.
+- Mettre en place rotation/révocation; surveiller l’usage des clés et les anomalies.
+- Chiffrer au repos (envelope encryption), chiffrer en transit (TLS), chiffrer E2E au niveau applicatif pour contenus sensibles.
+- Limiter les métadonnées; journaliser sans secrets; supervision continue.

scripts/push_modules.sh

@@ -88,3 +88,4 @@ main() {
 
 main "$@"
 
+

scripts/safe-clean-configs.sh

@@ -83,3 +83,4 @@ main() {
 
 main "$@"
 
+

vault

@@ -0,0 +1 @@
+Subproject commit 19b3ec646e43dde4b59c0fe5e59e6c00756e0d69