Suite aux réflexions du post du 06/08, voici les premières expérimentations.
Cette expérience ce fait sur un objet en ne tenant compte que des objets directement liés (niveau 1).
L’image résultant de l’objet c296a1b21db92be313bfd62e31192af5, générée automatiquement :
Continuer la lecture de Tracé de graphes objets/liens, mise en pratique 1
Suite au post du 7 août.
Le groupe est une notion assez générale qui désigne un certain nombre d’objets reliés entre eux par un seul objet. Ces objets pouvant être des entités.
Il y a deux façons de l’implémenter, en fonction de ce que l’on veut en faire :
– le groupe uni-polaire
– le groupe multipolaire
Qu’est ce qu’un groupe?
On le comprend habituellement comme un groupe de personnes.
Quel est la définition du groupe?
Qui/quoi attache des personnes à un groupe?
Comme est interprété un groupe attaché à un autre groupe?
Quelle est la solidité du groupe? Sa résilience?
Comment le traduit cryptographiquement?
Comment l’intégrer à nebule?
Est-il restreint à des entités ou peut-il intégrer des objets autres?
(voir suite sur le post du 20 août)
L’expérience 3 est lancée.
Cette nouvelle expérience doit permettre de gérer des objets privés, c’est à dire chiffrés.
Aujourd’hui, il est difficile d’exploiter des fichiers chiffrés sans devoir au préalable les déchiffrer. La messagerie est mieux logée puisque avec des certificats ou des clés PGP il est possible de lire mais aussi d’écrire nativement des messages.
En attendant de pouvoir nativement lire et écrire des objets chiffrés, il faut exploiter plusieurs capacités des liens. Il faut commencer par gérer la création d’un objet non chiffré (L), le mettre à jours vers sa version chiffrée (U) et supprimer le fichier en clair (D).
La suppression de l’objet en clair ne signifie pas la suppression de ses liens. Ainsi, si celui-ci est récupéré ailleurs, étant déjà marqué d’un lien de suppression, il sera automatiquement supprimé de nouveau. Les liens étant publics, la suppression va se propager entre entités de confiance.
L’expérience 2 est terminé. Elle restera néanmoins comme base d’objets et de liens pour la suite.
Conclusions de l’expérience :
Premier constat, déjà vu avec la première expérience, le nombre de fichiers tient bien dans un répertoire sans provoquer de ralentissement notoire. L’affichage est plus lent parce que le résultat passe par le réseau, mais la consultation d’un fichier particulier n’est pas visiblement plus lente. Par contre, difficile de traiter dans un shell bash une boucle avec autant de fichiers. La commande rm * ne marche plus avec une erreur disant qu’il y a trop d’arguments. Il faut la relancé avec moins de fichiers, par exemple rm a* .
La représentation sous forme de texte des liens est le minimum. Ca fait un peu un effet Matrix avec tous ces chiffres. Mais si on peut naviguer d’un objet à un autre, ce n’est pas très lisible et il faut la pratiquer pour s’y retrouver. Difficile de savoir du premier coup d’œil où on est ou quel est le type d’objet.
Certains objets ont une très grande quantité de liens. C’est impossible à afficher. Est-ce vraiment utile d’avoir un affichage complet de ceux-ci justement? N’est-il pas préférable dans certains cas de n’afficher que les derniers? Voir de n’afficher par défaut que sur certains critères? Ceci oblige à mettre en place une consultation des objets plus fine.
Dans cette expérience, tous les objets ont été liés sur une courte période de temps, de l’ordre de quelques heures. Mais en fait, les objets manipulés ont été créés sur plusieurs années. Ne faut-il pas donner par défaut les liens sur une période de temps défini, et de permettre de récupérer des liens sur des périodes de temps plus grandes moyennant une plus grande latence?
Quel valeur donner à un objet?
Peut-on se baser sur le nombre de liens, auquel cas des objets, comme 77d626eb24d2bae8391953237c40f058 qui contient « mime-type », deviennent des super stars? Or cet objet par exemple est (presque) toujours un objet méta et n’est donc jamais source d’un lien.
Et le plus important : ça marche !
La deuxième expérience monte le manque de représentation graphique des objets et liens générés.
Suite à la publication d’un projet personnel de Ruslan Enikeev, je me suis intéressé à son travail sur The Internet map :
Continuer la lecture de Tracé de graphes objets/liens, le début
La forme du lien est-elle optimale?
TimeStamp-Action-HashSource-HashCible-HashMeta-Signataire-Signature
Avec HashCible et HashMeta facultatifs.
Le Signataire et la Signature (obligatoirement présente mais éventuellement nulle) sont deux éléments indissociables et à la fin. Ils valident ainsi le (reste du) lien. Continuer la lecture de Agencement du registre de lien
Une deuxième expérience est lancée.
Cette expérience est globalement identique à le première, mais au lieu de générer des métas, on génère des liens.
Expérience 2 en cours…
De fait, l’expérience 1 est clôturée.
La mutualisation de certains objets métas pour relier un objet à une propriété particulière, et notamment pour lui donner un type, nécessite une certaine forme d’abstraction.
Plusieurs questions sont en attente :
Continuer la lecture de Impersonnalité, commutabilité et liens
Le wiki est remis en place sur un nouveau serveur.
En autre, c’est une mise à jour de version majeur, et non juste quelques correctifs appliqués régulièrement.
Reste à reprendre le thème graphique …
Les objets que l’on échange, y compris les textes, sont perdus dans l’océan des objets dont nous disposons.
Que devient un message ou un objet transmit comme message?
Il est naturellement ajouté aux autres objets. Mais en plus, il a un lien signé par une autre entité, donc on peut considérer que cet objet est aussi lié à cette entité.
Ce lien implicite à une entité fait que cet objet a une visibilité par cette entité, en l’analysant on verra cet objet.
Poussons encore plus loin, et si on analyse tous les liens vers des objets que publie cette entité, que voit-on ?
On va voir dans l’ordre chronologique tout ce qu’elle a jugé intéressant à garder, les objets qu’elle a créé, tous les objets sur lesquelles elle est intervenu, les messages que l’on a échangé avec elle, etc…
Les messages (objets échangés) ne sont visibles que si ils sont publics, ou si ils sont chiffrés et que l’on est destinataire.
Cette vue, ce comportement, c’est presque celui des réseaux sociaux!
En suivant le raisonnement sur l’annuaire et la messagerie, on peut aller encore plus loin.
Finalement, rien n’empêche que les entités s’échangent directement les objets messages.
Comment mettre à jour le contenu d’un relais?
Par principe, le relais (ou proxy) se contente de copier des objets. Mais aussi, de fait en tant qu’entité, en les copiant, il propose ces objets en diffusion (au téléchargement).
Quel est l’intérêt?
Cela permet à une entité source, par exemple un humain, de générer des objets et de les faire diffuser par des entités relais qu’il contrôle. Ainsi, il peut ne pas être en permanence accessible (volontairement ou pas). Ses objets restent accessibles si les relais le sont. Plusieurs relais peuvent diffuser les mêmes objets, on ajoute de la redondance et on cumule la bande passante de téléchargement pour quelqu’un qui télécharge un de ces objets, à la manière du P2P (peer to peer).
Question ouverte.
Un lien entre deux entités peut être annulé par l’entité source du lien. Peut-il être annulé par l’entité destination du lien?
Est-ce faisable pour un lien simple? lien double? lien triple?
Quel intérêt? Quels risques? Quelle application pratique?
La messagerie est un comportement assez difficile à reproduire, ou à remplacer dans un monde de liens dans lequel il n’existe pas de « connexion » autre que le téléchargement.
L’annuaire peut peut-être remplir ce rôle.
Le lien étant la partie essentielle du partage de l’information, il doit être définit pour répondre exactement à ce rôle. C’est un des trois piliers de Nebule.
Par essence, sa définition se doit aussi d’être précise et universelle.
Étudions quelques cas…
Revenons un peu en arrière, un peu…
En septembre 1987 est apparut le protocole X. Celui-ci, dans sa version majeur X11, permet le dialogue entre un serveur X et un client X (on n’est pas en science naturelle mais en informatique), typiquement sous UNIX et affiliés, mais pas exclusivement.
Un de ses avantages, c’est la transparence réseau. Mais, étant finalement peu employée, c’est aussi un inconvénient.
A quoi sert donc cette transparence réseau?
Que gagne-t-on à la garder?
Quel aurait pu être son avenir? Continuer la lecture de Environnement coopératif
En partant sur le modèle de lien avec objet méta par rapport au lien et non à l’objet source, on se rend compte que c’est un compromis.
L’Uniform Resource Identifier (URI) est une chaîne de caractères permettant l’identification d’un objet de façon univoque et permanente.
(Wikipedia – Licence CC BY-SA v3.0)
L’empreinte d’un objet réalisée au moyen d’une fonction de hash cryptographique est un URI.
(Suite du post Liens simples ou doubles?)
Le problème semble insoluble avec les liens simples pour partager efficacement de l’information sans être dépendant d’un nÅ“ud populaire. Que peut-on faire pour ré-équilibrer le sens de transfert des liens?
La notion d’arborescence convergente est une propriété intéressante, mais gagnerait à fonctionner dans les deux sens. C’est à dire d’être à la fois convergente vers de gros nÅ“uds du réseau, est d’être en même temps divergente en partant de ces gros nÅ“uds. Continuer la lecture de Liens doubles