meshticulumDeveloper documentation / Comparison
Shared ambitions.
Different designs.
MeshCore's practical radio operation and Reticulum's secure networking abstractions help explain why we're building Meshticulum. The comparison keeps each project's strengths and the current experiment's gaps visible.
Design and capabilities
What each system puts first.
The tables compare three project columns. Scroll horizontally on a small screen; the table region also accepts keyboard focus.
| Concern | MeshCore | Reticulum | Meshticulum |
|---|---|---|---|
| Core model | Embedded packet-radio framework with companion, repeater and room-server roles. Project | Cryptographic destinations, packets, Links and Resources across local or wide-area networks. Overview | Bounded authenticated flows, verified resources and explicit application and carrier boundaries. Technical overview |
| Runtime and carriers | C++ on embedded radios, with client connections over BLE, USB or Wi-Fi; a KISS modem example also exists. Examples | Python userland stack with RNode LoRa, serial, TCP and UDP interfaces. Interfaces | Python host libraries, exclusive serial and Linux SX1262 workers, plus an authenticated TCP prototype. Native product tooling belongs to Lantern. |
| Routing | Flood discovery and returned paths support later direct packets; roles determine forwarding behavior. Routing FAQ | Signed announcements and next-hop Transport routing establish reachability. Transport | Explicit supplied routes and measured resource-path selection. Autonomous authenticated discovery is not implemented. |
| Reliable transfer | Message ACKs, requests/replies and multipart/custom packet types. Applications can build on these. Payload format | Resources provide sequencing, retransmission, integrity and reassembly over a Link; Channels support reliable messages. Resources | Receiver credit, selective ACKs and bounded retries. MR1 binds blocks to requests; signed manifests verify complete public chunks. |
| Mixed paths | Companion client connectivity is distinct from a general mixed-media routed overlay. | Networks can combine interface types. IP can carry Reticulum traffic without replacing its network model. Interface guide | Finite native public LoRa/IP delivery and loss/LoRa-resume/IP-return evidence. Broader sustained qualification remains open. Recorded scope |
| Wire compatibility | MeshCore packet and routing protocol. | Reticulum packet, destination and Link protocol. | A separate protocol. It does not translate MeshCore or Reticulum peers into interoperable endpoints. |
Security properties
Encryption is only part of the question.
Compare author authentication, replay behavior and key compromise separately. A cipher name or a throughput figure cannot establish an overall security ranking.
| Property | MeshCore | Reticulum | Meshticulum |
|---|---|---|---|
| Identity and authentication | Ed25519-signed node advertisements and encrypted direct-message payloads. Shared-channel group text does not independently sign each displayed sender name. Reviewed payloads | A Link verifies the destination; the initiator may remain anonymous or identify inside the encrypted Link. Link establishment | Provisioned peer/session/service bindings and authenticated DATA/ACKs. Private envelopes separately carry sender signatures and recipient encryption. Trusted enrollment stays external. |
| Forward secrecy | The reviewed direct-message shared-secret path uses identity keys; it does not establish a fresh ephemeral exchange. This does not describe every custom application. Pinned source review | Links use ephemeral X25519 keys and document forward secrecy. Optional destination ratchets support some link-less traffic; GROUP/PLAIN modes differ. Mode details | Not proved for the current radio/IP session codecs or long-term recipient envelopes. The forward-session source primitive remains experimental, with native private qualification open. |
| Replay and lifecycle scope | Evaluate the selected payload and firmware path; this table does not equate all modes. | Evaluate Link, destination and ratchet behavior for the chosen API and mode. | Durable counters, replay decisions, original expiry and retained attempt debt. Protected state and operating-system rollback resistance remain deployment responsibilities. |
Full reviewed source baseline: MeshCore a366955; Reticulum 1.5.5 / 7f2b3b9. These identify source reviews, not flashed firmware or equal benchmark configurations.
Published observations
Keep the units and timing.
The competitive aim is more useful delivery per radio second. The figures below are different experiments, so each carries its own conditions.
| Measurement | MeshCore | Reticulum / RNode guide | Meshticulum |
|---|---|---|---|
| Reported figure | 410 B/s Contributor frame-ACK experiment in issue #3404. | 3.1 kb/s On-air bitrate in the RNode author's 2023 guide, whose example logs use RNS 0.3.3. | 1,071.3 B/s Useful resource bytes through the sender's reliable-flow ACK, with separate publisher verification. |
| Payload and radio scope | 25 individually acknowledged 128-byte frames. Two SX1262 companions, about one metre apart, SF7/BW500. Other settings/pins incompletely reported. | SF8/BW125/CR4/5 at 7 dBm. The figure is physical bitrate, not encrypted application goodput. | 16,356 useful bytes / 16,384-byte MR1 response. SF7/BW500/CR4/5, 0 dBm chip setting. 85 acknowledged DATA frames, zero DATA retries or duplicates. |
| Timing boundary | Each frame's ACK round trip; reported confirmed throughput. | Modem on-air bitrate. It is neither 3.1 kB/s nor a like-for-like application rate. | 15.268 seconds through sender ACK. Full request-to-publisher-verification: 80.731 seconds, 202.6 B/s. |
A scoped 2.61× numerical ratio.
1,071.3 / 410 is approximately 2.61. Windowed resource flow and individually acknowledged frames have different payloads and timing boundaries. Two consecutive Meshticulum finite samples exceeded 1,000 B/s; they do not establish sustained capacity, equal range or stronger encryption security.