Network Status Contact

Mesh Projects Comparison

Analyze the differences between Meshtastic, MeshCore, Reticulum and MeshCom. Detailed comparison with technical criteria and sources.

meets/true does not meet/not the focus
Criteria
Meshtastic
MeshCore
Reticulum
MeshCom
Pure mesh topology (non-hierarchical)
Whether any node can forward packets without fixed roles.
Non-hierarchical mesh with managed flood; any node can act as a relay.
Not a “pure” mesh. Routing concentrated in repeaters; clients do not repeat.
Decentralized multi-hop stack with autodiscovery and flexible policies.
Uses an APRS/AX.25-like format with MAX-HOP and a Digipeater field; any node can act as a digipeater/forwarder, plus gateways to message networks/HAMNET.
Clients relay/forward
Whether a “client” device can also act as a retransmission node.
Profiles allow retransmission (Client/Router/Repeater). Version 2.6 introduces next-hop for DMs, learning the best relay and reducing airtime.
Clients do not retransmit. Only repeaters forward, imposing hierarchy and requiring network planning.
Any node can route depending on policies and active links; the stack favors decentralized multi-hop.
Supports digipeating via protocol (path field and MAX-HOP), not requiring separate “repeater” roles.
Documented cryptography (algorithm/mode)
Whether the project clearly specifies ciphers and modes of operation.
Payload encrypted with AES-256-CTR, header in clear to allow retransmission. Official docs describe the scheme and key management.
Encryption exists (e.g., DMs and rooms), but there is no detailed technical documentation on algorithm/mode; relies on community posts and incomplete wiki.
Full E2EE with forward secrecy and authenticated ACKs; the manual details ciphers, key derivation, and security mechanisms.
No documented E2EE. Protocol based on APRS/AX.25, typically without encryption due to amateur radio regulations; site/protocol does not describe end-to-end encryption.
Store-and-Forward / history
Ability to store and resend messages until delivery or timeout.
Implements reliable retransmission with ACK/TTL: nodes keep messages until delivery or expiry. Works well in micro-communities; in dense national networks it can cause congestion, as each radio queues waiting for ACK.
Uses a dedicated Room Server that stores history (e.g., last ~16 messages) and replays to new clients.
LXMF with Distribution Net and E2EE: asynchronous delayed delivery even with offline nodes; history managed by the protocol.
Supports gateways/server, “Unified messaging” (APRS↔MeshCom) and Mailbox (BBS) — history/delayed delivery via server.
Telemetry (types, cadence and disable)
Supported metrics, configurable intervals, and how to disable/limit.
Includes a telemetry module that sends data such as battery level, channel utilization, and device state, plus environmental info. Send frequency can be adjusted and you can reduce or disable these sends.
No documented telemetry module comparable to Meshtastic. Public docs focus on Repeater/Room Server and CLI/serial operation; they do not clearly describe telemetry types/cadence or protocol-level disable. May require firmware/app-specific solutions.
Telemetry is application-level (e.g., LXMF/Sideband): can embed telemetry in messages and do store-and-forward. Cadence and enable/disable are defined by the app/service (not the stack).
Rich telemetry (BME/BMP/INA/DS18B20, etc.), dynamic compilation, APRS.fi uploads; commands to enable/disable sensors and set intervals.
Message delivery (confirmation)
Whether there is user feedback on send and delivery.
Android and iOS apps show states like sent and delivered, backed by ACKs in the protocol to confirm point-to-point delivery.
Mobile apps also show send/deliver indicators, though confirmation is based on topology and current app capabilities.
Support for authenticated ACKs in the core and LXMF/Sideband apps show detailed states (sent, confirmed, delivered).
No documented E2E ACK on RF; apps show status, and the server can resend/deliver (e.g., BBS), but there is no RF point-to-point confirmation spec.
Scalability in dense networks (airtime/collisions)
Ability to handle many nodes without saturating the radio channel.
The broadcast/flood model can cause congestion and collisions in very dense networks. Version 2.6 introduces next-hop for DMs, mitigating part of the issue.
Since clients do not retransmit, traffic is concentrated in repeaters, reducing collisions. Requires network planning for good performance.
Designed to operate in low-bandwidth and high-latency scenarios, with efficient protocols to reduce collisions and support dense networks.
Multi-hop with MAX-HOP and group filtering; gateways and BBS can reduce RF load in large networks.
Resilience in emergencies (off-grid & redundancy)
Ability to keep communications during blackouts or Internet failures, using autonomous power and local mechanisms.
Communication is 100% off-grid via LoRa multi-hop. MQTT is optional and only an extra for IP integration (e.g., apps, maps); the LoRa network works autonomously even without MQTT.
Works off-grid with autonomous solar-powered repeaters, as reported in multiple real cases. However, the hybrid architecture depends on fixed repeaters: clients do not route, so coverage requires planning. No official native MQTT backend; communication is LoRa only.
Designed for maximum resilience: operates over LoRa, radio, IP or any available medium. Fully off-grid with support for autonomous power and store-and-forward (LXMF) for offline nodes.
LoRa off-grid; can connect via gateways to HAMNET/Internet for redundancy between meshes.
Licensing / costs model
Whether the project is fully open-source or has paid/freemium features.
Fully open-source, no paid features or freemium tiers. Permissive license, active community.
OSSFree
Has premium features (e.g., some radio firmwares) with a paid license. Core is free, but extras require payment.
FreemiumPremium features
100% open-source project, no paid tiers, focused on user privacy and freedom.
OSSFree
Open-source (firmware and apps are public); no references to paid features.
OSSFree
Interoperability between projects
Ability to communicate directly over the air without gateways/converters.
Not natively interoperable with MeshCore. Meshtastic has its own protocol stack, framing, and encryption scheme.
Also does not talk to Meshtastic. Uses its own formats and roles (Repeater/Room), not compatible with the Meshtastic mesh.
Separate ecosystem (Reticulum/LXMF). Defines its own network and messaging layers; not interoperable over-the-air with Meshtastic/MeshCore.
Proprietary protocol (APRS/AX.25-like). Bridges to APRS/HAMNET via gateways, but not with Meshtastic/MeshCore/Reticulum over the air.
Roles/firmware (configuration flexibility)
How each project handles node roles and whether it requires distinct firmwares.
A single firmware with adjustable profiles (Client, Router, Repeater), configurable via the official app or CLI.
Roles separated by firmware: Repeater, Terminal Chat and Room Server have their own builds, requiring different flashes for each role ⇒ less flexible.
The Reticulum stack defines a dynamic role per node and link, without dependence on specific firmwares.
One firmware can act as client or gateway; only RAK with ETH has a dedicated gateway firmware.
Community size/adoption
Community size and activity, documentation presence and integrations.
A large and active community, with many integrations (apps, maps, gateways) and abundant documentation.
A significantly smaller community, with fewer guides/articles and adoption limited to some countries.
A more technical niche community, focused on privacy and network enthusiasts; not massive.
An active ham-radio community (site, forum, groups.io, Android/iOS apps), though smaller than Meshtastic.
Mobility support (nodes in motion)
Ability of the network to handle moving devices (cars, expeditions, etc.).
Works well with mobile nodes, thanks to flood control and next-hop for DMs introduced in 2.6. Ideal for expeditions, hiking or vehicles.
Network model favors fixed repeaters; moving clients do not route, limiting flexibility in dynamic scenarios.
Designed for harsh environments and variable mobility. The stack supports topology changes and intermittent links without reconfiguration.
Includes SmartBeaconing, GPS and mobile telemetry; messages via RF and via gateway as needed.
Tools & Operations (CLI/Apps)
Availability of official and community apps, and ease of configuration.
Official and community apps for Android, iOS and Web, plus a full CLI for configuration and operation.
Limited configuration via CLI/serial; proprietary apps are less mature. Requires distinct firmwares for each role (Repeater, Room Server, etc.).
Rich ecosystem: Sideband, NomadNet, MeshChat (LXMF) and other tools; easy integration with CLI and APIs.
Android/iOS apps, Web-installer, WebService, OTA and UDP JSON interface; node commands via app/serial.
Release cadence / board support
Firmware updates and variety of supported hardware.
Continuous development on GitHub and broad support for ESP32, Heltec, LilyGO boards, etc.
Active releases, with support for T-Lora C6, RP2040, Heltec V3 and others; focus on popular boards.
Hardware-agnostic: works on any common HW (LoRa, serial, radio, IP), with flexible support via drivers.
Firmware 4.x evolving; Web-installer; support for Heltec/T-Deck/RAK/ESP32, OTA and dedicated images (RAK gateway ETH).
Public density / spontaneous network
Presence of public nodes and ease of forming ad-hoc networks without prior planning.
Large number of public nodes in multiple regions, enabling spontaneous mesh formation and community roaming.
Lower spontaneous density; growth is more local or country-specific. Requires planning and fixed repeaters for good coverage.
Can operate both in spontaneous topologies and planned networks; the stack supports auto-discovery and intermittent links.
Growing ham community network (nodes, gateways and servers mapped; APRS/HAMNET integration encourages regional density).

Sources

Meshtastic
MeshCore
Reticulum
  • Manual — E2EE, forward secrecy, ACKs, latency tolerance. Manual (PDF)
  • LXMF / Distribution Net — FAQ
MeshCom
  • Project/Overview — MeshCom 4.0
  • Protocol — APRS/AX.25-like with MAX-HOP, path and digipeaters. Protocol · Firmware (GitHub)
  • Node commands — gateway, postime, sensors, etc. Node commands
  • Telemetry — dynamic compilation + APRS.fi. Telemetry
  • Unified messaging — APRS ↔ MeshCom via server. Unified messaging
  • Mailbox (BBS) — delayed delivery via server. LoRa Mailbox
  • Mobile apps — Android/iOS. FAQ App · App Store
  • Versions — “one firmware” client/gateway; RAK ETH has its own firmware. Versions

Notes: MeshCom is aimed at ham radio (APRS/HAMNET). In many countries, encryption is not allowed on amateur bands; the MeshCom site does not document E2EE on RF.
Some sources are official documentation; others are third-party articles and community discussions (identified as such) — included to record observed behavior and reported practical limitations.

Recommended use cases (summary)

Meshtastic

Off-grid Mobile teams
Expeditions, community networks, emergency.

MeshCore

Planned network Fixed repeaters
Neighborhoods/events with dedicated repeaters and rooms.

Reticulum

Resilience Delayed delivery
Extreme E2EE, LXMF, latency-tolerant.

MeshCom

APRS/HAMNET Gateways/BBS
Integrated ham networks, APRS.fi telemetry, mailbox via server.

Last update: 24/08/2025