Meshtastic routing proposal favors shortest observed path over stale relays

A Meshtastic packet that keeps favoring the last relay it heard can waste airtime, drag out delivery, and miss a shorter path that is already available. That is the problem Pablitosalinero is trying to solve in GitHub discussion #10246, where the pitch is not for a bigger protocol, but for a smarter choice using metadata Meshtastic already carries.

The idea is simple in concept and sharp in consequence. Instead of letting the mesh cling to a relay because it was heard most recently, the proposal uses hop count as the signal and calculates distance with hop_start minus hop_limit. If a node overhears the same destination through a shorter route, it would prefer that path. If the path is equal, it would refresh the assignment and keep it current. If a longer route shows up, the node would ignore it unless the current next hop has gone unconfirmed for a set period, such as 30 minutes. To make that clean, the post suggests a dedicated next_hop_last_confirmed timestamp in the node database. The author calls it “This is just a preliminary suggestion to see if you find it worthwhile to explore.”

That matters because Meshtastic’s own design keeps coming back to the same constraint: mobility. The project describes itself as an open-source, off-grid, decentralized mesh built for affordable, low-power devices, and its routing docs say the protocol does not assume static nodes. Since version 2.6, Meshtastic has used different approaches for broadcasts and direct messages, while its managed-flood explanation says the team has evaluated smarter routing protocols but has not found one that consistently beats the current approach across its real use cases. In that context, the new proposal is trying to improve route selection without adding extra control traffic or protocol overhead.

The history around Meshtastic 2.6 shows why the discussion has traction. The February 26, 2025 preview said the new next-hop routing for direct messages had taken about 1.5 years of work and used two previously unused bytes in the unencrypted header to store the current relayer and intended next hop. That same low-overhead mindset appears in the rest of the stack. The traceroute module exists from firmware 2.0.8 onward, and from firmware 2.5 it records the route back to origin with SNR for each link, even though LoRa bandwidth is tight and Meshtastic does not normally track every hop in a message’s trip.

Recent features point in the same direction. On November 17, 2025, Meshtastic introduced Zero-Cost Hops for favorite routers, preserving hop count between favored infrastructure nodes while keeping the maximum hop limit at 7. On September 25, 2025, it described ROUTER_LATE as a role for places that cannot see existing ROUTER sites, such as behind hills or in canyons. Together, those changes show a project still tuning path efficiency at the edges.

That is why this proposal feels bigger than a tidy routing cleanup. If stale next-hop choices are really causing missed messages, longer delays, and inefficient routes in moving meshes, then a shortest-observed-path rule could help real networks behave more predictably. If it only sounds cleaner on paper, Meshtastic will leave it behind like any other clever idea that could not survive the field.