Le groupe ?

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)

Début de l’expérience 3

L’expérience 3 est lancée.

Introduction

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.

Fin de l’expérience 2

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 !