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.
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, 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 ?
- 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.