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.

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.

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…