# Définition
## 1. Autheurs, validations, dates, versions, changement and historique
Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc)
## 2. Table des matières
* 1. [Autheurs, validations, dates, versions, changement and historique](#Autheursvalidationsdatesversionschangesandhistory)
* 2. [Table des matières](#Tabledesmatires)
* 3. [Documents de référence](#Documentsderfrence)
* 4. [Spécifique 4NK](#Spcifique4NK)
* 5. [Bitcoin](#Bitcoin)
* 6. [Chiffrement](#Chiffrement)
* 7. [Data](#Data)
* 8. [Exemples de Code](#ExemplesdeCode)
* 9. [Todo](#Todo)
## 3. Documents de référence
Voir [_Doc_references.md](_Doc_references.md).
## 4. Spécifique 4NK
* **Web 5.0.** : Une plateforme décentralisée innovante développée par 4NK, combinant les technologies de blockchain et de contrats intelligents pour révolutionner la manière dont les applications web interagissent avec les données et les transactions sécurisées.
* **Relay** : Serveurs ou noeuds spéciaux dans le réseau 4NK qui facilitent la communication peer-to-peer et la diffusion de transactions et de messages entre les utilisateurs et la blockchain. Les relais jouent un rôle crucial dans l'acheminement des informations et dans le maintien de la décentralisation du réseau.
* **4NK**: Système décentralisé innovant basé sur les principes du web 5, centré sur la sécurité des données et l'identité numérique.
* **Portable Contract Document (`Pcd`)**: Un format `JSON` chiffré conçu pour contenir des listes d'éléments d'un type spécifique, attachées à un processus (`process_hash`) et soumises aux règles de validation décrites dans le rôle correspondant à ce type d'`Item` dans le `Process` (`item_type`).
* **Portable Request Document (`Prd`)**: Format `JSON` chiffré contenant les valeurs de signatures et les clés de déchiffrement nécessaires à l'exploitation (requêtes et validation) des `Pcd`. Les `PrdResponse` sont collectés pour vérifier le respect des conditions de `Process`. D'autres types de `Prd` incluent :
* `PrdList`: Demande de listes d'`Item`. En réponse, une `Pcd` est reçue avec les `PrdResponse` correspondants.
* `PrdMessage`: Envoi de messages publics, confidentiels ou privés et/ou de transactions Silent Payments des autres `Prd` à diffuser sur le réseau des nœuds de la side chain. Les `PrdMessage` peuvent répondre les uns aux autres.
* `PrdUpdate`: Demande de mise à jour d'une liste d'`Item` (publiée via un `PCD`), qui sera déchiffrée et validée ou non par des `PrdResponse` en retour.
* `PrdConfirm`: Confirmation de la réception des `Prd` (à l'exception de `PrdConfirm` eux-même).
* `PrdResponse`: Réponse aux autres types de `Prd` (à l'exception de `PrdConfirm` et `PrdResponse`).
* **Message**: Enveloppe commune pour les `Prd` et `Pcd` lors de leur transmission aux relais et de leur réception depuis les relais. Dans cette enveloppe les `Prd` et `Pcd` sont chiffrés par la `ProcessKey` de `Process` (cf. [Specs-Definition](SpecsDefinition.md)) et ajoutés au champs `RequestEnc`.
* **KeyConfidential**: Clé AES-GCM-256 issue du `Diffie-Hellman` de la transaction Silent Payments correspondant à un `Prd`.
* **ProcessKey**: La clé publique de chiffrement d'un `Process` (trouvée dans un `Process`, dans son attribut `Item`, dans son attribut `metadata_contract_public`, dans son attribut `meta_data`, dans son attribut `key_list` au premier élément).
* **KeyRecover**: La clé privée de dépense de `recover` du signet, utilisée comme référence pour l'identité.
* **pre-id**: Pré-identifiant des utilisateurs, constitué du hash de la partie 1 de la `KeyRecover`.
* **Peer**: Terme générique pour représenter un nœud du réseau, pouvant avoir diverses fonctions.
* **Relay**: Un serveur web socket qui relaie en peer to peer les messages entre les autres pairs du réseau de relais et avec les clients connectés.
* **Process**: Contrat off-chain définissant des conditions d'affichage, légales, de validation cryptographique et de rémunération des signatures au global et par `Role`. Dans le contexte de 4NK, un contrat (souvent appelé smart contract) désigne un ensemble de règles codées et stockées et vérifiée côté client à la différence des principales blockchains. Ces règles automatisent l'exécution des accords et des transactions strictement par et entre les parties prenantes, garantissant l'intégrité et la transparence des interactions au sein de la plateforme Web 5.0. Ces contrats étant formulés dans objets `Process` avec une semantique explicite des attributs et des règles; les systèmes peuvent exploiter les contrats directement dans le système d'informatione et la notion de contrat est fusionnée avec celle processus.
*
* **Role**: Un `Role` décrit le type d'`Item` dans les listes (`PCD`) versionnées et gérées par ces `Member` identifiés par leur adresse silent payment. Le `Role` décrit aussi les conditions des conditions d'affichage, légales, de validation et chiffrement de ces listes. Parmi ces conditions, certaines actions peuvent requièrir d'autres `Item` de type `Payment`, `Commit` ou `Deposit` pour être validées; dans ces cas, ces objets sont eux même soumis à règle du `Role` correspondant.
* **Silent Payments Address**: Adresse Bitcoin utilisée pour les transactions Silent Payments, permettant de recevoir et d'envoyer des fonds de manière confidentielle. C'est aussi l'identifiant des `Member` dans les `Process` tel un annuaire, et les flux.
* **Utilisateur**: Client connecté pouvant être un navigateur, une application mobile, un logiciel, ou un IoT, utilisé par un humain ou une machine.
* **Recover**: Action de recomposer une identité numérique (clés privées).
* **Revoke**: Action de révoquer des clés privées et d'en proposer de nouvelles (en cas de révocation, expirations, pertes ou vols). Une adresse de révocation est stockée dans les données exifs d'une image générée avec l'image de login. Cette image doit être conservée en sécurité car elle permet de dépenser un UTXO d'une`adresse SP` indiquée dans son `Member` comme le signal pour les autres parties prenantes qu'une autre identité doit être prise en compte pour ce Member.
* **Onboard**: Action de demander un `rôle` dans un `Process` .
* **Member**: Une adresse Silent Payments, complétée de métadonnées, par `Process` et d'une adresse supplémentaire pour la révocation.
* **Third parties**:`adresse SP` complétant un `Member` pour reconnaître d'autres dispositifs du `Member`.
* **Autres termes propres à 4nk**: voir Specs-Datas.md.
## 5. Bitcoin
* **UTXO (Unspent Transaction Output)**: Sortie de transaction non dépensée dans la blockchain, représentant des tokens ou des actifs numériques qui peuvent être utilisés dans de futures transactions.
* **HD Wallet (Hierarchical Deterministic Wallet)**: Un portefeuille cryptographique qui génère une structure d'arbres de clés à partir d'une graine unique, permettant une gestion sécurisée et organisée des multiples adresses et clés cryptographiques.
* **Timechain**: Terme préféré à "blockchain", désignant un intervalle de temps régulier entre des blocs de transactions cryptographiques, sécurisées par cryptographie pour une distribution de la sécurité et de l'ordre des événements de façon identique sur l'ensemble du réseau.
* **Silent Payments (SP)**: Méthode de paiement permettant d'envoyer et de recevoir des fonds sans réutiliser les adresses Bitcoin, améliorant ainsi la confidentialité des transactions.
## 6. Chiffrement
* **MPC (Multi-Party Computation)**: Technique de calcul qui permet à plusieurs parties de calculer conjointement une fonction sur leurs entrées tout en gardant ces entrées secrètes.
* **PBKDF2 (abréviation de Password-Based Key Derivation Function 2)**: applique une fonction pseudo-aléatoire, telle qu'un code d'authentification de message basé sur le hachage (HMAC), au mot de passe ou à la phrase secrète d'entrée ainsi qu'une valeur salt et répète le processus plusieurs fois pour produire une clé dérivée, qui peut ensuite être utilisée comme clé cryptographique dans les opérations ultérieures. Cela étend l'entropie du mot de passe utilisateur. Cette fonction appartient à la famille des normes Public Key Cryptographic Standards, plus précisément PKCS #5 v2.0. Cette norme a également été publiée dans la RFC 2898. Elle succède au PBKDF1, qui pouvait produire des clés n'allant que jusqu'à 160 bits.
Cette norme est aujourd'hui utilisée pour le hachage de mot de passe (associé à des fonctions comme SHA-256) ou la génération de clé de chiffrement de données.
* **SHA256 (Secure Hash Algorithm 256)**: Fonction de hachage cryptographique utilisée pour assurer l'intégrité des données et générer des empreintes uniques des documents.
* **AES-GCM-256**: Implémente le codage et le décodage Rijndael en conformité avec la norme avancée de chiffrement (AES) du NIST. Il traite des blocs de 256 bits. Le mode Galois/Compteur (Galois/Counter Mode, GCM) est un mode d'opération pour les chiffrements par blocs à clé symétrique largement adopté pour sa performance. L'algorithme GCM fournit à la fois l'authenticité et la confidentialité des données et appartient à la classe des méthodes de chiffrement authentifié avec des données associées.
* **Diffie-Hellman key exchange**: Méthode d'échange sécurisé de clés cryptographiques sur un canal public, l'un des premiers protocoles de cryptographie à clé publique.
* **Shamir Secret Sharing**: Algorithme de cryptographie permettant de diviser un secret en plusieurs parties, nécessitant un certain nombre de ces parties pour le reconstituer.
* **Transport Layer Security**: Protocoles de sécurisation des échanges par réseau informatique, notamment par Internet.
## 7. Data
* **Cache**: Partie 1 chiffrée de la clé de dépense du signet du login stockée en cache, ainsi que les `Process` découverts et les pairs du réseau. Une fois identifié auprès des Members d'un `Process` et avec son identité `Member` récupérée, l'objet Member et les `Pcd` et `Prd` du compte sont stockés en cache. Le cache se compose d'une partie prive jamais partagée et d'une partie publique partagée.
* **IndexDB**: Base de données de stockage côté client utilisée pour stocker de manière sécurisée les données chiffrées, telles que les `Pcd` et Prd, dans les navigateurs web.
## 8. Exemples de Code
## 9. Todo