I have finally managed to get a good chunk of time to work on the new mesh protocol I have been hinting at, currently dubbed MeshCore, and the good news is, it's coming soon! A handful of people have been giving it a shake and trying it out in the wild, and it is performing really well. Chief among those has been that UK chap, Andy Kirby, who I've discussed a lot of mesh-related issues with for well over a year now. He has been instrumental in getting projects known out there, and for helping educate people with his videos.
I won't go too deep into how MeshCore works, or its design, but this is just to let you all know that it is real and will be available soon.
At present there is an open source C++ library, which has 5 Arduino samples on how to use it, with one important sample -- an open source repeater project. The repeater can already be flashed to about 3 different LoRa boards, and that list will be growing very quickly. The library will be published soon, along with other components I'll describe here.
The other initial part of the MeshCore offering is a new v6.0 T-Deck 'Ultra' firmware, which uses the multi network profile design of the aborted 5.0 release. The 6.0 firmware lets you create multiple profiles, with Ripple and MeshCore supported.
MeshCore lets you discover other nodes via 'Advertisement' packets which are broadcast, and propagate throughout the mesh. They are digitally signed, so cannot be forged! You can opt to NOT broadcast yourself if you don't want to. It's just an easy way to discover others, and is a dead simple way to exchange public encryption keys with each other.
Probably the biggest thing about MeshCore, though, is it's a hybrid routing/flooding protocol, and seeks to use whatever works the best.And, it's fast! I really believe this will scale to very large mesh sizes.
Like the R2 system (my previous attempt), MeshCore will rely on good repeaters. By default, mobile devices will be 'edge' nodes, and not re-transmit mesh traffic. Repeaters should typically be stationary, mounted at high elevations, or on roofs, etc. The repeaters are owned and monitored by whoever wants to run one, and they will have ways to influence routing policies through their node. Over time, if some abuses are discovered that are detrimental to the mesh, repeater owners can effectively demote kinds of traffic, and effectively give time penalties to nodes that aren't 'playing nice'. I believe the mesh can evolve, over time, in a democratic manner. And no single organisation owns or controls it!
The protocol has a number of use-cases already built in, the main one being text messaging/chat. The T-Deck firmware provides quite a nice chat/conversation experience, but anyone is free to write their own chat clients by following the 'simple_secure_chat' example in the C++ library.
The MeshCore C++ library automatically encrypts everything, so client apps don't have to worry about that, but everything that goes over the air is encrypted. For DM chats with another user, the packets are encrypted using ECDH (Elliptic Curve, Diffie Hellman) in the popular x25519 'curve', and then using AES128. Group chats are AES128 encrypted, with pre-shared symmetric keys.
The protocol also supports telemetry packets, generic request/response data (for server-like applications), and more.
Like I have previously described, I will be developing commercial, closed source MeshCore products, like the new v6.0 T-Deck firmware, but will be continuing to improve the underlying open source 'engine'. I hope to see other developers innovate, and make 3rd party offerings like a web flasher, or a web-based chat application with USB-attached LoRa board. There are many possibilities, and I mostly just enjoy doing the standalone device firmwares, like the T-Deck (and some other cool stuff LilyGo are bringing out soon!)
OK, that's it for now. There's a lot more to describe, but it will have to wait. Still a bunch of things to prepare and finish off before the official launch.
--Scott Powell.