Nous entrons actuellement dans la phase terminale du projet de réécriture v2, il reste à terminer quelques fonctionnalités et tout assembler. Cela va nécessiter du travail sur l’ensemble des logiciels de l’écosystème, non pas pour les terminer – car un logiciel n’est jamais terminé – mais pour produire une version stable qui remplisse les fonctionnalités minimales attendues par les utilisateurs de la Ğ1. Je décris ci-dessous les tâches principales pour m’aider à les prioriser.
Commentaires de transactions
L’implémentation actuelle des commentaires de transaction en v2 (cf Implémentation des commentaires de transaction) repose sur System.Remark. Cette fonction est disponible en gdev, mais @elois a prévu d’interdire cet appel dans la g1 (cf commit fix(runtime): filter remark calls (a3951e56) · Commits · nodes / rust / Duniter v2S · GitLab). Il faut soit lever cette interdiction en vérifiant que ça n’introduit pas de faille de sécurité, soit implémenter une autre pallet pour commenter en toute sécurité. Pour ce qui est des fonctionnalités additionnelles (commentaires offchain, chiffrés…), ce sont des problématiques clients qui pourront être traitées post-migration.
Datapods
La question des données hors chaîne est vaste et largement irrésolue. Les datapods v1 (pods Cesium+) reposent sur la couche réseau de Duniter v1, ce qui décourage fortement leur utilisation telle quelle. Après une proposition centralisée (V2s-datapod: Hasura with Deno middleware to store profiles) et une proposition décentralisée (IPFS pour les datapods v2), on se retrouve dans une situation intermédiaire inconfortable. Je compte assumer la proposition décentralisée jusqu’à fournir :
- une installation “clé en main” avec docker (jusque là un peu de configuration est nécessaire)
- une API RPC permettant de publier des données (jusque là ce n’est possible qu’en p2p ce qui nécessite d’embarquer un nœud ipfs, ou via une API HTTP archi bricolée)
- le strict minimum en manière de sécurité, tout en sachant qu’il s’agit plus d’une PoC que d’une vraie solution
C’est inconfortable de prévoir une migration dans des conditions si rudimentaires, mais vu les forces disponibles dans le projet, il m’est impossible d’envisager mieux.
Précalcul de la règle de distance
Comme expliqué dans ce sujet Guessing distance result before requesting evaluation, il faudrait un script qui évalue la règle de distance pour toutes les identités à intervalle régulier et fournisse le résultat au client. Ne pas fournir ce précalcul exposerait les nouveaux membres à une pénalité en cas d’évaluation négative et freinerait les nouvelles entrées. Ce n’est pas strictement nécessaire mais ça représente relativement peu de travail puisque l’oracle existe déjà et ça diminuerait les incompréhensions à l’étape critique que sont les nouvelles entrées dans la toile de confiance.
Cesium 2
Pour tester les fonctionnalités v2, j’ai fait Duniter panel (Duniter panel, un client pour tester la v2), mais la plupart des utilisateurs interagiront avec Cesium (Cesium² : top départ!), il faut donc que cette appli permette de réaliser toutes les tâches de base. Mon travail va être de suivre les tickets Cesium, prototyper quelques fonctionnalités, et surtout mettre en place toutes les fonctionnalités backend manquantes. Kimamila a besoin d’aide sur cette tâche, il pourrait être pertinent de financer un développeur frontend pour l’assister pendant quelques mois.
Beta-test
Il y a plusieurs points à avancer pour que le beta-test puisse se faire dans de bonnes conditions, notamment le runtime upgrade 802 sur la gdev (ĞDev Runtime 802 - #5 by HugoTrentesaux), un tutoriel détaillé pour les forgerons et nœuds miroirs, des outils pour simplifier l’utilisation. Cela permettra de tester les version de Cesium dans de bonnes conditions.
Stabilisation et gestion d’urgence
C’est un des points les plus difficiles à évaluer. Il reste (et restera toujours) des bugs plus ou moins impactants et plus ou moins complexes à résoudre. Il est impensable de les résoudre tous (cf tickets) avant la migration, et il faut donc choisir lesquels seront gérables en production et la stratégie de test à adopter pour se protéger contre des problèmes en cascade (#141).
Il serait également rassurant de prévoir les scénarios d’urgence que nous pourrions rencontrer (arrêt de la blockchain par exemple), et les actions à adopter en réponse (y compris code substitute). C’est pour l’instant inexploré si nous n’avons pas l’aide d’@elois.