MeshCore

P2P Infrastructure

A lightweight, open-source (MIT) C++ library and firmware ecosystem enabling multi-hop mesh networking over LoRa and other packet radios without internet or cellular infrastructure. Designed for developers building custom embedded communication systems (off-grid messaging, emergency response, IoT sensor networks, tactical communications). Optimized for long-distance multi-hop reliability, low power consumption, and ESP32-class hardware. Three firmware roles: Companion (personal messaging node), Room Server (persistent message store), Repeater (relay/router). Growing rapidly in Europe (868 MHz ISM band, license-free).

Community
Links
Visit Community

Details

License MIT License — open source, allows commercial use; community fork meshcore-open (Flutter client) also MIT
Dev Status 🔨 WIP
Dev Status Detail Active — firmware, mobile apps (Android/iOS), web client, and flasher tool all under active development as of early 2026; expanding European community
Owner meshcore-dev (Andy Kirby, primary developer / maintainer); community-driven with no institutional backing identified
Country UK (Andy Kirby; meshcore.co.uk domain)
Start Year 2024
Stack C++ (core library, ESP32/embedded); PlatformIO build system; Flutter (open-source mobile client: meshcore-open); Bluetooth Low Energy (BLE) for device-phone pairing; WebSerial (web client via Chrome); LoRa radio hardware (Heltec V3, RAK Wireless, LilyGo T-Deck)
Funding Community/volunteer — no grants, institutional funding, or commercial backing identified; Andy Kirby community Discord
Last Investigated Mar 9, 2026

Use Case Domains

Communication Platform Evolution & Sovereignty

Affordances

Works offline / mesh End-to-end encrypted

P2P Infrastructure Attributes

Origins Developed to address reliability gaps in Meshtastic for long-distance multi-hop routing; designed as a developer-focused library (not end-user platform) with MIT license enabling commercial embedding; positioned explicitly as simpler/more scalable than Meshtastic (GPLv3) and less complex than Reticulum
Database Room Server firmware: persistent message storage on-device for delayed delivery; no centralized database; distributed store-and-forward
Data Formats Custom binary packet format optimized for LoRa bandwidth constraints; text messages fragmented into small packets; GPS coordinates; device metadata (battery, signal quality)
Mobile Support Yes — official Android app (Google Play) and iOS app (App Store); BLE pairing with companion node
Web Support Yes — web client via Chrome (WebSerial API); online flasher at flasher.meshcore.co.uk; configuration tool via USB
Native Apps Official Android and iOS mobile apps; no desktop native app
Terms MIT License — permissive, commercial use allowed; no CLA required (unlike Meshtastic)
Funds No financial data available; fully volunteer-funded
Based On LoRa (Long Range radio modulation, Semtech); ISM band radio (868 MHz EU, 915 MHz US); custom lightweight routing protocol (not derived from Meshtastic or Reticulum codebase)
P2P Architecture Fully decentralized mesh — each node is peer and potential relay; three node roles: Companion (endpoint), Room Server (message store), Repeater (relay); no central server required; network self-heals via alternative routing
Overlay Network None — operates directly over LoRa radio layer; no IP overlay; no internet dependency
Content Addressing No — messages addressed by node unique address (not content hash)
Local-First Yes — fully offline by design; no internet connection required; Room Server enables store-and-forward for delayed delivery when recipients are offline
E2EE Yes — end-to-end encrypted; repeater nodes relay encrypted packets without ability to read content; only intended recipient can decrypt
Byzantine Fault Tolerance No formal BFT — mesh routing self-heals around failed nodes; no cryptographic consensus
Signature Implicit (via E2EE key pairs per node/device); unique node address for routing
Permissions MIT License — open; no access control in protocol beyond encryption (recipient-keyed); Room Server and Repeater management via Remote Management feature in mobile app
Protocol Maturity / Standardization Custom / community spec — not submitted to any SDO; MIT-licensed open implementation is de facto spec; actively evolving; no formal versioning or standardization process documented
Infrastructure Function Off-grid mesh radio networking — multi-hop LoRa message relay; emergency/disaster communication; IoT sensor data relay; tactical communication; outdoor/remote area messaging
Threat Model Designed for: infrastructure outage (no cellular/internet); surveillance/monitoring of communications (E2EE); range limitations (multi-hop relay extends coverage). Not designed for: high-bandwidth; adversarial RF jamming; quantum-resistant crypto; anonymity (node addresses are identifiers)
Volunteer / Node Model Community-run repeaters and room servers (volunteer hardware); companion nodes are user-owned personal devices; no incentive mechanism — entirely altruistic node operation
Traffic Visibility Metadata partially visible — node addresses and hop routing visible to relay nodes; message content E2EE; GPS location sharing is user-controlled (opt-in)
Active Deployment Scale Rapidly growing — European community expanding significantly on 868 MHz ISM band; US deployment smaller; specific node count not publicly tracked; dozens to hundreds of repeater nodes in UK/Europe as of early 2026