"Fiches de pair" de datapods

Nodes Datapods
1

@kimamila a posé la question du scan réseau pour les datapods. La libp2p y répond partiellement puisqu’on peut récupérer tous les pairs qui écoutent sur un topic pubsub. Mais on n’obtient que des endpoint p2p, constitués d’une multiaddress avec un peer id (clé publique). Il manque un moyen pour les clients d’obtenir l’endpoint graphql des datapods qui en ont un. Pour cela on pourrait l’annoncer parmi les addresses du nœud kubo : scripts/configure.sh · d36aa2f92fca21a8354ff18959c1a7bb42a3feeb · nodes / Duniter Datapod · GitLab

# configure the addresses to announce
ipfs config Addresses.Announce --json "[
    \"/dns/$KUBO_DOMAIN/tcp/4001\",
    ...
    \"/hasura/dns/$GRAPHQL_DOMAIN/tcp/443\",
]"

Il suffirait alors de filtrer les addresses connues pour les pairs qui écoutent sur le topic en sélectionnant celles qui commencent pas “/hasura/”. Je ne sais pas si c’est propre, mais au moins c’est simple.

2

Quand tu configure une annonce, c’est envoyé a chaque inscription à un topic PubSub, c’est bien ca ?

3

Non, les addresses annoncées sont un réglage statique au démarrage du nœud. Quand un pair établit une connexion, il récupère ces adresses, les stocke, et les partage pour que d’autres puissent établir une connexion.

→ https://github.com/ipfs/kubo/blob/master/docs/config.md#addressesannounce

C’est vraiment une fiche de pair utilisée pour se connecter aux autres nœuds p2p.

4

ok compris.
Ca me parait une bonne solution, du coup. Simple et efficace

5

Euh, du coup il vaut mieux utiliser AppendAnnounce non ?
comme cela les réglages standards peuvent être auto-générés dans Announce

6

En fait le fichier configure.sh que je pointe est intégré directement dans une image docker : Dockerfile.Kubo · main · nodes / Duniter Datapod · GitLab de sorte que la personne qui installe un datapod n’ait rien à configure d’autre qu’une variable d’environnement dans un docker compose : docker-compose.prod.yml · main · nodes / Duniter Datapod · GitLab.

Mais effectivement, si quelqu’un veut customiser la configuration de son nœud, il pourra créer un volume comme suggéré ici et utiliser AppendAnnounce. Mais ce champ existe surtout pour customiser une configuration automatique par exemple avec de la détection automatique d’ip. Alors que là on sera plutôt dans un cas où on disposera de dns.

7

J’ai fait un petit script pour tester cette idée :

  const peers = await kubo.swarm.peers()
  for (const p of peers) {
    for await (const evt of kubo.routing.findPeer(p.peer)) {
      if (evt.type == RoutingEventTypes.FINAL_PEER) {
        const e = evt as RoutingFinalPeerEvent
        for (const a of e.peer.multiaddrs) {
          const astr = a.toString()
          if (astr.startsWith('/dns')) {
            console.log(astr)
          }
        }
      }
    }
  }

Ça permet bien de filtrer toutes les multiaddresses des pairs qui commencent par /dns. Donc on pourrait a priori faire pareil pour une multiaddresse custom comme /duniter/datapod. Ça permet la découverte réseau en utilisant le réseau IPFS. Il y a peut-être moyen de faire pareil dans la couche p2p de substrate, mais c’est un peu plus d’efforts de creuser dedans.

1 Like