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.

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.