yep - multichannel support I bet will be a 1.1 feature (because it is pretty easy and helps users). Though we will need to be careful about the constraints on those channels (for channels you want to receive would need to be on the same frequency - so we’ll need to make that flow not confusing for the user)
Hi, I’m new, so I’ve been slowing digesting all the messages and docs to figure out what features are working and what are not. I have been playing with 2 units and it’s been fun so far.
Can you clarify that 0.9.1 does not support a unit being a repeater for the default channel for an unknown device? I wanted to know if there’s any point to leaving my unit powered-on to help others.
In Lora mesh network what do you mean by helping others?
The radios in the mesh network are all connected to each other with the group that exchange the same key, all the radios are repeaters that are part of the same group.
However it is better that you read the presentation and the project of Meshtastic, so you understand more how the mesh network works
@TitanTronics This topic was about programming a special channel that all devices are part of in addition to the private group people do their day to day chatting in.
This special channel could be very useful in an emergency. People not in the group could join in search and rescue efforts without finding someone that was in the lost persons group to share the keys.
Since I read there is already such a project, I think it will be available later. If you go around the various topics you will find information about it. geeksville talked about it here in the forum.
@DintheNorth, For now, nodes are not capable of repeating nor routing packets for other channels than one (your channel). There are both physical and logical (mesh protocol and encryption level) restrictions to be defeated, before emergency message and “multichannel” features can be enabled.
I think it is better not to intervene on the encryption of the mesh system but to create a channel and transmit the key to the public who wishes to report SOS.
Touching the encryption of the mesh system puts all users at risk.
Trust me there are so many people with bad intentions who want to read messages from groups who don’t share their information with others.
However for SOS situations you can use a cell phone instead of a mesh network that you are not sure if the message has been transmitted or not. Calling 911 or 112 is free, you don’t even need a phone sim card. it is much better to use cell phones in this case.
There are many different ways to build the emergency alert/beacon feature to the system. One of the easiest ways, regarding networking, might be to broadcast the message on the users channel with or without encryption. Another way could be to broadcast all emergency packets to a specific SOS channel.
The later could be better, if clearly specified and enabled on all nodes by default. However, the later one would require multichannel features, and the encryption part should be solved (to encrypt or not to encrypt SOS messages).
All the ways you have listed can be dangerous for users’ safety.
In this way any person can send annoying messages or block the whole network mesh with useless messages.
Spoofing would be a serious new problem.
I hope the project doesn’t go in this way because it would destroy the whole network, and I wouldn’t feel safe at all if I talk to friends in the group or talk to someone with bad intentions. Even if the intention initiative is good.
All of those functions could be optional, and configurable (for example encryption on or off). Unencrypted SOS messages (messages anyone could read) would not compromise other parts of the mesh.
Safety for an average hiker, or safety for a reporter in a non-permissive environment might mean different things: Certainty of SOS messages readability for some, and total message encryption for others.
Luckily, @geeksville, and other participants, have done a great job to make Meshtastic as versatile as possible. I feel confident the project will continue this way.