A max hop greater than 3bits would be nice.
I have heard of it, first question though.
Is it open source? I couldn't find the source code
Discussion
The firmware for the devices is open source, but the apps are not open source.
That's exactly why I absolutely refuse to touch it. Until somebody makes an open source app for it, you won't catch me using it.
Yes, the apps for meshtastic and the firmware for meshtastic is open source. The firmware for mesh core is open source, but the apps for mesh core are not open source.
Yeah, that's a pretty odd choice.
meshtastic lets you use up to seven hops, but they don't suggest doing it unless you absolutely need to.
What can happen if your hop count is too high is that you cause a packet storm where you send out your packet and then you hear it again later and you retransmit it over and over and over again until the hop count finally runs out in a big loop.
Say you have nodes A, B, C, D, and E. U transmit, B transmits, C transmits, D transmits, E transmits, U retransmit, B retransmits, C retransmits, D retransmits, E retransmits, etc. etc. until it finally runs out.
This sounds like a problem inherent in meshtastic's routing.
Reticulum, for example, doesn't route the way meshtastic does I believe.
It doesn't flood.
Actually, they both flood. Meshtastic does something they call managed flood, and meshcore does a full flood.
Yes, Meshcore and meshtastic.
But Reticulum does not do flooding.
This seems preventable, is there no mechanism to prevent rebroadcasts of messages that originated from the local device? Or would that break other functionality?
I'm not sure. My guess is that these devices have a very small memory, and so that's why it has trouble with that, but I won't swear to that because I'm not absolutely sure.
I think it is a choice they stuck with.
If they took a normal next-hop routing approach then they would need a routing table. Meshtastic has no concept of a routing table.
I will take a look at uRNS (which is a C++ impl of Reticulum that runs directly on the ESP)
They have somewhat of a routing table for next hop routing with direct messages, but only for the hop that your node heard the message from. That way, when you send a message in reply, it goes back to the same node that gave you the message to begin with. And then that node passes it off to the node that it heard that message from, etc, etc. But that's only for direct messages and was introduced in 2.6 back in like February 2025. They had a blog post about it if you're interested.
Ah so in certain cases they do, but that is on-demand next-hop routing then?
Reticulum sends announcements at certain intervals and maintains routing table entries via that mechanism.
I would agree with that assessment. It's only four direct messages and it's not maintained for any other purpose besides that.
Oh, sorry, my bad. I don't know much about the way reticulum works, because I haven't gotten the chance to really play with it.