Track: enabling the DHT by default

[achingbrain]

Steps

1. Support DHT client mode
   • E.g. be able to make queries for content and peers
2. Implement autonat
   • To become a server (e.g. to store DHT records), we need ensure we are dialable. Autonat will give us confidence we are externally dialable
3. Support DHT server mode
   • Once we know we are dialable we can become a DHT server and store records

Each step depends on the previous but represents a stand-alone piece of functionality so will be useful when shipped.

DHT client mode

• [ ] https://github.com/libp2p/js-libp2p-kad-dht/issues/230
• [ ] https://github.com/libp2p/js-libp2p-kad-dht/issues/231
• [x] https://github.com/libp2p/js-libp2p-kad-dht/issues/232
• [x] https://github.com/libp2p/js-libp2p-kad-dht/issues/233
  • https://github.com/libp2p/js-libp2p-kad-dht/pull/237
• [ ] https://github.com/ipfs/js-ipfs/pull/1994
• [x] https://github.com/ipfs/js-ipfs/pull/3947

Autonat

• [ ] https://github.com/libp2p/js-libp2p/issues/1005
• [ ] https://github.com/libp2p/js-libp2p-kad-dht/issues/234

DHT server mode

• [ ] https://github.com/ipfs/js-ipfs/pull/2184
• [ ] https://github.com/libp2p/js-libp2p-kad-dht/issues/235

Testing

Testing will be done through interop and Testground. The interop test suite PR needs updating but will help establish an absolute baseline. More advanced testing will need to be done in Testground which will require the js-sdk being usable.

• [ ] https://github.com/ipfs/interop/pull/376
• [ ] https://github.com/testground/sdk-js/issues/16

Wrap up

• [ ] Update the spec in libp2p with learnings

[2color]

As it currently stands, I presume that we only support DHT client mode, right?

[achingbrain]

DHT server mode works, but for the time being you have to enable it explicitly with "Type": "dhtserver".

Once autonat lands in libp2p we'll be able to flip into server mode automatically.

[2color]

That's amazing! Thanks for clarifying that.

Is upnp supported by js-libp2p to map ports?

[achingbrain]

Yes, it's on by default for node & electron - if your node manages to negotiate uPnP port forwarding with your router it should start to report a public IP address a few seconds after startup.

You should ensure your node is publicly addressable in this or some other fashion before enabling DHT server mode, otherwise it'll start storing provider records for peers but they'll not be resolvable on the network as other peers won't be able to dial your node.

If you just want DHT support to find other peers and content, client mode is all you need.

[2color]

Can js-ipfs running in a browser use the DHT in client mode over a WSS connection?

[achingbrain]

Yes, and it's recommended that they only use the DHT in client mode as browser nodes aren't typically around for long enough to make good DHT servers (it should be on the order of days).

One thing to bear in mind is that although you'll get results from DHT queries in the browser, most nodes on the network are not dialable from browsers due to them only supporting TCP and/or QUIC transports so you'll probably want to set up a circuit relay or similar to be able to connect to them. This will change with the arrival of WebRTC transports that don't need a signalling server.

[TinyTb]

backlog grooming: Autonat is the next step for this.

[achingbrain]

The DHT is enabled by default in Helia - if anyone is watching this issue for updates, please see the migration guide and update as soon as possible.