[Feature Request]: Private Primary channel with Secondary channel LongFast for new devices

[tropho23]

Platform

NRF52, ESP32

Description

Request a change to the primary channel configuration for newly flashed devices.

Note: this should NOT affect devices with channels already configured, only configure newly-flashed devices.

This has been discussed on the Discord server, with many users agreeing that since telemetry data is transmitted over the Primary channel, it makes sense to have this channel set as private, with a non-known encryption key by default. Moving the public, default/known LongFast settings to the Secondary channel ensures a few things:

1. Telemetry, specifically location data will not be inadvertently or unknowingly shared over the (current) LongFast primary channel
2. Provides users the opportunity to change & share their encryption key for private meshes (the new, private Primary channel)
3. All users can still advertise (or not, their choice) the default LongFast public encrypted settings, as the new default Secondary channel

This new primary channel requires an encryption key, ideally generated on-device (not via app) that configures two channels by default: (the new) private Primary and default LongFast Secondary. If this can be generated when the user, for the first time changes the region from UNSET to their region of choice, it is guaranteed to happen without users skipping the step or making a mistake.

We will also need to include some instructions, in the docs of course but also maybe on the webflasher site that mention that users that want to add devices to their new private Primary channel will have to use the QR code sharing method using the mobile apps, CLI, etc.

One consideration: changing a device's region to UNSET, then setting a region will trigger the 'newly flashed' scenario described above, wiping out any currently configured channels. This is an extreme edge case though, unlikely to occur without deliberate action. One way to prevent that is to check for any other configured channels besides the new Secondary LongFast.

[GUVWAF]

I would not be in favor of this, because it has various implications that leads to a bad (first-)user experience.

I agree that maybe indeed position should be set to imprecise by default, but I don’t really see how DeviceTelemetry (battery level, channel utilization, uptime) is sensitive information.

The downsides are that indeed somehow every client needs to create a way to force the user to create and share a channel before it even works.
Next, when everyone has a private primary, you will not even find new nodes unless you send a message on LongFast or someone else is doing that, because there are no periodic broadcasts there.
Besides, currently the primary channel determines the frequency slot, so to be able to talk over LongFast the automatic assignment should be removed and the default should be set to the current slot for LongFast.

[garthvh]

The problem is that this is now the first thing people are doing in pretty large numbers and it it currently kind of hard.

[GUVWAF]

I agree that that's currently hard, but can't this partly be solved in the UI by having a "public channel" option that automatically fills in "LongFast" and "AQ=="?
The only problem then is still the frequency slot. I would be fine with removing the automatic assignment based on the primary channel's name (but keeping the current default ofcourse) if that's needed, but I'd still rather keep the primary public.

[garthvh]

This sounds interesting, so it would no longer be necessary to set the frequency slot?

If doing a channel setup wizard in the app is the right way to go I am happy to do that.

[GUVWAF]

Yes, in principle we could always set it to what the hash generates with "LongFast", unless you manually overwrite it.

Downside is that if you want a private isolated network, you have to choose a frequency slot yourself.

[madeofstown]

I like the idea. Is there some kind of issue that prevents sending out node information on multiple channels?

[garthvh]

Sending anything on multiple channels means sending it twice, broadcasting to multiple channels can't really be a thing.

[aaro668]

Possibly adding to this, it would be really nice if the channel that telemetry and nodeinfo messages are sent on could be changed/customized....

[jhbruhn]

IMO this would be nice for every module. E.g. telemetry might be fine for the default channel, but Canned messages should go to some secondary channel.