Pro time!
1 Like
Looks great, I like the screens 
I also like the approach of adding on the more complex “channels or groups” as required, a huge percentage of users just use the defaults because it is easy and works and I don’t want to lose that
The overview is pretty complex and I can’t quite picture how it would flow through the text message app yet.
As for the terminology I like broadcast or all or everyone for the primary channel because it tells you what it does.
main ideas are pretty much available (though not added in the apps)
one caveat being a “permanent” public channel means everything is bound to the same LoRA settings (frequency, etc…)
another big unknown is how to deal with channels in the URL/QR code format we are using today to share them. right now you can’t join/share individual channels, it’s all one package.
Thanks @garth. Most of my inspiration came from your work, which is quite apparent. 
Ya, I agree that I think being able to add channels as needed would be very helpful, especially if you have a group of people that you only want in one channel, then you can just give them the QR code to that channel and not to all channels that you operate under. For the terminology, we can settle on anything we want, making the current primary channel obviously separate and distinct from secondary channels is the only thing that was important.
@AndreK I did wonder about the feasibility of having a “Public” channel. We basically already do, it’s just whether or not it can scale. To address the increased traffic, it may be wise to change the default public “Mesh”(primary Channel) to be medium and fast, or maybe even short and fast down the road to hopefully be able to handle more traffic. Having a limiter on amount of hops will already cut down on public traffic as a message can only travel so far, though I think we may want to increase the default hops to 4 to make a public mesh more useful(for the time being). Other questions arise from a public mesh, like if they are all hop limited can we have an infinite number of nodes, because the message can only travel so far? (currently I thought there was a cap to the amount of network nodes, correct?) At any one time in the future a node will probably only be connected to a max of like 10 nodes but extending that 4 hops and you’re looking at a possibility of thousands of nodes within reach, at which point I would assume things would get really congested. Which maybe that’s just how a public mesh would be in certain populated areas and if you need to you can always make a different private mesh. At the current adoption rate, I don’t see this as a problem, but It definitely could be an issue down the road. Right now it would be really great to have all the current adopters using each others devices to improve network reach as there are few of us. Could we also somehow limit how often one node can initiate a new message to cut down of traffic? Wondering what options are available to address this.
Things I forgot to mention:
-Location could be shared on a per channel basis in the channel settings menu
-The icon next to the first 3 nodes in the “Mesh” page are there to show which nodes you have admin channels with, and could be selected and have options similar to the device options page that could be changed over the air. I just didn’t have time to build that page out.
3 Likes
Thank you @Lester for the fine work.
I like the screens, specially the screens about how to pick a conversation.
In my usage, the design fits perfectly the need, which is to be able to set up easily a messaging infrastructure, allowing people to share short text messages privately.
As I wrote earlier here, I would think that features should be developed on the mobile client whenever possible, because a mobile phone has plenty of power and memory, plenty of screen size and UI capabilities, has plenty of readily usable library (for encryption and more) and also because the number of potential contributors on mobile is greater than on the embedded lora device.
Features I would love to have :
- a way to configure a node to only route messages that belong to a whitelist of channels or recipients
- client-side users name database (the author does not chose his own name, each peer chose author name by associating user unique ID with a name in local database)
- a way to authenticate message author (I guess the way to go would be to leverage asymmetric crypto)
Cheers
Yes, that was something I forgot to mention. You can see on the Mesh page that each node has a nickname associated with it that can be changed because people won’t be using real names on a public mesh. Though are you talking about the username being separate from the LoRa device even? Is there currently any form of this? I guess if the phone is doing all the channel keys then you could have a username that travels with you from LoRa device to LoRa device. In channel settings for each channel you could have a unique identifier, that all other channel members could then rename in their phones. Getting into realms where my understanding is very limited.
Many community members have put a lot of effort recently into our stand alone device hardware and code, so the device itself and it’s text message app are likely to be how this is managed, based on contributions a stand alone communicator is way higher on the desired feature list than additional channels with encryption.
The phone apps are really just a view into a device and what it sees.
This thread is about the need, for some users, for more comprehensive features regarding private channels. We are talking about how to improve things on this matter, and hopefully we will go forward with people willing to help us.
May you help us understand the rational behind putting as much logic as possible into the radio device, and as little as possible into the client ? I am sure there are a lot of advantages of this approach, to compensate the fact that the radio device has very limited hardware capabilities compared to the phone client.
In Meshtastic everything is done on device and the assorted clients are a view into that data (or longer term record of the data than is stored on the device like messages).
There are plenty of features like maps that use data from the device and display that data on a phone where more resources are available, but the LoRa mesh, which is what meshtastic is all about is provided entirely by the devices.
Based on the feedback I get from users there is little demand for more setup complexity.
2 Likes
Just downloaded the Alpha apk (android). !Thank You! so much for the work being done on separate channels. I was unsuccessful in the past using the CLI utility. This makes it much easier and will help with our backup / emergency communications. This was the only thing holding us back from further testing.
1 Like
The DM’s? There is still no messaging on secondary channels in either phone app.
I have not read all post in this thread, but I like what you guys have worked out so far.
I like the idea of the Radio settings becoming the ‘Mesh Settings’ and the secondary channels becoming ‘Subscriptions’.
Among Mesh Settings would be the option to change sub frequency range (trying to avoid saying channel) based on Region.
What would be really cool is if the Mesh Settings could change but Subscriptions are still valid. The reason for this idea is what if I set up a group of devices for private group chats, as well as routing packets for the ‘default’ mesh settings but I have poor performance due to radio congestion so as the admin of the ‘Node Collection’ I send a command message to change an aspect of the Mesh Settings.
I hope that’s enough to at least pin this idea. I keep thinking of the FRS Radios with the 16 channels and sub groups / privacy codes. Then going to events and being able to toggle between settings for my personal activities and connecting to others at larger events like Burning Man.
A proper separation of radio (mesh) settings and talk groups (private channels / subscriptions etc.) should provide what you are looking for. 
1 Like
Some people seem to misunderstand the working of the LoRa modules used in meshtastic_nodes.
These modules are usually built around SemTech chips, like SX1276 .
All these chips are single frequency/channel, single spreadfactor and single coding_rate, which in meshtastic is called ‘modem_settings’.
This means that the chip/module cannot read,decode or retransmit LoRa-transmissions with a different modem_setting than it has been setup for.
2 Likes
Thanks all for the additional info and the routing link. Still learning.
I did manage during one CLU test to have all the router nodes with one encryption key and two mobile nodes with another key. So that the router nodes could push messages that only the mobile nodes could read. Would help with any MIM. However, I would need to rebuild it after every firmware update and it was not always stable. Looking forward to any movement towards easy secondary channels.
I agree we need more than 1 channel, i thouht it was capable of having 10 channels at 1 time! please update the fw and android apk so we can use more than 1 channel.
2 Likes
Also very interested in “secondary” channels, I’d really love the ability to have at least a Public mesh channel, and 1 or more group channels so that two groups of radio users don’t need to be bothered with each other’s chats.
1 Like
I am a newb here, but I found the double use of the term “channel” very confusing, and even more so to a person to whom I was trying to explain meshtastic.
“Channel” referring to actual RF channels makes sense, everyone gets that.
“Channel” referring to what amounts to a segregation of users makes little sense to me. Could we call those “talk groups” perhaps? Ham radio operators would get the idea right away, and it would probably at least make some sense to everyone else.
It’s a small thing but future tech writers working on the project would probably be grateful.
Talk groups makes little sense to anyone who is not a ham
Maybe not, but the “channels” designation is really confusing. Doesn’t matter much what these things are called, as long as it is unambiguous. Maybe just “groups” or “comm groups”?