Isn't Meshtastic limited by how many hops messages can make?
Meshtastic has a fixed hop limit of 7, with the default being 3.
The main problem with Meshtastic is it's gone far beyond it's scope and the developers are trying to shoehorn in things that are simply not possible within the constraints of the existing firmware.
Meshtastic initially focused on just flood routing, (every Repeater role node just rebroadcasts the incoming packet and increments the hop) until moving to "managed flood routing"
https://meshtastic.org/docs/overview/mesh-algo/
IMO this scheme is horrible. It has the weaknesses of table based routing and flood routing with none of the benefits, especially given the bandwidth + airtime constraints of LoRa.
If you want a mesh device to chat with friends on a hike - Meshtastic does that better than anything else. But Meshtastic isn't scalable.
People are also idiots and do stupid shit with their nodes. In a Meshtastic network a poorly placed repeater/router is the biggest detriment you can have, Having your network able to be crippled by someone placing a Repeater role node down in the city with a shitty monopole antenna should not be a feature of any mesh networked solution. And with such a limited hop count this is something that's critical.
In comparison Reticulum is a network stack, and more like a set of rules and logic for how things talk to eachother. Meshtastic is more LoRa specific. Reticulum can work over LoRa or really any type of medium: packet radio, optical links, I2P, Yggdsrail, and regular IP. It isn't LoRa specific like Meshtastic is. It handles routing beautifully, even over topologies with mixed hardware and bandwidth. The hop limit is 255 and it uses a table of announces from destinations to solve paths.
https://reticulum.network/manual/understanding.html#introduction-basic-functionality
Reticulum can work with LoRa using the RNode firmware. The main drawback currently, for LoRa use, is that there is no native C implementation. While the RNode firmware is written in C it is more of a dumb modem that communicates with the rnsd daemon versus handling the application logic itself. This has been a barrier to adoption but there is no reason why outside of no mature C or C++ port that targets microcontrollers exists yet
There is a WIP port here though:
