Structure de liens et RDF

L’étude de la structure de liens à quatre champs objets (quoi quatre champs) crée un parallèle avec la structure du RDF et le bloc des blockchains.

La possibilité de permettre plus de trois champs dans la partie registre du lien crée de nouvelle possibilités certes à la marge mais qui peuvent avoir une utilité. Le premier est d’apporter un contexte à une opération entre source et destination. D’ailleurs, le champ méta devrait s’appeler opérateur. Et comme une opération peut avoir plusieurs contextes possibles le nombre de champs peut dépasser 4. Il faut cependant mettre une limite aux nombres de champs acceptables dans un lien.

signature_signataire_date_action_source_cible_opération_contexte

Mais plutôt que d’ajouter des champs, ou en plus, il est possible de prévoir de gérer deux registres de liens dans un même lien. Voir d’en gérer beaucoup plus. On s’approche là de la mise en forme d’un bloc chère aux crypto-monnaies. Dans cette forme, une partie commune contient la signature et la référence de temps. L’action doit rester associé au cÅ“ur du registre de lien. L’action permet aussi de marque un lien dissimulé et donc de le traiter comme tel. Cela nécessite de modifier la forme du lien

signature_signataire_date/action_source_cible_opération_contexte/action_source_cible_opération_contexte

Sous cette forme nous pouvons rejoindre la forme RDF en permettant la réutilisation de champs par indexation. Par exemple lien second cÅ“ur de lien peut référencer les objets 1 et 2, ou 1 et 4 du premier cÅ“ur de lien. Cela abrège l’écriture, prend moins de place mais complexifie la lecture.

signature_signataire_date/action_source_cible_opération/action_2_1_opération
signature_signataire_date/action_source_cible_opération_contexte/action_1_cible_opération_4

Une autre approche est de mieux délimiter le cÅ“ur de lien afin d’ajouter d’autres informations autour. Il n’y a pas une grande quantité d’information à ajouter, ce peut être de multiples signatures, notamment dans un système de cosignature à seuil. Et, à force d’ajouter des choses dans l’enregistrement des liens, il devient utile de placer une version. Les propriétés exploitables du lien seront directement liées à la version donnée. On arrive ainsi à trois types de blocs dans un lien : la version, les registres de liens et les signatures. Là encore la forme du lien enregistré se complexifie pour permettre de retrouver toutes ces parties sans ambiguïté. Et notamment, chaque partie doit être identifiée avec un préfixe, sauf la version si elle est placé avant le reste. La partie horodatage quand à elle doit aussi faire partie de ce qui est signé, dont elle migre vers les cÅ“urs de liens.

(version)(lien/date_action_source_cible_opération)(lien/date_action_source_cible_opération_contexte/action_1_cible_opération_4)(signe/signature_signataire)(signe/signature_signataire)

Il faut cependant veiller à la défendabilité de la structure ainsi créée. Les signatures sont indépendantes les unes des autres et chaque signature doit couvrir la version et tous les cÅ“urs de liens pris dans le même ordre. Jusque là la vérification des liens se faisait après reconstitution de chaque champs et nettoyage afin d’éviter une tentative de contournement. Ce nettoyage préliminaire peut être maintenu même si il sera plus gourmand en temps de calcul.

Cette forme apporte un nouvel intérêt. Puisque les signatures sont séparée, elles deviennent dissociables. Cela veut dire que l’on peut fusionner plusieurs liens identiques mais avec des signataires différents et donc gagner en place.

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

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.

Localisation des objets

La possibilité de localiser un objet ou juste une entité me travaille depuis un moment. Même si cela n’a pas d’application aujourd’hui, il est plus logique de faire remonter la possibilité de localisation au niveau de l’objet. Ainsi, si il sera toujours possible de localiser une entité, on peut imaginer soit localiser un objet soit aussi s’en servir pour demander à un robot d’héberger cet objet.

Ainsi, l’objet méta contenant la propriété ‘nebule/objet/entite/localisation‘ est doublé de ‘nebule/objet/localisation‘ pour l’instant et disparaîtra à terme. CF wiki.nebule.org – Documentation – nebule v1.2 – Objets à usage réservé

Les propriétés ‘nebule/objet/entite/webaccess‘ et ‘nebule/objet/entite/webaccess/firstofall‘ sont périmées et dès maintenant supprimées.

Les différentes propriétés ‘nebule/objet/entite/suivi/...‘ sont en sursit.

Ajout de sentiments sur des objets

Les derniers développements de sylabe on permit de réactualiser l’ajout de marques tel que j’aime, j’aime pas et bien plus encore.
CF : Blog sylabe – Avancement
Ces marques sont regroupées sous le terme de sentiments. Ils sont matérialisés par des liens de type l de l’objet vers le sentiment (un autre objet) et le méta ‘nebule/objet/sentiment‘.

Ces sentiments ont une signification purement humaine. Le code de nebule ne l’interprète pas et n’en tient pas compte. Mais ces sentiments ont chacun des objets dédiés qui eux ont tout intérêt à être communs à toutes les applications. Ils doivent être propagés quoi qu’il arrive comme tout liens. C’est la raison pour laquelle ils seront définis au niveau de nebule.

Leur affichage sera spécifiquement traduit pour être plus lisible et tenir compte de la langue d’affichage. Continuer la lecture de Ajout de sentiments sur des objets

Objet différencié ou indifférencié

Si un lien vers un objet ne contient pas de méta-données, il n’apporte pas d’informations sur le traitement, l’utilisation de cet objet. L’objet doit donc contenir le nécessaire pour que l’on puisse identifier son type, et par extension sa façon de l’utiliser. Il doit être différencié. Si le lien contient des métas, l’objet peut être indifférencié, ce sont les métas du lien qui détermineront le traitement de l’objet.

L’important, c’est qu’au moment du traitement, les données de l’objet aient été différenciées.

Continuer la lecture de Objet différencié ou indifférencié

Liens et méta-données

Quand dans un objet A il est fait référence à un autre objet B au moyen d’une URL, cela correspond à la mise en place d’un lien entre ces deux objets A et B. Ce lien est par défaut à sens unique, il désigne un autre objet.

Mais un lien n’existe jamais seul dans le monde réel, il est souvent accompagné d’informations complémentaires. Ces informations complémentaires permettent de préciser la façon dont on accède et/ou on utilise l’objet désigné. Cela s’appelle une méta-donnée, une donnée sur la donnée (raccourci en méta).

Cette méta s’applique-t-elle à l’objet désigné? Ou au lien?

Continuer la lecture de Liens et méta-données