In-browser Peer routing with DHT client not working

[2color]

Background

As a user, I want to be able to write browser-based applications that use PeerIDs, e.g. 12D3KooWRBy97UB99e3J6hiPesre1MZeuNQvfan4gBziswrRJsNK to connect to server peers (kubo) over WebTransport.

For js-libp2p to connect to a peer, it needs to resolve a string PeerID to a list of multi-addresses and establish a connection over a protocol supported by the browser, e.g. WebTransport /ip4/77.191.236.66/udp/27432/quic-v1/webtransport/certhash/uEiCHJ1wdNQ6PuWY_q1fZ1xYBk02c8P8vzYKLUB37swCD3g/certhash/uEiCdUXNMurDDZbHMsIBD-wEwuXN1xqT3LuAaS1XyLtEjVQ/p2p/12D3KooWRBy97UB99e3J6hiPesre1MZeuNQvfan4gBziswrRJsNK

This issue is blocking libp2p/universal-connectivity#1

Problem encountered

The problem is that when a js-libp2p node is instantiated with DHT client mode in the browser, and a call is made tolibp2p.dht.findPeer('12D3KooWBdmLJjhpgJ9KZgLM3f894ff9xyBfPvPjFNn7MKJpyrC2'), the response is missing the WebTransport multi addresses.

Specifically, I get:

/ip4/127.0.0.1/tcp/4001
/ip4/127.0.0.1/udp/4001/quic
/ip4/192.168.50.102/tcp/4001
/ip4/192.168.50.102/udp/4001/quic
/ip4/46.21.210.45/tcp/41752
/ip4/46.21.210.45/udp/41752/quic
/ip6/::1/tcp/4001

But why? 🙃

• I suspect it might have to do with how peer records from the DHT are parsed.
• Another suspicion is that not all multiaddrs aren't even stored on the DHT. Instead, they come from the identify protocol.
  • Is there a discrepancy between the DHT and the protocols coming from identify?
  • I can get the correct multiaddr with the kubo:

ipfs routing findpeer 12D3KooWBdmLJjhpgJ9KZgLM3f894ff9xyBfPvPjFNn7MKJpyrC2
/ip4/127.0.0.1/udp/4001/quic-v1
/ip4/46.21.210.45/udp/41752/quic-v1
/ip4/46.21.210.45/udp/41752/quic
/ip4/192.168.50.102/udp/4001/quic
/ip4/127.0.0.1/udp/4001/quic
/ip4/192.168.50.102/tcp/4001
/ip4/127.0.0.1/tcp/4001
/ip4/192.168.50.102/udp/4001/quic-v1
/ip4/127.0.0.1/udp/4001/quic-v1/webtransport/certhash/uEiC2VicD86O_HCbSJBdBTowH40qsRNOLoZsHRKUHMtVJVg/certhash/uEiCP5EPex6pTJYAvokykyQ2CKdcABpYsKmvEtMrt4_gLkw
/ip4/46.21.210.45/udp/41752/quic-v1/webtransport/certhash/uEiC2VicD86O_HCbSJBdBTowH40qsRNOLoZsHRKUHMtVJVg/certhash/uEiCP5EPex6pTJYAvokykyQ2CKdcABpYsKmvEtMrt4_gLkw
/ip6/::1/tcp/4001
/ip4/46.21.210.45/tcp/41752
/ip4/192.168.50.102/udp/4001/quic-v1/webtransport/certhash/uEiC2VicD86O_HCbSJBdBTowH40qsRNOLoZsHRKUHMtVJVg/certhash/uEiCP5EPex6pTJYAvokykyQ2CKdcABpYsKmvEtMrt4_gLkw

Reproduction: https://js-libp2p-transports-example-nextjs.vercel.app/

Source: https://github.com/2color/js-libp2p-transports-example/

Package Versions

  ├── @chainsafe/libp2p-noise@11.0.1
  ├── @chainsafe/libp2p-yamux@3.0.7
  ├── @headlessui/react@1.7.13
  ├── @heroicons/react@2.0.16
  ├── @libp2p/bootstrap@6.0.0
  ├── @libp2p/kad-dht@7.0.0
  ├── @libp2p/peer-id@2.0.2
  ├── @libp2p/websockets@5.0.4
  ├── @libp2p/webtransport@1.0.7
  ├── @types/node@18.14.6
  ├── @types/react-dom@18.0.11
  ├── @types/react@18.0.28
  ├── autoprefixer@10.4.13
  ├── blockstore-core@3.0.0
  ├── datastore-core@8.0.4
  ├── datastore-level@9.0.4
  ├── eslint-config-next@13.2.3
  ├── eslint@8.35.0
  ├── libp2p@0.42.2
  ├── next@13.2.3
  ├── postcss@8.4.21
  ├── private-ip@3.0.0
  ├── react-dom@18.2.0
  ├── react@18.2.0
  ├── tailwindcss@3.2.7
  └── typescript@4.9.5

Platform

• Chrome Version 110.0.5481.177 (Official Build) (arm64)

• Subsystem: DHT

Severity:

High - The main functionality of the application does not work, API breakage, repo format breakage, etc.

Steps to reproduce the error:

See full reproduction: https://github.com/2color/js-libp2p-transports-example/tree/main/packages/nextjs

• Instantiating libp2p https://github.com/2color/js-libp2p-transports-example/blob/main/packages/nextjs/src/lib/libp2p.ts#L22-L43

[2color]

Based on further investigation, the root cause of this problem is how multiaddrs are published to the DHT.

It seems that non of the quic-v1 multiaddrs are published to the DHT

[maschad]

Based on further investigation

Thanks for digging into this @2color , but I don't have access to that slack archive, would you be able to post a screenshot of those findings here for reference? Thanks.

[BigLep]

@maschad : the discussion is in a public channel #ipfs-chatter on Filecoin slack (which is bridged to IPFS Discord/Matrix).

[maschad]

Thanks for pointing that out @BigLep I will post a link here to the discord chat since that's a bit more accessible

@2color have you also explored whether identify and the peerstore are storing multiaddrs ? Apparently quic-v1 multiaddrs could be filtered out based on the discussion here

[2color]

have you also explored whether identify and the peerstore are storing multiaddrs ?

I haven't yet. Would love any tips on how to best debug/explore this with js-libp2p

Apparently quic-v1 multiaddrs could be filtered out based on the discussion here

Yeah that seems to be the case. There's a number of things happening here probably causing this:

• js-libp2p can only connect to nodes with a valid TLS certificate this limits the number of nodes to test with to the libp2p bootstrap nodes and preload nodes.
• 3 of the bootstrap nodes are running Kubo0.17 and one 0.18.1 (by running ipfs id QmQCU2EcMqAqQPR2i9bChDtGNJchTbq5TbXJJ16u19uLTa)

dig +short TXT _dnsaddr.bootstrap.libp2p.io
"dnsaddr=/dnsaddr/sg1.bootstrap.libp2p.io/p2p/QmcZf59bWwK5XFi76CZX8cbJ4BhTzzA3gU1ZjYZcYW3dwt"
"dnsaddr=/dnsaddr/sv15.bootstrap.libp2p.io/p2p/QmNnooDu7bfjPFoTZYxMNLWUQJyrVwtbZg5gBMjTezGAJN"
"dnsaddr=/dnsaddr/am6.bootstrap.libp2p.io/p2p/QmbLHAnMoJPWSCR5Zhtx6BHJX9KiKNN6tpvbUcqanj75Nb"
"dnsaddr=/dnsaddr/ny5.bootstrap.libp2p.io/p2p/QmQCU2EcMqAqQPR2i9bChDtGNJchTbq5TbXJJ16u19uLTa

• 0.17 Kubo nodes don't support quic-v1 multiaddrs.
• Kubo v0.18 introduced the quic-v1 multiaddrs.

---

• When connecting to the 0.18.1 bootstrap node over WSS (which wasn't working yesterday but now fixed), I am able to get the WebTransport addresses! 🎉

[p-shahi]

Issue for upgrading bootstrap nodes to newer Kubo versions: https://github.com/protocol/bifrost-infra/issues/2409

[achingbrain]

@2color I think this can be closed, right? There's no change to js-libp2p necessary here, the remote peer needs to be running kubo 0.18.x to tell you its quic-v1 addresses.

have you also explored whether identify and the peerstore are storing multiaddrs ?

I haven't yet. Would love any tips on how to best debug/explore this with js-libp2p

js-libp2p has a .peerStore property that lets you see what your node knows about a remote peer.

See the example in the jsdoc linked to for how to get that information.

[2color]

I want to verify this again today.

I also realised that this is very different to delegated routing because this lookup isn't recursive and there are likely not many other nodes the browser can connect to (only WSS and Webtransport), to find the peer record.

[achingbrain]

there are likely not many other nodes the browser can connect to (only WSS and Webtransport), to find the peer record.

That's correct, and why delegated routing exists - to ask a node that can make more connections (via tcp, quic, etc) to do the lookup operation on your behalf.

This will be less necessary over time, as more network non-browser nodes support listening on webtransport and webrtc addresses.

this lookup isn't recursive

What do you mean by "recursive" in this context?