Quelles priorités dans les devs Duniter?

Je ne sais pas si la gestion des clefs courtes (moins de 44 caracteres en base58) étaient la priorité pour Duniter ? On aurait aussi pu décider de ne pas les autoriser, dans les clients, pour le moment…

Par exemple la gestion des TX compatibles avec plusieurs branches BC me paraît prioritaire. Idem pour le changement d’implémentation des conditions, afin de pouvoir avancer sur les lightening network (je ne sais plus quelle condition s’appliquait sur le mauvais timestamp, entre bloc d’emission et bloc de prise en compte).

Avec @vit je me demande si on ne pourrait aussi avancer sur le portage de la BDD de Duniter ? Je fais ça très souvent dans mon boulot, et la BDD de Duniter n’a que quelques tables/concepts. Ca me paraît pas si compliqué… même si le risque de régression est réel.

Ceci nécessiterait, pour moi, de maintenir au strict minimum les évolutions de Cesium. D’un autre côté, cela faciliterait l’arrivée de GVA.

J’ai l’impression que certains devs se découragent un peu. Je voulais aussi vous redire à quel point selon moi ce projet est important. Il est normal que les fruits mettent du temps à sortir. Ce qui se construit pour le long terme arrive à maturation lentement.
Depuis 17 ans que je travaille dans la diffusion de données scientifiques, je vois bien qu’il faut facilement un décennie pour que des standards apparaissent, que les choses se débloquent et avancent enfin. Je persévère dans ce domaine et je constate que les fruits sont la, et resteront là pour longtemps.

Prenez patience et gardons Le Cap !

"La vie de beaucoup dépend du courage de quelques-uns " disait JRR Tolkien dans un de ses livres…

Cc @inso @cgeek @moul @ji_emme @poka @Frederic_Renault @tuxmain @elois
@gerard94 etc

6 J'aimes

Je me suis retrouvé tout seul sur une codebase vieillissante que le dev d’origine n’a plus envie de maintenir avec de nombreux petits bug( plus de 200 tickets) du couplage fort et le tout dans une techno avec laquelle j’ai du mal.

Je ne suis pas en capacité de maintenir ou faire évoluer significativement la codebase typescript actuelle, la seule chose que j’arrive à faire c’est de migrer en rust brique par brique, traitement par traitement, car je comprends suffisamment le métier de Duniter pour ça.

Donc ma priorité c’est de migrer Duniter tout en gardant une stabilité en prod. ce qui à des implications dans l’ordre dans lequel je peux migrer les différentes briques.

Il reste tout de même un petit degré de liberté, que j’essaye déjà d’exploiter au maximum en faveur de GVA car j’ai bien compris depuis longtemps que c’était un besoin prioritaire pour toi et les dev des autres clients.

C’est pour cela que depuis début juin j’ai commencé la migration de la DB de Duniter et de la couche DAL (Data Access Layer) qui se situe par-dessus. Pour respecter l’objectif indiqué au-dessus (migrer Duniter tout en gardant une stabilité en prod)’ je suis obligé de migrer entièrement DAL avant de pouvoir commencer GVA. J’ai déjà passé une centaine d’heures de travail la dessus depuis début juin, j’en ai peu parlé car je n’aime pas m’étaler sur des travaux pas finis, mais ton post m’oblige à le préciser.

En effet ce n’est pas la priorité, et je n’y ai d’ailleurs passé qu’un temps négligeable (moins d’1h) par rapport au temps colossal que j’ai passé sur la migration de la BD (plus de 100h déjà).

Je suis déjà bien avancé sur le portage, je préférerais que vous patientiez ne serait-ce que par respect pour tout le temps que j’y aie déjà consacré.

Tout à fait, je compléterai par l’histoire du bambou chinois :

C’est un peu ce que je ressens aujourd’hui, je m’implique énormément pour que vous ayez GVA dès que possible, mais vous n’en percevez pas encore les fruits.

9 J'aimes

Aussi migrer la DB et la couche DAL ne suffit pas pour GVA. Pour pouvoir fournir les données attendues par le schéma de GVA il faut aussi créer un code d’indexation des block spécifique pour remplir une db des données qui alimenteront GVA.
Faire tout ça en maintenant Duniter en prod c’est vraiment un chantier titanesque.

Si vous voulez un prototype restreint de GVA le plus tôt possible, je peux commencer par n’exposer que ce que la DB de Duniter permet directement.

4 J'aimes

@kimamila @Moul @vit en attendant qu’un premier prototype de GVA ne vois le jour vous pouvez dès maintenant créer un mockServer pour pouvoir commencer vos développements basés sur GVA, il suffit qu’on se mette bien d’accord sur le schéma de ce serveur de mock :slight_smile: (car je vais devoir fournir le même schéma derrière).

En particulier pour cesiumV2, créer un mock server en js est simple et bien documenté : https://graphql.org/blog/mocking-with-graphql/

Il semble même possible de faire du mock partiel: https://www.graphql-tools.com/docs/mocking/#addmockstoschema
Cela permettrait aux dev de CesiumV2 d’utiliser les premiers prototype de GVA même s’ils seront incomplets en bouchonnant les query manquantes.

1 J'aime

Je propose de se focaliser au début de GVA, sur le paiement rapide et fiable (malgré les forks).

En effet, nous avons démontré la faisabilité d’une création monétaire via une toile de confiance. Les logiciels sont opérationnels sur cet aspect.

Je penses qu’il est aujourd’hui utile de démontrer que des moyens de paiement pratiques et rapides peuvent être mis en oeuvre.

Ainsi, je propose que GVA ( + Césium V2) soit un PoC dans ce sens. Les utilisateurs pourraient très bien avoir les 2 versions de Césium sur leur téléphone, et comprendre que l’une est plus pratique pour les paiements, tandis que l’autre est plus complète (mais plus ancienne) pour la gestion de la WoT.

En effet, si les inscriptions & certifications peuvent être gérées à la maison, les paiements ont besoin d’être d’avantage sur mobile, avec ou sans réseau, avec ou sans contact, etc. Via des terminaux de paiement, cartes de paiement, etc.

Qu’en dites vous ?

GVA pourrait en premier lieu de focaliser sur une gestion pratique des TX ( accès aux « sources », accès au solde, usage de lightning network, etc.)
Plutôt qu’une migration, il s’agirait d’avantage de nouvelles fonctionnalités, ou disons de nouveaux formats de serialisation, plus pratique.

Par exemple, pour avoir une gestion hors ligne dans Cesium2, j’aimerai un moyen de télécharger rapidement un delta des sources (delta depuis le dernière synchro, avec détection des sources rollbackée/a supprimer). Il y a donc une notion d’arbre de Merkel a développer, j’imagines. A voir

3 J'aimes

Merci @elois pour tout ton travail sur la BDD ! Je te confirme dans cette voie. Clairement, c’est un bon investissement.

En revanche je ne vois pas de problème de respect la dedans. Césium a pu avancer grâce a des développeurs qui ont faire leur sauce dans leur coin, sur des forks, me permettant au final d’y prendre de bonnes idées.
J’y vois plutôt un problème d’orgueil…
D’autant que là il s’agirait de t’aider dans ce travail. Ne serait ce que pour relecture.

Par exemple je suis expert, dans mon boulot, en gestion de cache, pour décharger les BDD.
Cela peut donc être un travail parallèle et redondant, ou complémentaire, mais dans tous les cas utile in fine.

1 J'aime

Oups, j’avais oublié des mots ! C’est corrigé :grin:

Pour ma part j’avais pas mal baigné dans gva/rust mais très peu dans le code de duniter et encore moins dans celui de cesiumV2.

je peux faire des tests et du debug dans un premier temps et je verrais après.

1 J'aime

Dans ce cas-ci ce que je peux faire c’est laisser tomber la migration de la DB actuelle de Duniter et créer dès maintenant ure 2ème DB spécifique à GVA qu’on peuplera des transactions et sources uniquement pour commencer.
Je peux aussi migrer la DB SQLite des transactions, ce qui permettra de gérer la mempool des TX comme on veut (nécessaire pour que GVA puisse avoir des mutations pour les paiements), comme elle ne contient qu’une seule table ce sera rapide, je ne l’aie pas fait avant car je pensais que ce n’était pas prioritaire.
Concernant la compatibilité avec les lightning network tout est déjà bon sauf la contrainte txWindow qui reste a supprimé, je j’avais reportée car ça aurait nécessité d’ajouter une colonne dans receivedTime dans la Db SQLite des txs, et comme pour moi les mempool n’était pas prioritaire, j’avais reporté.

Peut tu développer plus précisément le besoin ? Je ne pense pas à première vu qu’une notion d’arbre de merkel soit nécessaire. C’est pour la maj de l’index des sources coté pod Cesium+ ?

Le problème c’est que dans Duniter la BDD est embarquée et fortement couplée aux traitements métiers, c’est beaucoup plus délicat qu’une simple migration.
Oui le risque de régression est important, et les tests automatisés ne peuvent pas tout couvrir.
C’est pour cela que je préfère m’en charger, je suis celui qui connaît le mieux la codebase de Duniter après cgeek, je sais exactement comment il faut s’y prendre pour minimiser le risque de régression.

Maintenant que je connais plus précisément tes besoins @kimamila je peux tout à fait réorienter mes développements pour y répondre au plus vite, voic ma proposition :

  1. Je migre TxsDAL seul (contient la mempool tx + historique des tx écritent). PerMet de supprimer la contrainte txWindow ET de gérer les paiements via GVA
  2. Je dev un prototype de GVA avec une base dédiée pour l’indexation des sources.

Je crois qu’il faut qu’on communique davantage par rapport à ce chantier « GVA paiement », il faudrait créer un sujet dédié :slight_smile:

Concernant les Lightning Network est on bien d’accord que le seul boulot coté Duniter c’est de rendre le protocole DUBP compatible ? Je préférerais que les « pod Lightning Network » soit un logiciel à part :slight_smile:

6 J'aimes

Un message a été scindé en un nouveau sujet : [GVA] CU « Emettre une transaction avec ou sans réseau »

J’ai fait un post pour te préciser cela.

Le dernier point (plus de block hash dans les TX) est à mon sens une priorité pour les devs Duniter. tu confirmes @elois ?

1 J'aime

J’entends que c’est une priorité pour toi, pour moi ça ne l’était pas. Mais je veux bien retarder la sortie de Duniter 1.9 pour intégrer ça dans DUBP v13 :slight_smile:

2 J'aimes