In the world of communication, mesh has slowly started to grow out of it’s niche as something radio amateurs use. It is becoming something ordinary people use on a daily basis and on a variety of devices. This is largely thanks to systems like Meshtastic, a message stack that helped make this type of off-grid communication accessible to everyone.
Mesh what?
The moment someone mentioned ‘radio’ I automatically tuned out of the conversation. As a child of the 70s and early 80s, my mind conjured up images of my neighbors garage, where an old man would spend his evenings maintaining bulky WW2 surplus radio equipment (and a huge antenna on the roof). That is how ‘radio’ looked like when i was a kid, and I honestly have not seen much of that since. I had absolutely no interest in that what so ever.
As the conversation progressed into software however, that’s when I started to pay attention, because the features that was outlined was (to be blunt) the recipe for a truly anonymous, ownerless network. One where there is no central authority or owner like we are used to with traditional internet.
And that’s when I discovered that mesh devices have little, if nothing at all, in common with the bulky old amateur radio equipment i remember. And also that mesh communication doesnt even need a radio, it runs just fine over tcp.
Community networking
First, the devices these protocols were designed to run on are tiny. Seriously, they are no larger than a pager from the late 90s that people would clip on their belt.
Secondly, mesh radio is purely digital. You can think of it as a a device designed to send sms/mms within a radius of 10-15 km (depending on device type and signal strength). So we are talking tiny devices, surprisingly long range and coverage, no service fees, and you can even write your own software for them and shape the data being sent.
Mesh radio has taken off around the world for many reasons. First there is privacy (messages are heavily encrypted), secondly there is mobility, and third is coverage. People who like to go hiking in regions without GSM coverage use mesh all the time. This allows them to communicate with friends and family within a 10-15 km radius regardless of gsm coverage.
Since the devices are small people usually just attach them to their backpack or belt, pair them with their phone over Bluetooth, and use one of the many mesh messaging apps to send text, gps coordinates and even audio.
The reason it’s called ‘mesh’ is because these devices cooperate to extend the range. If my message cannot be delivered directly to you, but there is someone between us – then my message will be sent to that device, and then re-broadcast there in order to reach you.
Message delivery can also be done over the internet. If you have wifi available or use your phone’s data, messages are no longer limited by radio range. The message will be delivered over MQTT either directly, or to a node closer to your location. Which is pretty clever.
The software, not the hardware
As fascinating as mesh hardware is, it’s not really the subject of this article. What is more interesting is: what happens if we take the software for mesh networking and use it as the backbone for chat services or data transport on the internet?
On the mesh market there are currently 3 software stacks that are popular (I am sure there are more but these 3 stick out as the most widely adopted):
- Meshtastic
- Meshcore
- Reticulum
Meshtastic is probably the software that put mesh networking on the map for non technical people. It is easy to use (no more difficult than sms), easy to flash onto a new device, and has the bulk of the userbase.
Meshcore is relatively new. As far as I can tell it was created to deal with some of the shortcomings of Meshtastic. It has smarter message delivery and optimized routing.
The final one, which is the system that caught my interest, is Reticulum. This is not just a message framework, but something that could be used to create a new type of network. In many ways it’s the building blocks of a truly anonymous ‘internet light’.
Reticulum is transport agnostic by design. It does not care how messages are delivered, as long as they are and replies comes back. So reticulum will happily work over TCP, UDP, Websocket, mesh radio, Bluetooth -and probably even carrier pigeons if you have enough of them.
Out of the box you have a mail format (or message format) built on top of the core data delivery protocol. For all means and purposes it’s email but designed to operate within a reticulum mesh.
Next there is group support, which is somewhat abused in other apps. Most apps display group content more like a feed (like a whatsapp feed or facebook feed almost), but if you look at the protocol it’s pretty clear that it was designed to mimic new-groups. You have message thread support, subject support etc. But I have yet to see a Reticulum client that implement it as such (I havent looked more than superficially so dont arreest me on that).
Another high-level protocol is Nomadnet (a.k.a ‘sites’) which can maybe resemble http but designed to be minimalistic. The standard document format is not html, but something called Micron. If you ever used a BBS back in the day and remember the console UI’s and ascii art pages — well, thats pretty much what Nomadnet pages are. The content is designed to work well over radio
Having said that, there is nothing stopping you from serving html. Opening a page ultimately resolve to a file-request. That it’s a Micron page is ultimately down to interpretation by the client and what it expects. Micron pages have the *.mu extension, but you can just as easily serve text-files, an mp3 or whatever you feel like.
Not limited to
What I find exciting about Reticulum is not so much the high-level protocols that are in place at the moment, but rather that the software-stack itself is inviting. As long as you follow and respect the underlying reticulum core protocol, you can build your own high-level protocols as much as you want.
I decided to implement the reticulum protocol in Object Pascal and do a little experiment. Without looking at the other clients, how would I interpret the protocols purely from the documentation?
I mentioned briefly that Reticulum groups have features that mimic old-school usenet groups. These were extremely useful back in the day, and I honestly dont know why Microsoft removed support for them in Outlook. Either way, I did notice when i googled the subject that others seem to present these more like a whatsapp or facebook feed. I ended up with something more traditional.
What I ended up with is something more akin to outlook how it was in the late 90s or early 2k’s. You have mail messages, you have news groups and you have nomadnet site browsing.
Rolling my own protocol
Groups are great but have one limitation: they are only meant to be run within a relatively small region (1-hop max, meaning between you and another radio, or between you and members connected to the same hub/node). The way people bypass that is through replication nodes. Nodes that purely copy messages further so that each member can re-create the full group message-index further away.
I decided to create something called ‘rooms’. More or less the same functionality as groups, but where each message is replicated to each member. My model also introduces the group creator as ‘admin’. New members are assigned a member role when they join, but only the creator can be admin and have the right to kick members from the room.
The benefit of this model is that:
- It does not flood the network, messages are 1:1 between the members only
- Metadata is handled by the group owner’s node
- The room exists as long as the metadata is carried by a member, so even if the creator’s node is offline, the room still exists in escrow. It’s just not accessible.
- Messages appear as a chat feed, nested per-message comments is not supported. It’s meant to be X number of people talking, not specific to subject.
Adding TOR
A month or two back I did a port of TOR (with much help from Grok to deal with the C header conversion and encryption logic) to object pascal. And this seemed like the perfect spot to use that code for something interesting. So where Reticulum anonymizes your identity, TOR anonymize your IP and location.
So after much swearing and late nights, I finally got my TOR port bolted into the reticulum client, and added an option for connecting through that. And so far it has worked brilliantly. The beleth server doesnt seem to like TOR exit nodes, but im not sure if that’s something done on purpose, or if it’s an ISP refusing to forward the TOR frames.
Chat service
On the plan for the Quartex Media Desktop is a chat service. I had originally drafted a chat protocol purely for websocket, but having spent some time with Reticulum – I think we will adopt that instead. It is a perfect fit for our desktop model, it’s lightweight and easy to work with – and it allows people that use our desktop system to access a wealth of existing reticulum resources.
The reticulum client I have coded was done using native code, so we will need to port the core of this to Quartex Pascal before we can isolate it as a component. For that to work smoothly we need to get parts of the codebase we currently use to build the IDE ported first. So this will not magically appear over night.
Meanwhile, the native client might end up as a download for our customers. We have to look at what we will be doing with it.
If you like the idea of your own private network, one that you can run over mesh radio or ordinary internet, then this will be a stellar addition. You can also use it for much more than just chat. Sensor data between an outpost and a main hub would benefit from this as well. Reticulum ticks all our boxes and we really love the community behind it, they have the same creative spark that we find in the object pascal community. Where the question is not always why, but how.
Oh, and the amount of encryption in this thing is off the scales. Reticulum is designed around encryption at the very core. Your identity is a single hash + nickname, and thats it. I followed suit by making sure data-files are likewise encrypted with the same military grade encryption. So it’s pretty much bolted shut. And with no external DLL’s as dependencies – it’s going to be very difficult to breach privacy in any meaningful way.