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
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.
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:
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…
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.
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
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.
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.
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.
J’ai compilé sur master, ça marche bien ^^. Et j’en profite pour te rappeler le bug que j’ai toujours en saisissant le dernier mot de mon mnemonic « lawsuit » où le clavier se replie avec le « law ».
