Auteur/autrice : webmaster

Bootstrap niveau de code

La stratégie de développement du bootstrap mérite une petite explication.

Ce « petit » morceau de code unique de quelques 6500 lignes aujourd’hui a pour rôle de recherche et charger la bibliothèque nebule et l’application demandée par l’utilisateur.

Son interface est sommaire, spartiate. L’utilisateur moyen n’a pas beaucoup de raison de s’y aventurer en temps normal. Si le bootstrap apparaît c’est sûrement pour un problème grave…

Son code résulte de la tension forte entre le besoin d’une code de démarrage unique des applications et le besoin récurrent de mise à jour en cas de faille.

Pour cela il intègre une bibliothèque réduite et limité de nebule afin de pouvoir manipuler les objets et liens en provenance uniquement des entités autorités. Ensuite, une fois l’application chargée, c’est le code de la bibliothèque complète qui est utilisée, mais celle-ci est tenu à jour en recherchant toujours la dernière version disponible. Et il en est de même pour les différentes applications.

Le code du bootstrap a été fait en programmation procédurale (dit libpp) afin qu’il n’y ai pas de confusion avec le code de la bibliothèque complète en programmation orientée objet (dit libpoo).

Afin de pouvoir être d’une certaine utilité en cas de problème, le bootstrap intègre trois toutes petites applications :

  • app 0 : sélection de l’application à lancer pour l’utilisateur.
  • app 1 : documentation nebule.
  • app 2 : application par défaut, ne fait rien que d’afficher une page simple.

Graphe des entités autorités

Afin d’organiser une certaine intendance autour de la diffusion du code des applications, un certain nombre d’entités sont nécessaires.

Le modèle utilisé est assez classique est simple, c’est un schéma de parenté. Il peut être amené à évoluer dans le futur.

La structure du graphe reconnue est la suivant :

  • Le maître du tout (puppetmaster)
    • Les autorités de la sécurité
    • Les autorités du code
    • Les autorités du temps
    • Les autorités de l’annuaire

Une évolution est en cours d’intégration avec la nouvelle version des liens. Si l’entité qui chapeaute toutes les autres est unique, chaque groupe d’autorités n’est plus seulement une entité mais devient un groupe d’entités à pouvoir identique.

Il est à prévoir que le maître du tout deviendra aussi, un jour, des autorités globales. Mais la forme n’est pas encore défini.

Chaque entité ici considérée doit être un objet entité EID (Entity ID) valide avec lien de type, un lien de nommage et un lien de localisation (URL web).

D’un point de vue sémantique, on quitte progressivement la notion de maître historique pour aller vers la notion d’autorité. Outre le rapport à l’esclavage, on est soumis au maître, on se soumet à l’autorité.

Le puppetmaster est un EID qui peut être remplacé. Il va faire référence par des liens dédiés vers les différents d’autorités au moyen de RID dédiés :

  • Autorités de la sécurité
    • a4b210d4fb820a5b715509e501e36873eb9e27dca1dd591a98a5fc264fd2238adf4b489d.none.288
  • Autorités du code
    • 2b9dd679451eaca14a50e7a65352f959fc3ad55efc572dcd009c526bc01ab3fe304d8e69.none.288
  • Autorités du temps
    • bab7966fd5b483f9556ac34e4fac9f778d0014149f196236064931378785d81cae5e7a6e.none.288
  • Autorités de l’annuaire
    • 50e1d0348892e7b8a555301983bccdb8a07871843ed8f392d539d3d90f37ea8c2a54d72a.none.288

C’est à dire que tout EID désigné par un de ces RID (l>RID>EID), et signé par le puppetmaster, devient une autorité dans le groupe considéré.

Nœuds et références

Entre le nÅ“ud et la référence, peu de différence à voir. C’est surtout un usage dans le code.

La référence RID (Reference ID) est un nÅ“ud NID que l’on utilise explicitement comme point de départ d’une recherche d’objets.

Là o`u un NID différent va être utilisé pour désigner chaque groupes, un RID va être unique pour retrouver une propriété.

Par exemple une conversation est un groupe de messages. Mais chaque conversation est unique, chacune dispose d’un NID propre.

Le suivi d’un code d’une application se fait en récupérant le dernier lien depuis un RID. Mais on peut aussi voir ce RID comme un groupe des versions successives de cette application.

Le nommage d’un RID n’a pas de raison d’être même si ce n’est pas interdit.

NÅ“ud – nouvel identifiant

La notion de nœuds dans nebule a évoluée avec le temps.

Le nÅ“ud servait avant pour désigner un point d’entrée afin de chercher certaines informations. C’était un objet, donc un contenu, et donc un identifiant (OID), défini à l’avance et que l’on pouvait retrouver facilement. Il était marqué en tant que tel. Puis il est devenu progressivement un objet virtuel, c’est à dire avec comme identifiant une empreinte aléatoire et donc sans contenu connu.

Maintenant, le nÅ“ud devient un objet virtuel clairement identifié en tant que tel, c’est à dire que si son identifiant (NID) est toujours aléatoire, le suffixe d’algorithme de prise d’empreinte démontre tout de suite que ce n’est pas une empreinte.

Un objet a pour identifiant OID (Object ID) :

88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256

Ici, le contenu est bien connu, c’est une entité connu. On voit que l’empreinte est faite avec l’algorithme sha256, c’est à dire de la famille sha2 avec une taille de 256bits.

L’identifiant NID (Node ID) d’un nÅ“ud va ressembler mais avec une taille et un suffixe différent :

a4b210d4fb820a5b715509e501e36873eb9e27dca1dd591a98a5fc264fd2238adf4b489d.none.288

Le suffixe est de la famille none et la taille est plus… variable. Ici la taille est de 288bits, soit 72octets. Cette forme est maintenant normalisée.

Attention cependant, il y a une taille minimum de la valeur des NID que le code va accepter. La course aux NID les plus petits n’est pas forcément une bonne idée.

Le nÅ“ud n’ayant pas de contenu, sont nom doit être au besoin explicitement définit par un lien de nommage vers un objet contenant le nom attendu.

Autour des NID, on va retrouver un graphe de OID ou autres NID. Ce graphe va dépendre de ce que l’on attend du NID mais celui-ci reste bien un point d’entrée privilégié dans le graphe global des données.

Enfin, il faut comprendre que c’est ici une façon de marquer explicitement un nÅ“ud dans son identifiant mais que tout objet est en soi un nÅ“ud et peut être utilisé comme tel. Un OID peut être considéré comme un NID avec un contenu.

Premiers liens signés en v2.0

Les deux premiers liens dans la nouvelle forme en v2.0 viennent d’être signés :

nebule:link/2:0_0:020210714/l>88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256>5d5b09f6dcb2d53a5fffc60c4ac0d55fabdf556069d6631545f42aa6e3500f2e.sha2.256>8e2adbda190535721fc8fceead980361e33523e97a9748aba95642f8310eb5ec.sha2.256_88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256>79bf4029cf6ee77b0f9db987fcb59c53434a8f2e36773d7a427ec869de04698ddb044bfe08d963732dec237ef56b03f003f4bcc491e293c0b6a7396a351b10e319aa80984bd5d7c0c812cd6a91a296d55ace2e6e6d266dd06c83f21814e272793e75e23cb8f70911ba845885f9e41636466b74e6a7f7e1c174e612776981e645273ac59410ab39606feb20102cf28834aa054008bb35191573189bb0266875dd82cbf12dc64d0eb77acf59e18c8336583faac32755450c00d559398fbd078871fcd9097ac476f67010a9d728a00860f1e34f66bd32b64093b834fcce2bf028193335ebedd1ae27e29df3b8184360bee9dbc707135c54ef48d3efc096b32ba33681925afb8d4e7d4f91598f4d250eb9d27b96762727610a87317892033e84e6e7198837a10ef5e8582ecb98d6aef00e7b4ef2d536cb2063b476d21a8abaf6678462e329bf08bb9159ec4a7358b1e6b15252bd1acf471eb43895edc4caaee58e9d1fcd36cd21b7fc45fb43443c3408de80c1aa3d8c45c71071bfebbfa0c82f747e97f0668d628a3bb5f18cf105b5c16ac14fa61730fdf97342add718ee6c55cf576b060027ce5dfd3651349ff3163011f58cdc2140ea3ef9d2bfefe1d105498722b6ff3c0993aaffa0f0625e5bd2503cf289ec3e694b43616134d1a938dfe1d050b4106f466b23c2dc446e7f1d96a942aaa73c694a8434bdf549fde985ff939142.sha2.512
nebule:link/2:0_0:020210714/l>88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256>970bdb5df1e795929c71503d578b1b6bed601bb65ed7b8e4ae77dd85125d7864.sha2.256>5312dedbae053266a3556f44aba2292f24cdf1c3213aa5b4934005dd582aefa0.sha2.256_88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256>58ca04cc43fc46c7a5176f2ff8f93754da9cfaabff2f12a3c9e6453d3dd3eeedd0208477f9e62c085a6f32583a127467696d7af980fe18a85a7951a6deea6372ca9f0c965d0a08fa159f241a680d5dba69449acb03043fc8021b93a2e34a1c3fb93385250f5ebf7a457fd38f2c6b1e500614f19b37bd37416342ddd94385ec2f5185fddde6d803fc1f89dabe6aebcd55490688cdbe5c779ae2b81d7a4b65c57fd6b35b6ad0fb20881f12c04e34a1730e254530a9c69fdaa9c1ef76fa6248a6e22417e25758837c7378f97af5c3d2cfe88fe9711ba705e2d017fe7ff4c97cbb44600e0d7b32e1c2f97467d8e79d48fc5d6dbd3d581bb831582be7f1a918609cd4a64e4d621bababaddde6da3621f24220ed7dc2ae585fe9b7f9cd71fe18a1a75778c54bdf1e7ad066e10c36e7fb2a4577f9d1bc7be1f80363d1a3e58e34ee4971ccd0a8a8b45665b1234909104558cb210ea402cb7822e3f4c5e1095c4f6a8a86b432b7c77028c76d38dd171a009dd7b251f74ea112739b91cfd8a6c665546bb984dc2fd1f59212a59f84154556bcdfade82c1b049e91a1befa45f2511f02123aa3f7718b0c64aeca984eb70cb9841e933603221765899384e1d3467cb31071ae3071e741f9689735a7e0c8cf7e202b926260067112fec8b24f991a6b35868fbb3653f2be774574d87e1a0fe9222774f6ede5b38c8393d72ff866faa40c5b706f.sha2.512

Ces deux liens concernent l’entité puppetmaster et sont ceux posés par défaut lors du premier lancement du bootstrap, lorsqu’il n’y a encore rien d’autre.

Ils sont la particularité d’avoir une signature faite sur un hash à 512bits.

Gestion du temps dans le lien

Dans le lien, la partie horodatage est constituée de deux parties.

La première partie, nommée MOD, désigne le mode d’exploitation de la marque de temps, c’est à dire sa forme.

La seconde partie, nommée CHR, contient la valeur de la marque de temps proprement dite. Cette valeur doit être interprétée suivant la valeur de MOD.

Tel que cela a déjà été vu avec la précédente forme des liens (Marque de temps, Gestion temporelle partielle, Marque de temps, Horodatage, ISO 8601, suite), la marque de temps peut prendre plusieurs formes. Ces formes peuvent dans certains cas être ambiguë. La partie MOD lève toute ambiguïté. Nous pouvons avoir un compteur, une date simple ou une date exprimée suivant la norme ISO 8601:2004 .

Dans le bootstrap seul est reconnu le mode 0 définissant une maque de temps simple mais adaptée au temps long. Cela donne :

0>020210417223045

Structure de donnés des liens v2:0

  • L : BH_BL_BS
    • BH : RF/RV
      • RF : APP:TYP
        • APP : nebule
        • TYP : link
      • RV : VER:SUB
        • VER : 2
        • SUB : 0
    • BL : RC/RL/RL…
      • RC : MOD>CHR
      • RL : REQ>NID>NID>NID…
        • REQ
        • NID : hash.algo.size
    • BS : RS/RS…
      • RS : NID>SIG
        • EID : hash.algo.size
        • SIG : sign.algo.size

BH_BL_BS

RF/RV_RC/RL/RL_RS/RS

APP:TYP/VER:SUB_MOD>CHR/REQ>NID>NID>NID/REQ>NID>NID>NID_EID>SIG/EID>SIG

nebule:link/2:0_0>020210308124933/l>hash.sha2.256>hash.sha2.256>hash.sha2.256_hash.sha2.256>sign.algo.size/hash.sha2.256>sign.algo.size

Structure

Fichiers

Pour chaque nœud va être associé un certain nombre de liens. Ces liens sont stockés, par nœuds, sous forme de fichiers dans le dossier des liens /l . Dans chaque fichiers, les liens sont séparés par un espace ou un retour chariot. Le retour chariot est à privilégier.

Liens

Chaque liens d’un fichier est composé de :

  • BH (blockhead) : Bloc d’entête.
  • BL (blocklinks) : Bloc de liens.
  • BS (blocksigns) : Bloc de signatures.

Chaque type de bloc est obligatoire et ne doit être présent qu’une seule fois. Lles blocs doivent être ordonnés BH, BL puis BS. Le séparateur inter-blocs est _ . Un lien a donc la forme :

BH_BL_BS

Blocs

Dans chaque bloc on va trouver des registres :

  • RF (regform) : Registre de forme. Bloc BH. Unique. Début.
  • RV (regversion) : Registre de version. Bloc BH. Unique.
  • RC (regchrono) : Registre de chronologie. Bloc BL. Unique. Début.
  • RL (reglink) : Registre du lien. Bloc BL. Multiple.
  • RS (regsign) : Registre de signature. Bloc BS. Multiple.

Les registres sont dédiés à des blocs particuliers. Tous les registres dédiés à un bloc doivent être présents dans le bloc. Certains registres doivent être unique dans leur bloc, d’autres peuvent être multiples. Certains registres sont forcément présent en début de bloc.

La structure des blocs est fixe même si certains registres peuvent être multiples :

  • BH : RF/RV
  • BL : RC/RL/RL/RL…
  • BS : RS/RS/RS…

Le séparateur inter-registres est / .

Registres

Certains registres vont contenir des éléments dans un ordre définit :

  • APP : application. Registre RF. Unique. Début.
  • TYP : type de contenu. Registre RF. Unique.
  • VER : version majeur. Registre RV. Unique. Début.
  • SUB : sous-version. Registre RV. Unique.
  • MOD : mode d’utilisation de la marque chronologique. Registre RC. Unique. Début.
  • CHR : valeur de la marque chronologique. Unique. Registre RC.
  • REQ : requête d’action sur le lien. Registre RL. Unique. Début.
  • NID (Node ID) : identifiant de nÅ“ud (ou de l’objet). Registre RL. Multiple dans RL.
  • EID (Entity ID) : identifiant de l’entité signataire. Registre RS. Unique dans RS. Début dans RS.
  • SIG (sign) : valeur de la signature. Unique. Registre RS.

La structure des registre est fixe même si certains éléments peuvent être multiples :

  • RF : APP:TYP
  • RV : VER:SUB
  • RC : MOD>CHR
  • RL : REQ>NID>NID>NID…
  • RS : EID>SIG

Le séparateur inter-éléments est > ou : en fonction du registre concerné.

Éléments

Les blocs et registres sont structurants de l’information. Les éléments sont contenants de l’information.

  • APP = « nebule ».
  • TYP = « link ».
  • VER = « 2 ».
  • SUB = « 0 ».
  • NID : l’identifiant de nÅ“ud ou d’objet = hash.algo.size
    • hash = valeur de l’empreinte.
    • algo = famille d’algorithme utilisé pour le calcul de l’empreinte.
    • size = taille de l’empreinte
  • EID : l’identifiant de l’entité signataire = hash.algo.size
    • hash = valeur de l’empreinte.
    • algo = famille d’algorithme utilisé pour le calcul de l’empreinte.
    • size = taille de l’empreinte
  • SIG : signature
    • sign = valeur de la signature
    • algo = famille d’algorithme utilisé pour le calcul de l’empreinte avant signature.
    • size = taille de l’empreinte

Vérifications

La vérification d’un lien se fait en trois étapes. La première étape va vérifier que le type et la version sont supportés. La seconde étape va permettre de vérifier la structure complète. La dernière va prendre les blocs BH et BL avec leur séparateur et vérifier la/les signature/s.

L’application qui exploite les liens va garder chaque registre de lien décomposé avec les entités signataires. Les signatures non reconnues seront ignorées.

Limites

Il y a un certains nombre de limites dans les quantités acceptables des registres et éléments que peuvent contenir un lien ainsi que de la taille des contenus. Ces limites ne sont pas définies dans le lien et ne sont pas dépendantes de la version du lien mais dépendent du paramétrage de l’application qui lit le lien.

Graphe des mises à jour – DAG

Comme on l’a vu dans l’article Objet de référence contre suivi du graphe des mises à jours il suffit de suive le graphe des mises à jour d’un objet de code afin de trouver la version la plus récente.

Le graphe orienté acyclique (DAG) permet une optimisation. En ajoutant eu fur et à mesure des mises à jour des liens supplémentaires vers des version beaucoup plus anciennes et pas juste la dernière, on crée des raccourcis dans le graphe et on accélère la recherche de la dernière version. Cependant cet usage doit être modéré afin de ne pas au contraire saturer la recherche de liens inutiles à lire, et à vérifier.

Lien, structure et nomenclature

La structure des liens est en cours de révision. La structure que l’on doit utiliser se doit d’être une représentation d’un arbre le plus équilibré possible afin d’accélérer le traitement et de permettre une réutilisation de code.

La structure de base est répartie en trois parties successives appelées blocs. Le premier est le bloc entête de version qui a pour rôle de définir la façon de traiter l’ensemble. Le second est le bloc des registres de liens. Le dernier est le bloc des signatures. Ces blocs sont obligatoires, sont non interchangeables et sont uniques. Les blocs sont séparés par le caractère _ .

La référence au bloc de la blockchain n’est pas anodine, le second bloc pourra contenir plusieurs liens que l’on pourrait appeler transactions. Il est dans ce cas facile d’ajouter dans ce bloc un lien vers le bloc précédent.

La partie la plus petite de cet arbre est appelée élément. Un élément peut être un identifiant d’objet, un horodatage, un champs action ou un identifiant de version. Cet élément est manipulé directement sans traitement. Il peut cependant être subdivisé soit avec un . soit avec un - . Le premier séparateur sert dans les identifiants d’objets afin de distinguer la valeur de l’empreinte et en extension l’algorithme utilisé.

Ce début de nomenclature n’est cependant pas clôt. L’ensemble des blocs ne peut plus être nommé lien au sens propre du graphe. Et il faut définir la forme du contenu du bloc de liens ainsi que du bloc des signatures.

Graphe et nomenclature

Dans nebule, les liens entre les objets forment ce que l’on nomme un graphe orienté.

Dans les graphes, un lien (ligne ou arête) relie deux objets (nÅ“uds ou points). Dans nebule, les liens relient potentiellement plusieurs objets simultanément. Mais ce n’est pas incompatible avec la théorie. On relie principalement un objet source et un objet destination. L’objet d’opération (ou méta) peut être vu comme une sorte de coloration du lien. Et si un quatrième objet est présent, l’objet de contextualisation, il va surtout servir à réduire les liens que l’on prend en compte à instant donné, c’est plus comme un filtre.

Il ne semble pas opportun de renommer les objets et liens dans nebule. Cependant, il existe des objets un peu particuliers qui n’ont pas de contenu. Leur identifiant n’est pas généré par rapport à un contenu mais est directement généré, souvent aléatoirement. Par construction, ce genre d’objets ne devraient pas pouvoir être rattaché à un contenu. Au pire, même si un contenu était découvert pour l’un de ces objets, n’étant pas attendu il ne devrait pas être utilisé. Ces objets sans contenus par construction seront désormais appelés nÅ“uds. En construisant un identifiant de nÅ“ud qui ne correspond en taille à aucun algorithme de hash, on s’assure qu’il ne sera jamais associé à un contenu. Si la taille de son identifiant correspond à un algorithme de hash, peut-être que ce nÅ“ud est en fait un objet dont on n’a pas eu le contenu.

Séparateurs et horodatage

Il y a deux philosophie de segmentation des données. La première consiste à encadrer les données, par exemple le XML ou le HTML. Chaque texte est encadré. Chaque partie est elle même encadrée. Les parties sont indépendantes et syntaxiquement interchangeables. Les encadrants sont obligatoirement ouverts et fermés. Il est possible de hiérarchiser les informations d’une partie en les plaçant dans des sous-parties incluses dans la partie. Les sous parties peuvent avoir les mêmes encadrants que la partie principale.

La seconde philosophie consiste à séparer les données. On ne délimite plus une donnée mais on marque la fin d’une donnée et donc implicitement le début de la suivante. L’absence de séparateur marque aussi la fin d’une donnée mais dans démarrer une autre donnée. Il existe bien un séparateur dans ce cas aussi mais il marque la fin d’un document… c’est à dire un niveau de données de plus haut niveau. Une hiérarchisation est possible en utilisant plusieurs séparateurs différents.

Cette seconde méthode a des avantages, et pas seulement en place économisée par rapport à des encadrants. Mais elle a comme inconvénient de consommer plus de (caractères) séparateurs.

Dans les liens nebule, la marque de temps à la norme ISO 8601:2004 consomme elle aussi de multiples séparateurs. Il n’est dès lors plus possible de les utiliser comme séparateur au même niveau ou au niveau supérieur. On peut cependant en gagner un, le / de séparation des périodes de temps est invalide pour un lien puisque la marque de temps doit impérativement être ponctuelle. C’est cette marque de temps qui va poser le plus de contraintes sur les séparateurs des liens… sauf à ne pas utiliser cette norme. Éternel débat en fait.

Il reste quand même plusieurs caractères utilisables comme séparateur :
_ / # = * % & @ $ ! ; ~ ( ) { } [ ] < >
Et hors concurrence avec la marque de temps :
- + :

Tout un monde…

P̩rim̬tre fonctionnel bootstrap Рlibpp

Jusque là le bootstrap intégrait une bibliothèque PHP procédurale (libpp) de nebule héritée et remaniée avec le temps mais ayant gardée tout ce qui était fonctionnel.

Or pour le bootstrap certaines fonctionnalités n’ont pas d’utilisé. Et comme il va falloir réécrire et revoir en grande partie cette bibliothèque, c’est le bon moment pour la simplifier. Et on va commencer par supprimer les parties sans utilité.

Au niveau cryptographie, seul la génération et la vérification des liens est utile. Le chiffrement d’objets n’a pas de raison d’être présent. La dissimulation de liens n’a pour l’instant pas d’utilité non plus.

La gestion des attributs d’objets n’a pas d’utilité mais il faut garder la capacité à suivre les mises à jours d’un objet et être capable d’aller chercher des mises à jour. Mais afin de réduire la complexité, seul le HTML sera utilisable.

Les liens supportés seront mono-registre et mono-cœur.

Le travail fait avant par la bibliothèque de nebule en bash permettait de générer un nouveau puppetmaster. Cela va devenir une nouvelle fonction dans le périmètre du bootstrap, et donc de la libpp. Il faut donc conserver la capacité de générer de nouvelles entités et de générer des liens.

Une autre partie qui va être intégrée au bootstrap, c’est la possibilité de faire les mises à jours des applications. Il faut donc que le bootstrap soit capable de parler avec le reste du monde. Seul le HTTP sera pris en compte pour ça. Et cela concerne aussi les entités.

Tout le reste fera partie de la bibliothèque en PHP orienté objet (libpoo).

Structure de liens et RDF

L’étude de la structure de liens à quatre champs objets (quoi quatre champs) crée un parallèle avec la structure du RDF et le bloc des blockchains.

La possibilité de permettre plus de trois champs dans la partie registre du lien crée de nouvelle possibilités certes à la marge mais qui peuvent avoir une utilité. Le premier est d’apporter un contexte à une opération entre source et destination. D’ailleurs, le champ méta devrait s’appeler opérateur. Et comme une opération peut avoir plusieurs contextes possibles le nombre de champs peut dépasser 4. Il faut cependant mettre une limite aux nombres de champs acceptables dans un lien.

signature_signataire_date_action_source_cible_opération_contexte

Mais plutôt que d’ajouter des champs, ou en plus, il est possible de prévoir de gérer deux registres de liens dans un même lien. Voir d’en gérer beaucoup plus. On s’approche là de la mise en forme d’un bloc chère aux crypto-monnaies. Dans cette forme, une partie commune contient la signature et la référence de temps. L’action doit rester associé au cÅ“ur du registre de lien. L’action permet aussi de marque un lien dissimulé et donc de le traiter comme tel. Cela nécessite de modifier la forme du lien

signature_signataire_date/action_source_cible_opération_contexte/action_source_cible_opération_contexte

Sous cette forme nous pouvons rejoindre la forme RDF en permettant la réutilisation de champs par indexation. Par exemple lien second cÅ“ur de lien peut référencer les objets 1 et 2, ou 1 et 4 du premier cÅ“ur de lien. Cela abrège l’écriture, prend moins de place mais complexifie la lecture.

signature_signataire_date/action_source_cible_opération/action_2_1_opération
signature_signataire_date/action_source_cible_opération_contexte/action_1_cible_opération_4

Une autre approche est de mieux délimiter le cÅ“ur de lien afin d’ajouter d’autres informations autour. Il n’y a pas une grande quantité d’information à ajouter, ce peut être de multiples signatures, notamment dans un système de cosignature à seuil. Et, à force d’ajouter des choses dans l’enregistrement des liens, il devient utile de placer une version. Les propriétés exploitables du lien seront directement liées à la version donnée. On arrive ainsi à trois types de blocs dans un lien : la version, les registres de liens et les signatures. Là encore la forme du lien enregistré se complexifie pour permettre de retrouver toutes ces parties sans ambiguïté. Et notamment, chaque partie doit être identifiée avec un préfixe, sauf la version si elle est placé avant le reste. La partie horodatage quand à elle doit aussi faire partie de ce qui est signé, dont elle migre vers les cÅ“urs de liens.

(version)(lien/date_action_source_cible_opération)(lien/date_action_source_cible_opération_contexte/action_1_cible_opération_4)(signe/signature_signataire)(signe/signature_signataire)

Il faut cependant veiller à la défendabilité de la structure ainsi créée. Les signatures sont indépendantes les unes des autres et chaque signature doit couvrir la version et tous les cÅ“urs de liens pris dans le même ordre. Jusque là la vérification des liens se faisait après reconstitution de chaque champs et nettoyage afin d’éviter une tentative de contournement. Ce nettoyage préliminaire peut être maintenu même si il sera plus gourmand en temps de calcul.

Cette forme apporte un nouvel intérêt. Puisque les signatures sont séparée, elles deviennent dissociables. Cela veut dire que l’on peut fusionner plusieurs liens identiques mais avec des signataires différents et donc gagner en place.

Champ action du lien Рaction suppl̩mentaire de transaction

Il était possible de créer une nouvelle action dédiée aux transactions et non annulable, cf l’article Lien de transaction, ce qui aurait nécessité une grosse modification du code de la bibliothèque.

Finalement cette nouvelle action ne sera pas implémentée, il est possible avec la gestion des relations sociales spécifiques à une monnaie de supporter une suppression de transaction par son initiateur mais sans effet de cette suppression si la transaction a déjà été validée par ailleurs.  dans ce cas c’est comme si la transaction marqué par l’utilisateur était une demande de transaction et que celle-ci était validée par une autorité reconnue au niveau de la monnaie.

Application d’authentification et gestion des entités déverrouillables

La gestion des entités déverrouillables sur une instance de serveur est pour l’instant rudimentaire. Toute entité qui réussi à poser une clé publique et une clé privée sur l’instance peut se connecter. Il serait intéressant de pouvoir restreindre ces entités à un groupe connu et alimenté par les autorités locales. Ce groupe pourrait être vu comme un annuaire. On peut imaginer aussi un mécanisme de cooptation. Et on peux imaginer un bannissement sur liste noire même si cette méthode doit être couplée à un autre mécanisme.

Dans la lignée de la réflexion, il pourrait être intéressant de déléguer l’authentification à une application dédiée avec retour à l’application d’origine si ça se passe bien.