Journal Camlistore, système de stockage universel, opensource et protégeant de la vie privée?

Posté par (page perso) . Licence CC by-sa
35
2
juil.
2013

Étant abonné à la liste des développeurs de Mozilla Persona/Identity, j'ai vu qu'ils parlaient de l'évolution de Camlistore, produit que je ne connaissais pas. ( http://camlistore.org/ )

Comme j'ai fait une recherche avec le mot Camlistore sur linuxfr, et que ça ne m'a donné qucun résultat, je me permet d'en toucher quelques mots.

Camlistore est sensé être une sorte de système de stockage hybride et universel :
- Système pub/sub (publication de flux, abonnement à des flux) qui regrouperait les fonctionnalités d'un CMS classique avec flux RSS, d'un flux XMPP, ou Twitter…
- Média d'interaction sociale à la facebook/diaspora/g+ (qu'on appelle "réseau social") le fait de pouvoir partager, commenter, taguer, créer des groupes, apprécier etc. Voire de télécharger toutes les photos de l'anniversaire de l'oncle Fred.
- Système de stockage de contenus classique en arborescence (Posix) et/ou sémantique sans arborescence, au choix, selon les besoins. En fait, camlistore est sensé pouvoir adopter n'importe quel modeling.

Le tout avec plein d'API (ligne de commande, FUSE, interfaces web) à la manière d'un Citadel ou d'un Salut-à-Toi.

À noter toutes les "promesses" de ce MultiDeskOS du cloud, qui en plus d'être opensource et selon toute vraisemblance libre, puisque publié sous licence apache, serait universel, extrêmement protecteur de la vie privée (même utilisé sur une infrastructure cloud propriétaire), langage-agnostique (désolé pour l'anglicisme, c'est pour dire que ça ne dépend pas d'un langage informatique particulier), protecteur des données avec du mirroring, backup, versionning dans tous les sens, avec un super-moteur de recherche qui permet de retrouver en deux clics toutes ses données grâce à son intelligence sémantique, il ferait du pain et des smoothies que ça ne m'étonnerait plus…

Cependant, c'est un projet soutenu à 20% par google. Évidemment ça ne veut rien dire, ce projet peut connaître la même destinée qu'un Google Wave, d'autant que si ça fonctionnait vraiment, ça créerait sûrement une forte concurrence à toutes la galaxie de services de Google…

En attendant, vous pouvez toujours leur envoyer des bitcoins, ils les acceptent.

  • # et une vidéo de démo, une !

    Posté par . Évalué à  6 . Dernière modification : le 02/07/13 à 11:51

    https://developers.google.com/live/shows/806271345

    à noter que d'après la liste des contributeurs, Julien Danjou, développeur de l'excellent awesome, travaille également sur ce projet

    Concernant le soutien à 20% par google, j'ai compris cela différemment: les responsables du projet travaillent pour google et profitent du fait que leur employeur les encourage à utiliser 20% de leur temps de travail à d'autres projets que ceux de la société. Il ne s'agit donc pas d'un soutien financier direct, ou d'une main mise sur les droits relatifs à ce projet.

    • [^] # Re: et une vidéo de démo, une !

      Posté par . Évalué à  2 . Dernière modification : le 02/07/13 à 18:22

      Si c'est leur temps de travail c'est donc payé et c'est donc d'une certaine façon un soutien financié. C'est une bonne initiative…qu'on est pas prêt de voir partout.

  • # 20%

    Posté par (page perso) . Évalué à  9 .

    Il n'est pas soutenu à 20% par google, c'est un projet 20% de quelques employés Google.

    Les contrats de travail de Google laissent 20% de leur temps aux employés pour faire ce qu'ils souhaitent, et ce sans que Google y ait des choses à dire (sauf si c'est manifestement un plagiat).

    Donc en gros, ce projet n'a presque rien à voir avec Google :)

    • [^] # Re: 20%

      Posté par (page perso) . Évalué à  2 . Dernière modification : le 02/07/13 à 12:21

      Merci pour la précision (ainsi qu'à Pierre Maziere). C'est clair que j'avais complètement déformé le propos du coup. D'un certain point de vue, c'est rassurant, ce n'est peut-être pas encore un projet qui finira dans le cimetière aux éléWWW la fondation Apache :]

      • [^] # Re: 20%

        Posté par . Évalué à  2 .

        Dans 1 mois, il sera devenu un Apache Top-Level Project, comme 99% des projets apache.

        A quand le ChuckNorris-Level Project™ ?

    • [^] # Re: 20%

      Posté par . Évalué à  4 .

      Etant fortement impliqué dans ce projet (et accessoirement pas chez Google), je peux vous confirmer que ce projet n'est pas du tout sous la tutelle de Google. Il se trouve juste que Brad en est le "leader", qu'il bosse dessus pendant ses week-ends, et que comme il est chez Google, tout travail qu'il produit est Copyright Google.
      D'où la différence entre le fichier AUTHORS et CONTRIBUTORS, comme pour le projet Golang.

      Mathieu
      (qui avait un autre compte linuxfr mais qui ne le retrouve plus).

      • [^] # Re: 20%

        Posté par (page perso) . Évalué à  2 .

        pendant ses week-ends, et que comme il est chez Google, tout travail qu'il produit est Copyright Google.

        Meme ce qu'il produit pendans ses week-ends ?

        • [^] # Re: 20%

          Posté par . Évalué à  4 . Dernière modification : le 02/07/13 à 17:04

          Oui, c'est ce qu'il m'a dit.

          Il s'en fiche puisque le soft est sous licence Apache. c'est même gagnant-gagnant d'une certaine manière; ce qui lui importe c'est que le soft soit libre, et en plus si jamais y'a des soucis de Copyright avec quelqu'un un jour, ce n'est pas lui qui aura à s'embêter avec les procès et les avocats, puisque c'est Google qui devra défendre le projet.

        • [^] # Re: 20%

          Posté par (page perso) . Évalué à  3 .

          Vu que c'est une concurrence directe pour son employeur, ça me semble plus ou moins normal.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

  • # Petites précisions

    Posté par (page perso) . Évalué à  10 .

    Merci pour le journal. J'avais moi-même jeté un oeil là-dessus il y a peu et j'aimerais apporter de petites précisions sur son fonctionnement interne pour démystifier un peu la chose :

    Dans camlistore, tout est blob. Un blob est une suite d'octets. Lorsqu'on la rentre dans camlistore, celui-ci va nous sortir le hash SHA1 du blob et identifier ce blob avec ce hash; ce sera son identité (et elle a le bon goût d'être stable, puisqu'elle dépend uniquement du contenu de la suite d'octets).

    Seulement voilà, une suite d'octets c'est bien gentil mais pas très flexible. Par exemple, je sais pas si c'est un fichier texte ou un fichier image… Pour résoudre ça, je vais donc ajouter un autre blob, qui sera une structure spécifiant tous les attributs de ma suite d'octets :

    • type: c'est un fichier
    • objet en question: le hash du contenu pur
    • taille: 1234 kO
    • utilisateur UNIX: rakoo
    • groupe UNIX: users
    • et d'autres paramètres selon l'envie

    Cette structure est à mettre au format JSON et à stocker dans camlistore, qui va nous ressortir… un hash SHA1. Et oui, cette structure sérialisée est en soi un blob, donc je la stocke en tant que blob dans camlistore ! Et si je veux accéder au contenu, je vais voir dans le champ "objet en question", j'y lis le hash du contenu et je vais lire ce contenu !

    Et on peut monter comme ça au dessus, en décrivant un dossier comme un ensemble de fichiers avec quelques attributs, et cet ensemble de fichiers sera décrit comme une liste de fichiers, et chacun de ces fichiers sera décrit comme précédemment…

    Maintenant, ça marche bien pour des fichiers immutables, mais comment on fait pour des fichiers que l'on souhaite modifier ? "Simple": on va créer un permanode, un noeud totalement au hasard, qui aura donc un hash SHA1 totalement au hasard, disons "hash-permanode". On va ensuite créer une autre structure JSON avec comme attributs:

    • type: modification
    • lié au permanode: hash du permanode
    • modification: ajout du tag "demo"

    et je vais stocker ça dans camlistore qui va là encore me donner un hash, disons "hash-ajout-tag". Ce hash représente ainsi un objet mutable auquel j'ai ajouté un tag et celui-là uniquement. Je peux ensuite apporter une modification, et dire que je veux que cet objet ait comme contenu le fichier précédemment entré dans camlistore. Je vais alors avoir un nouveau hash, disons "hash-ajout-contenu", qui représentera mon fichier avec le tag "demo" et avec un pointeur vers le contenu du fichier. On voit donc qu'on a tout naturellement un système de versionnement qui vient se mettre en place: j'ai 2 versions d'un objet unique qu'on peut appeler "hash-permanode", la première étant "hash-ajout-tag" et la deuxième étant "hash-ajout-contenu" ! Et si je veux accéder à la dernière version de l'objet, je vais directement demander "hash-permanode", qui est en fait une indirection vers l'ensemble des modifications mergées jusqu'à la dernière version !

    L'approche tout-hash n'est pas nouvelle, et le système le plus connu qui fait ça est certainement git. git utilise un système beaucoup plus basique, puisque les types d'objets sont fixés (contrairement à camlistore où c'est totalement dynamique), il n'y en a que 4, et chacun est très simple… mais le principe est exactement le même : un fichier est hashé et son contenu brut stocké, la liste des fichiers avec le nom et les droits UNIX et un pointeur vers leur contenu brut est hashé et son contenu stocké, et un commit avec les informations importantes et un pointeur vers la liste des fichiers est hashé et son contenu stocké. Tout pareil.

    Maintenant qu'on a posé les bases, on peut s'amuser à faire tout plein de choses :

    • toutes les données sont auto-vérifiées, puisque leur identifiant est leur hash SHA1.
    • on l'a vu, par construction l'historique complet depuis la création du fichier est là. En fait, ça crée un autre problème : comment vider les anciennes versions pour faire de la place.
    • la synchronisation est "triviale" : il "suffit" d'envoyer les hash qui ne sont pas présent de l'autre côté.
    • le partage avec un autre utilisateur est trivial : il suffit d'envoyer le hash de la donnée, l'autre peut prendre la donnée d'où elle veut (avec le bonus qu'elle est auto-vérifiée): mon serveur de stockage, son serveur de stockage, un serveur de stockage tiers qui fournirait ce service, peu importe…

    Camlistore c'est aussi plein de bonnes idées :

    • C'est du HTTP+JSON. On n'est certes que lundi, mais le HTTP et le JSON sont compréhensibles par à peu près tous les langages existants.
    • La gestion des données du point de vue utilisateur se fait via un moteur de recherche (venant de gens de Google, rien d'étonnant là-dedans): celui-ci va indexer par exemple tous les objets JSOn qui ont un attribut "tag", et qui ont "fichier" comme "type", pour que l'utilisateur puisse chercher ses fichiers avec un certain tag. On retrouve là l'un des concepts de CouchDB, à savoir que tout est JSON et que les données se trouvent à posteriori via des requêtes bien placées, mais en étant un peu plus générique.
    • Certains blobs peuvent être gros, et ça peut être sous-efficace de tout stocker d'un coup. Du coup ils ont implémenté le protocole de split de bup. Pour résumer, le principe est d'avoir une somme de contrôle spéciale dans laquelle on met tous les octets un par un et on regarde le résultat après chaque octet. Dès que le résultat a une forme spéciale (aujourd'hui, lorsque les 13 derniers bits sont à 1), on dit qu'on a atteint un octet frontière, et on casse le fichier entre l'octet frontière précédent et celui-ci. On a comme ça un découpage du fichier en blocs de taille variable qu'on va stocker dans camlistore en lieu et place du fichier complet, en général assez faible (quelques centaines de kO tout au plus), mais au moins si le fichier change peu, il n'y a pas besoin de stocker tout le nouveau fichier, juste les nouveaux blocs. On en avait déja parlé ici.
    • Il y a une gestion des droits pour le partage avec d'autres utilisateurs, et d'identités. Plutôt que de réinventer la roue, les auteurs ont décidé d'utiliser PGP.
    • Un seul et unique binaire pour le serveur. Yapasplusimple.
    • [^] # Re: Petites précisions

      Posté par . Évalué à  4 .

      Petite correction sur l'histoire des "modifications mergées jusqu'à la dernière version", juste pour être sûr qu'il n'y ait pas de confusion.
      Il n'y a pas de merging/fusion ou quoi que ce soit du genre. Tous les claims (modifications) restent stockés et distincts, et il n'y a pas à proprement parler d'objet qui représente la dernière version.

      Simplement, quand on demande à voir l'état d'un permanode, l'indexeur va retourner le dernier claim pertinent en date pour chaque attribut (ou un sous ensemble, selon la requête). De même, lorsqu'on veut annuler une modification, il n'y a pas supression du claim concerné; un nouveau claim invalidant le claim concerné est créé.

      • [^] # Re: Petites précisions

        Posté par . Évalué à  2 .

        J'ai plein de question !

        On peut imaginer que chaque bloc est crypté avec un AES, la clef est dans le fichier chapeau. Il suffit qu'un fichier top, soit crypté avec gpg, pour que "ses amis" puissent lire l'arborescence, non ?

        Pourquoi rester avec http ? On peut imaginer utiliser bittorrent pour diffuser les données. On peut même imaginer une sauvegarde par duplication chez les voisins, sécurisé par le cryptage symétrique, cela permet d'évacuer le problème de disponibilité des données si elles sont dupliquées et accessible ailleurs que sur un serveur perso.

        On peut même utilisé un cloud sans avoir peur de la NSA (sauf si elle casse de l'AES ayant une clef issue d'un vrai hasard et non un hash de mot de passe trouvé par un humain)

        Pourquoi avoir choisi sha1, et pas un truc encore complétement sûr comme sha256 ?

        Pour gérer les mises à jour, pourquoi ne peut jouer sur un numero de version basé sur une date, dans le fichier chapeau ?

        "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

        • [^] # Re: Petites précisions

          Posté par . Évalué à  3 .

          Pourquoi rester avec http ? On peut imaginer utiliser bittorrent pour diffuser les données. On peut même imaginer une sauvegarde par duplication chez les voisins, sécurisé par le cryptage symétrique, cela permet d'évacuer le problème de disponibilité des données si elles sont dupliquées et accessible ailleurs que sur un serveur perso.

          Parce que http est bien plus souple. parce que tu as besoin de faire des requêtes et toutes sortes de transferts point à point, et de définir une API par dessus. parce que le support http en Go est plus avancé que celui pour bittorrent. probablement aussi parce que Brad est un expert dans ce domaine. Si ma réponse n'est pas satisfaisante, la ML camlistore@googlegroups.com est là pour ça. :-)

          Pourquoi avoir choisi sha1, et pas un truc encore complétement sûr comme sha256 ?

          Parce que sha1 suffit contre les collisions accidentelles. Ceci dit, ce n'est pas (complètement) codé en dur évidemment, et la possibilité d'utiliser d'autres hashes est bien sûr prévue.

          Pour gérer les mises à jour, pourquoi ne peut jouer sur un numero de version basé sur une date, dans le fichier chapeau ?

          Quelles mises à jour?

          • [^] # Re: Petites précisions

            Posté par . Évalué à  2 .

            Si le but est de faire des échanges de fichiers, le binaire de bitorrent peut être utiliser telquel. Il reste les notifications (le push) a coder. Mais on eut imaginer un message purement textuel que l'on mettre n'importe ou (forum, twitter, tribune,…).

            "Quelles mises à jour?"

            Celle d'une donnée, un blob.

            "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

            • [^] # Re: Petites précisions

              Posté par . Évalué à  1 .

              Quelles mises à jour?

              Celle d'une donnée, un blob.

              Les blobs sont immuables.

        • [^] # Re: Petites précisions

          Posté par . Évalué à  1 .

          Pourquoi rester avec http ?

          Je suis pas rentré dans tous les détails de la bête, mais il me semble que
          1/ c'est fait pour être déployé à la maison, aussi bien qu'au DC
          2/ comme il gère nativement les fichiers fragmenté en blocs, je me dit qu'une fois qu'il y à un tracker et/ou un algo de découvrement des pairs proches, alors il n'y à pratiquement plus rien à faire. Et puis si tu shootes un email à ton ami, tu n'as besoin ni de l'un ni de l'autre !

          Ici http://camlistore.org/docs/uses

          Decentralized sharing system: share anything of yours with anybody or everybody (private is the default). This is already starting to work. See sharing.

          bon je ne plus retrouves le lien d'hier où j'avais lu des exemples de fichiers splittés avec des blobref en pagaille stacker dans un paramètre GET, qui d'ailleurs me faisait me demander si il supportait les short-tags pour les signatures comme GIT sait le faire car à empiler les blobrefs on va atteindre la limite de la taille d'une url, bref une paille quoi : )

    • [^] # Re: Petites précisions

      Posté par . Évalué à  5 .

      Merci beaucoup pour toutes ces informations sur le fonctionnement de camlistore, c'est très instructif. J'aurais juste une question: quand tu dis

      la synchronisation est "triviale" : il "suffit" d'envoyer les hash qui ne sont pas présent de l'autre côté.

      je me demande comment on fait pour réconcilier deux données qui ont évolué différemùent. Le merge est à faire explicitement, comme avec git?

      • [^] # Re: Petites précisions

        Posté par (page perso) . Évalué à  4 .

        Je dois t'avouer que je ne suis pas dans les arcanes de camlistore, je fais ici que supposer, considérant la vision des créateurs et le travail existant dans le milieu. Si quelqu'un pouvait corriger, ce serait bien sympathique.

        Pour faire simple, camlistore ne fera rien. camlistore n'est qu'un serveur de contenus, avec quelques petits plus par-dessus pour chercher et te montrer rapidement ce qui t'intéresse. Les conflits entre versions de fichiers sont le problème de l'application qui est au-dessus (le fait même que ce soit un conflit est le problème de l'application, pas du serveur de blobs). Fais le parallèle avec le système de fichiers : comment il gère les conflits entre versions ? Il ne les gère pas, c'est à l'application qui utilise les données en tant que version de gérer ça : prendre un bout de ce qu'il y a à droite, un bout de ce qu'il y a à gauche, mélanger le tout, enregistrer dans le système de fichiers, tout ça est le problème de l'application. Le système de fichiers ne fait qu'enregistrer ce qu'on lui dit d'enregistrer, rien d'autre, exactement comme camlistore.

        git est différent dans la mesure où c'est un gestionnaire de versions de code source. Il va donc t'avertir qu'il y a un problème dans les versions, parce que c'est son boulot.

        Et comme le dit mpl, merge est un mauvais mot. Ce qu'il se passe est qu'il va juste afficher la dernière version de chaque propriété de l'objet. Ça peut tout à fait être faux, mais dans ce cas c'est faux pour l'application seulement et c'est à elle de créer une nouvelle version (plus récente, donc) avec les propriétés qui vont bien. Du point de vue de camlistore, tant que le contenu matche avec le hash (il y a aussi d'autres choses notamment pour l'indexation du contenu, c'est encore un peu flou pour moi), les données sont correctes.

  • # merci !

    Posté par . Évalué à  2 .

    La précision était la bienvenue.

    Pour ceux qui se posent encore des questions,
    http://camlistore.org/docs/uses
    http://camlistore.org/docs/overview

    +1 pour l'explication du permanode !

    • [^] # Re: merci !

      Posté par . Évalué à  2 .

      Par contre, c'est du Go. Et il faut une version assez récente du langage (plus que ce que fournissent les distribs, apparemment).

      • [^] # Re: merci !

        Posté par . Évalué à  1 .

        je l'ai compilé sous debian testing sans aucun souci

        • [^] # Re: merci !

          Posté par . Évalué à  5 .

          Le problème, c'est qu'un serveur web qu'on met sur internet sera plutôt sur Stable.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: merci !

        Posté par . Évalué à  4 .

        On refuse de compiler avec toute version en dessous de Go 1.1, certes. C'est une solution de facilité qui nous permet d'enlever certains hacks qui étaient nécessaires pour Go 1.0. Si quelqu'un en a vraiment besoin, ce n'est pas très difficile de remettre ces hacks et de désactiver le check pour Go > 1.1.

        Après, toute personne faisant sèrieusement du Go vous encouragera clairement à installer Go 1.1. C'est officiellement la version stable, quoi qu'en disent les paquets des distros.

        • [^] # Re: merci !

          Posté par . Évalué à  5 .

          Après, toute personne faisant sèrieusement du Go vous encouragera clairement à installer Go 1.1. C'est officiellement la version stable, quoi qu'en disent les paquets des distros.

          Les distros n'en disent rien du tout.

          Si la version X du logiciel machin était la version stable au moment où la distro a été releasé, alors la version X restera la version utilisée sur la distro pendant tout le reste de sa vie. Sauf mise à jour ou backuport de sécurité, ça ne devrait plus bouger.

          Il peut y avoir quinze version stable du logiciel sorties entre temps, les distros s'en branlent. T'as qu'à te l'installer en local si tu le souhaite. Ce n'est pas le problème du mainteneur de la distro (que tu n'iras pas ennuyer si tu casse tout de ton côté).

          C'est le prix de la stabilité.

          Le FN est un parti d'extrême droite

          • [^] # Re: merci !

            Posté par . Évalué à  5 .

            bah de toute façon, vu comment il est simplissime de compiler une source go, même en cross plateforme (quoi que j'ai pas encore testé en 1.1), il est hautement préférable, dans ce cas là en effet, de passer outre ta distro.

            Go c'est d'la balle ! Allez y mangez en tant que faire ce peut.

  • # Publicité mensongère

    Posté par (page perso) . Évalué à  9 .

    Non mais allô !

    Appeler un logiciel Camlistore alors qu'il est écrit en Go, c'est un peu comme si on décidait de lancer un noyau iLinux…

    • [^] # Re: Publicité mensongère

      Posté par . Évalué à  2 .

      Officiellement, on ne refuse aucune contribution dans d'autres langages (surtout pour les clients). Après, on fait presque tout en Go parce que c'est ce qu'on préfère et que c'est le plus adapté pour ce genre de projet (je ne vais pas me lancer dans un débat sur les langages), et tant qu'on y est on élimine peu à peu toutes les dépendances inutiles (surtout aux niveau des outils tiers et du système de build). Genre scripts perl, shell, makefile…

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.