Appel à commentaires pour la future architecture de Cozy


#1

Bonjour,

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.

Pour cela, nous allons nous lancer dans un grand chantier et une première étape a été d’écrire un document d’architecture pour expliquer ce que nous voulons faire. Ce document d’architecture est disponible ici : https://github.com/cozy/cozy-stack/blob/master/docs/architecture.md

Avant de passer au développement, il nous semble particulièrement important de discuter avec notre communauté des choix faits dans ce document. Vos retours nous seront très précieux pour pointer du doigt nos oublis, nous proposer des alternatives et mieux prioriser les différents développements à réaliser.


L’équipe Cozy Cloud


[fr] À propos des serveurs gratuits de test
[FR][Infolettre] Cozy Cloud recrute ! Nouvelle architecture et actualité du forum
#2

J’ai un grand espoir pour cette réécriture même si le cozy d’aujourd’hui me satisfait ‘presque’ pleinement.

Personnellement, ci qu’il me manque c’est la possibilité de modifier les chemins de stockage des app et data, le manque d’accès simple aux changelog en cas de maj.

Après, et j’avoue ne pas avoir tout lu, mais est ce que les url représentent des applications installées d’office ou juste des exemples ?

Est ce que dans un environnement multi d’utilisateurs, les applications feront parties du coeur de cozy (et donc disponible à tout les utilisateurs) ou uniquement disponible dans l’environnement d’un utilisateur (et laisser chaque utilisateurs le choix d’installer ou utiliser les apps de son choix).

Par contre, bien dommage que cette appel ne soit pas à l’ordre du jour du meetup.


#3

Hello @amaymon,

C’est déjà partiellement possible. Les applications peuvent stocker des données à deux endroits :


#4

Bonjour @amaymon,

merci pour ces retours.

C’est la liste des applications installées par défaut (mais ça peut encore bouger).

Chaque utilisateur pourra installer les applications de son choix.


#5

Bonjour, merci de cette consultation !

Question sécurité, la question du multi utilisateur me semble poser un problème (que vous aviez certainement discuté lors de la conception initiale) : cela permet de contraindre quelqu’un de votre entourage à utiliser une machine que vous administrez, et donc de gérer sa vie privée, ce qui pose des problèmes de nature sociale (penser aux cas de l’adolescent qui souhaite avoir un jardin privé, au conjoint qui divorce…).

Ça m’incite à suggérer des fonctionalités d’évasion faciles à utiliser : «récupérer/envoyer une archive chiffrée de mes données» (qu’on pourra réimplanter dans un cozy perso et «effacer toutes mes données en raclant bien les octets sur le disque».

\o_

Feth


#6

Bonjour,

bravo pour cette architecture qui semble vraiment bien pensé. Le document est assez complet mais j’ai trois points que j’aimerai discuter avec vous :

  • le choix du Golang
  • le multi-utilisateurs (système d’ACL)
  • les événements Temps Réels

Le choix du Golang

J’ai bien compris vos différents arguments concernant le choix du langage golang pour la stack (simplicité, orienté productivité,les perfs sont au rendez-vous, une bonne gestion de la concurrence en terme de process et d’accès au données). Mais aujourd’hui, on trouve quand même des choses très bien et très complet en PHP. Je pense à Laravel 5 https://laravel.com/. Et franchement, c’est vraiment simple d’utilisation, implémentation de façon modulaire, vraiment performant et encore plus avec PHP7, un très très grosse communauté, le support “nativement” de OAuth2|notification Temps réel, … Aussi pour le développement d’app, installation via composer, tarball, … tout est possible. Après pour le dev d’app tierce, je pense qu’il faudrait un SDK dans quasi tout les langages pour ne pas laisser quelqu’un de côté.

Après c’est un choix comme un autre mais Laravel permet de gérer les ACL très facilement -> transition vers la deuxième partie ^^

Le multi-utilisateurs (système d’ACL)

Les ACL (https://fr.wikipedia.org/wiki/Access_Control_List) sont la solution la plus simple pour gérer des permissions multi-utilisateurs. Après j’ai pas assez de recule sur la complexité globale du système (permissions des fichiers, …) pour vraiment vous proposer une solution pertinente mais je sais que Laravel a un système d’ACL qui est vraiment bien foutu (voir on peut trouver des composants à récupérer via composer).

Les événements Temps-Réels

J’ai bien compris que vous aller mettre en place des événements Temps-Réels et que le client pourrait subscribe à ces events via l’API et le endpoint /real-time mais j’ai un peu du mal à bien cerner comment ces events vont être consommer/produit par le client. Est-ce que c’est des events générés par CouchDb ou vous dev un eventGenerator ? Via quel canal (Websocket) ? Voilà, j’aimerai vraiment bien comprendre cette partie là que j’ai du mal à cerner.

Merci d’avance pour vos réponses et super boulot/initiative OpenSource !!!

Cordialement,


#7

Bonjour @feth,

Oui, j’en parle dans la section Import and export. Il est important que l’utilisateur ait les moyens de déménager ses données ailleurs (dans un nouveau Cozy de préférence, mais le format sera documenté pour que ça puisse aussi servir de passerelle vers d’autres solutions).


#8

Bonjour @Nightbr,

merci pour ces retours.

Pour le choix du langage, PHP et Laravel sont sûrement très bien, mais ils ne correspondent pas à nos besoins. Pour les performances, ça reste bien en dessous de ce que propose un langage compilé comme Go (aussi bien pour le CPU que la consommation mémoire). De plus, Cozy sort du cadre d’une application web classique. La stack manipule beaucoup de fichiers, transfère des requêtes HTTP et a un réel besoin de gérer proprement la concurrence. Go est plus adapté pour ces cas d’usage à PHP.

Pour les événements temps-réel, il faut effectivement que l’on approfondisse cette partie. Il y aura des WebSockets disponibles, mais je ne sais pas encore si on va également prévoir des solutions de repli pour les navigateurs / environnements qui ne les prennent pas en charge (EventSource par exemple).

D’un point de vue utilisateur, une application JS pourra utiliser cet endpoint pour demander à recevoir tous les changements qui concernent des contacts par exemple. Quand un contact sera ajouté, modifié ou supprimé, un message sera envoyé de la stack vers l’app JS avec le changement en question, ce qui permettra de mettre à jour l’interface.


#9

Oui oui !

Toujours sur la meme préoccupation, serait-il possible d’avoir un chiffrement coté client pour certaines données (certaines images, certains textes, à la manière de ce que fait 0bin).


#10

La question est de savoir où stocker la clé de chiffrement/déchiffrement. Les API proposées par le DOM (localStorage, indexedDB, les cookies) ont tous un modèle de sécurité par origine. Or, toutes les applications d’un Cozy tournent sur le même domaine, et ont ainsi la même origine. Ça veut dire que n’importe quelle autre app Cozy pourrait aussi accéder à la clé.


#11

Je proposerais bien… de ne pas la stocker.
Dans 0bin elle n’est pas vue par le serveur : l’url est de la forme http://fqdn/path#key


#12

Ha oui, on peut effectivement la mettre dans l’URL et laisser l’utilisateur la stocker où il veut. Du coup, c’est déjà faisable dans Cozy aujourd’hui et ça restera le cas. Ça a même l’air assez découplé de Cozy. Est-ce que tu vois des choses que Cozy pourrait faire pour encourager/aider cette utilisation ?


#13

Je ne suis pas ergonome, et je pense que c’est plutot une question pour ergonome :smile:
En tout cas je verrais bien un chiffrement par défaut de la synchro depuis téléphone mobile (avec stockage de la clef sur le téléphone, du coup … c’est un souci).


#14

Pour la clé de chiffrement, regarder du coté de mega (https://mega.nz/). Il propose de télécharger la clé mais faudrait essayer de voir comment il gère ce point critique. Mais dans tous les cas, ça se fait.


#15

Merci pour cette réponse ! En effet, je connais pas trop GO, mais ça semble être bien adapté à votre besoin. Je vais suivre de prêt l’évolution du projet et cette partie Temps-Réel !

Bon courage et bonne continuation :wink:


#16

Le souci principal d’un chiffrement comme j’en parle, c’est qu’on doit dire adieu à quasiment tout traitement coté serveur, par exemple vignettage des images -si l’utilisateur veut ces fonctionalités, il faudrait soit que son terminal réalise les traitements et que le serveur stocke les données calculées, soit que l’utilisateur envoie (volontairement) une version non chiffrée de données qu’il estime moins sensibles.
Après, il y a peut-etre des cas où ça n’a aucun impact négatif que les données soient chiffrées (carnet d’adresses).


#17

Bonsoir @nono et al.

Je suis loin d’avoir les compétences requises pour donner mon avis sur les choix techniques exposés, mais, a contrario probablement d’une majorité d’utilisateurs, j’avoue être un peu déçu de l’aspect multi-utilisateurs vers lequel Cozy va désormais se tourner. Ainsi Cozy ne sera plus un “cloud personnel” comme il se plaisait à le revendiquer, et va donc devenir un cloud qui se rapproche des désormais très traditionnels Owncloud / Nextcloud et autres.

C’est justement l’aspect personnel, mono-utilisateur, et d’administration quasiment nulle qui m’avaient justement séduit.

Par exemple, on met souvent en avant l’exemple du modèle familial pour justifier un système multi-utilisateurs, alors je ne suis pas certain qu’à terme, ce soit la bonne solution. La vie n’est pas toujours un long fleuve tranquille, et il est parfois utile de pouvoir cloisonner, voire détacher vers d’autres cieux ses données personnelles d’une cellule familiale qui évolue. Dans le cas d’un système personnel, il est alors aisé de partir avec son RasPi et son support de stockage attaché sous le bras. Au prix du Mo de stockage aujourd’hui, le frein de la replication de données n’existe plus depuis longtemps (même si je comprends qu’intellectuellement, avoir X exemplaires des mêmes données n’est pas très satisfaisant).

De même, avoir un système personnel n’empêche en rien le partage avec d’autres utilisateurs (locaux dirai-je, ou distants) - c’était d’ailleurs ce qu’a commencé à mettre en place @Paul, et qui ouvrait des perspectives très prometteuses, en l’appliquant à d’autres “objets”.

Je comprends que l’on argue le coût matériel d’un seul utilisateur, mais peut-être était-il possible d’améliorer cela indépendamment du multi-utilisateurs qui amènera probablement un surcroit de travail, et des risques supplémentaires liés à la sécurité, très chronophages à maîtriser.

En fait, tout cela me laisse à penser que Cozy va se tourner désormais plus vers des utilisateurs “administrateurs” de groupes (personnels de sociétés, clients, etc.), que vers des personnes qui veulent gérer leurs données (vraiment) personnelles. Cette stratégie est tout à fait légitime, mais s’éloigne, AMHA, de l’objet initial.

En tous cas, bon courage aux développeurs !


#18

Sera-t-il possible de faire en sorte que les data des appli (photo, docs …) ne soient pas enfermées dans cozy ?
Exemple : possibilité de stocker les photo de l’appli photo dans un /media/monnasmaison …
et que l’appli se débrouille à les chercher quand elle en a besoin.

Et en attendant je peux sauvegarder mes photos tres facilement, séparément de la conf de cozy.


#19

Bonjour,
Je partage l’avis d’Efcis. Pour moi le multi-utilisateur est une fausse route. Il ne prend son sens que lorsque que l’on héberge Cozy sur son propre serveur, et c’est un cas qui restera forcément minoritaire. Cela implique trop de savoir-faire et de technique. Dans le cas où Cozy est un silo indépendant mais hébergé dans un data-center, on n’a plus besoin de s’occuper du multi. Une instance par personne, basta … du saas quoi.


#20

Je comprends l’avis de @Efcis et de @fracture, mais je connais un certain nombre de personne qui attendent un coté multi-utilisateur pour gérer un serveur fammillial, d’entreprise ou même d’association afin de partager ses données telles que photos ou musiques.

Peut-être q’une solution serai de poser la question du multi-utilisateur au premier démarage de l’instance, et que si le choix est d’une instance mono-utilisateur, les paramétrages du multi-utilisateur soit “bridés” de manière à laisser une administration facile à gérer (avec éventuellement un bouton pour passer de mono à multi-utilisater).