Targeted advert routing as an alternative to flood adverts on large meshes

[paulborneo]

This is a proposal for a new advert mode that could make long-distance advert delivery more efficient on large meshes by routing toward a selected destination instead of flooding the whole network.

Flood adverts work well because they are simple and empirically discover valid paths. But as MeshCore grows into larger regional and multi-region networks, they become increasingly expensive: a message intended for one area can consume airtime across a much larger area than necessary.

I’d like to propose a targeted advert mode as an alternative to flood adverts for non-local delivery.

Proposed behavior
A companion-device user would choose between:
• Local advert — unchanged
• Targeted advert — send to a selected destination location/region, then broadcast there
A targeted advert would include a destination region and destination location.

Routing behavior:
• If the destination is in the current region, route toward the repeater nearest the selected location and broadcast there.
• If the destination is outside the current region, forward region-by-region until it reaches the destination region, then route locally to the repeater nearest the selected location.
• Optionally, the final repeater could also forward to one or two nearby repeaters for limited redundancy.

Suggested implementation direction
This could be done with lightweight regional routing data rather than full-network topology awareness.
For example:
• Each repeater periodically reports reachable repeater neighbors and link quality.
• A regional coordination node on the MeshCore network computes a compressed set of strong backbone paths for that region.
• Repeaters receive only:
◦ a small set of backbone paths for their region
◦ repeater locations on those paths
◦ minimal adjacent-region connectivity data
That would let repeaters make simple forwarding decisions without requiring full topology knowledge or complex computation.

Design goals
• no internet dependency
• minimal storage/computation at companion devices and repeaters
• no requirement for full-network awareness at each node
• preserve current local advert behavior
• improve scaling for large regional meshes
• allow infrequent routing-table updates (for example, daily)
Why this may be useful
This could reduce unnecessary flood traffic while preserving a way to deliver adverts over long distances. The main goal is to make non-local adverts scale better as networks become larger.

Open questions
• How should regions be defined?
• What path metric should be optimized: link quality, hop count, airtime cost, or something else?
• How often should repeaters report connectivity?
• How often should regional routing data be recomputed?
• Should targeted adverts initially be limited to companion-device adverts?
• Should final delivery use one repeater or a small nearby set?

[paulborneo]

Problem

Flood routing works very well at smaller scales because it discovers viable paths empirically. A flood advert tests the network as it exists at that moment, finds a working path, and allows that path to be used until it breaks, at which point the process can repeat. That is a simple and elegant mechanism.

However, as MeshCore networks grow across larger geographic areas, flood adverts become increasingly inefficient. Their reach expands with the size of the network, and a single advert can consume resources far beyond the area it actually needs to reach. On very large meshes, repeated flood adverts can create significant congestion and can potentially degrade the network for everyone.

This appears to already be a practical problem in larger deployments, such as in the UK, where the scale and reach of flood adverts have caused concern. As MeshCore grows into regional and multi-region networks, it may need a way to deliver non-local adverts without flooding the entire mesh.

Proposal

I propose adding a new advert mode for companion-device users: a targeted advert.

Today, the choice is essentially between:

local advert
flood advert

Under this proposal, the choices would become:

local advert
targeted advert to a selected location

A user sending a targeted advert would choose a destination on a map. The advert would include a destination region and destination location. Instead of flooding the entire network, the mesh would route the advert toward that destination and broadcast it only when it arrives there.

This would make the system behave more like postal routing than flood discovery: the sender specifies where the message should go, and the network determines how to get it there efficiently.

Design principles

Any routing approach for this should follow a few principles:

It should not rely on the internet or any infrastructure outside the MeshCore network.
Information should be stored and used as locally as possible.
Companion nodes and repeaters should not need to store large amounts of topology data or perform complex calculations.
The system should not require each repeater to understand the full network.
Routing data probably does not need to update very often; daily or similarly infrequent updates may be sufficient.
How it would work

1. Local targeted delivery within a region

When a repeater receives a targeted advert, it examines the destination region and location.

If the destination is within its own region, it routes the advert toward the repeater nearest the selected location. When the advert reaches that repeater, that repeater broadcasts it locally.

For added resilience, that final repeater could also forward the advert to one or two nearby repeaters so they can broadcast it as well, in case the nearest repeater does not fully cover the intended area.

2. Routing across regions

If the advert is intended for another region, the receiving repeater forwards it toward the next region on the way to the final destination.

If the destination region is adjacent, it routes directly toward that region. If the destination is multiple regions away, the advert moves region by region until it reaches the target region. Once there, the local routing process takes over and delivers it to the repeater nearest the selected location.

3. Regional path computation

To support this, each repeater in a region could periodically report:

which repeaters it can reach
the relative quality or strength of those links

These reports would go to a regional coordination node or room server that exists on the MeshCore network itself.

Using that information, the coordination node would compute a compressed set of strong regional backbone paths made from the longest, strongest, and most reliable repeater-to-repeater links.

Rather than distributing the full topology, it would distribute only this compact routing structure back to the repeaters.

4. Lightweight repeater routing tables

Each repeater would then maintain:

a manageable set of backbone paths for its own region
the locations of repeaters on those paths
a small table describing which regions connect to which neighboring regions

This would allow a repeater to make simple forwarding decisions without needing a full view of the mesh.

When a targeted advert arrives, the repeater would:

identify the repeater on the known backbone nearest the destination location
determine a practical path to reach that backbone using available path intersections
forward the advert accordingly

For inter-region routing, it would:

determine which neighboring region is the next hop toward the destination region
forward the advert toward a repeater that can carry it into that region
Why this may help

This approach could provide several benefits:

reduce unnecessary network-wide flooding
make non-local adverts scale better on large meshes
preserve local adverts exactly as they work today
keep companion-device logic simple
keep repeater-side logic manageable
avoid requiring global topology knowledge at every node
create a more efficient backbone for regional and multi-region delivery
What this offloads where

This proposal keeps the burden low at the edge:

Companion device: only needs to include the selected destination location/region
Repeater: only needs to perform simple lookups and forwarding decisions using compact tables
Regional coordination node: performs the heavier work of analyzing connectivity and generating compressed routing paths

In effect, the coordination node would create a compact representation of the best available paths through a region, and repeaters would use that representation to forward targeted adverts efficiently.