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

[RubenKelevra]

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?

[lidel]

@aschmahmann iirc we no longer need to force dhtclient because go-ipfs now does self-tests to determine if it should run in client or server mode – is that still the case?

If so, we should remove dhtclient from default config, and add it as opt-in setting, similar to pubsub or IPNS over pubsub.

[RubenKelevra]

I retested this with 0.16.0 and that's true, dht is the default now.

This might not be ideal... it only makes sense to enable this on non-mobile devices. So if you use a laptop very much mobile all the time you don't want the traffic and the reduction of battery lifetime.

As long as we cannot react to "metered" connection detection and battery/ac power and also determine how long the device is usually online at a time, it makes sense to have dhtclient as the default and just ask the user what he wants to do.

Btw: Pre-0.16.0 it was dhtclient as a default. Do we update the config? Or do have old users now a different config than new users?

[RubenKelevra]

@lidel so I propose we change that back to dhtclient as long as we cannot ask the user if this is a mainly mobile computer since we would burn too much battery life.

[AlexxNica]

Do we have any metrics on battery consumption?

[RubenKelevra]

Do we have any metrics on battery consumption?

I mean, when we're mobile it's best to do only the absolutely necessary work to avoid having the Wifi/4G module active sending packages. I think this will consume most of the power.

I'll try to run my notebook until its empty with both settings and post some numbers :)

[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.

[lidel]

Thanks! I believe MVP here is to add opt-in that changes from dhtclient to dht similar to the toggle we recently added for GC: #1740 – PR welcome :)

[RubenKelevra]

Yeah that's a nice temporary solution until go-ipfs can switch on the fly :)

[2color]

I just came across this after trying to figure out why IPFS-desktop isn't putting the DHT to server mode.

I discovered that we have the '--routing=dhtclient' flag hardcoded:

ipfs-desktop/src/common/store.js

Lines 4 to 17 in bc321a6

	const defaults = {
	ipfsConfig: {
	type: 'go',
	path: '',
	flags: [
	'--agent-version-suffix=desktop',
	'--migrate',
	'--enable-gc',
	'--routing=dhtclient'
	]
	},
	language: (electron.app || electron.remote.app).getLocale(),
	experiments: {}
	}

I'd be interested in taking this one on.

@lidel
Do we still want to add an opt-in flag in the UI to set routing to dht? Or can we change the default (seeing as the dht option will automatically switch to server)?

[lidel]

My vote is to decrease code surface of ipfs-desktop that we need to maintain, and not add more dialogs, asks, and questions.

When left alone, go-ipfs is already deciding if it should be a server or not. being smarter about defaults, adjusting them based on network conditions (e.g: v0.13 it will have automatic hole punching).

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

@2color If you open a PR that removes --routing=dhtclient from default config + runs one-time migration that removes it from configs of existing users, i'd be happy to review and coordinate with go-ipfs (if needed).

[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.