Bootstrap niveau de code

La stratégie de développement du bootstrap mérite une petite explication.

Ce « petit » morceau de code unique de quelques 6500 lignes aujourd’hui a pour rôle de recherche et charger la bibliothèque nebule et l’application demandée par l’utilisateur.

Son interface est sommaire, spartiate. L’utilisateur moyen n’a pas beaucoup de raison de s’y aventurer en temps normal. Si le bootstrap apparaît c’est sûrement pour un problème grave…

Son code résulte de la tension forte entre le besoin d’une code de démarrage unique des applications et le besoin récurrent de mise à jour en cas de faille.

Pour cela il intègre une bibliothèque réduite et limité de nebule afin de pouvoir manipuler les objets et liens en provenance uniquement des entités autorités. Ensuite, une fois l’application chargée, c’est le code de la bibliothèque complète qui est utilisée, mais celle-ci est tenu à jour en recherchant toujours la dernière version disponible. Et il en est de même pour les différentes applications.

Le code du bootstrap a été fait en programmation procédurale (dit libpp) afin qu’il n’y ai pas de confusion avec le code de la bibliothèque complète en programmation orientée objet (dit libpoo).

Afin de pouvoir être d’une certaine utilité en cas de problème, le bootstrap intègre trois toutes petites applications :

  • app 0 : sélection de l’application à lancer pour l’utilisateur.
  • app 1 : documentation nebule.
  • app 2 : application par défaut, ne fait rien que d’afficher une page simple.

Nœuds et références

Entre le nÅ“ud et la référence, peu de différence à voir. C’est surtout un usage dans le code.

La référence RID (Reference ID) est un nÅ“ud NID que l’on utilise explicitement comme point de départ d’une recherche d’objets.

Là o`u un NID différent va être utilisé pour désigner chaque groupes, un RID va être unique pour retrouver une propriété.

Par exemple une conversation est un groupe de messages. Mais chaque conversation est unique, chacune dispose d’un NID propre.

Le suivi d’un code d’une application se fait en récupérant le dernier lien depuis un RID. Mais on peut aussi voir ce RID comme un groupe des versions successives de cette application.

Le nommage d’un RID n’a pas de raison d’être même si ce n’est pas interdit.

Premiers liens signés en v2.0

Les deux premiers liens dans la nouvelle forme en v2.0 viennent d’être signés :

nebule:link/2:0_0:020210714/l>88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256>5d5b09f6dcb2d53a5fffc60c4ac0d55fabdf556069d6631545f42aa6e3500f2e.sha2.256>8e2adbda190535721fc8fceead980361e33523e97a9748aba95642f8310eb5ec.sha2.256_88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256>79bf4029cf6ee77b0f9db987fcb59c53434a8f2e36773d7a427ec869de04698ddb044bfe08d963732dec237ef56b03f003f4bcc491e293c0b6a7396a351b10e319aa80984bd5d7c0c812cd6a91a296d55ace2e6e6d266dd06c83f21814e272793e75e23cb8f70911ba845885f9e41636466b74e6a7f7e1c174e612776981e645273ac59410ab39606feb20102cf28834aa054008bb35191573189bb0266875dd82cbf12dc64d0eb77acf59e18c8336583faac32755450c00d559398fbd078871fcd9097ac476f67010a9d728a00860f1e34f66bd32b64093b834fcce2bf028193335ebedd1ae27e29df3b8184360bee9dbc707135c54ef48d3efc096b32ba33681925afb8d4e7d4f91598f4d250eb9d27b96762727610a87317892033e84e6e7198837a10ef5e8582ecb98d6aef00e7b4ef2d536cb2063b476d21a8abaf6678462e329bf08bb9159ec4a7358b1e6b15252bd1acf471eb43895edc4caaee58e9d1fcd36cd21b7fc45fb43443c3408de80c1aa3d8c45c71071bfebbfa0c82f747e97f0668d628a3bb5f18cf105b5c16ac14fa61730fdf97342add718ee6c55cf576b060027ce5dfd3651349ff3163011f58cdc2140ea3ef9d2bfefe1d105498722b6ff3c0993aaffa0f0625e5bd2503cf289ec3e694b43616134d1a938dfe1d050b4106f466b23c2dc446e7f1d96a942aaa73c694a8434bdf549fde985ff939142.sha2.512
nebule:link/2:0_0:020210714/l>88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256>970bdb5df1e795929c71503d578b1b6bed601bb65ed7b8e4ae77dd85125d7864.sha2.256>5312dedbae053266a3556f44aba2292f24cdf1c3213aa5b4934005dd582aefa0.sha2.256_88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256>58ca04cc43fc46c7a5176f2ff8f93754da9cfaabff2f12a3c9e6453d3dd3eeedd0208477f9e62c085a6f32583a127467696d7af980fe18a85a7951a6deea6372ca9f0c965d0a08fa159f241a680d5dba69449acb03043fc8021b93a2e34a1c3fb93385250f5ebf7a457fd38f2c6b1e500614f19b37bd37416342ddd94385ec2f5185fddde6d803fc1f89dabe6aebcd55490688cdbe5c779ae2b81d7a4b65c57fd6b35b6ad0fb20881f12c04e34a1730e254530a9c69fdaa9c1ef76fa6248a6e22417e25758837c7378f97af5c3d2cfe88fe9711ba705e2d017fe7ff4c97cbb44600e0d7b32e1c2f97467d8e79d48fc5d6dbd3d581bb831582be7f1a918609cd4a64e4d621bababaddde6da3621f24220ed7dc2ae585fe9b7f9cd71fe18a1a75778c54bdf1e7ad066e10c36e7fb2a4577f9d1bc7be1f80363d1a3e58e34ee4971ccd0a8a8b45665b1234909104558cb210ea402cb7822e3f4c5e1095c4f6a8a86b432b7c77028c76d38dd171a009dd7b251f74ea112739b91cfd8a6c665546bb984dc2fd1f59212a59f84154556bcdfade82c1b049e91a1befa45f2511f02123aa3f7718b0c64aeca984eb70cb9841e933603221765899384e1d3467cb31071ae3071e741f9689735a7e0c8cf7e202b926260067112fec8b24f991a6b35868fbb3653f2be774574d87e1a0fe9222774f6ede5b38c8393d72ff866faa40c5b706f.sha2.512

Ces deux liens concernent l’entité puppetmaster et sont ceux posés par défaut lors du premier lancement du bootstrap, lorsqu’il n’y a encore rien d’autre.

Ils sont la particularité d’avoir une signature faite sur un hash à 512bits.

Gestion du temps dans le lien

Dans le lien, la partie horodatage est constituée de deux parties.

La première partie, nommée MOD, désigne le mode d’exploitation de la marque de temps, c’est à dire sa forme.

La seconde partie, nommée CHR, contient la valeur de la marque de temps proprement dite. Cette valeur doit être interprétée suivant la valeur de MOD.

Tel que cela a déjà été vu avec la précédente forme des liens (Marque de temps, Gestion temporelle partielle, Marque de temps, Horodatage, ISO 8601, suite), la marque de temps peut prendre plusieurs formes. Ces formes peuvent dans certains cas être ambiguë. La partie MOD lève toute ambiguïté. Nous pouvons avoir un compteur, une date simple ou une date exprimée suivant la norme ISO 8601:2004 .

Dans le bootstrap seul est reconnu le mode 0 définissant une maque de temps simple mais adaptée au temps long. Cela donne :

0>020210417223045

P̩rim̬tre fonctionnel bootstrap Рlibpp

Jusque là le bootstrap intégrait une bibliothèque PHP procédurale (libpp) de nebule héritée et remaniée avec le temps mais ayant gardée tout ce qui était fonctionnel.

Or pour le bootstrap certaines fonctionnalités n’ont pas d’utilisé. Et comme il va falloir réécrire et revoir en grande partie cette bibliothèque, c’est le bon moment pour la simplifier. Et on va commencer par supprimer les parties sans utilité.

Au niveau cryptographie, seul la génération et la vérification des liens est utile. Le chiffrement d’objets n’a pas de raison d’être présent. La dissimulation de liens n’a pour l’instant pas d’utilité non plus.

La gestion des attributs d’objets n’a pas d’utilité mais il faut garder la capacité à suivre les mises à jours d’un objet et être capable d’aller chercher des mises à jour. Mais afin de réduire la complexité, seul le HTML sera utilisable.

Les liens supportés seront mono-registre et mono-cœur.

Le travail fait avant par la bibliothèque de nebule en bash permettait de générer un nouveau puppetmaster. Cela va devenir une nouvelle fonction dans le périmètre du bootstrap, et donc de la libpp. Il faut donc conserver la capacité de générer de nouvelles entités et de générer des liens.

Une autre partie qui va être intégrée au bootstrap, c’est la possibilité de faire les mises à jours des applications. Il faut donc que le bootstrap soit capable de parler avec le reste du monde. Seul le HTTP sera pris en compte pour ça. Et cela concerne aussi les entités.

Tout le reste fera partie de la bibliothèque en PHP orienté objet (libpoo).

Champ action du lien Рaction suppl̩mentaire de transaction

Il était possible de créer une nouvelle action dédiée aux transactions et non annulable, cf l’article Lien de transaction, ce qui aurait nécessité une grosse modification du code de la bibliothèque.

Finalement cette nouvelle action ne sera pas implémentée, il est possible avec la gestion des relations sociales spécifiques à une monnaie de supporter une suppression de transaction par son initiateur mais sans effet de cette suppression si la transaction a déjà été validée par ailleurs.  dans ce cas c’est comme si la transaction marqué par l’utilisateur était une demande de transaction et que celle-ci était validée par une autorité reconnue au niveau de la monnaie.

Application d’authentification et gestion des entités déverrouillables

La gestion des entités déverrouillables sur une instance de serveur est pour l’instant rudimentaire. Toute entité qui réussi à poser une clé publique et une clé privée sur l’instance peut se connecter. Il serait intéressant de pouvoir restreindre ces entités à un groupe connu et alimenté par les autorités locales. Ce groupe pourrait être vu comme un annuaire. On peut imaginer aussi un mécanisme de cooptation. Et on peux imaginer un bannissement sur liste noire même si cette méthode doit être couplée à un autre mécanisme.

Dans la lignée de la réflexion, il pourrait être intéressant de déléguer l’authentification à une application dédiée avec retour à l’application d’origine si ça se passe bien.

Bonne année 2020

Une nouvelle année signifie la mise à jour de toutes les dates à côté des licences… que ce soit dans les différents code mais aussi des sites web statiques et des blogs.

Aucune publication de code n’a été faite depuis le 8 mai 2017. Les différentes applications sont toujours en cours de ré-écriture avec la nouvelle partie graphique intégrée à la bibliothèque nebule. Et elles rejoignent progressivement la mise en pratique de la Réflexion sur l’évolution de l’interface web pour nebule. Cependant une publication en cours de migration avec des modifications partielles serait catastrophique pour l’utilisabilité des applications.

Par rapport à début 2019, une nouvelle application qantion dédiée à la crypto-monnaie a vu le jour. La réorganisation de la partie graphique est très avancée. Les autres applications n’ont pas bougées. Le travail avance lentement mais il ouvre progressivement de nouvelles perspectives.

La documentation technique de nebule a migré vers une pseudo-application dédiée gérée par le bootstrap. Mais la documentation est en fait contenu, et mise à jour, par la bibliothèque.

Oubli, nettoyage et suppression des liens

Suite des articles Nettoyage des liens et suite, et Suppression et oubli. Le sujet est déjà ancien et il y a eu quelques réflexions sur les objets mais rien de concert n’a été mis en place. Cette absence d’implémentation s’explique parce que la gestion des relations sociales dans les liens n’est pas assez avancée. Le but est double, gérer le stockage et améliorer les performances.

Cependant il est possible de continuer la réflexion notamment sur les liens qui n’ont pas les mêmes contraintes que les objets. La gestion des liens dissimulés dans des fichiers de liens spécifiquement nommés a créé une brèche dans le nommage strict des fichiers de liens. Une première tentative avait commencée avec le stockages de liens anciens dans des fichiers de liens avec un chaînage au fichier d’origine mais n’avait pas abouti du fait de plusieurs problèmes.

Aujourd’hui il est possible de gérer les liens suivant deux méthodes, l’ancienneté et/ou le surnombre. Et cela va trouver une solution dans deux type d’actions, la suppression ou la mise à l’écart dans des fichiers d’archivage datés dédiés. Il faut une option d’activation de l’oubli des liens, une option de sélection de la méthode et option de sélection de l’action. On peut envisager d’utiliser les deux méthodes simultanément.

Pour la méthode de l’ancienneté, il faut distinguer quel type de lien on doit garder disponible immédiatement. Cela veut dire des options par types de liens pour dire l’ancienneté maximale attendue. La notion de sociabilité des liens et intéressante aussi parce qu’il suffit de garder un seul lien signé par l’entité ayant le plus gros score social.

Pour la méthode du surnombre, il faut aussi distinguer le type de lien parce que certains liens sont indispensables au bon fonctionnement d’un objet. Pour chaque type de liens, on garde les liens les plus récents à concurrence du nombre autorisé. Il faut une option par type de liens de définition du nombre à garder pour chaque types. Peut-être faut-il prévoir une gestion sociale afin de pondérer l’ordre des liens et de garder les liens les plus pertinents.

Certains objets ont des rôles importants comme les codes des applications. Ils sont assez facile à gérer parce que les liens sont signés d’une autorité maîtresse du code. Cela va peut-être nécessiter la création d’un nouveau type social mixant strict et réputation pour les gérer encore plus facilement.

Pour l’action de suppression c’est facile, il suffit de ré-écrire le fichier des liens d’un objet en ne gardant que ceux désirés. Les autres liens sont oubliés et perdus localement. Il n’y a pas de mécanisme de corbeille, si besoin il faut basculer sur l’action de mise à l’écart.

Pour l’action de mise à l’écart, on ré-écrit les liens désirés dans le fichiers des liens de l’objet et on écrit les autres liens dans un autre fichier avec un nommage spécial. Ce nommage commence par l’identifiant de l’objet et se voit ajouter une marque de temps et une valeur aléatoire. L’identifiant permet de relier les liens contenus à l’objet concerné. La marque de temps permet de remonter dans le temps progressivement en cas de besoin. La valeur aléatoire empêche la récupération à distance des liens anciens. Le datage se fait à la journée, reste à choisir la base de temps utilisée.

La mise à l’écart de liens avec un horodatage permet un nettoyage facile à posteriori des liens anciens. Et cela permet aussi localement d’activer une utilisation des liens plus anciens sur la sélection d’une date de départ mais au prix de performances dégradées. Ce paramètre de recherche temporelle doit être un argument de l’URL des applications et doit être contrôlé par une option d’autorisation pour une entité déverrouillée ou non.

Ensuite il y a deux stratégies pour rechercher et traiter les fichiers de liens trop gros et/ou avec des liens trop anciens. Soit on fait une recherche globale systématique à intervalle régulier ou lorsque que les performances baissent. Soit on met en place lors de la lecture des fichiers de liens des détecteurs à seuils afin de détecter à l’usage les fichiers de liens nécessitant un nettoyage, et on les traitent immédiatement ou à intervalle régulier.

Lien à quatre champs objets – quoi

Suite des articles Lien à quatre champs objets et Structure du lien à quatre champs objets.

Avant de réorganiser le registre des liens il faut réfléchir aux besoins.

Ajouter un champs version du (registre du) lien est intéressant parce qu’il permettrait nativement des évolutions et des scissions dans la gestions des liens. La scission des liens n’est clairement pas un but parce qu’il introduit des incompatibilités de communications entre différentes communautés (comme les langues), mais c’est une possibilité qui serait ouverte.

Le cÅ“ur du registre des liens avec aujourd’hui un triptyque de champs source_destination_méta pourrait devenir un champs unique contenant des sous-champs en plus grand nombre (mais strictement limité). Ce champs unifié cÅ“ur du registre pourrait avoir 4 sous-champs pour source-destination-opération-contexte et recevoir en plus le champs action. Doit-il en avoir plus ? Est-ce que l’on peut utiliser un autre modèle type qui-quoi-quand-comment-pourquoi… ?

Le lien doit aussi pouvoir facilement supporter la dissimulation de lien, c’est à l’offuscation de du cÅ“ur du registre du lien.

Par contre, il n’est toujours pas opportun de gérer dans un lien de multiples cÅ“urs de lien à la façon du RDF.

Si refonte du lien, cela entraînera un nouvellement complet des implémentations des librairies et des applications avec une incompatibilité forte avec l’existant.

Fusion des monnaies dans la bibliothèque

Plutôt que de laisser tout dans une application et un module, la gestion des monnaies a migré vers la bibliothèque nebule.

C’est plus simple pour l’application mais cela a nécessité pas mal de modifications dans la bibliothèque. Cela veut dire aussi que la documentation dispose maintenant d’une partie dédiée.

Premiers essais pour bientôt !

Options et subordination

Suite des articles Liens des options et Lien à quatre champs objets.

Il paraissait intéressant de pouvoir définir les options d’une entité sous contrôle comme une instance sur un serveur. Cela voulait dire contextualiser le lien or les trois champs des liens de définition des options étaient déjà utilisés. Mais comme il est possible de fusionner le champs option avec le champs définissant de quelle option on traite, cela libère une champs pour une entité cible.

Les liens de modification des options ont été changés dans la bibliothèque nebule afin de prendre en compte ce changement. L’entité est en champs source. Le hash de la valeur de l’option est en champs cible. Et le champs méta contient le hash du nom de l’option préfixé par nebule/option/.

Et une nouvelle option subordinationEntity permet de définir une entité de subordination, c’est à dire une entité qui peut forcer les options. C’est utiliser typiquement pour définir les options d’une instance sur un serveur distant (qui n’est pas sous contrôle physique). Cette option est en lecture seule, c’est à dire qu’elle ne peut être modifiée que via le fichier d’environnement.

L’option doit renvoyer un identifiant d’entité mais plus tard il sera possible de mettre en groupe d’entités…

Le bootstrap affiche maintenant aussi cette entité de subordination dans la page d’interruption.

La documentation décrit cette évolution :

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 définis par des liens sont attachées à des entités. C’est à dire que le lien d’une option doit contenir l’entité à laquelle s’applique le lien. L’utilisation ou non de l’option se fait par l’entité si le lien lui appartient ou si elle est subordonnée à l’entité signataire du lien (voir CCOS). Les liens de l’entité de subordination sont prioritaires sur les liens propres.
Toutes les options inscrites dans le fichier des options sont dites forcées et ne peuvent être surchargées par un lien d’option.
La valeur de l’option doit être présente ou écrite dans l’objet correspondant. Si la valeur de l’option ne peut être lu, elle ne sera pas prise en compte. Le nom de l’option n’a pas besoin d’être écrit dans l’objet correspondant, il est déjà défini dans le code.
Les options définis par les liens ne sont pas prises en compte par la bibliothèque nebule en PHP procédurale du bootstrap.
L’option se définit en créant un lien :

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

Liste des options non modifiables via des liens :

  •     Option ‘puppetmaster’
  •     Option ‘permitWrite’
  •     Option ‘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’
  •     Option ‘subordinationEntity’

CCOS / Subordination

Une entité peut définir ses propres options mais peut aussi se voir défini ses options par une autre entité. C’est principalement utilisé afin de piloter des instances sur des serveurs distants.
La mise en place de ce mécanisme permet de maintenir autant que possible le contrôle sur un serveur que l’on ne maîtrise pas physiquement. Elle est mise en place via l’option subordinationEntity en lecture seule écrite dans le fichier des options. Cela veut dire aussi qu’une entité peut être compromise et pilotée à distance si le fichier des options est modifié par une entité tièrce.
La subordination peut être faite vers une seule entité, défini par son identifiant, ou pour un groupe d’entités. La gestion du groupe n’est pas encore fonctionnel, seule une entité peut être défini.
La subordination n’est pas prise en compte par la bibliothèque nebule en PHP procédurale du bootstrap.

Export des articles de blockchain et transaction vers le blog de qantion

Les projets développés autour de nebule avaient peu de réflexions propres et les différentes réflexions revenaient invariablement à la gestion d’information, donc vers le blog de nebule. Il n’en est pas tout à fait de même pour les réflexions sur la blockchain et les transactions qui sont souvent propres au projet qantion aujourd’hui mis en place.

Afin de garder une cohérence dans les réflexions menées sur le nouveau blog dédié à qantion, les différentes articles du blog de nebule traitants de blockchain et de transactions ont été dupliqués ici et anti-datés.

Toutes nouvelles réflexions liées à la blockchain ou aux transactions seront faites sur le blog de qantion, et seront dupliquées ici si elles intègrent aussi une réflexion de portée plus fondamentale sur la gestion d’information.

Nouvelle application qantion

Les réflexions sur les crypto-monnaies commencent à prendre beaucoup de place et de temps de réflexion. Il est temps de démarrer une application à part entière dédiée à la crypto-monnaie basée sur nebule.

Après une phase de réflexion sur un nom possible, percutant, porteur de sens… et encore disponible dans les noms de domaines sur Internet, c’est finalement qantion qui s’est imposé.

Il désigne le plus petite élément de quantification.

Une autre alternative de noms partait sur deux noms proches (et eux aussi disponibles) pour porter les deux facettes des monnaies, c’est à dire une locale et une globale avec deux fonctionnements différents.

Donc, nous avons blog.qantion.org pour le suivi du projet et qantion.com pour le démonstrateur.

Transcodage et translation

Suite aux articles Anonymisation/dissimulation des liens – ségrégation partielle, transcodage, Transcodage des liens dissimulés et Anonymisation des fichiers transcodés, il était apparu un problème avec le contenu des fichiers transcodés.

Le transcodage des identifiants des objets pour lesquels on dissimule des liens permet de stocker ces liens dans des fichiers non directement associés à l’identifiant de l’objet concerné. C’est en fait une translation d’identifiant.

Ces objets ‘virtuels’ translatés doivent pouvoir être partagés par transfert ou synchronisation sans risquer de dévoiler l’association entre l’identifiant en clair et l’identifiant translaté.

Le système de translation aujourd’hui mis en place est basé sur une clé unique de translation par entité. Cette translation doit être une fonction à sens unique, donc à base de prise d’empreinte (hash), y compris lorsqu’une ou plusieurs translations sont connues. Enfin, la translation doit être dépendante de l’entité qui les utilise, c’est à dire qu’une même clé peut être commune à plusieurs entités sans donner les mêmes translations.

Dissimulation, transcodage et dossier privé

La réflexion de l’article Anonymisation/dissimulation des liens – transcodage est très intéressante parce qu’elle rejoint la réflexion originel de nebule implémenté en bash pour les expérimentations. Cette implémentation en bash est clairement mono-entité, c’est à dire à l’usage exclusif d’une entité là où une implémentation en php comme l’application sylabe permet un usage multi-entités simultané.

L’implémentation en bash utilise un dossier nommé /pub pour recevoir les dossiers o et l contenants les objets et les liens dits publiques, ou plutôt publiables. Ce dossier /pub peut être partagé via un serveur web. Mais il y a aussi un dossier nommé /priv qui lui reçoit des dossiers o et l contenants les objets et les liens dits privés, donc non publiables. Le dossier des objets privés permet de recevoir le contenu des objets protégés et déchiffrés le temps de leur utilisation. Le dossier des liens privés n’a jamais été utilisé mais il correspond tout à fait à ce que l’on essaye de faire aujourd’hui avec le transcodage pour les liens de dissimulation.

La structure typique des dossiers de l’implémentation en bash :

/home/user
   +-> /neb
       +-> /pub
       |   +-> /l
       |   +-> /o
       +-> /priv
           +-> /l
           +-> /o

Or le problème de la dissimulation est facile à résoudre sans transcodage dans l’implémentation bash. Mais ce n’est pas transposable dans l’implémentation en php à cause de la notion cité plus haut de capacité multi-entités simultané. Les fichiers transcodés contenants les liens dissimulés répartis par ID d’objets sont le pendant direct des liens du dossier /priv/l.

Anonymisation/dissimulation des liens – transcodage

Suite à l’article Anonymisation/dissimulation des liens – ségrégation et temporalité et ségrégation partielle, la réflexion et l’implémentation sur le stockage et l’échange des liens dissimulés progresse.

La méthode de ségrégation des liens dissimulés développée est suffisante pour retrouver les liens dissimulés et les partager. Mais si le partage est efficace parce que l’on ne récupère que les liens dissimulés des entités connues, la lecture des liens n’est clairement pas efficace.

Lors de la consultation des liens d’une objet particulier, il faut lire tous les liens de l’objet, facile, et lire l’intégralité des liens dissimulés parce que l’on ne sait pas à l’avance quelle entité à dissimulé des liens pour cet objet. Il manque de pouvoir localement (indépendamment du partage) stocker les liens en fonction des objets source, cible et méta. Mais il faut aussi ne pas dévoiler cette association d’objets cités dans la partie dissimulée du lien, ce qui permet rapidement de lever la partie dissimulée.
Il est possible de transcoder les identifiants des objets cités par le lien dissimulé. On parle bien de travailler toujours sur des fichiers de stockage dédiés aux liens dissimulés, et donc indépendamment des liens non dissimulés. Ce transcodage doit permettre de ne pas révéler l’association entre les objets cités par le lien dissimulé. Ce transcodage peut être commun à tous les objets avec une clé de codage commune, ou chaque objet peut disposer de sa propre clé de codage. Et bien sûr, chaque entité dispose de sa/ses clés de transcodage, donc chiffrées avec la clé privée.
Un transcodage avec une clé unique est plus facile puisque l’on peut chiffrer cette clé et la stocker à un endroit unique, mais il est moins sûr que le transcodage à clés individuelles.
Pour commencer on va partir sur la base de la clé unique de transcodage.

Les liens dissimulés dans des fichiers transcodés sont lisibles publiquement et peuvent potentiellement être synchronisés mais ils n’ont pas vocation à remplacer les liens dissimulés dans les fichiers dédiés à la ségrégation et utilisés lors du partage des liens.

Le nettoyage des fichiers des liens dissimulés et transcodés devient un nouveau problème.
Plusieurs entités pouvant localement générer des liens dissimulés, et donc utiliser des clés de transcodage différentes, il n’y a pas de méthode de nettoyage générique des liens dissimulés dans les fichiers transcodés. Seule une entité peut faire le nettoyage de ses propres fichiers transcodés. Il faut donc que ces fichiers transcodés soient clairement associés à une entité.

Il est possible par contre de supprimer tous les fichiers transcodés d’une entité (ou plus). Il faut dans ce cas que l’entité, une fois déverrouillée, reconstitue ses fichiers transcodés.
Cela lève un nouveau problème, comment savoir que tous les fichiers transcodés sont présents et qu’ils sont à jour. Avec cette méthode, il ne faut pas que les fichiers dédiés à la ségrégation des liens dissimulés pour une entité soient manipulés par une autre entité parce que les fichiers transcodés ne seront pas synchrones. Et les transferts ne sont pas possibles.

Les entités ne doivent pas synchroniser les liens dissimulés des autres entités !

Il reste encore des réflexions à mener autour de cette méthode de transcodage.

Implémentation de la gestion des liens dissimulés

La bibliothèque nebule en php orienté objet est en cours de modification pour être capable de gérer les liens dissimulés.

La classe qui gère les I/O reçoit une nouvelle fonction parce que la demande de liens dissimulés ne se gère pas de la même façon que les autres liens.
La partie écriture a été modifiée aussi afin de détecter si le lien à écrire est dissimulé ou pas. Dans le cas d’un lien dissimulé le fichier de stockage est différent.
Et lors de la lecture de liens dissimulés, il est possible de préciser un signataire, ce qui cible directement un seul fichier de liens à lire.

La classe qui gère les liens va être modifiée pour être capable d’interroger la classe des I/O pour les liens dissimulés ou non.

Liens hypertexte et insertions

Liens hypertexte

Le lien hypertexte a fait le succès de l’Internet en permettant depuis un document HTML de pointer vers d’autres documents HTML, ou d’autres ressources, et sur d’autres serveurs à travers tout l’Internet. C’est tellement pratique que d’autres programmes reprennent le même principe, par exemple les outils de bureautique qui permettent de pointer vers des fichiers externes sur le réseau ou localement sur la machine.

Le lien hypertexte ou ses équivalents utilisent une balise dans le texte du document. Cette balise est interprétée par le programme exploitant le document pour l’utilisateur. Et à la place de la balise on montre à l’utilisateur un contenu descriptif sur la destination comme un texte ou une image.

Dans les objets manipulés par nebule, il est possible d’ajouter une balise propre à nebule. Cette balise ne peut pas être la même que pour un document HTML parce que les objets peuvent ne pas être exploités via une page web. La balise doit se déclarer comme balise nebule et faire référence à un objet avec un élément de remplacement. Dans le cas de l’application sylabe, la balise sera remplacée par un lien HTML pointant vers l’objet mais sur le même serveur web.

Ici pas de nécessité de localisation dans la balise parce que la cible, un objet, est une URI et non une URL. Et le protocole n’est pas précisé parce que c’est le programme qui génère l’affichage qui va se charger de choisir le moyen de renvoie, HTTP, FTP, SMTP, XMPP, etc…

Insertions

Mais de la même façon, une balise peut être utilisée pour non plus renvoyer l’utilisateur vers une ressource externe mais plutôt pour inclure une ressource dans l’affichage présenté à l’utilisateur d’un objet. On obtient ainsi plusieurs contenus affichés en même temps par l’intermédiaire d’un seul objet maître.

C’est ce qui est fait par exemple dans l’inclusion de parties dans une page d’un Wiki.

Cela veut dire que les objets contenus doivent être présents sur le serveur pour permettre un affichage complet. Dans le cas contraire il devra être montré clairement à l’utilisateur qu’une partie du contenu manque.

Chaque objet peut avoir une mise à jour. Il est judicieux pour un même objet maître de ne pas suivre les liens de mise à jour des objets contenus. Mais il est possible de générer et de suivre les mises à jour de l’objet maître intégrant celles des objets contenus.