Ask user if he want's to enable dht (instead of just running a client)

Is your feature request related to a problem? Please describe. Currently, the default config is using Routing.Type = 'dhtclient'. This isn’t really scaling if we onboard more and more desktop clients.

Describe the solution you’d like We should ask the user if he/she if she likes to contribute more to the network and has a stable non-metered internet connection + runs the computer usually for several hours.

Something along these lines.

This would help the network in the long run, as the desktop users get aware of the fact that they do run an ipfs node, but only using network resources.

If a node isn’t properly accessible autonat should disable the dht server functionality anyway, right?

[RubenKelevra]

@AlexxNica So I ran the test. Battery consumption is pretty low on a idling desktop on my laptop so I had to plan two days without having to use the laptop to run it - sorry for the delay.

Test procedure:

• Wifi/Bluetooth off
• 4G on with 5/5 bars signal strength
• Operating System: Windows 11
• ipfs 0.9.1 (console version)
• ipfs default settings, except turning Swarm.EnableAutoRelay on
• daemon was started with gc + pubsub + namesys-pubsub and routing overwrite depending on the test.
• freshly generated node previous to each test
• let it run 5 minutes on power supply power, to complete the bootstrapping
• started it at 2 am local time in Europe both times
• display was turned on with 60% brightness
• a webcam recorded the test and I wrote down the time when windows turned off the display
• test ran the battery down to 1%
• I stopped the Windows updates, by pausing them for one week prior to the first test
• Hardware: Intel i5-1135G7, 16 GB memory, integrated Intel graphics, NVMe storage and a 14 inch display

The first test was with dhtserver which ran 12:50 h and used 891 MB traffic.

The second test was with dhtclient which ran 13:55 h and used 661 MB traffic.

In theory there’s a Samsung specific setting to conserve a bit more power, but I haven’t used it to make the test less hardware depended.

[2color]

Removing hardcoded --routing preference sounds like a better allocation of time, and can act as a forcing function to improve go-ipfs (if needed).

Makes sense.

I’ll give this a go.