Figure out how to come up with more free time in the week
The first thing is it needs some testing and bug fixes, statistically it is essentially unused right now.
Neither me or @AndreK can even start on adding it to the phone apps until the code is tested and works, there is documentation and examples and it has been integrated in a mostly transparent to the user way into the text message app packet type on the device. The overwhelming majority of users won’t use the feature and should not have to deal with it at all.
Some of this is code, but a lot of it is going to be coordination with the devs working on assorted clients. There are also a lot of messaging features that are coming first and I think many of the theoretical use cases for for multi channel are handled by features we have that are not implemented across clients like DM’s, replies, tapbacks etc.
I very much disagree with the sentiment that most users shouldn’t or wouldn’t use secondary channels. People are primarily getting these for private backup coms. The reason no one is using secondary channels is because their useless in their current state. Nobody is communicating through nodes with their computer, they’re using their phones. Personally I think the way to simplify and improve the experience is to actually make the default “Primary” channel invisible. Most people would like to piggy back off other nodes while still maintaining their own private channel and not jumping through hoops in configuration menus or terminal commands to get it to work. Private secondary channels should be the focus, not the Primary channel (in my opinion). And then if someone wanted, they could gain access to the Primary channels settings if they so desired to change something or enable the “Public” chat through an advanced menu option. It really seems convoluted how it currently functions.
The issue is right now, as you’re pointing out, client support for secondary channels is immature
We’re a group of volunteers working on this on our free time and would love contributions to help shore up this area. As an open source project, we have a guiding principal around here that volunteers / contributors do what they are personally passionate about. This is, of course, not our day job.
Let’s find or build some momentum or designs for this. What or how would the functionality tie into the user experience?
Thank you for reminding me of the volunteer nature of this project. Sorry if my post came across as negative. I didn’t mean it to be. I am very impressed and thankful for how much progress this project has had and am amazed at the accessibility that these open source projects provide. You all are amazing! I might be able to make up some UI design ideas of how this feature could be implemented and post them for inspiration as something I can contribute.
Hi @mc-hamster, thank you for caring.
First thing I would do is clean-up the vocabulary, and possibly the code-base, so that concerns are well defined and well separated.
Current “channel” definition includes both radio settings and channel settings. It would be an improvement, in my opinion, to separate both more clearly. Radio settings are only radio settings, and define basically how to send packets through the LoRa layer, and how to listen. Channels on the other hand is a property of the meshtastic protocol, one layer above (at least). If the word “channel” is too ambiguous, let’s use “private room”.
Also, I don’t think selecting the radio sub-band based on the name given to the “channel” is a great idea. This is a fairly basic setting that most users will understand.
I think it is fine to have a default channel (private room).
I also think it could be desirable to have “non private rooms”, IE rooms that you will receive and be able to decode if you listen on the right radio settings, but I will let others discuss this feature.
“Private rooms” should provide the following desirable features :
- groups privacy
- repeater selectivity (select what channels should be repeated, don’t repeat everything so that you save bandwidth if other groups are using same radio settings, and also prevent a easy DoS on the mesh network by a bad guy)
- users should have an easy way to share 1 “private room” (basically its key) with an other user, without having to share “all private rooms”. Currently, it seems that the way to share a secondary channel is to share all of them, which is a real defect in my opinion.
On the user interface design, there is plenty of inspiration to take from the myriad of group messaging apps, such as telegram etc. In my opinion, nothing fancy is required, basically 1 tab per “private room”, sorted by most recently used rooms, and this is perfect.
I would really, really love to see that implemented, and if I can help please let me know how.
Maybe we can do some ux rapid prototyping around this and then we can rally people on a call or or zoom or whatever … to shoot darts at the prototype, talk about what would work, what won’t work and then iterate on the prototype.
We have the backend done but no North Star to guide how the user interaction would work. Unlike many things here, this is something that will need to be closely coordinated between a lot of applications and having a clear North Star would help.
@Eagle I agree about the channel naming confusion. I think the backend radio settings should definitely be kept separate. Also, thanks for pointing out that a DoS attacks could be very damaging to a public node network. I wonder if we could build in some kind of protection for this, but that’s for a different discussion. @mc-hamster, I think a call is an excellent idea, and would love to be involved if I may. I can build out some ideas of how the UX could work and maybe even throw together some app page designs for reference.
The only “public” mesh network we have now is the one setup by the default device configuration and that’s only because the crypto keys for that are distributed with the firmware. Even with secondary channels, there really isn’t a concept of a public mesh.
If you’d like to collect the information, brainstorm and work on a rapid prototype, go ahead. I’d bet there are people here who would like to participate.
Once you’re ready for the firing squad, either you could setup a gathering or we can work on that together.
Thank you all again for your fine work, greatly appreciated.
Let me know what if there is something I can do. I am also a developer, but not much experienced in android and embedded unfortunately (mostly a functional prog guy working on highly reliable network stuff). But if I can help, let me know how. Cheers
Pretty much everything I said here remains true Encryption / Secondary Channels - #5 by garth
These secondary channel / group features have generated a ton of discussion, but little contributed code and I have never received any TestFlight feedback requesting secondary channel messaging. The code to get this started is going to be testing on device and figuring out how to work with the text message app port num. Most of us are not working in the language we do at work so don’t let that stop you
@mc-hamster Sounds good. I’ll get started on some proposed ways of implementations and then I’ll initiate a meet-up by coming back to this discussion once I have something flushed out.
@garth @mc-hamster @Eagle Got some mockups I’m ready to run through if you guys are open to a virtual meet-up. Want to get some feedback before I get too ahead of myself. Let me know how we should proceed.
Post your mockups here. I need to schedule a developer check-in for progress on 1.3 and will send out a scheduler invite for that soon. Will add you to that agenda.
It’s likely going to be on a weekend based on prior availability.
Are you on our discord? It’ll be hosted as a video chat in there.
Yes, I have discord.
Here are the mockups that I made from the ideas I had about implementing what we currently call “secondary channels”. Please feel free to pick them apart. I’m not a backend person, so my ideas may be way off base, but I hope I can contribute something.
The main ideas I’m going for are these:
-Easily use neighboring devices to communicate further without sharing info before-hand
-Primary channel is now just “Mesh”
-Secondary channels are just “Channels”
-The default “Mesh”(currently default Primary Channel) is referred to as a public mesh in the hopes of using it as such. In advanced settings you can add other Mesh Presets and assign them to devices if you do not want to contribute to or utilize the Public Mesh or want more security/less traffic.
-Sharing location to Mesh and “Mesh Chat” are disabled by default.
-The preferred mode of communication is through channels or direct to another person.
-Each device can have one admin channel which allows it to have settings and firmware changes over the air. (there’s something like this in the works right?)
-Channels and their keys are stored on the phone and not the Lora device, so you can change the Lora device to a new mesh and retain all your channels. Also possibly more secure if messages are not decrypted on meshtastic device? If a router is intercepted it doesn’t contain the keys. Is this how secondary channels already work?
Below are the mockups and one flow chart that I threw some ideas onto.
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.