I believe the term "region" for transport keyed traffic is a deceptive and incomplete descriptor of the feature.
Transport Keying offers a level of per-hop validation: the repeater that repeated your traffic at least knew your repeat key, as well as any other repeater in the path after it. Keep in mind that this isn't full path validation because it only functions as a per-hop validation mechanism: your last hop could easily lie to you about the path if it knows the transport key.
I believe that the "region" verbiage causes people to think inside the box, and not appreciate the true power of such a capability as "transport keys and codes". Each repeater along a path must know the transport key used to calculate the correct transport code of a packet that should be repeated to the repeater's viewshed/RF footprint.
This can be used to represent regions, but as I just commented on in #2495, international standards are not always internationally useful. The USA does slightly participate in ISO, but does not segment its regions in the standard with more granularity than US States. This presents a gigantic gap in our ability to use global standards such as ISO, since some US States are as big as 1/3rd of Europe as a whole. Without a simple standard for defining a default set of "regions" across the world, this really opens the doors to local conflict about "what the right set of regions" are. Even if there was a standard, people would still argue over the boundaries of each region.
From a regional sociological perspective, US peoples generally group ourselves into more specific geographies than are represented in the ISO standard. From a physical and technical perspective, most US States are extremely large, and would represent quite a large flood/broadcast domain, almost defeating the purpose of the feature.
This is a social problem, not a technical one. I do not believe that "region" is an appropriate way to designate this feature, not only because it doesn't give it credit for it's usefulness (for keeping traffic scoped down to specific repeaters on the mesh), but also because I think the name "region" causes some mesh users to form a cliquey, almost "campist" mindset right out of the gate.
Someone in the PNW has written a custom script or firmware that is blasting their garden sensor data from Eugene, OR all the way up to Vancouver, BC. This kind of use of the mesh, just to make sure their plants are doing alright from across town, is anti-social behavior. Nobody ever explained to them that "you can just create your own region bro, trust me bro", cause that frankly sounds insane. If the user had "created their own region" and only applied it to the repeaters that service the areas that they frequent, they could have programmed their garden sensors to use that "region" rather than spamming the entire god damned mesh on a hashtag channel.
If they used their own "region", they even could have kept using a hashtag channel, or naively flooding, without having any concerns that they were flooding the whole mesh.
I wouldn't be surprised if the operator of this "Garden Bot" is not even aware that people 1000 miles away are having their airtime consumed by their garden data.
Some of the proposed name alternatives for the "region" terminology are: "network", "scope", "VLAN", or "transport key". Feel free to suggest other options!
I believe the term "region" for transport keyed traffic is a deceptive and incomplete descriptor of the feature.
Transport Keying offers a level of per-hop validation: the repeater that repeated your traffic at least knew your repeat key, as well as any other repeater in the path after it. Keep in mind that this isn't full path validation because it only functions as a per-hop validation mechanism: your last hop could easily lie to you about the path if it knows the transport key.
I believe that the "region" verbiage causes people to think inside the box, and not appreciate the true power of such a capability as "transport keys and codes". Each repeater along a path must know the transport key used to calculate the correct transport code of a packet that should be repeated to the repeater's viewshed/RF footprint.
This can be used to represent regions, but as I just commented on in #2495, international standards are not always internationally useful. The USA does slightly participate in ISO, but does not segment its regions in the standard with more granularity than US States. This presents a gigantic gap in our ability to use global standards such as ISO, since some US States are as big as 1/3rd of Europe as a whole. Without a simple standard for defining a default set of "regions" across the world, this really opens the doors to local conflict about "what the right set of regions" are. Even if there was a standard, people would still argue over the boundaries of each region.
From a regional sociological perspective, US peoples generally group ourselves into more specific geographies than are represented in the ISO standard. From a physical and technical perspective, most US States are extremely large, and would represent quite a large flood/broadcast domain, almost defeating the purpose of the feature.
This is a social problem, not a technical one. I do not believe that "region" is an appropriate way to designate this feature, not only because it doesn't give it credit for it's usefulness (for keeping traffic scoped down to specific repeaters on the mesh), but also because I think the name "region" causes some mesh users to form a cliquey, almost "campist" mindset right out of the gate.
Someone in the PNW has written a custom script or firmware that is blasting their garden sensor data from Eugene, OR all the way up to Vancouver, BC. This kind of use of the mesh, just to make sure their plants are doing alright from across town, is anti-social behavior. Nobody ever explained to them that "you can just create your own region bro, trust me bro", cause that frankly sounds insane. If the user had "created their own region" and only applied it to the repeaters that service the areas that they frequent, they could have programmed their garden sensors to use that "region" rather than spamming the entire god damned mesh on a hashtag channel.
If they used their own "region", they even could have kept using a hashtag channel, or naively flooding, without having any concerns that they were flooding the whole mesh.
I wouldn't be surprised if the operator of this "Garden Bot" is not even aware that people 1000 miles away are having their airtime consumed by their garden data.
Some of the proposed name alternatives for the "region" terminology are: "network", "scope", "VLAN", or "transport key". Feel free to suggest other options!