Génial !!
Oui, comme on en a déjà parlé, le plus simple pour Gecko est de continuer sur l’archi binding rust étant donné que tout existe en Rust, et le dépôt Dart n’est plus vraiment à jour: News about this repository · Issue #5 · Pocket4D/Polkadot-Dart · GitHub
Je vais donc attendre les binding avant de toucher à Gecko, obligé. Par contre, si il y a des changements d’UX à prévoir, on peut les commencer dès maintenant.
Oui, la BlockChain se lance bien, nickel.
J’ai repris les travaux de Cesium2 a partir des lib Polkadot-js et ça a l’air pas mal. La suite bientôt 
Génial !
Est-ce que tu pars sur à peut prêt la même UI/UX de Cesium v1 ?
(bon en même tant on en est pas là, mais j’aimerai bien qu’on parle d’UX tous ensemble, sur figma ou pas, à l’occaz, ce serai chouette 
)
Juste une question : on saura si on obtient le financement ADEME début août. Si on l’obtient, penses-tu que nous serons capables de tenir les engagements ?
Ne pas les tenir pourrait nous handicaper si on décide de demander un autre financement pour l’implémentation de DUBP dans Substrate.
Oui sans aucun doute.
Aller, je fais un petit point Gecko, ça commence à faire un moment que je ne donne pas de nouvelles.
Voici un lien vers la dernière version:
J’ai bien avancé, je ne saurais être exhaustif quant aux changements depuis la dernière fois, mais voici quelques points à noter:
Utilisation de Hive pour les données locales: Base de donnée clé/valeur full dart, chiffré en sha512 et optimal pour flutter. Finit la gestion du stockage en mode fichier brutes parsés maison (mode bash…)
La plupart des écrans du dernier prototype Figma de Boris on été implémentés, dont l’UI a pas mal changé pour la plupart des écrans (l’écran d’onbarding cela dit n’a pas bougé d’un poil, il est toujours obsolète, ça devrait venir bientôt…)
Nouveaux écrans de changement de coffre, et de choix de coffre et de portefeuille lors du paiement
Import de coffre via mnemonic fonctionnel
Import de portefeuilles Cesium de nouveau fonctionnel, avec cette fois ci la gestion de multi coffre-à-Cesium
La recherche par username fait son apparition, mais avec un fonctionnement temporaire (utilisation du cache g1-stats qui lui même utilise une requête GVA gourmande, avec envoi d’un json entier mis en cache localement…) en attendant d’avoir mieux côté API. Quand je vois les performance de wotwizard-ui pour la recherche par username, je me demande si je ne vais pas partir là dessus aussi (ce qui ferait un total de 4 API pour Gecko: GVA, Cs+, gchange-pod et wotwizard, plus BMA si je décide d’intégrer les certifications maintenant… En espérant a terme remplacer tout ça pour une unique API RPC + gchange-pod).
Plus de binding Rust, j’ai créé ma propre lib de crypto (qui externalise aussi une partie des requêtes GVA aussi du coup, et dont les requêtes Cs+ viendront): Durt (Duniter/Dart, j’étais pas très inspiré pour le nom…)
Passage de toute l’app entièrement en « sound null safety ».
Au début je pensais que le binding rust était une force pour le projet, d’une part en couplant le client avec une partie du code de Duniter pour la crypto, en factorisant donc le code, en augmentant les performances grâce au Rust, et en m’épargnant du travail si d’autres se chargent de cette partie.
En réalité, Duniter n’est plus maintenu et est voué à disparaître sous cette forme, le mainteneur de la lib n’est plus disponible, le binding complique sensiblement la stack pour le potentiels futurs contributeurs, et enfin, il m’empêchait de compiler Gecko pour le web, ainsi que pour Desktop (ça aurait été possible sur desktop mais en adaptant le binding, on ne savais pas pourquoi cela ne fonctionnait pas avec Elois).
Il est vrai que des pertes en performance sont à noter lors de la création d’un coffre ou le déverrouillage de ce dernier, mais j’ai fait mon maximum pour le compenser, vous verrez (peut-être) à l’usage.
Voici donc une version native Linux: https://cloud.p2p.legal/s/WdNq8PyWQKZeg3c
Et une version web de Gecko: https://gecko.axiom-team.fr
Et en bonus une version iOS, non testé car je n’ai pas d’iPhone à disposition… Mais je sais d’avance que le scan de qrcode ne fonctionnera pas car il faut que je change de lib pour ça.
La version Linux fonctionne très bien, malgré des layout parfois pas du tout adaptés à cette taille d’écran et quelques détails ergonomiques. On sens bien que l’app n’a pas été pensé pour Desktop ^^
Cependant la version web est très décevante pour le moment, des lenteurs au chargement (le navigateur télécharge toute l’application avant d’afficher quoi que ce soit, manque à minima d’un écran de chargement), la recherche est anormalement lente, les requêtes Cs+ ne se font pas correctement, il y a un soucis avec les requêtes http pour le web (un comble) alors que les requêtes graphql fonctionnent bien.
Je rappel cependant que le but est avant tout de sortir une version Android et iOS fiable avant de penser aux autres plateformes, mais j’ai ouvert la voie pour ceux qui souhaiteraient s’y atteler 
Contrairement à ce que je disais dans le sujet Durt, la cryptographie est pour le moment exactement la même que celle utilisé par Dubp-Rust, c’est à dire l’utilisation de scrypt pour le passage mnemonic → seed pour les HD wallets.
Durt permet optionnellement de passer de Pbkdf2 ou Scrypt lors de la génération d’un dewif à partir d’un mnemonic (pour la partie mnemonic → seed bien sûr).
J’attends qu’on se mette tous d’accords sur les HD wallets avant de changer quoi que ce soit.
Il y a probablement des bugs dans cette version, mes tests d’intégrations ne sont plus à jours (je sais c’est vilain). Je me suis rendu compte que je perdais du temps à faire des tests si je sais que les écrans vont changer prochainement (c’est le cas de l’onboarding notamment, et certainement d’autres). Comme il s’agit de tests end-to-end chaque changement d’UI me fait refaire mes tests.
J’attends donc un peu d’être sûr de garder à peu prêt ces écrans avant de refaire mes tests.
Je vous donne donc des nouvelles uniquement pour les curieux et ceux qui se posaient des questions.
Cela dit vos retours m’intéressent tout de même ^^
J’ai essayé de dé-prioriser au maximum tout ce qui concerne GVA et le dialogue avec Duniter pour me concentrer sur la mécanique propre à l’application (même si parfois je n’ai pas le choix de passer un peu de temps dessus).
J’attends de mieux comprendre de mon côté le fonctionnement de l’api RPC et de savoir comment l’intégrer à Gecko, ainsi que l’avancement de Duniter v2, avant de songer à laisser GVA et Duniter v1 de côté.
Mais au rythme où vont les choses, je n’exclus toujours pas de sortir Gecko GVA si je le considère prêt (v0.1.0) bien avant que Duniter v2 soit prêt. A voir, je suis un peu dans le flou à ce sujet là, étant donnée qu’il n’y a pas d’échéances.
Plus j’avance et plus je me rends compte du travail qu’il me reste avant d’espérer sortir une version grand publique.
Je remet en question beaucoup de choses, que ce soit au niveau de l’UX, mais aussi au niveau de l’organisation de mon code.
Je me dis aussi de plus en plus que sortir une version sans la possibilité de gérer son compte membre et ses certifications n’a peut être pas trop de sens, et risque de perdre les utilisateurs avec un outil qui ne permet pas de tout faire.
Vos avis m’intéressent là dessus.
La bonne nouvelle pour ceux qui souhaiterai contribuer, c’est que désormais débarrassé du binding Rust, il devient beaucoup plus simple de lancer Gecko en mode dev.
A vrai dire, en théorie si vous arrivez à lancer un hello world flutter, vous devriez pouvoir lancer gecko de la même manière 
(désolé pour ce pavé, en espérant ne pas attendre de nouveau 6 mois pour les prochaines nouvelles…)
Pourquoi envisages-tu un branchement sur l’API RPC déjà ?
Je croyais que GVA était abandonné… Puisque Duniter 1.9 ne verra jamais le jour.
Gecko utilisera donc un seul nœud de dev pour ses requêtes GVA ?
Si oui, ne crains-tu pas un problème de goulot d’étranglement ?
Je commence quelques essais.
Au début, il y a la phase création du coffre. C’est long, je ne sais pas si les gens vont bien prendre le temps de lire toutes les explications.
Mais au moment de saisir le nieme mot de la phrase de récupération, il est clair qu’il faut l’avoir noté. J’ai essayé de faire une capture d’écran, mais le fait de quitter l’appli pour voir la capture oblige à tout recommencer. Donc obligé de noté (avec risque d’erreur)
Je n’ai pas vu comment retrouver cette phrase de passe si on perds le papier sur lequel on a pris des notes.
Après saisie du mot de passe il y a un temps assez long, je me suis demandé si je devais faire quelque chose ou juste patienter.
Quand je vais sur la page gérer mon coffre, et que je touche la flèche pour revenir en arrière, j’arrive sur un écran blanc, et je ne peut plus rien faire.
Edit : Bon en fait je viens de me rendre compte que je n’avais pas l’accès internet. (ce serait sympa de le dire)
Et bien pour communiquer avec Duniter v2, émettre des transactions, certifier, ect …
Pour les lectures uniquement, si j’ai bien compris, on pourrait plutôt passer par un proxy graphql comme Hydra.
A moins que je n’ai pas compris quelque chose ?
Pour le moment, je n’ai aucune visibilité sur l’avenir de Duniter.
Il y a eu tellement de rebondissements en 1 an que je n’exclu pas que la situation reste ainsi pendant encore un moment.
Pour le moment GVA ne fonctionne que sur les noeuds de dev mais il n’est pas exclus, même si peu probable, qu’on décide de passer Duniter 1.9 en prod un jour si Duniter v2 se fait trop attendre.
Le plus probable est que Gecko ne sorte pas tout de suite en prod et qu’on parvienne à lancer Duniter v2 d’ici, donc plus de GVA, mais l’avenir nous le dira.
Je sens bien que je devrais moi même mettre les main dans le cambouis de substrate pour avancer, mais ça me parait encore hors d’atteinte, je viens à peine d’apprendre Dart, me mettre au Rust c’est encore toute une histoire.
J’ai tellement de boulo sur Gecko que je ne m’imagine pas contribuer à Duniter v2 directement, qui est encore d’un autre niveau.
Donc le scénario de rester sur Duniter v1 encore un moment est tout à fait probable.
C’est le but recherché de s’assurer que l’utilisateur ai bien noté sa phrase.
Tu peux aussi l’imprimer via l’icone associé, et normalement (je crois) pouvoir l’imprimer dans un fichier, ce qui est mieux qu’une capture d’écran (le layout du pdf imprimé sera revu pour être plus jolie).
C’est la création du dewif qui prend un certain temps, plus qu’en rust en effet.
J’ai des versions où cette exécution se fait dans un isolate que je spawn manuellement, ce qui permet de ne pas freezer l’UI et ainsi d’afficher un icone de chargement, mais il se trouve que cela ralentie encore plus cette exécution, j’ai donc fait marche arrière en attendant de trouver mieux.
Je pense qu’il va falloir que je change de méthode de création d’isolation pour passer un peu plus bas niveau et ainsi augmenter les performances.
Ok c’est une régression il faut que je vérifie cela. Désolé je ne devrais plus partager de version non testé intégralement pour vous éviter ce genre d’expérience, mais ça risque de prendre encore un peu de temps…
C’était le cas avant mais depuis que GVA a été abandonné je suis passé en mono noeud et ne test même plus son accessibilité, c’est provisoire.
Bref il reste beaucoup de boulo.
J’ai essayé la version web et je l’aime beaucoup, la facilité d’utilisation et les temps de réponse seront sûrement améliorés (j’aimerais pouvoir vous aider avec le code mais pour le moment je ne peux être qu’un betatester et j’espère que je ne dérangerai pas trop).
Une chose qui pourrait aider serait de changer le mot de pass de cifrage du trusseau (5 lettres aléatoires) pour un PIN à 6 chiffres avec certaines règles (par exemple, avoir au moins 4 chiffres différents), non consécutifs… etc…
ou laisser les gens choisir un mot, au lieu de devoir se souvenir de 5 lettres que les gens oublieront sûrement et qu’ils devront regarder tout le temps sur leur portable ou sur un bout de papier… ou sinon, que les gens puissent écrire le mot… si vous considérez que ce n’est pas sûr en cas de vol de l’appareil… je le retire
Non, non ! L’API RPC pour soumettre des documents c’est OK, pour les requêtes, passer par une API Hydra ou similaire, on est en phase.
Pourquoi pas, en fait Duniter v2 ne représentera pas beaucoup de code métier. Le plus dur, je trouve, c’est de s’y retrouver dans Substrate et Rust. Mon boulot de cadrage avec le protocole devrait aider un peu à s’y retrouver, d’ailleurs je vais commencer à publier cette semaine.
Mais donc : ne te mets pas trop la pression, laisses-en pour les autres, il est possible que les développements Duniter avancent vite une fois le cadrage bien avancé.
Salut poka et bravo pour ton boulot.
Je me permet de réagir là dessus :
Si les comptes sur Gecko n’ont pas besoin de la création du DU ou qu’on puisse faire un virement récurent automatique à partir de son compte membre dans DuniterV2, Gecko a du sens. Par contre dans les autres cas il sera surement plus contraignant de devoir passer par une autre appli pour pouvoir virer ses DU de son compte membre de temps en temps.
Concernant la toile de confiance, elle mériterait une véritable app compagnon, pour la gestion des certifs, des rappels, la correspondance avec ses contacts téléphone, etc. Mais c’est beaucoup de boulot, je pense que tu as déjà assez à faire avec la migration sur la v2.
On pourra, mais je recommanderai plus optimal: définir le compte sur son smartphone comme délégataire du compte membre.
Ça permet d’accéder directement à la monnaie sur le compte membre sans avoir à faire de virement régulier sur un autre compte, c’est plus optimal pour la blockchain car ça demande moins de traitements onchain.
Ça me semble également plus simple pour les utilisateurs: ils peuvent indiquer un seul compte sur lequel se faire payer (le compte membre), n’ont alors besoin que d’un seul profil, etc.
Il faut juste définir qu’est-ce que le délégataire/proxy de type “Smartphone” où plus généralement “WeakMachine” a le droit de faire. Sachant qu’on peut très bien proposer plusieurs choix. L’important étant que ce type de délégataire ne puisse pas certifier
J’ai bien avancé sur Gecko ces derniers jours:
On peut créer/importer des portefeuilles connectés à un noeud v2s
On peut payer et voir les soldes en live.
Je vais essayer d’ajouter un menu pour choisir un noeud custom dans l’application (pour le moment ip local en dur), de couvrir quelques tests et de publier une app avant les RML.
Très joli ! Bravo !
Vas tu utiliser la libp2p pour interroger la couche réseau de Substrate et permettre (ou pas) le choix du noeud ?
Pour le moment, je viens d’ajouter un menu dans les paramètres pour renseigner un endpoint:
C’est provisoire le temps du lancement de la gdev.
Ensuite, je ne pense pas permettre dans un premier temps de choisir un noeud manuellement, mais plutôt partir d’une liste boostrap inscrite en dur, et éventullement le choix d’un réseau Duniter (Gdev, G1, ect …)
Je me base sur ces derniers propos d’elois.
Je n’ai pas creuser plus, mais personnellement, je trouve que la solution d’une liste de noeud en ligne mise à jours manuellement régulièrement et accessible par les clients me semble très bien, en tout cas pour le moyen terme.
De puis, la lib JS de polkadot permet déjà de renseigner une liste d’endpoint auxquels se connecter.
Je ne suis pas encore bien compris ce qu’il fait avec une liste de plus d’un nœud, si il envoie les requêtes à tous les noeuds, ou au premier qui répond positif, à creuser.
Tant qu’on a pas de solution de découverte p2p fiable et simple, je pense rester sur une liste en dur puis récuépéré sur le réseau quand un outil le permettra.
Elle en choisi un au hasard, et s’il répond avant un certain timeout elle reste avec celui-là.
Ça reste du client naïf.
Si on veut un client septique/p2p, il faut utiliser le protocole pour light client qu’utilise smoldot, via l’endpoint libp2p, mais ce protocole est très complexe à utiliser, donc je recommande très fortement d’utiliser smoldot directement, qui fera le taff forcément mieux que toute implémentation que vous tenteriez vous-même, car développer par des experts réseaux spécialisés dans ce domaine depuis de nombreuses années, dont une partie des développeurs de libp2p itself!
Pour moi l’intérêt principal de l’écosystème substrate c’est justement qu’on est plus à gérer la partie réseau p2p, qui est parfaitement bien gérée par substrate et smoldot, donc je ne vais pas creuser moi-même davantage cette partie, car on a déjà un milliard d’autres truc à creuser bien plus importants.
En résumé: je recommande à tous les développeurs des client/wallet de développer des clients naïfs qui font confiance à un seul nœud, selon la stratégie suivante:
Du coup, pour l’utilisateur qui veut bénéficier d’un client septique/p2p, il lui suffit d’installer en local un light client smoldot et c’est bon.
C’est juste coté mobile qu’il faut voir si 2 app peuvent communiquer ensemble via le réseau local, je pense que ça marche sur android, j’ai plus de doutes sur iOS…
