Documentation technique de nebule – 020190821

Documentation technique de nebule
Version 1.3 – 020190821 Developpement
(c) GNU GPL 2010-2019 Projet nebule – www.nebule.org

— Copie en attendant la mise en ligne —

Table des matières

F / Fondations

Le but du projet nebule, c’est le moteur de gestion des objets. La couche basse qui s’occupe du stockage des objets et liens, et de leur diffusion.

L’interface utilisateur est un programme utilisé pour manipuler ces objets et traduire les liens à l’utilisateur ou les actions de l’utilisateur en liens.

Le projet nebule se concrétise numériquement par trois piliers de base :

  1. l’objet
  2. le lien
  3. la confiance

O / Objet

L’objet est le contenant de toutes les informations.

OO / Objet

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).

OON / Nommage

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

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

A faire…

OOD / Dissimulation

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 faire…

OOC / Création

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
  • source : ID de l’objet
  • cible : hash du nom de l’algorithme de prise d’empreinte
  • méta : 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
  • source : ID de l’objet
  • cible : hash(type de l’objet)
  • méta : hash(‘nebule/objet/type’)

A faire…

OOS / Stockage

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

A faire…

OOSA / Arborescence

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 faire…

OOR / Réservation

Les différentes 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/modules
  • 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/option
  • nebule/danger
  • nebule/warning
  • nebule/reference
  • nebule/arborescence

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

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

OOIO / Implémentation des Options

A faire…

OOIA / Implémentation des Actions

A faire…

OOV / Vérification

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).

OOO / 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).

OE / Entité

A faire…

L’entité est un objet caractéristique. Elle dispose d’une clé publique, par laquelle elle est identifiée, et d’une clé privée.

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

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.

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 assabyia. Voir CAMA.
  5. Maître du temps. L’instance actuelle s’appelle kronos. Voir CAMT.

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

A faire…

OED / Dissimulation

A faire…

OEL / Liens

A faire…

OEC / Création

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

On extrait la clé publique du bi-clé. 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 du bi-clé. 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).

A partir de maintenant, le bi-clé 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 :
    • Signature du lien par la clé privée de la nouvelle entité
    • Identifiant de la clé publique
    • Horodatage
    • Lien de type l
    • Identifiant de la clé publique
    • Empreinte de l’algorithme de hash utilisé pour le calcul des empreintes
    • Empreinte de ‘nebule/objet/hash’
  • Lien 2 :
    • Signature du lien par la clé privée de la nouvelle entité
    • Identifiant de la clé publique
    • Horodatage
    • Lien de type l
    • Identifiant de la clé privée
    • Empreinte de l’algorithme de hash utilisé pour le calcul des empreintes
    • Empreinte de ‘nebule/objet/hash’
  • Lien 3 :
    • Signature du lien par la clé privée de la nouvelle entité
    • Identifiant de la clé publique
    • Horodatage
    • Lien de type l
    • Identifiant de la clé publique
    • Empreinte de ‘application/x-pem-file’
    • Empreinte de ‘nebule/objet/type’
  • Lien 4 :
    • Signature du lien par la clé privée de la nouvelle entité
    • Identifiant de la clé publique
    • Horodatage
    • Lien de type l
    • Identifiant de la clé privée
    • Empreinte de ‘application/x-pem-file’
    • Empreinte de ‘nebule/objet/type’
  • Lien 5 :
    • Signature du lien par la clé privée de la nouvelle entité
    • Identifiant de la clé publique
    • Horodatage
    • Lien de type f ;
    • Identifiant de la clé privée
    • Identifiant de la clé publique
    • 0.

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

Si le mot de passe de la clé privée est définit 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

Voir OOS, pas de particularité de stockage.

OET / Transfert

A faire…

OER / Réservation

A faire…

OEIO / Implémentation des Options

A faire…

OEIA / Implémentation des Actions

A faire…

OEO / 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).

OR / Référence

A faire…

ORN / Nommage

A faire…

ORP / Protection

A faire…

ORD / Dissimulation

A faire…

ORL / Liens

A faire…

ORC / Création

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

A faire…

ORS / Stockage

Voir OOS, pas de particularité de stockage.

ORT/ Transfert

A faire…

ORR / Réservation

A faire…

ORIO / Implémentation des Options

A faire…

ORIA / Implémentation des Actions

A faire…

ORO / 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).

OG / Groupe

Le groupe est un objet définit comme tel, c’est à dire qu’il doit avoir un type mime 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 si 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.

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.

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.

La création d’un objet virtuel comme groupe 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 006e6562756c652f6f626a65742f67726f757065. Soit un identifiant complet de la taille de 104 caractères.

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 méta :

  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 ajouter 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 on filtre sur les membres uniquement ajoutés par des entités définies.

Dans nebule, l’objet réservé nebule/objet/groupe/ferme est dédié à la gestion des groupes fermés. Un groupe est considéré fermé 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 champs cible on utilise une autre entité, cela revient à prendre aussi en compte ses liens dans le groupe fermé. Dans ce cas c’est une entité contributrice.

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

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.

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.

OGPM / Protection des membres

Le groupe va contenir un certain nombre de membres ajouter 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 champs 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.

OGDM / Dissimulation des membres

Le groupe va contenir un certain nombre de membres ajouter 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é 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 champs 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.

OGL / Liens

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
    • source : ID du groupe
    • cible : hash(‘nebule/objet/groupe’)
    • méta : hash(‘nebule/objet/type’)
  • Le lien de suppression d’un groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • source : ID du groupe
    • cible : hash(‘nebule/objet/groupe’)
    • méta : hash(‘nebule/objet/type’)
  • Le lien de suivi du groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID de l’entité, par défaut l’entité signataire
    • cible : ID du groupe
    • méta : hash(‘nebule/objet/groupe/suivi’)
  • Le lien de suppression de suivi du groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • source : ID de l’entité, par défaut l’entité signataire
    • cible : ID du groupe
    • méta : hash(‘nebule/objet/groupe/suivi’)
  • Le lien de dissimulation d’un groupe est le lien de définition caché dans une lien de type c.
  • Le lien de rattachement d’un membre du groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID du groupe
    • cible : ID de l’objet
    • méta : ID du groupe
  • Le lien de suppression de rattachement d’un membre du groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • source : ID du groupe
    • cible : ID de l’objet
    • méta : ID du groupe
  • Le lien de fermeture d’un groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID du groupe
    • cible : ID de l’entité, par défaut l’entité signataire
    • méta : hash(‘nebule/objet/groupe/ferme’)
  • Le lien de suppression de fermeture d’un groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • source : ID du groupe
    • cible : ID de l’entité, par défaut l’entité signataire
    • méta : hash(‘nebule/objet/groupe/ferme’)
  • Le lien de protection des membres d’un groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID du groupe
    • cible : ID de l’entité, par défaut l’entité signataire
    • méta : 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
    • source : ID du groupe
    • cible : ID de l’entité, par défaut l’entité signataire
    • méta : hash(‘nebule/objet/groupe/protege’)
  • Le lien de dissimulation des membres d’un groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID du groupe
    • cible : ID de l’entité, par défaut l’entité signataire
    • méta : 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
    • source : ID du groupe
    • cible : ID de l’entité, par défaut l’entité signataire
    • méta : hash(‘nebule/objet/groupe/dissimule’)

OGC / Création

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
    • source : ID du groupe
    • cible : hash(‘nebule/objet/groupe’)
    • méta : hash(‘nebule/objet/type’)
  • Le lien de nommage du groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID du groupe
    • cible : hash(nom du groupe)
    • méta : hash(‘nebule/objet/nom’)
  • Le lien de suivi du groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID de l’entité, par défaut l’entité signataire
    • cible : ID du groupe
    • méta : 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
    • source : ID du groupe
    • cible : ID de l’entité, par défaut l’entité signataire
    • méta : hash(‘nebule/objet/groupe/ferme’)
  • Le lien de protection des membres d’un groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID du groupe
    • cible : ID de l’entité, par défaut l’entité signataire
    • méta : hash(‘nebule/objet/groupe/protege’)
  • Le lien de dissimulation des membres d’un groupe :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID du groupe
    • cible : ID de l’entité, par défaut l’entité signataire
    • méta : hash(‘nebule/objet/groupe/dissimule’)

OGS / Stockage

Voir OOS, pas de particularité de stockage.

OGT / Transfert

A faire…

OGR / Réservation

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

OGIO / Implémentation des Options

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

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.

OC / Conversation

La conversation est un objet définit comme tel, c’est à dire qu’il 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 message. 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 méta :

  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 champs 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, 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
    • source : ID de la conversation
    • cible : hash(‘nebule/objet/conversation’)
    • méta : hash(‘nebule/objet/type’)
  • Le lien de suppression d’une conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • source : ID de la conversation
    • cible : hash(‘nebule/objet/conversation’)
    • méta : hash(‘nebule/objet/type’)
  • Le lien de suivi de la conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID de l’entité, par défaut l’entité signataire
    • cible : ID de la conversation
    • méta : hash(‘nebule/objet/conversation/suivie’)
  • Le lien de suppression de suivi de la conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • source : ID de l’entité, par défaut l’entité signataire
    • cible : ID de la conversation
    • méta : 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
    • source : ID de la conversation
    • cible : ID de l’objet
    • méta : 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
    • source : ID de la conversation
    • cible : ID de l’objet
    • méta : ID de la conversation
  • Le lien de fermeture d’une conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID de la conversation
    • cible : ID de l’entité, par défaut l’entité signataire.
    • méta : hash(‘nebule/objet/conversation/fermee’)
  • Le lien de suppression de fermeture d’une conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : x
    • source : ID de la conversation
    • cible : ID de l’entité, par défaut l’entité signataire.
    • méta : hash(‘nebule/objet/conversation/fermee’)
  • Le lien de protection des membres d’une conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID de la conversation
    • cible : ID de l’entité, par défaut l’entité signataire.
    • méta : 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
    • source : ID de la conversation
    • cible : ID de l’entité, par défaut l’entité signataire.
    • méta : hash(‘nebule/objet/conversation/protegee’)
  • Le lien de dissimulation des membres d’une conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID de la conversation
    • cible : ID de l’entité, par défaut l’entité signataire.
    • méta : 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
    • source : ID de la conversation
    • cible : ID de l’entité, par défaut l’entité signataire.
    • méta : 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
    • source : ID de la conversation
    • cible : hash(‘nebule/objet/conversation’)
    • méta : hash(‘nebule/objet/type’)
  • Le lien de nommage de la conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID de la conversation
    • cible : hash(nom de la conversation)
    • méta : hash(‘nebule/objet/nom’)
  • Le lien de suivi de la conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID de l’entité, par défaut l’entité signataire
    • cible : ID de la conversation
    • méta : 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
    • source : ID de la conversation
    • cible : ID de l’entité, par défaut l’entité signataire
    • méta : hash(‘nebule/objet/conversation/ferme’)
  • Le lien de protection des membres d’une conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID de la conversation
    • cible : ID de l’entité, par défaut l’entité signataire
    • méta : hash(‘nebule/objet/conversation/protege’)
  • Le lien de dissimulation des membres d’une conversation :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID de la conversation
    • cible : ID de l’entité, par défaut l’entité signataire
    • méta : 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.

OL / Localisation

A faire…

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 faire…

OLP / Protection

A faire…

OLD / Dissimulation

A faire…

OLL / Liens

A faire…

OLC / Création

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

A faire…

OLS / Stockage

Voir OOS, pas de particularité de stockage.

OLT / Transfert

A faire…

OLR / Réservation

A faire…

OLIO / Implémentation des Options

A faire…

OLIA / Implémentation des Actions

A faire…

OA / Application

A faire…

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

Un application qui ne fait que lire des objets et liens, ou retrasmettre 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 paticuliè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é à 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, objets ;
  • 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 variables personnalisées :

  • $applicationName
  • $applicationSurname
  • $applicationDescription
  • $applicationVersion
  • $applicationLevel
  • $applicationLicence
  • $applicationAuthor
  • $applicationWebsite

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.

OAN / Nommage

A faire…

OAP / Protection

A faire…

OAD / Dissimulation

A faire…

OAL / Liens

A faire…

OAC / Création

A faire…

OAS / Stockage

Voir OOS, pas de particularité de stockage.

OAT / Transfert

A faire…

OAR / Réservation

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

  • nebule/objet/applications

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.

A faire…

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

  • bootstrap : le chargeur initial de la librairie et des applications, OAIGB.
  • sylabe : l’application de référence des possibilités de nebule, OAIGS, blog.sylabe.org.
  • klicty : l’application de partage d’objets à durée limitée, OAIGk, blog.klicty.org.
  • messae : l’application de gestion des conversations et messages, OAIGM, blog.messae.org.
  • option : l’application de gestion des options, OAIGO.
  • upload : l’application de chargement de mises à jours, OAIGU.
  • defolt : l’application pour un affichage par défaut sans application interactive, OAIGD.
Nb
break
Me
messae
No
option
Nd
defolt
Kl
klicty
Nu
upload
Sy
sylabe

OAIN / Nommage

A faire…

OAIP / Protection

A faire…

OAID / Dissimulation

A faire…

OAIL / Liens

A faire…

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

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 en quelque sorte 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 24

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

e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687

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 :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID de l’application
    • cible : hash du nom de l’algorithme de prise d’empreinte
    • méta : hash(‘nebule/objet/hash’)
  • Le lien de définition de type application :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID de l’application
    • cible : hash(‘nebule/objet/interface/web/php/applications’)
    • méta : hash(‘nebule/objet/type’)
  • Le lien de nommage long de l’application :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID de l’application
    • cible : hash(nom long de l’application)
    • méta : hash(‘nebule/objet/nom’)
  • Le lien de nommage court de l’application :
    • Signature du lien
    • Identifiant du signataire
    • Horodatage
    • action : l
    • source : ID de l’application
    • cible : hash(nom court de l’application)
    • méta : 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

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 :

  • Signature du lien
  • Identifiant du signataire
  • Horodatage
  • action : f
  • source :
  • cible :
  • méta :

Exemple de modèle d’application :

<?php
// ------------------------------------------------------------------------------------------
$applicationName		= 'Share';
$applicationSurname		= 'Share All';
$applicationDescription	= 'Web page for sharing all you want.';
$applicationVersion		= '020190109';
$applicationLevel		= 'Developpement'; // Experimental | Developpement | Testing | Production
$applicationLicence		= 'GNU GPL 2019';
$applicationAuthor		= 'Me';
$applicationWebsite		= 'notme.nebule.org';
// ------------------------------------------------------------------------------------------



/*
 ------------------------------------------------------------------------------------------
 /// 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 !
   / V \   [EN] Any changes to this code will cause a chage in its footprint and therefore
  /__°__\         automatically result in its invalidation!
     N     [ES] Cualquier cambio en el código causarán un cambio en su presencia y por lo
     N            tanto lugar automáticamente a su anulación!
     N
     N                                                                       Projet nebule
 ----N-------------------------------------------------------------------------------------
 /// WARNING /// WARNING /// WARNING /// WARNING /// WARNING /// WARNING /// WARNING ///
 ------------------------------------------------------------------------------------------
 */



/**
 * Classe Application
 * @author Me
 *
 * Le coeur de l'application.
 *
 */
class Application extends Applications
{
	/**
	 * Constructeur.
	 *
	 * @param nebule $nebuleInstance
	 * @return void
	 */
	public function __construct(nebule $nebuleInstance)
	{
		$this->_nebuleInstance = $nebuleInstance;
	}

	// Tout par défaut.
}



/**
 * Classe Display
 * @author Me
 */
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()
	{
		global $applicationVersion, $applicationLevel, $applicationLicence, $applicationWebsite,
				$applicationName, $applicationSurname, $applicationAuthor;
		?>
<!DOCTYPE html>
<html>
	<body>
		Hello
	</body>
</html>
<?php
	}
}



/**
 * Classe Action
 * @author Me
 */
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', 'DEBUG'); // Log

		// Rien.

		$this->_metrology->addLog('Generic actions end', 'DEBUG'); // Log
	}
	

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

		// Rien.
		
		$this->_metrology->addLog('Special actions end', 'DEBUG'); // Log
	}
}



/**
 * Classe Traduction
 * @author Me
 */
class Traduction extends Traductions
{
	/**
	 * Constructeur.
	 *
	 * @param Application $applicationInstance
	 * @return void
	 */
	public function __construct(Application $applicationInstance)
	{
		$this->_applicationInstance = $applicationInstance;
	}
	
	
	
	/**
	 * Initialisation de la table de traduction.
	 */
	protected function _initTable()
	{
		$this->_table['fr-fr']['::::INFO']='Information';
		$this->_table['en-en']['::::INFO']='Information';
		$this->_table['es-co']['::::INFO']='Information';
		$this->_table['fr-fr']['::::OK']='OK';
		$this->_table['en-en']['::::OK']='OK';
		$this->_table['es-co']['::::OK']='OK';
		$this->_table['fr-fr']['::::INFORMATION']='Message';
		$this->_table['en-en']['::::INFORMATION']='Message';
		$this->_table['es-co']['::::INFORMATION']='Mensaje';
		$this->_table['fr-fr']['::::WARN']='ATTENTION !';
		$this->_table['en-en']['::::WARN']='WARNING!';
		$this->_table['es-co']['::::WARN']='¡ADVERTENCIA!';
		$this->_table['fr-fr']['::::ERROR']='ERREUR !';
		$this->_table['en-en']['::::ERROR']='ERROR!';
		$this->_table['es-co']['::::ERROR']='¡ERROR!';

		$this->_table['fr-fr']['::::RESCUE']='Mode de sauvetage !';
		$this->_table['en-en']['::::RESCUE']='Rescue mode!';
		$this->_table['es-co']['::::RESCUE']='¡Modo de rescate!';
	}
}
OAICE / Enregistrement

Le lien d’enregistrement de l’application :

  • Signature du lien
  • Identifiant du signataire
  • Horodatage
  • action : l
  • source :
  • cible :
  • méta :

A faire…

OAIU / Mise à Jour

A faire…

OAIS / Stockage

Voir OOS, pas de particularité de stockage.

OAIT / Transfert

A faire…

OAIR / Réservation

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

  • 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

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

A faire…

OAIGS / Sy – sylabe

A faire…

OAIGK / Kl – klicty

A faire…

OAIGM / Me – messae

A faire…

OAIGO / No – option

A faire…

OAIGU / Nu – upload

A faire…

OAIGD / Nd – defolt

A faire…

OAM / Module

A faire…

OAMN / Nommage

A faire…

OAMP / Protection

A faire…

OAMD / Dissimulation

A faire…

OAML / Liens

A faire…

OAMC / Création

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

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

  • nebule/objet/interface/web/php/applications/modules
  • nebule/objet/interface/web/php/applications/modules/active

OAIO / Implémentation des Options

A faire…

OAIA / Implémentation des Actions

A faire…

L / Lien

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

LELPO / Liens à Propos d’un Objet

Les liens d’un objet sont consultables séquentiellement. Il 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 champs.

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

LELCO / Liens Contenu dans un Objet

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 peux pas s’en servir facilement pour de l’anonymisation.

LE / Entête

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 transmit avec les liens, en premier.

LR / Registre

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 champs 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

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 alpha-numériques en minuscule.

LRHSI / Le champ HashSignataire

Le champ signataire 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

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

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.

LRAF / Action f Dérivé d’objet

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.

LRAU / Action u Mise à jour d’objet

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

u comme update.

LRAD / Action d Suppression d’objet

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

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. 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.

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 émetrices 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

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

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

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

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

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

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

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

Il ressemble à :

Signature_HashSignataire_TimeStamp_Action_HashSource_HashCible_0

L3 / Lien triple

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

Il ressemble à :

Signature_HashSignataire_TimeStamp_Action_HashSource_HashCible_HashMeta

LS / Stockage

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

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

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).

LSDA / Attaque sur la dissimulation

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

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 faire…

LSDSP / Protection de translation

A faire…

LSDT / Transfert et partage

A faire…

LSDC / Compromission

A faire…

LT / Transfert

A faire…

LV / Vérification

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

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).

C / Confiance

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

– 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

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

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 inclue dans la partie signée, ainsi il ne peut être modifier 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é

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

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

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 puppetmaster.nebule.org.

L’identifiant de cette entité est 88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.

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

Cette entité est dédignée par le puppetmaster par rapport au rôle de maître de la sécurité. Le rôle est définit 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 cerberus.nebule.org.

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

CAMC / Autorité Maîtresse du code

Cette entité est dédignée par le puppetmaster par rapport au rôle de maître du code. Le rôle est définit 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 bachue.nebule.org.

CAMA / Autorité Maîtresse de l’annuaire

Cette entité est dédignée par le puppetmaster par rapport au rôle de maître de l’annuaire. Le rôle est définit 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 asabiyya.nebule.org.

CAMT / Autorité Maîtresse du temps

Cette entité est dédignée par le puppetmaster par rapport au rôle de maître du temps. Le rôle est définit 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 kronos.nebule.org.

CC / Configuration

A faire…

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 niveau 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
  • 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
      • 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 ‘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.
  • 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 localy.
      • 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 ‘permitDeleteObjectOnUnknowHash‘ :
      • 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 localy.
      • 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 ‘permitPublicUploadCodeMasterLink‘ :
      • 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 ‘maxFollowedUpdates‘ :
      • Description : Todo description...
      • Criticité : useful
      • Type : integer
      • Valeur par défaut : 100
    • Option ‘defaultObfuscateLinks‘ :
      • Description : Todo description...
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : false
    • Option ‘defaultLinksVersion‘ :
      • Description : Todo description...
      • Criticité : useful
      • Type : string
      • Valeur par défaut : 1.3
  • Catégorie ‘Entities‘ :
    • Option ‘permitWriteEntity‘ :
      • Description : The switch to permit entities writing.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : false
    • Option ‘permitPublicCreateEntity‘ :
      • Description : The switch to permit create new entity by anyone.
      • Criticité : critical
      • Type : boolean
      • Valeur par défaut : false
    • Option ‘permitInstanceEntityAsAuthority‘ :
      • 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
    • Option ‘permitRecoveryEntities‘ :
      • Description : Activate the recovery process. Local recovery entities are listed and new protection of objects are automaticaly 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 permited.
      • Criticité : careful
      • Type : boolean
      • Valeur par défaut : false
      • En lecture seule.
    • Option ‘permitInstanceEntityAsRecovery‘ :
      • 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 ‘defaultCurrentEntity‘ :
      • Description : Todo description...
      • Criticité : useful
      • Type : string
      • Valeur par défaut : 88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea
  • Catégorie ‘Groups‘ :
    • Option ‘permitWriteGroup‘ :
      • Description : The switch to permit groups writing.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : false
  • Catégorie ‘Conversations‘ :
    • Option ‘permitWriteConversation‘ :
      • Description : The switch to permit conversations writing.
      • Criticité : useful
      • 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 ‘defaultApplication‘ :
      • Description : Todo description...
      • Criticité : useful
      • Type : string
      • Valeur par défaut : 0
  • Catégorie ‘Logs‘ :
    • Option ‘permitLogs‘ :
      • Description : Activate more logs (syslog) on internal process.
      • Criticité : useful
      • Type : boolean
      • Valeur par défaut : false
    • Option ‘logsLevel‘ :
      • Description : Select verbosity of logs. Select on NORMAL, ERROR, FUNCTION and DEBUG.
      • Criticité : useful
      • Type : string
      • Valeur par défaut : NORMAL
  • Catégorie ‘Cryptography‘ :
    • Option ‘cryptoLibrary‘ :
      • Description : Todo description...
      • Criticité : careful
      • Type : string
      • Valeur par défaut : openssl
    • Option ‘cryptoHashAlgorithm‘ :
      • Description : Todo description...
      • Criticité : careful
      • Type : string
      • Valeur par défaut : sha256
    • Option ‘cryptoSymetricAlgorithm‘ :
      • Description : Todo description...
      • Criticité : careful
      • Type : string
      • Valeur par défaut : aes-256-ctr
    • Option ‘cryptoAsymetricAlgorithm‘ :
      • Description : Todo description...
      • Criticité : careful
      • Type : string
      • Valeur par défaut : rsa2048
  • Catégorie ‘I/O‘ :
    • Option ‘ioLibrary‘ :
      • Description : Todo description...
      • Criticité : careful
      • Type : string
      • Valeur par défaut : ioFileSystem
    • 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 : 10000
    • 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 : Todo description...
      • 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 ‘sessionBufferSize‘ :
      • Description : Todo description...
      • Criticité : useful
      • Type : integer
      • Valeur par défaut : 1000
  • Catégorie ‘Social‘ :
    • Option ‘socialLibrary‘ :
      • Description : Todo description...
      • Criticité : careful
      • Type : string
      • Valeur par défaut : strict
  • 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

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ée que via le fichier des options.

Le fichier contenant les options doit s’appeler nebule.env, 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 nebule.env 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 options. Les options inconnues sont ignorées. Seule la première occurence d’une option est prise en compte.

Par défaut, le fichier des options contient :

# nebule bash
filesystemBaseDirectory=~/nebule
filesystemPublicDirectory=~/nebule/pub
filesystemPrivateDirectory=~/nebule/priv
filesystemTemporaryDirectory=~/nebule/temp
filesystemLogActivate=false
filesystemLogFile=~/nebule/neb.log

# nebule php
#puppetmaster = 88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea
#hostURL = localhost
#permitWrite = true
#permitWriteObject = true
#permitCreateObject = true
#permitSynchronizeObject = false
#permitProtectedObject = true
#permitWriteLink = true
#permitCreateLink = true
#permitSynchronizeLink = false
#permitUploadLink = false
#permitPublicUploadLink = false
#permitPublicUploadCodeMasterLink = true
#permitObfuscatedLink = true
#permitWriteEntity = false
#permitPublicCreateEntity = false
#permitWriteGroup = false
#permitWriteConversation = false
#permitSynchronizeApplication = false
#permitPublicSynchronizeApplication = false
#permitDeleteObjectOnUnknowHash = true
#permitCheckSignOnVerify = true
#permitCheckSignOnList = true
#permitCheckObjectHash = true
#permitListInvalidLinks = false
#permitHistoryLinksSign = false
#permitInstanceEntityAsAuthority = false
#permitDefaultEntityAsAuthority = false
#permitLocalSecondaryAuthorities = true
#permitRecoveryEntities = false
#permitRecoveryRemoveEntity = false
#permitInstanceEntityAsRecovery = false
#permitDefaultEntityAsRecovery = false
#permitAddLinkToSigner = true
#permitListOtherHash = false
#permitLocalisationStats = true
#permitFollowUpdates = true
#permitOnlineRescue = false
#permitLogs = false
#permitJavaScript = true
#logsLevel = NORMAL
#modeRescue = false
#cryptoLibrary = openssl
#cryptoHashAlgorithm = sha256
#cryptoSymetricAlgorithm = aes-256-ctr
#cryptoAsymetricAlgorithm = rsa2048
#socialLibrary = strict
#ioLibrary = ioFileSystem
#ioReadMaxLinks = 2000
#ioReadMaxData = 10000
#ioReadMaxUpload = 2000000
#ioTimeout = 1
#displayUnsecureURL = true
#displayNameSize = 128
#displayEmotions = true
#forceDisplayEntityOnTitle = false
#maxFollowedUpdates = 100
#permitSessionOptions = true
#permitSessionBuffer = true
#sessionBufferSize = 1000
#defaultCurrentEntity = 88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea
#defaultApplication = 0
#defaultObfuscateLinks = false
#defaultLinksVersion = 1.3

CCOL / Options via Liens

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 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.

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

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

Liste des options non modifiables via des liens :

  • Option ‘puppetmaster‘
  • Option ‘permitWrite‘
  • Option ‘permitDeleteObjectOnUnknowHash‘
  • Option ‘permitCheckSignOnVerify‘
  • Option ‘permitCheckObjectHash‘
  • Option ‘permitListInvalidLinks‘
  • Option ‘permitInstanceEntityAsAuthority‘
  • Option ‘permitDefaultEntityAsAuthority‘
  • Option ‘permitRecoveryEntities‘
  • Option ‘permitRecoveryRemoveEntity‘
  • Option ‘permitInstanceEntityAsRecovery‘
  • Option ‘permitDefaultEntityAsRecovery‘
  • Option ‘permitJavaScript‘
  • Option ‘modeRescue‘
  • Option ‘displayUnsecureURL‘

CE / Confiance dans les Échanges

A faire…

CEMS / Moyens et Supports

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

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 faire…

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

A faire…

CK / Cryptographie

CKL / Cryptographie du Lien

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

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

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

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

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

É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

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

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

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

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

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é

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

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).

Laisser un commentaire