Je ne savais pas dans quelle catégorie ranger ce post, vous pouvez le déplacer si vous voulez.
J’aimerais mettre sur le tapis un sujet qui m’irrite profondément. Mon but n’est pas d’envenimer des tensions actuelles, mais d’exprimer ce qui me dérange profondément au lieu de le garder et que ça continue de salir mes propos.
Je me permets de retransmettre ici quelques passages isolés d’une conversation que nous avons eue avec @kimamila ces derniers jours.
Je ne touche bien sûr pas à ce qui doit rester dans la sphère privée, uniquement à ce qui me semble nécessaire pour alimenter cette discussion.
J’aimerais qu’on s’arrête 5 minutes sur ce bout d’échange.
Tout d’abord j’aimerais éclaircir un point.
Je suis admiratif du travail que @kimamila a fait pour le lancement de la G1. Je l’ai déjà dit mais j’ai vraiment envie de le redire : l’adoption de ce réseau n’aurait probablement pas été la même s’il n’y avait pas eu un outil aussi user friendly que Cesium pour onboarder les gens, avec un rendu moderne (pour l’époque du moins), responsive, web/android/ios, avec des données offchain pour les profils utilisateurs. Ça a été un travail titanesque, surtout quand on met en perspective les limitations de l’API BMA de Duniter v1, le travail sur les pods Cs, tout un écosystème backend, et je ne compte pas gchange qui était initialement intégré à Cesium et qui a été sorti pour devenir indépendant suite aux débats de l’époque.
On s’en rend d’autant plus compte quand on travaille soi-même sur un client de même gabarit : réussir à rejoindre le niveau fonctionnel de l’écosystème Cesium est vraiment long et semé d’embûches.
Pour la suite, je pense qu’il faut persister dans notre volonté de modularité dans les services offchain, et persévérer dans notre veille sur les solutions existantes pouvant coller à notre besoin tout en reposant sur des communautés actives.
Un monde existe en dehors du nôtre, et je pense que ce serait une erreur de vouloir tout refaire nous-mêmes de nouveau au vu du peu de ressources et de temps que nous réussissons à débloquer.
Ainsi, j’aimerais qu’on soit au clair sur ce que nous appelons migration “ISO”.
Selon moi, il y a des fonctionnalités non essentielles et très peu (voire pas du tout) utilisées qui ne sont pas du tout essentielles pour la migration.
Pire encore, je pense qu’il est contre-productif de livrer encore aujourd’hui de nouvelles fonctionnalités à Cesium v1 (les notifications) et de demander derrière une migration ISO comprenant ces nouvelles fonctionnalités.
Plutôt que de lister ce qui me semble essentiel, je vais plutôt lister ce qui ne me semble pas essentiel :
- Le système de notifications : utile mais bugué, les notifs ne passent jamais en “lu”, et c’est une fonctionnalité qui pourra aisément être ajoutée un peu après la migration. Je pense que les gens pourront s’en passer quelques temps sans trop de problèmes.
- La messagerie Cesium : pareil, je pense que plus personne ne s’en sert (hormis des spammeurs une fois tous les 2 ou 3 ans), qu’elle manque actuellement cruellement d’intégration UX pour être pratique à utiliser, et surtout que ça n’a rien à faire dans des datapods. Il vaudrait mieux s’emparer/hacker des solutions existantes, standalone, capables d’être utilisées avec nos clés G1, et éventuellement ensuite intégrées aux clients si l’envie en est, mais ce n’est pas nécessaire. En tout cas, en second temps.
- Les invitations : je pense que les gens pourront s’en passer quelques temps sans trop de problème. D’autant que ça pose justement parfois problème socialement, donc cela nécessite d’être discuté/revu.
- Notifications email : devront être repensées pour être correctement intégrées dans un système de push notifs robuste, tout en restant décentralisé (le système de services de Cesium allait dans ce sens), avec des solutions que j’ai listées plus haut dans ma citation. Non essentiel.
Je pense que passer du temps à reproduire ça pour la migration v2 est une perte de temps. Là, les devs de Cesium devraient se focus sur la stabilisation des fonctionnalités essentielles : comme la gestion complète des comptes membres, l’intégration des requêtes squid manquantes (historiques des DUs, etc.).
Continuer de laisser les devs de Cesium faire ce que bon leur semble, en conscience, c’est aller à l’encontre des intérêts des utilisateurs pour la bonne tenue de la migration v2.
Et ça rajoute une pression inutile au reste des devs de l’écosystème technique, en élargissant constamment la notion de “ISO”.
Et surtout, cela fait des années que certains choix d’architectures ayant été faits côté pods Cs sont remis en question et pour lesquels d’autres voies plus collectives et robustes ont été explorées, mais qui ne sont pas terminées. Vouloir imposer ce mode ISO, c’est précipiter les choses pour refaire les mêmes erreurs qu’en v1, refermer les portes vers d’autres voies plus robustes mais qui prennent plus de temps à se mettre en place.
Personnellement je ne suis pas (ou plus) pressé du tout, mais qu’importe. J’ai assez de stress ailleurs dans ma vie. Je continue mon chemin avec les priorités qui sont les miennes.
