Depuis longtemps, on me demande de faire évoluer Cesium pour que le noeud Duniter ne soit pas toujours celui par défaut (cad celui du fichier config.js à la racine de Cesium). Typiquement souvent : g1.duniter.org.
J’ai travaillé ces jours-ci à clarifier le code de démarrage de Cesium, avec une meilleur ordonnancement du démarrage des services. Je vais donc pouvoir avancer sur ce point plus facilement.
Principe
Au 1er démarrage de Cesium, Cesium pourrait ainsi demander à l’utilisateur de choisir un noeud Duniter. Ce noeud serait celui utiliser pour toute la session.
Voici l’algo executé :
Trouver un noeud Duniter accessible (avec BMA) :
D’abord le noeud par défaut (du fichier config.js), ou à défaut un des noeuds de fallback;
Utiliser le fichier config.js à l’avantage de partir de noeuds « réputés fiables », depuis une liste qu’on peut maintenir (exemple ici).
A partir de ce noeud Duniter, faire un scan réseau et ouvrir la fenêtre de sélection de nœuds :
Avec seulement les noeuds BMA (et éventuelle seulement les noeuds SSL, si le navigateur est lui même déjà en SSL)
Enregistrer le nœud sélectionné, pour que le service d’accès réseau l’utilise, ET aussi dans les Paramètres.
Si l’utilisateur ne choisit aucun noeud (s’il annule = « il ne sait pas ») on garde le noeud UP, trouvé à l’étape n°1.
A la prochaine session (2ème, 3ième lancements, etc.) plusieurs options sont alors possibles :
Soit on propose la même chose : choix d’un nœud, etc.
Et ceci tant que l’utilisateur n’a pas cocher une case (par exemple « Toujours utiliser ce nœud » - qui reste à ajouter dans l’écran)
Soit on utilise le même nœud que celui choisi au premier lancement. Mais cette option me plaît moins, car il se peut que, ne sachant rien de la monnaie et de son fonctionnement, l’utilisateur est choisi la première fois au hasard… Ne pas lui redemander me parait risqué…
Dans les Paramètres, tant que l’utilisateur ne choisit pas explicitement un nœud (par exemple via la case à cocher « Toujours utiliser ce noeud »), un message en rouge indique : « nœud utilisé temporairement » :
(en corrigeant le problème d’affichage avec les icones )
Ce message disparait si l’utilisateur choisi explicitement un noeud
@elois suggérait de choisir le noeud aléatoirement. Mais n’est-ce pas également risqué ?
A moins d’ajouter une option (case à cocher) « Choisir automatiquement un noeud ». Dans ce cas, à chaque session un scan est fait, et un noeud de la branche principale de la blockchain est choisi.
Une première idée comme ça à chaud serait de toujours afficher le serveur utilisé au lancement de Cesium « Cesium va se connecter au serveur toto, cliquez ici pour changer de serveur. »
Ainsi cela peut habituer les utilisateurs à cette notion de serveur, qu’il peuvent ignorer si tout se passe bien, mais qui peut être moins nébuleuse en cas de problèmes. Demander de l’aide sur un problème de serveur permet au non expert de relancer l’application pour vérifier le serveur et le changer, sans allez dans les paramètres.
Il « suffirait » de profiter de la phase de vérification de la disponibilité du serveur au démarrage (le moment où on voit le warning en cas de serveur down) pour afficher cette fenêtre d’information, qui peut se fermer automatiquement après quelques secondes (le plus convivial) ou après un clique dessus.
Je parlais de choisir un noeud aléatoire dans une liste de trusted nodes en dur.
C’est ainsi qu’on fait dans ğecko pour l’instant :
Il y a une liste de trusted nodes en dur
Au démarrage, ğecko mélange aléatoirement la liste des trusted nodes (shuffle) puis se connecte au premier, puis au second si le premier ne répond pas, etc jusqu’à tomber sur un noeud qui répond assez vite.
Jaime beaucoup l’idée, ça force les utilisateurs à découvrir cette notion de nœuds, c’est à la fois un avantage (on forme mieux les utilisateurs) et un inconvénient (c’est plus dur pour ceux qui débarquent).
Je réfléchis à implémenter un client GVA p2p dans dubp-rs-client-lib,une bibliothèque utilisée par ğcli et ğecko.
Mais je partirai plutôt sur des approches où on ne demande pas à l’utilisateur de gérer ça, la sélection se ferait pour lui (dans ure liste de trusted nodes) où alors il n’y aurait pas de sélection du tout (multi-nœud à chaque requête). Il faut que l’explore tout ça pour voir
Moi j’ai la sensation que les utilisateurs lambda s’en foutent de cette histoire de nœuds.
S’ils pouvaient ne pas avoir à s’en occuper ce serait plus simple pour eux! Il y a déjà beaucoup à découvrir dans la monnaie libre. Le coté technique est rébarbatif pour de nombreuses personnes.
Je suis d’accord, mais au fond ils ont tort de s’en foutre.
À quoi ça sert d’avoir un système décentralisé si finalement les utilisateurs ne choisissent pas à quel nœud faire confiance ?
Je suis à fond pour la simplicité d’utilisation, mais si cela implique un paternalisme trop prononcé, où est la liberté de l’utilisateur ?
C’est un dilemme compliqué, mais la décentralisation n’est réelle et effective que si les utilisateurs ont la liberté de choisir leurs nœuds de confiance
Un bon compromis me semble être :
une liste de trusted nodes remplie par défaut par les dev mais modifiable par l’utilisateur dans les paramètres du logiciel client.
Le logiciel client se débrouille avec cette liste de trusted nodes pour choisir le ou les nœuds à qui envoyer des requêtes et ne fait pas chier l’utilisateur si le noeud choisi ni répond pas, il utilise automatiquement un autre noeud de la trusted liste.
Ça permettrait à l’utilisateur de dire en une seule fois : « voici la liste des nœuds en lesquels je fais confiance », puis de laisser le logiciel gérer sans avoir à embêter l’utilisateur avec des problèmes de nœuds down.
Évidemment, cela ne fonctionne que si la liste de trusted nodes contient toujours au moins un nœud up, c’est pourquoi il en faut un nombre suffisant (au moins 4 où 5).
Et pour répartir la charge, le logiciel client devrait mélanger cette liste au hasard, pour ne pas prendre toujours le premier, car dans la pratique beaucoup d’utilisateurs auront la même liste de trusted nodes (soit celle par défaut, soit celle fournie par leur groupe local où leur « parrain » Ğ1 où autre).
C’est le meilleur compromis que j’ai trouvé pour l’instant entre simplicité d’usage (par défaut l’utilisateur peut ignorer cette notion de nœuds) et liberté (l’utilisateur peut décider à quels nœuds il fait confiance).
Ce que tu décris là, c’est tout simplement le fonctionnement de Sakia !
Que je compte reproduire dans Tikka, quand j’aurai les Heads et les Peers dans GVA (vivement le hackathon !).
Des serveurs « root » ou « bootstrap » présents par défaut dans la config, modifiables par l’utilisateur.
Une liste « vivante » des serveurs majoritaires, dans lesquels on se connecte à un seul aléatoirement pour les données blockchain, et à plusieurs pour l’agrégation des données en mempool.
Si malgré tout ça, on est dans une partie du réseau qui est dans les choux (souvent sur g1-test…), on peut repartir sur les serveurs par défaut de la config.
Vous allez voir qu’avec des clients p2p comme ça, nos problèmes de synchro des serveurs seront bien moins impactant au quotidien, ce qui nous laissera le temps de les analyser et de les corriger.
De ce que j’avais compris de sakia en écoutant la présentation d’@inso aux RML7 il me semble que non c’est différent.
Sakia est un client 100% septique, il prend donc beaucoup de temps pour déterminer quel est le consensus réseau et tout revérifier sur plusieurs nœuds (avec une proportion de nœuds membres obligatoire).
Ce que je propose est infiniment plus simple et plus naïf, donc bien plus rapide mais pas septique.
Il s’agit bien de faire confiance à un seul nœud si ce dernier répond bien, mais s’il ne répond pas dans un délai imparti (timeout), basculer automatiquement sur un autre de la liste trusted sans rien demander à l’utilisateur.
Même avec la meilleure API du monde, un client septique sera toujours plus lent qu’un client naïf.
Ce que je propose est un client naïf multi-nœuds en round robin, afin de mieux répartir la charge ET de rendre l’utilisation plus confortable en basculant automatiquement pour contourner les aléas réseaux.
Moi je me demandais si le client ne pouvait déterminer tout seul les nœuds de confiance, et surtout les nœuds qui fonctionnent bien.
Genre envoi d’une sorte de ping à plusieurs nœuds, pour voir celui qui réponds mieux et « bien » (synchro et à jour). Ce petit « test » se ferait régulièrement genre un fois par jour ou par semaine si c’est trop gourmand.
La liste des nœuds affiché est longue, l’utilisateur n’a aucune idée de comment faire un choix. Et les conseils des « parrains » c’est toujours le même, le nœud de Bertrand va finir en surcharge…
La difficulté n’est pas pour moi de sélectionner aléatoirement un nœud, parmi les noeud de confiance (trusted node) mais plutôt être sûr que ce noeud n’est pas sur un fork… Comment le savoir sans faire un scan ?
Cela serait possible de faire le scan SANS afficher la liste des noeuds à l’utilisateur, en tâche de fond, puis de choisir un noeud aléatoirement dans la branche principale, en filtrant sur les trusted node.
Le problème est que cela ajoute une latence au lancement, sans que rien ne se passe à l’écran.
Une sensation de lenteur, finalement.
Du coup le message pourrait etre “Connexion au réseau : sélection automatique du noeud. Veuillez patientez” avec un bouton optionnem “Chosir manuellement”.
Je peux essayer de prototyper cela, pour voir ce que ca donne en terme de perception utilisateur.
Amha, le plus simple est de faire appel à la requête BMA Heads (elle te donne les serveurs connus, à jour ou pas de la blockchain), sur tes serveurs de confiance, puis d’obtenir les endpoints des serveurs qui t’intéresse avec la requête BMA Peers.
J’ai déjà expliqué le principe et implémenté cela en Python dans DuniterPy.
Ben c’est ce que j’appelle le “scan du réseau” : heads puis peers/endpoints, puis test que le EP est UP. Cesium fait déjà ainsi. Seulement les heads sont parfois mauvais (jai déjà signalé ce problème, il y a bien longtemps), il faut donc les vérifier avec un appel au block/current. On est obligé de le faire sur tous les EP, sinon impossible de savoir qui est sur la branche principale.
Mais il n’empêche que cela prend un peu de temps à fire, ce scan.
)
