Why LoRa Relay Chat? An honest comparison
Both Meshtastic and MeshCore are good at what they aim at. LoRa Relay Chat aims somewhere else. This page is transcribed from the repo’s normative comparison doc and the engineering deep dive, and it keeps their rule: honest positioning, because both communities will read it. Where LRC is behind, this page says so.
The table
Section titled “The table”| Meshtastic | MeshCore | LRC | |
|---|---|---|---|
| Primary goal | off-grid mesh messaging | leaner off-grid mesh, clean roles | chat network at scale, off-grid capable |
| Client app | custom apps + protobuf API | custom apps | any IRC client, unmodified |
| Routing | managed flood | flood discovery → direct paths | registration + directed paths; flood for discovery only |
| Wide-area transport | MQTT broker (central) | — | router federation over peer TCP, no broker |
| Identity | node id (+PKC channels) | Ed25519 key | Ed25519 key is the identity; multi-device shared keys |
| Message privacy | encrypted channels | encrypted | plaintext by policy, signed/attested (tiered: tags + checkpoints) |
| Group chat | encrypted flood channels | room servers (separate role) | router-sequenced channels, federation merge, gap backfill |
| History/recovery | none (best-effort) | room server timestamp sync | sequence numbers + ranged backfill; join scrollback |
| Roles | ~10 device roles | separate firmwares per role | 2 binaries (node, router; relay = build flag) |
| Loss recovery | ACK + rebroadcast | ACK + retry | seq/backfill + ACK; network-as-WAL |
| Multi-speed RF | one preset per mesh | one preset | lane plans: concurrent presets/frequencies, probing, burst lanes |
| Bulk transfer | no | no | DCC over burst lanes |
| Linux native | portduino port | — (firmware focus) | first-class lrcd router/daemon |
Sources: meshtastic.org and the Meshtastic firmware source, meshcore.co.uk and the MeshCore repo, and LoRa Relay Chat’s own docs — which include the places where the docs say “designed, not yet built.”
What LoRa Relay Chat consciously gives up
Section titled “What LoRa Relay Chat consciously gives up”Confidentiality. Meshtastic and MeshCore encrypt; LRC’s charter is public plaintext chat with verifiable origin — Identity spells out exactly what the 8-byte tags do and don’t prove. If you need private communications, use those projects. Different tool, and this is a genuine reason to choose them.
Serverless purity. LRC has infrastructure — routers. That’s the
point: infrastructure is what lets tens of thousands of users converge on
one #channel without melting the spectrum. But it means someone runs the
routers, and a network with roles is more complex to operate than a flood
mesh where every node is identical.
Protocol compatibility. LRC does not interoperate with either mesh on the air. It coexists politely — the frequency planner dodges every Meshtastic modem preset and three coordinated MeshCore metro channels with guard bands, by design — and it gratefully reuses their published lessons (pin maps, sleep mechanics, retry constants), credited in the docs where used.
Where LRC is honestly behind
Section titled “Where LRC is honestly behind”Credibility is the strategy, so here is the uncomfortable column:
- Ecosystem and maturity. Meshtastic has years of field deployment, dozens of supported boards across three chip families, polished iOS and Android apps, an MQTT ecosystem, and a large contributor community. MeshCore has shipped apps, a hardware store, and a real user base. As of this writing LRC is pre-1.0 with two boards verified on hardware (a third compiles but is untested), no published release yet, and no community to speak of. If you want something proven at scale today, that isn’t LRC yet.
- Phone-first users. “No app” is the pitch, but if your daily driver is a phone, an IRC client is a thing you’d have to choose and install there — the zero-install story is strongest on laptops and SBCs. Meshtastic’s and MeshCore’s phone apps are genuinely better onboarding for phone-first users.
- Range-proven deployments. Meshtastic links have been demonstrated over extreme distances by a global community of testers. LRC’s over-the-air validation so far is bench-scale: two radios, registration handshake, bidirectional channel chat at US915/SF12. The asymmetric multi-SF routing — the headline innovation — is host-tested policy with the wire carriage landed, and its RF actuation is still on the bench roadmap.
- Encrypted comms, at all. Not offered, not planned for chat. Charter.
Where the architecture is genuinely different
Section titled “Where the architecture is genuinely different”Three structural claims, each grounded in the deep dive:
- No app. The IRC gateway is a real subset of RFC 1459/2812 — irssi, WeeChat, HexChat, a serial TUI, or telnet all work today. The client problem was solved thirty years ago; LRC inherits that solution instead of competing with it.
- Cellular, not flood. Clients register to routers; routers sequence channels and federate over TCP or RF. Steady-state traffic never floods. That’s why history, gap-healing and netsplit recovery are possible at all: a sequenced stream can be audited for holes; a flood cannot.
- Asymmetric multi-SF routing. Forward and return legs of a LoRa link are physically different problems (the hilltop router reaches you fast; you reach it back slow, if at all). LRC measures per-direction link quality and picks the return lane that maximizes delivery-probability-per-airtime. No other LoRa mesh stack models this.
Choose them, honestly
Section titled “Choose them, honestly”- Choose Meshtastic if you want the mature ecosystem: encrypted channels, phone apps, huge board support, an established community.
- Choose MeshCore if you want lean flood-mesh comms with clean roles and polished apps.
- Choose LoRa Relay Chat if you want public, signed, IRC-native chat that behaves like infrastructure — sequence numbers, scrollback, federation — and you can live with a pre-1.0 project that publishes its own wart list.