search

meshtastic / firmware

Meshtastic device firmware
https://meshtastic.org
GNU General Public License v3.0
3.37k stars 824 forks source link

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

Closed tropho23 closed 4 months ago

tropho23 commented 5 months ago

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 commented 4 months ago

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.