Pour plusieurs raisons que j’expliciterai peut-être plus tard, j’ai décidé de me lancer dans un « nouveau » projet, du moins à court terme : l’Oxydation de Duniter.
Ce n’est pas tant un « nouveau » projet qu’un changement de stratégie, voici l’idée générale :
Plutôt que d’écrire une nouvelle implémentation du protocole DUBP a coté (Dunitrust), l’idée du projet « Duniteroxyde » est d’intégrer progressivement du code Rust dans Duniter via un outil de binding NodeJs<->Rust: Neon.
Cette approche a plusieurs avantages :
- Suppression de l’effet tunnel que connaît actuellement la Ğ1 (Pendant que je dev Dunitrust je ne fais pas avancer Duniter, et en même temps Dunitrust est encore très trèèèès loin d’une v1).
- Bénéficier de la couverture fonctionnelle offerte par les TF que possède Duniter.
Étapes
- Migration de wotb: en bas de ce 1er post
- Migration de naclb: post n°32 (lien direct)
Architecture
Le projet d’oxydation de Duniter s’étaler sur 3 dépôts git :
- dubp-rs-libs: contient les crates que j’extrait de Dunitrust pour les intégrer dans Duniter
- duniteroxyde: contient de code de binding Rust<->NodeJs (utilise neon-binding)
- duniter: le dépôt historique du logiciel Duniter, utilise désormais le module npm « duniteroxyde » comme dépendance.
Pourquoi n’était-ce pas envisageable dès le début ?
Pour au moins 3 raisons :
- A l’époque, Neon était trop jeune et incomplet, le code de binding était lourd et verbeux, et faisait perdre certaines garanties du Rust (notamment la sûreté de la mémoire).
- L’oxydation de Duniter n’était de toute façon pas possible à cause d’un problème bloquant au niveau du build pour windows (c’est juste un problème de VM pas a jours mais en 2 ans personne n’a su le régler), cf ce fils : Du Rust dans NodeJs graçe a Neon : le courant passe !
- J’ai découvert NodeJs en même temps que la monnaie libre il y a 3 ans et demi, il y a 2 ans je n’avais clairement pas le niveau requis en NodeJs pour me lancer dans une oxydation de Duniter. Je découvrais la programmation asynchrone (moi qui avais toujours codé en synchrone), et je suis resté très mal à l’aise avec ce paradigme jusqu’à récemment.
Oxyder Duniter jusqu’où ? Quid de Dunitrust ?
Pour être franc je n’en ai absolument aucune idée, l’avenir nous le dira. Cela dépendra aussi de jusqu’où il sera envisageable d’oxyder Duniter, en concertation avec @cgeek 
Quant au projet Dunitrust, une grande partie du code pourrait être réutilisée plus ou moins directement dans l’oxydation de Duniter, du moins en théorie, en pratique ça dépendra des difficultés rencontrées et de jusqu’où ou souhaite aller dans l’intégration.
Les portions de code qui seront intégrés dans Duniter pourrons être « mises a l’épreuve de la prod », donc en vrai cela bénéficie aussi au projet Dunitrust d’une certaine façon.
Qu’en est t’il à court terme ?
A cours terme je vois déjà 2 étapes dans l’oxydation de Duniter que je suis en mesure de réaliser rapidement :
- Migration de wotb: je viens de passer 4 jours sur cette étape a quasi plein-temps (environ 30h), cela fût long car je suis reparti d’une feuille blanche (explication ici) et qu’il a fallu que je me replonge dans Neon (qui a beaucoup changé, pour le mieux) et dans NodeJs/Typescript. L’étape 2 devrait être beaucoup plus rapide.
- Migration de scryptb et naclb: dans une approche isofonctionelle bien entendu (donc avec gestion de la clé privée), l’objectif n’est pas de restreindre Duniter (du moins pas pour l’instant, on pourra toujours décider de le faire plus tard s’il y a un consensus en ce sens).
Étape 1 : Migration de wotb
La 1ère étape est déjà quasiment terminée, la MR est ici : https://git.duniter.org/nodes/typescript/duniter/-/merge_requests/1290 (la CI a des soucis bizarres mais les tests passent chez moi).
J’en ai profité pour externaliser la crate dubp-wot dans son propre dépôt, qui contiens également le code de binding (dans le dossier node-binding) : https://git.duniter.org/libs/dubp-wot
J’ai déjà déployé ce code sur un de mes nœuds g1-test, et tout semble bien fonctionner : ts.gt.librelois.fr
Je n’ai pas refait de sync, ce n’est pas nécessaire car le code de binding que j’ai écris est capable de lire le fichier wotb.bin d’origine. (j’ai aussi testé en faisant une sync, sur mon nœud duniter de dev en local et tout se passe bien).
J’ai également mis à jours tous les scripts de build, il faut encore que je teste chacun des paquets (variante desktop et paquet arm notamment).
EDIT: toutes les variantes ont été testées et toutes se build avec succès.
Pour tester Duniter en mode « oxydé » vous aurez besoin de Rust et d’un version précise de node, voici les commandes (a ne faire qu’une fois) :
nvm install 10
nvm use 10
curl https://sh.rustup.rs -sSf | sh -s -- -y
echo "export PATH=\"$HOME/.cargo/bin:\$PATH\"" >> ~/.bashrc
source ~/.bashrc
A partir de la 2ème fois, la commande nvm use 10 suffit.
Pour compiler Duniter, utilisez comme d’habitude la commande yarn
