Auteur/autrice : webmaster

Nommage d’entité – préfix

Le nommage des objets permet d’inclure un préfixe et un suffixe.

Pour les fichiers nébulisés, le suffixe correspond à l’extension du nom de fichier. Cette extension ne fait pas partie du nom.

Pour une entité, le préfixe peut être utilisé pour contenir le titre d’une personne ou un grade. Mais le suffixe n’a pas d’utilité au premier abord. Mais une entité peut disposer de plusieurs entités qui lui sont rattachées. Afin de distinguer l’entité maîtresse des autres entités, le suffixe peut les différencier en leur donnant une distinction ou un rôle précis.

Entités de recouvrement

Le mécanisme de recouvrement des objets protégés et des liens dissimulés est en train d’être doucement mis en place.

D’un point de vue théorique, cela répond à deux problèmes similaires.
En entreprise, et pas que, il est recommandé d’utiliser une ou plusieurs autorités de recouvrement lorsque l’on utilise de la cryptographie pour protéger ses données. Les décideurs le prennent souvent comme une contraite et oublient de mettre en place ce mécanisme de restauration des données chiffrées. Et ce mécanisme est différent de celui de restauration classique alors qu’il est perçu comme étant le même. Résultat, lorsqu’un employé critique vient à manquer, ses données, critiques aussi, deviennent subitement inaccessibles. La disponibilité c’est aussi de la sécurité.
Pour différentes raisons, des états plus ou moins démocratiques peuvent imposer la mise en place d’un mécanisme de déchiffrement des données de leurs concitoyens.

Mais, afin de ne pas rompre la confiance, ce mécanisme doit être loyale, c’est à dire public, transparent et vérifiable.

D’un point de vue pratique, la mise en place comprend deux parties.
Il faut commencer par recenser les entités éligibles comme autorités de recouvrement. Pour l’instant dans le code de la librairie en php, la liste de ces entités est renvoyée vide. Les applications peuvent donc commencer à prendre en compte ces entités pour l’affichage public. C’est le cas dans klicty mais pas encore dans sylabe.
Il faut ensuite, lors de la protection d’un objet ou de la dissimulation d’un lien, dupliquer la protection ou le lien pour chacune des entités de recouvrement. Cela revient simplement à faire un partage de la protection pour un objet protégé en duplicant le lien de type k de chiffrement de la clé de session.

Pour terminer, la librairie n’intégrera pas par défaut d’entité de recouvrement. Si des entités sont définies comme tel, ce sera uniquement par choix (ou obligation) de l’entité responsable du serveur.

Intégration des groupes dans la librairie php

Suite à la définition des groupes, l’intégration a commencé dans la librairie php orienté objet.

L’intégration est profonde puisque les groupes sont gérés comme des objets spécifiques comme c’était déjà le cas pour les entités. Une classe dédiée ainsi que tout un tas de fonctions leurs sont dédiés et personnalisés.

Les applications sylabe et klicty vont intégrer progressivement les groupes, notamment dans un module adapté.

Dans le même temps, un groupe fermé étant uniquement constitué de liens d’une seule entité (et cela doit être vérifié), le filtre social est en cours de mise en place. Ainsi, il est possible de restreindre la prise en compte des liens suivant ces filtres sociaux :

  • self : liens de l’entité ;
  • strict : liens de l’entité et des entités autorités locales ;
  • all : toutes les entités, mais avec un classement par pondération des entités.

L’activation du filtre social et donc de la possibilité de le choisir dans le code à nécessité un revue de tout le code de la librairie et des applications. Il reste à vérifier les modules de sylabe.

Définition des groupes

Dans le cadre de la recherche sur l’implémentation des groupes dans nebule, voir 1 2 3 4 5, deux nouveaux objets réservés ont été ajoutés :

  • nebule/objet/groupe
  • nebule/objet/groupe/ferme

Le groupe

Il a été décidé de rattacher explicitement le groupe aux objets, et donc aussi aux entités notamment. Mais la notion de groupe peut être vu comme plus globale.

Si on reprend par exemple l’objet réservé nebule/danger, les objets qui lui sont liés deviennent de fait un groupe des objets à éviter. Il suffit donc de lier un objet à un autre objet pour créer un groupe. Cependant cela n’est pas très pratique puisque l’on ne peut rechercher que des groupes pré-définis à l’avance et communément acceptés. Cela marche bien pour quelques groupes avec des fonctions biens précises et universellement reconnues, et pas plus.

Fondamentalement, le groupe est la définition d’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. Le groupe met en relation des objets vis-à-vis d’une référence. C’est la référence qui identifie le groupe. Dans le cas de notre objet réservé nebule/danger, c’est cet objet réservé qui est la référence du groupe. Par simplification, l’objet de référence peut être assimilé comme étant le groupe.

Tout objet peut ainsi devenir la référence d’un groupe. Cela n’est pas sans poser un gros problème pratique. Puisque tout objet peut être un groupe, comment fait-on pour s’y retrouver dans l’immensité des groupes disponibles ?
Pour simplifier le problème, nous allons considérer les liens comme étant des groupes directs ou explicites. Et nous allons considérer les relations de deux liens ou plus comme étant des groupes indirectes ou implicites. Ces groupes indirectes sont centrés sur un et un seul objet de référence. Si nous prenons par exemple comme référence l’objet réservé nebule/objet/type, nous avons un groupe indirecte qui va contenir tous les objets de même type mime.

Nous allons à partir de maintenant considérer comme groupe uniquement les groupes indirectes.

Mais cela fait encore beaucoup trop de possibilités en pratique pour que la notion de groupe n’ai un intérêt pour gérer les objets. Nous allons en plus restreindre la notion du groupe, et donc son exploitation dans nebule, à l’objet vers lequel un lien explicite est créé avec les objets. Ce lien explicite est un lien de type l avec comme objet meta l’objet réservé nebule/objet/groupe ou nebule/objet/groupe/ferme.

Groupe ouvert ou fermé

L’exploitation des objets d’un groupe nécessite de pouvoir lire et vérifier les liens qui unissent les objets au groupe. Ces liens peuvent être générés par différentes entités, le traitement social des liens déterminera pour une entité donnée quels sont les objets reconnus dans le groupe ou pas. Ce processus est avant tout un traitement pour reconnaitre ou non les objets d’un groupe ouvert.

Pour un groupe fermé, la reconnaissance des objets du groupe n’est plus déterminée par le traitement social des liens. Ne sont reconnus les objets comme appartenant au groupe fermé que ceux dont le lien est signé par l’entité qui a créé le groupe. Dans le cas d’un groupe fermé, les liens générés par une autre entité pour ajouter des objets au groupe ne sont pas pris en compte.

Si il est possible de créer un groupe ouvert avec un objet de référence donné, le même objet de référence peut aussi servir pour un groupe fermé. Dans ce cas, lors du traitement, le groupe ouvert et le groupe fermé apparaissent comme deux groupes distincts. Si plusieurs entités créent des groupes ouverts avec le même objet de référence, un seul groupe est affiché et regroupe tous les groupes ouverts. Si plusieurs entités créent des groupes fermés avec le même objet de référence, il faut exploiter et afficher tous les groupes fermés comme des groupes indépendants.

Un groupe fermé doit toujours être accompagné son l’entité créatrice lors de l’affichage.

Groupe public ou privé

La distinction entre un groupe public et un groupe privé, c’est la visibilité de celui-ci pour les entités tierces. Si tous les liens qui relient les objets au groupe sont dissimulés, alors le groupe est privé et seuls les entités qui peuvent voir ces liens ont accès au groupe.

Cependant, si une partie des liens ne sont pas dissimulés ou si ils sont rendus publics, alors le groupe devient partiellement public.
Les liens, même dissimulés, sont complètement manipulables par toute entité qui y a accès, ainsi en terme de sécurité on peut dire qu’un groupe privé est un groupe public qui s’ignore. Mais ce n’est pas forcément un problème, si une entité A crée un groupe fermé et privé, alors le fait qu’une autre entité B crée un même groupe (même référence) ouvert et public ne rend pas pour autant public le groupe de l’entité A.

Groupe actif ou passif

Un groupe est par défaut passif. Il devient actif lorsqu’il devient capable de réaliser des actions, c’est à dire de signer des liens. Le seul objet capable de signer un lien est une entité, ainsi un groupe actif est un groupe dont l’objet de référence est une entité.

Si le secret de cette entité de référence du groupe n’est connu que d’une seule autre entité (entité maitresse) alors c’est un groupe actif fermé. Si cette entité de référence du groupe a plusieurs entités maitresses alors c’est un groupe actif ouvert.

Un groupe actif ouvert peut aussi être privé si tous ses liens sont dissimulés. Il devient semi-public ou public si une des entités maitresse dévoile tout ou partie des liens du groupe. De la même façon, une entité peut ajouter d’autres entités au groupe, c’est à dire partager le secret de l’entité de référence du groupe. En terme de sécurité, un groupe actif ouvert privé est souvent un groupe actif ouvert public qui s’ignore.

De fait, toute entité piratée devient un groupe actif ouvert, même si le secret de l’entité n’est pas rendu public.

Groupe d’entités

Un groupe d’entité est un groupe dans lequel on ne considère que les objets qui sont des entités. Les autres objets sont ignorés. Lorsque ce groupe n’est plus vu comme un groupe d’entités, tous les objets sont pris en compte et les entités sont gérés comme des objets. La distinction se fait donc uniquement sur le type d’objet que l’on attend du groupe au moment de l’exploiter.

Graphe de groupes

Lorsque l’on a un groupe qui est lié à un autre groupe, comme doit-on l’interpréter ?
Cela crée un graphe de groupes. Il est possible soit d’ignorer les sous-groupes dans un groupe ou au contraire de résoudre le graphe pour en exploiter tous les objets. Dans le cas de la résolution du graphe, on retombe sur les problèmes classiques de la résolution d’un graphe.

Le graphe de groupe peut aussi dans certains cas avoir un traitement convenu. Cela peut être appliqué à la gestion des options ou des droits dans une application. On va ainsi lier des groupes d’entités avec des groupes d’options et/ou des groupes de droits. Dans ce cas on ne parcours le graphe que de façon simple et non ambigüe.

NÅ“ud

La notion de nœud est concurrente de la notion de groupe. Sauf usage nouveau et différencié, le nœud va disparaitre de nebule.

Liens de propriétés d’un objet

Rien de vraiment nouveau pour ce début d’année 2016.

Via la librairie php, on pouvait récupérer une ou des propriétés d’un objet avec le contenu de ces propriétés, on peut maintenant récupérer juste le ou les liens correspondants. Ainsi il est possible d’extraire facilement d’autres informations sur ces propriétés comme la date ou l’entité créatrice…

Intégration d’une partie affichage dans la librairie PHP

Des corrections de buggs sont réalisés dans la librairie nebule en PHP ainsi que dans le bootstrap en fonction des progrès de klicty.

Pour faciliter le développement et la cohérence de l’affichage, la librairie nebule en PHP intègre maintenant une partie ‘display‘ dédiée à l’affichage de petites parties de pages comme par exemple un objet. La gestion globale de l’affichage reste du ressort des applications comme sylabe ou klicty.

Historique des liens générés

Il y avait dans la librairie nebule en php procédural une option permettant de copier au moment de leur écriture les nouveaux liens générés. C’est une forme d’historique qui vient en complément de la possibilité d’écriture des nouveaux liens signés dans les liens de l’entité signataire. Par défaut tout arrivait dans le fichier l/f qu’il fallait bien sûr penser à vider de temps en temps.

Mais cela n’avait pas été ré-implémenté. C’est maintenant fait dans la librairie en php orienté objet. L’option permitHistoryLinksSign permet d’activer cette fonctionnalité et est par défaut à false, soit désactivé.

C’est utile pour le développement puisqu’il suffit de récupérer les derniers liens des programmes en cours de développement pour les faire signer par une autorité de code (bachue). C’est plus facile que d’aller faire la pêche aux liens sur les différents objets concernés.

Projet klicty

Voici donc venir le projet klicty. C’est un dérivé de sylabe mais en plus spécialisé et donc plus léger aussi. En attendant qu’il ai sont propre blog, voici donc quelques captures. Globalement, il va permettre le partage de fichiers sur Internet, mais bien sûr le moteur c’est nebule…

20151031 klicty_-_hôte_bachue_-_2015-11-01_00.41.11Écran d’accueil.

Continuer la lecture de Projet klicty

Page par défaut du bootstrap

Le bootstrap évolue un peu dans la présentation de sa page par défaut :

20151022 nebule_bootstrap_-_2015-10-22_23.47.17

Une nouvelle application klicty s’ajoute à sylabe, c’est pour plus tard…

Mais sur un serveur, il n’y aura sûrement qu’une seule application, et elle sera utilisée par défaut plutôt que de passer par cette page du bootstrap.

Gestion des applications au niveau du bootstrap

Le bootstrap était jusque là assez sommaire. Il se contentait de trouver la dernière version valide de l’application en cours puis la chargeait pour affichage à l’utilisateur. Une page spécifique permettait, et permet toujours, de voir les caractéristiques du bootstrap et de son travail à des fins de dépannage, mais sans interaction possible.

20151018 nebule_bootstrap_-_2015-10-18_23.19.21
La page de dépannage du bootstrap. Continuer la lecture de Gestion des applications au niveau du bootstrap

Permettre les modifications par d̩faut Рannulation

Certaines options avaient été modifiées dans le bootstrap et la librairie. Voir l’article Permettre les modifications par défaut.

Ces modifications étaient nécessaires pour que le bootstrap puisse générer ou télécharger les objets et liens manquants à la mise en place de son environnement. Maintenant, lors du premier lancement, un fichier d’options par défaut est mise en place avec les options d’écritures nécessaires, puis ce fichier est remplacé à la fin avec des options verrouillées par défaut.

C’est plus propre comme ça.

Auto-installation depuis le bootstrap

Le bootstrap est en cours de modification pour pouvoir être posé tout seul sur un nouveau serveur. Il crée dans ce cas l’environnement nécessaire à son fonctionnement et télécharge ce qui manque.

Le but est ici de simplifier au maximum l’installation. Il restera ensuite à changer l’application par défaut, mais c’est un autre problème…

20150926 nebule_bootstrap_-_2015-09-27_00.43.11
Le bootstrap en cours de création de son environnement de travail.

Il reste à faire la partie qui génère une nouvelle entité pour l’instance locale. Par défaut c’est le puppetmaster, mais il n’y a pas de raison que ce soit lui partout. Avec la génération de cette entité, il sera affiché le mot de passe pour que son propriétaire puisse se l’approprier.

Permettre les modifications par défaut

La modification du bootstrap est en cours pour la préparation par défaut d’un nouvel environnement sur un serveur vierge.

Cependant, les options permitWrite, permitWriteObject et permitWriteLinks étaient par défaut à false. Et comme sur un nouveau serveur il n’y a pas de fichier contenant les options, c’était false la réponse par défaut pour ces options. Cela induit que la librairie refuse par défaut d’écrire les objets et liens associés pour la création du nouvel environnement et donc l’impossibilité de préparer ce nouveau serveur…

Ces options sont maintenant à true par défaut.

Sondages et votes

Dans un article La Suisse pourrait imposer l’open-source pour le vote électronique de Numerama, il est de nouveau question de la mise à disposition du code source du programme sous forme de logiciel libre.

L’avenir du vote électronique ne fait aucun doute, seule sa réalisation pose problème aujourd’hui. Beaucoup de débats comparatifs et contradictoires ont lieux vis-à-vis de la pertinence du vote électronique et de la confiance que l’on peut apporter aux machines de vote et au processus dans son ensemble. Ces débats peuvent paraître très conservateurs mais ils sont néanmoins nécessaires puisque le vote est un acte fondamental de nos démocraties, c’est le moyen d’expression de chacun d’entre nous.

La confiance en ce genre de machine de vote et du code qui l’anime ne peut être assurée sans l’ouverture du code à minima en lecture. Il faut aussi connaître précisément l’environnement de compilation et d’exécution pour le code soit parfaitement reproductible. Et bien sûr, il faut être sûr ce c’est bien ce code qui a été utilisé et pas un autre.
Invoquer le secret industriel sur du code pour un processus parfaitement connu et un enjeu majeur de démocratie, c’est particulièrement malhonnête. Tout au plus une société éditrice peut-elle demander un droit de paternité et une restriction de commercialisation à son seul bénéfice. Mais il suffit à l’état qui fait la commande du code de demander, et payer, explicitement la libre diffusion ou la libéralisation complète du code.

Le code doit être capable dans son ensemble de permettre la centralisation des votes, l’anonymisation des électeurs ainsi que la vérification en temps réel et à postériori du décompte des votes. L’authentification de l’utilisateur devrait être le principal problème mais il apparaît que c’est en fait le décompte et sa vérification qui interpellent le plus souvent les détracteurs du vote électronique.

Un vote a un point de départ dans le temps et une fin à partir de laquelle le décompte des votes est considéré comme définitif.

L’anonymisation est aussi un problème pour la vérification de conformité du vote à postériori puisqu’elle casse le lien sûr entre le votant et le vote unitaire. On peut ainsi affirmer que le votant à voté (il a posé un papier et signé le paraphore) mais on ne peut pas le prouver à postériori (était-ce vraiment lui).
La capacité de multi-entité et la dissimulation de liens dans nebule permettent de résoudre ce problème.

Voici un scénario possible de vote avec les objets et liens de nebule :

  1. Pour un vote, une entité maîtresse du vote est générée. Elle est explicitement reconnue par les autorités comme telle. Son seul rôle est de générer les jetons de vote et de les attribuer aux électeurs.
  2. L’entité maîtresse du vote va générer autant d’objets jetons qu’il y a de votants. Ces jetons sont aléatoires et n’ont pas de relation directes avec les électeurs. Chaque jeton est en fait la partie publique d’un bi-clé cryptographique (RSA par exemple). La clé privée de chaque jetons est protégé par un mot de passe stocké dans un objet protégé par et pour l’entité maîtresse (dans un premier temps).
  3. Le jeton est en fait l’entité qui réalisera le vote via la clé privée. Chaque vote peut être vérifié par rapport au jeton, c’est à dire la clé publique.
  4. Pour chaque objets de clés privées de chaque jetons, l’entité maîtresse va partager le secret de chiffrement de l’objet contenant le mot de passe. Le lien entre objet chiffré et objet non chiffré est dissimulé, c’est à dire que c’est un lien de type c masquant le vrai lien.
  5. La clé privée de l’entité maîtresse est détruite. Il n’est ainsi plus possible de retrouver l’intégralité des relations en les jetons et les électeurs mais il est possible de vérifier que tous les électeurs ont reçus un lien dissimulé et de vérifier tous les jetons réalisant le vote.
  6. Pour un vote, une entité de décompte du vote est générée. Elle est explicitement reconnue par l’entité maîtresse Son seul rôle est de recueillir et de valider les votes. La période de vote démarre.
  7. L’électeur, c’est à dire l’entités votantes, va récupérer auprès de l’entité maîtresse du vote l’intégralité des jetons et des clés privées associées (et pas juste son jeton). Il va ainsi obtenir tous les liens dont le lien dissimulé le concernant. Via le lien dissimulé, il va savoir quel est la clé privée du jeton que l’entité maîtresse lui a attribué. Disposant de cette information il peut déprotéger à son profit l’objet contenant le mot de passe de la clé privée du jeton.
  8. L’électeur, mettant à profit la clé privée du jeton, peut réaliser un ou plusieurs votes, seul le dernier est pris en compte. Le vote consiste en un lien entre le jeton et le choix de vote dans le contexte de l’entité de décompte du vote (champs méta).
  9. L’entité de décompte du vote vérifie régulièrement auprès de tous les électeurs la présence de liens dont elle est le contexte. au fur et à mesure de la récupération des liens, elle se les approprie (signature du lien de vote).
  10. A la fin de la période de vote, la clé privé de l’entité de décompte du vote est détruite. Plus aucun vote ne peut être ajouté, modifié ou supprimé. Les votes comptabilisés sont ceux qui ont été signés par l’entité de décompte du vote.
  11. L’électeur qui souhaite rendre publique son vote a juste à prouver qu’il dispose du jeton en utilisant sa clé privée pour autre chose que le vote en relation avec sa véritable entité. Il peut aussi révéler le lien dissimulé que lui avait généré l’entité maîtresse du vote.

Un des aspects des liens dissimulés est qu’il est possible de les dissimuler pour plusieurs entités. Ainsi il est possible de générer une entité d’audit du vote à qui l’entité maîtresse partagera les liens dissimulés, de façon également dissimulé.L’entité d’audit devient capable à postériori de vérifier la bonne association entre jetons de vote et électeurs sans être elle-même capable d’émettre de nouveaux jetons.

Le sondage est moins contraignant et surtout peut être à choix multiples.

Attribuer des propriétés aux autres entités

Je viens de voir que dans Google Plus on peut ajouter des coordonnées à une autre personnes. Celles-ci restent confidentielles, c’est à dire juste connues de soi-même… et de Google. C’est un peu intrusif quand même puisque Google peut connaître les coordonnées d’une personne alors qu’elle ne les a pas volontairement publiées.

Dans nebule, on peut faire la même chose puisque l’on dérive d’une entité une propriété. Mais on en reste maître et, si les liens sont masqués, cela reste complètement privé. Même l’entité qui en fait l’objet ne le sait pas. La différence, c’est que on est le seul ‘strictement’ à connaître cet ajout de propriété et cela n’apparaît pas dans une base de donnée d’une grande société que l’on ne maîtrise pas.

Caliopen

Depuis le début de Caliop ou pas loin, je regarde ce qui s’y passe. Aujourd’hui ce projet de messagerie sécurisée continue sous Caliopen.

Ce n’est pas un service tout à fait comparable à ce que propose nebule. C’est un service qui se veut compatible avec la messagerie smtp. Cela implique la présence et l’utilisation de serveurs centraux de messagerie. Ensuite, si l’interface mélange les différentes sources de messages comme SMS, emails et tchats, il ne semble pas y avoir d’autres moyens d’échange ou de gestion de l’information.

Dans l’interface proposée, il y a une chose intéressante. Dans la vue de boite d’entrée, on a deux curseurs permettant de montrer les messages.

Le premier curseur gère le niveau de sécurité des messages affichés. Lors des échanges de messages, on doit s’attendre à ce que la confiance dans le contenu des messages soit forte ou à défaut qu’un indicateur de cette confiance pondère son contenu. Il est un peu étonnant qu’il y ai un seuil haut et bas. Quel sera l’usage du seuil haut que l’on abaisserait ? Le niveau de confiance d’un message est calculé sur la façon dont il est transmis, le réseau proche utilisé, et la cryptographie employée.
Dans nebule, cette confiance n’est pas vraiment calculée. Les réseaux utilisés et les serveurs parcourus ne sont pas source de calcul d’une confiance. Ils ont par défaut une confiance nulle. C’est la façon de parcourir de multiples serveurs de façon aléatoire qui va palier au manque de confiance dans les réseaux et les serveurs. Par contre, un curseur social sera définit et les liens seront triés en fonction de seuils. Et ce curseur dépendra surtout de l’entité avec qui on correspond. Une pondération automatique sera possible pour les entités inconnues en fonction des entités connues qui la reconnaissent. Pour la cryptographie, chacun peut librement choisir ce qu’il utilise et ce qu’il protège, c’est comme pour Caliopen.

Le second curseur gère l’importance des messages avec un seuil haut et bas. là aussi il y a un seuil haut dont l’usage est à voir en pratique. L’importance est donnée par l’émetteur du message.
Dans nebule, l’importance n’est pas fixée par l’émetteur mais est calculée en fonction de l’émetteur et des liens vers des objets pondérés. Il est même possible de simuler en public une importance forte à une entité en particulier mais en réalité de dissimuler que cette entité n’en a pas.

La découverte de nouvelles personnes avec qui converser se fait par divers moyens. Mais il faut bien vérifier la clé publique. Caliopen propose d’utiliser le DNS. Tout le monde peut contrôler un nom de domaine ou appartenir à un nom géré par quelqu’un d’autre. Il est possible de transmettre par ce biais une clé publique pour une adresse (email) correspondante. On rend difficile l’usurpation d’une identité.
Avec nebule, en l’absence de vérification directe d’une entité et donc d’une pondération forte, on fait confiance à des entités proches pour pondérer cette entité que l’on ne connais pas. C’est un peu le système utilisé dans PGP.

Je continue à regarder l’évolution du projet en espérant qu’il ne capotera pas comme tant d’autres…

Exploitation de liens dissimulés

Dans l’article sur la Dissimulation de liens, multi-entités et anonymat, on a vu comment implémenter des liens dissimulés dans d’autres liens.

Ici, on va apporter quelques précisions pratiques.

Déjà, un lien dissimulé va apparaître avec une entité signataire et une entité destinataire du lien. On a vu que c’était le minimum vital pour que cela fonctionne et que l’on puisse partager les liens même si cela implique de travailler sur les entités pour parfaire l’anonymisation. Il y a le cas particulier du lien dissimulé pour soi-même, dans ce cas l’entité signataire est aussi l’entité destinataire.

Lorsque l’on regarde les liens d’un objet, on va voir tous les liens non dissimulés. Si une entité est déverrouillée, il faut en plus parcourir tous les liens de type c de l’objet de l’entité pour en extraire les liens dissimulés relatifs à l’objet que l’on regardait. Dans le cas de multiples entités esclaves d’une entité maîtresse, il faut faire de même pour extraire tous les liens dissimulés pour toutes les entités accessibles. Il faut veiller dans ce cas à ce que l’interface montre clairement qui est l’entité concernée pour éviter toute confusion de l’utilisateur.

Objet réservé pour les pseudo systèmes de fichiers

Pour les besoins de sylabe et la gestion des équivalents de systèmes de fichiers, un objet réservé à été créé : nebule/arborescence

Il sert de repère pour les points d’entrés des arborescences des systèmes de fichiers. C’est ajouté au wiki Documentation – nebule v1.2 – Objets à usage réservé.

CF : sylabe – blog – Avancement