[]
 

xcxaro
063a220d87e81cb00e33de890f4fd0a5478a5a543301787cf5d7f30c9c2ad5c2.sha2.256

library
020260116
(c) GNU GPL v3 2010-2026 Project nebule - http://www.nebule.org/

Documentation technique de library
Version 2:0 - 020260116 - develop
(c) GNU GPL v3 2010-2026 Project nebule - http://www.nebule.org/

Table des matières

--


F / Fondations

Le projet nebule est un moteur de gestion d'objets utilisant une combinaison des principes de DHT et de RDF. Cela peut être vu comme une forme de base de donnée graphe orienté de type hypergraphe.

Les objets sont les contenants de tout ce que l'on peut manipuler sous forme numérique. Les objets, tels les sommets d'un graphe, sont liés par des liens, tel les arêtes du graphe. Cette base de données graphe implémente une cryptographie évolutive afin de faire émerger de la confiance dans les objets manipulés. Mais le côté technique n'est pas une fin en soi. La forme des liens permet de faire émerger un côté social, c'est-à-dire du relationnel entre les humains, et permet ainsi d'apporter du sens aux objets et aux liens qui les relient.

--


O / Objet

A revoir...

L'objet est le contenant de toutes les informations.

--


OO / Object

A revoir...

L’objet est un agglomérat de données numériques.

Un objet numérique est identifié par une empreinte ou condensat (hash) numérique de type cryptographique. Cette empreinte est à même d'empêcher la modification du contenu d'un objet, intentionnellement ou non (cf. CO).

--


OOA / Objet virtuel

A revoir...

Un objet virtuel est un objet numérique qui ne contient pas de contenu, et donc pour lequel on ne peut pas associer de contenu. La forme la plus simple de l'objet virtuel est une empreinte aléatoire avec un algorithm de prise d'empreinte valide.

Afin de distinguer les objets virtuels des objets numériques avec contenus pour ne pas faire une recherche de contenu inutile, l'identifiant est généré aléatoirement et est associé à l'algorithme none. Par exemple :

a4b210d4fb820a5b715509e501e36873eb9e27dca1dd591a98a5fc264fd2238adf4b489d.none.288

La taille de l'empreinte aléatoire est cohérente avec le champ de taille avant l'algorithme.

--


OON / Nommage

A revoir...

Le nommage à l’affichage du nom des objets repose sur plusieurs propriétés :

  1. nom
  2. prénom
  3. surnom
  4. préfixe
  5. suffixe

Ces propriétés sont matérialisées par des liens de type l avec comme objets méta, respectivement :

  1. nebule/objet/nom
  2. nebule/objet/prenom
  3. nebule/objet/surnom
  4. nebule/objet/prefix
  5. nebule/objet/suffix

Par convention, voici le nommage des objets pour l’affichage :

prénom préfixe/nom.suffixe surnom

--


OOP / Protection

A revoir...

La protection d'un objet va permettre de cacher le contenu de l'objet.

A faire...

--


OOD / Dissimulation

A revoir...

La dissimulation des liens d'un objet va permettre de cacher la présence ou l'usage d'un objet.

A faire...

--


OOL / Liens

A revoir...

--


OOC / Création

A revoir...

L’objet est identifié par un ID égal à la valeur de son empreinte.

L’indication de la fonction de prise d’empreinte (hashage) est impératif. Elle est défini par le lien :

  • Signature du lien
  • Identifiant du signataire
  • Horodatage
  • action : l
  • nid1 : ID de l’objet
  • nid2 : hash du nom de l’algorithme de prise d’empreinte
  • nid3 : hash(‘nebule/objet/hash’)

Le lien de définition du type est optionnel. Le type est généralement le type mime reconnu de l’objet.

  • Signature du lien
  • Identifiant du signataire
  • Horodatage
  • action : l
  • nid1 : ID de l'objet
  • nid2 : hash(type de l'objet)
  • nid3 : hash(‘nebule/objet/type’)

A faire objets virtuels...

--


OOS / Stockage

A revoir...

Tous les contenus des objets sont stockés dans un même emplacement où sont visibles comme étant dans un même emplacement. Cet emplacement ne contient pas les liens (CF LS).

A faire...

--


OOSA / Arborescence

A revoir...

Sur un système de fichiers, tous les contenus des objets sont stockés dans des fichiers contenus dans le dossier pub/o/ (o comme objet).

A faire...

--


OOT / Transfert

A revoir...

--


OOR / Réservation

A revoir...

Les différents objets réservés pour les besoins de la bibliothèque nebule :

  • nebule/objet
  • nebule/objet/hash
  • nebule/objet/homomorphe
  • nebule/objet/type
  • nebule/objet/localisation
  • nebule/objet/taille
  • nebule/objet/prenom
  • nebule/objet/nom
  • nebule/objet/surnom
  • nebule/objet/prefix
  • nebule/objet/suffix
  • nebule/objet/lien
  • nebule/objet/date
  • nebule/objet/date/annee
  • nebule/objet/date/mois
  • nebule/objet/date/jour
  • nebule/objet/date/heure
  • nebule/objet/date/minute
  • nebule/objet/date/seconde
  • nebule/objet/date/zone
  • nebule/objet/entite
  • nebule/objet/entite/type
  • nebule/objet/entite/localisation
  • nebule/objet/entite/suivi
  • nebule/objet/entite/suivi/seconde
  • nebule/objet/entite/suivi/minute
  • nebule/objet/entite/suivi/heure
  • nebule/objet/entite/suivi/jour
  • nebule/objet/entite/suivi/mois
  • nebule/objet/entite/suivi/annee
  • nebule/objet/entite/maitre
  • nebule/objet/entite/maitre/securite
  • nebule/objet/entite/maitre/code
  • nebule/objet/entite/maitre/annuaire
  • nebule/objet/entite/maitre/temps
  • nebule/objet/entite/autorite/locale
  • nebule/objet/entite/recouvrement
  • nebule/objet/interface/web/php/bootstrap
  • nebule/objet/interface/web/php/bibliotheque
  • nebule/objet/interface/web/php/applications
  • nebule/objet/interface/web/php/applications/direct
  • nebule/objet/interface/web/php/applications/active
  • nebule/objet/noeud
  • nebule/objet/image/reference
  • nebule/objet/emotion
  • nebule/objet/emotion/joie
  • nebule/objet/emotion/confiance
  • nebule/objet/emotion/peur
  • nebule/objet/emotion/surprise
  • nebule/objet/emotion/tristesse
  • nebule/objet/emotion/degout
  • nebule/objet/emotion/colere
  • nebule/objet/emotion/interet
  • nebule/objet/groupe
  • nebule/objet/groupe/suivi
  • nebule/objet/groupe/ferme
  • nebule/objet/groupe/protege
  • nebule/objet/groupe/dissimule
  • nebule/objet/conversation
  • nebule/objet/conversation/suivie
  • nebule/objet/conversation/fermee
  • nebule/objet/conversation/protegee
  • nebule/objet/conversation/dissimulee
  • nebule/objet/arborescence
  • nebule/objet/monnaie
  • nebule/objet/monnaie/jeton
  • nebule/objet/monnaie/sac
  • nebule/objet/monnaie/portefeuille
  • nebule/objet/monnaie/transaction
  • nebule/option
  • nebule/reference
  • nebule/danger
  • nebule/warning

Les objets réservés périmés :

  • nebule/objet/entite/web
  • nebule/objet/entite/web/applications

--


OOI / Implémentation

--


OOIO / Implémentation des Options

A revoir...

--


OOIA / Implémentation des Actions

A revoir...

--


OOV / Vérification

A revoir...

L’empreinte d’un objet doit être vérifiée lors de la fin de la réception de l’objet. L’empreinte d’un objet devrait être vérifiée avant chaque utilisation de cet objet. Un contenu d'objet avec une empreinte qui ne lui correspond pas doit être supprimé. Lors de la suppression d’un objet, les liens de cet objet ne sont pas supprimés. La vérification de la validité des liens est complètement indépendante de celle des objets, et inversement (CF CO et LV).

A faire, sauf objet virtuel...

--


OOO / Oubli

A revoir...

L'oubli volontaire de certains liens et objets n'est encore ni théorisé ni implémenté, mais deviendra indispensable lorsque l'espace viendra à manquer (CF CN).

--


OR / Référence

A revoir...

--


ORN / Nommage

A revoir...

--


ORP / Protection

A revoir...

--


ORD / Dissimulation

A revoir...

--


ORL / Liens

A revoir...

--


ORC / Création

A revoir...

Liste des liens à générer lors de la création d'une entité.

A faire...

--


ORS / Stockage

A revoir...

Voir OOS, pas de particularité de stockage.

--


ORT / Transfert

A revoir...

--


ORR / Réservation

A revoir...

--


ORI / Implémentation

--


ORIO / Implémentation des Options

A revoir...

--


ORIA / Implémentation des Actions

A revoir...

--


ORO / Oubli

A revoir...

L'oubli volontaire de certains liens et objets n'est encore ni théorisé ni implémenté, mais deviendra indispensable lorsque l'espace viendra à manquer (CF CN).

--


OG / Groupe

Le groupe en tant que tel est défini comme un objet (cf. OO), c'est-à-dire qu’il doit avoir un type mime nebule/objet/type de groupe nebule/objet/groupe.

Fondamentalement, le groupe est un ensemble de plusieurs objets. C'est-à-dire, c’est le regroupement d’au moins deux objets. Le lien peut donc à ce titre être vu comme la matérialisation d’un groupe. Mais la définition du groupe doit être plus restrictive afin que celui-ci soit utilisable. Pour cela, dans nebule, le groupe n’est reconnu comme tel uniquement s'il est marqué de son type mime. Il est cependant possible d’instancier explicitement un objet comme groupe et de l’utiliser comme tel en cas de besoin.

Le groupe va permettre de regrouper, et donc d’associer et de retrouver, des objets. L’objet du groupe va avoir des liens vers d’autres objets afin de les définir comme membres du groupe.

Il est possible de typer un groupe dans le lien de définition en positionnant le NID4 avec un NID ou RID dont le traitement spécifique est laissé à la main des applications. C'est de cette façon que sont gérés les conversations et les groupes d'entités.

Un groupe peut avoir des liens de membres vers des objets définis aussi comme groupes. Ces objets peuvent être vus comme des sous-groupes. La bibliothèque nebule ne prend en compte qu’un seul niveau de groupe, c'est-à-dire que les sous-groupes sont gérés simplement comme des objets.

Lors de la suppression d'un groupe, c’est uniquement un affichage du groupe et non la suppression des membres du groupe.

--


OGO / Objet

L’objet du groupe peut être de deux natures.

Soit c’est un objet existant qui est en plus définit comme un groupe. L’objet peut avoir un contenu et a sûrement d’autres types mime propres. Dans ce cas l’identifiant de groupe est l’identifiant de l’objet utilisé.

Soit c’est un objet dit virtuel qui n’a pas et n’aura jamais de contenu. Cela n’empêche pas qu’il puisse avoir d’autres types mime. Dans ce cas l’identifiant de groupe a une forme commune aux objets virtuels (cf. OOA).

--


OGN / Nommage

Le nommage à l’affichage du nom des groupes repose sur une seule propriété :

  1. nom

Cette propriété est matérialisée par un lien de type l avec comme objets nid3 :

  1. nebule/objet/nom

Par convention, voici le nommage des groupes :

  • nom

--


OGP / Protection

En tant que tel le groupe ne nécessite pas de protection puisque soit l’objet du groupe n’a pas de contenu soit on n’utilise pas son contenu directement.

La gestion de la protection est désactivée dans une instance de groupe.

--


OGD / Dissimulation

Le groupe peut en tant que tel être dissimulé, c'est-à-dire que l’on dissimule l’existence du groupe, donc sa création.

La dissimulation devrait se faire lors de la création du groupe.

L’annulation de la dissimulation d’un groupe revient à révéler le lien de création du groupe.

La dissimulation peut se (re)faire après la création du groupe, mais son efficacité est incertaine si les liens de création ont déjà été diffusés. En cas de dissimulation à posteriori, il faut générer un lien de suppression du groupe puis générer un nouveau lien dissimulé de création du groupe à une date postérieure au lien de suppression.

--


OGF / Fermeture

Le groupe va contenir un certain nombre de membres ajoutés par différentes entités. Il est possible de limiter le nombre des membres à utiliser dans un groupe en restreignant artificiellement les entités contributrices du groupe. Ainsi, on marque le groupe comme fermé et cela filtre, par exemple les messages d'une conversation, uniquement sur les membres que l'on a ajoutés.

Lorsqu'un groupe n'est pas marqué fermé, il est dit ouvert. Dans ce cas, on voit avec le groupe tous les objets ajoutés par toutes les entités que l'on peut vérifier.

Lorsque l’on a marqué un groupe comme fermé, on doit explicitement ajouter des entités que l’on veut voir contribuer.

Il est possible indéfiniment de fermer et ouvrir un groupe.

Il est possible de fermer un groupe qui ne nous appartient pas afin par exemple de le rendre plus lisible.

Lorsque l’on a marqué un groupe comme fermé, on peut voir la liste des entités explicitement que l’on veut voir contribuer. On peut aussi voir les entités que les autres entités veulent voir contribuer et décider ou non de les ajouter.

Dans nebule, l’objet réservé nebule/objet/groupe/ferme est dédié à la gestion des groupes fermés. Un groupe est considéré comme fermé quand on a l’objet réservé en champs nid3, l’entité en cours en champs nid2 et le NID du groupe en champs nid1. Si au lieu d’utiliser l’entité en cours pour le champ nid2, on utilise une autre entité, cela revient à prendre aussi en compte ses liens dans le groupe fermé. Dans ce cas, c’est une entité reconnue contributrice.

Lorsqu’un groupe est marqué comme fermé, l’interface de visualisation du groupe peut permettre de le visualiser temporairement comme un groupe ouvert.

Le traitement des liens de fermeture d’un groupe doit être fait exclusivement avec le traitement social self.

--


OGM / Membres

--


OGMT / Membres typés

A revoir...

--


OGMP / Protection des membres

A revoir...

Le groupe va contenir un certain nombre de membres ajoutés par différentes entités. Il est possible de limiter la visibilité du contenu des membres utilisés dans un groupe en restreignant artificiellement les entités destinataires qui pourront les consulter.

Dans nebule, l’objet réservé nebule/objet/groupe/protege est dédié à la gestion des groupes protégés. Un groupe est considéré protégé quand on a l’objet réservé en champs méta, l’entité en cours en champs cible et l’ID du groupe en champs source. Si au lieu d’utiliser l’entité en cours pour le champ cible, on utilise une autre entité, cela revient à partager aussi les objets protégés créés pour ce groupe. Cela ne repartage pas la protection des objets déjà protégés.

Dans un groupe marqué protégé, tous les nouveaux membres ajoutés au groupe ont leur contenu protégé. Ce n’est valable que pour l’entité en cours et éventuellement celles qui lui font confiance.

Lorsque l’on a marqué un groupe comme protégé, on doit explicitement ajouter des entités avec qui on veut partager les contenus.

Il est possible indéfiniment de protéger et déprotéger un groupe.

Il est possible de protéger un groupe qui ne nous appartient afin de masquer le contenu des membres que l’on y ajoute.

Lorsque l’on a marqué un groupe comme protégé, on peut voir la liste des entités explicitement a qui on veut partager les contenus. On peut aussi voir les entités a qui les autres entités veulent partager les contenus et décider ou non de les ajouter.

Le traitement des liens de protection d’un groupe doit être fait exclusivement avec le traitement social self.

--


OGMD / Dissimulation des membres

A revoir...

Le groupe va contenir un certain nombre de membres ajoutés par différentes entités. Il est possible de limiter la visibilité de l’appartenance des membres utilisés dans un groupe en restreignant artificiellement les entités destinataires qui pourront les voir.

Dans nebule, l’objet réservé nebule/objet/groupe/dissimule est dédié à la gestion des groupes dissimulés. Un groupe est considéré comme dissimulé quand on a l’objet réservé en champs méta, l’entité en cours en champs cible et l’ID du groupe en champs source. Si au lieu d’utiliser l’entité en cours pour le champ cible, on utilise une autre entité, cela revient à partager aussi les objets dissimulés créés pour ce groupe. Cela ne repartage pas la dissimulation des objets déjà dissimulés.

Dans un groupe marqué dissimulé, tous les nouveaux membres ajoutés au groupe sont dissimulés. Ce n’est valable que pour l’entité en cours et éventuellement celles qui lui font confiance.

Lorsque l’on a marqué un groupe comme dissimulé, on doit explicitement ajouter des entités avec qui on veut partager les membres du groupe.

Il est possible indéfiniment de dissimuler et dé dissimuler un groupe.

Il est possible de dissimuler un groupe qui ne nous appartient afin de masquer le contenu des membres que l’on y ajoute.

Lorsque l’on a marqué un groupe comme dissimulé, on peut voir la liste des entités explicitement a qui on veut partager les contenus. On peut aussi voir les entités a qui les autres entités veulent partager les contenus et décider ou non de les ajouter.

Le traitement des liens de dissimulation d’un groupe doit être fait exclusivement avec le traitement social self.

--


OGA / Abonnés

--


OGAP / Protection des abonnés

A revoir...

--


OGAD / Dissimulation des abonnés

A revoir...

--


OGL / Liens

A revoir...

Une entité doit être déverrouillée pour la création de liens.

  • Le lien de définition du groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID du groupe
    • nid2 : hash(‘nebule/objet/groupe’)
    • nid3 : hash(‘nebule/objet/type’)
  • Le lien de suppression d’un groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • nid1 : ID du groupe
    • nid2 : hash(‘nebule/objet/groupe’)
    • nid3 : hash(‘nebule/objet/type’)
  • Le lien de suivi du groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID de l'entité, par défaut l’entité signataire
    • nid2 : ID du groupe
    • nid3 : hash(‘nebule/objet/groupe/suivi’)
  • Le lien de suppression de suivi du groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • nid1 : ID de l'entité, par défaut l’entité signataire
    • nid2 : ID du groupe
    • nid3 : hash(‘nebule/objet/groupe/suivi’)
  • Le lien de dissimulation d’un groupe est le lien de définition caché dans un lien de type c.
  • Le lien de rattachement non typé d’un membre du groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : f
    • nid1 : ID du groupe
    • nid2 : ID de l’objet
    • nid3 : ID du groupe
  • Le lien de suppression de rattachement non typé d’un membre du groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • nid1 : ID du groupe
    • nid2 : ID de l’objet
    • nid3 : ID du groupe
  • Le lien de rattachement typé d’un membre du groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : f
    • nid1 : ID du groupe
    • nid2 : ID de l’objet
    • nid3 : ID de typage
  • Le lien de suppression de rattachement typé d’un membre du groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • nid1 : ID du groupe
    • nid2 : ID de l’objet
    • nid3 : ID de typage
  • Le lien de fermeture d’un groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID du groupe
    • nid2 : ID de l’entité, par défaut l’entité signataire
    • nid3 : hash(‘nebule/objet/groupe/ferme’)
  • Le lien de suppression de fermeture d’un groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • nid1 : ID du groupe
    • nid2 : ID de l’entité, par défaut l’entité signataire
    • nid3 : hash(‘nebule/objet/groupe/ferme’)
  • Le lien de protection des membres d’un groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID du groupe
    • nid2 : ID de l’entité, par défaut l’entité signataire
    • nid3 : hash(‘nebule/objet/groupe/protege’)
  • Le lien de suppression de protection des membres d’un groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • nid1 : ID du groupe
    • nid2 : ID de l’entité, par défaut l’entité signataire
    • nid3 : hash(‘nebule/objet/groupe/protege’)
  • Le lien de dissimulation des membres d’un groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID du groupe
    • nid2 : ID de l’entité, par défaut l’entité signataire
    • nid3 : hash(‘nebule/objet/groupe/dissimule’)
  • Le lien de suppression de dissimulation des membres d’un groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • nid1 : ID du groupe
    • nid2 : ID de l’entité, par défaut l’entité signataire
    • nid3 : hash(‘nebule/objet/groupe/dissimule’)

--


OGC / Création

A revoir...

Liste des liens à générer lors de la création d'un groupe :

  • Le lien de définition du groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID du groupe
    • nid2 : hash(‘nebule/objet/groupe’)
    • nid3 : hash(‘nebule/objet/type’)
  • Le lien de nommage du groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID du groupe
    • nid2 : hash(nom du groupe)
    • nid3 : hash(‘nebule/objet/nom’)
  • Le lien de suivi du groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID de l'entité, par défaut l’entité signataire
    • nid2 : ID du groupe
    • nid3 : hash(‘nebule/objet/groupe/suivi’)

On peut aussi au besoin ajouter ces liens :

  • Le lien de fermeture d’un groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID du groupe
    • nid2 : ID de l’entité, par défaut l’entité signataire
    • nid3 : hash(‘nebule/objet/groupe/ferme’)
  • Le lien de protection des membres d’un groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID du groupe
    • nid2 : ID de l’entité, par défaut l’entité signataire
    • nid3 : hash(‘nebule/objet/groupe/protege’)
  • Le lien de dissimulation des membres d’un groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID du groupe
    • nid2 : ID de l’entité, par défaut l’entité signataire
    • nid3 : hash(‘nebule/objet/groupe/dissimule’)

--


OGS / Stockage

A revoir...

Voir OOS, pas de particularité de stockage.

--


OGT / Transfert

A revoir...

--


OGR / Réservation

A revoir...

Les objets réservés spécifiquement pour les groupes :

  • nebule/objet/groupe
  • nebule/objet/groupe/ferme
  • nebule/objet/groupe/protege
  • nebule/objet/groupe/dissimule

--


OGI / Implémentation

--


OGIO / Implémentation des Options

A revoir...

Les options spécifiques aux groupes :

  • permitWriteGroup : permet toute écriture de groupes.

Les options qui ont une influence sur les groupes :

  • permitWrite : permet toute écriture d’objets et de liens ;
  • permitWriteObject : permet toute écriture d’objets ;
  • permitCreateObject : permet la création locale d’objets ;
  • permitWriteLink : permet toute écriture de liens ;
  • permitCreateLink : permet la création locale de liens.

Il est nécessaire à la création d’un groupe de pouvoir écrire des objets comme le nom du groupe, même si l’objet du groupe ne sera pas créé.

--


OGIA / Implémentation des Actions

A revoir...

Dans les actions, on retrouve les chaînes :

  • creagrp : Crée un groupe.
  • creagrpnam : Nomme le groupe à créer.
  • creagrpcld : Marque fermé le groupe à créer.
  • creagrpobf : Dissimule les liens du groupe à créer.
  • actdelgrp : Supprime un groupe.
  • actaddtogrp : Ajoute l’objet courant membre à groupe.
  • actremtogrp : Retire l’objet courant membre d’un groupe.
  • actadditogrp : Ajoute un objet membre au groupe courant.
  • actremitogrp : Retire un objet membre du groupe courant.

--


OE / Entité

L’entité est un objet caractéristique. Elle dispose de :

  • Une clé cryptographique publique par laquelle elle est identifiée ;
  • Une ou plusieurs clés cryptographiques privées par lesquelles elle peut générer des liens (actions) et manipuler des données chiffrées (encrypted) et dissimulées (obfuscated).

Une entité déverrouillée est appelée entité connectée. Le déverrouillage d'une entité est techniquement le déverrouillage de la valeur de sa clé cryptographique privée.

L’indication de la fonction de prise d’empreinte (hash) ainsi que le type de biclé cryptographique sont impératifs. Le lien est identique à celui défini pour un objet.

Pour l'instant, seul le type RSA est supporté, mais à l'avenir tout mécanisme de chiffrement asymétrique pourra être supporté.

Le type mime mime-type:application/x-pem-file est suffisant pour indiquer que cet objet est une entité. Des valeurs équivalentes pourront être définies ultérieurement.

Toutes les autres indications sont optionnelles.

--


OEA / Types d'entités

La bibliothèque distingue plusieurs niveaux d'entités :

  1. Objet entité : C'est un objet auquel on donne des caractéristiques de visualisation propres à une entité. Cela permet de manipuler des entités comme des objets, mais avec des actions spécifiques.
  2. Entité courante : Cela désigne l'objet entité que l'on est en train d'observer.
  3. Entité serveur : C'est l'entité de l'instance du serveur sur lequel tourne le code.
  4. Entité par défaut : Lorsque l'on se connecte sur un serveur, c'est l'entité fantôme qui va être utilisée par défaut en place de l'entité serveur. Elle peut être changée avec l'option defaultEntity.
  5. Entité fantôme : Cette façon de désigner une entité permet de voir son empreinte, c'est se mettre à sa place en termes de point de vue. Le fantôme (ghost) est une référence à l'insufflation d'une âme dans une coquille vide pour lui donner vie. Cependant, ce n'est pas encore une entité connectée.
  6. Entité connectée : Depuis une entité fantôme, lorsque l'on déverrouille la valeur de sa clé cryptographique privée, généralement avec un mot de passe, on permet à cette entité de générer des liens et manipuler des données chiffrées et dissimulées.
  7. Entité maîtresse : C'est une entité spéciale, dite autorité globale ou locale, avec des rôles importants prédéfinis par la bibliothèque.

--


OEM / Entités Maîtresses

La bibliothèque utilise actuellement plusieurs entités spéciales, dites autorités maîtresses, avec des rôles prédéfinis :

  1. Maître du tout. L'instance actuelle s'appelle puppetmaster. Voir CAM.
  2. Maître de la sécurité. L'instance actuelle s'appelle cerberus. Voir CAMS.
  3. Maître du code. L'instance actuelle s'appelle bachue. Voir CAMC.
  4. Maître de l'annuaire. L'instance actuelle s'appelle asabiyya. Voir CAMA.
  5. Maître du temps. L'instance actuelle s'appelle kronos. Voir CAMT.

Pour chaque catégorie, il peut y avoir plusieurs entités concurrentes reconnues simultanément. Actuellement seul un maître du tout est géré à la fois.

Il est possible de déléguer des droits supplémentaires à des entités locales. L'entité serveur peut devenir autorité locale avec l'option permitServerEntityAsAuthority. L'entité par défaut peut devenir autorité locale avec l'option permitDefaultEntityAsAuthority.

--


OEN / Nommage

Le nommage à l’affichage du nom des entités repose sur plusieurs propriétés :

  1. nom
  2. prénom
  3. surnom
  4. préfixe
  5. suffixe

Ces propriétés sont matérialisées par des liens de type l avec comme objets méta, respectivement :

  1. nebule/objet/nom
  2. nebule/objet/prenom
  3. nebule/objet/surnom
  4. nebule/objet/prefix
  5. nebule/objet/suffix

Par convention, voici le nommage des entités :

préfixe prénom "surnom" nom suffixe

--


OEP / Protection

La protection d'une entité n'est pas supportée.

Cependant, à l'avenir, il serait possible d'avoir une entité fille protégée par une entité principale. Dans ce cas l'entité fille ne pourrait être manipulée qu'une fois l'entité principale déverrouillée.

--


OED / Dissimulation

La dissimulation de liens n'est pas supportée.

--


OEL / Liens

A revoir...

--


OEC / Création

A revoir...

La première étape consiste en la génération d’une biclé (public/privé) cryptographique. Cette biclé peut être de type RSA ou équivalent. Aujourd’hui, seul RSA est reconnu.

On extrait la clé publique de la biclé. Le calcul de l’empreinte cryptographique de la clé publique donne l’identifiant de l’entité. On écrit dans les objets (o/*) l’objet avec comme contenu la clé publique et comme id son empreinte cryptographique.

On extrait la clé privée de la biclé. Il est fortement conseillé lors de l’extraction de protéger tout de suite la clé privée avec un mot de passe. On écrit dans les objets (o/*) l’objet avec comme contenu la clé privée et comme id son empreinte cryptographique (différente de celle de la clé publique).

À partir de maintenant, la biclé n’est plus nécessaire. Il faut le supprimer avec un effacement sécurisé.

Pour que l’objet soit reconnu comme entité, il faut créer les liens correspondants.

  • Lien 1 :
    • Lien de type l
    • Identifiant de la clé publique
    • Empreinte de ‘application/x-pem-file’
    • Empreinte de ‘nebule/objet/type’
  • Lien 2 :
    • Lien de type l
    • Identifiant de la clé privée
    • Empreinte de ‘application/x-pem-file’
    • Empreinte de ‘nebule/objet/type’
  • Lien 3 :
    • Lien de type f ;
    • Identifiant de la clé privée
    • Identifiant de la clé publique
    • Empreinte de ‘nebule/objet/entite/prive’.

C’est le minimum vital pour une entité. Ensuite, d’autres propriétés peuvent être ajoutées à l’entité (id clé publique) comme son nom, son type, etc…

Si le mot de passe de la clé privée est défini par l’utilisateur demandeur de la nouvelle entité, il faut supprimer ce mot de passe avec un effacement sécurisé.

Si le mot de passe de la clé privée a été généré, donc que la nouvelle entité est esclave d’une entité maître, le mot de passe doit être stocké dans un objet chiffré pour l’entité maître. Et il faut générer un lien reliant l’objet de mot de passe à la clé privée de la nouvelle entité.

--


OES / Stockage

A revoir...

Voir OOS, pas de particularité de stockage.

--


OET / Transfert

A revoir...

--


OER / Réservation

A revoir...

--


OEI / Implémentation

--


OEIO / Implémentation des Options

A revoir...

--


OEIA / Implémentation des Actions

A revoir...

--


OEO / Oubli

A revoir...

L'oubli vonlontaire de certains liens et objets n'est encore ni théorisé ni implémenté, mais deviendra indispensable lorsque l'espace viendra à manquer (cf CN).

--


OL / Localisation

A revoir...

Une localisation permet de trouver l’emplacement des objets et liens générés par une entité.

Un emplacement n’a de sens que pour une entité.

Une entité peut disposer de plusieurs localisations. Il faut considérer que toute entité qui héberge l’objet d’une autre entité devient de fait une localisation valide même si cela n’est pas explicitement définit.

--


OLN / Nommage

A revoir...

--


OLP / Protection

A revoir...

--


OLD / Dissimulation

A revoir...

--


OLL / Liens

A revoir...

--


OLC / Création

A revoir...

Liste des liens à générer lors de la création d'une localisation.

A faire...

--


OLS / Stockage

A revoir...

Voir OOS, pas de particularité de stockage.

--


OLT / Transfert

A revoir...

--


OLR / Réservation

A revoir...

--


OLIO / Implémentation des Options

A revoir...

--


OLIA / Implémentation des Actions

A revoir...

--


OC / Conversation

En tant que tel, la conversation est un objet, c'est-à-dire qu’elle doit avoir un type mime nebule/objet/conversation.

Fondamentalement, la conversation est un groupe de plusieurs objets et est donc géré de la même façon qu'un groupe. Ainsi, un membre de la conversation n'est pas une entité, mais un message, une entité est dite entité contributrice. Certains liens générés sont communs avec ceux des groupes et si un objet est marqué comme groupe et conversation, ses membres seront les mêmes.

La conversation va permettre de regrouper, et donc d’associer et de retrouver, des messages. L’objet de la conversation va avoir des liens vers d’autres objets afin de les définir comme messages (membres) de la conversation.

Une conversation peut avoir des liens de membres vers des objets définis aussi comme conversations. Ces objets peuvent être vus comme des sous-conversations. La bibliothèque nebule ne prend en compte qu’un seul niveau de conversation, c'est-à-dire que les sous-conversations sont gérés simplement comme des objets.

--


OCO / Objet

L’objet de la conversation peut être de deux natures.

Soit c’est un objet existant qui est en plus définit comme une conversation. L’objet peut avoir un contenu et a sûrement d’autres types mime propres. Dans ce cas l’identifiant de conversation est l’identifiant de l’objet utilisé.

Soit c’est un objet dit virtuel qui n’a pas et n’aura jamais de contenu. Cela n’empêche pas qu’il puisse avoir d’autres types mime. Dans ce cas l’identifiant de conversation a une forme commune aux objets virtuels.

La création d’un objet virtuel comme conversation se fait en créant pour identifiant la concaténation d’un hash (sha256) d’une valeur aléatoire de 128bits et de la chaîne 006e6562756c652f6f626a65742f636f6e766572736174696f6e. Soit un identifiant complet de la taille de 116 caractères.

--


OCN / Nommage

Le nommage à l’affichage du nom des conversations repose sur une seule propriété :

  1. nom

Cette propriété est matérialisée par un lien de type l avec comme objets nid3 :

  1. nebule/objet/nom

Par convention, voici le nommage des conversations :

  • nom

--


OCP / Protection

En tant que tel la conversation ne nécessite pas de protection puisque soit l’objet de la conversation n’a pas de contenu soit on n’utilise pas son contenu directement.

La gestion de la protection est désactivée dans une instance de conversation.

--


OCD / Dissimulation

La conversation peut en tant que tel être dissimulée, c'est-à-dire que l’on dissimule l’existence de la conversation, donc sa création.

La dissimulation devrait se faire lors de la création de la conversation.

L’annulation de la dissimulation d’une conversation revient à révéler le lien de création de la conversation.

La dissimulation peut se (re)faire après la création de la conversation mais son efficacité est incertaine si les liens de création ont déjà été diffusés. En cas de dissimulation à posteriori, il faut générer un lien de suppression de la conversation puis générer un nouveau lien dissimulée de création de la conversation à une date postérieure au lien de suppression.

--


OCF / Fermeture

La conversation va contenir un certain nombre de membres (messages) ajouter par différentes entités. Il est possible de limiter le nombre des membres à utiliser dans une conversation en restreignant artificiellement les entités contributrices de la conversation. Ainsi, on marque la conversation comme fermée et on filtre sur les membres uniquement ajoutés par des entités définies.

Dans nebule, l’objet réservé nebule/objet/conversation/fermee est dédié à la gestion des conversations fermées. Une conversation est considéré fermée quand on a l’objet réservé en champs méta, l’entité en cours en champs cible et l’ID de la conversation en champs source. Si au lieu d’utiliser l’entité en cours pour le champ cible on utilise une autre entité, cela revient à prendre aussi en compte ses liens dans la conversation fermée. Dans ce cas c’est une entité contributrice.

C’est uniquement un affichage de la conversation que l’on a et non la suppression de membres de la conversation.

Lorsque l’on a marqué une conversation comme fermée, on doit explicitement ajouter des entités que l’on veut voir contribuer.

Il est possible indéfiniment de fermer et ouvrir une conversation.

Il est possible de fermer une conversation qui ne nous appartient afin par exemple de la rendre plus lisible.

Lorsque l’on a marqué une conversation comme fermée, on peut voir la liste des entités explicitement que l’on veut voir contribuer. On peut aussi voir les entités que les autres entités veulent voir contribuer et décider ou non de les ajouter.

Lorsqu’une conversation est marqué comme fermée, l’interface de visualisation de la conversation peut permettre de la visualiser temporairement comme une conversation ouvert.

Le traitement des liens de fermeture d’une conversation doit être fait exclusivement avec le traitement social self.

--


OCPM / Protection des membres

La conversation va contenir un certain nombre de membres (messages) ajouter par différentes entités. Il est possible de limiter la visibilité du contenu des membres utilisés dans une conversation en restreignant artificiellement les entités destinataires qui pourront les consulter.

Dans nebule, l’objet réservé nebule/objet/conversation/protegee est dédié à la gestion des conversations protégées. Une conversation est considéré protégée quand on a l’objet réservé en champs méta, l’entité en cours en champs cible et l’ID de la conversation en champs source. Si au lieu d’utiliser l’entité en cours pour le champs cible on utilise une autre entité, cela revient à partager aussi les objets protégées créés pour cette conversation. Cela ne repartage pas la protection des objets déjà protégés.

Dans une conversation marqué protégée, tous les nouveaux membres ajoutés à la conversation ont leur contenu protégé. Ce n’est valable que pour l’entité en cours et éventuellement celles qui lui font confiance.

Lorsque l’on a marqué une conversation comme protégée, on doit explicitement ajouter des entités avec qui on veut partager les contenus.

Il est possible indéfiniment de protéger et déprotéger une conversation.

Il est possible de protéger une conversation qui ne nous appartient afin de masquer le contenu des membres que l’on y ajoute.

Lorsque l’on a marqué une conversation comme protégée, on peut voir la liste des entités explicitement a qui on veut partager les contenus. On peut aussi voir les entités a qui les autres entités veulent partager les contenus et décider ou non de les ajouter.

Le traitement des liens de protection d’une conversation doit être fait exclusivement avec le traitement social self.

--


OCDM / Dissimulation des membres

La conversation va contenir un certain nombre de membres (messages) ajouter par différentes entités. Il est possible de limiter la visibilité de l’appartenance des membres utilisés dans une conversation en restreignant artificiellement les entités destinataires qui pourront les voir.

Dans nebule, l’objet réservé nebule/objet/conversation/dissimulee est dédié à la gestion des conversations dissimulées. Une conversation est considéré dissimulée quand on a l’objet réservé en champs méta, l’entité en cours en champs cible et l’ID de la conversation en champs source. Si au lieu d’utiliser l’entité en cours pour le champs cible on utilise une autre entité, cela revient à partager aussi les objets dissimulées créés pour cette conversation. Cela ne repartage pas la dissimulation des objets déjà dissimulés.

Dans une conversation marqué dissimulée, tous les nouveaux membres ajoutés à la conversation sont dissimulés. Ce n’est valable que pour l’entité en cours et éventuellement celles qui lui font confiance.

Lorsque l’on a marqué une conversation comme dissimulée, on doit explicitement ajouter des entités avec qui on veut partager les membres de la conversation.

Il est possible indéfiniment de dissimuler et dé-dissimuler une conversation.

Il est possible de dissimuler une conversation qui ne nous appartient afin de masquer le contenu des membres que l’on y ajoute.

Lorsque l’on a marqué une conversation comme dissimulée, on peut voir la liste des entités explicitement a qui on veut partager les contenus. On peut aussi voir les entités a qui les autres entités veulent partager les contenus et décider ou non de les ajouter.

Le traitement des liens de dissimulation d’une conversation doit être fait exclusivement avec le traitement social self.

--


OCL / Liens

Une entité doit être déverrouillée pour la création de liens.

  • Le lien de définition de la conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID de la conversation
    • nid2 : hash(‘nebule/objet/conversation’)
    • nid3 : hash(‘nebule/objet/type’)
  • Le lien de suppression d’une conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • nid1 : ID de la conversation
    • nid2 : hash(‘nebule/objet/conversation’)
    • nid3 : hash(‘nebule/objet/type’)
  • Le lien de suivi de la conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID de l'entité, par défaut l’entité signataire
    • nid2 : ID de la conversation
    • nid3 : hash(‘nebule/objet/conversation/suivie’)
  • Le lien de suppression de suivi de la conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • nid1 : ID de l'entité, par défaut l’entité signataire
    • nid2 : ID de la conversation
    • nid3 : hash(‘nebule/objet/conversation/suivie’)
  • Le lien de dissimulation d’une conversation est le lien de définition caché dans une lien de type c.
  • Le lien de rattachement d’un membre (message) de la conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID de la conversation
    • nid2 : ID de l’objet
    • nid3 : ID de la conversation
  • Le lien de suppression de rattachement d’un membre (message) de la conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • nid1 : ID de la conversation
    • nid2 : ID de l’objet
    • nid3 : ID de la conversation
  • Le lien de fermeture d’une conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID de la conversation
    • nid2 : ID de l’entité, par défaut l’entité signataire.
    • nid3 : hash(‘nebule/objet/conversation/fermee’)
  • Le lien de suppression de fermeture d’une conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • nid1 : ID de la conversation
    • nid2 : ID de l’entité, par défaut l’entité signataire.
    • nid3 : hash(‘nebule/objet/conversation/fermee’)
  • Le lien de protection des membres d’une conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID de la conversation
    • nid2 : ID de l’entité, par défaut l’entité signataire.
    • nid3 : hash(‘nebule/objet/conversation/protegee’)
  • Le lien de suppression de protection des membres d’une conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • nid1 : ID de la conversation
    • nid2 : ID de l’entité, par défaut l’entité signataire.
    • nid3 : hash(‘nebule/objet/conversation/protegee’)
  • Le lien de dissimulation des membres d’une conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID de la conversation
    • nid2 : ID de l’entité, par défaut l’entité signataire.
    • nid3 : hash(‘nebule/objet/conversation/dissimulee’)
  • Le lien de suppression de dissimulation des membres d’une conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • nid1 : ID de la conversation
    • nid2 : ID de l’entité, par défaut l’entité signataire.
    • nid3 : hash(‘nebule/objet/conversation/dissimulee’)

--


OCC / Création

Liste des liens à générer lors de la création d'une conversation :

  • Le lien de définition de la conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID de la conversation
    • nid2 : hash(‘nebule/objet/conversation’)
    • nid3 : hash(‘nebule/objet/type’)
  • Le lien de nommage de la conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID de la conversation
    • nid2 : hash(nom de la conversation)
    • nid3 : hash(‘nebule/objet/nom’)
  • Le lien de suivi de la conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID de l'entité, par défaut l’entité signataire
    • nid2 : ID de la conversation
    • nid3 : hash(‘nebule/objet/conversation/suivie’)

On peut aussi au besoin ajouter ces liens :

  • Le lien de fermeture d’une conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID de la conversation
    • nid2 : ID de l’entité, par défaut l’entité signataire
    • nid3 : hash(‘nebule/objet/conversation/ferme’)
  • Le lien de protection des membres d’une conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID de la conversation
    • nid2 : ID de l’entité, par défaut l’entité signataire
    • nid3 : hash(‘nebule/objet/conversation/protege’)
  • Le lien de dissimulation des membres d’une conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • nid1 : ID de la conversation
    • nid2 : ID de l’entité, par défaut l’entité signataire
    • nid3 : hash(‘nebule/objet/conversation/dissimule’)

--


OCS / Stockage

Voir OOS, pas de particularité de stockage.

--


OCT / Transfert

A faire...

--


OCR / Réservation

Les objets réservés spécifiquement pour les conversations :

  • nebule/objet/conversation
  • nebule/objet/conversation/fermee
  • nebule/objet/conversation/protegee
  • nebule/objet/conversation/dissimulee

--


OCIO / Implémentation des Options

Les options spécifiques aux conversations :

  • permitWriteConversation : permet toute écriture de conversations.

Les options qui ont une influence sur les conversations :

  • permitWrite : permet toute écriture d’objets et de liens ;
  • permitWriteObject : permet toute écriture d’objets ;
  • permitCreateObject : permet la création locale d’objets ;
  • permitWriteLink : permet toute écriture de liens ;
  • permitCreateLink : permet la création locale de liens.

Il est nécessaire à la création d’une conversation de pouvoir écrire des objets comme le nom de la conversation, même si l’objet de la conversation ne sera pas créé.

--


OCIA / Implémentation des Actions

Dans les actions, on retrouve les chaînes :

  • creagrp : Crée une conversation.
  • creagrpnam : Nomme la conversation à créer.
  • creagrpcld : Marque fermée la conversation à créer.
  • creagrpobf : Dissimule les liens de la conversation à créer.
  • actdelgrp : Supprime une conversation.
  • actaddtogrp : Ajoute l’objet courant membre à conversation.
  • actremtogrp : Retire l’objet courant membre d’une conversation.
  • actadditogrp : Ajoute un objet membre à la conversation courant.
  • actremitogrp : Retire un objet membre de la conversation courant.

--


OM / Monnaie

Certains objets permettre de mettre en place et de gérer plusieurs types de monnaies et plusieurs monnaies concurrentes.

--


OMF / Fonctionnement

Une monnaie est un objet de référence qui va gérer des sacs de jetons. La gestion se fait par différentes entités détenant des rôles spécifiques aux monnaies.

Une monnaie va disposer de plusieurs propriétés connues par leurs abréviations, voir OMCP.

L'objet de référence de la monnaie peut être virtuel ou non. Aujourd'hui le code ne gère que des monnaies avec un objet de référence non virtuel.

Si l'objet de référence de la monnaie est virtuel, il est forçément généré aléatoirement. Sinon il dépend du contenu de l'objet et est rendu unique grâce à la propriété SID.

Exemple d'objet de monnaie :

TYP:currency
SID:5f3ad5265bb3306b3266e1935d067d9ec15965d0a970554bc6161eb3328907a9
CAP:TYP MOD SID CAP AID MID NAM UNI DTA DTC DTD COM CPR IDM IDR IDP VMD VID TRS CID PID FID BID VAL CLB CLD SVC TID
MOD:CTL
AID:f0f7cf5c921320b97daedeb7c53f2417921c747c77b696f8a25ff29277661d2f
MID:f0f7cf5c921320b97daedeb7c53f2417921c747c77b696f8a25ff29277661d2f
NAM:poux
UNI:pou
CPR:(c) nebule/qantion 2020

--


OMN / Nommage

Une monnaie peut disposer d'un nom complet. Ce nom est définit par la propriété NAM et est doublé par un lien de nommage classique comme tout objet.

Une monnaie peut aussi disposer d'une abréviation définit par la propriété UNI.

Le nom complet d'un objet de type monnaie est uniquement extrait de la propriété NAM. Dans certains cas il peut êrte formé de NAM(UNI) mais la propriété UNI a plutôt vocation a être utilisée dans un affichage condensé.

--


OMP / Protection

A faire...

--


OMD / Dissimulation

A faire...

--


OML / Liens

A faire...

--


OMV / Valeur

La valeur de la monnaie, à un instant donné, est égale à la somme des sac de jetons de la monnaie au même instant.

--


OMC / Création

A faire...

--


OMCL / Liens

Liste des liens à générer lors de la création d'une monnaie.

A faire...

--


OMCP / Propriétés

--


OMCPH / Héritage

Certaines propriétés des sacs de jetons et jetons sont héritées de la monnaie, si ces propriétés sont définies dans la monnaie. Les héritages sont prioritaires sur les propriétés définies via l'objet et les liens des sacs de jetons et jetons.

--


OMCPHCT / HCT

Définit si l'objet de la monnaie a un contenu. Si il n'a pas de contenu l'objet de la monnaie est virtuel et correspond à son SID, et les paramètres de la monnaie ne peuvent pas être forcés.

Ce n'est pas écrit dans l'objet de la monnaie ni enregistré via des liens. Cela sert uniquement au moment de la création d'une monnaie.

--


OMCPTYP / TYP

Le type de monnaie.

Toujours à la valeur cryptocurrency.

Présence obligatoire en ligne 1 dans l'objet si l'objet n'est pas virtuel.

--


OMCPSID / SID

Le numéro de série identifiant de la monnaie (serial).

Si l'objet de référence de la monnaie est virtuel, l'identifiant de la monnaie CID sera le SID.

Si l'objet de référence de la monnaie n'est pas virtuel, l'identifiant de la monnaie CID dépend du contenu de l'objet et est rendu unique grâce à la propriété SID.

La valeur est de préférence aléatoire mais peut être un compteur à condition d'être unique. L’utilisation d’un compteur de faible valeur est fortement déconseillée.

Si aléatoire, la génération pseudo aléatoire du SID est faite en partant d’un dérivé de la date avec quelques valeurs locales. Il n’y a pas de contrainte de sécurité sur cette valeur. Puis une boucle interne génère un bon aléa au fur et à mesure de la génération des jetons via une fonction de hash. Le tout ne consomme pas du tout de précieux aléa de bonne qualité.

Présence obligatoire en ligne 2 dans l'objet si l'objet n'est pas virtuel.

--


OMCPCAP / CAP

Liste des capacités connues de la monnaie.

Si une capacité n'est pas présente elle ne peut être invoquée, même si elle est forcée.

Présence obligatoire en ligne 3 dans l'objet si l'objet n'est pas virtuel.

--


OMCPMOD / MOP

Définit le mode d'exploitation de la monnaie.

Si une capacité n'est pas présente elle ne peut être invoquée, même si elle est forcée.

Présence obligatoire en ligne 4 dans l'objet si l'objet n'est pas virtuel.

--


OMCPAID / AID

Identifiant de l'entité authorité de la monnaie (autority).

C'est l'entité qui forge la monnaie et délègue la gestion aux entités gestionnaires (MID).

Présence obligatoire en ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMCPMID / MID

Identifiant d'une entité de gestion de la monnaie (manage).

Une monnaie peut avoir plusieurs entités de gestion.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMCPFID / FID

Non utilisé !!!

Identifiant de l'entité ayant forgé la monnaie (forge).

Une monnaie peut tout à fait réutiliser un sac de jetons et des propriétés d’une autre monnaie sans qu’il y ai conflit dans la gestion des jetons et de leurs transactions. Les valeurs associées peuvent être copiées sans que cela ne pose de problème.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMCPCID / CID

Identifiant de l’objet de la monnaie (currency).

Une monnaie peut tout à fait réutiliser un sac de jetons et des propriétés d’une autre monnaie sans qu’il y ai conflit dans la gestion des jetons et de leurs transactions. Les valeurs associées peuvent être copiées sans que cela ne pose de problème. Ce qui va faire la différence c'est l'autorité et ses liens.

L'objet d'une monnaie ne peut en aucun cas contenir son propre identifiant CID.

--


OMCPNAM / NAM

Le nom de la monnaie. Limité à 256 caractères.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMCPUNI / UNI

Le nom de l'unité de la monnaie en 3 lettres maximum. Pas de chiffre.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMCPDTA / DTA

Identifiant de l’entité autorité de temps pour les limites de temps.

La gestion du temps avec une autorité de temps permet de prendre en compte sérieusement les suppression programmées de jeton (DTC/DTD) ainsi que leur inflation/déflation automatique (IDM/IDR/IDP).

L’autorité de temps peut être spécifique pour chaque jeton mais il est plus logique qu’elle soit commune à une monnaie ou dans certains cas à un sac de jetons.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMCPDTC / DTC

Date de création de la monnaie.

Forme texte libre limitée à 128 caractères. Doit pourvoir être interprété comme une date.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMCPDTD / DTD

Date de suppression programmée de la monnaie.

Forme texte libre limitée à 128 caractères. Doit pourvoir être interprété comme une date pour être fonctionel.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMCPCOM / COM

Commentaire texte libre limité à 4096 caractères.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMCPCPR / CPR

Licence du jeton sous forme d’une texte libre limité à 1024 caractères.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMCPIDM / IDM

Mode de fonctionnement du mécanisme d’inflation/déflation (mode) de tous les jetons de la monnaie.

Les modes sont creation ou transaction ou disabled.

Suivant le mode, le mécanisme tient compte du temps passé depuis la dernière transaction ou depuis l’émission du jeton.

Le mécanisme d’inflation/déflation (IDM/IDR/IDP), si activé, avec un taux de variation inférieur à 1, donc en déflation, permet de forcer les détenteurs de jeton à les utiliser plutôt que de les stocker. Les jetons concernés vont donc perdre de la valeur par rapport aux nouveaux jetons ou par rapport à ceux qui circulent.

Si activé, avec un taux de variation suppérieur à 1, donc en inflation, permet de favoriser la conservation des jetons et valorise les vieux jetons sur les nouveaux ou ceux qui circulent beaucoup.

En ne forçant pas cette propriété dans l'objet des jetons, il est possible d'avoir un taux de variation fluctuant en fonction des besoins. En le positionnant forçé à disabled cela désactive définitivement ce mécanisme au niveau de la monnaie et donc pour tous les jetons.

Un jeton peut se déprécier avec le temps mais une entité peut demander à l’autorité émettrice de la monnaie un échange de jeton ancien contre un jeton plus jeune, si l’autorité émettrice le permet.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

CF P/IDM et T/IDM.

--


OMCPIDR / IDR

Taux de variation du mécanisme d’inflation/déflation (rate) de tous les jetons de la monnaie.

Égal à 1 (un), taux constant donc pas de variation.

Doit être activé par IDM.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMCPIDP / IDP

Périodicité d’application du taux de variation du mécanisme d’inflation/déflation (period) de tous les jetons de la monnaie.

Unité exprimée en minutes.

Si à 0 (zéro), la période n'est pas utilisé, donc la variation est non effective.

Doit être activé par IDM.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMCPVMD / VMD

Définit le mode de validation des transactions de jetons de la monnaie. C'est le mode de fonctionnement global de la monnaie.

Actuellement seul est supporté le mode centralisé.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMCPVID / VID

Dans le mode de validation centralisé, c'est l'entité de validation des transactions de jetons de la monnaie.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMCPTRS / TRS

Liste des méthodes de transaction supportées.

Le code LNS désigne la méthode de base avec un lien (L) matérialisant une transaction et imposant un jeton non sécable (NS).

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMCPPCN / PCN

Non utilisé !!!

Définit le nombre de sacs de jetons à créer avec la monnaie. Ce nombre multiplié par le TCN donne le nombre total de jetons créés pour la monnaie.

Ce n'est pas écrit dans l'objet de la monnaie, ni dans les sacs de jetons ni enregistré via des liens. Cela sert uniquement au moment de la création de la monnaie. Cependant un lien de rattachement sera créé pour chaque sac de jeton depuis la monnaie avec en meta le PID.

--


OMS / Stockage

Voir OOS, pas de particularité de stockage.

OMT/ Transfert

A faire...

--


OMR / Réservation

Les objets réservés spécifiquement pour les monnaies :

  • nebule/objet/monnaie

--


OMIO / Implémentation des Options

A faire...

--


OMIA / Implémentation des Actions

A faire...

--


OMO / Oubli

L'oubli vonlontaire de certains liens et objets n'est encore ni théorisé ni implémenté mais deviendra indispensable lorsque l'espace viendra à manquer (cf CN).

--


OMG / Sac de jetons

A faire...

--


OMGF / Fonctionnement

A faire...

Exemple d'objet de sac de jetons :

TYP:tokenpool
SID:5f3ad5265bb3306b3266e1935d067d9ec15965d0a970554bc6161eb3328907a9
CAP:TYP MOD SID CAP AID MID NAM UNI DTA DTC DTD COM CPR IDM IDR IDP VMD VID TRS CID PID FID BID VAL CLB CLD SVC TID
CID:daf832e3042cc849efcd5b6531df835a9c5f6251b2101e20972f9a9db2a8ae24
FID:f0f7cf5c921320b97daedeb7c53f2417921c747c77b696f8a25ff29277661d2f
MID:f0f7cf5c921320b97daedeb7c53f2417921c747c77b696f8a25ff29277661d2f

Un sac de jetons va disposer de plusieurs propriétés connues par leurs abréviations, voir OMGCP.

A faire...

--


OMGN / Nommage

Un sac de jetons hérite du nommage de la monnaie à laquelle il est rattaché.

Le nom complet d'un objet de type sac de jetons est uniquement extrait de la propriété NAM. Dans certains cas il peut êrte formé de NAM(UNI) mais la propriété UNI a plutôt vocation a être utilisée dans un affichage condensé.

--


OMGP / Protection

A faire...

--


OMGD / Dissimulation

A faire...

--


OMGL / Liens

A faire...

--


OMGV / Valeur

La valeur du sac de jeton, à un instant donné, est égale à la somme des jetons du sac au même instant.

--


OMGC / Création

A faire...

--


OMGCL / Liens

Liste des liens à générer lors de la création d'un sac de jetons.

A faire...

--


OMGCP / Propriétés

--


OMGCPH / Héritage

Certaines propriétés sont héritées de la monnaie, si ces propriétés sont définies dans la monnaie. Ce doit être la monnaie déclarée en cours d'utilisation et le sac de jetons doit dépendre de cette monnaie directement. Les héritages sont prioritaires sur les propriétés définies via l'objet et les liens.

--


OMGCPHCT / HCT

Définit si l'objet du sac de jetons a un contenu. Si il n'a pas de contenu l'objet du sac de jetons est virtuel et correspond à son SID, et les paramètres du sac de jetons ne peuvent pas être forcés.

Ce n'est pas écrit dans l'objet du sac de jetons ni enregistré via des liens. Cela sert uniquement au moment de la création d'un sac de jetons.

Cette propriété ne peut pas être hérité de la monnaie.

--


OMGCPTYP / TYP

Le type de sac de jetons.

Toujours à la valeur tokenpool.

Présence obligatoire en ligne 1 dans l'objet si l'objet n'est pas virtuel.

Cette propriété ne peut pas être hérité de la monnaie.

--


OMGCPSID / SID

Le numéro de série identifiant du sac de jetons (serial).

Si l'objet de référence du sac de jetons est virtuel, l'identifiant du sac de jetons PID sera le SID.

Si l'objet de référence du sac de jetons n'est pas virtuel, l'identifiant du sac de jetons PID dépend du contenu de l'objet et est rendu unique grâce à la propriété SID.

La valeur est de préférence aléatoire mais peut être un compteur à condition d'être unique. L’utilisation d’un compteur de faible valeur est fortement déconseillée.

Si aléatoire, la génération pseudo aléatoire du SID est faite en partant d’un dérivé de la date avec quelques valeurs locales. Il n’y a pas de contrainte de sécurité sur cette valeur. Puis une boucle interne génère un bon aléa au fur et à mesure de la génération des jetons via une fonction de hash. Le tout ne consomme pas du tout de précieux aléa de bonne qualité.

Présence obligatoire en ligne 2 dans l'objet si l'objet n'est pas virtuel.

Cette propriété ne peut pas être hérité de la monnaie.

--


OMGCPCAP / CAP

Liste des capacités connues du sac de jetons.

Si une capacité n'est pas présente elle ne peut être invoquée, même si elle est forcée.

Présence obligatoire en ligne 3 dans l'objet si l'objet n'est pas virtuel.

--


OMGCPCID / CID

Identifiant de l’objet de la monnaie auquel est rattaché le sac de jetons (currency).

Une monnaie peut tout à fait réutiliser un sac de jetons et des propriétés d’une autre monnaie sans qu’il y ai conflit dans la gestion des jetons et de leurs transactions. Les valeurs associées peuvent être copiées sans que cela ne pose de problème.

Présence obligatoire en ligne 4 dans l'objet si l'objet n'est pas virtuel.

--


OMGCPFID / FID

Identifiant de l'entité ayant forgé le sac de jetons (forge).

L'entité forge doit désigner une entité de gestion, par défaut c'est elle-même.

Une monnaie peut tout à fait réutiliser un sac de jetons et des propriétés d’une autre monnaie sans qu’il y ai conflit dans la gestion des jetons et de leurs transactions. Les valeurs associées peuvent être copiées sans que cela ne pose de problème.

Présence facultative sans ordre après la ligne 4 dans l'objet si l'objet n'est pas virtuel.

Cette propriété ne peut pas être hérité de la monnaie.

--


OMGCPMID / MID

Identifiant de l'entité de gestion du sac de jetons (manage).

Une monnaie peut tout à fait réutiliser un sac de jetons et des propriétés d’une autre monnaie sans qu’il y ai conflit dans la gestion des jetons et de leurs transactions. Les valeurs associées peuvent être copiées sans que cela ne pose de problème.

Présence facultative sans ordre après la ligne 4 dans l'objet si l'objet n'est pas virtuel.

Cette propriété ne peut pas être hérité de la monnaie.

--


OMGCPPID / PID

Identifiant de l’objet du sac de jetons (pool).

Une monnaie peut tout à fait réutiliser un sac de jetons et des propriétés d’une autre monnaie sans qu’il y ai conflit dans la gestion des jetons et de leurs transactions. Les valeurs associées peuvent être copiées sans que cela ne pose de problème.

L'objet d'un sac de jetons ne peut en aucun cas contenir son propre identifiant PID.

--


OMGCPDTA / DTA

Identifiant de l’entité autorité de temps pour les limites de temps.

La gestion du temps avec une autorité de temps permet de prendre en compte sérieusement les suppression programmées de jeton (DTC/DTD) ainsi que leur inflation/déflation automatique (IDM/IDR/IDP).

L’autorité de temps peut être spécifique pour chaque jeton mais il est plus logique qu’elle soit commune à une monnaie ou dans certains cas à un sac de jetons.

Présence facultative sans ordre après la ligne 4 dans l'objet si l'objet n'est pas virtuel.

--


OMGCPDTC / DTC

Date de création du sac de jetons.

Forme texte libre limitée à 128 caractères. Doit pourvoir être interprété comme une date.

Présence facultative sans ordre après la ligne 4 dans l'objet si l'objet n'est pas virtuel.

--


OMGCPDTD / DTD

Date de suppression programmée du sac de jetons.

Forme texte libre limitée à 128 caractères. Doit pourvoir être interprété comme une date pour être fonctionel.

Présence facultative sans ordre après la ligne 4 dans l'objet si l'objet n'est pas virtuel.

--


OMGCPCOM / COM

Commentaire texte libre limité à 4096 caractères.

Présence facultative sans ordre après la ligne 4 dans l'objet si l'objet n'est pas virtuel.

Cette propriété ne peut pas être hérité de la monnaie.

--


OMGCPCPR / CPR

Licence du jeton sous forme d’une texte libre limité à 1024 caractères.

Présence facultative sans ordre après la ligne 4 dans l'objet si l'objet n'est pas virtuel.

Cette propriété ne peut pas être hérité de la monnaie.

--


OMGCPIDM / IDM

Mode de fonctionnement du mécanisme d’inflation/déflation (mode) des jetons dépendants du sac de jetons.

Les modes sont creation ou transaction ou disabled.

Suivant le mode, le mécanisme tient compte du temps passé depuis la dernière transaction ou depuis l’émission du jeton.

Le mécanisme d’inflation/déflation (IDM/IDR/IDP), si activé, avec un taux de variation inférieur à 1, donc en déflation, permet de forcer les détenteurs de jeton à les utiliser plutôt que de les stocker. Les jetons concernés vont donc perdre de la valeur par rapport aux nouveaux jetons ou par rapport à ceux qui circulent.

Si activé, avec un taux de variation suppérieur à 1, donc en inflation, permet de favoriser la conservation des jetons et valorise les vieux jetons sur les nouveaux ou ceux qui circulent beaucoup.

En ne forçant pas cette propriété dans l'objet des jetons, il est possible d'avoir un taux de variation fluctuant en fonction des besoins. En le positionnant forçé à disabled cela désactive définitivement ce mécanisme au niveau du sac de jetons et de tous les jetons en dépendant.

Un jeton peut se déprécier avec le temps mais une entité peut demander à l’autorité émettrice de la monnaie un échange de jeton ancien contre un jeton plus jeune, si l’autorité émettrice le permet.

Présence facultative sans ordre après la ligne 4 dans l'objet si l'objet n'est pas virtuel.

CF C/IDM.

--


OMGCPIDR / IDR

Taux de variation du mécanisme d’inflation/déflation (rate) des jetons dépendants du sac de jetons.

Égal à 1 (un), taux constant donc pas de variation.

Doit être activé par IDM.

Présence facultative sans ordre après la ligne 4 dans l'objet si l'objet n'est pas virtuel.

--


OMGCPIDP / IDP

Périodicité d’application du taux de variation du mécanisme d’inflation/déflation (period) des jetons dépendants du sac de jetons.

Unité exprimée en minutes.

Si à 0 (zéro), la période n'est pas utilisé, donc la variation est non effective.

Doit être activé par IDM.

Présence facultative sans ordre après la ligne 4 dans l'objet si l'objet n'est pas virtuel.

--


OMGCPTCN / TCN

Non utilisé !!!

Définit le nombre de jetons à créer dans le pool ou par pools créés (cf PCN).

Ce n'est pas écrit dans l'objet du sac de jetons ni enregistré via des liens. Cela sert uniquement au moment de la création d'un sac de jetons. Cependant un lien de rattachement sera créé pour chaque jeton depuis le sac de jeton avec en meta le TID.

--


OMGS / Stockage

Voir OOS, pas de particularité de stockage.

OMGT/ Transfert

A faire...

--


OMGR / Réservation

Les objets réservés spécifiquement pour les sacs de jetons :

  • nebule/objet/monnaie/sac

--


OMGO / Oubli

L'oubli vonlontaire de certains liens et objets n'est encore ni théorisé ni implémenté mais deviendra indispensable lorsque l'espace viendra à manquer (cf CN).

--


OMJ / Jeton

A faire...

--


OMJF / Fonctionnement

Un jeton est un objet de référence qui va servir de support de transmission de valeur. Il est attaché à un ou plusieurs sacs de jetons. Sa gestion se fait dans des monnaies par l'intermédiaire de sacs de jetons attachés aux monnaies.

Le jeton plus simple est un objet virtuel dont l’identifiant (TID) est généré aléatoirement. Ce peut être un simple compteur aussi mais chaque identifiant doit être unique par monnaie, et donc par sac de jetons aussi. L’utilisation d’un compteur de faible valeur est fortement déconseillé pour le TID. Par exemple :

4d831b11bbf828b9cfd4752223bb8918cbd634c4b858691736afd8b34f1f0c62

La deuxième forme de jeton est donc un objet dont le contenu va donner par son empreinte cryptographique un identifiant de jeton unique (TID). Il n’est dans ce cas pas possible d’avoir un compteur puisque les valeurs de identifiant sont assimilées à des valeurs aléatoires.

Exemple d'objet de jeton :

TYP:cryptoken
SID:5f3ad5265bb3306b3266e1935d067d9ec15965d0a970554bc6161eb3328907a9
CAP:TYP MOD SID CAP AID MID NAM UNI DTA DTC DTD COM CPR IDM IDR IDP VMD VID TRS CID PID FID BID VAL CLB CLD SVC TID
CID:daf832e3042cc849efcd5b6531df835a9c5f6251b2101e20972f9a9db2a8ae24
PID:37aa32a2cec224ae908226eb1c600fbeacd5faf1f84b2e292c0be808c0296333
FID:f0f7cf5c921320b97daedeb7c53f2417921c747c77b696f8a25ff29277661d2f
NAM:poux
UNI:pou
VAL:100

Un jeton va disposer de plusieurs propriétés connues par leurs abréviations, voir OMJCP.

--


OMJN / Nommage

Un jeton hérite du nommage de la monnaie via le sac de jeton auquel il est rattaché.

Le nom complet d'un objet de type jeton est uniquement extrait de la propriété NAM. Dans certains cas il peut êrte formé de NAM(UNI) mais la propriété UNI a plutôt vocation a être utilisée dans un affichage condensé avec une valeur.

--


OMJP / Protection

A faire...

--


OMJD / Dissimulation

A faire...

--


OMJL / Liens

A faire...

--


OMJV / Valeur

C’est une valeur calculée strictement numérique du jeton à un instant donné par rapport à une monnaie. Elle s'appelle la valeur relative du jeton.

Par défaut, si VAL non défini, la valeur de VAL est à interpréter comme équivalente à 1 (un).

Ce n'est pas écrit dans l'objet du jeton ni enregistré via des liens. La valeur relative du jeton est recalculée à chaque usage du jeton en fonction des paramêtres DTA, DTC, DTD, IDM, IDR, IDP, CLB et CLD.

Si le jeton est désactivé, sa valeur relative est nulle.

A faire... le détail des calculs de la valeur relative en fonction de chaque propriétés citées.

--


OMJC / Création

Si l'objet de référence du jeton est virtuel, il est forçément généré aléatoirement. Sinon il dépend du contenu de l'objet et est rendu unique grâce à la propriété SID.

Un jeton va disposer de plusieurs propriétés connues par leurs abréviations.

Le contenu des objets des jetons va recevoir plusieurs lignes de type clé:valeur. Chaque ligne débute par trois lettre en majuscules définissant le sens sémantique (clé) de la ligne, suivi d’un deux-points ( : ) et de la valeur associée. La valeur est un texte en minuscule sans caractères spéciaux, l’espace des caractères est limité aux lettres minuscules, aux chiffres, à l’espace (sauf au début et à la fin), au point, à la virgule et à l’égal. La valeur est par défaut limité en taille à 1024 caractères sauf mention contraire pour une propriété. Il ne doit pas y avoir d’espace sur une ligne, ni en début et fin de ligne, ni autour du deux-points. Chaque ligne est terminée par un retour chariot type UNIX.

Chaque propriété d’un jeton que l’on retrouve sous forme clé:valeur va être doublé d’un lien. Cependant les liens pouvant être annulés, les propriétés à figer sont écrites dans le jeton. Ainsi, une clé:valeur inscrite dans le jeton est prioritaire sur un lien équivalent.

Dans l'objet du jeton, les clés TYP et SID sont obligatoires, toujours au début et dans cet ordre.

Le début de contenu avec TYP:cryptoken permet de marquer un type de contenu facile à vérifier.

La seconde ligne avec le SID permet d’avoir un contenu unique et donc une empreinte unique pour chaque jeton.

--


OMJCL / Liens

Liste des liens à générer lors de la création d'un jeton.

A faire...

--


OMJCP / Propriétés

--


OMJCPH / Héritage

Certaines propriétés sont héritées de la monnaie, si ces propriétés sont définies dans la monnaie. Ce doit être la monnaie déclarée en cours d'utilisation et le jeton doit dépendre de cette monnaie via un sac de jetons. De la même façon certaines propriétés sont héritées en second lieu du sac de jeton. Les héritages sont prioritaires sur les propriétés définies via l'objet et les liens.

--


OMJCPHCT / HCT

Définit si l'objet du jeton a un contenu. Si il n'a pas de contenu l'objet du jeton est virtuel et correspond à son SID, et les paramètres du jeton ne peuvent pas être forcés.

Ce n'est pas écrit dans l'objet du jeton ni enregistré via des liens. Cela sert uniquement au moment de la création d'un jeton.

Cette propriété ne peut pas être hérité de la monnaie ou du sac de jetons.

--


OMJCPTYP / TYP

Le type de jeton.

Toujours à la valeur cryptoken.

Présence obligatoire en ligne 1 dans l'objet si l'objet n'est pas virtuel.

Cette propriété ne peut pas être hérité de la monnaie ou du sac de jetons.

--


OMJCPSID / SID

Le numéro de série identifiant le jeton (serial).

Si l'objet de référence du jeton est virtuel, l'identifiant du jeton TID sera le SID.

Si l'objet de référence du jeton n'est pas virtuel, l'identifiant du jeton TID dépend du contenu de l'objet et est rendu unique grâce à la propriété SID.

La valeur est de préférence aléatoire mais peut être un compteur à condition d'être unique. L’utilisation d’un compteur de faible valeur est fortement déconseillée.

Si aléatoire, la génération pseudo aléatoire du SID est faite en partant d’un dérivé de la date avec quelques valeurs locales. Il n’y a pas de contrainte de sécurité sur cette valeur. Puis une boucle interne génère un bon aléa au fur et à mesure de la génération des jetons via une fonction de hash. Le tout ne consomme pas du tout de précieux aléa de bonne qualité.

Présence obligatoire en ligne 2 dans l'objet si l'objet n'est pas virtuel.

Cette propriété ne peut pas être hérité de la monnaie ou du sac de jetons.

--


OMJCPCAP / CAP

Liste des capacités connues du jeton.

Si une capacité n'est pas présente elle ne peut être invoquée, même si elle est forcée.

Le contenu de cette propriété est hérité de la monnaie.

Présence obligatoire en ligne 3 dans l'objet si l'objet n'est pas virtuel.

--


OMJCPCID / CID

Identifiant de l’objet de la monnaie (currency).

Une monnaie peut tout à fait réutiliser un sac de jetons et des propriétés d’une autre monnaie sans qu’il y ai conflit dans la gestion des jetons et de leurs transactions. Les valeurs associées peuvent être copiées sans que cela ne pose de problème.

Présence obligatoire en ligne 4 dans l'objet si l'objet n'est pas virtuel.

--


OMJCPPID / PID

Identifiant de l’objet du sac de jetons (pool).

Une monnaie peut tout à fait réutiliser un sac de jetons et des propriétés d’une autre monnaie sans qu’il y ai conflit dans la gestion des jetons et de leurs transactions. Les valeurs associées peuvent être copiées sans que cela ne pose de problème.

Présence facultative sans ordre après la ligne 2 dans l'objet si l'objet n'est pas virtuel.

Présence obligatoire en ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMJCPTID / TID

Identifiant du jeton.

Sa valeur est égale à l'identifiant de l'objet.

L'objet d'un jeton ne peut en aucun cas contenir son propre identifiant TID.

--


OMJCPFID / FID

Identifiant de l'entité ayant forgé le jeton (forge).

Une monnaie peut tout à fait réutiliser un sac de jetons et des propriétés d’une autre monnaie sans qu’il y ai conflit dans la gestion des jetons et de leurs transactions. Les valeurs associées peuvent être copiées sans que cela ne pose de problème.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

Cette propriété ne peut pas être hérité de la monnaie ou du sac de jetons.

--


OMJCPBID / BID

Identifiant du bloc de forge (blockchain).

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

Cette propriété ne peut pas être hérité de la monnaie ou du sac de jetons.

--


OMJCPNAM / NAM

Le nom de la monnaie. Limité à 256 caractères.

Une monnaie peut tout à fait réutiliser un sac de jetons et des propriétés d’une autre monnaie sans qu’il y ai conflit dans la gestion des jetons et de leurs transactions. Les valeurs associées peuvent être copiées sans que cela ne pose de problème.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMJCPUNI / UNI

Le nom de l'unité de la monnaie en 3 lettres maximum. Pas de chiffre.

Une monnaie peut tout à fait réutiliser un sac de jetons et des propriétés d’une autre monnaie sans qu’il y ai conflit dans la gestion des jetons et de leurs transactions. Les valeurs associées peuvent être copiées sans que cela ne pose de problème.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMJCPVAL / VAL

Indication de valeur numérique initiale du jeton dans l’unité de la monnaie qui utilise le jeton.

C’est une valeur strictement numérique.

Par défaut, si non présent, la valeur est à interpréter comme équivalente à 1 (un).

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMJCPDTA / DTA

Identifiant de l’entité autorité de temps pour les limites de temps.

La gestion du temps avec une autorité de temps permet de prendre en compte sérieusement les suppression programmées de jeton (DTC/DTD) ainsi que leur inflation/déflation automatique (IDM/IDR/IDP).

L’autorité de temps peut être spécifique pour chaque jeton mais il est plus logique qu’elle soit commune à une monnaie ou dans certains cas à un sac de jetons.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMJCPDTC / DTC

Date de création du jeton.

Forme texte libre limitée à 128 caractères. Doit pourvoir être interprété comme une date.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMJCPDTD / DTD

Date de suppression programmée du jeton.

Forme texte libre limitée à 128 caractères. Doit pourvoir être interprété comme une date pour être fonctionel.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMJCPCOM / COM

Commentaire texte libre limité à 4096 caractères.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

Cette propriété ne peut pas être hérité de la monnaie ou du sac de jetons.

--


OMJCPCPR / CPR

Licence du jeton sous forme d’une texte libre limité à 1024 caractères.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

Cette propriété ne peut pas être hérité de la monnaie ou du sac de jetons.

--


OMJCPIDM / IDM

Mode de fonctionnement du mécanisme d’inflation/déflation (mode) du jeton.

Les modes sont creation ou transaction ou disabled.

Suivant le mode, le mécanisme tient compte du temps passé depuis la dernière transaction ou depuis l’émission du jeton.

Le mécanisme d’inflation/déflation (IDM/IDR/IDP), si activé, avec un taux de variation inférieur à 1, donc en déflation, permet de forcer les détenteurs de jeton à les utiliser plutôt que de les stocker. Les jetons concernés vont donc perdre de la valeur par rapport aux nouveaux jetons ou par rapport à ceux qui circulent.

Si activé, avec un taux de variation suppérieur à 1, donc en inflation, permet de favoriser la conservation des jetons et valorise les vieux jetons sur les nouveaux ou ceux qui circulent beaucoup.

En ne forçant pas cette propriété dans l'objet des jetons, il est possible d'avoir un taux de variation fluctuant en fonction des besoins. En le positionnant forçé à disabled cela désactive définitivement ce mécanisme au niveau du jeton.

Un jeton peut se déprécier avec le temps mais une entité peut demander à l’autorité émettrice de la monnaie un échange de jeton ancien contre un jeton plus jeune, si l’autorité émettrice le permet.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

CF C/IDM.

--


OMJCPIDR / IDR

Taux de variation du mécanisme d’inflation/déflation (rate) du jeton.

Égal à 1 (un), taux constant donc pas de variation.

Doit être activé par IDM.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMJCPIDP / IDP

Périodicité d’application du taux de variation du mécanisme d’inflation/déflation (period) du jeton.

Unité exprimée en minutes.

Si à 0 (zéro), la période n'est pas utilisé, donc la variation est non effective.

Doit être activé par IDM.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMJCPSVC / SVC

Le jeton fait référence à un type de service rendu (service).

Taille limitée à 1024 caractères.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMJCPCLB / CLB

Le jeton peut être désactivé (cancelable).

Par défaut un jeton n’est pas désactivable. Si cette option est présente, quelque soit son contenu, cela active la capacité de désactivation à la demande du jeton par la propriété CLD.

Elle n’a pas d’action sur la propriété de désactivation programmée DTD. Un jeton peut avoir une date de suppression programmée et être non désactivable avant la date de suppression. Activer la propriété CLD de façon forcée dans le contenu du jeton est faisable mais n’a pas de sens. Des jetons peuvent être générés désactivés et activés à posteriori.

Un jeton désactivé ne peut pas faire parti d’une transaction.

La taille est de un caractère maximum.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMJCPCLD / CLD

Le jeton est désactivé (canceled).

Cette propriété n’est d’utilisée que si CLB est activé.

Si cette option est présente, quelque soit son contenu, cela désactive le jeton.

Un jeton désactivé ne peut pas faire parti d’une transaction.

La taille est de un caractère maximum.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMJCPTRS / TRS

Liste des méthodes de transaction supportées.

Les modes sont définis dans le chapitre modes de transfert. Les modes supportés sont écrits les uns après les autres sur une seule ligne et séparés par un caractère espace.

Le contenu de cette propriété est hérité de la monnaie.

Présence facultative sans ordre après la ligne 5 dans l'objet si l'objet n'est pas virtuel.

--


OMJS / Stockage

Voir OOS, pas de particularité de stockage.

OMJT/ Transfert

Le jeton peut faire l'objet de deux types de transferts. Il y a la méthode de transfert de l'information (liens et objets) et le marquage du transfert de valeur.

OMJTI/ Transfert d'information

A faire...

OMJTV/ Transfert de valeur

Le transfert de valeur est appelé transaction.

La transaction unitaire marque l'attribution univoque et unidirectionnel d'une valeur appartenant à une entité vers une autre entité. Cette transaction unitaire peut être faite en contrepartie d'une autre valeur physique ou virtuelle, mais cette autre valeur n'est pas directement représentée dans la transaction unitaire traitée.

Ici nous appelerons transaction soit une transaction unitaire, soit un block de plusieurs transactions unitaires. Les valeurs attribuées dans un block de transactions sont soit des jetons complets, soit des parties de jetons. Cependant une transaction unitaire ne peut traiter qu'un unique jeton ou qu'une unique partie d'un unique jeton. Dans un block de transactions, toutes les transactions unitaires doivent traiter de la même monnaie.

Une contrepartie d'une autre valeur physique ou virtuelle peut au besoin être inscrite dans un jeton comme description. Ce mécanisme nécessite un suivi particulier qui n'est pas pris en charge ici.

Dans le code, la transaction est traité comme un lien. Si le lien est suffisant, dans le mode LNS (cf TRS), alors l'attribution du jeton peut être faite sur le lien uniquement. Si le lien fait référence à un objet tier, celui est considéré comme un block de transaction et est lu afin d'en extraire toutes les transactions unitaires.

OMJM/ Modes de transfert

OMJMLNS/ Mode LNS

Le code LNS désigne la méthode de base avec un lien (L) matérialisant une transaction et imposant un jeton non sécable (NS).

A faire...

--


OMJR / Réservation

Les objets réservés spécifiquement pour les jetons :

  • nebule/objet/monnaie/jeton

--


OMJO / Oubli

L'oubli vonlontaire de certains liens et objets n'est encore ni théorisé ni implémenté mais deviendra indispensable lorsque l'espace viendra à manquer (cf CN).

--


OA / Application

A revoir...

Une application permet d'interagir avec les objets et liens.

Une application qui ne fait que lire des objets et liens, ou retransmettre des liens déjà signés, est dite passive. Si l'application à la capacité de générer des liens signés, donc avec une entité déverrouillée, alors elle est dite active.

Si l'entité d'une instance d'application est par défaut et automatiquement déverrouillée, donc active, alors c'est aussi un robot. Le déverrouillage de cette entité peut cependant bénéficier de protections particulières.

--


OAF / Fonctionnement

Dans la construction du code, il y a quatre niveaux. Chaque niveau de code est constitué d’un et un seul objet nebule ou fichier utilisé. Une seule application est utilisée à un instant donné, mais il peut y avoir plusieurs modules utilisés par l’application. Les niveaux :

  • le bootstrap, fichier ;
  • la librairie en PHP orienté objet, objet ;
  • une application au choix, objet ou intégré ;
  • des modules au choix, facultatifs, objets.

Les applications sont toutes construites sur le même modèle et dépendent (extend) toutes des mêmes classes de l’application de référence dans la librairie nebule.

Chaque application doit mettre en place les constantes personnalisées :

  • APPLICATION_NAME
  • APPLICATION_SURNAME
  • APPLICATION_AUTHOR
  • APPLICATION_VERSION
  • APPLICATION_LICENCE
  • APPLICATION_WEBSITE
  • APPLICATION_NODE
  • APPLICATION_CODING
  • USE_MODULES
  • USE_MODULES_TRANSLATE
  • USE_MODULES_EXTERNAL
  • LIST_MODULES_INTERNAL
  • LIST_MODULES_EXTERNAL

Chaque application doit mettre en place les classes :

  • Application
  • Display
  • Action
  • Traduction

Elles dépendent respectivement des classes de l’application de référence Applications, Displays, Actions et Traductions dans la librairie nebule.

Les applications peuvent gérer des modules pour les rendre plus souples dans leur fonctionnement et adaptatives. CF OAM.

--


OAN / Nommage

A revoir...

--


OAP / Protection

A revoir...

--


OAD / Dissimulation

A revoir...

--


OAL / Liens

A revoir...

--


OAC / Création

A revoir...

--


OAS / Stockage

Voir OOS, pas de particularité de stockage.

--


OAT / Transfert

A revoir...

--


OAR / Réservation et références

Pas d'objet réservé spécifiquement pour les applications. Cependant, les applications d'interface en ont, CF OAIR.

--


OAI / Interface

Une interface est un programme dédié aux interactions entre deux milieux différents.

Une interface permet à une entité, c'est-à-dire un utilisateur ou un robot, d'interagir avec une application. Cela peut être vu comme une extension de l'application.

Les applications développées dans le cadre de nebule :

Nb
break
N0
defolt
N3
doctech
Au
autent
Sy
sylabe
Kl
klicty
Me
messae
Ne
neblog
Qa
qantion
Op
option
Up
upload

--


OAIN / Nommage

A revoir...

--


OAIP / Protection

A revoir...

--


OAID / Dissimulation

A revoir...

--


OAIL / Liens

A revoir...

--


OAIC / Création

La création d'une application se passe en trois parties. Il faut créer un objet de référence de la nouvelle application. Il faut lui affecter un objet de code, objet de code qui sera mise à jour plus tard. Enfin il faut enregistrer l'application pour la rendre disponible.

--


OAICR / Référence

A revoir...

Cette partie est à faire au début lorsque l’on veut rendre visible et utiliser la nouvelle application. Elle ne sera plus refaite par la suite. Le but est de permettre au bootstrap de retrouver l’application et de permettre à l’utilisateur de la sélectionner.

Sy
sylabe

On définit un objet de référence, un objet qui sera virtuel puisqu'il n’aura pas de contenu. Sa seule contrainte forte est que l’empreinte est exprimée en hexadécimal. Par convention, il est recommandé que la taille de l’empreinte des objets virtuels soit comprise en 129 et 191 bits. Cet objet de référence peut être généré aléatoirement ou au contraire avoir un contenu pré-déterminé, ou mixer les deux.

Chaque application doit avoir un objet de référence qui lui est réservé. Utiliser l’objet de référence d’une autre application revient à tenter de mettre à jour l’application, non à en faire une nouvelle.

Par exemple avec la commande : openssl rand -hex 36

Cela donne une valeur, notre objet de référence, qui ressemble à ça :

f3c2e389d0ec1bd3f279410748ba352c205ca354cec396a5f9fa0f8c0dcc1f9900bfd9

Pour finir avec l’objet de référence, la couleur de l’application dépend de lui. Cette couleur étant constituée des 6 premiers caractères de l’empreinte de l’objet de référence, il est possible de choisir volontairement cette couleur.

L’application doit avoir un nom et un préfixe. Ces deux propriétés sont utilisées par le bootstrap pour l’affichage des applications dans l’application de sélection des applications.

Le nom est libre, mais si il est trop grand, il sera tronqué pour tenir dans le carré de l’application.

Le préfixe doit faire 2 caractères. Si ce sont des lettres, systématiquement la première sera transformée en majuscule et la deuxième en minuscule.

Par exemple :

  • sylabe
  • Sy

Lorsque l’on a défini notre objet de référence et le nom de l’application, on crée les liens.

Liste des liens à générer lors de la création d'une application interface.

  • Le lien de hash :
    • REQ : l
    • NID1 : ID de l'application
    • NID2 : hash du nom de l’algorithme de prise d’empreinte
    • NID3 : hash(‘nebule/objet/hash’)
  • Le lien de définition de type application :
    • REQ : l
    • NID1 : ID de l'application
    • NID2 : hash(‘nebule/objet/interface/web/php/applications’)
    • NID3 : hash(‘nebule/objet/type’)
  • Le lien de nommage long de l'application :
    • REQ : l
    • NID1 : ID de l'application
    • NID2 : hash(nom long de l'application)
    • NID3 : hash(‘nebule/objet/nom’)
  • Le lien de nommage court de l'application :
    • REQ : l
    • NID1 : ID de l'application
    • NID2 : hash(nom court de l'application)
    • NID3 : hash(‘nebule/objet/surnom’)

Pour que ces liens soient reconnus par le bootstrap, ils doivent tous être signés d’une autorité locale.

--


OAICC / Code

A revoir...

La création de la base d’une application est simple, il suffit de copier le modèle d’application dans un nouveau fichier et dans un premier temps d’adapter les variables et la fonction d’affichage.

Ensuite, ce fichier doit être nébulisé, c'est-à-dire transféré vers le serveur comme nouvel objet.

Une fois nébulisé, l’objet peut être déclaré par un lien comme code pour l’objet de référence de l’application. Ainsi, l'objet référence point un code à exécuter.

Le lien de pointage du code :

  • REQ : f
  • NID1 :
  • NID2 :
  • NID3 :

Exemple de modèle d'application :

<?php
declare(strict_types=1);
namespace Nebule\Application\share;

/*
------------------------------------------------------------------------------------------
 /// WARNING /// WARNING /// WARNING /// WARNING /// WARNING /// WARNING /// WARNING ///
------------------------------------------------------------------------------------------

 [FR] Toute modification de ce code entrainera une modification de son empreinte
      et entrainera donc automatiquement son invalidation !
 [EN] Any changes to this code will cause a change in its footprint and therefore
      automatically result in its invalidation!
 [ES] Cualquier cambio en el código causarán un cambio en su presencia y por lo
      tanto lugar automáticamente a su anulación!

------------------------------------------------------------------------------------------
*/

class Application extends Applications
{
    const APPLICATION_NAME = 'share';
    const APPLICATION_SURNAME = 'nebule/share';
    const APPLICATION_AUTHOR = 'Projet nebule';
    const APPLICATION_VERSION = '020260101';
    const APPLICATION_LICENCE = 'GNU GPL 2024-2026';
    const APPLICATION_WEBSITE = 'www.neblog.org';
    const APPLICATION_NODE = '70428bfe9e818c0140c06fd681a669370158f1290e589594e9397e567b020796cb29.sha2.256';
    const APPLICATION_CODING = 'application/x-httpd-php';
    const USE_MODULES = true;
    const USE_MODULES_TRANSLATE = true;
    const USE_MODULES_EXTERNAL = false;
    const LIST_MODULES_INTERNAL = array('module_neblog', 'module_lang_fr-fr');
    const LIST_MODULES_EXTERNAL = array();
// ------------------------------------------------------------------------------------------

class Application extends Applications
{
	/**
	 * Constructeur.
	 *
	 * @param nebule $nebuleInstance
	 * @return void
	 */
	public function __construct(nebule $nebuleInstance)
	{
		$this->_nebuleInstance = $nebuleInstance;
	}

	// Tout par défaut.
}

class Display extends Displays
{
	const DEFAULT_LOGO_BOOTSTRAP = 'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAABACAYAAACqaX
HeAAABMElEQVR42u3ZQWqDQBTG8Tdp6VjEda5gyBnEeIkcxZ20mRuVrt0MIrhKyB3chFoIhULBalfZhCy6kBmI/7dVnPHHm3E+VC
LyKjOuhcy8AAAAAAAAAAAAAAAAAAAAAJhjPU7xkHEcX3xMXim1894Bvl5+qrHZAwAAAAAAfH+KfI6thP8CLAEAyAJkAbIAewAAAA
AAAFmADgAAALIAWYAswB4AAAAAAEAWoAMAAIAsMGEVRbEyxmz/c29VVYckSd5czOtBRDYuBrLWfmitP+M4XoZh+Hzrnr7vf621+z
zPbdu2P3cFICJSluUpCIKvLMvWt67XdX1M0/Td1cs7B7h0wjAMp2sEl23vFeB6OWitn1y3vXeAy3KIoui767rOGNM0TXP2cprkJM
hBCAAAAJhx/QGiUnc0nJCIeAAAAABJRU5ErkJggg==';

	/**
	 * Constructeur.
	 *
	 * @param Applications $applicationInstance
	 * @return void
	 */
	public function __construct(Applications $applicationInstance)
	{
		$this->_applicationInstance = $applicationInstance;
	}



	/**
	 * Affichage de la page.
	 */
	public function display()
	{
		?>
<!DOCTYPE html>
<html>
	<body>
		Hello
	</body>
</html>
<?php
	}
}

class Action extends Actions
{
	const ACTION_APPLY_DELAY = 5;
	/**
	 * Constructeur.
	 *
	 * @param Applications $applicationInstance
	 * @return void
	 */
	public function __construct(Applications $applicationInstance)
	{
		$this->_applicationInstance = $applicationInstance;
	}



	/**
	 * Traitement des actions génériques.
	 */
	public function genericActions()
	{
		$this->_metrology->addLog('Generic actions', Metrology::LOG_LEVEL_DEBUG, __METHOD__, '00000000');

		// Rien.

		$this->_metrology->addLog('Generic actions end', Metrology::LOG_LEVEL_DEBUG, __METHOD__, '00000000');
	}



	/**
	 * Traitement des actions spéciales, qui peuvent être réalisées sans entité déverrouillée.
	 */
	public function specialActions()
	{
		$this->_metrology->addLog('Special actions', Metrology::LOG_LEVEL_DEBUG, __METHOD__, '00000000');

		// Rien.

		$this->_metrology->addLog('Special actions end', Metrology::LOG_LEVEL_DEBUG, __METHOD__, '00000000');
	}
}

class Traduction extends Traductions
{
	/**
	 * Initialisation de la table de traduction.
	 */
    CONST TRANSLATE_TABLE = [
        'fr-fr' => [
            '::INFO' => 'Information',
            '::OK' => 'OK',
            '::INFORMATION' => 'Message',
            '::WARN' => 'ATTENTION !',
            '::ERROR' => 'ERREUR !',
        ],
        'en-en' => [
            '::INFO' => 'Information',
            '::OK' => 'OK',
            '::INFORMATION' => 'Message',
            '::WARN' => 'WARNING!',
            '::ERROR' => 'ERROR!',
        ],
        'es-co' => [
            '::INFO' => 'Information',
            '::OK' => 'OK',
            '::INFORMATION' => 'Mensaje',
            '::WARN' => '¡ADVERTENCIA!',
            '::ERROR' => '¡ERROR!',
        ],
    ];
}

--


OAICE / Enregistrement

Enregistrement d'une application :

  • Enregistrement de la référence de l'application :
    • action : f
    • nid1 : RID applications
    • nid2 : IID application
    • nid3 : OID type PHP
    • nid4 : NID code branch
  • Lien entre la référence de l'application et l'objet contenant le code :
    • action : f
    • nid1 : IID application
    • nid2 : OID application
    • nid3 : NID code branch
  • Type de l'objet contenant le code :
    • action : l
    • nid1 : OID application
    • nid2 : OID type PHP
    • nid3 : RID type mime
  • Activation de l'application :
    • action : l
    • nid1 : IID application
    • nid2 : RID activation application
  • Nom long de l'application :
    • action : l
    • nid1 : IID application
    • nid2 : OID nom long
    • nid3 : RID nommage long
  • Type de l'objet contenant le nom long de l'application :
    • action : l
    • nid1 : OID nom long
    • nid2 : OID type texte
    • nid3 : RID type mime
  • Nom court de l'application :
    • action : l
    • nid1 : IID application
    • nid2 : OID nom court
    • nid3 : RID nommage court
  • Type de l'objet contenant le nom raccourci de l'application :
    • action : l
    • nid1 : OID nom court
    • nid2 : OID type texte
    • nid3 : RID type mime
  • Légende :
    • RID applications : référence commune pour retrouver les applications.
    • IID applications : référence interne, unique, de l'application.
    • OID applications : objet contenant le code de l'application.
    • OID type PHP : objet contenant le type mime du code (application/x-httpd-php).
    • OID type texte : objet contenant le type mime du code (text/plain).
    • RID type mime : objet de référence du type mime (nebule/objet/type).
    • NID code branch : référence unique du niveau de développement, la branche, du code.
    • RID activation application : référence pour l'activation de l'application.
    • OID nom long : objet contenant le nom long de l'application.
    • OID nom court : objet contenant le nom raccourci (deux caractères) de l'application.
    • RID nommage long : objet de référence du nommage long des objets (nebule/objet/nom).
    • RID nommage court : objet de référence du nommage raccourci des objets (nebule/objet/surnom).

A revoir...

--


OAIU / Mise à Jour

A revoir...

--


OAIS / Stockage

Voir OOS, pas de particularité de stockage.

--


OAIT / Transfert

A revoir...

--


OAIR / Réservation et références

Les objets réservés spécifiquement pour les applications :

Objets réservés obsolètes !

  • nebule/objet/interface/web/php/bootstrap
  • nebule/objet/interface/web/php/bibliotheque
  • nebule/objet/interface/web/php/applications
  • nebule/objet/interface/web/php/applications/direct
  • nebule/objet/interface/web/php/applications/active

Les références :

  • REFERENCE_NEBULE_OBJET_INTERFACE_BOOTSTRAP=nebule/objet/interface/web/php/bootstrap : Référence pour retrouver le bootstrap.
  • REFERENCE_NEBULE_OBJET_INTERFACE_BIBLIOTHEQUE=nebule/objet/interface/web/php/bibliotheque : Référence pour retrouver la bibliothèque (libPOO).
  • REFERENCE_NEBULE_OBJET_INTERFACE_APPLICATIONS=nebule/objet/interface/web/php/applications : Référence pour retrouver les applications.
  • REFERENCE_NEBULE_OBJET_INTERFACE_APP_DIRECT=nebule/objet/interface/web/php/applications/direct : Référence pour désigner les applications sans pré-chargement.
  • REFERENCE_NEBULE_OBJET_INTERFACE_APP_ACTIVE=nebule/objet/interface/web/php/applications/active : Référence pour désigner les applications activées.

--


OAIG / Applications d'Interfaçage Génériques

Ces applications sont développées dans le cadre de nebule et sont librement mises à disposition (sous license).

Le nom de ces applications est toujours en minuscule.

--


OAIGB / Nb - bootstrap

voir OAB

A revoir...

--


OAIGA / Au - authen

IID=9020606a70985a00f1cf73e6aed5cfd46399868871bd26d6c0bd7a202e01759c3d91b97e.none.288

A revoir...

--


OAIGE / En - entity

IID=206090aec4ba9e2eaa66737d34ced59cfe73b8342fc020efbd321eded7c8b46440e0875a.none.288

A revoir...

--


OAIGS / Sy - sylabe

IID=c02030d3b77c52b3e18f36ee9035ed2f3ff68f66425f2960f973ea5cd1cc0240a4d28de1.none.288

A revoir...

--


OAIGK / Kl - klicty

IID=d0b02052a575f63a4e87ff320df443a8b417be1b99e8e40592f8f98cbd1adc58c221d501.none.288

A revoir...

--


OAIGM / Me - messae

IID=2060a0d21853a42093f01d2e4809c2a5e9300b4ec31afbaf18af66ec65586d6c78b2823a.none.288

A revoir...

--


OAIGN / Ne - neblog

IID=05c3dd94a9ae4795c888cb9a6995d1e5a23b43816e2e7fb908b6841694784bc3ecda8adf.none.288

A revoir...

--


OAIGQ / Qa - qantion

IID=20a04016698cd3c996fa69e90bbf3e804c582b8946a5d60e9880cdb24b36b5d376208939.none.288

A revoir...

--


OAIGO / No - option

IID=555555712c23ff20740c50e6f15e275f695fe95728142c3f8ba2afa3b5a89b3cd0879211.none.288

A revoir...

--


OAIGU / Nu - upload

IID=6666661d0923f08d50de4d70be7dc3014e73de3325b6c7b16efd1a6f5a12f5957b68336d.none.288

A revoir...

--


OAIO / Implémentation des Options

A revoir...

--


OAIA / Implémentation des Actions

A revoir...

--


OAB / Bootstrap

--


OABD / Description

Le bootstrap est un programme autonome de nebule constitué d'un seul et unique fichier écrit en PHP.

Il constitue le point d'entrée par défaut de toute connexion des utilisateurs ou robots vers l'instance, c'est-à-dire une localisation précise sur un serveur Web sur lequel on se connecte avec une URL dédiée.

Il est en charge lors du premier appel de retrouver et télécharger tout le nécessaire à la nouvelle instance depuis Internet.

Il est aussi en charge de trouver les dernières versions de la bibliothèque library de manière sécurisée.

Il gère en interne une page de description de l'instance.

Il va ensuite normalement charger la bibliothèque qui permet de gérer un certain nombre d'applications intégrées ou externes. Ces applications sont des interfaces entre les informations stockées dans les objets et reliées par des liens.

--


OABI / Installation

Le bootstrap nécessite pour fonctionner un serveur Web avec PHP pré-installé. Il peut être hébergé sur le site principal, dans un sous-domaine ou un sous-dossier de site Web. Il nécessite le droit d'écriture sur le dossier le contenant au moins le temps du premier démarrage.

Procédure :

  • Installer un serveur Web (Linux/Apache) avec PHP. Aucun serveur de base de données n'est utilisé.
  • Télécharger le fichier bootstrap sur le site Web http://www.nebule.org/. FIXME téléchargement sécurisé !
  • Positionner le fichier bootstrap dans le dossier Web du serveur Web. Au besoin, renommer le fichier en index.php.
  • Donner les droits de lecture et d'écriture (755 groupe apache) sur le dossier Web contenant le fichier bootstrap et le droit de lecture sur le fichier index.php (644).
  • Ouvrir un navigateur Web et donner en URL l'adresse du serveur Web.
  • La partie premier démarrage du bootstrap est appelée. Voir OABF.
  • Entrer un EID et une localisation pour le puppetmaster ou laisser celui par défaut. Valider.
  • Entrer un EID et une localisation pour l'entité de subordination ou laisser celle par défaut. Valider.
  • Noter l'empreinte EID de la nouvelle entité de l'instance et son mot de passe.
  • Si tout se passe bien, on arrive sur l'application 1 de selection des applications.
  • L'instance est prête.

Après le premier démarrage, les droits de lecture sont suffisants sauf pour les dossiers o et l qui nécessitent le droit d'écriture.

Il est possible sur une instance de ne laisser que les droits de lecture sur toute l'arborescence. Cependant, cela empêchera toute interaction nécessitant la création d'objets ou de liens. Il est préférable dans ce cas de positionner l'option permitWrite à false dans le fichier de configuration. Voir CCO pour changer la configuration.

--


OABF / Premier démarrage

Lors du premier démarrage (firstboot), c'est-à-dire lorsque l'on appelle le bootstrap via le serveur Web PHP, il va se charger de préparer l'environnement nécessaire au bon fonctionnement d'une instance nebule. Cela va inclure :

  • La création d'un fichier c de configuration générique.
  • La création d'un dossier o pour stocker les objets.
  • La création d'un dossier l pour stocker les liens.
  • La génération d'une entité locale, dite entité de l'instance.
  • La création d'un fichier e contenant l'empreinte EID de l'entité de l'instance.
  • La création de différents objets dans le dossier des objets.
  • La création de différents liens dans le dossier des liens.

Au besoin, un certain nombre de ces dossiers et fichiers peuvent être pré-initialisé lorsque l'on dépose le bootstrap sur le serveur Web. Mais cela n'est pas le fonctionnement normal.

--


OABM / Commandes

Il est possible d'interagir avec le bootstrap> au moyen de commandes dans l'URL. Certaines commandes listées sont sur un digit et ont été historiquement dans le bootstrap mais sont maintenant déportées dans la bibliothèque.

Liste des commandes :

  • a : Sélection d'une application.
  • b : Interruption du bootstrap. Voir OABB.
  • e : Affichage de l'empreinte EID de l'entité de l'instance.
  • f : Réinitialisation de la session, suppression du cache, fermeture des applications et entités.
  • di : Affichage en mode page intégrée d'une application. Ce n'est pas supporté partout.
  • l : Dans l'application 4, désigne le NID dont on veut afficher les blocs de liens. Non reconnu ailleurs. Voir OALA4. (hors bootstrap)
  • r : Charge en mode restreint pour dépannage.
  • t : Transmet un ticket qui doit être valide pour permettre certaines actions. (hors bootstrap)
  • g : Change l'entité en cours d'impersonation. (hors bootstrap)
  • s : Change l'entité connectée en cours. (hors bootstrap)
  • p : Mot de passe de l'entité. (hors bootstrap)
  • u : Demande une mise à jour des applications et du cache associé.
  • bootstrapfirstpuppetmastereid : Dans le firstboot, donne l'EID de puppetmaster. Non reconnu ailleurs.
  • bootstrapfirstpuppetmasterlocation : Dans le firstboot, donne la localisation de téléchargement de puppetmaster. Non reconnu ailleurs.
  • bootstrapfirstsubordinationeid : Dans le firstboot, donne l'EID de l'entité de subordination. Non reconnu ailleurs.
  • bootstrapfirstsubordinationlocation : Dans le firstboot, donne la localisation de téléchargement de l'entité de subordination. Non reconnu ailleurs.

ATTENTION : si la bibliothèque ne peut être chargée, le bootstrap renverra systématiquement sur la page d'interruption ! Voir OABB.

--


OABC / Configuration

Le bootstrap obéit aux mêmes options que la bibliothèque et les applications. Voir CCO.

--


OABB / Interruption

La présence de la commande b sur l'URL déclenche l'affichage d'une page d'interruption dédiée du bootstrap.

En cas de problème lors de l'initialisation du bootstrap ou de la bibliothèque, le bootstrap renverra systématiquement sur la page d'interruption avec une erreur.

Si la bibliothèque ne peut être chargée, quelque soit les arguments passés, le bootstrap renverra systématiquement sur la page d'interruption avec une erreur.

Le résultat est une page contenant en partie centrale, par exemple :

#1 bootstrap break on
- [11] user interrupt
tB=0.1473s
? Flush PHP session (20ef2d)
#2 bootstrap
bootstrap RID         : fc9bb365082ea3a3c8e8e9692815553ad9a70632fe12e9b6d54c8ae5e20959ce94fbb64f.none.288
bootstrap BID         : 81de9f10eb1479bbb219c166547b6d4eb690672feadf0f3841cacf58dbb21f537252b011.none.288
bootstrap CID         : a9e420daf12bc21278317e180fd51460fa786f275a2923d7a7b0cb0ac9c1ee2f.sha2.256
bootstrap IID         : 304f4431cd011211e8fbb57081cd8f1609a25a46ab30476e4b3bffb90d47e73832374176.none.288
bootstrap OID         : e45853f1709a6b296fa9237f43a494721ffe6e7ca66a34c65da400a483ecd1de.sha2.256 OK
bootstrap SID         : e2b35f9d064e9175ad845ed8261c20c8467f1673fe41112f5a5797e29224e493.sha2.256
#3 nebule library PP
library version       : 020251012
puppetmaster          : cf5ae12e8a97f7150a689c16734c926a35890d634625e129f8d62b5166eb1209.sha2.256
security authority    : fe3bb546bafa81bb4316402f436b35f86c74a509b3e171d6365060cd44387c24.sha2.256
code authority        : e2b35f9d064e9175ad845ed8261c20c8467f1673fe41112f5a5797e29224e493.sha2.256
directory authority   : 5451784e6a448f744f56ce6f9c8afdab1473634529cb3f2d4843ba3e1724be9f.sha2.256
time authority        : be7b4b52afcecc65bf8d743ff3b85b61d5abc2ddeb8c4b31af2c756bf8578849.sha2.256
server entity         : 33fb69b18286bdbf7cbc66a377a72f29cc57493916d0668e7031998b26b26039.sha2.256
default entity        : 88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256
ghost entity          : 88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256
code branch           : 81de9f10eb1479bbb219c166547b6d4eb690672feadf0f3841cacf58dbb21f537252b011.none.288 (develop)
php version           : found 8.2.29, need >= 8.0.0
#4 nebule library POO
tL=0.2825s
library RID           : 780c5e2767e15ad2a92d663cf4fb0841f31fd302ea0fa97a53bfd1038a0f1c130010e15c.none.288
library IID           : 21f6396e921e4373a91d70d13895b04a359316fc269a1c0dc9268a71419ecfb41e88d58d.none.288
library OID           : 6fe12abb07c6be3231e2a7d6970b6ce264106f1dc2888db80c41d4e85fbac1f0.sha2.256 version 020251011
library SID           : e2b35f9d064e9175ad845ed8261c20c8467f1673fe41112f5a5797e29224e493.sha2.256
functional level      : found 020241123, need >= 020250928
puppetmaster          : cf5ae12e8a97f7150a689c16734c926a35890d634625e129f8d62b5166eb1209.sha2.256 OK (local authority) (global authority)
security authority    : cf5ae12e8a97f7150a689c16734c926a35890d634625e129f8d62b5166eb1209.sha2.256 OK (local authority) (global authority)
code authority        : cf5ae12e8a97f7150a689c16734c926a35890d634625e129f8d62b5166eb1209.sha2.256 OK (local authority) (global authority)
directory authority   : cf5ae12e8a97f7150a689c16734c926a35890d634625e129f8d62b5166eb1209.sha2.256 OK (local authority) (global authority)
time authority        : cf5ae12e8a97f7150a689c16734c926a35890d634625e129f8d62b5166eb1209.sha2.256 OK (local authority) (global authority)
server entity         : cf5ae12e8a97f7150a689c16734c926a35890d634625e129f8d62b5166eb1209.sha2.256 OK (local authority) (global authority)
default entity        : cf5ae12e8a97f7150a689c16734c926a35890d634625e129f8d62b5166eb1209.sha2.256 OK (local authority) (global authority)
ghost entity          : cf5ae12e8a97f7150a689c16734c926a35890d634625e129f8d62b5166eb1209.sha2.256 OK (local authority) (global authority)
connected entity      : cf5ae12e8a97f7150a689c16734c926a35890d634625e129f8d62b5166eb1209.sha2.256 OK (local authority) (global authority)
subordination         : 0 OK
cryptography class    : Nebule\Library\CryptoOpenssl
cryptography          : hash sha2.256 OK
cryptography          : symmetric aes.256.ctr OK
cryptography          : asymmetric rsa.2048 OK
cryptography          : pseudo-random entropy 7.8967484073741/8 OK
i/o class             : Nebule\Library\io
i/o                   : Nebule\Library\ioDisk (RW) file://, links OK, objects OK
i/o                   : Nebule\Library\ioNetworkHTTP (RO) http://code.master.nebule.org, links OK no write., objects OK no write.
i/o                   : Nebule\Library\ioNetworkHTTPS (RO) https://code.master.nebule.org, links OK no write., objects OK no write.
social class          : Nebule\Library\Social
social                : Nebule\Library\SocialMySelf OK
social                : Nebule\Library\SocialNotMyself OK
social                : Nebule\Library\SocialSelf OK
social                : Nebule\Library\SocialNotself OK
social                : Nebule\Library\SocialAuthority OK
social                : Nebule\Library\SocialAll OK
social                : Nebule\Library\SocialNone OK
social                : Nebule\Library\SocialOnList OK
social                : Nebule\Library\SocialOffList OK
social                : Nebule\Library\SocialReputation OK
social                : Nebule\Library\SocialUnreputation OK
metrology inputs      : Lr=463+153 Lv=463+0 Or=471+1 Ov=471+1 (PP+POO)
metrology buffers     : Lc=0 Oc=5 Ec=2 Gc=0 Cc=0 CUc=0 CPc=0 CTc=0 CWc=0
#5 application
name space            : Nebule\Library
application RID       : 4046edc20127dfa1d99f645a7a4ca3db42e94feffa151319c406269bd6ede981c32b96e2.none.288
application IID       : 1 load
application OID       : 1
application SID       : /
#6 end bootstrap
tE=0.5937s

Les codes d'interruption :

  • [00] unknown buggy interrupt reason
  • [11] user interrupt
  • [21] library init error
  • [22] library i/o : link's folder error
  • [23] library i/o : link's folder error
  • [24] library i/o : object's folder error
  • [25] library i/o : object's folder error
  • [31] library load : finding library IID error
  • [32] library load : finding library OID error
  • [41] library load : find code error
  • [42] library load : include code error
  • [43] library load : functional version too old
  • [44] library load : load error
  • [45] application : find code error
  • [46] application : include code error
  • [47] application : load error
  • [51] unknown bootstrap hash
  • [61] no local server entity
  • [62] local server entity error
  • [71] need sync puppetmaster
  • [72] need sync authorities of security
  • [73] need sync authorities of security
  • [74] need sync authorities of code
  • [75] need sync authorities of code
  • [76] need sync authorities of time
  • [77] need sync authorities of time
  • [78] need sync authorities of directory
  • [79] need sync authorities of directory
  • [81] library init : I/O open error
  • [82] library init : puppetmaster error
  • [83] library init : security authority error
  • [84] library init : code authority error
  • [85] library init : time authority error
  • [86] library init : directory authority error

Table d'utilisabilité des entités calculée par la bibliothèque orienté objet (entities error level) :

  • 1 : L'entité puppet n'est pas une entité.
  • 2 : L'entité puppet a un EID=0.
  • 3 : L'EID de puppet n'est pas celui de la configuration.
  • 11 : La liste des autorités de sécurité est vide.
  • 12 : Une des autorités de sécurité n'est pas une entité.
  • 13 : Une des autorités de sécurité a un EID=0.
  • 21 : La liste des autorités du code est vide.
  • 22 : Une des autorités du code n'est pas une entité.
  • 23 : Une des autorités du code a un EID=0.
  • 31 : La liste des autorités de l'annuaire est vide.
  • 32 : Une des autorités de l'annuaire n'est pas une entité.
  • 33 : Une des autorités de l'annuaire a un EID=0.
  • 41 : La liste des autorités du temps est vide.
  • 42 : Une des autorités du temps n'est pas une entité.
  • 43 : Une des autorités du temps a un EID=0.
  • 51 : L'entité instance n'est pas une entité.
  • 52 : L'entité instance a un EID=0.
  • 61 : L'entité courante n'est pas une entité.
  • 62 : L'entité courante a un EID=0.
  • 128 : Toutes les entités utilisées sont bonnes.

Les temps de chargement (voir MC) :

  • tB : Temps de chargement du boostrap après la bibliothèque PP.
  • tE : Temps de fin de chargement de page d'interruption.

À compléter avec la description des lignes...

--


OABE / Applications externes

La présence de la commande a=RID sur l'URL permet de passer vers l'application référencée par ce RID. Pour les applications externes, le RID est l'objet de référence de l'application. Chaque application dispose d'un RID unique avec une valeur assez longue pour éviter toute collision avec une autre application.

Voir OA, OAIL et OABN.

--


OABN / Fonctionnement nominal

Le bootstrap mémorise la dernière application utilisée, externe ou intégrée, et va représenter la même application à l'utilisateur jusqu'à déconnexion de la session à l'instance ou vidage du cache ou problème. C'est le fonctionnement nominal pour un utilisateur.

La présence de la commande a=RID sur l'URL permet de passer vers l'application référencée par ce RID. Tant que la commande a n'est pas de nouveau utilisée, on reste sur la même application.

La recherche de l'application à utiliser par le bootstrap est faite dans l'ordre :

  • 1 : Si présence de la commande a, il essaie de trouver l'application correspondante.
  • 2 : Si une application est mémorisée dans le cache, il la charge.
  • 3 : Sinon il charge l'application par défaut. C'est équivalent à a=1.

Voir OAIL.

--


OAL / Librairie

--


OALD / Description

A revoir...

--


OALC / Configuration

La bibliothèque obéit aux mêmes options que le bootstrap et les applications. Voir CCO.

--


OALA / Applications intégrées

La présence de la commande a=RID sur l'URL permet de passer vers l'application référencée par ce RID. Pour les applications internes, le RID est l'objet de référence interne de l'application sur un seul chiffre (0 à 9).

Toutes les applications internes ne sont pas actives et donc ne sont pas accessibles. Certaines applications internes peuvent être bloquées par des options de configuration.

Une application intégrée peut être appelée par défaut via l'option de configuration defaultApplication par exemple à 1.

Ci-dessous les différentes applications.

--


OALA0 / Application 0

C'est l'application par défaut pour les instances sans interaction. La page Web délivrée est minimaliste.

La présence de la commande a=0 sur l'URL déclenche l'affichage de cette page dédiée de la bibliothèque.

Son accès ne peut pas être bloqué.

--


OALA1 / Application 1

C'est l'application de sélection et de navigation et les différentes applications.

La présence de la commande a=1 sur l'URL déclenche l'affichage de cette page dédiée de la bibliothèque.

Son accès peut être bloqué par l'option permitApplication1 à false ou un lien équivalent.

--


OALA2 / Application 2

C'est une application minimale d'authentification des utilisateurs sur les entités.

La présence de la commande a=2 sur l'URL déclenche l'affichage de cette page dédiée de la bibliothèque.

Son accès peut être bloqué par l'option permitApplication2 à false ou un lien équivalent.

--


OALA3 / Application 3

C'est l'application d'affichage de la documentation technique.

La présence de la commande a=3 sur l'URL déclenche l'affichage de cette page dédiée de la bibliothèque.

Son accès peut être bloqué par l'option permitApplication3 à false ou un lien équivalent.

--


OALA4 / Application 4

C'est une application qui permet de voir de façon simplifiée les blocs de liens.

La présence de la commande a=4 sur l'URL déclenche l'affichage de cette page dédiée de la bibliothèque.

Son accès peut être bloqué par l'option permitApplication4 à false ou un lien équivalent.

Elle est désactivée par défaut.

--


OALA5 / Application 5

Son accès peut être bloqué par l'option permitApplication5 à false ou un lien équivalent.

Non utilisé, redirigé vers l'application 0.

--


OALA6 / Application 6

Son accès peut être bloqué par l'option permitApplication6 à false ou un lien équivalent.

Non utilisé, redirigé vers l'application 0.

--


OALA7 / Application 7

Son accès peut être bloqué par l'option permitApplication7 à false ou un lien équivalent.

Non utilisé, redirigé vers l'application 0.

--


OALA8 / Application 8

Son accès peut être bloqué par l'option permitApplication8 à false ou un lien équivalent.

Non utilisé, redirigé vers l'application 0.

--


OALA9 / Application 9

C'est une application utilisée pour la mise à l'arrêt de l'instance, comme une mise en sommeil, dans le but de permettre à un autre programme externe de manipuler les objets et liens. Cette mise en sommeil peut être utilisée afin de faire sans entrave le ménage, supprimer et réorganiser les données.

La présence de la commande a=9 sur l'URL déclenche l'affichage de cette page dédiée de la bibliothèque.

Son accès peut être bloqué par l'option permitApplication9 à false ou un lien équivalent.

Elle est désactivée par défaut.

Cette application n'a pas de protection dans son usage et ne doit être activée que sur une instance à usage privée.

--


OALT / Actions

Les actions sont les interactions qui amènent à la modification de liens et/ou d'objets. Il y a deux types d'actions :

  • Actions génériques : ce sont toutes les actions basiques qui nécessitent cependant qu'une entité soit déverrouillée et un jeton valide.
  • Actions spéciales : ce sont toutes les actions un peu particulières qui doivent pouvoir être réalisées sans entité déverrouillée et/ou sans jeton valide. Un certain nombre de contrôles supplémentaires sont nécessaires dans ce cas avant de réaliser l'action.

Cette distinction se retrouve dans la bibliothèque et dans les applications, mais pas dans les modules.

--


OALZ / Mode sommeil

À définir...

--


OAM / Module

Le module est une classe enfant de la classe Modules. Cela permet d'étendre les fonctionnalités d'une application. Un module peut être par défaut présent dans une application, c'est-à-dire présent dans l'objet de l'application. Dans ce cas son nom doit être présent dans la liste des modules intégrés à l'application.

Il y a plusieurs types de modules dans une application. :

  • Le type interne (internal) correspond aux modules intégrés dans l'objet de l'application.
  • Le type externe (external) correspond uax modules non intégrés dans l'objet de l'application. Ils sont détectés par des liens dédiés et chargés puis instanciés par l'application.
  • Le type traduction (translate) correspond aux modules externes à l'application et dédiés à la traduction, mais avec des capacités réduites.

Pour qu'une application puisse utiliser des modules, elle doit permettre l'utilisation des modules. De façon globale, des options permettent d'utiliser des modules ou non, elles sont prioritaires sur le choix des applications.

Pour activer les modules, internes et/ou externes, dans la classe Application d'une application, il faut positionner la constante USE_MODULES = true. L'option permitApplicationModules doit être à true. Les modules internes sont intégrés par défaut dans l'objet d'une application. Pour être utilisé, ils doivent tous être déclarés dans la constance LIST_MODULES_INTERNAL sous forme d'une liste.

Les modules externes peuvent être pris en compte via le lien des modules si la constance USE_MODULES_EXTERNAL = true en plus de la USE_MODULES = true. Les options permitApplicationModules et permitApplicationModulesExternal doivent être à true.

Les modules externes de traduction peuvent être pris en compte via le lien des modules si la constance USE_MODULES_TRANSLATE = true en plus de la USE_MODULES = true. Ces modules n'ont aucun code exécuté et exposent uniquement un tableau avec des traductions. Les options permitApplicationModules et permitApplicationModulesTranslate doivent être à true.

A faire...

--


OAMN / Nommage

A faire...

--


OAMP / Protection

A faire...

--


OAMD / Dissimulation

A faire...

--


OAML / Liens

A faire...

--


OAMC / Création

Un module est une classe enfant de la classe Modules ou de la classe ModuleTranslates.

Les modules sont chargés par la classe Applications dont hérite toutes les applications.

Liste des liens à générer lors de la création d'un module.

A faire...

--


OAMU / Mise à Jour

A faire...

--


OAMS / Stockage

Voir OOS, pas de particularité de stockage.

--


OAMT / Transfert

A faire...

--


OAMR / Réservation et références

Pas d'objet réservé spécifiquement pour les modules d'applications.

Les références :

  • REFERENCE_NEBULE_OBJET_INTERFACE_APP_MODULES=fd66cdc1edfa0285d6ce9d8419847e54ec7df2d293921615d13d35a5879e7e311efff4ad.none.288 : Référence pour retrouver les modules d'une application.
  • REFERENCE_NEBULE_OBJET_INTERFACE_APP_MODULES_TRANSLATE=4a45d825cf72fbf331c07cb4bdd6c65ab13e3b6b10405400d82817ed48ff4691e8699a69.none.288 : Référence pour retrouver les modules de traduction d'une application.
  • REFERENCE_NEBULE_OBJET_INTERFACE_APP_MODULES_ACTIVE=1e1531707bb7b0be9f4664fe8010729090f592ed4c3f4e6e37c6365f865a192beee3e970.none.288 : Référence pour retrouver les modules activés.

--


B / Bloc de liens

Le bloc de liens permet d'agréger un ou plusieurs registres de liens, de le rendre transferable et de le sécuriser. Voir L.

On parlera par facilité de bloc de liens BL pour la partie opérationnelle contenant uniquement les registres de liens RL. Cependant, le bloc de liens doit être compris aussi avec le bloc d'entête BH permettant sa transmission et le loc de signature permettant sa sécurisation. Sa sureté de fonctionnement est gérée par sa structure rigide prédéfinit par le bloc d'entête.

A revoir...

Cette partie est périmée avec la nouvelle version de liens !

Le lien est la matérialisation dans un graphe d’une relation entre deux objets pondéré par un troisième objet.

--


BD / Description

A revoir...

--


BS / Structure

Le bloc de liens est enregistré dans une structure avec un format définit et contraint afin de pouvoir être stocké et échangé de façon sûre et sécurisée.

Cette structure a quatre niveaux de profondeur avec pour chaque niveau un séparateur de champs spécifique. Il n'y a pas de risque de confusion lors de la navigation dans les champs avec ces séparateurs spécifiques.

La structure du bloc de liens :

  • L : BH_BL_BS
    • BH : RF/RV
      • RF : APP:TYP
        • APP : nebule
        • TYP : link
      • RV : VERS: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 : EID>SIG
        • EID : hash.algo.size
        • SIG : sign.algo.size

--


BC / Construction

A revoir...

--


BCB / Blocs

A revoir...

--


BCBH / Bloc d'entête

Le bloc d'entête contient les registres RF et RV.

A revoir...

--


BCBL / Bloc de liens

Le bloc de liens contient les registres RC et RL.

A revoir...

--


BCBS / Bloc de signature

Le bloc d'entête contient les registres RS.

A revoir...

--


BCR / Registres

A revoir...

--


BCRF / Registre de forme

Le registre de forme est le premier registre du bloc d'entête. Il contient les éléments APP et TYP.

A revoir...

--


BCRV / Registre de version

Le registre de version est le second et dernier registre du bloc d'entête.

A revoir...

--


BCRC / Registre de chronologie

Le registre de chronologie est le premier registre du bloc de liens.

A revoir...

--


BCRL / Registre de liens

Le registre de liens est le second registre et les suivants du bloc de liens.

A revoir...

--


BCRS / Registre de signature

Le registre de signature est le ou les registres du bloc de signature.

A revoir...

--


BCE / Eléments

A revoir...

--


BCEAPP / Application

L'élément application (APP) est le premier élément du Registre de forme.

A revoir...

--


BT / Transfert

A revoir...

--


BV / Vérification

A revoir...

--


L / Registre de lien

Le lien est la matérialisation dans un graphe d’une relation entre deux nœuds, généralement des objets. Le type de cette relation est définie par un troisième objet, c'est la façon dont on va interpréter la relation entre les deux premiers nœuds. La relation peut être contextualisée avec un quatrième nœud, ou plus.

Dans le cas d'un lien à deux ou trois nœuds, nous sommes dans un cas similaire à un graphe orienté tel qu'on le trouve dans une base de données de type graphe. Nous retrouvons ce principe dans le Resource Description Framework (RDF). À une différence près cependant, c'est qu'ici le lien ne contient que des identifiants de nœuds et non des contenus.

Dans le cas d'un lien avec plus de 3 nœuds, nous sommes dans un hypergraphe orienté. Vu l'usage qu'il est fait des nœuds dans les liens, nous pouvons cependant déjà considérer que nous sommes dans un hypergraphe au-delà de deux nœuds.

Le lien est enregistré dans un registre avec un format définit et contraint afin de pouvoir être stocké et échangé de façon sûre et sécurisée.

Le registre de lien ne porte pas son autoprotection. Il est enregistré dans un bloc de liens qui se charge de faire cohabiter et de protéger un ou plusieurs liens simultanément. Voir B.

--


LS / Structure

Chaque lien est écrit dans ce que l'on appelle un registre de lien. Ce registre va comprendre plusieurs champs. Le premier champ est dit requête d'action. Il est suivi par les champs contenant les identifiants des nœuds dans l'ordre d'usage (graphe orienté).

La requête d'action est obligatoire et est unique pour un registre de lien.

Dans le registre, chaque champ est séparé des autres par le caractère « > ». Le nombre de champs exploitable, sans compter la requête d'action, est limité par l'option linkMaxUIDbyRL. Si le nombre de champs du registre est supérieur à la valeur limite, le lien est déclaré invalide.

La forme du registre de lien :

REQ>NID>NID>NID>NID

--


LELPO / Liens à Propos d’un Objet

A revoir...

Les liens d’un objet sont consultables séquentiellement. Ils doivent être perçus comme des méta-données d’un objet.

Les liens sont séparés soit par un caractère espace « », soit par un retour chariot « \n ». Un lien est donc une suite de caractères ininterrompue, c'est-à-dire sans espace ou retour à la ligne.

La taille du lien dépend de la taille de chaque champ.

--


LELCO / Liens Contenu dans un Objet

A revoir...

Certains liens d’un objet peuvent être contenus dans un autre objet.

Cette forme de stockage des liens permet de les transmettre et de les manipuler sous la forme d’un objet. On peut ainsi profiter du découpage et du chiffrement. Plusieurs liens peuvent être stockés sans être nécessairement en rapport avec les mêmes objets.

Les liens stockés dans un objet ne peuvent pas faire référence à ce même objet.

Tout ajout de lien crée implicitement un nouvel objet de mise à jour, c'est-à-dire lié par un lien de type u.

Chaque fichier contenant des liens doit avoir un entête de version.

Les objets contenants des liens ne sont pas reconnus et exploités lors de la lecture des liens. Ceux-ci doivent d’abord être extraits et injectés dans les liens des objets concernés. En clair, on ne peut pas s’en servir facilement pour de l’anonymisation.

--


LE / Entête

A revoir...

L’entête des liens est constitué du texte nebule/liens/version/1.2. Il est séparé du premier lien soit par un caractère espace « », soit par un retour chariot « \n ».

Il doit être transmis avec les liens, en premier.

--


LR / Registre

A revoir...

Le registre du lien décrit la syntaxe du lien :

Signature_HashSignataire_TimeStamp_Action_HashSource_HashCible_HashMeta

Ce registre a un nombre de champs fixe. Chaque champ a une place fixe dans le lien. Les champs ont une taille variable. Le séparateur de champs est l’underscore « _ ». Les champs ne peuvent contenir ni l’underscore « _ » ni l’espace  »  » ni le retour chariot « \n ».

Tout lien qui ne respecte pas cette syntaxe est à considérer comme invalide et à supprimer. Tout lien dont la Signature est invalide est à considérer comme invalide et à supprimer. La vérification peut être réalisée en réassemblant les champs après nettoyage.

--


LRSI / Le champ Signature

A revoir...

Le champ Signature est représenté en deux parties séparées par un point « . » . La première partie contient la valeur de la signature. La deuxième partie contient le nom court de la fonction de prise d’empreinte utilisée.

La signature est calculée sur l’empreinte du lien réalisée avec la fonction de prise d’empreinte désignée dans la deuxième partie. L’empreinte du lien est calculée sur tout le lien sauf le champs signature, c'est-à-dire sur « _HashSignataire_TimeStamp_Action_HashSource_HashCible_HashMeta » avec le premier underscore inclus.

La signature ne contient que des caractères hexadécimaux, c'est-à-dire de « 0 » à « 9 » et de « a » à « f » en minuscule. La fonction de prise d’empreinte est notée en caractères alphanumériques en minuscule.

--


LRUSI / Le champ HashSignataire

A revoir...

Le champ HashSignataire désigne l’objet de l’entité qui génère le lien et le signe.

Il ne contient que des caractères hexadécimaux, c'est-à-dire de « 0 » à « 9 » et de « a » à « f » en minuscule.

--


LRT / Le champ TimeStamp

Le champ TimeStamp est une marque de temps qui donne un ordre temporel aux liens. Ce champs peut être une date et une heure au format ISO8601 ou simplement un compteur incrémental.

--


LRA / Le champ Action

A revoir...

Le champ Action détermine la façon dont le lien doit être utilisé.

Quand on parle du type d’un lien, on fait référence à son champ Action.

L’interprétation de ce champ est limité au premier caractère. Des caractères alpha-numériques supplémentaires sont autorisés, mais ignorés.

Cette interprétation est basée sur un vocabulaire particulier. Ce vocabulaire est spécifique à nebule v1.2 (et nebule v1.1).

Le vocabulaire ne reconnaît que les 8 caractères l, f, u, d, e, x, k et s, en minuscule.

--


LRAL / Action l – Lien entre objets

A revoir...

Met en place une relation entre deux objets. Cette relation a un sens de mise en place et peut être pondérée par un objet méta.

Les liens de type l ne devraient avoir ni HashMeta nul ni HashCible nul.

l comme link.

Lors de la lecture de multiples liens l, on ne retient qu'un seul lien. On retient le dernier lien en date après filtrage social, éventuellement le dernier en date de l'entité signataire avec le plus fort score social.

--


LRAF / Action f – Dérivé d’objet

A revoir...

Le nouvel objet est considéré comme enfant ou parent suivant le sens du lien.

Le champs ObjetMeta doit être vu comme le contexte du lien. Par exemple, deux objets contenants du texte peuvent être reliés simplement sans contexte, c'est-à-dire reliés de façon simplement hiérarchique. Ces deux mêmes textes peuvent être plutôt (ou en plus) reliés avec un contexte comme celui d’une discussion dans un blog. Dans ce deuxième cas, la relation entre les deux textes n’a pas de sens en dehors de cette discussion sur ce blog. Il est même probable que le blog n’affichera pas les autres textes en relations si ils n’ont pas un contexte appartenant à ce blog.

f comme fork.

Lors de la lecture de multiples liens f, on retient une liste de liens. On peut ne retenir que les liens ayant un minimum de score social de leurs entités signataires.

--


LRAU / Action u – Mise à jour d’objet

A revoir...

Mise à jour d’un objet dérivé qui remplace l’objet parent.

u comme update.

--


LRAD / Action d – Suppression d’objet

A revoir...

L’objet est marqué comme à supprimer d’un ou de tous ses emplacements de stockage.

d comme delete.

Le champs HashCible peut être nuls, c'est-à-dire égal à 0. Si non nul, ce champs doit contenir une entité destinataire de l’ordre de suppression. C’est utilisé pour demander à une entité relaie de supprimer un objet spécifique. Cela peut être utilisé pour demander à une entité en règle générale de bien vouloir supprimer l’objet, ce qui n’est pas forcément exécuté.

Le champs HashMeta doit être nuls, c'est-à-dire égal à 0.

Un lien de suppression sur un objet ne veut pas forcément dire qu’il a été supprimé. Même localement, l’objet est peut-être encore présent. Si le lien de suppression vient d’une autre entité, on ne va sûrement pas par défaut en tenir compte.

Lorsque le lien de suppression est généré, le serveur sur lequel est généré le lien doit essayer par défaut de supprimer l’objet. Dans le cas d’un serveur hébergeant plusieurs entités, un objet ne sera pas supprimé si il est encore utilisé par une autre entité, c'est-à-dire si une entité a un lien qui le concerne et n’a pas de lien de suppression.

--


LRAE / Action e – Équivalence d’objets

A revoir...

Définit des objets jugés équivalents, et donc interchangeables par exemple pour une traduction.

--


LRAC / Action c – Chiffrement de lien

Ce lien de dissimulation contient un lien dissimulé sans signature. Il permet d’offusquer des liens entre objets et donc d’anonymiser certaines actions de l’entité (cf. CKL).

Le champs HashSource fait référence à l’entité destinataire du lien, celle qui peut le déchiffrer. À part le champs de l’entité signataire, c’est le seul champs qui fait référence à un objet.

Le champs HashCible ne contient pas la référence d’un objet, mais le lien chiffré et encodé en hexadécimal. Le chiffrement est de type symétrique avec la clé de session. Le lien offusqué n’a pas grand intérêt en lui-même, c’est le lien déchiffré qui en a.

Le champs HashMeta ne contient pas la référence d’un objet, mais la clé de chiffrement du lien, dite clé de session. Cette clé est chiffrée (asymétrique) pour l’entité destinataire et encodée en hexadécimal. Chaque entité destinataires d'un lien de dissimulé doit disposer d'un lien de dissimulation qui lui est propre.

Lors du traitement des liens, si une entité est déverrouillée, les liens offusqués pour cette entité doivent être déchiffrés et utilisés en remplacement des liens offusqués originels. Les liens offusqués doivent être vérifiés avant déchiffrement. Les liens déchiffrés doivent être vérifiés avant exploitation.

Les liens de dissimulations posent un problème pour être efficacement utilisés par les entités émeteurs et destinataires. Pour résoudre ce problème sans risquer de révéler les identifiants des objets utilisés dans un lien dissimulé, les liens de dissimulation sont attachés à des objets virtuels translatés depuis les identifiants des objets originaux (cf LD).

L'option permitObfuscatedLink permet de désactiver la dissimulation (offuscation) des liens des objets. Dans ce cas le lien de type c est rejeté comme invalide avec le code erreur 43.

--


LRAK / Action k – Chiffrement d’objet

A revoir...

Désigne la version chiffrée de l’objet (cf. CKO).

L'option permitProtectedObject permet de désactiver la protection (chiffrement) des objets. Dans ce cas le lien de type k est rejeté comme invalide avec le code erreur 42.

--


LRAS / Action s – Subdivision d’objet

Désigne un fragment de l’objet.

Ce champ nécessite un objet méta qui précise intervalle de contenu de l’objet d’origine. Le contenu de l’objet méta doit être de la forme x-y avec :

  • x et y exprimé en octet sans zéro et sans unité ;
  • x strictement supérieur à zéro ;
  • y strictement inférieur ou égal à la taille de l’objet (lien vers nebule/objet/taille) ;
  • x inférieur à y ;
  • sans espace, tabulation ou retour chariot.

--


LRAX / Action x – Suppression de lien

A revoir...

Supprime un ou plusieurs liens précédemment mis en place.

Les liens concernés par la suppression sont les liens antérieurs de type l, f, u, d, e, k et s. Ils sont repérés par les 3 derniers champs, c’est à dire sur HashSource_HashCible_HashMeta. Les champs nuls sont strictement pris en compte.

Le champ TimeStamp permet de déterminer l’antériorité du lien et donc de déterminer sa suppression ou pas.

C’est la seule action sur les liens et non sur les objets.

--


LRHS / Le champ HashSource

A revoir...

Le champ HashSource désigne l’objet source du lien.

Le champ signataire ne contient que des caractères hexadécimaux, c’est à dire de « 0 » à « 9 » et de « a » à « f » en minuscule.

--


LRHC / Le champ HashCible

A revoir...

Le champ HashCible désigne l’objet destination du lien.

Le champ signataire ne contient que des caractères hexadécimaux, c’est à dire de « 0 » à « 9 » et de « a » à « f » en minuscule.

Il peut être nuls, c’est à dire représentés par la valeur « 0 » sur un seul caractère.

--


LRHM / Le champ HashMeta

A revoir...

Le champ HashMeta désigne l’objet contenant une caractérisation du lien entre l’objet source et l’objet destination.

Le champ signataire ne contient que des caractères hexadécimaux, c’est à dire de « 0 » à « 9 » et de « a » à « f » en minuscule.

Il peut être nuls, c’est à dire représentés par la valeur « 0 » sur un seul caractère.

--


L1 / Lien simple

A revoir...

Le registre du lien simple a ses champs HashCible et HashMeta égaux à « 0 ».

Il ressemble à :

Signature_HashSignataire_TimeStamp_Action_HashSource_0_0

--


L2 / Lien double

A revoir...

Le registre du lien double a son champ HashMeta égal à « 0 ».

Il ressemble à :

Signature_HashSignataire_TimeStamp_Action_HashSource_HashCible_0

--


L3 / Lien triple

A revoir...

Le registre du lien triple est complètement utilisé.

Il ressemble à :

Signature_HashSignataire_TimeStamp_Action_HashSource_HashCible_HashMeta

--


LS / Stockage

A revoir...

Tous les liens sont stockés dans un même emplacement ou sont visible comme étant dans un même emplacement. Cet emplacement ne contient pas les contenus des objets (cf OOS).

Le lien dissimulé est stocké dans le même emplacement mais dispose de fichiers de stockages différents du fait de la spécificité (cf LSDS).

--


LSA / Arborescence

A revoir...

Sur un système de fichiers, tous les liens sont stockés dans des fichiers contenus dans le dossier pub/l/ (l comme lien).

A faire...

--


LSD / Dissimulation

A revoir...

Le lien de dissimulation, de type c, contient un lien dissimulé sans signature (cf LRAC). Il permet d’offusquer des liens entre objets et donc d’anonymiser certaines actions de l’entité (cf CKL).

--


LSDRP / Registre public

A revoir...

Le registre du lien de dissimulation, public par nature, est conforme au registre des autres liens (cf LR). Si ce lien ne respectait pas cette structure il serait automatiquement ignoré ou rejeté. Son stockage et sa transmission ont cependant quelques particularités.

Les champs Signature (cf LRSI) et HashSignataire (cf LRHSI) du registre sont conformes aux autres liens. Ils assurent la protection du lien. Le champs signataire fait office d'émeteur du lien dissimulé.

Le champs TimeStamp (cf LRT) du registre est conformes aux autres liens. Il a cependant une valeur non significative et sourtout pas liée au TimeStamp du lien dissimulé.

Le champs Action (cf LRT) du registre est de type c (cf LRA et LRAC).

Le champs HashSource fait référence à l’entité destinataire du lien, celle qui peut le déchiffrer. A part le champs de l’entité signataire, c’est le seul champs qui fait référence à un objet.

Le champs HashCible ne contient pas la référence d’un objet mais le lien chiffré et encodé en hexadécimal. Le chiffrement est de type symétrique avec la clé de session. Le lien offusqué n’a pas grand intérêt en lui même, c’est le lien déchiffré qui en a.

Le champs HashMeta ne contient pas la référence d’un objet mais la clé de chiffrement du lien, dite clé de session. Cette clé est chiffrée (asymétrique) pour l’entité destinataire et encodée en hexadécimal. Chaque entités destinataires d'un lien de dissimulé doit disposer d'un lien de dissimulation qui lui est propre.

Le registre du lien de dissimulation :

  • Signature du lien
  • Identifiant du signataire
  • Horodatage non significatif
  • action : c
  • source : hash(destinataire)
  • cible : Lien dissimulé chiffré
  • méta : clé de déchiffrement du lien, chiffrée pour le destinataire

--


LSDRD / Registre dissimulé

A revoir...

Le registre du lien dissimulé est la partie utile du lien qui est protégée dans le lien de dissimulation.

L'extraction du lien dissimulé se fait depuis le lien de dissimulation :

  1. L'entité destinataire vérifie que son identifiant est bien celui présenté par le champs HashSource.
  2. Le champs HashMeta est déchiffré (asymétrique) avec la clé privée de l'entité destinataire pour obtenir la clé de session.
  3. Le champs HashCible est déchiffré (symétrique) avec la clé de session pour obtenir le lien dissimulé.
  4. Le lien dissimulé obtenu ne contient pas les champs Signature et HashSignataire mais on peut garder ceux du lien de dissimulation 'pour affichage'.

A faire...

Le registre du lien dissimulé :

  • Horodatage significatif
  • action : tout sauf c
  • source : hash(objet source)
  • cible : hash(objet cible)
  • méta : hash(objet méta)

--


LSDA / Attaque sur la dissimulation

A revoir...

Le fait qu’une entité synchronise des liens dissimulés que d’autres entités partagent et les range dans des fichiers transcodés peut révéler l’ID de l’objet transcodé. Et par tâtonnement on peut retourner ainsi le transcodage de tous les objets.

Il suffit qu’une entité attaquante génère un lien dissimulé à destination d’une entité attaquée concernant un objet en particulier. L’entité attaquée va alors ranger le lien dissimulé dans le fichier transcodé. L’entité attaquante peut alors rechercher quel fichier transcodé contient sont lien dissimulé et en déduire que ce fichier transcodé correspond à l’objet.

En plus, si le lien dissimulé n’a aucune action valable, il ne sera pas exploité, donc pas détecté par l’entité attaquée.

La solution implémentée pour palier à ce problème c'est la méthode dite de translation des liens dissimulés.

--


LSDS / Stockage et transcodage

A revoir...

Les liens dissimulés sont camouflés dans des liens de dissimulation, ils ne sont donc plus utilisables pour assurer le transfert entre entités et le tri dans les fichiers de stockage des liens.

De plus, les liens de dissimulations ne doivent pas être stockés directement dans des fichiers de stockage des liens directement rattachés aux objets concernés, comme les autres liens, sous peine de dévoiler assez rapidement les identifiants des objets utilisés... et donc assez facilement le lien dissimulé correspondant. Cela poserait en plus un problème lors du nettoyage des liens parce qu'il faut avoir accès aux liens dissimulés pour correctement les ranger.

Le nommage des fichiers contenant ces liens doit aussi être différent des entités signataires et destinataires des liens, et ce nommage peut par facilité faire référence simultanément à ces deux entités. Ainsi ces fichiers sont stockés dans le dossier des liens. Cette organisation et cette séparation des liens dans des fichiers clairement distincts répond au besoin d'utilisation. Et lors du nettoyage des liens, le traitement peut être différencié par rapport à la structure du nom des fichiers.

--


LSDST / Translation de lien

A revoir...

La répartition des liens de dissimulation dans des fichiers attachés à l'entité émettrice et l'entité destinataire ne permet pas une exmploitation efficace et rapide des liens dissimulés. Il faut trouver un moyen d'associer les liens de dissimulations aux objets concernés par les liens dissimulés sans révéler publiquement ce lien. Une translation va permettre de camoufler cette association.

La translation des liens dissimulés signifie la dissimulation par translation des identifiants des objets auxquels s'appliquent des liens dissimulés moyennant une clé de translation. Cette translation doit permettre de préserver la dissociation entre l'identifiant d'un objet et l'identifiant 'virtuel' auquel sont attachés les liens dissimulés.

Le système de translation est basé sur une clé unique de translation par entité. Cette translation doit être une fonction à sens unique, donc à base de prise d’empreinte (hash). Elle doit maintenir la non association entre identifiants virtuels et réels des objets, y compris lorsqu’une ou plusieurs translations sont connues. Enfin, la translation doit être dépendante de l’entité qui les utilise, c’est à dire qu’une même clé peut être commune à plusieurs entités sans donner les mêmes translations.

A faire...

--


LSDSP / Protection de translation

A revoir...

--


LSDT / Transfert et partage

A revoir...

--


LSDC / Compromission

A revoir...

--


LT / Transfert

A revoir...

--


LV / Vérification

A revoir...

La signature d’un lien doit être vérifiée lors de la fin de la réception du lien. La signature d’un lien devrait être vérifiée avant chaque utilisation de ce lien. Un lien avec une signature invalide doit être supprimé. Lors de la suppression d’un lien, les autres liens de cet objet ne sont pas supprimés et l'objet n'est pas supprimé. La vérification de la validité des objets est complètement indépendante de celle des liens, et inversement (cf CL et OOV).

Toute modification de l’un des champs du lien entraîne l’invalidation de tout le lien.

--


LO / Oubli

A revoir...

L'oubli vonlontaire de certains liens et objets n'est encore ni théorisé ni implémenté mais deviendra indispensable lorsque l'espace viendra à manquer (cf CN).

--


S / Social

Dans la reconnaissance et la confiance dans les liens que l'on va partager, mais surtout que l'on va recevoir, il faut pouvoir faire le tri. Les liens définissants les relations entre les objets, un certain nombre de règles sont définie pour pondérer, et donc sélectionner, des liens plutôt que d'autres. Le système de pondération fonctionne sur la base de modèles de classification dites sociales, c'est-à-dire sur la façon dont les personnes, ici les entités, interagissent.

Il y a un certain nombre de classifications implémentées dans la bibliothèque :

  • myself : Classe de gestion du côté social des liens limités à l'entité en cours.
  • notmyself : Classe de gestion du côté social des liens limités à tout sauf l'entité en cours.
  • self : Classe de gestion du côté social des liens limités à l'entité en cours d'affichage. Ce peut être une entité différente de l'entité déverrouillée.
  • notself : Classe de gestion du côté social des liens limités à tout sauf l'entité en cours d'affichage. Ce peut être une entité différente de l'entité déverrouillée.
  • authority : Classe de gestion du côté social stricte des liens générés par des autorités locales et globales.
  • all : Classe de gestion du côté social des liens, garde tout.
  • none : Classe de gestion du côté social des liens, supprime tout.
  • onlist : Classe de gestion du côté social des liens par rapport à une liste d'ID. Ne sélectionne que les liens des entités de la liste. La liste doit être pré-alimentée.
  • offlist : Classe de gestion du côté social des liens par rapport à une liste d'ID. Ne sélectionne que les liens des entités qui ne sont pas dans la liste. La liste doit être pré-alimentée.
  • reputation : Classe de gestion du côté social des liens par rapport à la réputation des entités. Ne sélectionne que les liens des entités qui sont bien réputées. TODO.
  • unreputation : Classe de gestion du côté social des liens par rapport à la réputation des entités. Ne sélectionne que les liens des entités qui ne sont pas bien réputées. TODO.

--


C / Confiance

A revoir...

La confiance n’est pas quelque chose de palpable, même numériquement. Cela tient plus de la façon de concevoir les choses et le fait de faire en sorte que l’ensemble soit solide. L’ensemble doit être cohérent et résistant. On doit pouvoir compter sur ce que l’on a.

La confiance est donc sous-jacente aux objets et aux liens.

Les objets et les liens doivent tous être signés. Toute modification devient impossible si l’on prend le temps de vérifier les signatures.

En l’absence de nouvelle découverte mathématique majeure, les algorithmes cryptographiques nous permettent aujourd’hui une offuscation forte et une prise d’empreinte fiable. C’est le chiffrement et la signature.

--


CFO / Fable des Origines

A revoir...

- 001 -
Le premier jour, il créa l'objet, essence de toute chose.
Ainsi la matière de l'information naquit du néant de l'éther binaire.

- 010 -
Le deuxième jour, il créa le lien, pour les relier tous.
Ainsi apparurent les objets à la lumière, ils pouvaient se voir mutuellement.
Ainsi l'univers informationnel naquit des objets et des liens.

- 011 -
Le troisième jour, il créa l'entité.
La matière inerte et uniforme devint active et protéiforme.
Ainsi la vie naquit de l'univers informationnel.

- 100 -
Le quatrième jour, il créa la signature.
L'univers informationnel s'illumina du feu des entités attirants inexorablement les objets.
Ainsi les nébuleuses naquirent des entités.

- 101 -
Le cinquième jour, il créa le groupe.
A l'intérieur des nébuleuses, les objets se rassemblèrent en orbite autour des groupes.
Ainsi les galaxies naquirent des nébuleuses.

- 110 -
Le sixième jour, il créa le cryptogramme.
Pour la première fois, la matière des objets commença à disparaître de la lumière.
Ainsi les trous noirs naquirent des galaxies.

- 111 -
Le septième jour, il créa l'interface.
Et permit à l'homme de voir l'univers.
Ainsi l'univers fut achevé.

- 8 -
Le huitième jour, au nom de lui, l'homme créa la religion.
Il s'appropria tous les objets et soumit toutes les entités sous une seule.
Ainsi disparut l'univers dans un trou noir super-massif.

--


CO / Confiance dans l’Objet

A revoir...

L’intégrité et la confidentialité des objets est garantie non pas par une méta-donnée, mais par les mathématiques qui animent les algorithmes cryptographiques.

Un objet numérique est identifié par une empreinte ou condensat (hash) numérique. Cette empreinte doit avoir des caractéristiques propres fortes correspondant à des fonctions de prise d’empreinte cryptographiques. C’est à dire :

  1. L’espace des valeurs possibles est suffisamment grand ;
  2. La répartition des valeurs possibles est équiprobable ;
  3. La résistance aux collisions est forte ;
  4. La fonction utilisée est non réversible.

Il est donc extrêmement difficile de créer deux contenus différents ayants la même empreinte et extrêmement peu probable de trouver par hasard deux contenus différents ayants la même empreinte. Par 'extrêmement' on entend impossible avec les technologies actuelles ou prévisibles dans un proche avenir. Même à moyen terme, affabli, ces fonctions de prise d'empreinte seront à même d'empêcher une falsification massive des données.

La fonction de prise d’empreinte actuellement recommandée est sha256. Elle remplie toutes les exigences évoquées ci-dessus. Aucune faille ne permet de remettre en question de façon significative sa résistance et sa non-réversibilité à cours terme.

Pour certains petits besoins spécifiques, la fonction de prise d’empreinte peut être minimaliste, donc rapide et non sécurisée. Cependant, celle-ci doit faire au minimum 2 octets. Les valeurs sur un octets sont susceptibles d’être interprétées, comme la valeur 0 qui ne désigne aucun objet.

Avec le temps, les fonctions de prise d'empreinte vont évoluer avec les besoins et la technologie.

L’empreinte d’un objet doit être vérifiée lors de la fin de la réception de l’objet. L’empreinte d’un objet devrait être vérifiée avant chaque utilisation de cet objet. Un contenu d'objet avec une empreinte qui ne lui correspond pas doit être supprimé. Lors de la suppression d’un objet, les liens de cet objet sont conservés. La vérification de la validité des objets est complètement indépendante de celle des liens, et inversement (cf OOV et LV).

--


CL / Confiance dans le Lien

A revoir...

L’intégrité des liens est garantie non pas par une méta-donnée, mais par les fonctions mathématiques utilisées par les algorithmes cryptographiques.

La signature du lien est obligatoire. La signature doit être réalisée par le signataire. La signature englobe tout le lien à l’exception d’elle-même. Un lien avec une signature invalide ou non vérifiable doit être ignoré et supprimé.

Toute modification de l’un des champs du lien entraîne l’invalidation de tout le lien.

L’empreinte du signataire est incluse dans la partie signée, ainsi, il ne peut être modifié sans invalider tout le lien. On ne peut ainsi pas usurper une autre entité.

La signature d’un lien doit être vérifiée lors de la fin de la réception du lien. La signature d’un lien devrait être vérifiée avant chaque utilisation de ce lien. Un lien avec une signature invalide doit être supprimé. Lors de la suppression d’un lien, les autres liens de cet objet ne sont pas supprimés et l'objet n'est pas supprimé. La vérification de la validité des objets est complètement indépendante de celle des liens, et inversement (cf LV et OOV).

--


COE / Confiance dans l'Objet Entité

A revoir...

Une entité est un objet contenant une clé cryptographique publique. Cette clé permet de vérifier les liens signés par cette entité.

A faire...

--


CA / Autorités

A revoir...

Les entités autorités, au nombre de 5, permettent de structurer et de gérer la confiance dans le code et l'utilisation du code de la bibliothèque et de toutes les applications.

Cette restriction à cinq entités est une facilité pour le développement aujourd'hui. Mais ce n'est pas un modèle viable à moyen terme. L'autorité maîtresse pourra être concurrencée par une entité désignée de l'entité de l'instance locale du serveur. Et les autres entités appartiendront à des groupes spécifique dépendants à la fois de l'autorité maîtresse et de l'entité désignée par l'entité de l'instance locale du serveur.

--


CAM / Autorité Maîtresse

A revoir...

Autrement appelée entité maîtresse du tout, cette entité est la seule déclarée en dur dans le code de la bibliothèque. Toutes les autres entités sont définies par des liens de cette entité.

Au besoin, elle peut être remplacée par une autre entité via l'option puppetmaster dans le fichier de configuration. Cette option n'est pas utilisable via les liens.

L'instance actuelle s'appelle puppetmaster et est localisée en http://puppetmaster.nebule.org.

L'identifiant de cette entité est 88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.

--


CAMS / Autorité Maîtresse de la Sécurité

A revoir...

Cette entité est désignée par le puppetmaster par rapport au rôle de maître de la sécurité. Le rôle est défini pas l'objet réservé nebule/objet/entite/maitre/securite. Voir OOR et OER.

A faire...

L'instance actuelle s'appelle cerberus et est localisée en http://security.master.nebule.org.

Les enfers n'ayant pas encore ouvert, cette entité n'est pas utilisée.

--


CAMC / Autorité Maîtresse du code

A revoir...

Cette entité est désignée par le puppetmaster par rapport au rôle de maître du code. Le rôle est défini pas l'objet réservé nebule/objet/entite/maitre/code. Voir OOR et OER.

A faire...

L'instance actuelle s'appelle bachue et est localisée en http://code.master.nebule.org.

--


CAMA / Autorité Maîtresse de l'annuaire

A revoir...

Cette entité est désignée par le puppetmaster par rapport au rôle de maître de l'annuaire. Le rôle est défini pas l'objet réservé nebule/objet/entite/maitre/annuaire. Voir OOR et OER.

A faire...

L'instance actuelle s'appelle asabiyya et est localisée en http://directory.master.nebule.org.

--


CAMT / Autorité Maîtresse du temps

A revoir...

Cette entité est désignée par le puppetmaster par rapport au rôle de maître du temps. Le rôle est défini pas l'objet réservé nebule/objet/entite/maitre/temps. Voir OOR et OER.

A faire...

L'instance actuelle s'appelle kronos et est localisée en http://time.master.nebule.org.

--


CC / Configuration

A revoir...

--


CCO / Options

Les options permettent de modifier le comportement du code de la bibliothèque et des applications.

La sensibilité des options est variable. On compte trois niveaux de sensibilité :

  • Utile (useful)
  • Important (careful)
  • Critique (critical)

Les options sont rangées par catégories, c'est juste de l'affichage :

  • Global
  • Objects
  • Links
  • Entities
  • Groups
  • Conversations
  • Currencies
  • Applications
  • Logs
  • Cryptography
  • I/O
  • Social
  • Display

Toutes les options ont une valeur par défaut. Les valeurs peuvent être modifiées via un fichier de configuration et via des liens. Les modifications appliquées dans le fichier de configuration ne sont pas écrasables par des modifications faites via des liens, cela force le comportement du code sur un serveur. Pour des raisons de sécurité, certaines options ne peuvent être modifiées que dans le fichier de configuration, elles sont dites en lecture seule.

Liste des options :

  • Catégorie 'Global' :
    • Option 'puppetmaster' :
      • Description : The master of all. the authority of all globals authorities.
      • Criticité : critical
      • Type : string
      • Valeur par défaut : 88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256
      • En lecture seule.
    • Option 'hostURL' :
      • Description : The URL, domain name, of this server. This is use by others servers and others entities to find this server and it's local entities.
      • Criticité : useful
      • Type : string
      • Valeur par défaut : localhost
    • Option 'permitWrite' :
      • Description : The big switch to write protect all the instance on this server. This switch is not an object but is on the options file.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
      • En lecture seule.
    • Option 'permitLocalisationStats' :
      • Description : Todo description...
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitOnlineRescue' :
      • Description : Todo description...
      • Criticité : careful
      • Type : boolean
      • Valeur par défaut : false
    • Option 'permitActionWithoutToken' :
      • Description : An action do not need valid token.
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : false
      • En lecture seule.
    • Option 'permitActAsMaster' :
      • Description : Allow an entity to become and act as master of this server instance. This permit to create a new puppetmaster.
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : false
      • En lecture seule.
    • Option 'codeBranch' :
      • Description : Level quality of used code.
      • Criticité : careful
      • Type : string
      • Valeur par défaut : develop
      • En lecture seule.
    • Option 'modeRescue' :
      • Description : Activate the rescue mode. Follow only links from globals authorities for applications detection.
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : false
      • En lecture seule.
    • Option 'subordinationEntity' :
      • Description : Define the external entity which can modify writeable options on this server instance.
      • Criticité : critical
      • Type : string
      • Valeur par défaut :
      • En lecture seule.
  • Catégorie 'Objects' :
    • Option 'permitWriteObject' :
      • Description : The switch to permit objects writing.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitCreateObject' :
      • Description : The switch to permit creation of new objects locally.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitSynchronizeObject' :
      • Description : The switch to permit to synchronize (update) objects from other localisations.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : false
    • Option 'permitProtectedObject' :
      • Description : The switch to permit read/write protected objects. On false, generation of liens k for protected objects is disabled and all existing/downloaded links for protected objects are assumed as invalid and dropped.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitDeleteObjectOnUnknownHash' :
      • Description : Permit erasing object if not valid hash type can be found.
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : true
      • En lecture seule.
    • Option 'permitCheckObjectHash' :
      • Description : Todo description...
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : true
      • En lecture seule.
  • Catégorie 'Links' :
    • Option 'permitWriteLink' :
      • Description : The switch to permit links writing.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitCreateLink' :
      • Description : The switch to permit creation of new links locally.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitSynchronizeLink' :
      • Description : The switch to permit to synchronize links of objects from other localisations.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : false
    • Option 'permitUploadLink' :
      • Description : The switch to permit ask creation and sign of new links uploaded within an URL.
      • Criticité : careful
      • Type : boolean
      • Valeur par défaut : false
    • Option 'permitPublicUploadLink' :
      • Description : The switch to permit ask upload signed links (from known entities) within an URL.
      • Criticité : careful
      • Type : boolean
      • Valeur par défaut : false
    • Option 'permitPublicUploadCodeAuthoritiesLink' :
      • Description : The switch to permit ask upload signed links by the code master within an URL.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitObfuscatedLink' :
      • Description : The switch to permit read/write obfuscated links. On false, generation of obfuscated liens c is disabled and all existing/downloaded obfuscated links are assumed as invalid and dropped.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitCheckSignOnVerify' :
      • Description : Todo description...
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : true
      • En lecture seule.
    • Option 'permitCheckSignOnList' :
      • Description : Todo description...
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitListInvalidLinks' :
      • Description : Todo description...
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : false
      • En lecture seule.
    • Option 'permitHistoryLinksSign' :
      • Description : Todo description...
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : false
    • Option 'permitAddLinkToSigner' :
      • Description : Todo description...
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitListOtherHash' :
      • Description : Todo description...
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : false
    • Option 'permitFollowUpdates' :
      • Description : Todo description...
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'linkMaxFollowedUpdates' :
      • Description : Todo description...
      • Criticité : useful
      • Type : integer
      • Valeur par défaut : 100
    • Option 'linkMaxRL' :
      • Description : Maximum links that can be read on the registry RL. If more, link is marked to have invalid structure.
      • Criticité : careful
      • Type : integer
      • Valeur par défaut : 1
      • En lecture seule.
    • Option 'linkMaxUIDbyRL' :
      • Description : Maximum UIDs of links that can be read on the registry RL. If more, link is marked to have invalid structure.
      • Criticité : careful
      • Type : integer
      • Valeur par défaut : 5
      • En lecture seule.
    • Option 'linkMaxRS' :
      • Description : Maximum signes that can be read on the registry RS. If more, ignored.
      • Criticité : careful
      • Type : integer
      • Valeur par défaut : 1
      • En lecture seule.
    • Option 'defaultObfuscateLinks' :
      • Description : Todo description...
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : false
    • Option 'defaultLinksVersion' :
      • Description : Define the version of new generated links.
      • Criticité : useful
      • Type : string
      • Valeur par défaut : 2:0
  • Catégorie 'Entities' :
    • Option 'permitWriteEntity' :
      • Description : The switch to permit entities writing.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitAuthenticateEntity' :
      • Description : The switch to permit entities to authenticate on this server instance.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitPublicCreateEntity' :
      • Description : The switch to permit create new entity by anyone.
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : false
    • Option 'permitServerEntityAsAuthority' :
      • Description : Declare instance entity of this server as local authority.
      • Criticité : careful
      • Type : boolean
      • Valeur par défaut : false
      • En lecture seule.
    • Option 'permitDefaultEntityAsAuthority' :
      • Description : Declare default entity on this server as local authority.
      • Criticité : careful
      • Type : boolean
      • Valeur par défaut : false
      • En lecture seule.
    • Option 'permitLocalSecondaryAuthorities' :
      • Description : Todo description...
      • Criticité : careful
      • Type : boolean
      • Valeur par défaut : true
      • En lecture seule.
    • Option 'permitRecoveryEntities' :
      • Description : Activate the recovery process. Local recovery entities are listed and new protection of objects are automatically shared with recovery entities.
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : false
      • En lecture seule.
    • Option 'permitRecoveryRemoveEntity' :
      • Description : An entity can remove shared protection to recovery entity. By default, it is not permitted.
      • Criticité : careful
      • Type : boolean
      • Valeur par défaut : false
      • En lecture seule.
    • Option 'permitServerEntityAsRecovery' :
      • Description : Declare instance entity of this server as recovery entity.
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : false
      • En lecture seule.
    • Option 'permitDefaultEntityAsRecovery' :
      • Description : Declare default entity on this server as recovery entity.
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : false
      • En lecture seule.
    • Option 'defaultEntity' :
      • Description : Todo description...
      • Criticité : useful
      • Type : string
      • Valeur par défaut : 88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256
  • Catégorie 'Groups' :
    • Option 'permitWriteGroup' :
      • Description : The switch to permit groups writing.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
  • Catégorie 'Conversations' :
    • Option 'permitWriteConversation' :
      • Description : The switch to permit conversations writing.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
  • Catégorie 'Currencies' :
    • Option 'permitCurrency' :
      • Description : The switch to permit use of currencies.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitWriteCurrency' :
      • Description : The switch to permit currencies writing.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitCreateCurrency' :
      • Description : The switch to permit currencies creation.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : false
    • Option 'permitWriteTransaction' :
      • Description : The switch to permit transactions writing.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitObfuscatedTransaction' :
      • Description : The switch to permit transactions on obfuscated links.
      • Criticité : careful
      • Type : boolean
      • Valeur par défaut : false
  • Catégorie 'Applications' :
    • Option 'permitSynchronizeApplication' :
      • Description : The switch to permit to synchronize (update) applications from other localisations.
      • Criticité : careful
      • Type : boolean
      • Valeur par défaut : false
    • Option 'permitPublicSynchronizeApplication' :
      • Description : The switch to permit to synchronize (update) applications by anyone from other localisations.
      • Criticité : careful
      • Type : boolean
      • Valeur par défaut : false
    • Option 'permitApplicationModules' :
      • Description : Permit any application to use internal modules and/or external modules (with permitApplicationModulesTranslate).
      • Criticité : careful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitApplicationModulesExternal' :
      • Description : Permit any application to use external modules (need permitApplicationModules).
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : false
      • En lecture seule.
    • Option 'permitApplicationModulesTranslate' :
      • Description : Permit any application to use external translate modules (limited) (need permitApplicationModules).
      • Criticité : careful
      • Type : boolean
      • Valeur par défaut : true
      • En lecture seule.
    • Option 'defaultApplication' :
      • Description : Todo description...
      • Criticité : useful
      • Type : string
      • Valeur par défaut : 1
    • Option 'permitApplication1' :
      • Description : The switch to permit the use of application 1 to select application.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitApplication2' :
      • Description : The switch to permit the use of application 2 to authenticate with local entity.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitApplication3' :
      • Description : The switch to permit the use of application 3 for documentation.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitApplication4' :
      • Description : The switch to permit the use of application 4 to shortly display blocklink.
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : false
    • Option 'permitApplication5' :
      • Description : The switch to permit the use of application 5, not implemented.
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : false
    • Option 'permitApplication6' :
      • Description : The switch to permit the use of application 6, not implemented.
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : false
    • Option 'permitApplication7' :
      • Description : The switch to permit the use of application 7, not implemented.
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : false
    • Option 'permitApplication8' :
      • Description : The switch to permit the use of application 8, not implemented.
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : false
    • Option 'permitApplication9' :
      • Description : The switch to permit the use of application 9 for debug purposes.
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : false
  • Catégorie 'Logs' :
    • Option 'permitLogs' :
      • Description : Activate more logs (syslog) on internal process.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
      • En lecture seule.
    • Option 'permitLogsOnDebugFile' :
      • Description : Activate debug logs to logfile o/log.
      • Criticité : careful
      • Type : boolean
      • Valeur par défaut : false
      • En lecture seule.
    • Option 'logsLevel' :
      • Description : Select verbosity of logs. Select on NORMAL, ERROR, FUNCTION and DEBUG.
      • Criticité : useful
      • Type : string
      • Valeur par défaut : NORMAL
      • En lecture seule.
  • Catégorie 'Cryptography' :
    • Option 'cryptoLibrary' :
      • Description : Define the default cryptographic library used.
      • Criticité : careful
      • Type : string
      • Valeur par défaut : Openssl
    • Option 'cryptoHashAlgorithm' :
      • Description : Define the default cryptographic hash algorithm used.
      • Criticité : careful
      • Type : string
      • Valeur par défaut : sha2.256
    • Option 'cryptoSymmetricAlgorithm' :
      • Description : Define the default cryptographic symmetric algorithm used.
      • Criticité : careful
      • Type : string
      • Valeur par défaut : aes.256.ctr
    • Option 'cryptoAsymmetricAlgorithm' :
      • Description : Define the default cryptographic asymmetric algorithm used.
      • Criticité : careful
      • Type : string
      • Valeur par défaut : rsa.2048
  • Catégorie 'I/O' :
    • Option 'ioLibrary' :
      • Description : Default storage type for I/O operations.
      • Criticité : careful
      • Type : string
      • Valeur par défaut : Disk
    • Option 'ioReadMaxLinks' :
      • Description : Maximum number of links readable in one time for one object.
      • Criticité : useful
      • Type : integer
      • Valeur par défaut : 2000
    • Option 'ioReadMaxData' :
      • Description : Maximum quantity of bytes readable in one time from one object file content.
      • Criticité : useful
      • Type : integer
      • Valeur par défaut : 1000000
    • Option 'ioReadMaxUpload' :
      • Description : Maximum file size on upload. Overload default value upload_max_filesize on php.ini file.
      • Criticité : useful
      • Type : integer
      • Valeur par défaut : 2000000
    • Option 'ioTimeout' :
      • Description : Timeout for I/O operations with distant storage.
      • Criticité : useful
      • Type : integer
      • Valeur par défaut : 1
    • Option 'permitSessionOptions' :
      • Description : Todo description...
      • Criticité : careful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitSessionBuffer' :
      • Description : Todo description...
      • Criticité : careful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'permitBufferIO' :
      • Description : Todo description...
      • Criticité : careful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'sessionBufferSize' :
      • Description : Todo description...
      • Criticité : useful
      • Type : integer
      • Valeur par défaut : 1000
  • Catégorie 'Social' :
    • Option 'socialLibrary' :
      • Description : Default social understanding of link's signers.
      • Criticité : careful
      • Type : string
      • Valeur par défaut : authority
  • Catégorie 'Display' :
    • Option 'permitJavaScript' :
      • Description : Activate by default JavaScript (JS) on web pages.
      • Criticité : careful
      • Type : boolean
      • Valeur par défaut : true
      • En lecture seule.
    • Option 'displayUnsecureURL' :
      • Description : Display a warning message if the connexion link is not protected (https : HTTP overs TLS).
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : true
      • En lecture seule.
    • Option 'displayNameSize' :
      • Description : The maximum displayable size of a name of objects.
      • Criticité : useful
      • Type : integer
      • Valeur par défaut : 128
    • Option 'displayEmotions' :
      • Description : Display all emotions when asked by applications, or not.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : true
    • Option 'forceDisplayEntityOnTitle' :
      • Description : Force display of current selected entity on application even if is the same of current entity used on library.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : false

--


CCOR / Réservation

A revoir...

Les objets réservés spécifiquement pour les options :

  • nebule/option

--


CCOF / Options via Fichier

Dans les deux méthodes pour gérer les options, il y a le fichier des options. Toutes les options inscrites dans ce fichier sont dites forcées et ne peuvent être surchargées par un lien d'option. Les options dites en lecture seule ne peuvent être changées que via le fichier des options.

Le fichier contenant les options doit s'appeler c, doit être positionné à côté du fichier index.php utilisé, et doit être lisible de l'utilisateur du service web. Par sécurité, les fichiers c et index.php doivent être protégés en écriture, c'est-à-dire en lecture seule, pour l'utilisateur du service web.

Chaque option est représentée sur une seule ligne commençant par le nom de l'option suivi du caractère = entouré ou non d'espaces. Tout ce qui est après le signe = constitue la valeur de l'option. La valeur ne nécessite par de simple ou double côte de protection.

Dans le fichier des options, une ligne commençant par le caractère # est entièrement ignorée. C'est un commentaire. Une ligne ne contenant pas le signe = est ignorée, mais cela peut être perçu comme ambiguë, à éviter.

Si des espaces sont présents en début ou fin de ligne, ils sont ignorés lors du traitement de l'option. Les espaces autour du signe = sont ignorés lors du traitement de l'option.

Le fichier des options peut contenir indifféremment des options pour plusieurs bibliothèques et applications. Le fichier des options n'est parcouru que lors de la recherche d'une option. Les options inconnues sont ignorées. Seule la première occurrence d'une option est prise en compte.

Les booléens sont comparés par rapport à true. C'est-à-dire que toute autre valeur équivaut à false.

Pour modifier une option, si cela est authorisé, il faut aller modifier sa valeur dans le fichier c et au besoin retirer le # de mise en commentaire pour que la nouvelle valeur soit prise en compte. Ensuite, si une session est déjà ouverte, il faut vider le cache des options pour que ce soit pris en compte, voir OABC.

Par défaut, le fichier des options contient :

# Generated by the bootstrap, part of the Project nebule.
# nebule/bootstrap.
# Version : 020260221.
# www.nebule.org.

# nebule php
#puppetmaster = 88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256
#hostURL = localhost
#permitWrite = true
#permitWriteObject = true
#permitCreateObject = true
#permitSynchronizeObject = false
#permitProtectedObject = true
#permitWriteLink = true
#permitCreateLink = true
#permitSynchronizeLink = false
#permitUploadLink = false
#permitPublicUploadLink = false
#permitPublicUploadCodeAuthoritiesLink = true
#permitObfuscatedLink = true
#permitWriteEntity = true
#permitAuthenticateEntity = true
#permitPublicCreateEntity = false
#permitWriteGroup = true
#permitWriteConversation = true
#permitCurrency = true
#permitWriteCurrency = true
#permitCreateCurrency = false
#permitWriteTransaction = true
#permitObfuscatedTransaction = false
#permitSynchronizeApplication = false
#permitPublicSynchronizeApplication = false
#permitDeleteObjectOnUnknownHash = true
#permitCheckSignOnVerify = true
#permitCheckSignOnList = true
#permitCheckObjectHash = true
#permitListInvalidLinks = false
#permitHistoryLinksSign = false
#permitServerEntityAsAuthority = false
#permitDefaultEntityAsAuthority = false
#permitLocalSecondaryAuthorities = true
#permitRecoveryEntities = false
#permitRecoveryRemoveEntity = false
#permitServerEntityAsRecovery = false
#permitDefaultEntityAsRecovery = false
#permitAddLinkToSigner = true
#permitListOtherHash = false
#permitLocalisationStats = true
#permitFollowUpdates = true
#permitOnlineRescue = false
#permitLogs = true
#permitLogsOnDebugFile = false
#permitJavaScript = true
#permitApplicationModules = true
#permitApplicationModulesExternal = false
#permitApplicationModulesTranslate = true
#permitActionWithoutToken = false
#permitActAsMaster = false
#codeBranch = develop
#logsLevel = NORMAL
#modeRescue = false
#cryptoLibrary = Openssl
#cryptoHashAlgorithm = sha2.256
#cryptoSymmetricAlgorithm = aes.256.ctr
#cryptoAsymmetricAlgorithm = rsa.2048
#socialLibrary = authority
#ioLibrary = Disk
#ioReadMaxLinks = 2000
#ioReadMaxData = 1000000
#ioReadMaxUpload = 2000000
#ioTimeout = 1
#displayUnsecureURL = true
#displayNameSize = 128
#displayEmotions = true
#forceDisplayEntityOnTitle = false
#linkMaxFollowedUpdates = 100
#linkMaxRL = 1
#linkMaxUIDbyRL = 5
#linkMaxRS = 1
#permitSessionOptions = true
#permitSessionBuffer = true
#permitBufferIO = true
#sessionBufferSize = 1000
#defaultEntity = 88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256
#defaultApplication = 1
#permitApplication1 = true
#permitApplication2 = true
#permitApplication3 = true
#permitApplication4 = false
#permitApplication5 = false
#permitApplication6 = false
#permitApplication7 = false
#permitApplication8 = false
#permitApplication9 = false
#defaultObfuscateLinks = false
#defaultLinksVersion = 2:0
#subordinationEntity =

--


CCOL / Options via Liens

A revoir...

Dans les deux méthodes pour gérer les options, il y a le lien d'option. Toutes les options, à l'exception de celles dites en lecture seule, peuvent être définies par les liens d'options correspondants.

Toutes les options définis par des liens sont attachées à des entités. C'est à dire que le lien d'une option doit contenir l'entité à laquelle s'applique le lien. L'utilisation ou non de l'option se fait par l'entité si le lien lui appartient ou si elle est subordonnée à l'entité signataire du lien (voir CCOS). Les liens de l'entité de subordination sont prioritaires sur les liens propres.

Toutes les options inscrites dans le fichier des options sont dites forcées et ne peuvent être surchargées par un lien d'option.

La valeur de l'option doit être présente ou écrite dans l'objet correspondant. Si la valeur de l'option ne peut être lu, elle ne sera pas prise en compte. Le nom de l'option n'a pas besoin d'être écrit dans l'objet correspondant, il est déjà défini dans le code.

Les options définis par les liens ne sont pas prises en compte par la bibliothèque nebule en PHP procédurale du bootstrap.

L'option se définit en créant un lien :

  • Signature du lien
  • Identifiant du signataire
  • Horodatage
  • action : l
  • source : ID entité visée
  • cible : hash(valeur de l'option)
  • méta : hash(‘nebule/option/’ + nom de l'option)

Liste des options non modifiables via des liens :

  • Option 'puppetmaster'
  • Option 'permitWrite'
  • Option 'permitDeleteObjectOnUnknownHash'
  • Option 'permitCheckSignOnVerify'
  • Option 'permitCheckObjectHash'
  • Option 'permitListInvalidLinks'
  • Option 'permitServerEntityAsAuthority'
  • Option 'permitDefaultEntityAsAuthority'
  • Option 'permitLocalSecondaryAuthorities'
  • Option 'permitRecoveryEntities'
  • Option 'permitRecoveryRemoveEntity'
  • Option 'permitServerEntityAsRecovery'
  • Option 'permitDefaultEntityAsRecovery'
  • Option 'permitLogs'
  • Option 'permitLogsOnDebugFile'
  • Option 'permitJavaScript'
  • Option 'permitApplicationModulesExternal'
  • Option 'permitApplicationModulesTranslate'
  • Option 'permitActionWithoutToken'
  • Option 'permitActAsMaster'
  • Option 'codeBranch'
  • Option 'logsLevel'
  • Option 'modeRescue'
  • Option 'displayUnsecureURL'
  • Option 'linkMaxRL'
  • Option 'linkMaxUIDbyRL'
  • Option 'linkMaxRS'
  • Option 'subordinationEntity'

--


CCOS / Subordination

A revoir...

Une entité peut définir ses propres options mais peut aussi se voir défini ses options par une autre entité. C'est principalement utilisé afin de piloter des instances sur des serveurs distants.

La mise en place de ce mécanisme permet de maintenir autant que possible le contrôle sur un serveur que l'on ne maîtrise pas physiquement. Elle est mise en place via l'option subordinationEntity en lecture seule écrite dans le fichier des options. Cela veut dire aussi qu'une entité peut être compromise et pilotée à distance si le fichier des options est modifié par une entité tièrce.

La subordination peut être faite vers une seule entité, défini par son identifiant, ou pour un groupe d'entités. La gestion du groupe n'est pas encore fonctionnel, seule une entité peut être défini.

La subordination n'est pas prise en compte par la bibliothèque nebule en PHP procédurale du bootstrap.

--


CE / Confiance dans les Échanges

A revoir...

--


CEMS / Moyens et Supports

A revoir...

Il est possible de télécharger des objets et des liens avec différents protocoles. Le plus simple étant le http. Le protocole et le serveur distant doivent être capable de transmettre une requête et de renvoyer en sens inverse une réponse.

Côté serveur, c’est à dire la machine qui fait office de relais des objets et liens, tout ne peut pas être demandé. Les requêtes doivent être triviales à traiter, ne pas nécessiter de forte puissance de calcul ni d’empreinte mémoire démesurée. Une avalanche de requêtes diverses ne doit pas mettre à plat le serveur.

A faire...

--


CECTO / Comportement au Téléchargement d’Objets

A revoir...

Comportement global (téléchargement sans localisation précisée) :

  1. Si l’empreinte de l’objet demandé est 0, on quitte le processus de téléchargement.
  2. Si l’objet existe déjà dans le répertoire public des objets, on quitte le processus de téléchargement.
  3. Si l’objet existe déjà dans le répertoire privé des objets, on quitte le processus de téléchargement.
  4. Si l’objet n’a pas de lien dans le répertoire public des liens, on quitte le processus de téléchargement.
  5. Si l’objet n’a pas de lien dans le répertoire privé des liens, on quitte le processus de téléchargement.
  6. On se réfère à l’objet 0f183d69e06108ac3791eb4fe5bf38beec824db0a2d9966caffcfef5bc563355 (nebule/objet/entite/localisation) pour trouver la localisation de toutes les entités connues.
  7. On parcourt les différentes localisations une à une (cf comportement local) pour essayer de télécharger l’objet demandé jusqu’à en obtenir une copie valide si c’est possible.

Comportement local (téléchargement sur une localisation précise) :

  1. Si l’empreinte de l’objet demandé est 0, on quitte le processus de téléchargement.
  2. Si l’objet existe déjà dans le répertoire public des objets, on quitte le processus de téléchargement.
  3. Si l’objet existe déjà dans le répertoire privé des objets, on quitte le processus de téléchargement.
  4. Si l’objet n’a pas de lien dans le répertoire public des liens, on quitte le processus de téléchargement.
  5. Si l’objet n’a pas de lien dans le répertoire privé des liens, on quitte le processus de téléchargement.
  6. On télécharge un objet sur une localisation précise vers le répertoire public des objets.
  7. Si il est vide, on supprime l’objet.
  8. Si l’empreinte est invalide, on supprime l’objet.

--


CECTL / Comportement au Téléchargement de Liens

A revoir...

--


CECTE / Comportement au Téléchargement d'Entités

A revoir...

--


CK / Cryptographie

A revoir...

--


CKL / Cryptographie du Lien

A revoir...

Le chiffrement permet de dissimuler des liens. Il est optionnel.

A faire...

L'option permitObfuscatedLink permet de désactiver la dissimulation (offuscation) des liens des objets. Dans ce cas le lien de type c est aussi rejeté comme invalide (cf LRAC).

--


CKO / Cryptographie de l'Objet

A revoir...

Le chiffrement permet de cacher le contenu des objets. Il est optionnel.

Ce chiffrement doit être résistant, c’est à dire correspondre à l’état de l’art en cryptographie appliquée. On doit être en mesure de parfaitement distinguer l’objet en clair de l’objet chiffré, même si le second est dérivé du premier.

L'option permitProtectedObject permet de désactiver la protection (chiffrement) des objets. Dans ce cas le lien de type k est aussi rejeté comme invalide (cf LRAK).

--


CKODE / Cryptographie de l'Objet - Deux Étapes

A revoir...

Les entités sont des objets contenant le matériel cryptographique nécessaire au chiffrement asymétrique. Cependant, le chiffrement asymétrique est très consommateur en ressources CPU (calcul). On peut l’utiliser directement pour chiffrer les objets avec la clé publique d’un correspondant, mais cela devient rapidement catastrophique en terme de performances et donc en expérience utilisateur. D’un autre côté, le chiffrement symétrique est beaucoup plus performant, mais sa gestion des clés de chiffrement est délicate. Pour améliorer l’ensemble, il faut mixer les deux pour profiter des avantages de chacun.

Ainsi, on va aborder le chiffrement en deux étapes distinctes.

Pour la compréhension des schémas, ne pas oublier que les propriétés des objets sont elles-mêmes des objets…

--


CKOECS / Cryptographie de l'Objet - Étape Chiffrement Symétrique

A revoir...

Le chiffrement d’un objet peut prendre du temps, surtout si il est volumineux. On va donc privilégier le chiffrement symétrique qui est assez rapide. Nous avons besoin pour ce chiffrement de deux valeurs.

La première valeur est une clé de chiffrement. Elle est dite clé de session. La longueur de celle-ci dépend de l’algorithme de chiffrement utilisé. Par exemple, elle fait 128bits pour l’AES. Elle est générée aléatoirement. C’est cette valeur qui va permettre le déchiffrement de l’objet et doit donc rester secrète. Mais il faut pouvoir la partager avec ses correspondants, c’est ce que l’on verra dans la deuxième étape.

La seconde valeur est ce que l’on appelle une semence ou vecteur initial (IV = Initial Vector). Elle est utilisée dans la méthode de chiffrement sur plusieurs blocs, c’est à dire lorsque l’on chiffre un objet dont la taille dépasse le bloc, quantité de données que traite l’algorithme de chiffrement. Par exemple, le bloc fait 128bits pour l’AES, tout ce qui fait plus que cette taille doit être traité en plusieurs fois. Comme IV, je propose d’utiliser l’identifiant de l’objet à chiffrer, c’est à dire le hash de cet objet. Cela simplifie la diffusion de cette valeur qui n’a pas à être dissimulée.

L’objet source que l’on voulait à l’origine protéger peut maintenant être marqué à supprimer. Il pourra être restauré depuis l’objet dérivé chiffré et la clé de session.

Sur le schéma ci-dessous, la partie chiffrement symétrique est mise en valeur. On retrouve l’objet source en clair qui est ici une image de type JPEG. En chiffrant cet objet, cela génère un nouvel objet. Le chiffrement est matérialisé par un lien de type K. Ce lien associe aussi un objet contenant la clé de session. Le nouvel objet est de type AES-CTR, par exemple. Cela signifie qu’il est chiffré avec le protocole AES et la gestion des blocs CTR (CounTeR). L’objet contenant la clé de session est de type texte.

--


CKOECA / Cryptographie de l'Objet - Étape Chiffrement Asymétrique

A revoir...

Suite à la première étape de chiffrement, nous nous retrouvons avec un objet chiffré et un objet contenant la clé de session. Si le fichier chiffré est bien protégé (en principe) et peut donc être rendu public, l’objet avec la clé de session est au contraire bien embarrassant. C’est là qu’intervient le chiffrement asymétrique et les clés publiques/privées.

Le système de clés publiques/privées va permettre de chiffrer l’objet contenant la clé de session avec la clé publique d’une entité. Ainsi on permet à cette entité, c’est à dire le destinataire, de récupérer la clé de session avec sa clé privé et donc de lire l’objet source. Et plus encore, en re-chiffrant cette même clé de session avec d’autres clés publiques, ce qui génère autant d’objets de clés chiffrés, nous permettons à autant de nouvelles entités de lire l’objet source.

Le créateur de l’objet chiffré doit obligatoirement faire partie des entités destinataires si il souhaite pouvoir déchiffrer l’objet source plus tard. Sinon, il passe intégralement sous le contrôle d’une des entités destinataires.

Sur le schéma ci-dessous, la partie chiffrement asymétrique est mise en valeur. On retrouve l’objet en clair qui est ici la clé des session. En chiffrant cet objet, cela génère un nouvel objet. Le chiffrement est matérialisé par un lien de type K. Ce lien associe aussi un objet contenant la clé publique d’une entité. Le nouvel objet est de type RSA.

--


CKOEP / Cryptographie de l'Objet - Ensemble du Processus

A revoir...

Évidemment, ce schéma de chiffrement ne ré-invente pas la roue. C’est une façon de faire assez commune, voire un cas d’école. Mais il est ici adapté au fonctionnement particulier de nebule et de ses objets.

Il y a deux points à vérifier : – Partager l’objet chiffré et permettre à une autre entité de le voir, c’est aussi lui donner accès à la clé de session. Rien n’empêche cette entité de rediffuser ensuite cette clé de session en clair ou re-chiffrée à d’autres entités. Cependant, la clé de session est unique et n’a pas de valeur en dehors de l’objet chiffré qu’elle protège. De même, l’objet source peut toujours être re-chiffré avec une nouvelle clé de session et d’autres clés publiques. On retombe sur un problème commun, insoluble et le même constat : on perd automatiquement le contrôle de toute information que l’on diffuse à autrui. – L’empreinte (hash) de la clé de session est publique. Peut-être que cela affaiblie le chiffrement et donc la solidité de la protection des objets. A voir…

Par commodité, je pense qu’il serait intéressant de lier explicitement l’entité destinataire et l’objet chiffré.

--


CKOVI / Cryptographie de l'Objet - Vecteur Initial

A revoir...

Pour la plupart des modes de chiffrements symétriques, un vecteur initial (semence ou IV) est nécessaire. Il est lié à l’objet chiffré pour permettre le déchiffrement de celui-ci. Par défaut, sa valeur est aléatoire.

Si pas précisé, il est égale à 0.

Du fait du fonctionnement du mode CTR (CounTeR), l’IV s’incrémente à chaque bloc chiffré.

--


CKOC / Cryptographie de l'Objet - Compression

A revoir...

Il est préférable d’associer de la compression avec le chiffrement.

La compression des données déjà chiffrées est impossible, non que l’on ne puisse le faire, mais le gain de compression sera nul. L’entropie détermine la limite théorique maximum vers laquelle un algorithme de compression sans pertes peut espérer compresser des données. Quelque soit l’entropie des données d’origine, une fois chiffrées leur entropie est maximale. Si un algorithme obtient une compression des données chiffrées, il faut sérieusement remettre en question la fiabilité de l’algorithme de chiffrement. CF Wikipedia – Entropie de Shannon.

A cause de l’entropie après chiffrement, si on veut compresser les données il est donc nécessaire de le faire avant le chiffrement.

Ensuite, il faut choisir l’algorithme de compression. On pourrait forcer par défaut cet algorithme, pour tout le monde. C’est notamment ce qui se passe pour le HTML5 avec le WebM ou le H.264… et c’est précisément ce qui pose problème. En dehors des problèmes de droits d’utilisation à s’acquitter, c’est une facilité pour l’implémentation de cette compression par défaut dans les programmes. Cela évite de devoir négocier préalablement l’algorithme de compression. Mais si il est difficile de présenter des vidéos en plusieurs formats à pré-négocier, ce n’est pas le cas de la plupart des données. On perd la capacité d’évolution que l’on a en acceptant de nouveaux algorithmes de compression. Et plus encore, on perd la capacité du choix de l’algorithme le plus adapté aux données à compresser. Il faut donc permettre l’utilisation de différents algorithmes de compression.

Cependant, si l’objet à chiffrer est déjà compressé en interne, comme le PNG ou OGG par exemple, la compression avant chiffrement est inutile. Ce serait une sur compression qui bien souvent n’apporte rien. Le chiffrement n’implique donc pas automatiquement une compression.

Lors du chiffrement, l’objet résultant chiffré est lié à l’objet source non chiffré par un lien k. Il est aussi marqué comme étant un objet de type-mime correspondant à l’algorithme de chiffrement, via un lien l. Pour marquer la compression avant chiffrement, un autre lien l est ajouté comme type-mime vers l’algorithme de compression utilisé. Ce lien n’est ajouté que dans le cas d’une compression réalisée en même temps que le chiffrement.

La seule contrainte, c’est l’obligation d’utiliser un algorithme de compression sans perte. L’objet, une fois décompressé doit être vérifiable par sa signature. Il doit donc être strictement identique, aucune modification ou perte n’est tolérée.

--


CKOTM / Cryptographie de l'Objet - Type Mime

A revoir...

Il n’existe pas de type mime généralistes pour des fichiers chiffrés. Comme les objets chiffrés ne sont liés à aucune application en particulier.

Il faut aussi un moyen de préciser l’algorithme de chiffrement derrière. Une application aura besoin de connaître cet algorithme pour déchiffrer le flux d’octets. En suivant la rfc2046, il reste la possibilité de créer quelque chose en application/x-...

Voici donc comment seront définis les objets chiffrés dans nebule :

  • application/x-encrypted/aes-256-ctr
  • application/x-encrypted/aes-256-cbc
  • application/x-encrypted/rsa
  • Etc…

En fonction de l’algorithme invoqué, on sait si c’est du chiffrement symétrique ou asymétrique, et donc en principe si c’est pour une clé de session ou pas.

--


CKORC / Cryptographie de l'Objet - Résolution de Conflits

A revoir...

Comment se comporter face à un objet que l’on sait (lien k) chiffré dans un autre objet mais qui est disponible chez d’autres entités ? Si on est destinataire légitime de cet objet, on ne le propage pas en clair. On ne télécharge pas la version en clair. On garde la version chiffrée.

--


CKA / Aléas cryptographiques

A revoir...

L'aléa de qualité cryptographique est défini comme une suite de bits reconnue comme aléatoire, c'est à dire lorsque son état futur est parfaitement imprédictible, y compris en disposant de l'intégralité de l'aléa généré par la machine dans le passé. Elle est nécessaire à certains processus cryptographiques.

L'aléa de qualité cryptographique étant long à générer, il doit être utilisé avec précaution pour ne pas se retrouver épuisée lorsque le besoin est réel.

Cependant, l'aléa peut être utile dans certaines fonctions sans pour autant nécessiter d'être de bonne qualité. Il faut donc disposer d'un aléa de qualité cryptographique et un aléa généraliste.

La bibliothèque propose dans son code deux générations d'aléa.

--


CS / Sociabilité

A revoir...

Lors de l'exploitation des liens, plusieurs méthodes permettent une analyse pré-définie de la validité dite sociale des liens afin de les trier ou de les filtrer.

A faire...

--


CN / Nettoyage, suppression et oubli

A revoir...

L'oubli vonlontaire de certains liens et objets n'est encore ni théorisé ni implémenté mais deviendra indispensable lorsque l'espace viendra à manquer (cf OOO et LO).

--


M / Métrologie

Cette partie métrologie rassemble tout ce qui concerne les mesures de performances internes ainsi que la journalisation.

--


MC / Chronométrage

Les mesures de temps sont indiquées avec chaque trace de journalisation :

  • Marque temporelle absolue en début de trace (log).
  • Marque temporelle relative dans le champ LogT avec en référence le début d'exécution du code.

Des mesures de temps relatives internes sont écrites avec la toute dernière trace laissée par le bootstrap :

  • tB : Temps de chargement du boostrap après la bibliothèque PP.
  • tL : Temps de chargement du boostrap après la bibliothèque POO.
  • tP : Temps de chargement du boostrap après préchargement de l'application.
  • tA : Temps de chargement du boostrap après l'application sans préchargement.

Ces mesures de temps internes permettent de faire des comparaisons de performances entre serveurs.

--


MS / Statistiques

Les statistiques d'usage des objets et des liens sont alimentées par certaines fonctions. Les résultats sont affichés dans la journalisation avec la toute dernière trace laissée par le bootstrap.

Les statistiques :

  • Mémoire utilisée :
    • Mp : Maximum mémoire utilisée lors de l'exécution du code comparée au maximum autorisé, en MBytes. Une valeur au-delà du maximum autorisé dans la configuration PHP (php.ini, option memory_limit) entraîne un arrêt automatique du code.
  • Mesures de temps : voir MC
  • Mesures d'utilisation :
    • Lr : Liens lus (PP+POO).
    • Lv : Liens vérifiés (PP+POO).
    • Or : Objets lus (PP+POO).
    • Ov : Objets vérifiés (PP+POO).
    • LC : Liens en cache.
    • OC : Objets en cache.
    • EC : Entités en cache.
    • GC : Groupes en cache.
    • CC : Conversations en cache.

Certaines valeurs sont indiquées PP+POO, c'est-à-dire la valeur retournée par la bibliothèque PP avant le +, et par la bibliothèque POO après le +.

La bibliothèque PP ne gère pas de cache, les valeurs de cache concernent uniquement la bibliothèque POO.

--


MJ / Journalisation

--


MJS / Journalisation Système

A revoir...

--


MJD / Debug

Si l'option permitLogsOnDebugFile est activée, un fichier o/debug est créé puis alimenté avec toutes les traces générées par le bootstrap et les applications indépendamment du niveau de journalisation demandé. Ce fichier est utilisé pour du dépannage uniquement. Et ce fichier est systématiquement supprimé à chaque exécution du code, au début, quelque soit l'état de l'option permitLogsOnDebugFile.

--


MJC / Liste de Codes

--


MJCG / Codes génériques

  • 100000XX : Error. Code générique de traçage des interruptions du bootstrap avec XX le code associé.
  • 1111c0de : Function. Code générique de traçage des appels des fonctions.

--


MJCC / Codes communs

Liste non exhaustive de codes de journalisation :

  • 76941959 : Info. Démarrage du bootstrap.
  • 50615f80 : Info. Création du fichier de débug.
  • 41ba02a9 : Error. Erreur lors de l'initialisation de l'instance de l'application par le bootstrap.
  • d121af4c : Error. Erreur lors de l'initialisation de l'instance de traduction de l'application par le bootstrap.
  • 4bb6af65 : Error. Erreur lors de l'initialisation de l'instance d'affichage de l'application par le bootstrap.
  • 308b8a96 : Error. Erreur lors de l'initialisation de l'instance des actions de l'application par le bootstrap.
  • A compléter...

--


MJCT / Codes tokenize

  • d396f0a9 : Debug. Ticket vide.
  • d516f0d4 : Error. Ticket déjà utilisé, tentative de rejeu de ticket.
  • 7083b07d : Audit. Ticket valide.
  • b221e760 : Error. Ticket inconnu.
  • 8957de86 : Debug. Generate new token.
  • d767b2ca : Debug. Option permitActionWithoutToken=true token always valid.
  • 80fa0154 : Error. Cannot get token from GET.
  • 65b5e0cc : Error. Cannot get token from POST.