Idea
It would be useful if the sender of a flood packet could define the maximum number of repeater hops that the packet is allowed to travel through.
The existing region field could be extended to support a second mode.
Instead of specifying a region such as:
ch-de
the sender could alternatively specify:
hops:5
hops:5 would not represent a region. Instead, it would tell the mesh:
This packet may be forwarded through a maximum of 5 repeater hops.
Using the existing path information
MeshCore already contains the information required to implement this.
When a repeater forwards a packet, it adds its own identifier to the packet path. Therefore, a subsequent repeater can already determine which repeaters the packet has passed through, and thus how many repeater hops have already occurred.
For this proposed feature, no additional hop counter would therefore be required.
For a packet containing:
hops:5
the repeater could simply evaluate the existing path information and determine how many repeater hops have already occurred.
Repeater behavior
The repeater should be able to distinguish between a normal region value and a hop-limit value.
For example:
ch-de
would keep the existing behavior:
Is this packet relevant to my region?
Whereas:
hops:5
would indicate that no region-based filtering should be performed. Instead, the repeater should check the number of repeater hops already present in the path.
Once the fifth repeater hop has been reached, the packet should no longer be forwarded further as a flood.
Interaction with flood.max
The sender-defined hop limit must not override the local configuration of a repeater.
The sender-defined limit should therefore only be able to further restrict the flood range.
For example:
Sender: hops:5
Repeater: flood.max = 10
→ Maximum 5 hops
Conversely:
Sender: hops:10
Repeater: flood.max = 5
→ Maximum 5 hops
The sender can therefore reduce the propagation range of its own packet, but can never increase the maximum flood range configured by the repeater operator.
In other words:
Effective limit = min(sender hop limit, repeater flood.max)
Why use the existing region field?
One major advantage of this approach is that it would not require a completely new user interface or configuration concept.
The existing field could support two different modes:
ch-de → region-based forwarding
hops:3 → hop-based forwarding
hops:5 → hop-based forwarding
The repeater could recognize the hops: prefix and interpret the value as a hop limit rather than as a region name.
This would give the sender a simple way to specify:
I don't want this packet to be propagated based on a region. I want it to be propagated for a maximum of X repeater hops.
Use cases
This would be particularly useful when local communication should make use of existing repeaters, while avoiding unnecessary propagation throughout the entire mesh.
Examples:
• Nearby village: A destination may be two repeaters away. hops:3 would allow the packet to reach the destination without propagating it further into the regional mesh.
• Events / meetings: Communication could intentionally be limited to the local area.
• Sensor data: A sensor could limit its broadcasts to, for example, 1–3 hops.
• City / municipality: Messages could intentionally be restricted to the local mesh.
• Temporary local communication: Existing repeaters could still be used, while preventing packets from unnecessarily propagating through a large part of the mesh.
Benefits
This extension would allow the sender to limit the propagation range of an individual flood packet without requiring any changes to the repeater configuration.
It could also significantly reduce unnecessary flooding of packets across a large number of repeaters.
The repeater operator would still define the maximum permitted flood range using flood.max.
The sender could voluntarily reduce this range for an individual packet.
This creates two levels of control:
Repeater configuration:
"How far may a flood packet go at most?"
Sender:
"How far should this particular packet go at most?"
The actual maximum range would always be the lower of these two limits.
Summary
The proposed extension could be described very simply:
Region field:
ch-de → existing region-based forwarding
hops:3 → maximum 3 repeater hops
hops:5 → maximum 5 repeater hops
When hops:X is specified, the repeater would use the existing path information, which already contains the identifiers of previously traversed repeaters, to determine how many hops have already occurred.
No additional hop counter should therefore be necessary.
Once the sender-defined maximum number of hops has been reached, the packet would no longer be flood-forwarded.
The existing flood.max setting would remain the repeater's absolute upper limit.
This would give MeshCore a simple way to let the sender control the maximum propagation range of an individual packet, while keeping the repeater operator in control of the overall network-wide flood limits.
Idea
It would be useful if the sender of a flood packet could define the maximum number of repeater hops that the packet is allowed to travel through.
The existing region field could be extended to support a second mode.
Instead of specifying a region such as:
ch-de
the sender could alternatively specify:
hops:5
hops:5 would not represent a region. Instead, it would tell the mesh:
This packet may be forwarded through a maximum of 5 repeater hops.
Using the existing path information
MeshCore already contains the information required to implement this.
When a repeater forwards a packet, it adds its own identifier to the packet path. Therefore, a subsequent repeater can already determine which repeaters the packet has passed through, and thus how many repeater hops have already occurred.
For this proposed feature, no additional hop counter would therefore be required.
For a packet containing:
hops:5
the repeater could simply evaluate the existing path information and determine how many repeater hops have already occurred.
Repeater behavior
The repeater should be able to distinguish between a normal region value and a hop-limit value.
For example:
ch-de
would keep the existing behavior:
Is this packet relevant to my region?
Whereas:
hops:5
would indicate that no region-based filtering should be performed. Instead, the repeater should check the number of repeater hops already present in the path.
Once the fifth repeater hop has been reached, the packet should no longer be forwarded further as a flood.
Interaction with flood.max
The sender-defined hop limit must not override the local configuration of a repeater.
The sender-defined limit should therefore only be able to further restrict the flood range.
For example:
Sender: hops:5
Repeater: flood.max = 10
→ Maximum 5 hops
Conversely:
Sender: hops:10
Repeater: flood.max = 5
→ Maximum 5 hops
The sender can therefore reduce the propagation range of its own packet, but can never increase the maximum flood range configured by the repeater operator.
In other words:
Effective limit = min(sender hop limit, repeater flood.max)
Why use the existing region field?
One major advantage of this approach is that it would not require a completely new user interface or configuration concept.
The existing field could support two different modes:
ch-de → region-based forwarding
hops:3 → hop-based forwarding
hops:5 → hop-based forwarding
The repeater could recognize the hops: prefix and interpret the value as a hop limit rather than as a region name.
This would give the sender a simple way to specify:
I don't want this packet to be propagated based on a region. I want it to be propagated for a maximum of X repeater hops.
Use cases
This would be particularly useful when local communication should make use of existing repeaters, while avoiding unnecessary propagation throughout the entire mesh.
Examples:
• Nearby village: A destination may be two repeaters away. hops:3 would allow the packet to reach the destination without propagating it further into the regional mesh.
• Events / meetings: Communication could intentionally be limited to the local area.
• Sensor data: A sensor could limit its broadcasts to, for example, 1–3 hops.
• City / municipality: Messages could intentionally be restricted to the local mesh.
• Temporary local communication: Existing repeaters could still be used, while preventing packets from unnecessarily propagating through a large part of the mesh.
Benefits
This extension would allow the sender to limit the propagation range of an individual flood packet without requiring any changes to the repeater configuration.
It could also significantly reduce unnecessary flooding of packets across a large number of repeaters.
The repeater operator would still define the maximum permitted flood range using flood.max.
The sender could voluntarily reduce this range for an individual packet.
This creates two levels of control:
Repeater configuration:
"How far may a flood packet go at most?"
Sender:
"How far should this particular packet go at most?"
The actual maximum range would always be the lower of these two limits.
Summary
The proposed extension could be described very simply:
Region field:
ch-de → existing region-based forwarding
hops:3 → maximum 3 repeater hops
hops:5 → maximum 5 repeater hops
When hops:X is specified, the repeater would use the existing path information, which already contains the identifiers of previously traversed repeaters, to determine how many hops have already occurred.
No additional hop counter should therefore be necessary.
Once the sender-defined maximum number of hops has been reached, the packet would no longer be flood-forwarded.
The existing flood.max setting would remain the repeater's absolute upper limit.
This would give MeshCore a simple way to let the sender control the maximum propagation range of an individual packet, while keeping the repeater operator in control of the overall network-wide flood limits.