Liste des endpoints

Lors d’une discussion hier avec @kimamila, nous avons parlé de la liste des endpoints. Cela concerne à la fois les endpoint RPC de Duniter, les endpoint GraphQL de duniter-squid, des datapods, des passerelles ipfs… Et cela rejoint la discussion "Fiches de pair" de datapods.

Mon point de vue initial était que l’on pouvait hardcoder dans les clients une liste de endpoints de bootstrap “fiables” au sens où il y avait peu de chance qu’ils tombent tous en panne dans l’année à venir. L’utilisateur pouvant toujours ajouter un endpoint manuellement. Cela laisserait assez de temps pour construire une autre solution post-migration.

Mais Benoit a insisté sur la nécessité de pouvoir modifier la liste des endpoints sans intervention de l’utilisateur et sans déployer une mise-à-jour de l’application. J’ai donc re-priorisé cette tâche s’insère dans la question Oplog onchain vs offchain.


En v1, chaque nœud pouvait déclarer un endpoint dans son fichier de configuration :

$ head .config/duniter/duniter_default/conf.json 
{
 "currency": "g1",
 "endpoints": [
  "BMAS g1.trentesaux.fr 443",
  "WS2P 23456abc g1.trentesaux.fr 443 /ws2p"
 ],

Ces informations étaient partagées dans les fiches de pair et utilisées par Cesium et Kazou pour avoir une liste d’API à explorer pour sélectionner des nœuds à jour et avec un bon temps de réponse.

En v2, l’équivalent de ws2p est DUNITER_PUBLIC_ADDR, et pour rpc (équivalent
bma) il faut qu’on ajoute PUBLIC_ADDR (je m’en aperçois maintenant @Pini, → #246).

--public-addr <PUBLIC_ADDR>...
    Public address that other nodes will use to connect to this node.
    This can be used if there's a proxy in front of this node.

Reste à publier une liste de endpoint duniter-squid et datapod. Le plus efficace serait de les déclarer onchain avec un extrinsic dédié du style remark, mais qualifié, et de les stocker dans la base de données hors chaîne de Duniter via OffchainIndex. En gros, c’est là qu’on met les informations utiles mais optionnelles car non nécessaires au consensus. Il faut s’occuper de #97 et à l’occasion voir ce qu’on peut faire pour les autres endpoints.

Et ensuite se pose la question de la mise-à-jour de ces listes : comment mettre en avant les endpoints les plus fiables et retirer ceux qui ne répondent plus ou ne sont plus à jour ? Peut-être qu’un système de upvote / downvote par les membres pourrait être intéressant à implémenter dans un deuxième temps.

3 Likes

Je ne suis pas sûr de comprendre. N’est-ce pas justement déjà pris en charge par la variable d’environnement DUNITER_PUBLIC_ADDR ?

3 Likes

Oups, oui tu as raison c’est effectivement uniquement pour la connexion p2p, et il nous faut une autre manière d’indiquer le endpoint rpc. C’est ça que je cherchais et j’ai lu trop vite :person_facepalming:. “address that other nodes will use to connect to this node” ça veut dire “p2p” pas “rpc”. je trouve qu’il manque une option --public-rpc-addr ou quelque chose comme ça, mais c’est à modifier dans substrate directement, pas dans Duniter. Merci pour ta réponse :pray: :smile_cat:

2 Likes

Par contre, ils sont vraiment bouchés sur le stackexchange substrate : networking - How to declare a RPC endpoint in the node config? - Substrate and Polkadot Stack Exchange, ils comprennent pas du tout la question.