Regions, when implemented, work pretty well for reducing the congestion on the Mesh. However the adoption of regions is hampered by the fear that new users will somehow turn on their radios to a silent mesh and assume nothing is there and not continue any further.
To address these concerns, and to make it easier in general for new users to onboard, the following features could be added:
-
Zero-Hop Adverts from repeaters include a region (and byte size). This could either be the configured Home, Default, or Other region (either tbd or let users pick: set zerohop.broadcast.region Home, Default, existing region). This information can then be used in multiple ways:
- Companions & Apps can include a "detect regions" section that will show what regions are available to the user, based on the heard zerohop adverts
- Repeater Discovery requests will return the region information when users request it
- Repeater Admins can view the regions of their neighbors - even if they aren't supporting flood on * (or that neighbors default region)
-
Along with set flood.max, there should be a new setting for set flood.max.unscoped`` that will allow Repeater administrators to set a different hop limit on for messages that are unscoped. New repeater admins can get their messages heard and repeated across their local mesh, but not carried further than that. Allowing a new user who has setup a new repeater to have their messages relayed by neighboring established repeaters. In observation of rolling out repeaters with regions here on the Island of Ireland, this is actually rare that a new user can _only_ user a repeater to access the mesh - maybe reliably, but they usually get some signal on their companion first or as part of determining where to setup a repeater. If they aren't immediately within ZeroHop of an established MeshCore repeater, they are 1-2 hops away from one, so set flood.max.unscoped 2would work well here. Others may needset flood.max.unscoped 5` etc.
Instead of trying to prescript region names as the solution, these improvements would make using the existing method of letting users discover and coordinate what regions are in place organicly as they are engaging with the mesh. There's not presumed "correct" region name for an area other than what the people who are building the mesh in the region decide it to be. The RF waves don't conform to UNLOC region codes, human social groups definitely don't, so focusing on improving the UX of learning what regions are being scoped around the user should be the focus and would likely improve the traffic congestion situation as it is less daunting or "drastic" to disable flood on * since now:
- New users can find out the regions that are in use around them through their companion app and their own repeaters neighbors discovery list. App improvements can make this easier and part of a new user setup of just pinging them when the first time a region is detected when they open the app (not notifying outside the app)
- Existing mesh admins who have done the work to coordinate the optimal tunings for their region can also communicate a simple
set flood.max.unscoped 2 though the same channels, and that allows for new user onboarding and communication, without opening floodgates. Even if it is a new user spamming the local area without knowing it, at most it would impact nodes X hops away and not flood the entire mesh.
Each repeater's ZeroHop Advert becomes a welcoming message to new users.
Regions, when implemented, work pretty well for reducing the congestion on the Mesh. However the adoption of regions is hampered by the fear that new users will somehow turn on their radios to a silent mesh and assume nothing is there and not continue any further.
To address these concerns, and to make it easier in general for new users to onboard, the following features could be added:
Zero-Hop Adverts from repeaters include a region (and byte size). This could either be the configured Home, Default, or Other region (either tbd or let users pick:
set zerohop.broadcast.region Home, Default, existing region). This information can then be used in multiple ways:Along with
set flood.max, there should be a new setting forset flood.max.unscoped`` that will allow Repeater administrators to set a different hop limit on for messages that are unscoped. New repeater admins can get their messages heard and repeated across their local mesh, but not carried further than that. Allowing a new user who has setup a new repeater to have their messages relayed by neighboring established repeaters. In observation of rolling out repeaters with regions here on the Island of Ireland, this is actually rare that a new user can _only_ user a repeater to access the mesh - maybe reliably, but they usually get some signal on their companion first or as part of determining where to setup a repeater. If they aren't immediately within ZeroHop of an established MeshCore repeater, they are 1-2 hops away from one, soset flood.max.unscoped 2would work well here. Others may needset flood.max.unscoped 5` etc.Instead of trying to prescript region names as the solution, these improvements would make using the existing method of letting users discover and coordinate what regions are in place organicly as they are engaging with the mesh. There's not presumed "correct" region name for an area other than what the people who are building the mesh in the region decide it to be. The RF waves don't conform to UNLOC region codes, human social groups definitely don't, so focusing on improving the UX of learning what regions are being scoped around the user should be the focus and would likely improve the traffic congestion situation as it is less daunting or "drastic" to disable flood on * since now:
set flood.max.unscoped 2though the same channels, and that allows for new user onboarding and communication, without opening floodgates. Even if it is a new user spamming the local area without knowing it, at most it would impact nodes X hops away and not flood the entire mesh.Each repeater's ZeroHop Advert becomes a welcoming message to new users.