J’ai passé beaucoup de temps à optimiser la découverte réseau des nœuds RPC et indexers côté lib durt2 à ses débuts.
Je pense avoir trouvé, à l’époque, un bon compromis entre résilience en cas de perte significative du réseau et vitesse d’initialisation d’une connexion.
Mais avec le recul, je pense que tout ce mécanisme est sur-ingénieré, peu économe et inutilement complexe.
Même dans un réseau décentralisé, tant que ce réseau n’est pas distribué à 100 % dans chaque client, il me semble sain de pouvoir s’appuyer sur des nœuds de référence co-maintenus.
Les apps pourraient facilement faire confiance à ces nœuds et en ajouter d’autres en fallback.
De toute manière, même avec une découverte réseau, il est nécessaire d’avoir au moins un nœud bootstrap fonctionnel en cache pour débuter la découverte, quel que soit son format (p2p, rpc, etc.).
Les nœuds Duniter partagent déjà leurs endpoints connus via une requête RPC.
Avec ces simples éléments, je pense qu’on peut considérer une app comme robuste même si elle n’implémente pas de découverte réseau, avec fallback vers le noeud suivant si la chaine est bloqué ou inaccessible, ce qui correspondant alors a un mode dégradé relativement rare mais à considérer.
Je dis ça de manière générale, à destination des développeurs d’apps, afin de ne pas créer de freins à l’entrée inutiles.
Les mécanismes de découverte réseau restent intéressants, mais ils sont à mettre en balance avec le coût en complexité et en ressources côté apps que cela engendre, même si c’est optimisé et même si cela se passe en background.