I think the plan is to have multiple channel support, hopefully simultaneously. Last I heard the idea was to keep a single NodeDB, but I think the specifics are still in early stages
1 Like
Yes, I really need to do a long much cleaner write-up about how the current mesh protocol works and options we should consider as we go forward. The short write-up in the docs directory is pretty incomplete. It is basically a bog-simple implementation of a subset of the standard DSR RFC but with the addition of (naive) flood routing.
I’ll also include a link to the spreadsheet I used when planning the current implementation. My expectation is that “up to 30 nodes on a channel should be pretty usable” and “definitely 100 nodes would be unusably big.” This is largely based on the use-case for 1.0 (“a pretty secure, cheap, long battery life, longish range mesh gps communicator for small groups”)
As we go forward we can make protocol changes based on demand and planning - probably most lining up with major releases. Also, one of the high priority work items (IMO) post 1.0 is better simulation support. I’m sure we’ll have a thread to decide what we want to do 1.1/1.5. Possible improvements include ideas include full DSR for unicast, making our naive flood router less naive, modelling mesh comms (store and forward) as a distributed DB unification problem, QMesh, Reticulum etc… Each one of these options has pros/cons and there are a lot of really great papers to read and discuss.
Also: the constraints/opportunties with longish range radios like we use are different than wifi/ble mesh. Really - for most topologies, with only a few nodes you can cover quite a bit of area and you really don’t want nodes that have great line-of-site to be getting stomped on by nodes with a crummier place in the topology.
But just to set expectations: lora (at least the way we use it to get surface 12kmish ranges) is very slow, and by design (for good reasons) we have one radio per node. So even after we optimize the protocol, you won’t be ‘wiring up towns with this stuff’ 
(IMO)
As much as I would love to see Signal integration, I can’t help but see a lot of potential issues at the moment.
Signal as a service has been pretty resistant to any federation of it’s service up to this point. Moxie talks about this here: https://signal.org/blog/the-ecosystem-is-moving/
Another issue is the overall size of the messages and “chatty” nature of the Signal Protocol. There is a lot information that needs to be exchanged even before a message between two clients can happen. Then you have to also make ensure the keys are always in sync between two endpoints trying to talk.
Breakdown of the protocol flow:
There is the issue of generating and storing lots of keys which probably won’t work well directly on embedded systems. Maybe if implemented on mobile phones this is less of a concern.
Double-ratchet, perfect forward secrecy and “future secrecy” are amazing but much harder when you have to consider a simplex radio network that has to contend with traffic congestion.
I like what Mark Qvist has been doing with Reticulum in regards to the security and still making the system work on an RF network.
I also have to say I love what you guys are doing on meshtastic. I am having a blast with it at the moment.
A group of us are attempting to get ATAK to run over it.
Thanks for making that possible.
1 Like
Just came across the previous threads discussing Signal. Didn’t mean to rehash the old threads here.
I wish I had read those first.
I had no idea that Meshtastic grew out of the intention to make an offline capable signal compatible client.
Glad we a share a love for Signal/security though !
1 Like
I’ve been looking at Matrix since it was brought up in this context. I’ll not pretend to understand the underlying protocols and crypto, but I found their founder’s discussion of their attempts to get matrix to work with low overhead at lower bitrates was interesting.
[PDF] 2019-02-03 FOSDEM Low Bandwidth - Matrix.org
TL;DR:
- ~90 bytes (inc headers) + 16 bytes of crypto overhead.
- 8 seconds to send a message at 100bps
Upon further examination, a lot of the low ratings in the Play Store stem from one of the following:
- Bad signup experience
- Delays when using matrix.org servers
They have made steps to resolve both of these, and my experience registering and installing accounts with their Riot app and their dev version, RiotX, was fine.
But Meshtastic wouldn’t necessarily bump into either the signup or issues specific to matrix.org even if they still were issues.
Their goal is to replace telephone networks globally, so wiring up whole towns is part of their deal.
1 Like
btw - I exchanged emails with a matrix person and they mentioned the low reviews of their old android app. Apparently their plan is to remove that app from the playstore real soon now, and just tell everyone to use RiotX (which I agree - seems solid)
1 Like
Personally was looking into the project and it was the first thing I searched. Wanted to jump in to say ive been using the Matrix protocol for 4 years and it has served me really well. I am less familiar w/ the LoraWan protocol or mesh networking in general, but I thought i would mention that the Matrix protocol has a reverse proxy service called pantalaimon that is meant to handle E2EE for 3rd party services. This may actually handle alot of your work load as far as encryption goes, but im not sure how optimized would be for the low bandwidth+forward error correction restrictions of the Lora protocol.
1 Like
thanks for that link. btw an update:
The matrix devs were super kind and put me in touch with someone that has already made a Matrix to MQTT based bridge. So I suspect (once this work starts) I’ll probably use and extend that bridge (to make it secure) and come up with some sort of bidirectional gateway between matrix and any meshtastic nodes.
2 Likes
well, we ported WIFI to NRF52840 using the WIFININA.
We ported too ESP32 AT and ESP8266 AT commands too.
And ethernet enc28/wiznet
No NRF52840 make internet cloud access
let me know if interested!
1 Like
Hi. New to the forum. Have you considered trying to use Briar (https://briarproject.org/) over Meshtastic instead of a central server based solution? Since Briar is P2P and already can pass messages via internet, bluetooth, or wifi it seems like it’s a good candidate to pass messages via Meshtastic.
2 Likes
hmm - looking at briar those features seem to match what the built in meshtastic app already provides. I think the appeal adding an optional internet gateway is so “whenever some member of your mesh happens to connect to the internet, it will magically send/receive messages to/from any internet user”
5 Likes
Looks like someone at the Briar project already checked out this project. https://code.briarproject.org/briar/briar/-/issues/1742
I think the appeal of Briar would be the added security, plus it’s already sort of a connection agnostic mesh anyway, it does store your friends’ messages and send them over internet (or whatever service) when connected. Obviously Signal is much more user friendly since it’s tied to phone #s but it would be nice to have the added security without relying on connection to the internet. For an inreach replacement the added security isn’t as much if a concern
Downside of Briar is that since it doesn’t have a central server it has to run in the background on your phone which drains battery faster, although they are talking about having a way to set up a helper device to do the message reception to take the burden of your phone app (LoRa device could be that?)
2 Likes
Yes, I messed around with Briar a bit a couple years back. The draw for me was that it would work over WiFi if there was no internet.
Might be an advantage in scenarios where devices which are close enough to use wifi could decongest the LoRa network by sending messages on the other interface (which is already in the ESP32s, and not being used for much).
This would likely become more significant if the Home Assistant (MQTT, etc.) integration requests are implemented, and people suddenly have 20 additional devices polling sensors over the LoRa spectrum every 15 seconds (or whatever mix of intervals).
Briar may or may not be the right solution, but conceptualizing the mesh the way they do (interface agnostic) might make sense.
4 Likes
Matrix rebranded their Riot.im client to Element.io and merged the RiotX beta.
Probably not a great idea to splinter into a thousand apps, but is it worth considering using Matrix/Element rather than, or bridged with, Slack for Meshtastic conversations that don’t fit in the forums or GitHub? I suspect I’m not the only one who’d prefer an open source alternative to Slack.
Probably too early to plan on Meshtastic service integration with Matrix as global messaging, but maybe it makes sense to take a dip for the Slack use-case to test it out. Just thinking out loud.
1 Like
yah - I kinda signed up for slack because it was quick and easy. real soonish (definitely in this next month) we will chat (probably on here and on slack) and decide what we want our first global messaging integration to be. And if riot is still looking plausible we might want to switch our dev chat over to that platform (so we could ‘eat our own dogfood’).
1 Like
The Discourse --> Chat (includes Slack and Matrix) plugin might be good intro to showing folks where the dogfood bowl is. It basically just sends forum notifications to chat clients.
1 Like
Thanks for the mention, I just saw this.
I do work for goTenna - but we have an open source initiative called ‘Global Mesh Labs’ with the mission to create an interoperable standard for incentivized decentralized messaging.
If someone is interested in adding support for another mesh device, such as Meshtastic, to the Signal App fork and python Internet gateway, I’d be happy to advise and assist.
Our ultimate goal is a mobile app that can send messages along with incentive payments to relay and gateway nodes that help deliver messages. We’re currently customizing Bitcoin Lightning node software (based on LND) for lower bandwidth/higher latency transports to enable optional incentives for relay/gateway nodes.
6 Likes
Not sure this ha been pointed out. Riot.im is now Element - Secure Messenger