LPWAN Meshes: Reticulum - Where I Landed
After years of experimenting with various LPWAN mesh networking technologies, I’ve unequivocally settled on Reticulum for my serious deployments. It emerged as the clear frontrunner not because it’s simpler than the rudimentary Meshtastic (it isn’t), nor because it’s overtly more feature-rich than the robust MeshCore (though debatable), but because its extremely well-thought-through design philosophy fundamentally aligns with what I’ve come to believe matters most: privacy, resilience, and true decentralisation in the face of an increasingly “enshittified” internet. It strongly supports multiple bearer protocols, making it an ideal candidate for a future decentralised internet.
Reticulum takes a fundamentally different approach to mesh networking. Rather than being another protocol optimised for LoRa or Sub-GHz radio, it’s a complete networking stack that can run over almost any medium—radio, wired, optical, even sneakernet. This transport-agnostic design creates possibilities that other platforms simply can’t match.

What is Reticulum?
Reticulum is a cryptography-based networking stack designed for resilient, secure, and private communication over unreliable links. It was created by Mark Qvist with a clear vision: communications should be end-to-end encrypted by default, work over any physical medium, and remain functional even when large parts of the infrastructure fail.
Unlike rudimentary solutions like Meshtastic, which treated encryption as an afterthought, or even MeshCore, which offers robust but configurable security, Reticulum puts cryptography at its very core from the ground up. Every packet is encrypted by default. Every connection is authenticated. Privacy isn’t merely an optional feature or a configuration setting—it’s absolutely fundamental to Reticulum’s design philosophy and implementation.
The protocol is deliberately minimal. There’s no blockchain, no proof-of-work, no unnecessary complexity. Just solid cryptography (Curve25519, Ed25519, AES, SHA-256) and elegant protocol design.
The Transport-Agnostic Advantage
This is where Reticulum gets really interesting. The protocol doesn’t care about the physical layer. It can run over:
- LoRa radio (my primary use case)
- Packet radio (AX.25, APRS networks)
- TCP/IP (yes, you can run a Reticulum mesh over the internet)
- I2P (anonymous routing for extreme privacy)
- Serial links (wired connections between nodes)
- AutoInterface (automatically discovers and uses available interfaces)
More importantly, a single Reticulum network can use multiple transport methods simultaneously. A node might have a LoRa interface for local communication, a TCP connection to a distant relay, and an I2P connection for anonymous routing. Messages automatically route over whatever paths are available.
This flexibility is powerful. When a bushfire takes out radio links, traffic can reroute through internet-connected nodes. When the internet fails, the radio mesh keeps working. It’s genuinely resilient.
Cryptographic Architecture
Reticulum’s cryptographic design is where it really differentiates itself. Every destination (think of these as addresses) is a cryptographic identity. The destination’s address is derived from its public key—there’s no separate addressing scheme.
This has profound implications:
Perfect Forward Secrecy
Every link uses ephemeral key pairs. Compromising one session doesn’t compromise others. This is cryptography you’d expect from Signal or WhatsApp, not from a low-power mesh network.
Cryptographic Authentication
You can’t spoof a destination because you’d need the private key. Impersonation is cryptographically impossible, not just difficult.
No Trusted Third Parties
There are no certificate authorities, no central key servers, no infrastructure to compromise. You exchange public keys directly or through a web of trust.
End-to-End Encryption
By default, always. Not optional, not something you enable—it’s how the protocol works.
For someone who’s watched IoT platforms brick devices and corporations abandon their commitments (as I discussed in my future brick article), this design is refreshing. No corporation controls the protocol. No company can decide to shut it down. No government can demand a backdoor.
Practical Implementation
Getting Reticulum running requires more technical knowledge than MeshTastic but less than a full MeshCore deployment. The Python-based implementation runs on:
- Linux systems (Raspberry Pi, desktop machines, servers)
- macOS and Windows (for development and desktop nodes)
- Android (via Termux or Sideband app)
- Embedded devices (with some porting effort)
My typical setup involves:
- Raspberry Pi nodes with USB LoRa adapters (RNode interfaces)
- Desktop machines running Reticulum as infrastructure nodes
- Android phones with Sideband for mobile communication
The configuration is straightforward—edit a TOML file to specify your interfaces and you’re operational. For my LoRa interfaces, the config looks like:
[[interfaces]]
type = RNodeInterface
enabled = yes
port = /dev/ttyUSB0
frequency = 916800000
bandwidth = 125000
txpower = 7
spreadingfactor = 8
codingrate = 5
That’s it. Once configured, the node joins the mesh and begins routing traffic.
Applications and Use Cases
What really sold me on Reticulum was the ecosystem of applications being built on it:
Nomad Network
A text-based communications system—think email and forums over a mesh network. I use this for longer-form communication when text messages aren’t adequate.
Sideband
A mobile app that brings Reticulum to Android. Send messages, share files, and participate in the mesh from your phone. It’s not as polished as MeshTastic’s app, but it’s functional and improving rapidly.
LXMF (Lightweight Extensible Message Format)
A store-and-forward messaging layer built on Reticulum. Messages don’t require both parties online simultaneously—they propagate through the mesh and are delivered when the recipient connects.
Custom Applications
Because Reticulum provides a proper networking stack (not just a radio protocol), building applications is straightforward. I’ve built custom tools for sensor data collection, file synchronisation, and remote system monitoring.
The RNS (Reticulum Network Stack) API is clean and well-documented. If you can write Python, you can build Reticulum applications.
Real-World Performance
I’ve deployed Reticulum nodes across multiple properties with LoRa radio interfaces. While the raw physical layer performance (range, throughput) with comparable LoRa settings can be similar to other protocols like Meshtastic, the fundamental difference lies in Reticulum’s intelligent routing and robust behaviour, which is vastly superior.
Range and Throughput
Using comparable LoRa settings (SF8, BW125, CR5), I achieve similar range to MeshTastic—several kilometres in good conditions. The trade-off between range, speed, and reliability is determined by LoRa parameters, not the protocol.
Routing Intelligence
Reticulum’s routing is sophisticated. It learns the network topology, measures link quality, and prefers better paths. It handles mobile nodes gracefully—when a node moves, routes update automatically.
Reliability
The combination of multiple transport paths and intelligent routing means the network stays functional even when parts fail. I’ve had radio links go down and watched traffic seamlessly reroute through alternate paths.
Security Impact
End-to-end encryption does add overhead. Packets are larger than equivalent MeshTastic packets due to cryptographic headers. For time-critical or bandwidth-constrained scenarios, this matters. For most real-world use, it’s a worthwhile trade-off.
Privacy and Anonymity
This is where Reticulum truly shines. The protocol is designed from the ground up for privacy:
- No identifying information in packet headers beyond cryptographic addresses
- Traffic analysis resistance through packet padding and timing obfuscation
- Anonymous routing when using I2P transport
- Local first design—no data leaves your network unless you explicitly route it
For anyone concerned about surveillance, corporate data harvesting, or simply wanting genuine privacy, Reticulum delivers in ways that other mesh platforms don’t even attempt.
The Learning Curve
I won’t pretend Reticulum is as accessible as MeshTastic. The documentation is comprehensive but assumes networking knowledge. There’s no “press button, send message” option.
You need to understand:
- Basic networking concepts
- Public key cryptography fundamentals
- How to configure Linux systems
- Comfort with command-line tools
The community is smaller than MeshTastic’s, though notably more technical. Questions get answered, but you’re expected to have done your homework first.
For me, this learning curve was worthwhile. I wanted to truly understand the system I was deploying, not just follow a quick-start guide. The knowledge gained has broader applicability beyond just running a mesh network.
Why Reticulum Won Me Over
After years with other platforms, here’s why I’ve settled on Reticulum:
Security Without Compromise
The cryptography is solid, well-implemented, and fundamental to the design. I trust it in ways I don’t trust security features bolted onto other platforms.
Transport Independence
Being able to use multiple physical layers—LoRa for local, internet for distant connections, I2P for anonymity—provides resilience and flexibility no other platform offers.
True Decentralisation
No company owns Reticulum. No service can be shut down. No subscription can be imposed. It’s genuinely owned by the community.
Future-Proof
The protocol is stable and well-designed. Applications built today will work tomorrow. There’s no vendor lock-in, no obsolescence by corporate decision.
Philosophical Alignment
The project’s values—uncompromising privacy, resilience, and true user sovereignty—profoundly align with my own. Especially after witnessing the fundamental security and routing deficiencies of platforms like Meshtastic, and experiencing how easily IoT platforms can brick devices or corporations abandon commitments, Reticulum’s design is a breath of fresh air. This alignment of philosophy with practical, robust implementation matters immensely.
Where Reticulum Falls Short
Reticulum isn’t perfect, and honesty about limitations is important:
Steeper Learning Curve
If you want something running this weekend and you’re not technical, MeshTastic is a better choice. Reticulum requires time investment.
Smaller Community
Fewer people means fewer tutorials, examples, and third-party tools. You’ll rely more on official documentation and your own troubleshooting.
Application Ecosystem
While growing, the application ecosystem isn’t as mature as what you’d find on more established platforms. You might need to build tools rather than find them ready-made.
Hardware Ecosystem
There’s no “official Reticulum hardware.” You assemble components—a Raspberry Pi, a LoRa adapter, power supply, antenna. This flexibility is powerful but less convenient than purpose-built devices.
Mobile Support
Sideband is functional but not as polished as MeshTastic’s mobile apps. iOS support is limited. If mobile-first is your priority, MeshTastic currently has the edge.
Getting Started with Reticulum
If you want to explore Reticulum:
- Read the documentation - Start at reticulum.network
- Set up a test node - Raspberry Pi + RNode interface is the path of least resistance
- Join the community - GitHub discussions and Matrix chat are active
- Experiment with applications - Nomad Network and LXMF are good starting points
- Build something - The API makes custom applications tractable
Budget more time than MeshTastic but less hardware knowledge than MeshCore. A Raspberry Pi Zero W with an RNode interface gets you started for under $100.
My Real-World Usage
I run Reticulum for:
- Property-wide communications - Secure messaging between buildings and remote locations
- Sensor networks - Environmental monitoring with tamper-proof data collection
- Emergency communications - A resilient backup when primary systems fail
- Experimentation - Building custom applications for specific needs
For any communications—casual or critical—I have entirely moved away from Meshtastic due to its inherent security flaws and poor routing. Instead, I now strictly use Reticulum for all property-wide communications, sensor networks, and anything I consider important, valuing its robust security and reliability above all else.
The Verdict
Reticulum isn’t for everyone. It requires more knowledge, more setup effort, and more willingness to troubleshoot than friendlier platforms. But what you get in return—genuine security, true resilience, and complete sovereignty over your communications—makes that investment worthwhile.
For me, after years of exploring options, Reticulum represents the mesh networking platform I wish existed when I started. It’s what I’ll continue using and developing on for the foreseeable future.
Next week, I’ll look at the ClusterDuck Protocol—a technology that sparked my initial interest in mesh networks. While my personal journey has led me to more robust and secure platforms like Reticulum, CDP remains highly relevant for its unique target use case: emergency communications and disaster response.
Comments
Be the first to comment! Reply to this post from your Mastodon/Fediverse or Bluesky account, or mention this post's URL in your reply. Your comment will appear here automatically via webmention.
Follow this blog on Mastodon at @gaggl.com@web.brid.gy or on Bluesky at @gaggl.com