Liens des options

Le lien permettant de définir une option, si elle est autorisée à être modifiée, est constitué d’un type l, du nom de l’option, de sa valeur et d’un objet méta de référence nebule/option.

Cette forme de lien est bonne pour un usage locale et personnel des options. Mais il se prête mal à la gestion des options d’entités sous contrôle. Par exemple si on a un serveur de diffusion de contenu, on peut être amené à changer son comportement. Cette forme de lien impose dans ce cas de générer un lien avec l’entité instance du serveur… et donc de connaître obligatoirement son mot de passe.

Peut-être serait-il judicieux de changer maintenant la forme du lien pour inclure une entité. L’objet méta n’a pas grande utilité ici comme référence fixe. La référence pourrait devenir le nom de l’option… et les noms des options deviendraient des objets réservés.

Suite au prochain épisode…

Gestion du cache des objets et liens

La bibliothèque nebule gère maintenant mieux le cache des objets et des liens.

Jusque là tous les objets et liens lus étaient mis en cache. Cela pouvait conduire assez rapidement à une dépassement de la mémoire disponible pour un processus PHP.

Maintenant l’option sessionBufferSize permet de limiter la taille du cache. Par défaut l’option est à 1000. Cette limitation est tout compris, que ce soit les liens ou les différents types d’objets.

Chaque entrée du cache est maintenant datée de sa création ou de sa dernière re-création, c’est à dire à chaque fois qu’elle est utilisée. Au besoin, une place est faite dans le cache pour la nouvelle entrée en supprimant la plus ancienne, càd celle qui n’a pas été utilisée depuis le plus longtemps.

Et en fait cela accélère le calcul des pages parce que l’on a moins de choses à recharger de la session PHP.

Options de désactivation de protection et de dissimulation

La protection des objets est fonctionnelle. La dissimulation des liens des objets pas encore. Les deux sont implémentés dans la bibliothèque nebule.

Mais il y a désormais des options pour les désactiver, elles sont activées par défaut :

  • permitProtectedObject : Cette option active la possibilité de gérer la protection des objets et la possibilité de prendre en compte les liens de type k.
  • permitObfuscatedLink : Cette option active la possibilité de gérer la dissimulation (offuscation) des liens des objets et la possibilité de prendre en compte les liens de type c.

Lorsque une option est désactivée, le type de lien correspondant n’est plus géré, il est explicitement refusé. C’est à dire que les liens existants sont ignorés et les nouveaux liens sont rejetés comme invalides.

Ces options sont encore en cours d’ajout dans le code mais sont déjà fonctionnels pour les liens.

Filtre social de liens sur réputation du signataire

Dans les filtres sociaux des liens, deux nouveaux types sont ajoutés : reputation et unreputation

Cela permettra à terme le tri par rapport à la réputation d’une entité. Cependant, la pondération des entités n’étant pas implémentée, ces deux filtres sont pour l’instant équivalents au filtre social none.

Traitement social des liens sur liste

Typiquement, dans une conversation, on peut n’afficher les messages que de certaines entités. C’est le cas si on a marqué la conversation comme fermée.

Jusque là on listait les liens de tous les messages de la conversation puis le module filtrait les liens par rapport aux entités de la conversation.

Maintenant, la bibliothèque nebule intègre dans la partie calcul social deux nouvelles façons de filtrer les liens : onlist et offlist
Il faut préalablement envoyer au module de filtre social la liste des ID des entités que l’on veut garder ou filtrer puis appeler le filtre.

Cela centralise le processus et simplifie les applications et modules.

Soi-même ou moi-même

Dans la partie gestion sociale de la bibliothèque de nebule, il y avait peu de sous-parties dédiées à des calculs sociaux des liens. Il y avait notamment une partie self dédiée à la reconnaissance de ses propres liens, et son inverse notself pour exclure ses propres liens d’une recherche.

Cependant, la bibliothèque reconnait en quelque sorte deux type de soi. Il y a le soi de l’entité connectée et le soi de l’entité que l’on regarde. En quelque sorte un moi et un soi. Quand on désigne moi-même il est fait explicitement référence à ma personne, ou dans notre cas à son entité. Alors que le soi-même désigne le moi-même d’une personne, qui peut être quelqu’un d’autre, dans notre cas une autre entité.
Dans la bibliothèque, cette distinction apparaît dans la place de deux variables qui portent le même nom $currentEntity. Utilisée dans la classe très généraliste nebule, elle désigne l’entité connectée (déverrouillée). Utilisée dans la classe Applications elle désigne l’entité que l’on regarde, de la même façon que l’on désigne un objet que l’on regarde.

Cela a mené à devoir dissocier le traitement social pour refléter cette distinction. Ainsi self et notself références maintenant l’entité que l’on regarde (au travers d’une Application). Et myself et notmyself désigne l’entité connectée elle-même, c’est à dire l’entité active.

Ce comportement peut parraître subtil mais il prend tout son sens dans l’application messae et le module messagerie de sylabe. en effet, l’affichage de la liste des conversations se fait par rapport à une entité, donc des conversations de soi-même d’une entité. Mais si on ne précise pas d’entité alors c’est de l’entité connectée que l’on parle, donc soi-même.

D’autres types de traitement sociaux des liens seront ajoutés plus tard. Il faudra notamment trouver un moyen de pondérer les liens de ses amis…

Réorganisation des entités spéciales – gestion

Suite des articles Réorganisation des entités spéciales – inventaire de départ. et groupes d’entités.

L’application option permet aujourd’hui d’afficher les autorités globales et locales. Cette interface avec l’instance nebule du serveur doit être le seul point de gestion de ces entités et de leurs rôles. Cette application va donc devoir évoluer pour prendre en compte les évolutions des entités spéciales, et pas seulement les afficher.

Bonne année 2019

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 2018, la réorganisation de la partie graphique est bien avancée. De nouvelles réflexions se font sur une possible implémentation de crypto-monaie basée sur nebule, et donc sur la réliance que l’on peut en espérer. Les réflexions continent aussi sur la réorganisation des rôles provilégiés par groupes.

La documentation technique de nebule migre maintenant 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.

Création d’objet et dissimulation des liens

Lors de la création d’un objet, quel qu’il soit, génère au minimum un lien de définition du hash de l’empreinte. Sauf que la création par défaut de liens peut perturber voir anéantir la dissimulation de la création de l’objet.

Certains liens peuvent être dissimulés au moment de la création ou à posteriori, mais le lien de l’empreinte doit rester visible sous peine de perturber la vérification des objets. Il est possible cependant d’anti-dater le champ date de ce lien pour lui retirer toute référence à une plage temporelle de création. Mais il restera et sera un marque d’association du créateur de l’objet si par ailleurs l’objet a un lien d’usage non dissimulé, y compris d’une autre entité.

Le lien d’annulation de suppression d’un objet est moins critique, si dissimulé il fonctionnera toujours.

Les autres liens définissants des propriétés de l’objet peuvent être aussi dissimulés sans problème.

Le code de la bibliothèque nebule en php intègre ces modifications pour les objets, les groupes et les conversations. Seules les entités ne sont pas concernées, leurs contenus ne pouvant être protégés, dissimuler les liens n’a pas de sens.

Penser à supprimer le lien de l’empreinte reviendrait à faire apparaître l’algorithme dans le lien… et donc à changer significativement la forme des liens et le fonctionnement de nebule.

Non v̩rification crypto et lecture seule РCentre de donn̩es et r̩partition

Suite de l’article sur la Non vérification crypto et lecture seule.

Le problème des très gros objets peut être résolu avec un fonctionnement segmenté de l’application. D’un côté on a l’application principale qui structure et délivre des informations aux utilisateurs, par exemple la page de diffusion des vidéos. Et de l’autre un serveur uniquement dédié au stockage des objets volumineux.

L’application principale peut fonctionner classiquement sur une ou plusieurs instances et faire référence à du contenu, y compris volumineux, hébergé sur un autre serveur. Le contenu est constitué d’objets parfaitement référencés par leurs empreintes et dont l’usage est définit par des liens. On ne fait là qu’exporter le problème des gros objets.

Un serveur uniquement dédié au stockage des objets volumineux va devoir résoudre le problème de la vérification des objets volumineux sans avoir à se poser de question sur leurs pertinences. La pertinence des données, ce sont les applications qui la gère avec les liens. Ce serveur devient ainsi un centre de distribution de données (CDN) dont la stratégie de vérification peut être adaptée. Et là, l’usage des instances sur ces serveurs étant très restreint en fonctionnalité, il est possible d’alléger la vérification des objets. La vérification peut ne plus être systématique avant un téléchargement par un client mais peut être préprogrammée périodiquement lors de faibles sollicitations. Cela veut dire qu’il faut faire confiance à un serveur qui, peut-être, n’est pas entièrement sous contrôle. Il reste possible bien sûr de vérifier la validité des objets après téléchargement.

Reste un petit engrenage à ajouter là dedans. Il faut que la ou les applications, dans des instances différentes, soient capable non seulement de manipuler la référence d’un objet volumineux sans l’avoir effectivement à portée, mais soient aussi capable de faire pointer l’utilisateur sur le bon point de stockage de l’objet volumineux. C’est à dire qu’elles soient capable de désigner le bon centre de données au bon moment.
Pour cela, soit chaque application dispose d’une configuration définissant quel (unique) centre de données utiliser pour les objets dont la taille (défini par un lien de propriété) est supérieure à une limite de vérification. Soit l’application crée un lien (de propriété) définissant pour chaque objet volumineux sur quel centre de données il est disponible. La première solution est la plus simple, la seconde est la plus souple, et les deux peuvent cohabiter.

L’air de rien, le lien définissant sur quel centre de données est disponible un objet volumineux, la deuxième solution, existe déjà. Pour une entité il est possible de définir un lien avec pour objet méta ‘nebule/objet/entite/localisation‘ afin de donner des points de présences d’une entité. Cet objet méta réservé, non utilisé aujourd’hui, pourrait être abandonné et directement remplacé par l’objet méta ‘nebule/objet/localisation‘ plus générique. Ça tombe bien, ce dernier existe déjà… ne reste maintenant qu’à l’implémenter dans le code…

Non vérification crypto et lecture seule

Dans la réflexion de créer une application dédiée à la manipulation de photos et de vidéos se pose invariablement la question des vidéos HD, FHD et UHD. La taille de ce genre de vidéo, pour conserver une qualité de restitution optimale, est assez conséquente.

Le problème ici dans nebule c’est la vérification systématique de la validité du contenu d’un objet manipulé, c’est à dire le re-calcul de son empreinte cryptographique. Si la librairie nebule mémorise le temps d’une session un objet vérifié, dans un cache, ce qui peut déjà présenter un problème de sécurité, il faut cependant toujours faire cette prise d’empreinte au moins une fois.
Par exemple l’empreinte SHA256 d’un fichier de 1,6Go va nécessiter environ 30s sur un disque dur à plateaux normal. La consommation de temps vient principalement de la lecture du support et non du calcul cryptographique. Et la prise d’empreinte cryptographique est un calcul relativement simple…

Il peut en être de même avec les liens qui nécessitent une vérification de signature de type RSA ou équivalent. Ce calcul en cryptographie asymétrique est beaucoup plus long rapporté à la quantité de données. Si un lien ne faire que quelques kilo-octets tout au plus, le nombre de liens à vérifier pour un seul objet peut être potentiellement gigantesque. Au cours du développement des applications de nebule il n’est pas rare de devoir nettoyer à la main les liens de la bibliothèque parce qu’il y en a plus de 80.000 … soit systématiquement 80.000 lien à lire et à vérifier. Là aussi un cache des liens déjà validés dans la session est en place pour accélérer le travail mais ce n’est pas toujours suffisant.

Une possible résolution de ce problème peut être de changer de disque et de passer sur SSD, ou de nettoyer sévèrement les liens utilisés. Mais ces deux cas sont extrêmes et pas toujours réalisables.

Une autre solution peut être envisageable dans le cas de machines de relais ou de partage d’informations en particulier. Comme on l’a vu dans l’article Frontal et relai d’information verrouillé en écriture, il est possible d’avoir des serveurs en lecture seule en activant l’option de lecture seule ou en figeant le système de fichiers. Cela pose des contraintes particulières sur la synchronisation des objets et des liens et sur le fait qu’ils doivent être vérifiés à un moment ou à un autre. Dans ce cas on peut coupler une option de non vérification des objets et des liens avec une option de lecture seule.
Avec cet exemple une entité peut toujours d’authentifier afin d’accéder à du contenu protégé mais ne pourra réaliser aucune action.

On peut imaginer aussi que l’application de mise à jour (upload) peut être autorisée à mettre à jours des liens et des objets en les vérifiant et ainsi avoir un serveur partiellement en lecture seule.

Donc il serait possible d’avoir un serveur de relai d’information en lecture seule uniquement mais avec un fonctionnement accéléré.
Ceci n’est pas implémenté actuellement.

Le message et le messager

Dans sylabe, il y a une implémentation de la messagerie.

Mais la messagerie tel que l’on a l’habitude de l’utiliser est un peu réductrice dans sa forme. L’article d’un blog comme le commentaire sur un réseau social sont aussi des formes de messages. Dans nebule, il est fort probable que ce soit la même information mais avec une présentation différente.

Dans un système de gestion de l’information dans lequel chaque information est intégrée dans un fichier avec ses usages, c’est à dire ses méta-données, une information transmise pour un nouvel usage devient un nouveau fichier. C’est le cas par exemple de la messagerie dans lequel un message retransmit à une nouvelle adresse devient un nouveau message alors qu’il contient la même information à la base. La différence, c’est que les destinataires du premier message ne sont pas forcément au courant du nouveau message et donc du partage de l’information. Ce non partage de certaines informations de diffusions (méta-données) est géré dans nebule par la mise en place de l’offuscation des liens.

La transmission d’un message c’est simplement la transmission d’une information. Ce qui permet au destinataire de savoir qu’une information lui est destiné c’est le fait de l’inclure dans un lien entre cette information et un objet dédié qu’il scrute. L’objet dédié est de fait un groupe d’objets lui étant destinés, ce qui s’apparente à un salon de discussion d’une messagerie. Ce salon de discussion est désigné par le terme de conversation contenant des messages.

Le mécanisme des conversations mis en place étant un retour à la sources des informations et de leurs usages, cela offre beaucoup de possibilités et de nouvelles perspectives. Une conversation peut être fermée et publique, elle est ainsi visible de tout le monde mais seules certaines personnes vont pouvoir légitimement et publiquement dialoguer dans cette conversation. Toute entité qui ne fait pas partie de la conversation fermée peut émettre des messages dans cette conversation mais ceux-ci ne seront pas vus pas les autres entités à part peut-être ses amis. Un groupe d’amis peut donc commenter en directe une conversation fermée sans perturber le déroulement de celle-ci pour les autres écouteurs de la conversation. Le statut d’une conversation peut être changé par un participant, cela n’impacte pas les autres participants, ce dernier peut ainsi décider de passer la conversation en ouverte et voir maintenant la contribution de tout le monde et non plus seulement les participants… sans plus gêner pour autant les participants.

Un nouveau problème arrive, comment présenter dans une interface ces fonctionnements à l’utilisateur, et de façon intuitive ?…

Définition des groupes

La gestion des groupes est entièrement revue et corrigée dans la bibliothèque nebule en PHP orienté objet et dans les applications (sylabe, klicty, messae).
Une fois les applications mises à jour, les groupes existants disparaîtront.

Cet article invalide la définition de groupe telle que définit dans l’article Définition des groupes du 14/01/2016.

Cette implémentation des groupes sera aussi utilisée pour les conversations contenant des messages.

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.

Continuer la lecture de Définition des groupes

Frontal et relai d’information verrouillé en écriture

Le mécanisme de transmission d’objets et de liens dans nebule permet de distribuer de façon sûr l’information.

Mais le serveur qui héberge des informations et l’application qui manipule ces informations peuvent tous deux être attaqués afin de corrompre ou supprimer ces informations.

Cette capacité de relais fiable de l’information peut être exploité pour maintenir ‘au chaud’ la source de certaines information et n’exposer publiquement que des relais. On peut même avoir plusieurs couches concentriques de relais, ce qui se rapproche beaucoup du chaînage de proxys web. Mais si le cheminement de l’information s’apparente à des sauts entre relais, chaque relai peut être vu individuellement comme un serveur frontal de partage de l’information. Le rôle de frontal l’empêche de relayer automatiquement une attaque, celle-ci doit d’abord compromettre le serveur frontal avant de pouvoir espérer continuer vers la source de l’information.

Enfin, il est possible de faire transiter de 3 façons différents l’information entre source et relais :

  1. le serveur relai va chercher régulièrement de l’information à synchroniser sur la source (ou un autre relai) ;
  2. le serveur source va synchroniser via une connexion montante, et l’application upload, l’information ;
  3. le serveur source va synchroniser l’information en synchronisant le système de fichier, c’est à dire l’intégralité de l’instance nebule.

Afin de renforcer la robustesse d’une instance de serveur nebule, il est possible d’utiliser l’option de verrouillage globale en écriture. Si cette option est forcée dans le fichier de configuration de l’instance, elle ne peut être modifiée via nebule. Mais si cette option interdit au moteur de la bibliothèque nebule d’écrire quoi que ce soit, cela n’empêche pas le serveur web lui même, une application ou un module compromis, d’écrire. Il est aussi possible de rendre impossible l’écriture des objets et liens en changeant les droits sur le système de fichier contenant la page web. Dans ce cas, seule la synchronisation complète via le système de fichier permet de transmettre l’information.

Ainsi, pour l’entité bachue, maître du code, le serveur qui reçoit le nom de domaine, et donc les connexion, est un frontal qui n’a pas de lien réseau direct vers la source, c’est à dire l’entité bachue elle-même.

Le passage par support amovible (air gap) interdit toute attaque directe de l’entité source.

Référencement par défaut

Suite des articles Références d’images, Propriété d’un objet et référence par rapport à un objet et Objet de référence contre suivi du graphe des mises à jours.

La recherche par référence se fait par rapport à un contexte. Ce contexte est définit par le champ méta des liens.

Pour les images, le contexte est définit par un objet contenant ‘nebule/objet/image/reference‘, soit l’ID 1ca96e517fc6ccca45080244c594dd777dc5d3bde0f872f961c28a4e9749ba82.

Pour la bibliothèque nebule en php, le contexte est définit par un objet contenant ‘nebule/objet/interface/web/php/bibliotheque‘, soit l’ID 4297b53cfab1fc41f7820a47d1c21fbf7d0ab83a5ee4f94331c1e0ba1cbb99cf.

Pour les applications, le contexte est définit par un objet contenant ‘nebule/objet/interface/web/php/applications‘, soit l’ID e0150ff815bd5343034ff025624d20f723e2293842ab4eaedabda1ea5790e66b.

Etc…

Mais il n’y a pas que des usages dans des contextes techniques qui sont à prendre en compte. On peut permettre à l’utilisateur de gérer ses références. Pour cet usage un objet de référencement ‘nebule/reference‘ est dédié, soit l’objet 7339ea8fd26c67c3857ca94f9bac47d3841a3b75e799609720b8cc739732a161. La version publique actuelle de sylabe ne le reconnaît pas encore mais c’est le cas dans la version en cours de développement.

La reconnaissance des liens pour les références ne va pas être faite tout à fait de la même façon en fonction de l’usage. On doit être plus restrictif sur les références concernant les applications que pour celles de l’utilisateur. On va se base sur un calcul social de tri différent.

Et pour faciliter la gestion des références par l’utilisateur, un module dédié est en cours de développement. Il est dédié aux utilisateur donc il se base par défaut sur l’objet de référencement dédié aux utilisateurs mais peut très bien se baser sur d’autres objets de référencement.

Enfin, un lien de référence pourra être dissimulé.

Anonymisation/dissimulation des liens

Il y a déjà une série d’articles en 2012 sur la Liaison secrète (et suite), puis en 2014 sur l’Anonymisation de lien (et correction du registre de lien), et enfin en 2015 sur la Dissimulation de liens, multi-entités et anonymat et l’Exploitation de liens dissimulés.

On trouve dès 2015 un schéma d’implémentation d’un lien dissimulé (offusqué) et le mécanisme cryptographique utilisé :

20150627-nebule-schema-crypto-lien-c

Mais la mise en pratique ne suit pas alors que la bibliothèque nebule en php orienté objet est prête à reconnaître les liens dissimulés.

Parce qu’en pratique, il ne suffit pas juste de générer ces liens et de les lire, il faut aussi les stocker de manière à pouvoir les retrouver tout en gardant des performances acceptables lors du passage à l’échelle.

Comme l’anonymisation attendue nécessite la mise en place d’un minimum de déception vis-à-vis d’un adversaire, il n’est pas possible de stocker les liens dissimulés dans les liens des objets concernés. Cela casserait presque immédiatement la confidentialité du lien dissimulé parce que les objets ont souvent chacun des rôles propres et donc des places privilégiées dans les liens qui servent aux usages de ces objets.

Les deux seules informations que l’on ne peut dissimuler sans bloquer le transfert et l’exploitation des liens dissimulés, c’est l’entité signataire et l’entité destinataire (si différente). Donc le stockage ne peut se faire que de façon connexe à des deux entités. Si ce n’est pas le cas les liens ne pourront pas être retrouvés et utilisés lorsque nécessaire.

Prenons le cas d’une entité qui décide de dissimuler la grande majorité de son activité, elle va donc dissimuler tous les liens qu’elle génère (ou presque). Là où habituellement le stockage des liens aurait été réparti entre tous les objets concernés, du fait de la dissimulation ils vont tous se retrouver attachés à un même objet, l’entité signataire. Cela veut dire que pour extraire un lien de cette entité il va falloir parcourir tous les liens. Cela peut fortement impacter les performances de l’ensemble.
Et c’est aussi sans compter le problème de distribution des liens parce que l’on les distribue aujourd’hui que vers les objets source, cible et méta… et non sur les entités signataires. L’entité destinataire est dans ce cas naturellement desservie directement, est-ce un problème si l’entité signataire ne l’est pas ?
Une autre méthode pourrait consister à créer un objet de référence rattaché à l’entité et spécifiquement dédié à recevoir les liens dissimulés. Mais les liens dissimulés ne contenant pas cette objet de référence, on doit créer un processus plus complexe pour la distribution des liens tenant compte des entités signataires et destinataires.
On peut aussi mettre tous les liens chiffrés dans les liens d’un objet c puisque c’est le type de lien après dissimulation. Mais cela veut dire que tous les liens dissimulés de toutes les entités se retrouvent au même endroit. On ne fait que déplacer le problème de la longue liste des liens à parcourir.
Enfin on peut rester sur une des premières idées qui consiste à stocker des liens dissimulés non plus dans la partie du stockage dédié au liens mais directement dans un objet. Le défaut de cette méthode est qu’à chaque nouveau lien dissimulé généré, il faut refaire un nouvel objet avec une novelle empreinte… et donc un nouveau lien pour le retrouver.

On rejoint le problème de la persistance des données dans le temps, de leurs objets et liens associés. Une solution déjà proposée, mais non implémentée, consiste à organiser un nettoyage par l’oubli des objets et des liens dans le temps en fonction d’une pondération.

Pour commencer à expérimenter, les liens dissimulés seront stockés uniquement avec l’entité destinataire. Cela ne remet pas en cause la distribution actuelle des liens. On verra à l’expérience comment gérer un flux massif de liens et son impact sur les performances.

Copier/coller et marquage

Dans les différentes applications sont hérités des classes de la bibliothèque nebule un équivalent du copier/coller. C’est un équivalent parce que cela ne fonctionne pas tout à fait pareil.

Copier un objet que l’on collerait ailleurs pourrait se rapprocher de copier un fichier mais cela ne veut rien dire dans nebule parce qu’un objet copié… ne donnerait que l’objet lui même. Seul une transformation (dérivation) donne un nouvel objet à part entière, aussi infime soit la transformation.

De même, un couper/coller n’a pas plus de sens parce que cela reviendrait à retirer un objet pour le remettre au même endroit.

Quand on parle d’endroit d’un objet, techniquement c’est son emplacement de stockage. Mais pour l’utilisateur d’une application cela peut vouloir dire que c’est l’usage de l’objet qui est copié. On copie donc un usage, c’est à dire plus ou moins un lien, d’un objet pour en faire autre chose. Par exemple on peut vouloir faire apparaître l’objet dans plusieurs endroits différents d’une arborescence.
Pour répondre à cette usage sans usurper la fonction de copier/coller, il a été introduit depuis quelques temps dans les applications la notion de marquage. Marquer un ou plusieurs objets permet ensuite d’y faire référence plus tard ailleurs dans l’application, ou dans une autre application. Ainsi, un objet dans une arborescence peut être marqué puis peut être utilisé dans la messagerie pour le transmettre à quelqu’un.

Le marquage peut contenir des objets, y compris sous forme d’entités de groupes ou de messages, et/ou des liens. L’application qui permet l’usage des objets et liens doit faire le tri de ce qui est utilisable pour elle entre les différents types d’objets et les liens.

Il peut être possible de parler d’un vrai copier/coller ou couper/coller d’un objet non pas localement mais entre plusieurs instance de nebule, c’est à dire entre plusieurs serveurs. Le copier/coller reviendrait à une duplication de l’objet sur une autre instance. Le couper/coller reviendrait à dupliquer un objet sur une autre instance puis à supprimer l’objet localement, par exemple pour faire de la place.

php, gd et mbstring

Pour une installation sous Linux, ne pas oublier les paquets php-gd et php-mbstring permettant d’avoir accès aux fonctions de modification graphique et à mbstring qui va notamment convertir les textes en utf-8.

C’est utilisé par la bibliothèque nebule procédurale incluse dans le bootstrap. Donc si pas de mbstring disponible, ça plante dès le début…

Les documentations sont déjà à jour :

Sous FreeBSD et OpenBSD, il faut compiler php avec gd et mdstring, ou l’installer via les portages avec ces dépendances. Bon… ça fait un moment que le code n’a pas été testé sur ces plateformes par manque de temps.

Debian 8 n’est pas concerné. C’est par défaut en dépendance de php.

L’idéal serait de pouvoir s’en passer pour simplifier l’installation… à voir…

Chargement de liens

Les applications génèrent par elles-même les liens dont elles ont besoin pour répondre aux usages des utilisateurs.

Il est possible de transmettre des liens qui ne peuvent être générés localement. C’est le cas des mises à jours d’applications.
Pour cela, il existe deux méthodes et deux moyens. Le code correspondant à été ré-écrit dans la bibliothèque nebule.

Pour qu’un lien soit traité, il faut que les trois soit validées :

  1. permitWrite : permet d’écrire des objets ou des liens.
  2. permitWriteLink : permet d’écrire des liens.
  3. permitUploadLink : permet de charger des liens.

Les deux méthodes sont :

  • le transfert d’un lien individuel ;
  • le transfert d’un fichier contenant (potentiellement) plusieurs liens.

Les deux moyens sont deux possibilités de transmettre les liens :

  • via l’application upload directement ;
  • via le module module_upload de l’application sylabe.

Lors du chargement d’un lien, quelque soit la méthode ou le moyen, le lien est d’abord vérifié structurellement.
Ensuite la vérification de la signature du lien et de son signataire répond à un processus plus complexe dépendant de deux options et de l’état de connexion d’une entité :

  1. permitPublicUploadLink : permet de charger des liens signés sans qu’une entité en cours ne soit déverrouillée, quelque soit le signataire.
  2. permitPublicUploadCodeMasterLink : permet de charger des liens signés par le maître du code (bachue) sans qu’une entité en cours ne soit déverrouillée.
  3. $this->_unlocked : variable qui donne l’état de déverrouillage de l’entité en cours d’utilisation, càd qu’une entité est connectée.

Si l’entité locale est déverrouillée, le transfert d’un lien devient une action légitime de l’entité. Tous les liens signés sont écrits si ils sont valides (structure et signature). Tous lien non signé est ré-écrit et signé par l’entité en cours; puis écrit.

Cette ré-écriture de lien est une ré-appropriation du lien. Est-ce que cette ré-appropriation peut poser problème ?

Bonne année 2018

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.

Cette focalisation à temps plein sur l’évolution de l’interface est bénéfique à la qualité de l’affichage des applications et à leur utilisabilité. Mais elle est temporaire, pendant ce temps il n’y a de travail ni sur le fond ni sur la théorie et les problématiques spécifiques à nebule.