MeshCore message formats & payloads
Practical explanation of how MeshCore messages are designed for reliable text communication over LoRa, without incorrect assumptions from other protocols.
How MeshCore messages are structured
MeshCore is designed for lightweight text communication over LoRa with minimal overhead. Messages must stay compact because LoRa airtime is limited and directly impacts range, latency, and reliability.
This page focuses on safely documented MeshCore behavior: clients do not repeat, forwarding is handled by repeaters, flood can be used for initial route discovery, and follow-up traffic can use a learned repeater path.
Important: avoid copying field names or message schemas from other mesh projects. Keep documentation at protocol-behavior level and based on MeshCore-supported behavior.
Schema and internal message structure
MeshCore uses compact internal message representations for LoRa traffic. Public documentation does not define a stable external schema you should treat as a fixed API.
MeshCore message (conceptual): - source/target context - compact payload - forwarding context via repeater behavior - integrity and delivery context
For website-level technical copy, prefer a conceptual protocol description over non-official field-level schemas. This avoids incorrect implementations and confusion with other protocols.
Message forms that matter in MeshCore
Direct message (node-to-node)
Targeted message to a specific node for private or one-to-one communication.
Room message
Message to a room (chat channel) so multiple participants receive the same content.
Discovery forwarding
If no route is known yet, routing can start with flood via repeaters to establish reachability.
Path learning after delivery
After successful delivery, path information can be learned so follow-up traffic is forwarded more directly.
Repeater behavior
Forwarding happens at repeater level; clients are not a general repeater layer.
Encrypted content
MeshCore supports message encryption. Document this at high level without unverified key/channel implementation details.
Payload and transport context
Header and transport context
In MeshCore, this section focuses on:
- Compact payloads: messages are kept small to reduce LoRa airtime.
- Forwarding context: repeaters handle forwarding behavior, clients do not repeat.
- Hops/flood: protocol has an internal upper bound (64); practical propagation is tuned at repeater level (e.g. flood.max).
- No fixed public field schema claim: do not publish non-official packet fields as hard specification.
Payload size in practice
There is no single universal packet size that always applies to MeshCore. Effective payload depends on LoRa settings (such as spreading factor, bandwidth, coding rate), regional settings, and firmware behavior.
Technical guidance
| Parameter | Value | Description |
|---|---|---|
| Primary use case | Compact text communication | Designed for reliable message exchange at low data rates. |
| Forwarding model | Repeater-based | Clients do not repeat; forwarding is handled by repeaters/room servers with repeat enabled. |
| Route formation | Flood discovery + path learning | Initial reachability can use flood, then forwarding can follow learned repeater paths. |
| Rooms | Supported | MeshCore supports room communication in addition to direct node messages. |
| Hop context | Internal upper bound 64 | Practical behavior is constrained by repeater settings (e.g. flood.max). |
| Encryption | Supported | Describe at high level; avoid unverified claims about exact key/channel models. |
Why this approach is accurate
Protocol-accurate
Avoids mixing MeshCore behavior with details from other mesh protocols.
Less misleading
Avoids hard claims about packet fields or limits that are not officially defined for MeshCore.
Easier to maintain
Concept-level documentation stays valid as firmware evolves.
LoRa-realistic
Makes clear that effective payload/behavior depends on radio settings and topology.
Safer security copy
Mentions encryption correctly without unsupported implementation details.
Clearer developer model
Readers get the right mental model: rooms, repeaters, discovery, and learned-path forwarding.
Frequently asked questions
Does MeshCore use the same message schemas as other well-known LoRa mesh projects?
No. Do not copy external schemas one-to-one. Describe MeshCore using officially documented behavior.
Do all nodes repeat messages?
No. Clients do not repeat. Forwarding is handled by repeaters (and room servers with repeat enabled).
How is route formation handled?
When no route is known, flood discovery can be used. After successful delivery, path information can be learned for more targeted follow-up forwarding.
Does MeshCore support rooms and direct messages?
Yes. MeshCore supports both room communication and direct node-to-node messaging.
What is the maximum packet size?
Do not publish one fixed universal value. Effective packet size depends on LoRa settings, region, and firmware behavior.
Are messages encrypted?
MeshCore supports encryption. Keep public documentation high-level and avoid unverified claims about exact key/channel implementation.
Use protocol-accurate MeshCore documentation
Use a clean MeshCore framing: compact messages, repeater forwarding, discovery + learned paths, and realistic LoRa constraints.