Nous n’avons finalement pas trouver de créneaux pour en discuter car cela n’étais pas prévu dans le programme. Il faut qu’on se cale un créneaux pour ça dans le programme de Bordeaux !
De toute façon de mon coté j’ai d’autres priorités sur les 6 mois a venir.
Je vois que c’était prévu dans le programme :
Du coup, je ne sais plus trop où donner de la tête, l’API BMA commence à m’agacer pour le développement de Silkaj.
Du coup, j’aimerais bien faire avancer cette API cliente, développer Silkaj et durs.
Je suppose que cette nouvelle API est déjà implémentable en l’état dans durs.
Je ne pense pas que quelqu’un veut ou a l’énergie pour l’implémenter en TS.
Je pense qu’il est plus simple de l’implémenter en TS dans un premier temps à vrai dire. C’est quand même bien plus souple comme langage 
Il y a 2 éléments pour lesquelles cette API doit répondre à la problématique :
Le premier point peut être mis en oeuvre dès maintenant et c’est souhaitable à mon avis. Il faut une BDD distincte de duniter pour pouvoir héberger les données importantes telles que l’historique des DU générés (c’est ce qui fait que sakia met des heures à charger la premiere fois qu’on connecte un compte)
Je pense pas qu’il y ait besoin d’attendre énormément, soit on spécifie l’API d’abord, soit on y va en l’implémentant et en l’améliorant de manière incrémentale à l’usage.
Si la deuxième solution permet de démarrer sans attendre, je pense qu’il ne faut pas hésiter à y aller.
Je veux bien aider sur duniterpy, en nettoyant le code pour accueillir un package GVA qui implémenterait GraphQL pour python.
Mon but est de continuer à monter en compétence en python.
Par contre je ne saurais pas faire de zéro un module Duniter, ni en TS ni en Rust.
Mais si on veut l’api pour clients dont on rêve, il faut bosser sur les deux en parallèle je pense…
Vous n’avez pas pêché du breizh développeur à Douarnenez ? 
ha oui en effet, ben personne n’y a penser le jours J 
Non pas pour le moment car le module API client aura besoin de requeter le module Blockchain hors je compte refondre les façon de requêter le module Blockchain, donc avant de pouvoir dev l’api GVA dans durs il faut d’abord qu’on se mette d’accord sur les spec des messages inter-modules.
Ensuite pour dev l’api GVA dans durs il vous faudra un nœud qui reste synchro sinon ça va être l’horreur a dev, hors pour l’instant ce n’est pas le cas car je n’ai pas codé le roll back, et avant de coder ça je compte migrer tout le système de donnée de SQLite vers rustbreak (oui j’ai enfin choisi 
).
Ce qui va me prendre une durée indéterminée, ça peut prendre 1 semaine comme 3 mois, je n’en sais rien.
Bref c’est un peu tôt.
Ah yes !
Si jamais tu veux de l’aide, hésite pas à spit le boulot, je contribuerai quand je pourrais.
Du coup cette API, où en est-elle ?
Avec @inso, nous avons rédigé une RFC qui identifie les besoins, voir si GraphQL est vraiment le bon choix. Il semblerait que oui.
Mais en suivant la RFC de @nanocryk sur le protocole V11, on s’est dit que c’était bête de faire deux fois le travail… Refaire le protocole V10 en mode texte, puis tout refaire en mode binaire avec des merkle trees.
On s’est mis en attente du protocole V11…
Comme nanocryk est parti sur Fygg (j’espère ne pas écorcher le nom…), ben on attends le format de documents binaire déjà.
Sachant que le gros du boulot sera le module serveur (rust ou ts) avec son parser GraphQL et toutes les fonctions de l’api, et sa database dédiée pour les historiques.
Côté client, la librairie Python duniterpy supportera le GraphQL très simplement au départ avec les deux types d’appels (query et mutation). Viendra ensuite si besoin une classe d’abstraction reprenant le schema GraphQL du serveur.
Je suis en train de refactoriser duniterpy.
La librairie supporte :
A faire :
@inso et moi gérons donc la partie client de l’api (en Python).
Par contre, personne en vue pour écrire le module serveur GraphQL en Rust ou Typescript…
De mon coté tout les documents du protocole sont déjà binarisés dans duniter-rust, donc sur cette base je pourrais proposer un format binaire pour les documents du protocole Duniter
Même si on ne l’implémentera pas tout de suite car on n’a d’autres priorités, ça vous permettrait d’avancer sur les spec de GVA
En Rust si, j’ai déjà dit que je le ferai car le moment venu je vais de toute façon avoir besoin d’une API Client, et pas BMA car elle est obsolète.
Entre faire ma propre API de mon coté ou implémenter GVA pour moi c’est a peu près pareil niveau temps et énergie demandée donc autant implémenter GVA.
Cependant, en vue de tout ce que j’ai a faire sur Duniter-Rust avant, je pense m’atteler a la partie API Client au printemps 2019 dans le meilleur des cas, et plus probablement a l’été 2019.
mais jusqu’à quand comptez-vous attendre ? Si je m’étais dit qu’il valait mieux que je fasse tout du 1er coup je n’aurais jamais rien fait.
Moi je veux bien vous aider en codant la partie backend, mais il me faut 2-3 documents explicatifs.
Et pas besoin d’attendre 6 mois, je peux développer un module et le brancher sur le nœud ĞTest de duniter.org au fur et à mesure de son développement, donc vous sortir une API exploitable dès la semaine prochaine si vous voulez.
Ben là moi j’attends plus justement. 
Je reprends toute l’architecture de Duniterpy depuis plusieurs jours pour y ajouter le support client de GraphQL. J’ai terminé la refonte. Mais avant GraphQL, je veux ajouter le support de WS2P qui n’avait pas été terminé. 
Après cela, je m’attaquerai au support de GraphQL, et à la génération des documents pour la GVA. Documents dont le format reste à déterminé. Celui de Durs ? Celui qui tu as préparé pour la 1.7… Enfin du binaire, ça c’est sûr…
Par contre, pour le module côté serveur, il faudra bien un jour passer en revue les choses importantes dont ont besoin les clients et qui sont absentes de l’api BMA, avec @inso et les mettre dans la RFC de la GVA.
Mais on peut commencer par des requêtes Query simples pour se faire la main avec GraphQL côté serveur (schéma, choix de la librairie, notion de resolve, etc). Puis on enchaînera par une requête Mutation avec l’envoie d’un document Identité par exemple.
Le gros de la RFC sera sur la gestion des historiques, la vérification par Merkle Trees, l’agrégation de données en états, etc…
Bref, je continue côté client cette semaine et je te demanderai ton aide dès que je serai prêt pour un test avec le serveur de test. A suivre…
Je pense qu’il faut, dans un premier temps, ignorer les Merkle Trees et l’aggrégation des données en états.
Il faut faire une API GraphQL pour le protocole blockchain actuel.
On mettre à jour l’API lorsqu’on mettra à jour le protocole blockchain
Si GraphQL impose du binaire ça veut dire qu’il faut être capable de convertir les documents actuels au format binaire, donc faut qu’on se mette d’accord sur un format avec @cgeek.
Ou alors j’ai mal compris, @vit, GraphQL impose nécessairement du binaire ?
GraphQL n’impose pas de binaire Mais à la base, on voulait mettre en place de la vérification décentralisée dans GraphQL. Je pense qu’il faut l’oublier tant qu’on a pas les merkle tree.
Pourquoi vouloir du binaire sinon ?
Il y a juste eu confusion entre les merkle tree et la binarisation du protocole.
Je crois que @kimamila a déjà bien avancé sur le sujet GraphQL, mais pour un autre projet. Il nous avait fait quelques démonstrations aux RML11.
Je veux bien creuser un peu le sujet tout seul, mais bon si certains ont déjà réfléchi je ne suis pas contre quelques conseils/préconisations.
Non Graphql est indépendant du protocole de transmission normalement. On peut utiliser http ou websocket. Les requêtes et retour sont en string json, pas de binaire.
Je retiens donc pour ma partie cliente que j’ai juste à faire du BMA en Graphql.
Il semble que @kimamila maîtrise un peu graphql, si il a fait un module nodejs c’est top. Si c’est du java… De toute façon je vais chercher de mon côté comment on déclare les fonctions et les objets de l’api côté serveur. Je pourrais t’aider @cgeek.
Ok très bien, je vais regarder un peu cet après-midi aussi.
Je rassemble ici les ressources trouvées sur GraphQL pour nodejs citées plus haut dans ce sujet :
Une réflexion m’est venue à l’esprit. Un gros avantage de GraphQL est de pouvoir demander une partie des champs d’un objet/document. Mais comme nos documents sont signés, ben on est obligé de recevoir tout le document pour vérifier la signature…