You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support multiple region scopes in flood packages to allow a fine-grained flood limitation, reduce border routing issues and support long corridors #2811
Currently, flood packages support only a single scope value, effectively one region hash. In practice, this has led communities to build region hierarchies to support broad regions while trying to avoid excessive propagation. However, this approach isn't fine-grained at all and always breaks down at regional borders, especially between neighboring countries where local communication should still work naturally.
Using top-level hierarchies like de as an allowed region can also cause propagation to spread much wider than intended, which creates unnecessary network load and does not match community expectations.
I’d like to propose exploring a more flexible region-scoping model with the following ideas:
Allow multiple scope values (multiple region hashes) in flood packages
This could enable a smaller directed path to be determined when a target lies beyond a region border.
Optionally add a home-region value to adverts
This would allow regions to be stored per contact and help with routing decisions later.
Calculate a chain of adjacent regions when contacting a remote node
This would allow remote locations to be reached even with region limitations, while still reducing unnecessary interference with the wider network (the calculation of a region chain could be done by the collected contact/region/gps-information).
If the community eventually agrees on smaller region definitions, this could also work well with priority-based forwarding ideas such as those discussed in #2747 (comment), where repeaters prioritize their own small region and neighboring regions. That could reduce total network stress and keep flood corridors smaller overall.
Currently, flood packages support only a single scope value, effectively one region hash. In practice, this has led communities to build region hierarchies to support broad regions while trying to avoid excessive propagation. However, this approach isn't fine-grained at all and always breaks down at regional borders, especially between neighboring countries where local communication should still work naturally.
Using top-level hierarchies like
deas an allowed region can also cause propagation to spread much wider than intended, which creates unnecessary network load and does not match community expectations.I’d like to propose exploring a more flexible region-scoping model with the following ideas:
Allow multiple scope values (multiple region hashes) in flood packages
This could enable a smaller directed path to be determined when a target lies beyond a region border.
Focus on local districts as the primary unit for:
This should help keep flood corridors as narrow as possible, similar to the direction of issue Proposal: Limit Floods by a geo-coord-defined Corridor Approach #1451.
Optionally add a home-region value to adverts
This would allow regions to be stored per contact and help with routing decisions later.
Calculate a chain of adjacent regions when contacting a remote node
This would allow remote locations to be reached even with region limitations, while still reducing unnecessary interference with the wider network (the calculation of a region chain could be done by the collected contact/region/gps-information).
If the community eventually agrees on smaller region definitions, this could also work well with priority-based forwarding ideas such as those discussed in #2747 (comment), where repeaters prioritize their own small region and neighboring regions. That could reduce total network stress and keep flood corridors smaller overall.