MeshCore: Companions, Repeaters, and Room Servers

MeshCore is an open-source, off-grid communication system that uses LoRa (Long Range), a low-power radio modulation designed for small amounts of data over comparatively long distances. It provides encrypted text messaging without requiring cellular service, Wi-Fi, an internet connection, or a central network operator. The project describes its core as a lightweight, portable multi-hop routing system for embedded packet radios. MeshCore official website and MeshCore official repository

MeshCore is often mentioned beside Meshtastic because both can turn inexpensive LoRa boards into independent communication networks. They are nevertheless separate ecosystems with different packet formats, routing strategies, applications, and device roles. MeshCore is not a Meshtastic add-on or a drop-in replacement.

The easiest way to understand MeshCore is to look at its three principal roles:

A companion belongs to a user and connects the radio to an application.
A repeater belongs to the network and forwards packets between users.
A room server stores shared posts so users can retrieve messages they missed.

This separation is one of the most important differences between MeshCore and a typical Meshtastic deployment.

What is MeshCore?

MeshCore supports direct messages, group conversations, node discovery, and small data exchanges over LoRa. It is also a C/C++ routing library, packet protocol, firmware collection, and set of client interfaces released under the permissive MIT licence. MeshCore repository and licence information

The radio network can operate entirely off-grid. Each participating device must use compatible radio parameters, including frequency, bandwidth, spreading factor, and coding rate. Those settings determine where and how the LoRa signal is transmitted; they do not make MeshCore compatible with another protocol that happens to use the same frequency.

MeshCore supports regional configurations for 433 MHz, 868 MHz, and 915 MHz hardware. The appropriate band and legal settings depend on the country. The official flasher is the best current source for board and firmware availability, while users remain responsible for following their national rules. Do not copy another region’s frequency or transmit-power setting simply because it works technically. MeshCore web flasher and MeshCore radio configuration reference

The MeshCore ecosystem

Role	Main job	Used directly by a person?	Relays mesh traffic?	Stores shared message history?
Companion	Connects a LoRa radio to a phone or computer app	Yes	Normally no	Not as a room server
Repeater	Extends the radio network and participates in routing	No, it runs autonomously	Yes	No
Room server	Provides a shared, store-and-forward message room	Users connect to it through their clients	Can be enabled, but separate repeaters are recommended	Yes

Companions

A MeshCore companion is the user-facing radio endpoint. The radio runs companion firmware and connects to the MeshCore application through Bluetooth Low Energy (BLE), USB serial, or, on supported builds, Wi-Fi. The application provides the screen, keyboard, contact management, map, and messaging interface. Official client and connection information

The word companion does not mean a secondary radio attached to a normal node. It is the user’s MeshCore radio; a phone or computer is its interface.

Unlike an ordinary Meshtastic client node, a MeshCore companion normally does not rebroadcast other users’ packets. The official repository explains that companions use a fixed non-repeating role so that mobile or poorly placed personal devices do not become undesirable routing paths. This gives the infrastructure a clearer shape: fixed, deliberately positioned repeaters carry the network, while personal radios remain endpoints. MeshCore routing-role description

There are also standalone MeshCore implementations for devices with screens and keyboards, including supported LILYGO T-Deck-family hardware. These can provide a complete interface without a phone. They do not change the underlying distinction between a personal endpoint and dedicated network infrastructure. MeshCore hardware and firmware FAQ

Repeaters

A repeater is a fixed infrastructure node whose purpose is to receive and forward MeshCore packets. It normally runs without a phone connection and is most useful at an elevated, reliable location with a suitable antenna and continuous or solar-backed power.

MeshCore does not simply retransmit every packet in the same manner. Its version 1 packet format defines both flood routes and direct routes. Flooding sends a packet outward through available repeaters when a route is not yet known or when a broadcast must reach the wider mesh. After a direct-message exchange discovers a usable path, later packets can include that path so the appropriate repeaters forward them toward the destination. Official MeshCore packet format

In plain language, the first message is somewhat like asking everyone in a building, “Where is Ana?” Once a route comes back, later messages can be addressed along a known chain of corridors instead of asking on every floor again. The project FAQ explains that an initial flooded message produces a return path, which is stored with the contact and can be embedded in later direct packets. MeshCore path-discovery explanation

The protocol can encode paths of up to 64 hops, but that is an implementation ceiling, not a realistic range promise. Every hop consumes airtime, adds delay, and introduces another opportunity for loss or interference. A useful network still depends on sensible repeater spacing, clear radio paths, compatible settings, and responsible use of the regional band.

Compared with Meshtastic, the key point is not that one has repeaters and the other does not. Both can relay packets. MeshCore more strongly separates non-repeating personal companions from dedicated repeaters and combines flooding with learned direct paths. Meshtastic uses its own managed-flooding and next-hop behavior and offers multiple configurable node roles. Official Meshtastic mesh algorithm and Meshtastic node roles explained

Room servers

A room server is the MeshCore concept most likely to be unfamiliar to a Meshtastic user. It is a small radio-based bulletin board system, or BBS: users join a named room, publish posts, and retrieve stored messages.

A normal live group channel is ephemeral from the perspective of an absent radio. If your device is switched off or out of range when a channel message crosses the network, you may miss it. A room server keeps history and can deliver unseen posts when you reconnect. The current official FAQ says that a client logging into a room server receives the previous 32 unseen messages. Official room-server explanation

A room server is therefore closer to a shared mailbox or a tiny forum than to a repeater:

A repeater helps packets travel.
A room server receives, stores, and serves shared posts.
A companion gives a person access to both messaging and rooms.

Room servers can technically be configured to repeat traffic, but the MeshCore documentation recommends running the room server and repeater roles on separate devices. A room server with repeating enabled does not provide the complete repeater feature set, and combining the functions can complicate operation and airtime use. MeshCore deployment recommendation

Community reports show why this feature is attractive: users employ room servers as mailboxes for periods when a portable node is offline or outside reliable coverage. They also report that catching up many users can produce bursts of traffic, so room-server placement, message volume, and firmware version matter. These are user experiences rather than guarantees from the project. Community discussion about room-server use and Community discussion about room-server limitations

How MeshCore works

A companion radio advertises its identity, public key, name, and optionally its position so other users can add it as a contact.
A user writes a direct or group message in a MeshCore client.
The companion turns that message into a MeshCore packet and transmits it with the configured LoRa radio settings.
Dedicated repeaters forward eligible packets. An unknown direct route can begin with flooding; a learned route can later be carried in the packet.
The receiving companion decrypts and passes the message to its application, or a room server stores a post for later retrieval.

MeshCore’s documented packet structure is its own protocol. It defines route types, path data, transport codes, payload types, advertisements, acknowledgements, group messages, and control packets. It is not LoRaWAN, and it does not require LoRaWAN gateways or a network server. MeshCore packet specification

Encryption and identity

The official site describes messages as end-to-end encrypted. The current protocol documentation lists Ed25519 for identity and signatures, X25519 Elliptic-Curve Diffie–Hellman for key exchange, AES-128 for encrypted data, HMAC-SHA256 for message authentication, and SHA-256 for hashing. Public advertisements necessarily expose some routing and identity information, including the node’s public key and any name or position the user chooses to publish. Encryption protects message content; it does not make radio activity invisible or anonymous. MeshCore cryptographic algorithms and MeshCore advertisement payload

Meshtastic uses a different security design. Its channels can use shared AES-128 or AES-256 pre-shared keys, while current direct messages use public-key cryptography. Because the two systems use different identities, packet layouts, routing metadata, and message formats, matching a frequency and encryption key would still not make them communicate. Official Meshtastic encryption documentation

MeshCore and Meshtastic compared

Area	MeshCore	Meshtastic
Personal radio	Companion normally acts as an endpoint and does not repeat	Default client roles can participate in rebroadcasting according to role and rebroadcast settings
Infrastructure	Dedicated repeaters are central to extending the mesh	Clients and special infrastructure roles can relay traffic
Routing	Hybrid flood and learned direct-path routing	Managed flooding with newer next-hop behavior for direct traffic
Stored group messages	Room servers provide radio-based store-and-forward posts	No directly equivalent standard room-server role
Internet bridging	Core design is radio-first; bridge and transport work is evolving	Established optional MQTT module and public MQTT ecosystem
Protocol	MeshCore packet and companion protocols	Meshtastic protobuf-based packet protocol
Native interoperability	None; the systems cannot exchange ordinary messages over the air

This is not a universal performance ranking. Dedicated infrastructure may suit a region with coordinated high sites, while a general client mesh may suit users who want portable radios to help opportunistically. Results depend on deployment, terrain, airtime, settings, and coordination.

Hardware compatibility

Many boards commonly used for Meshtastic can also run MeshCore. Official MeshCore material lists devices from Heltec, RAK Wireless, LILYGO, Seeed Studio, and others; examples include the Heltec V3, RAK4631-based WisBlock boards, T-Deck, Heltec T114, and Seeed T1000-E. The list changes frequently, so check the current flasher before buying or erasing a device. Current MeshCore firmware and board list

This is hardware compatibility, not network compatibility. A supported board can be erased and flashed with either system’s firmware, where both projects support that exact board and radio variant. It then operates as a MeshCore device or as a Meshtastic device—not both at the same time on the same radio.

Before changing firmware:

Confirm the exact board revision and radio band.
Back up keys and configuration that you may want later.
Select the correct companion, repeater, or room-server image.
Set legal radio parameters for your country and coordinate with the local network.
Never transmit without a correctly tuned antenna attached.

Can MeshCore and Meshtastic talk to each other?

No, not natively. A MeshCore node cannot decode a Meshtastic packet as a normal MeshCore message, and a Meshtastic node cannot join a MeshCore route. Using the same LoRa chipset, antenna, frequency, or even similar bandwidth and spreading-factor settings does not solve the protocol mismatch.

A developer could build a gateway containing two radios or software stacks and translate selected messages between them. That would be an application-level bridge with explicit rules for identity, encryption, channels, acknowledgements, and routing. It would not make the radio protocols interoperable, and it could weaken privacy or create loops if designed carelessly. Current project discussions describe cross-system translators as proposals or opportunities, not built-in interoperability. MeshCore interoperability discussion

For a deeper treatment, read other compatible or experimental LoRa mesh systems and how LoRa mesh systems compare and whether they interoperate.

When to choose MeshCore or Meshtastic

MeshCore may fit better when:

Your community wants personal radios to remain endpoints and fixed repeaters to provide the routing layer.
Learned direct paths are attractive for your network shape and traffic pattern.
You specifically want radio-based room servers with stored group posts.
Your local community already operates MeshCore repeaters and agrees on radio settings.
You want to experiment with its lightweight open packet-routing library.

Meshtastic may fit better when:

An established Meshtastic community already exists near you.
You want its mature application, device-role, telemetry, map, and optional MQTT ecosystem.
You want ordinary client devices to help relay packets under configurable rules.
Your chosen hardware or integration is supported more completely by Meshtastic.
You prefer its current documentation depth and larger installed community.

You do not need to declare one project the winner. Communities can test both on separate frequencies or at separate times where regulations and local band plans permit. The practical choice is usually the network that nearby people will actually maintain, document, and use consistently.

Project status, community, and maturity

MeshCore is an active, comparatively young project. Its main firmware and routing repository is maintained under the meshcore-dev GitHub organisation, while Scott Powell of Ripple Radios is identified in the official FAQ as the creator and firmware developer. Liam Cottle develops the cross-platform companion application. The project also accepts community contributions and has third-party clients, command-line tools, integrations, maps, and hardware builds. MeshCore GitHub organisation

At the time this article was checked, the official release page listed companion, repeater, and room-server firmware version 1.16.0, released in June 2026. The repository showed thousands of commits, hundreds of contributors or proposed changes, and continuing issue and pull-request activity. Release numbers and activity counts change, so consult the live pages rather than treating these figures as permanent. Current MeshCore releases

Documentation is improving but is not yet uniformly mature. The official documentation now includes packet and payload formats, command references, a companion protocol, power-management notes, and an extensive FAQ. However, the companion protocol explicitly warns that it remains in development and may contain inaccuracies, while some important user guidance is concentrated in the FAQ. The repository roadmap also lists substantial future work, including bridge standardisation, routing improvements, multiple sub-mesh support, and discussion of a version 2 protocol. MeshCore documentation, companion protocol status, and project roadmap

That does not make MeshCore unusable. It means deployments should standardise on tested firmware, record their settings, change default administration passwords, and expect features or procedures to evolve. For support and real-world deployment discussion, use the project’s official Discord invitation, MeshCore subreddit, and GitHub Discussions. Community advice is valuable, but protocol and firmware claims should still be checked against official documentation and current releases.