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)
1 Like
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.
3 Likes
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é.
6 Likes
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
3 Likes
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.
12 Likes
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.
3 Likes
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:
- Au démarrage, tester s’il y a un nœud local en requetant localhost:PORT, reste à se mettre d’accord ensemble sur le port à tester, c’est alors sur ce port qu’écouterait par défaut un light client local.
- Si aucun nœud local ne répond après un timeout très cours (genre 100ms), choisir un nœud au hasard parmi une liste en dur.
- Permettre à l’utilisateur avancé de saisir manuellement un endpoint RPC, (voir plusieurs qui serait en ajout/remplacement de la liste en dur).
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…
5 Likes
Je suis entièrement pour cette stratégie.
Je dirais même 3 noeuds au hasard parmis une liste de plus de noeud en dur, ainsi la lib JS gèrera si un des noeud tombe pendant l’exécution de l’app.
Un projet moyen/long terme intéressant serait de binder smoldot (Rust) en Dart pour l’embarquer directement dans Gecko, et ajouter un menu pour l’activer optionnellement.
Comme c’est directement en localhost, même pas sur le réseau local, je pense que ça ne devrait pas poser de problème pour des websockets, à voir.
1 Like
Je propose autre chose pour éviter :
- d’embarquer plusieurs fois smoldot dans différentes applis (Ǧecko, Césium, Wotwizard…)
- que l’utilisateur débutant attende 100 ms de trop
- que l’utilisateur avancé puisse croire être connecté à son nœud p2p local éteint alors qu’il est connecté à un seul nœud
Ma proposition est la suivante :
- par défaut, l’appli est en mode « naïf » et se connecte à un seul nœud qui répond parmi une liste prédéfinie
- l’utilisateur avancé peut activer le mode « avancé », renseigner des nœuds custom, dont un smoldot local, et si la connexion au smoldot échoue, il est prévenu, ce qui lui laisse le choix de rallumer son smoldot ou basculer sur le mode naïf
1 Like
Je suis contre cette idée, et plus généralement contre l’idée que les light clients seraient réservés aux utilisateurs avancés.
Je veux qu’un utilisateur lambda qui ne comprend rien à la technique puisse utiliser un light client, qu’on est juste à lui dire, tu installes tel programme et que ça juste marche, sans configuration manuelle à faire.
1 Like
Moi je suis pour qu’un utilisateur lambda qui souhaite utiliser un light client le fasse en deux étapes
- installation du light client
- configuration de son / ses wallets
Ça me paraît être la base de la responsabilisation : comprendre qu’un app se connecte à quelque chose.
Mais on peut aussi faire ça de manière astucieuse avec un bouton dans le light client qui mène à l’écran de configuration du wallet. Par exemple dans Android, quand tu installes Fdroid, il te mène à l’écran qui l’autorise comme source d’installation de logiciels.
Dans un premier temps de toute façon je compte pas m’attaquer à smoldot tout de suite (trop de choses bien plus prioritaires) donc ce sera liste locale directement pendant un moment.
Quand on commencera à intégrer smoldot, bindé ou non, on commencera par une saisie manuelle uniquement comme le propose Hugo, le temps de bien tester dans la durée. Puis on envisagera plus d’automatisation plus tard.
1 Like
Attention, il faut avoir en tête la réalité : tous les noeuds n’auront pas les indexeurs, et tous les indexeurs ne seront pas forcément configurer avec la même stratégie.
Il faut donc bien savoir quel noeud propose quoi.
1 Like
Bien sûr, il y a (au moins) trois API :
- les clients substrate pour soumettre des extrinsics via les libs clients
- les indexeurs pour récupérer des données blockchain indexées (solde du compte, historique de transactions, statut membre…)
- les données hors chaîne (photo de profile, commentaires de transaction…)