Après avoir tourné un peu autour du pot, je me lance dans l’utilisation directe de la couche p2p de substrate. L’idée est d’ajouter des types de message gossip pour partager un endpoint (rpc, squid, autre…) et un mécanisme pour traiter ces messages et ajouter les noeuds au localstorage. Cela pour répondre proprement à la question Liste des endpoints.
Je commence ici dans le readme du module network : polkadot-sdk/substrate/client/network/README.md at 21930ed2019219c2ffd57c08c0bf675db467a91f · paritytech/polkadot-sdk · GitHub. La bonne nouvelle est que la plupart de ce que j’ai appris avec ipfs va m’être utile.
3 Likes
Bon, je galère vraiment avec l’architecture de substrate. Mon idée était d’ajouter une extension uniquement dans Duniter sans toucher au framework, mais c’est tellement au cœur du système que ça implique quand même de toucher à pas mal de choses.
- cli : ajouter des arguments en ligne de commande et les passer au bon endroit = facile
- service : ajouter un nouvel exécuteur qui gère cette fonctionnalité ~= ça va encore
- network config : configurer la couche réseau (
NetworkConfig, NetworkParams) = difficile à cause de l’aspect paramétrique (NetworkBackend, trait Network), pas toujours évident de s’y retrouver (NetworkService, NetworkWorker)
- gossip : traitement des messages entrants et re-partage des endpoints = difficile d’accéder au
GossipEngine à cause de la configuration du réseau ci-dessus
- notification protocol : enregistrer un nouveau protocole de notification = ça a l’air ok mais je sais pas encore trop comment ça marche derrière
- test des endpoints : tester les endpoints pour voir s’ils répondent à certains critères (réseau, synchro…) = pas forcément évident, mais au moins c’est séparé du reste
- offchain storage : stockage des endpoints connus = pas encore exploré, mais devrait être ok car API assez similaire au stockage onchain
- RPC : servir les endpoints connus via l’API RPC = pas encore exploré, mais devrait être ok sauf surprise
Au vu du temps que ça m’a déjà pris et de mon avancement, je m’interroge sur la pertinence d’en allouer une quantité supplémentaire significative (minimum trois semaines plein temps) pour développer cette fonctionnalité.
Ce serait confortable que les gens qui installent un nœud miroir ou un indexeur aient juste à renseigner l’URL prévue dans leur fichier de config, et que les clients puissent directement récupérer une liste de endpoints pré-triée via l’API RPC, mais ça me semble trop compliqué de passer par la couche p2p, je préfère envisager une solution centralisée plus simple.
2 Likes