Transport Node Should Be Disabled by Default

[LinuxinaBit]

This was mentioned in #49 though seems to have been reverted at some point.

I understand wanting everything to be a Transport Node, in fact I asked Mark about the same thing here: markqvist/Reticulum#422 (comment) but as he mentioned it's just plain not good for network stability/efficiency if everyone is a Transport Node by default.

Having a large number of moving Transport Nodes is especially bad for the stability of a Reticulum network (requiring an announce frequency that simply isn't possible due to bandwidth-related limitations), and the likelihood of wasting an unsuspecting person's mobile data is also high enough to be concerning.

If you make it part of the 'getting started' flow, properly explaining what should be a Transport Node, and make the toggle immediately accessible on the settings page, it should work well enough without the downsides of having it enabled by default.

[LinuxinaBit]

Maybe call the setting "Route other people's data" or something to make its purpose more clear.

[serialrf433]

I always disable this first in the settings when i reset the app for testing.
Yes, i also vote for not having it enabled by default. If a regular user would want to be a transport node, then the user should find this function on their own in the settings.

I do not think it is a good idea to put it into the 'getting started' flow.

[torlando-tech]

Thanks for pointing this out. Indeed, there was a recent experiment of Columba at a music festival away from any cell service, and a lot of the issues encountered pointed at this. I think for my vision of having ad hoc BLE reticulum networks, there needs to be a new interface mode that more intentionally supports it. I haven't really thought through it properly, but here's what I've been pondering on:

• "Mini transport" only for select interfaces and its spawned peer interfaces (only transport traffic from BLE to BLE)
• Allow path requests (like Gateway mode?)
• Immediate (or only slightly delayed, like 5 minutes maybe) path expiry when a BLE peer disconnects (only for the paths in which that peer was the next hop)
• Request new paths from the network for these forcefully expired paths
• Immediate announce when a BLE peer connects