Routage

Une notion nouvelle émerge de l’utilisation des liens et objets de nebule, c’est le routage.

Cette notion est assimilée au routage que l’on connaît en réseau. Le routage réseau est lui-même dérivé du routage de marchandises. C’est à dire le transports de marchandises variées en masse par la route mais répartit sur plusieurs transporteurs, tel des paquets dans le réseau.

Cette notion profonde de transport de quelque chose d’un point à un autre se distingue du transport par commutation (de circuit). Dans le cas de la commutation, c’est comme si l’on réservait pour un temps donné (qui peut être assez long) une voie de circulation complète de façon continue du point de départ au point d’arrivée. Cette préemption de la route est complète que la route soit utilisée ou pas. Cela peut répondre à des besoins spécifiques, voie réservée aux bus, mais en règle générale c’est plutôt générateur d’une grosse perte de rendement.

Avec les liens nebule, il peut se passer un peu comme du routage lorsque les liens sont générés par l’entité source et synchronisées parfois par des chemins différents vers une autre entité. Il en est de même avec un objet qui, si il est fractionné (liens type s), peut être relayé par des entités différentes, voir être déjà des objets issus de plusieurs autres objets eux-même fractionnés.

Le but est ici de s’assurer (ou pas) du bon acheminement des liens et des objets vers une entité tierce. Si les liens, qui sont signés, doivent impérativement être relayés, les objets peuvent tout à fait être ré-assemblés en fonction de fragments déjà présents chez (ou proche de) l’entité destinataire.

Bien sûr, en temps normal, les entités sont tout à fait capables de se connecter directement les unes aux autres sans passer par des relais. Le routage est une notion qui n’interviendra en pratique que entre deux entités qui sont sur des réseaux filtrés, semi-isolés, ou complètement isolés. Dans ce dernier cas, un vecteur est nécessaire entre les deux réseaux (clé USB par exemple)…

Le weblog et la relation d’objets – 2

Suite de la réflexion sur le weblog et la relation d’objets.

La première expérience avec sylabe sur une arborescence d’objets liés montre qu’il faut privilégier les liens de type dérivation f dans cet usage. Le lien de type l permet avec un objet méta de déterminer la relation entre deux objets dans l’arborescence. Mais c’est déjà ce que fait le lien de type dérivation f sans objet méta. Et si l’emplacement de l’objet méta est utilisé, il n’est du coup pas possible de définir ce que l’on peut appeler un contexte. C’est à dire de définir que les deux objets sont dans une arborescence bien délimitée et non tout le temps liés.

Ensuite, des liens de type dérivation f peuvent être utilisés sans objet méta afin de définir un objet dérivé d’un autre de façon générale. La différence, c’est que sans objet méta, le lien n’est pas utilisé dans l’affichage d’une arborescence d’objets. Mais cela n’empêche pas qu’ils soient utilisés pour améliorer l’affichage de certains objets spécifiques dans la représentation de l’arborescence. Ainsi, une arborescence d’images de grandes tailles gagnera à voir chaque image remplacée une à une par une versions réduite. C’est plus adaptée à l’affichage d’un navigateur web par exemple. La version réduite de chaque image étant liée à l’image originale par un lien de dérivation f.

Cette façon de faire résout les cas de gestion d’un article dans plusieurs nœuds et de gestion d’un article à plusieurs endroits dans le même nœud.

Reste à définir le cas de la gestion d’un nœud sous un autre nœud.

OMS et openPDS

Un article intéressant de InternetActu fait découvrir openPDS (Personal Data Store). On y retrouve les bases autour desquelles gravitent un certain nombre de recherches sur l’amélioration de la gestion des données privées. C’est surtout sur leur contrôle de ces données par l’utilisateur légitime, et notamment leur divulgation volontaire à des tiers. C’est un projet fait en collaboration avec ID3 et dont la base technique est Open Mustard Seed (OMS). OMS est à openPDS ce que nebule est à sylabe.

La solution semble reposer sur un espace de stockage et de traitement centralisé. L’espace de stockage est voulu comme étant sous contrôle exclusif et complet de l’utilisateur détenteur. Le traitement centralisé avec les données permet d’extraire une partie des données sans en exporter plus que demandé. L’export de données pour un traitement délocalisé semble poser un problème pour les auteurs de openPDS. Rien ne semble prévu notamment pour conserver localement certaines données en cache ou pour un mode déconnecté. Les données ainsi pré-traitées peuvent être transmises aux tiers extérieurs.

La centralisation du stockage permet logiquement une grande cohérence de gestion des données. Tout étant en un emplacement unique, le traitement peut en permanence accéder à tout. Il est sûrement prévu un mécanisme de sauvegarde des données dans un autre emplacement, mais c’est un autre débat. Cette centralisation va poser à mon avis deux problèmes. Le premier est la disponibilité en cas de panne de l’infrastructure de stockage. La deuxième réserve concerne le traitement. Pour traiter les données, il faut accéder aux données. Mais en permettant à une machine d’accéder aux données, on permet aussi aux administrateurs d’y avoir accès. On retombe finalement sur une sorte de solution de cloud assez classique. Finalement, qu’est ce qui garanti que les données ne sont pas exploitées par derrière par l’opérateur technique du cloud ? En l’état, rien.

L’identité des personnes est assurée par OAuth2 ou OpenID. La confiance dans les identifiants entre personnes est gérée par une notion de rôles, c’est à dire des groupes auxquels on attribue des droits.

Le site de référence de openPDS ne dit pas quelle genre de données peuvent être stockées et traitées, ou plutôt la variété des données. On manipule potentiellement plus que la géolocalisation, des données bancaires par exemple.

OMS semble vouloir de son côté s’assurer de la bonne application des préférences de confidentialité définies par l’utilisateur légitime sur ses données. Il faut voir comment l’implémentation est réalisée, mais la théorie montre que c’est illusoire.

Enfin, l’ensemble se base sur de la cryptographie pour identifier les personnes et leurs échanges avec les PDS. Mais les données ne semblent pas en profiter. Tout se base sur des droits d’accès, donc des droits assez faibles.

Bon, la critique est facile. OMS et openPDS sont encore très jeunes. Il faut voir comment cela évoluera dans le temps…

L’article de InternetActu fait aussi référence à MesInfos, une initiative de la Fing. Ici l’étendue des données est visiblement assez restreinte : consommation, finances, communication, navigation, mobilité, santé, emploi et énergie. En fait, ça regroupe des domaines de données mais pas des types de données. Le but est ici encore de permettre à l’usager de se réapproprier ses données et leurs usages. Est on est ici aussi au stade de la réflexion préliminaire.

Liens :
http://openpds.media.mit.edu/
http://www.internetactu.net/2013/07/03/dautres-outils-et-regles-pour-mieux-controler-les-donnees/
http://idcubed.org/
http://idhypercubed.org/
http://fing.org/?-MesInfos-les-donnees-personnelles-
http://fing.org/

Le weblog et la relation d’objets

La mise en application des objets et liens nebule dans sylabe montre qu’un aspect important de la relation entre les objets a été sous-estimé.

Prenons l’exemple d’un blog ou d’un fil de discussion sur FB (en autres). Un utilisateur publie un article, un texte en fait. A cet article, tous les utilisateurs (ou presque) peuvent répondre, c’est à dire attacher à l’article un nouvel article. Ce nouvel article est aussi un texte, mais il est subordonné à l’article initial.
On peut ainsi ajouter une infinité d’articles subordonnés à l’article initial ou subordonnés les uns aux autres.

Première remarque à priori. L’article initial, celui de plus haut niveau, a tout intérêt à être déclaré comme étant un nÅ“ud. Mais ça n’est pas obligatoire en fait.

Ensuite, le lien entre l’article initial et les articles qui lui répondent est un lien créant une hiérarchie. Les liens nebule de type l ou f peuvent répondre à ce besoin.

La réflexion est cependant incomplète. Il faut tenir compte de :
– la gestion d’un article dans plusieurs nÅ“uds ;
– la gestion d’un article à plusieurs endroits dans le même nÅ“ud ;
– la gestion d’un nÅ“ud sous un autre nÅ“ud.

A suivre…