"LoRa mesh vs encrypted messengers: which actually keeps you connected off-grid"
LoRa mesh vs encrypted messengers: which actually keeps you connected off-grid
The honest answer up front: neither wins on its own. An encrypted messenger is superb at protecting content while the internet exists and useless the moment it doesn't. A LoRa mesh works with zero infrastructure but can only carry short text and broadcasts your participation to anyone with a receiver. If your threat model includes blackout, bushfire or dead-signal hiking, you need both, because they cover each other's failure modes almost perfectly. The rest of this post shows why, with the trade-offs stated plainly.
What a LoRa mesh actually is
Meshtastic runs LoRa (long-range, low-bandwidth chirp-spread-spectrum radio) on small battery devices, in Australia on the 915–928 MHz ISM band. Each node relays packets it hears, so a chain of nodes extends coverage well beyond a single radio link; a few kilometres per hop in suburbia, tens of kilometres for a node on a ridge with line of sight (realistic range depends overwhelmingly on height and terrain). Bandwidth is the price: the in-app message cap is 200 bytes: short text and coordinates, nothing else.
Key characteristics that matter for the comparison:
- Encryption: payloads are AES256-CTR encrypted per channel, with public-key encryption for direct messages since firmware 2.5. Packet headers are deliberately unencrypted so nodes can relay what they can't read. There is no forward secrecy: if a channel key leaks later, previously captured traffic decrypts. Meshtastic's own docs say so.
- Store-and-forward: a designated ESP32 node with PSRAM can hold recent text messages and replay them when a client comes back in range: an experimental, text-only answer to "I was out of range for six hours".
- Reliability: best-effort by design. LoRa packets can be lost, duplicated or delayed; there's no delivery guarantee like TCP.
What the encrypted messengers actually do offline
Almost nothing, and this is the crux.
- Signal is the strongest everyday E2EE (sealed sender, forward secrecy, big audit track record; see our nine-messenger comparison) but it needs internet connectivity end to end. No connectivity, no Signal. Full stop.
- Session routes through an onion network of service nodes: good for metadata, still internet-dependent. Blackout, no Session.
- Briar is the only mainstream exception: messages sync device-to-device over Bluetooth or Wi-Fi when there's no internet at all, and a spare "mailbox" device can hold encrypted messages for contacts. This is genuinely valuable, but the range is phone radio range: tens of metres for Bluetooth, same room or same site for Wi-Fi. Briar is an on-site tool, not a across-the-valley tool.
So the real spectrum is: Signal (protected, online-only) → Session (protected, online-only, better anonymity) → Briar (protected, offline at metre scale) → Meshtastic (protected-ish, offline at kilometre scale, tiny payloads, weaker crypto properties).
Comparison table
| Signal | Session | Briar | Meshtastic (LoRa) | |
|---|---|---|---|---|
| Works with no internet | No | No | Yes, via BT/Wi-Fi | Yes, native |
| Effective range | Global (internet) | Global (internet) | 10–100 m | ~1–5 km/hop, more with relays/height |
| Payload | Rich media, calls | Rich media | Text, attachments | ~200 bytes text; positions/telemetry |
| Latency | Seconds | Seconds–minutes | Seconds when in sync | Seconds, or never if a link drops |
| Delivery guarantee | Yes | Yes | Yes (sync) | Best-effort |
| Encryption | Signal Protocol, audited | Session protocol, 2021 audit | E2EE, P2P over Tor | AES256-CTR channels + PKC DMs, no forward secrecy |
| Key model | Server-managed safety numbers | Server-managed | Verified per contact | Pre-shared channel key; steal a node, leak the key |
| Metadata | Sealed sender, phone-number identity | Minimal, no phone | Minimal, no servers | Packet headers cleartext; every relay hears timing and origin roughly |
| Store-and-forward | Server queues | Server queues | Briar Mailbox | Optional experimental module, text only |
| Infrastructure | Signal servers | Service nodes | None | None |
Read the metadata row twice. On a LoRa mesh, every relay node in earshot sees when a packet moved and roughly where it came from, even if it can't read the content. On a busy public mesh, participation itself is public. For most people that's fine. If your threat model is "a specific party wants to know who was communicating with whom during an event", it is not fine. That's a Briar/Signal problem, not a Meshtastic one.
Where each actually wins
Off-grid hiking. Meshtastic, unambiguously. Phones lose coverage kilometres from a trailhead; a mesh with a fixed node on the car and a T-Beam in the pack keeps position and status pings flowing for days on battery. Briar installed adds nothing unless your hiking partner is within Bluetooth range, which covers "we got separated at the junction" emergencies nicely. Run both.
Rural properties. Meshtastic. A property is exactly the scale LoRa handles: put nodes on the house, the shed, the gate. Gates left open, vehicle arrivals, water tank telemetry: this is what the protocol is for, and the first-node checklist walks the setup. Messengers don't apply because the property doesn't have (or want) coverage everywhere.
Bushfire and blackout comms. This is the case the encrypted-messenger camp gets wrong. When the towers lose power or the fibre gets cut, Signal dies with them, and historically that is precisely when communities need coordination. A LoRa mesh keeps working: it's your own radios, your own battery. But temper expectations: a mesh is for short coordination text, not reassurance, not photos, not 000. Always ring 000 first where any service exists. And a mesh only works if it was built before the emergency; a kit in a drawer during the fire is not a network. Briar earns its place here too, for two people on the same site whose phones need to sync without any network.
Protest and civil safety. Encrypted messengers win, with caveats. Real-time coordination across a city over a LoRa mesh is not realistic: payloads too small, hops too slow. But the LoRa mesh has a different role here as an out-of-band panic/status channel that doesn't touch the phone network at all (which may be congested or monitored). For content confidentiality among a group, Briar's offline sync or Signal beat anything on LoRa, because LoRa's cleartext headers and lack of forward secrecy are a real liability if radios get seized: a captured node hands over the channel key, and everything previously captured on that channel decrypts.
Family operations (the realistic one). Both, divided by job. Meshtastic handles positions and "running late, be there in 20" over the back paddock with no coverage. Signal handles everything that needs photos, a map link or an actual conversation the moment anyone is back in coverage. A family that treats the mesh as the telemetry layer and Signal as the content layer gets the best of both.
The honest limitations of LoRa mesh
Worth stating as a list because marketing elsewhere won't:
- Tiny payloads. 200 bytes of text. No images, no voice, no attachments, ever, on the standard stack.
- No forward secrecy. Documented by the project itself: compromise the channel key later and old captured traffic falls open.
- Key management is manual. Channels share a pre-shared key. Rotate it by coordinating every member. Lose a node in the field and treat the key as burned.
- Single band, shared spectrum. Everything in 915–928 MHz, every Meshtastic node and every other ISM user, shares airspace. A busy mesh slows itself through airtime contention, and interference from other devices degrades everyone.
- Mesh flooding is a privacy trade. Rebroadcasting is how coverage happens, and it means unencrypted headers propagate everywhere. A rebroadcast-mode setting can reduce this; it can't eliminate it.
- Best-effort delivery. No guarantees, no read receipts you can trust. Plan procedures around "message sent" ≠ "message received".
The Australian legal layer
Meshtastic in Australia operates lawfully under the ACMA Low Interference Potential Devices (LIPD) class licence, in the 915–928 MHz band with no licence or registration. The Meshtastic ANZ region profile caps transmit power at 30 dBm (1 W), a conservative ceiling against the class-licence conditions, and Australian practice is documented at wireless.org.au/meshtastic. Antenna gain counts toward EIRP: a bigger antenna means you may need to back off transmit power to stay compliant. Never modify firmware to exceed the limits; that converts a lawful device into an unlicensed transmitter, which ACMA acts on. And class-licensed operation carries no interference protection: if a licensed service lands on your frequency, the mesh yields.
Encrypted messengers face the opposite legal posture: the app is lawful, but the TOLA framework can compel providers, and Australia's metadata-retention regime applies to your telco. A LoRa mesh sits outside both: no carrier, no provider to compel. That is exactly why it complements, rather than duplicates, your messenger.
The recommendation: layered, not either/or
A working setup for most privacy-conscious Australians:
- Meshtastic as the always-on, no-infrastructure layer: positions, short status text, works through blackout and dead zones. Fixed nodes where you live/roam, a mobile node in the pack.
- Briar for two-party offline sync at close range: the layer that survives with zero network and strong crypto.
- Signal (or SimpleX if anonymity from the provider matters) as the content layer whenever any connectivity exists: photos, detail, media.
Test the mesh before you need it, on foot, with real messages. The failure you discover on a Sunday walk costs nothing; the one you discover during an emergency costs the exercise.
Disclosure: links to /product/ pages are our own store. Sources were live-verified at publication. This post is general information, not legal advice.*