Donnez votre avis sur la nouvelle architecture de Cozy

Posté par (page perso) . Édité par palm123. Modéré par Xavier Claude. Licence CC by-sa
Tags :
42
31
août
2016
Cloud

Cozy est un cloud personnel que nous suivons et évoquons régulièrement sur LinuxFr.org. Il a fait récemment parler de lui via le recrutement de Tristan Nitot, sa version 2.0, sa quête permanente d'améliorations, sa toute nouvelle application de synchronisation de fichiers ou encore sa récente levée de fonds. Aujourd'hui, l'équipe Cozy Cloud fait appel à vous.

Nous souhaitons développer une nouvelle version majeure de Cozy qui puisse répondre à de nouveaux besoins :

  • permettre aux auto-hébergés d'avoir du multi-utilisateurs
  • diminuer grandement la consommation de ressources par instance Cozy hébergée pour en réduire le coût
  • améliorer la sécurité globale
  • revoir certains aspects de la plateforme qui ne nous plaisaient pas.

Fidèle à notre attachement pour le Logiciel Libre, le dépôt git dans lequel le développement va se faire est public. Il contient pour le moment surtout un document qui décrit la nouvelle architecture que l'on souhaite mettre en place.

Mais avant de commencer à coder, il nous semble particulièrement important d'avoir l'avis de la communauté. Donnez-nous vos commentaires et impressions. Nous souhaitons savoir ce que nous avons pu manquer, quelles sont les forces et faiblesses que vous voyez dans cette architecture, ce que nous pourrions faire différemment. Alors, à vos claviers !

  • # Améliorer l’installation

    Posté par . Évalué à 10.

    Dans mon cas, et une recherche rapide montre facilement que je suis loin d'être le seul, c’est l’installation qui pose problème. L’image Docker ne veut pas se télécharger ou se construire, ou quand elle veut bien on récupère une erreur 500 (et ça sur une Debian Jessie à jour, ce n’est pas comme si la distribution était exotique), il n’y a pas de dépôt pour les distributions… Donc si je puis me permettre un conseil, c’est considérer ce point comme prioritaire. Avoir un système de validation de l’image Docker vraiment solide et testé sur les principales distributions, proposer des dépôts pour les versions stables des principales distributions. J’aime beaucoup l’idée de Cozy, mais je n’ai pas des heures à consacrer à chercher pourquoi je récupère une erreur XYZ lorsque j’essaie de l’installer.

    • [^] # Re: Améliorer l’installation

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

      Merci pour ces retours.

      Actuellement, pour installer sur une Debian Jessie, le plus simple est de passer par les paquets debian -> https://docs.cozy.io/fr/host/install/install-on-debian.html.

      Pour Cozy et Docker, il y a pas mal d'infos sur https://forum.cozy.io/t/update-on-cozy-and-docker/3009, mais ce n'est pas encore au point pour le moment.

      Et, oui, globalement, il faut que l'on continue à faciliter l'installation.

      • [^] # Re: Améliorer l’installation

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

        Ça n'est pas une installation de Cozy, c'est une installation d'un installateur qui va lui télécharger Cozy sans respecter le système de paquets de la distribution. Une sorte de wget | tar zxf déguisé.
        Pas terrible quoi.

        • [^] # Re: Améliorer l’installation

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

          Effectivement, la version actuelle en nodejs est très difficile à packager proprement pour debian (on a pourtant essayé fort), et on a donc eu recourt à cet artifice : le paquet debian installe un installeur.

          Pour la future version, on va prendre ça en compte et les paquets debian permettront d'installer directement le cozy, sans tricher.

          • [^] # Re:Améliorer l’installation

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

            et pousser cozy dans Debian ?

          • [^] # Re: Améliorer l’installation

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

            Je vous souhaite bien du courage ! Tout dépend du nombre de modules en dépendance, mais chez hupstream nous avons eu déjà quelques demandes clients concernant un tel packaging en nodejs. C'est juste infaisable… Le dépot npm est un tel merdier (pardon du terme), que le packaging est un véritable enfer. Et beaucoup de distros refusent tout net l'intégration des modules, se contentant de la brique de base et d'une dizaine de modules parmi les plus utilisés.

          • [^] # Re: Améliorer l’installation

            Posté par . Évalué à 3.

            Je comprend pas, pourquoi ne pas simplement packager nodejs avec cozy dans son paquet debian ? Pas besoin d'un installateur… et la façon dont npm marche devrait permettre ce genre de fonctionnement je pense !

            • [^] # Re: Améliorer l’installation

              Posté par . Évalué à 2.

              Ça marche mais tu te retrouves à packager plusieurs fois des composants communs, ce qui est contraire à la politique debian. Il y a même des warning lintian pour ça (typiquement, si un package contient jquery).

              Après, c’est mieux que rien (perso, j’ai fait ça pour une appli angularjs).

              Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

            • [^] # Re: Améliorer l’installation

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

              Ça a été essayé, mais ça posait plein de problèmes. C'était avant mon arrivée chez Cozy, dont je ne pourrais pas donner plus de détails.

  • # Mes 2 centimes

    Posté par . Évalué à 10.

    Bonjour Bruno,
    Comme j'ai eu maintes fois l'occasion de le dire ici et sur le forum, je vois les problèmes suivants :
    - Multi-utilisateurs : indispensable dans un contexte familial, asso, etc
    - Fichiers stockés dans CouchDB, donc en cas de crash, plus d'accès aux fichiers (me corriger si je me trompe), c'est juste un NoGO pour moi.

    • [^] # Re: Mes 2 centimes

      Posté par . Évalué à 6.

      • Fichiers stockés dans CouchDB, donc en cas de crash, plus d'accès aux fichiers (me corriger si je me trompe), c'est juste un NoGO pour moi.

      Bof c'est pas vraiment un souci. Je ne connais pas particulièrement couch, mais la DB peut permettre d'avoir plusieurs instance du serveur web qui partagent les fichiers. La problématique pour récupérer/extraire les fichiers sans cozy pourrait être d'avoir un outil spécifique qui permet de lister, extraire/importer tout ou partie des fichiers.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Mes 2 centimes

      Posté par . Évalué à 6.

      Après le document d'architecture montre qu'ils réfléchissent à stocker les fichiers sur le système de fichier.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Mes 2 centimes

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

      Nous avons tenu compte de ces problématiques dans la nouvelle architecture :

      • Il sera possible d'installer Cozy sur un petit serveur local, type RPi, et que plusieurs utilisateurs puissent s'en servir (chacun avec son instance et ses données).

      • Pour le stockage des fichiers, ce sera modulaire. Les auto-hébergés pourront effectivement stocker leurs fichiers sur le file system.

      • [^] # Re: Mes 2 centimes

        Posté par . Évalué à 5.

        Merci, et grosse honte sur moi qui n'avait pas été voir le doc.

    • [^] # Re: Mes 2 centimes

      Posté par . Évalué à 9.

      • Fichiers stockés dans CouchDB, donc en cas de crash, plus d'accès aux fichiers (me corriger si je me trompe), c'est juste un NoGO pour moi.

      Je plussois. Owncloud stocke les fichiers utilisateur en FS. Cela permet de faire des basckups avec des outils conventionnels.
      Pour ma part: un rsync par jour sur une autre machine hors site.

      C'est indispensable.

    • [^] # Re: Mes 2 centimes

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

      J'abonde dans ce sens:
      - gestion de plusieurs utilisateurs,
      - partage de document entre eux ,
      - stockage des données hors de la base de donnée.

      Si c'est dans la feuille de route, c'est parfait. Je trouve Cozy bien plus agréable à utiliser que owncloud et pas plus lent ou gourmand. Dès que l'on a mis en route un serveur de base de données, les ressources sont plombées de toute façon :).

      Par contre, je n'ai pas trouvé très claire le document de la nouvelle architecture, en particulier le dépôt des fichiers directement dans le système de fichier.

      Je trouve aussi curieux de construire une database pour chaque utilisateur, mais je ne suis pas familier de couch-DB.

      Je n'ai eu aucun problème, de mon coté, à installer le système sur une debian de base installée chez un hébergeur connu.

      Un petite chose peut-être, synchroniser deux Cozy, à la demande.
      Dans l'idée de faire une machine de secours, gérer de la redondance, ce qui n'est pas le pied avec owncloud.


      A quand une version FreeBSD ? Pour coller le serveur de données dans une jail avec un gros rctl autour.


      De grâce, continuez de proposer une installation normale, et ne cédez pas à la mode du tout Docker.

      • [^] # Re: Mes 2 centimes

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

        A quand une version FreeBSD ? Pour coller le serveur de données dans une jail avec un gros rctl autour.

        Oui, ça serait sympa. Nous n'avons pas prévu de le faire nous-même mais si des contributeurs veulent faire ça, on peut les aider.

        De grâce, continuez de proposer une installation normale, et ne cédez pas à la mode du tout Docker.

        Oui, on va continuer à proposer une installation sans passer par Docker.

      • [^] # Re: Mes 2 centimes

        Posté par . Évalué à 4. Dernière modification le 01/09/16 à 14:11.

        Dans l'idée de faire une machine de secours, gérer de la redondance, ce qui n'est pas le pied avec owncloud.

        C'est pas vraiment le rôle de la couche cloud de gérer le cluster mais c'est vrai que pouvoir paramétrer ça (raid10, rsync, etc) facilement via WebUI serait un sacré plus (par contre se serait la galère a coder*1 vu que les logiciels de clustering ne sont pas compatible avec toutes les architectures et les versions packagées pour les distro ne sont pas les mêmes (raspbian a par exemple du retard sur Debian pour GlusterFS, se qui force a passer par les backports).

        *1 : note que freenas fait ce genre de chose, du code libre le fait déjà ^ ^

        stockage des données hors de la base de donnée.

        Et pouvoir y accéder via le filesystem d'une autre machine grâce à DavFS voir, SSHFS (le pied), ou autre, se serait intéressant.

        De grâce, continuez de proposer une installation normale, et ne cédez pas à la mode du tout Docker.

        +1

        PS Bruno : ça fait plaisir de voir un projet qui écoute la/les communauté(s) et agis en conséquence ;) Cozy est très prometteur. (franchement j'attends de voir des gens de owncloud prendre la même patience et venir chercher les idées des gens)

        • [^] # Re: Mes 2 centimes

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

          PS Bruno : ça fait plaisir de voir un projet qui écoute la/les communauté(s) et agis en conséquence ;) Cozy est très prometteur. (franchement j'attends de voir des gens de owncloud prendre la même patience et venir chercher les idées des gens)

          Merci. On a la chance d'avoir une communauté constructive, alors on en profite !

  • # Bon courage

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

    Je viens de voir que vous allez carrément réécrire le backend en go plutôt qu'en JS avec Nodejs.
    Au delà de l'avis technique, c'est toujours un gros chantier, alors bon courage …

    Par contre j'ai vu ça dans votre doc :

    The Cozy Stack will have no auto-update mechanism

    Et quand on voit le message précédent à propos de l'installation, je crois qu'il y a erreur sur vos priorités : il faut, à mon avis, que l'installation, la maintenance (et donc la mise à jour) soient le plus simple et le plus robuste possible. Simple étant le mot-clef. Si vous voulez un bon nombre d'utilisateurs, qu'ils restent, et qu'ils soient à jour (en particulier pour des raisons de sécurité), vous devez fournir une manière simple de mise à jour.

    • [^] # Re: Bon courage

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

      Au delà de l'avis technique, c'est toujours un gros chantier, alors bon courage …

      Merci !

      Pour la mise à jour du cozy lui-même, il faut effectivement que ce soit simple. Autant que possible, on souhaite passer par les paquets de la distribution. Sous debian, ce sera le classique apt-get update && apt-get dist-upgrade. Pour les cas où ce ne sera pas possible, on va proposer un script. J'espère que l'on va réussir à faire quelque chose de simple (genre télécharger un tarball, arrêter le cozy, remplacer un répertoire par le contenu du tarball et relancer le cozy). Et on peut imaginer qu'il y ait un bouton dans l'interface web de cozy pour lancer la mise à jour du système ou le script en question.

      • [^] # Re: Bon courage

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

        Je plussoie allègrement cette décision. Ça et le fait de pouvoir utiliser directement le système de fichier comme stockage.

      • [^] # Re: Bon courage

        Posté par . Évalué à 7.

        Une solution sympa pourrait être de faire faire un export des données de l'instance courrante pour l'importer dans le suivant. Ça vous permet :

        • de pousser les utilisateurs à faire une sauvegarde avant la mise à jour
        • d'avoir un processus bien identifié de mise à jour et donc pouvoir y faire tous les traitements voulu
        • à un utilisateur qui a aujourd'hui plusieurs instances pour plusieurs utilisateurs de les fusionner très facilement
        • d'avoir un format de données pivot et donc plus de souplesse dans la forme des données que vous voulais utiliser après coup (passer à un stockage des fichiers dans couch à un stockage sur le système de fichiers)

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Bon courage

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

          C'est effectivement cette solution que l'on envisage pour le passage de la version nodejs à celle en Go. Et pour le format de données, nous souhaitons avoir quelque chose de simple, documenté et qui repose autant que possible sur d'autres formats ouverts et interopérables. Ça permettra de déplacer son instance Cozy pour l'héberger ailleurs et pourra servir de passerelles vers d'autres solutions.

          • [^] # Re: Bon courage

            Posté par . Évalué à 3.

            J'allais justement demander un passage en Go .. c'est vraiment intelligent de votre part de savoir se remettre en question de la sorte.. Cozy pourra vraiment devenir quelque chose d'énorme. Pour la gestion des mises à jour, et de la gestion des différents formats de paquet, l'auteur de ngrok.com propose https://equinox.io , certes il a un cout mais si ca peut faciliter les mises à jour …
            Pour la base, peut être qu'un de ces 2 projets en Go seraient plus adaptés que couchdb : https://goshawkdb.io https://camlistore.org

            J'ai hate de voir ce que cela donne et participer au développement..

  • # Go!

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

    Je note le passage à Go et je trouve ça vraiment cool!
    En tout cas personnellement ça me donne beaucoup plus envie que de développer du backend en js.

    Et l'idée de passer en multi-utilisateur me plait bien :-)

    • [^] # Re: Go!

      Posté par . Évalué à 3.

      Je serais intéressé par plus d’informations à ce sujet. Je connais quelqu’un qui envisage un nouveau développement en node sans pour autant être fixé sur ce point, il serait certainement preneur de retours d’expériences sur les avantages/inconvénients de node et go dans un contexte de production.

      • [^] # Re: Go!

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

        Rien que pour npm ou la gestion de l'asynchrone js (callback ou promises — quelle implémentation d'ailleurs ?) est aujourd'hui assez affreux.
        Quand j'ai besoin de faire du js côté serveur je le fais maintenant au maximum en clojurescript…

        Dernière tranche de lol sur npm :

        • [^] # Re: Go!

          Posté par . Évalué à 1.

          Personnellement, quand je dois faire du JS côté client, je le fait en go avec gopherjs. Faut pas déconner :p
          [/troll]
          En vérité je suis en train de tester pour un jeu que je fais avec des websockets, et gopherjs, et pour le moment, c'est l'amour inconditionnel.

      • [^] # Re: Go!

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

        Avantages pour node :

        • un écosystème globalement plus fourni
        • ça va plus vite pour écrire la première version d'un projet et itérer rapidement
        • la possibilité d'avoir des applications « isomorphiques » (le même code est utilisé côté client et côté serveur).

        Avantages pour go :

        • les performances
        • la concurrence (les goroutines et channels sont une bien meilleure abstraction que les callbacks ou promises)
        • la maintenabilité sur le long-terme
        • plus stable en production.
  • # Re: Donnez votre avis sur la nouvelle architecture de Cozy

    Posté par . Évalué à 10.

    Bonjour,

    Je me pose plusieurs questions :

    1. La réécriture en Go signifie-t-elle que tout le code backend actuel est jeté
      à la poubelle ?

    2. Comment est-ce que seront écrites les applications de Cozy ? Il est fait
      mention d'avoir des helpers JS etc., mais la partie serveur des applications
      sera-t-elle bien en Go ? Ou alors est que le lien avec le core se fera
      uniquement par le biais de l'API REST ?

    3. Est-ce que le départ de Frank (dont l'événement a été oublié d'être mentionné
      en préambule de la dépêche) est lié à ce changement d'architecture ? Est-ce que
      les discussions ont commencé avant, et y a-t-il participé ?

    4. Comment est-ce que vous allez gérer la transition au sein de l'équipe de Cozy
      Cloud ? Est-ce que vous n'allez pas vous retrouver avec trop de développeurs JS
      et pas assez de développeurs Go ? Misez-vous sur leur reconversion ?

    5. Dans les buts fixés, je n'ai pas lu « gagner de l'argent ». La gestion du
      multi-user est une fonctionnalité qui devrait augmenter la valeur de CozyCloud
      pour les entreprises. Néanmoins, j'ai l'impression qu'il n'y a toujours pas de
      vision claire du modèle économique. Est-ce qu'il y a eu des évolutions à ce
      sujet ?

    6. Est-ce pour pouvoir s'intégrer dans un environnement comme celui de la MAIF
      qu'il a été envisagé de réécrire CozyCloud et d'en changer son architecture ?
      Est-ce que vous avez eu des discussions avec des architectes à cravate de chez
      eux à ce sujet ?

    • [^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy

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

      1 La réécriture en Go signifie-t-elle que tout le code backend actuel est jeté à la poubelle ?

      Malheureusement, oui. Ceci dit, la grande majorité de notre code actuel est côté front et va pouvoir être gardé. Et pour le côté back, on a tiré des enseignements de la version actuelle qui vont bien nous aider pour la suite pour éviter de retomber dans les mêmes pièges (notamment, une bien meilleure connaissance de CouchDB).

      2 Comment est-ce que seront écrites les applications de Cozy ?

      Le but est d'avoir un maximum qui ne fonctionnent que côté client. La stack en Go va fournir un grand nombre de services communs aux applications pour ça.

      Bien entendu, pour certaines applications, ça ne va pas être possible. Par exemple, The lounge, un client IRC, ne peut pas tourner côté client car il a besoin de se connecter à un serveur IRC (ce que les navigateurs web ne permettent pas). Dans ce cas, il est effectivement prévu de les faire tourner à côté et de les laisser discuter avec le core via l'API Rest.

      3 Est-ce que le départ de Frank est lié à ce changement d'architecture ?

      Les discussions ont commencé avant le départ de Frank et il a participé à celles-ci.

      Une des raisons qui nous motive à changer d'architecture est le coût d'une instance Cozy. La version actuelle en nodejs est gourmande en RAM et ça coûte donc des sous pour héberger un Cozy (l'achat d'un RPi + électricité qui va avec, ou louer un serveur assez puissant chez un hébergeur, ou les sous de Cozy pour l'offre beta gratuite). On parle de quelques euros par mois (à multiplier par le nombre de personnes pour une famille si chacun veut son cozy). C'est un gros frein pour avoir beaucoup plus d'utilisateurs. Tout le monde est d'accord sur ce point.

      Par contre, la suite à donner l'est moins. Frank défendait une approche où la majorité des personnes ont leur serveur (un RPi chez eux, ou un serveur loué à OVH, Gandi, etc.). Et dans cette approche, il est préférable de juste regrouper cozy-home, cozy-proxy et cozy-datasystem à l'intérieur d'un seul processus et d'optimiser sa consommation mémoire. Les gains sont faibles mais c'est relativement facile à mettre en place (en tout cas, bien plus facile que recoder le backend dans un autre langage).

      À l'inverse, si la majorité des utilisateurs n'ont pas les compétences pour gérer leur serveur, ils vont se tourner vers des offres d'hébergement de cozy tierces. Ça peut-être l'offre beta de Cozy Cloud, bientôt celles de partenaires comme Gandi (avec qui nous avons remporté le Concours d'Innovation Numérique sur cette thématique), et plus tard, potentiellement ce que des grands groupes comme la MAIF pourront offrir à leurs clients. Dans ce cas là, il est possible d'aller beaucoup plus loin dans la réduction de la consommation de ressources (et donc faire baisser le prix d'une instance Cozy) en mutualisant les briques. Au lieu d'avoir un processus par utilisateur, on peut servir plusieurs utilisateurs avec ce même processus.

      Le Concours d'Innovation Numérique a fait pencher la balance pour cette seconde option (et la levée de fonds auprès de la MAIF quelques mois plus tard a renforcé cela).

      4 Comment est-ce que vous allez gérer la transition au sein de l'équipe de Cozy Cloud ?

      Il est prévu que l'on soit 3 développeurs back :

      • un développeur recruté pour l'occasion
      • un développeur nodejs, qui a déjà regardé Go mais n'en a quasiment pas fait, et va donc se reconvertir
      • et moi, qui ait déjà fait du Go par le passé (dont img pour LinuxFr.org).

      Mais nos développeurs JS ne vont pas chômer pour autant. Comme je l'expliquais plus haut, la majorité du code de Cozy est côté front. Actuellement, ils travaillent sur le client emails. Et il y a beaucoup d'autres choses qui les attendent ensuite.

      5 Néanmoins, j'ai l'impression qu'il n'y a toujours pas de vision claire du modèle économique. Est-ce qu'il y a eu des évolutions à ce sujet ?

      On souhaite que ce soient les entreprises qui nous payent, pas les particuliers. Ça peut-être des grands groupes comme EDF qui souhaitent expérimenter autour de Cozy ou qui veulent développer une application pour Cozy (même si tout le monde peut le faire, les grands groupes sont souvent rassurés si c'est nous qui le faisons). On souhaite également renforcer nos partenariats avec des hébergeurs comme Gandi et OVH. Et enfin, si MAIF et d'autres ensuite vont proposer des instances Cozy à leurs clients, nous seront forcément sur le chemin pour les accompagner.

      6 Est-ce pour pouvoir s'intégrer dans un environnement comme celui de la MAIF qu'il a été envisagé de réécrire CozyCloud et d'en changer son architecture ?

      On en revient à la question des coûts. La MAIF a des millions de sociétaires et si elle veut proposer une instance Cozy à chacun d'eux, c'est sûr que quelques euros par instance chaque mois, ça va être trop cher.

      Est-ce que vous avez eu des discussions avec des architectes à cravate de chez eux à ce sujet ?

      Non, il n'y a eu aucune discussion de ce type. Je pense que la MAIF nous fait entièrement confiance pour ça.

      • [^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy

        Posté par . Évalué à 4.

        Ça peut-être l'offre beta de Cozy Cloud, bientôt celles de partenaires comme Gandi (avec qui nous avons remporté le Concours d'Innovation Numérique sur cette thématique), et plus tard, potentiellement ce que des grands groupes comme la MAIF pourront offrir à leurs clients.

        Pour commencer, la MAIF pourrait elle déjà commencer par offrir une crypto décente sur son site avant de se lancer dans l’hébergement d'instances cozy ? J'ai vraiment peur quand leurs concurrents feront de même car la MAIF fait parti des bons élèves parmi les assureurs ( voir très bons )….

        En tout cas, je trouve que Cozy va enfin dans le bon sens: Absurdité de l'instance mono-utilisateur ( surtout avec une telle consommation RAM ) et il à été signalé à plusieurs reprises: " mais où sont mes fichiers au final ? "

        Avec tout ça, on passe du simple jouet au truc véritablement sérieux. Je vous souhaites bon courage pour la suite, car il va y'avoir du boulot !

      • [^] # Commentaire supprimé

        Posté par . Évalué à -9.

        Ce commentaire a été supprimé par l'équipe de modération.

      • [^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy

        Posté par . Évalué à 9.

        Je vais m'éloigner du sujet de la dépêche qui pose l'architecture mais j'aimerais quand même réagir sur votre stratégie.

        Lorsque je lis:

        Par contre, la suite à donner l'est moins. Frank défendait une approche où la majorité des personnes ont leur serveur (un RPi chez eux, ou un serveur loué à OVH, Gandi, etc.). Et dans cette approche, il est préférable de juste regrouper cozy-home, cozy-proxy et cozy-datasystem à l'intérieur d'un seul processus et d'optimiser sa consommation mémoire. Les gains sont faibles mais c'est relativement facile à mettre en place (en tout cas, bien plus facile que recoder le backend dans un autre langage).

        À l'inverse, si la majorité des utilisateurs n'ont pas les compétences pour gérer leur serveur, ils vont se tourner vers des offres d'hébergement de cozy tierces. Ça peut-être l'offre beta de Cozy Cloud, bientôt celles de partenaires comme Gandi (avec qui nous avons remporté le Concours d'Innovation Numérique sur cette thématique), et plus tard, potentiellement ce que des grands groupes comme la MAIF pourront offrir à leurs clients. Dans ce cas là, il est possible d'aller beaucoup plus loin dans la réduction de la consommation de ressources (et donc faire baisser le prix d'une instance Cozy) en mutualisant les briques. Au lieu d'avoir un processus par utilisateur, on peut servir plusieurs utilisateurs avec ce même processus.

        … je m'interroge quelques peu

        Si on s'en tient à cet extrait, votre vision à terme n'est absolument pas l'auto-hébergement.
        Vous souhaitez développer des partenariats et j'en conclus qu'il sera de plus en plus complexe de s'installer une infra pour son propre besoin sans être obligé d'en passer par un prestataire. Et vos choix architecturaux vont dans ce sens.
        Je peux me tromper cependant.
        Je comprend que chacun doive trouver des moyens de subsistance et je ne critique pas vos choix.

        Mais il serait bien de les clarifier. Notamment sur votre page d'accueil on voit "Run your cloud at home"
        Ca ne ma parait pas approprié.

        Encore une fois je comprends votre position mais le minimum est d'être honnête avec vos potentiels "partenaires" (j'entends ceux qui vont rentrer dans l'aventure du LL).

        Quoiqu'il en soit, me concernant je ne participerai pas si cette vision est confirmée.

        D'ailleurs nous n'avons pas eu de nouvelles de Franck qui souhaitait s'exprimer.
        Qu'il sache (s'il traîne par ici) en tout cas que je soutiens sa vision et que s'il souhaite relancer le projet en forkant dans cette direction, il trouvera certainement des soutiens.

        • [^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy

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

          Nous allons continuer à prendre en compte les auto-hébergés (dont je fais parti). Ça ne représente pas la majorité des utilisateurs mais ça reste un public important pour nous, notamment parce qu'ils sont souvent plus avancés techniquement et font plus de contributions.

          La nouvelle architecture doit même rendre plus simple de s'installer un cozy chez soi.

          • [^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy

            Posté par . Évalué à 4.

            Merci pour cette clarification … même si je crains que certains choix de design ne vous conduisent à un moment à négliger l'une des 2 cibles.

            Voici donc quelques suggestions qui pourraient influencer votre architecture. Je ne suis pas assez technique pour être précis mais je comprends que cette nouvelle architecture vous permettra de scaler en multipliant les instances et même si vous vous défendez d'utiliser des microservices, vous n'êtes pas non plus dans une approche monolithique. Vous explorez une voie intermédiaire.

            Il y a 2 aspects qui, me semble t'il, ne doivent pas être négligés:

            Le premier réside en la possibilité de faire du crowdsourcing.
            Je m'explique: Vous évoquez le fait de pouvoir partager un album photo pour la famille et donc de mettre en place des niveaux de permission. Il faut donc qu'ils soient implémentés au niveau de votre API mais je n'ai pas trouvé à quel service ça pouvait correspondre.
            Pour ce cas d'usage, un seul repository sert référence mais imaginez qu'à présent on puisse proposer un service de tags partageables entre tous pour identifier papi et mamie. Imaginez que sur une instance mutualisée chez un hébergeur, sur laquelle on stocke ses bookmarks, on veuille bénéficier de tags auto dont la pertinence est liée au nombre de clients qui ont appliqué ce même tag. Il serait dommage que chaque appli doivent réimplémenter çà au travers de requêtes massives sur l'API de chaque instance utilisateur. Il serait préférable d'offrir ce genre de service de base. Votre architecture le permettra t'elle ?

            L'autre aspect est la fédération. A l'image de XMPP, on pourrait imaginer de mettre en relation plusieurs noeuds cozy afin par exemple de croiser encore plus les données ou autre exemple de partager des items de ma todolist avec d'autres utilisateurs qui ne sont pas hébergés sur le même noeud. Pour vous représenter ceci, vous pouvez vous inspirer d'OSLC qui a spécifié une architecture de bus et un protocole même s'il vise le domaine de l'ALM.

            Enfin 2 petites questions.
            * Il est fait mention du service /realtime. Est-ce que ceci fait référence à une implémentation des Websockets ?
            * pour cozy desktop, vous avez pensé à un framework en particulier ? Electron ?

            • [^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy

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

              Imaginez que sur une instance mutualisée chez un hébergeur, sur laquelle on stocke ses bookmarks, on veuille bénéficier de tags auto dont la pertinence est liée au nombre de clients qui ont appliqué ce même tag. Il serait dommage que chaque appli doivent réimplémenter çà au travers de requêtes massives sur l'API de chaque instance utilisateur. Il serait préférable d'offrir ce genre de service de base. Votre architecture le permettra t'elle ?

              C'est un cas d'usage intéressant, mais je n'ai rien prévu qui aille dans ce sens. À ton avis, que faudrait-il mettre en place pour répondre à ce cas d'usage ? Comment ça pourrait fonctionner ?

              A l'image de XMPP, on pourrait imaginer de mettre en relation plusieurs noeuds cozy afin par exemple de croiser encore plus les données ou autre exemple de partager des items de ma todolist avec d'autres utilisateurs qui ne sont pas hébergés sur le même noeud.

              Ça rentre dans le cadre de ce que nous appelons partage. Il sera possible de partager un calendrier ou une todo-list entre utilisateurs de Cozy, hébergés sur le même nœud ou non.

              Il est fait mention du service /realtime. Est-ce que ceci fait référence à une implémentation des Websockets ?

              Oui, le service realtime vise à permettre à des applications d'être notifiés d'événements via Websockets (et peut-être des fallbacks comme EventSource). Ces événements peuvent provenir de la base de données (un nouveau document par exemple) ou de la stack (une application a fini d'être installée).

              pour cozy desktop, vous avez pensé à un framework en particulier ? Electron ?

              Oui, c'est du Electron. D'ailleurs, on n'a pas fait qu'y penser, c'est déjà disponible pour Linux.

              • [^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy

                Posté par . Évalué à 3.

                C'est un cas d'usage intéressant, mais je n'ai rien prévu qui aille dans ce sens. À ton avis, que faudrait-il mettre en place pour répondre à ce cas d'usage ? Comment ça pourrait fonctionner ?

                Je n'ai pas précisément réfléchi à ça, mais je voulais d'abord attirer votre attention, afin que vous vous preniez ce besoin en compte et j'essayais de le projeter sur votre architecture.

                Toutefois, voici quelques pistes de réflexion
                Il faut d'abord élaborer votre système d'ACL pour en tenir compte au niveau de l'API REST mais peut-être aussi coté backend pour plus d'efficience.
                Vous définissez la notion de contexte (un peu comme les cercles google) ce qui est très bien. Vous prenez en compte la notion de données cryptées. Pensez à la notion de données anonymisées à ces fins de statistiques. Ca va au delà des "metrics" puisque c'est pour un usage "métier".
                Chaque utilisateur pourrait donc décider de l'utilisation de ses données en se basant par exemple sur 4 niveaux
                * privé
                * restreint (géré par les contextes)
                * anonyme (la donnée est accédée en lecture par des traitements mais ne peut pas être associée à l'utilisateur)
                * publique

                Pour l'implémentation, il me semble que des processus transverses du genre de ceux mis en place par les "metrics avec des dbs dédiées(Redis ou CouchDB) pourraient convenir.

                Cependant l'usage est différent puisque ces infos seraient accessibles au niveau des applications hôte. Ceci a donc un impact sur /data

                De la même manière, j'imagine que dans votre architecture actuelle un développeur d'application hôte (sauf cas serverless) doit coder une partie backend s'il doit persister des infos partageables entre points d'accès. Il devrait alors pouvoir accéder à votre système d'autorisations sans passer par l'API REST sinon ça va se ressentir sur les perfs. Il devrait donc pouvoir non seulement interroger votre API bas niveau mais aussi pouvoir collecter des données anonymisées et les persister dans ces bases dédiées. Il devra certainement être en mesure aussi de publier les services associés dans un genre d'annuaire (niveau REST et plus bas)

                Autre point pour la syndication.
                Si j'extrapole votre archi, un système d'annuaire distribué sera mis en place et les échanges passeront par l'API REST.
                Là encore un faudra peut-être prévoir des canaux basés sur des abonnements à des événements au niveau Websocket (par exemple pour calculer les indicateurs sur des données anonymisées en agrégeant plusieurs noeuds.

                Enfin dernier point, prévoir une couche d'abstraction (API bas niveau incluse) permettrait de mieux cloisonner les application hôtes, voire même d'héberger à terme d'autre langages (bon ça aurait été mieux avec du Java pour cause de JVM ;-).

            • [^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy

              Posté par . Évalué à 4.

              […] vous n'êtes pas non plus dans une approche monolithique.

              Tous les diagrammes d'archi du document montrent, ils cherchent à livrer sous forme d'un unique binaire exécutable,… Le fais qu'il y ai les applications n'a rien avoir avec la notion de microservice (sinon firefox serait aussi concerné).

              Pour rappel les microservices consistent à découper un logiciel en une série d'application au couplage faible communiquant entre eux via des API (souvent REST). Normalement chaque microservice est conçu par une équipe différent (d'1 à 3 personnes) et une description (que je trouve claire sur la taille d'un microservice) est : « on peut réécrire un microservice dans un autre langage en 1 ou 2 jours (on a pas à alerté le manager etc) ».

              Du coup ni d'un point de vu organisationnel, ni d'un point de vu technique cela ne s'approche des microservices.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # konnectors et weboob

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

    Actuellement, Cozy utilise à la fois ses propres konnectors et Weboob. Est-il prévu de rationaliser ça ? On peut noter qu'il y a même des modules en doublon.

    • [^] # Re: konnectors et weboob

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

      Oui, c'est embêtant mais il y a beaucoup de boulot des 2 côtés qui seraient long et difficile à porter de l'autre. Donc, pour le moment, on va continuer avec les deux.

  • # Petits retours

    Posté par . Évalué à 7.

    Super démarche ! C'est bien de montrer l'état du travail au plus tôt c'est le moment où vous êtes probablement le plus ouvert aux remarques.

    Pour le moment l'architecture n'est pas encore détaillée, mais j'ai tout de même quelques petites remarques :

    • pour le reverse proxy, il est question de gérer TLS et d'avoir les droits sur les ports 80 et 443. Il serait AMHA intéressant de s'en servir aussi pour fournir les fichiers statiques du client web.
    • dans les stratégies de déploiement vous envisagez du multi datacenter ? Parce que dans ce cas là je ne suis pas certain que redis pour le lock distribué soit une solution pérenne… Il est vraiment nécessaire d'avoir des locks (distribués qui plus est) pour l'installation des applications ?
    • Je ne suis pas un grand connaisseur de couch, vous parlez de créer une db par couple utilisateur/application. Comment se passe le partage d'informations dans ce cas là ? Une recopie ? Est-ce qu'il ne serait pas intéressant d'avoir un système de label ? Chaque document possède un ou plusieurs labels. Les vues sont créé à partir de ses labels et il est possible de partager des document json sans difficulté (mais aussi de visualiser tous les documents partagés sans problème) - c'est une idée en l'air, hein ? -
    • je n'ai pas vu (ou pas compris) le modèle d'exécution des application tierce, notamment pour tout ce qui est gestion des droits

    Une réécriture en changeant de langage c'est courageux ! Mais si vous visez un déploiement possible sur rPi, ça va vous facilité la tâche avec moins de pression sur la gestion des ressources et une crosscompilation simple.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Petits retours

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

      Merci pour ces retours !

      pour le reverse proxy, il est question de gérer TLS et d'avoir les droits sur les ports 80 et 443. Il serait AMHA intéressant de s'en servir aussi pour fournir les fichiers statiques du client web.

      Oui, je pense que l'on va faire ça de manière optionnelle.

      dans les stratégies de déploiement vous envisagez du multi datacenter ?

      Pas dans cette version. On a déjà largement assez de boulot sans ça.

      Il est vraiment nécessaire d'avoir des locks (distribués qui plus est) pour l'installation des applications ?

      Actuellement, la version nodejs a des locks pour ce genre de chose (le risque est plus sur les mises à jour que les installations). Et avec plusieurs serveurs, ça va devenir encore plus compliqué à gérer. Donc, oui, je pense que l'on ne pourra pas se passer de locks.

      Comment se passe le partage d'informations dans ce cas là ? Une recopie ?

      Oui, on s'appuie sur la réplication de CouchDB pour le partage d'informations.

      Est-ce qu'il ne serait pas intéressant d'avoir un système de label ? Chaque document possède un ou plusieurs labels. Les vues sont créé à partir de ses labels et il est possible de partager des document json sans difficulté

      En pratique, cette approche est bien plus compliquée et pose des problèmes, notamment de performances. Ça veut dire que lorsqu'un document est ajouté/modifié/supprimé, il faut mettre à jour toutes les vues de tous les utilisateurs, ce qui est assez gourmand en ressources pour CouchDB.

      On va discuter avec Jan Lehnardt (un des créateurs de CouchDB) la semaine prochaine, notamment pour s'assurer que ce que l'on veut faire est bien dans l'esprit de CouchDB et ne nous posera pas de problèmes de performances/scalabilité plus tard.

      je n'ai pas vu (ou pas compris) le modèle d'exécution des application tierce, notamment pour tout ce qui est gestion des droits

      Oui, ça reste à détailler. Je ne voulais pas retarder plus longtemps la publication du document d'architecture et l'appel à commentaires associés pour avoir des retours avant de commencer à coder. Mais c'est vrai que certaines parties sont encore loin d'être claires (y compris pour moi).

  • # Le chiffrement

    Posté par . Évalué à 5.

    Pour moi un élément majeur de décision, c'est la possibilité de chiffrer toutes les données que je mettrais dans mon cozy. Je sais que c'est encore trop tôt pour demander cela en natif, mais comme lu dans votre doc, c'est à l'étude et suivant votre expérience vous pourrez étendre cela. Je pense que dans une ère post Snowden, ce genre de feature est trivial !

    Bon courage à l'équipe pour la suite !

    • [^] # Re: Le chiffrement

      Posté par . Évalué à 4.

      Je pense que dans une ère post Snowden, ce genre de feature est trivial

      Tu veux dire obligatoire/importante… Car euh trivial à implémenter sûrement pas en tout cas… J'avoue que l'idée d'avoir une base de donnée avec des données cryptées dedans me semble un peu étrange (mais je veux bien voir), je sais qu'il y a des études là dessus, mais ça reste très loin de mise en production (si tu crypte les données, adieu les indexes, les vues, etc…)
      L'auto-hébergement + TLS (et chiffrement des mails) me semble une méthode plus réaliste à l'heure actuelle, et justement envisagée dans ce schéma.

      • [^] # Re: Le chiffrement

        Posté par . Évalué à 4.

        je sais qu'il y a des études là dessus, mais ça reste très loin de mise en production (si tu crypte les données, adieu les indexes, les vues, etc…)

        Le chiffrement homomorphique est discuté dans leur document : https://github.com/cozy/cozy-stack/blob/master/doc/architecture.md#encrypted-data

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Le chiffrement

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

          Oui, nous avons 2 thésards dans l'équipe qui travaillent sur les questions de partage et de calcul distribué. Ils suivent donc de près ce genre de sujets et m'ont confirmé que le chiffrement homomorphique n'est pas faisable actuellement pour cozy (en tout cas, pas si l'on veut des temps de réponse inférieure à la minute quand on fait une requête en base de données).

          De manière générale, dans l'ère post-snowden, il est difficile de se mettre à l'abri. Beaucoup de solutions vantent leur méthodes de discussions chiffrées, mais il est souvent possible de récupérer des meta-données malgré cela. Et il a été montré que les métadonnées sont généralement suffisantes pour une atteinte forte à la vie privée (cf http://mobile.lemonde.fr/pixels/article/2016/05/18/les-metadonnees-telephoniques-revelent-des-informations-tres-privees_4921532_4408996.html).

          • [^] # Re: Le chiffrement

            Posté par . Évalué à 3.

            mailpile stocke ses données, métadonnées et indexs de manière chiffrée (sans aller taper dans le chiffrement homomorphique). Peut-être regarder de ce côté là.

            Vous avez une timeline grossière ?

    • [^] # Re: Le chiffrement

      Posté par (page perso) . Évalué à 3. Dernière modification le 31/08/16 à 15:40.

      Je pense que dans une ère post Snowden, ce genre de feature est trivial !

      Attention à ne pas tout mélanger !
      Snowden a montré que les communications doivent être protégées. Le stockage en lui-même non, en tout cas pas pour des motifs liés à cette affaire.

      Le stockage chiffré est intéressant uniquement pour se protéger d’une divulgation involontaire des données dans la nature (machine perdue, intrusion informatique, saisie judiciaire…).
      Et le chiffrement côté stockage vient avec pas mal d’inconvénients si le chiffrement est fait en haut niveau (contenue de la base de données). Impossible de lancer (en tout cas de manière efficace) une recherche par nom de fichier ou sur le contenu d’un mail par exemple.
      Ou totalement inutile si fait en bas niveau (système de fichiers ou moteur de base de données). En effet dans ce mode de fonctionnement, les données sont accessibles en clair tant que la machine est maintenue allumée.

      Cozy utilise TLS (correctement configuré !) pour le chiffrement des communications, donc adresse le problème de l’affaire Snowden autant que possible (les méta-données restent un problème difficile à résoudre, pour tout le monde).

      Le chiffrement haut niveau du stockage est inutilisable en pratique à l’heure actuelle sans chiffrement homomorphique, ou avec pertes très importantes en terme de performances ou de fonctionnalités.
      On pourrait chiffrer en bas niveau, mais on se prémunirait uniquement d’un cambriolage dans le cas des auto-hébergés et d’une saisie judiciaire côté offre hébergée. Autant dire d’un risque plus que faible voire inexistant. Et dans tous les cas les données seraient accessibles tant que le système resterait en ligne (pas de protection contre une intrusion par exemple).

      Oui, le chiffrement est important. Non, ce n’est pas la solution à tous les maux. :)

      • [^] # Re: Le chiffrement

        Posté par . Évalué à 6.

        est intéressant uniquement pour se protéger d’une divulgation involontaire des données dans la nature (machine perdue, intrusion informatique,

        saisie judiciaire…)

        on, ce n’est pas la solution à tous les maux.

        Je pense qu'en ces temps où l'exécutif tente sans cesse de repousser l'intervention du judiciaire il est bon de pouvoir répondre "je n'ai pas la clé du coffre. C'est pas que je ne veux pas vous la donner, c'est que je ne la possède pas".

      • [^] # Re: Le chiffrement

        Posté par . Évalué à 1. Dernière modification le 02/09/16 à 14:43.

        On pourrait chiffrer en bas niveau, mais on se prémunirait uniquement d’un cambriolage dans le cas des auto-hébergés et d’une saisie judiciaire côté offre hébergée.

        Se protéger aussi d'un disque qui part en garantie (pseudo réparation) ^ ^
        D'ailleurs si vous avez un tuto sur ce sujet, je suis preneur ^ ^

        (note qu'owncloud est censé intégrer un système de crypto, mais il est en beta test et internet déconseille de l'activer en prod)

    • [^] # Re: Le chiffrement

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

      La communications étant déjà chiffrée, je suppose qu'il s'agit de chiffrer le stockage ?

      Si les documents étaient stockés directement dans le système de fichier, il suffit d'utiliser un système de fichier qui permette le chiffrement ?

      • [^] # Re: Le chiffrement

        Posté par . Évalué à 5.

        Si les documents étaient stockés directement dans le système de fichier, il suffit d'utiliser un système de fichier qui permette le chiffrement ?

        Ce n’est pas la même chose.

        Si le chiffrement est au niveau disque, cela veut dire que n’importe qui qui gagne accès au système de fichier monté peut lire toutes les données en clair.

        Si le chiffrement est au niveau fichier, cela veut dire qu’il faut accéder à la clé pour déchiffrer chaque fichier. Cette clé peut très bien ne pas être stockée sur le serveur, auquel cas le déchiffrement peut s’exécuter côté navigateur, ou alors stockée avec une passphrase, auquel cas la clé n’est dispo que dans la ram de la machine (à mon avis, il faut envisager un système hybride, les métadonnées chiffrées avec une clé côté serveur, le contenu avec une clé qui n’est que sur le client).

        De plus, il parait compliqué, avec un chiffrement au niveau FS, de chiffrer avec des clés différentes par utilisateur, alors qu’avec un chiffrement au niveau fichier, c’est très simple.

        Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

  • # Notion de groupe ?

    Posté par . Évalué à 3.

    Hello,

    En premier je trouve la démarche de présenter son architecture courageuse et sympa. Après je pense que c'est important d'écouter tous les conseils, mais de prendre des décisions selon sa vision.

    Je voulais savoir s'il était prévu la notion d'instance de groupe. Ça me semble une notion complémentaire au partage.

    Dans un groupe les personnes peuvent varier dans le temps mais (pour simplifier) l'ensemble des documents est propriété de ce groupe.

    Exemple de groupe : une entreprise, un projet open-source, un groupe de travail, etc…

    Dans un modèle très simple (et proche de la notion de données personnelles) qui appartient au groupe obtient automatiquement les pleins pouvoirs (administrateurs). Ce groupe peut ensuite éventuellement partager des informations avec d'autres personnes (participants), comme le fait une autre instance. Ce qui est important c'est que ces administrateurs sont plusieurs, peuvent changer dans le temps, et s'authentifient de manière transparente avec leur compte habituel.

    Un autre notion de groupe que je ne vois pas apparaître est celle qui concerne les permissions (mais là c'est peut être en dehors des objectifs du document). Pourtant au niveau utilisateur, pouvoir donner accès à son album à toute la famille, dans le cas de l'instance groupe ci-dessus, pouvoir partager un document à tous les participants, etc…

    • [^] # Re: Notion de groupe ?

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

      En premier je trouve la démarche de présenter son architecture courageuse et sympa. Après je pense que c'est important d'écouter tous les conseils, mais de prendre des décisions selon sa vision.

      Oui, ça résume bien ce que l'on essaye de faire. On ne peut évidement pas satisfaire tout le monde, mais des personnes en dehors de l'équipe ont sûrement des idées très pertinentes et il serait dommage de ne pas écouter leurs opinions.

      Dans un groupe les personnes peuvent varier dans le temps mais (pour simplifier) l'ensemble des documents est propriété de ce groupe.
      Exemple de groupe : une entreprise, un projet open-source, un groupe de travail, etc…

      Non, il n'est pas prévu d'avoir de groupes sous cette forme là (une instance cozy partagée par plusieurs utilisateurs). Ça revient à faire un autre projet, avec d'autres préoccupations en termes d'expérience utilisateur, d'applications à mettre à disposition, etc. Et Owncloud/Nextcloud occupe déjà bien ce terrain.

      Un autre notion de groupe que je ne vois pas apparaître est celle qui concerne les permissions (mais là c'est peut être en dehors des objectifs du document). Pourtant au niveau utilisateur, pouvoir donner accès à son album à toute la famille, dans le cas de l'instance groupe ci-dessus, pouvoir partager un document à tous les participants, etc…

      Ça, par contre, avoir des groupes dans le cas du partage nous intéresse beaucoup.

      Le partage dans la version actuelle de Cozy fonctionne avec la réplication entre instance CouchDB + du code pour gérer les droits. On souhaite reprendre le même mécanisme pour la nouvelle architecture. Mais ce n'est pas clair de comment faire ça proprement avec un groupe. On souhaite notamment avoir l'avis d'un expert CouchDB pour nous éclairer sur ce point (on va rencontrer Jan Lehnardt, un des créateurs de CouchDB, la semaine prochaine pour discuter de ça et d'autres points).

  • # Une vie sans jointure

    Posté par . Évalué à 2.

    Ma question est plus sur un retour d'expérience.

    Personnellement ce qui me surprend le plus dans Cozy c'est qu'il n'y ai ni base de donnée relationnelle, ni moteur d'indexation (qui pourrait éventuellement pallier au problème).

    Je n'ai jamais travaillé avec CouchDB, donc je ne mesure pas la capacité à gérer des données (peut être agit-il très bien comme moteur d'indexation, comparable à Elastic Search).

    Est-ce que c'est parce-que le champs applicatif envisagé ne devrait pas nécessiter trop de croisement de données, ou en tout cas porter sur des tailles raisonnables ?

    • [^] # Re: Une vie sans jointure

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

      Effectivement, CouchDB sort des modèles classiques de base de données et il faut souvent un peu de temps avant de comprendre comment l'utiliser. Avec ses vues et requêtes, on arrive généralement à faire ce que l'on veut, mais c'est vrai que dans certains cas, l'absence de croisement de données manque (ça reste rare toutefois). C'est un niveau en-dessous des bases de données relationnelles, mais ça va, on vit avec.

      Pour la recherche full-text, on n'a rien de comparable à ElasticSearch. On a essayé d'indexer les données de CouchDB via des moteurs externes (pas ElasticSearch, car il faut quand même que ça puisse tourner sur machines avec peu de RAM pour les auto-hébergés), mais ça n'a pas été très concluant.

      Par contre, CouchDB a aussi des fonctionnalités très intéressantes (on serait passé à autre chose sinon). En particulier, la réplication est très puissante et on s'en sert beaucoup (pour le partage entre instance cozy, ou la synchronisation des contacts et calendriers entre le cozy et un smartphone).

      Et, en production, c'est du solide. Pouvoir faire des backups à chaud juste en recopiant des fichiers est un gros plus.

      • [^] # Re: Une vie sans jointure

        Posté par . Évalué à 5.

        Effectivement, CouchDB sort des modèles classiques de base de données et il faut souvent un peu de temps avant de comprendre comment l'utiliser.

        C'est un peu le cas de toutes les db non relationnelle.

        En particulier, la réplication est très puissante et on s'en sert beaucoup (pour le partage entre instance cozy, ou la synchronisation des contacts et calendriers entre le cozy et un smartphone).

        Tu en parlais plus haut, j'ai pas compris ce qu'elle avait de particulier dans leur doc. Tu peux en dire plus ?

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Une vie sans jointure

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

          Voici quelques caractéristiques de la réplication de CouchDB :

          • Elle se fait entre 2 bases de données CouchDB (ou autres instances qui parlent le protocole de réplication de CouchDB, pouchdb par exemple), sur le même serveur ou sur 2 serveurs différents.
          • Il n'y a pas de notion de primary/secondary entre ces 2 bases de données. Les 2 bases peuvent évoluer différemment (avec une notion de conflit quand un même document est modifié dans les 2 bases en même temps).
          • La réplication peut se faire dans un seul sens, ou dans les deux sens.
          • La réplication peut porter sur l'intégralité de la base de données, ou juste sur un sous-ensemble. Dans le second cas, on peut utiliser une fonction JavaScript qui va pour chaque document dire s'il doit être repliqué ou non. Par exemple, on peut vouloir répliquer que les documents qui ont le champ public avec une valeur true.
          • La réplication peut se faire en continu (on ouvre une socket entre les 2 bases de données et chaque modification est envoyée au fur et à mesure dans cette socket) ou en mode single-shot (une base de données dit à l'autre que lors de la dernière réplication, elle en était à telle révision et qu'elle aurait besoin des nouvelles modifications).

          Du coup, ça permet de faire des choses assez sympas, comme avoir dans le navigateur une base de données locale, qui peut fonctionner en mode offline et se resynchroniser quand le réseau revient.

          • [^] # Re: Une vie sans jointure

            Posté par . Évalué à 5.

            Du coup, ça permet de faire des choses assez sympas, comme avoir dans le navigateur une base de données locale, qui peut fonctionner en mode offline et se resynchroniser quand le réseau revient.

            Ok merci je vois. Mais il y a quoi comme sécurité pour ne pas totalement exposer sa base au client du coup ? Authentification, gestion de quota ou ce genre de choses ou alors tout est en HTTP et vous vérifiez ça via un reverse proxy ?

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Une vie sans jointure

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

              CouchDB parle en HTTP et a un mécanisme d'authentification (login+password pour se connecter à la base de données). Pour Cozy, les flux vers CouchDB passent par du code à nous pour vérifier l'authentification et les permissions (en mode reverse proxy).

              • [^] # Re: Une vie sans jointure

                Posté par . Évalué à 6.

                Merci pour toutes ces précisions

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Une vie sans jointure

        Posté par . Évalué à 1.

        Pour la recherche full-text, on n'a rien de comparable à ElasticSearch. On a essayé d'indexer les données de CouchDB via des moteurs externes (pas ElasticSearch, car il faut quand même que ça puisse tourner sur machines avec peu de RAM pour les auto-hébergés), mais ça n'a pas été très concluant.

        Suivant le volume, ça peut passer dans Elasticsearch avec peu de RAM. Je stocke 1m de docs facilement sur 1Go de RAM.

        Disclaimer : je bosse pour elastic.

        • [^] # Re: Une vie sans jointure

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

          Elasticsearch avec peu de RAM. Je stocke 1m de docs facilement sur 1Go de RAM.

          Cozy devra revoir son objectif de tourner sur un Raspberry Pi alors… mais sur 4, c’est bon : ce sera 1 pour Cozy et 3 pour l’indexation.

          • [^] # Re: Une vie sans jointure

            Posté par . Évalué à 1.

            Je n'étais pas assez précis mais en fait ça peut utiliser moins que 1Go, hein.
            Je sais qu'un de mes collègues avait fait un cluster de raspberry PI à une lointaine époque (version 0.90 de mémoire).

            Bref, faut tester… :)

        • [^] # Re: Une vie sans jointure

          Posté par . Évalué à 3.

          Solar est plus léger, non ?

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Mécène : qu'est ce qu'ils y gagnent ?

    Posté par . Évalué à 4. Dernière modification le 31/08/16 à 17:44.

    Ce poste n'est pas en rapport avec le fonctionnement de Cozy et je m'en excuse mais voila déjà plusieurs fois où je veux poser la question mais j'oublie …

    Sait on ce qu’elles veulent faire les entreprises avec Cozy ?
    Je m’explique, je ne comprend pas ce qu’elles peuvent gagner à s’impliquer dans Cozy.

    Pour les hébergeurs comme Gandi, le but je pense est de proposer un service CozyCloud comme le GandiMail ou le blog.

    Mais pour par exemple la Macif et EDF ?

    Peut être que le but est d'avoir une application spécifique à Cozy pour « avoir accès à nos données » à travers Cozy, mais :

    • les données seront toujours sur leurs serveurs (donc je ne vois pas l’intérêt)
    • je vois mal madame et monsieur Michu qui ne voient pas le rapport entre « vie privée » et les GAFAM & co et ne savent pas se que veut dire « libre », « opensource » utiliser Cozy et donc l’application Cozy que la Macif et consort leurs propose.

    Je pense qu’il serait bien d’avoir un peut plus d’informations concernant cette interrogation car je ne dois pas être le seul à me poser la cette question.
    Autrement dit, quand je vois ce genre de grande entreprise s’intéresser à Cozy, je me pose la question : par où vont ils nous enfumer …

    PS : linky en opensource et openharware qui transfère ses informations à notre instance Cozy et non pas chez EDF ? J'ai du mal a y croire !

    PPS : j'approuve le coté multi-utilisateurs.

    • [^] # Re: Mécène : qu'est ce qu'ils y gagnent ?

      Posté par . Évalué à 3.

      Je pense qu'ils ont déjà répondu à ce genre de question. Un résumé de ce que j'ai compris / imagine:

      L'idée est un trade-off confiance utilisateur / accès aux données.
      Si EDF mets des infos dans ton cozy c'est que tu es libre d'héberger ton Cozy où tu veux, bien sur (chez toi, chez Cozy, à la MACIF, chez eux).

      Ça peut laisser sceptique mais peut-être que le marché ira vers ça, en fonction des lois, de l'opinion publique qui peut évoluer dans le temps et de pratique de précurseurs. Par exemple si EDF veut te proposer des optimisations de ta consommation ou de ton offre en analysant tes données, ils doivent de toute façon faire une application, il te faut un login etc… en faisant une application cozy, il s'occupent juste de leur métier et en plus peuvent se dégager des obligations sur tes données personnelles puisque c'est toi qui les possède.

      Dans un registre assez proche, la Poste a une solution de coffre fort numérique gratuit: Digipost. Leur modèle économique c'est que les entreprises peuvent l'utiliser pour te pousser des factures où ton bulletin de salaire (ils font alors payer les entreprises, comme quand tu délivre un courrier, voir ici).

      • [^] # Re: Mécène : qu'est ce qu'ils y gagnent ?

        Posté par . Évalué à 1.

        Hum … Je ne suis pas vraiment convaincu du rôle que les entreprises veulent jouer…
        Peut être que avec le temps cela sera plus clair mais je reste septique.

        Merci de m'avoir répondu en tout cas.

  • # Multi-utilisateur et stockage séparé

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

    Bonjour,

    Je suis sûr que cela a été évoqué dans les commentaires plus haut mais ça n'est pas vraiment un sondage si vous n'avez pas tous les avis ! :)

    Actuellement, j'ai un serveur hébergé qui mutualise OwnCloud pour quelques utilisateurs (moins de dix).
    J'adore Cozy (que j'ai essayé) mais il est vrai que la version actuelle ne me permettait pas d'avoir une instance par utilisateur et surtout de séparer leur stockage et leurs données. Dans notre cas, chaque utilisateur a une partition séparée et on arrive à séparer les données Owncloud grâce à des liens symboliques (non officiellement supporté)

    Damien

  • # ETA ?

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

    Toutes ces réflexions sur la nouvelle architecture vont dans le bon sens (vu de loin, même si j'aurais s/go/rust/ mais ça reste de la pinaille), du coup : quand est-ce que ça sort ?

    • [^] # Re: ETA ?

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

      Quand ce sera prêt ;-)

      C'est difficile de donner une date alors que je n'ai pas encore intégré tous les retours au document d'architecture. Probablement d'ici 6 mois à 1 an, selon la vitesse à laquelle on avance et si on parle de sortir une version alpha ou une version finale.

  • # Stop avec le RapberryPI

    Posté par . Évalué à -9.

    C'est une erreur que de vouloir suggerer le Raspberry Pi, fusse t-il le 3, comme hôte d'une solution de stockage de fichiers distribués alors un Cozy…

    Les i/o sont désastreux, le CPU aura du mal si Cozy est utilisé dans tous ses composants.
    J'irais vers un truc au minimum doté de 2GiO de RAM, multi-coeurs, SATA et avec du vrai Gigabit. Ben oui, Cozy tente de devenir le HUB de ma consommation de données, j'éspère avoir du 60-70Mo/s à la maison, ne pas oublier qu'en multi utilisateur, ça réduit vite.

    Certes, on pourrait faire un cluster de rpi mais du coup, ce n'est plus la cible de Cozy et ce n'est pas dit que ça soit rentable.
    Bref, virez le RPi de votre communication.

    Et je dis cible mais qui est la cible au final? Je ne comprend pas où Cozy veut se situer.
    Au vu de ce qu'il offre c'est même encore plus incompréhensible voire de l'amateurisme, ça vise le minimum syndicale quand même pour la partie PIM, la moitié des autres modules est ridicule (hastebin, term, irc!!!!, mstsc!!, map,…).
    Je n'arrive pas à croire l'investissement de 4 millions d'euros, sous-évalué si vous espèrez fournir des outils à l'aune de l'équivalent proprio ou fonctionnel, c'est beau de simplifier la mise en marche mais si c'est pour 2 fonctionnalités…
    Mais bon, il y a tellement d'autres choses nécessitant des euros dans le monde du libre-o-linux centrique que ça me frustre qu'un projet comme Cozy l'emporte. Avec toute l'amitié que j'ai pour vous.

    • Le Webmail: Je veux pas un Roundcube. Je veux l'équivalent de Gmail avec le serveur de mail fourni et GPG.
    • L'appli Note: Je veux pas d'un notepad avec bullets et gras, je veux le petit frère d'Evernote.
    • L'appli Cal/Card: je veux pas un truc à la owncoud, je veux Google Calendar/Contacts… bon son petit frere. :P
    • L'appli Musique: Réellement? Si c'est ma collection privée, elle est dispo localement sur tous mes "devices".

    Et qui dit "cloud" dit bullshit^Wmobilité, je veux que ça marche nickel sur smartphone et pas dans une Webview de 200Mo de RAM.

    Tristan Nitot est vraiment dans l'équipe? Je n'arrive pas à croire qu'il se satisfasse d'une telle communication et d'outils si peu avenant.

    Je vous souhaite tout de même de réussir, je ne vois personne saine d'esprit se réjouir de la faillite d'un LL.

    PS:Non mais IRC? Réellement?!! Hastbin??? Réellement?!! J'ai lu quelque part Weboob, c'est une farce, non?

    • [^] # Re: Stop avec le RapberryPI

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

      Non mais IRC? Réellement?!!

      Tu as une dent contre IRC ?

      * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

      • [^] # Re: Stop avec le RapberryPI

        Posté par . Évalué à 1.

        Tu as une dent contre IRC ?

        Non, je me demande ce que ça fait dans un tel bundle.
        Cozy veut rivaliser avec Google, Dropbox, Evernote, Pocket pour le commun des mortels, non?

        C'est bien ça la cible? Le commun, non?

        • [^] # Re: Stop avec le RapberryPI

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

          Qu'est-ce que tu appelles le "bundle" ?

          Le client IRC ne fait pas parti des applications installées par défaut sur une instance Cozy et n'a pas été développé par Cozy. Ceci dit, en temps qu'application communautaire, je trouve ça intéressant et j'espère que l'on va retrouver d'autres applications dans ce style.

          • [^] # Re: Stop avec le RapberryPI

            Posté par . Évalué à 2.

            Le client IRC ne fait pas parti des applications installées par défaut sur une instance Cozy et n'a pas été développé par Cozy.

            On n'a pas de moyen de le savoir sur cette page https://cozy.io/en/apps/.
            Je propserais que vous fassiez 2 pages différentes, une avec le "core" où ce qui vient réellement de l'équipe Cozy et une autre page nommée 3rd Party/ Contributions ou autres.
            En tant qu'utilisateur, je n'ai pas les même attentes venant de Cozy que de contributions libres sauf si, et je l'encourage, il y a un vrai control qualité pour les modules tiers. Comme ce qu'a décidé de faire Mozilla.

            Il faut encourager la qualité et pas seulement les contributions gratuites.

            • [^] # Re: Stop avec le RapberryPI

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

              Les applications officielles sont déjà présentées sur les autres pages du site. Sur la page en question, on voulait donner un éventail de toutes les applications développées pour Cozy. Pour chacune, il est marqué par qui elle a été développée. Ce n'est pas idéal mais j'ai l'impression que ça reste compréhensible.

              La distinction entre application officielle et communautaire est mieux affichée dans le store. Quand tu choisis d'installer une app sur ton cozy, il est clairement marqué si c'est une app développée par Cozy ou par la communauté. Tu as bien expliqué pourquoi c'est important :

              En tant qu'utilisateur, je n'ai pas les même attentes venant de Cozy que de contributions libres

              Pour ce qui est d'avoir un vrai contrôle de la qualité des contributions externes, on essaye un peu (notamment en aidant les développeurs externes) mais on est loin d'avoir les moyens de Mozilla. Pour le moment, c'est difficile de généraliser ça.

              Il faut encourager la qualité et pas seulement les contributions gratuites.

              On passe du temps avec les contributeurs externes pour les aider à faire leurs premiers pas. Ça leur permet de réussir à se lancer et ça nous permet de combler nos lacunes sur la documentation et de faire passer des bonnes pratiques.

    • [^] # Re: Stop avec le RapberryPI

      Posté par . Évalué à 5.

      L'appli Cal/Card: je veux pas un truc à la owncoud, je veux Google Calendar/Contacts… bon son petit frere. :P

      Tu as quoi contre le truc d’owncloud ?

      En détail, hein.

      Parce que pour le coup, cette solution me convient parfaitement, et je ne vois pas trop ce qui lui manque.

      Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

      • [^] # Re: Stop avec le RapberryPI

        Posté par . Évalué à 1.

        Tu as quoi contre le truc d’owncloud ?

        Toujours cette sacro sainte synchro qui ne marche pas, à moitié ET donc ça ne marche pas.
        Quand j'ai testé Owncloud pour la dernière fois? Il y a 1 an mois pour mois. Et c'était déjà une version qui vantait avoir réglé le problème.

        • [^] # Re: Stop avec le RapberryPI

          Posté par . Évalué à 2.

          Owncloud client ne fait pas de la synchro de calendrier (pour le moment), se sont des autres applications (genre DavDroid , aCalDav).
          Dans mon cas ca fonctionne parfaitement bien sur smartphone android par contre impossible sur tablette android (pas de calendrier intégré par défaut et installer Google Calendar ne règle strictement rien, mon logiciel de caldav ne détecte aucun calendrier).
          Es-tu sur que tes soucis proviennent d'owncloud et non pas de ton calendrier local?

    • [^] # Re: Stop avec le RapberryPI

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

      Je suis certains que l'équipe de Cozy se fera un plaisir d'étudier voir d'intégrer tes contributions ;-)

    • [^] # Re: Stop avec le RapberryPI

      Posté par . Évalué à 2.

      C'est une erreur que de vouloir suggerer le Raspberry Pi, fusse t-il le 3, comme hôte d'une solution de stockage de fichiers distribués alors un Cozy…

      Je le dirais autrement : ne visez pas les Raspberry actuels.

      Autant réutiliser un vieil ordinateur comme serveur, je comprends. Autant réutiliser un vieux Raspberry Pi, c'est très pingre. Si la nouvelle version de Cozy sort dans un an, il est possible que le Raspberry Pi 4 intègre 2 Go de RAM et l'USB 3. Ça serait une configuration minimum plus pertinente et pour le prix, les utilisateurs pourront bien acheter la dernière version du Raspberry s'ils veulent faire tourner Cozy.

      Cette signature est publiée sous licence WTFPL

    • [^] # Re: Stop avec le RapberryPI

      Posté par . Évalué à 4.

      Bref, virez le RPi de votre communication.

      Si ça marche sur raspberry pi, alors ça fonctionne sur les ordinosaures, sur les Banana Pi et les ODROID-XU4. En plus c'est pratique de pouvoir faire ses test sur raspberry pi, ça va plus vite que de monter une VM :P

      PS: on peut mettre du Gigabit sur RPI (un benchmark ici)

      C'est une erreur que de vouloir suggerer le Raspberry Pi, fusse t-il le 3, comme hôte d'une solution de stockage de fichiers distribués

      Mon RAID10 est en désaccord avec toi, il fonctionne bien :P (RPI2 + ordinosaure)

      L'appli Musique: Réellement? Si c'est ma collection privée, elle est dispo localement sur tous mes "devices".

      Utilises syncthing et non un système cloud alors. Moi c'est l'opposé: musique centralisée sur owncloud avec lecture via DavFS*1 ou SSHFS et sur mobile je garde le stricte minimum pour quand hors réseau.

      *1 note: à travers Tor ça lag ça race

    • [^] # Re: Stop avec le RapberryPI

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

      Je sens une grande frustration dans ton commentaire, mais j'ai du mal à pointer précisément vers quoi elle est tournée.

      Pour la configuration minimum, ça reste une configuration minimum. Si tu veux effectivement avoir un Cozy rapide tout en ayant un usage poussé, il vaut mieux prendre une machine plus puissante.

      la moitié des autres modules est ridicule (hastebin, term, irc!!!!, mstsc!!, map,…)

      Ce sont des applications communautaires, développées par des gens externes à Cozy. Je trouve ça très positif que d'autres personnes contribuent ce qu'ils ont envie de voir dans Cozy.

      Le Webmail: Je veux pas un Roundcube. Je veux l'équivalent de Gmail avec le serveur de mail fourni et GPG.

      Même si on utilisait les 4 millions d'euros juste sur ça, on n'arriverait pas à faire ça. Le but est de faire un webmail avec lequel les gens sont à l'aise, mais qui bénéficie de l'intégration avec les autres applications Cozy.

      L'appli Note: Je veux pas d'un notepad avec bullets et gras, je veux le petit frère d'Evernote.

      Est-ce que certaines fonctionnalités en particulier te semblent importantes ?

      L'appli Cal/Card: je veux pas un truc à la owncoud, je veux Google Calendar/Contacts… bon son petit frere. :P

      Qu'est-ce qui te manque dans la version actuelle de Cozy ? La partie calendrier a des lacunes, mais contacts tient déjà bien la route.

      L'appli Musique: Réellement? Si c'est ma collection privée, elle est dispo localement sur tous mes "devices".

      Oui, dans ce cas, elle n'a pas beaucoup d'utilité pour toi. Mais je connais d'autres personnes qui s'en servent et en sont très contentes.

      Tristan Nitot est vraiment dans l'équipe?

      Oui, et il sera présent au meetup ce soir.

      • [^] # Re: Stop avec le RapberryPI

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

        Même si on utilisait les 4 millions d'euros juste sur ça, on n'arriverait pas à faire ça. Le but est de faire un webmail avec lequel les gens sont à l'aise, mais qui bénéficie de l'intégration avec les autres applications Cozy.

        Justement vous serez toujours en retard, meme face à des produits comme Horde, Zimbra ou RoundCube. Pourquoi ne pas faciliter l'integration d'applications existantes plutot que de reinventer la roue ?

        Pareil pour la musique, ce n'est pas une critique de vos talents mais à mon avis il vous faudra des années pour arriver au niveau de MPD, alors que ça semble simple de faire seulement un client.

        • [^] # Re: Stop avec le RapberryPI

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

          Des solutions "Cloud" qui intègrent d'autres produits, ça existe. On peut parler de yunohost ou sandstorm. Mais elles n'offrent pas une expérience utilisateur cohérente et de pouvoir réutiliser des données entre applications. Pour moi, les forces de Cozy se trouvent justement là. Et, oui, ça demande souvent de réinventer la roue en moins abouti. Chaque application prise individuellement est moins bonne que la concurrence, mais c'est l'expérience globale qui compte.

          Pour le lecteur de musique, on ne va pas remplacer les autres lecteurs. Mais il offre d'autres usages intéressants : tu peux vouloir faire écouter un morceau de musique quand tu es chez des amis, ou tu peux t'en servir pour écouter des podcasts que l'application konnectors aura récupéré automatiquement pour toi.

          Cozy, comme toute plateforme, a besoin d'un écosystème assez riche pour montrer de quoi elle est capable. Mais je suis convaincu de son potentiel.

    • [^] # Re: Stop avec le RapberryPI

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

      Autant sur le reste des critiques, je ne les partage pas, mais effectivement, le RaspberryPI me semble fort limité pour quelque chose comme Cozy. On a pas besoin de port HDMI !

      Par contre, on a effectivement besoin d'IO descentes, de gigabit ethernet et de SATA (voire multiple SATA pour faire du RAID).

      D'une manière générale, je regrette que tout se fasse a base de Raspberry. Il manque une alternative orientées stockage de données (pour Cozy par exemple) et une autre alternative orientée réseau pour faire son routeur maison (gigabit ethernet, switch ethernet intégré, pas besoin de SATA ni HDMI).

      Vous connaissez des alternatives spécialisées dans ce genre ressemblant dans l'esprit au Raspberry ?

      • [^] # Re: Stop avec le RapberryPI

        Posté par . Évalué à 2.

        D'une manière générale, je regrette que tout se fasse a base de Raspberry.

        Le raspberry pi est le plus connu des mini pc, normal qu'il serve de base pour le marketing (si ça tourne sur lui, on part du principe, à tort ou à raison, que ça fonctionne sur les très très très nombreuses alternatives).

        Il manque une alternative orientées stockage de données

        Tu as une prise Sata sur les Banana Pi, les orange pi, les HummingBoard Pro, la LeMaker Cello, le BeagleBoard X15, le OLinuXino A20 et j'en passe beaucoup d'autres (je pense qu'une journée ne suffirait pas pour lister toutes les alternatives).

        Il y a aussi une floppée d'adaptateur USB-Sata et des cartes d'extension comme la X300 ou celle de HardKernel

        Sans compter que l'on peut directement brancher des HDD/SSD via USB (une partie de mon raid10 est basé sur ça, avant qu'on viennent encore dire qu'USB c'est juste de la merde…)

        faire son routeur maison (gigabit ethernet, switch ethernet intégré, pas besoin de SATA ni HDMI)

        Il y a le BP-R1 (sur Youtube) de chez BananaPi. Je ne sais pas a quel stade d'avancement ils sont ni si la technologie s'est stabilisée.
        Si non j'ai déjà vu des gens faire un MITM matériel avec un raspberry pi + connecteur USB-RJ45, on doit pouvoir ré-utiliser le principe pour monter un routeur.

  • # Cahier des charges

    Posté par . Évalué à 4. Dernière modification le 01/09/16 à 13:56.

    La proposition de nouvelle architecture est très intéressante mais elle saute l'étape du cahier des charges et décrit déjà une partie de l'implémentation.

    Les buts mériteraient d'être regroupés dans un document séparé détaillant le but du projet, ses valeurs, les utilisateurs ciblés, les exigences minimum (matériel et OS, clients et serveurs, en test et production) et la stratégie de développement (contributeurs ciblés - individus ou entreprise => choix de la licence avec ou sans clause sur les brevets, CLA ou non - cf. problème qu'a rencontré VLC pour le relicensing -, critères pour le choix du langage de programmation, etc.). En gros, les choix techniques faits dans la proposition devraient répondre à une exigence dans le cahier des charges.

    Le document décrivant l'architecture peut ensuite être complété avec les raisons pour lesquels le choix a été fait. Par exemple, pour le choix du langage de programmation, on voit dans le lien que Python et PHP sont plus populaires que Go. Le choix ne semble pas venir des compétences de l'équipe puisque sur les trois développeurs Go, un connais bien, un connais un peu et un est à recruter. Il serait intéressant de détailler. Est-ce parce que la réputation de Go monte et que c'est une solution d'avenir ? Est-ce pour cibler les développeurs Go puisqu'il n'y a pas de Cloud libre auxquels ils pourraient contribuer, contrairement aux développeurs PHP pour lesquels il existe plusieurs Clouds libres, mais pas en Python à ma connaissance.

    Au premier abord, ça semble fastidieux d'écrire ce genre de documents (le pourquoi) mais ça permet de mettre en évidence beaucoup plus vite les lacunes de certains choix (mince, on a prévu d'avoir une interface CardDAV, il n'y a pas de bibliothèque Go qui fait ça, on va devoir l'écrire et c'est assez compliqué comme protocole… note : je n'ai aucune idée de si ça existe ou pas en Go, c'est juste pour l'exemple).

    Cette signature est publiée sous licence WTFPL

    • [^] # Re: Cahier des charges

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

      Oui, ça aurait été bien d'avoir un tel document. Malheureusement, ça prend beaucoup de temps d'écrire ce genre de document, de communiquer dessus, écouter les retours, etc. Pour le cahier des charges, une grande partie est de l'existant que l'équipe connaît et ne prend donc pas le temps de documenter. Pour l'architecture, comme je propose quelque chose de nouveau, c'est une bonne occasion pour faire ce travail.

  • # échange de code

    Posté par . Évalué à 1.

    Je me posais une question: y a-t-il de l'échange de code (et de bon procédé) entre Cozy, Owncloud, Seafile, et autres logiciels libre ?

    • [^] # Re: échange de code

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

      Échange de code entre les solutions libres de cloud, pas à ma connaissance. Il faut dire que ce ne sont pas les mêmes langages et technologies qui sont utilisées. Par contre, chacun utilise des bibliothèques libres développées ailleurs et en produit également. Il y a également des discussions entre Cozy Cloud, Owncloud et d'autres pour essayer d'avancer sur un standard pour partager des données entre ces solutions (exemple : un utilisateur d'owncloud pourrait vouloir partager un calendrier avec un autre utilisateur qui serait sur cozy).

  • # Et les valeurs du logiciel libre ?

    Posté par . Évalué à 1.

    En allant voir les sources, on peut constater une large utilisation de licences de logiciel libre (GNU AGPL, GNU LGPL, MIT…).

    Sachant que seuls des logiciels libres garantissent éthiquement la liberté/sécurité/indépendance/inter-opérabilité pour les utilisateurs :

    1. À quand l'abandon de GitHub qui n'est pas un logiciel libre ?
    2. Sur le site web de Cozy, où est la page valorisant l'adhésion de Cozy aux valeurs du logiciel libre ?
    • [^] # Re: Et les valeurs du logiciel libre ?

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

      1. À quand l'abandon de GitHub qui n'est pas un logiciel libre ?

      Sans avancer de date, je peux dire que l'on regarde ce que fait gitlab.

      2 Sur le site web de Cozy, où est la page valorisant l'adhésion de Cozy aux valeurs du logiciel libre ?

      Il n'y a pas de page qui liste les valeurs de Cozy, ça apparaît sur plusieurs pages. Le premier des 5 mots cléfs pour décrire Cozy sur la page presse dit :

      Ouverture : Cozy est disponible sous license open source et ses utilisateurs sont encouragés à modifier la plateforme et créer autout d'elle. Les développeurs peuvent étendre les fonctionnalités de Cozy en créant des applications et des connecteurs.

  • # Mal à l'aise

    Posté par (page perso) . Évalué à 10. Dernière modification le 02/09/16 à 00:01.

    Cher Nono<,

    Je t'écris parce que cela fait deux fois que je suis mal à l'aise vis-à-vis de tes interventions sur ce site. Je m'explique.

    La première fois a été sur Cozy cloud, maif et licenciement du CTO???. Sur ce journal, j'ai lu plusieurs de tes posts en toute innocence, te connaissant principalement pour ton implication dans linuxfr. Et puis quelques jours plus tard (Je ne me rappelle plus vraiment du temps), je me suis rendu compte que tu étais « partie prenante » travaillant pour cozy. Cela m'a mis très mal à l'aise : je ne sais plus quand tu parles en ton nom propre, pour ton employeur ou encore au nom de linuxfr. Sur le moment, j'ai laissé couler.

    Aujourd'hui, je suis de nouveau mal à l'aise. Premièrement parce que la première phrase « Cozy est un cloud personnel que nous suivons et évoquons régulièrement sur LinuxFr.org » me donne l'impression que tu parles au nom de linuxfr. Deuxièmement, parce que la suivante omet que récemment cozy a fait parler de lui pour un limogeage d'une personne et me donne la forte impression que tu fais de la communication pour ton employeur. Le paragraphe suivant emploie le « nous » qui sous-entend que tu parles au nom de ton employeur à partir de là.

    Ne serait-il pas opportun de mentionner si tu parles en ton nom propre, pour ton employeur ou encore au nom de linuxfr ?

    Bien à toi,
    Alenvers.

    • [^] # Re: Mal à l'aise

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

      Salut,

      je peux comprendre ce sentiment de malaise. Mais je suis loin d'être la seule personne sur LinuxFr.org à parler de sujets qui lui tiennent à cœur et pour lesquels elle peut être impliquée avec différentes casquettes. D'ailleurs, c'est un des points que j'apprécie ici : on sent l'implication des personnes qui contribuent au site, c'est tout sauf des copier-coller de communiqués de presse insipides. Bien sûr, cela veut aussi dire qu'il faut accepter de lire le site en prenant un certain recul.

      Ne serait-il pas opportun de mentionner si tu parles en ton nom propre, pour ton employeur ou encore au nom de linuxfr ?

      Je parle en mon nom propre sur ce site. La seule exception est les dépêches qui concernent LinuxFr.org où je parle en temps que LinuxFr.org, mais vu que je suis très peu actif ces derniers temps, je pense que l'on peut ignorer ça.

      Cozy Cloud, en tant qu'employeur, n'a jamais fait de remarques[*] sur ce que j'écris sur LinuxFr.org. Mes collègues sont contents que je le fasse, mais de la même façon que je suis content quand ils parlent de Cozy Cloud lors de conférences ou prennent sur leur temps libre pour aider des utilisateurs qui ont des problèmes. C'est quelque chose que l'on fait parce que l'on croit dans le projet, en aucun cas par obligation.

      [*] Pour être honnête, ce n'est pas tout à fait vrai. Une fois, Frank m'a fait une remarque pour un des commentaires sur LinuxFr.org à propos d'un article sur Next Inpact sur la levée de fonds auprès de la MAIF, mais ça reste totalement anecdotique et je ne l'ai pas ressenti comme une atteinte à ma liberté de parole.

      Aujourd'hui, je suis de nouveau mal à l'aise. Premièrement parce que la première phrase « Cozy est un cloud personnel que nous suivons et évoquons régulièrement sur LinuxFr.org » me donne l'impression que tu parles au nom de linuxfr. Deuxièmement, parce que la suivante omet que récemment cozy a fait parler de lui pour un limogeage d'une personne et me donne la forte impression que tu fais de la communication pour ton employeur. Le paragraphe suivant emploie le « nous » qui sous-entend que tu parles au nom de ton employeur à partir de là.

      J'ai piqué l'introduction de la dernière dépêche sur LinuxFr.org qui parlait de Cozy Cloud (celle sur la levée de fonds auprès de la MAIF). Merci Floxy, qui l'a rédigée. Le nous du second paragraphe reprend l'équipe Cozy Cloud de la dernière phrase du premier paragraphe : « Aujourd'hui, l'équipe Cozy Cloud fait appel à vous. »

      J'aurais sûrement pu/du reformuler ça pour que ce soit plus clair, mais je pense que le message a été compris.

    • [^] # Re: Mal à l'aise

      Posté par . Évalué à 3.

      Dans sa première dépêche à propos de Cozy, Bruno à bien mentionné qu'il avait été embauché par CozyCloud. Même sans avoir lu les autres dépêches citées, ça paraît clair qu'il parle au nom de l'équipe CozyCloud et qu'il s'agit d'une entreprise commerciale (recrutement, levée de fonds - le lien est cassé d'ailleurs).

      Ce qui semble te gêner, c'est plus la promotion qui peut être faite pour une entreprise commerciale que l'affiliation de Bruno avec cette entreprise, affiliation qu'il ne cache absolument pas.

      Personnellement, je suis très content de pouvoir lire une dépêche concernant une entreprise française qui développe un logiciel libre qui m'intéresse pour un usage personnel. Les commentaires sont très pertinents comme à chaque dépêche sur l'auto-hébergement. Je ne semble donc pas le seul à suivre le sujet de près. Et ça fait plaisir de voir que libre et commercial peuvent aller de pair.

      Disclaimer: je ne travaille pas pour CozyCloud. Je n'ai jamais utilisé ni même testé Cozy. Sur mon serveur perso, j'utilise OpenMediaVault et un peu de config maison.

      Cette signature est publiée sous licence WTFPL

  • # Cozy et Social Web − interopérabilité ?

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

    Étant donné que Cozy est une application web qui dispose de très nombreuses facettes, il pourrait être intéressant pour vous de jeter un coup d'œil aux travaux du Social Working Group du W3C.

    TL;DR : Y'a probablement des technos à emprunter au W3C pour vous faciliter la vie ET permettre l’interopérabilité avec le Social Web naissant.

    Le Social WG planche sur différents standards (interopérables) concernant le partage et la publication de données.

    Les deux formats qui en ressortent sont microformats2 (markup HTML) et ActivityStreams 2.0 (JSON). Typiquement, AS2 est fait pour construire des API/applications et mf2 pour pouvoir intégrer de la sémantique directement dans une page web générée.

    Rien n'empêche par ailleurs d'utiliser les deux à la fois.

    Par-dessus cela s'ajoute de la fédération. Pour l'instant, cela est assuré de façon assez basique (pas de gestion des contacts, du spam) par Webmention (malgré un WIP sur la question), mais un nouveau protocole de fédération est en train d'émerger : ActivityPub.

    ActivityPub n'est pour le moment qu'un working draft, mais par sa gestion apportée des contacts, des streams (chaque utilisateurice a ses propres flux de données) et de 1001 autres choses en font une candidature sérieuse pour dessiner des plateformes modernes et interopérables.

    À noter aussi l'émergence de Indieauth pour une gestion décentralisée de l'authentification (super pour partager des documents d'une instance à l'autre, par exemple), et de Micropub comme API de publication standard (usage multiples, mais typiquement orienté blogging).

    • [^] # Re: Cozy et Social Web − interopérabilité ?

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

      Merci pour tous ces liens. J'en connaissais quelques uns mais pas tous. Je vais regarder les autres dès que j'aurais un peu de temps. J'ai également transmis ça à d'autres personnes dans l'équipe que ça peut intéresser.

      • [^] # Re: Cozy et Social Web − interopérabilité ?

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

        Pour faire court, le couple ActivityPub/ActivityStreams fait un très bon protocole de fédération (avec des trucs cool comme les personal streams, dont le vocabulaire est extensible si besoin, le tout basé sur du JSON (donc assez interopérable).

        Par-dessus cela, les vues HTML du contenu devraient comporter des microformats2 (et parler webmention) pour permettre aux gens d'intéragir directement avec le contenu public ailleurs sur le web (repartager, liker).

        Après, il y a aussi Linked Data Platform sur lequel bosse Tim Berners Lee (sur la plateforme Solid), mais les travaux en terme d'intéractions sociales et de partage de contenu sont moins avancés là-bas, même si l'aspect stockage de contenu (linked data à proprement parler) est très abouti.

        Bonne lecture, et n'hésitez pas à venir faire un tour sur la communauté IndieWeb si vous avez des interrogations. La documentation y est parfois un peu brouillon (surtout en français), mais le wiki est public : il suffit d'une page personnelle avec des liens <a rel="me"> vers des services d'authentification pour pouvoir se connecter (IndieAuth).

        Du coup, tous ces standards et projets, bien que déjà employés en production, sont des Work In Progress permanents qui ne demandent qu'à être améliorés avec des retours d'expérience concrets. En gros, travailler avec ces projets vous donnera une base solide sur laquelle vous baser, tout en vous donnant l'occasion d'améliorer les spécifications eu égard à vos besoins, ce qui en retour pourra éviter à d'autres projets type "cloud personnel" de réinventer la roue, faisant au final plus d'interopérabilité entre tout le monde.

Suivre le flux des commentaires

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