Preventing confusion on channel settings

Tomorrow I’m going to change how channel names are shown in the android and device screens. I’m probably going to add a short two digit hash at the end of the channel name (i.e. channels will be shown as “#AnnesChannel-a3”). This hash will be generated with our crypto hash and will reflect any channel parameter settings as well.

The purpose of this is to make it a bit less opaque how the “automatic” channel crypto/settings/frequency stuff works. Because the current approach leads users to think “if I just tell my friend to put in #AnnesChannel” that our two nodes should be talking (which is not true, because you haven’t given the secret key). This short suffix (which the user can not edit) will implicitly indicate the uniqueness of all channels. And if you change anything fundamental (speed, name or the crypto key gets regened) that short suffix will also change. So if you see two radios and those codes match you can be sure (basically ;-)) that they are able to talk to each other.

Hopefully this will solve a “dark pattern” of the current approach. Sound reasonable? I’m happy to tweak before I implement :wink:

4 Likes

Could this tweak include a human readable element of the suffix which indicates which of the optimisations was chosen for the channel?

If I’m looking at a channel, I’d like to be reminded whether it’s short range / fast, or long range / slow.

1 Like

There could be a way to enter channel details by hand (including the crypto key)? The hash would tell, if the details were correctly defined. The hash could be separated from the channel name, if the hash had to be longer. Although, I like the short one.

That sounds sensible. So its essentially symmetric key exchange. Some explanation of how to setup multiple devices using a single phone or the Python API, or manually (as @CycloMies suggested would be good) .

good idea. I’ll try to do that also.

1 Like

good points! I’ll also add a --setchannel and --getchannel to the python command that work with those same ‘URLs’.

And btw: the reason we encode the channel settings as ‘URLs’ is twofold:

  • On android there is good support for registering a particular app to handle those urls, so that if someone shares a channel with another user, the recipient will be automatically prompted a) do you want to install this.

  • (not yet implemented but someday) On the meshtastic.org domain we can put a placeholder page up that maps to any of those channel URLs, so that if someone doesn’t have the app installed and they get the url and click on it that page can say “it looks like you have an URL to join a meshtastic mesh, click here to download the appropriate client app”

1 Like

actually the options should be called --addchannel and --getchannels so that we are ready for the ‘multichannel aware’ future.

Also - I think once multichannel is in, that might be a good way to provide the more expensive crypto options but still keep them optional. i.e. if you need one-time-pad or time expiring messages/keys that would be an attribute of that channel variant.

2 Likes