larlet-fr-david/david/stream/2015/05/01/index.md

title: Stockage décentralisé

> Les aspects de l’architecture qui nous semblent incontournables:
>
> * La solution doit reposer sur un protocole, et non sur une implémentation ;
> * L’auto-hébergement de l’ensemble doit être simplissime ;
> * L’authentification doit être *pluggable*, voire décentralisée (OAuth2, FxA, Persona) ;
> * Les enregistrements doivent pouvoir être validés par le serveur ;
> * Les données doivent pouvoir être stockées dans n’importe quel backend ;
> * Un système de permissions doit permettre de protéger des collections, ou de partager des enregistrements de manière fine ;
> * La résolution de conflits doit pouvoir avoir lieu sur le serveur ;
> * Le client doit être pensé «*offline-first*» ;
> * Le client doit pouvoir réconcilier les données simplement ;
> * Le client doit pouvoir être utilisé aussi bien dans le navigateur que côté serveur.
> 
> <cite>*[Eco-système et stockage générique](http://www.servicedenuages.fr/eco-systeme-et-stockage-generique.html)* ([cache](/david/cache/56a65f2910bbf3fc01d248c0826bbcf9/))</cite>

Les amis (ex-)pythonistes actuellement chez Mozilla sont en train de faire des choses intéressantes. Avec un blog qui me rappelle à chaque fois [Georges Clooney](http://www.imdb.com/title/tt1234548/), merci les gars. Un petit retour à chaud sur la stratégie adoptée :

* pourquoi avoir encore besoin d’un serveur et ne pas penser directement P2P ?
* est-ce qu’il n’y aurait pas moyen d’étendre la réflexion sur une approche non pas individuelle mais [communautaire](/david/stream/2015/04/15/) ?
* dans quelle mesure les données pourraient être chiffrées par défaut ?
* est-ce que l’utilisation d’un DCVS a été envisagée ? Quid de la pérennité des données en cas de disparition du serveur ?
* quand je lis l’intégralité de la liste citée, j’ai peur que le résultat soit trop générique/intelligent pour être [convivial](/david/blog/2013/outils-conviviaux/).