Skip to content

RFC001: MeshCore scopes - #1

Open
nwithan8 wants to merge 2 commits into
masterfrom
rfc001_meshcore_scopes
Open

nwithan8 wants to merge 2 commits into
masterfrom
rfc001_meshcore_scopes

Conversation

@nwithan8

@nwithan8 nwithan8 commented Sep 9, 2026

Copy link
Copy Markdown
Member

Proposal for a high-level, hierarchical scope tree for the Colorado Mesh MeshCore network, based in part on the existing IATA code-based regions utilized across Colorado Mesh.

These scopes are intentionally broad, allowing smaller, local-level scopes to be introduced as needed by the relevant community members.

For those unfamiliar with GitHub, you can view the main document here: https://github.com/Colorado-Mesh/organization/blob/rfc001_meshcore_scopes/RFC/001_MeshCore_Scopes/rfc001_meshcore_scopes.md

@beala

beala commented Sep 10, 2026

Copy link
Copy Markdown

Thanks for putting this together so quickly!

I think it would be useful to have a plain english call-to-action that makes it very clear what you need to do. Something like:

Scopes are a meshcore feature that allow senders to limit the reach of their messages. This is a proposal that makes scopes opt-in. What does this mean?
I send messages and do NOT maintain a repeater or other infrastructure...
Messages you write will continue to transmit across the entire mesh. Once roll out is complete, you will have the option of limiting your messages to a certain region by tagging your messages with a scope in your meshcore client. Doing so will help limit congestion on the mesh and make it more reliable for all users. Guides on how to do this will be forthcoming.
I maintain a repeater...
Once the proposal is finalized, please add the configuration to your repeaters. There will be a tool that will make this as simple as copying-and-pasting a configuration command into the repeater CLI. It's important that a critical mass of repeaters add this configuration. If a critical mass is not achieved, none of the benefits can be realized.
I maintain a bot or other automation...
Once the proposal is finalized, consider if limiting the reach of these automated messages would be appropriate. Doing so will help make the mesh less congested and more reliable for all users. Guides on how to do this for common automations (like meshcore-bot) will be forthcoming. It's not possible to use scopes until repeaters are updated, so there is currently no action to take.

And a section on benefits:

Adding scopes will enable the following benefits:

  • War driving traffic can be limited to the region that the war driver is in. For example, a war driver in Colorado Springs will not congest the mesh in Fort Collins.
  • Bots and automations can be limited to a particular region. For example, a bot that sends out alerts about wildfires can limit those alerts to the relevant regions, cutting down on alert-fatigue. An overly noisy alert channel tends to be ignored.
  • Message senders have the option of limiting region specific channels like #den to only transmit across the co-den region. This is purely opt-in and will not prevent messages from propagating further if the sender does not want their reach limited.

As far as the proposed configuration, I think one unanswered question is what "distributor" repeaters should do. Will Lookout Mountain have a scope? How does this fit in to the backhaul frequency that some folks are looking into?

@zevaryx

zevaryx commented Sep 10, 2026

Copy link
Copy Markdown

We also need to make sure we provide guides on how to set this up, as well as when to use it. The current documentation from MeshCore is not the easiest to parse and understand

@ajquick

ajquick commented Sep 11, 2026

Copy link
Copy Markdown

I think we should keep the general Colorado structure and the IATA-based local scopes, but tweak the naming and upper-level structure so it scales better outside Colorado. Instead of "us → west → mnw → co → co-fr → co-den", I’d make "west" the broad western scope, use "rockies" for the Rocky Mountain region, and then use "us-co" for anything Colorado-specific. That makes every scope understandable on its own, avoids ambiguous abbreviations like "mnw", "co", or "fr", and allows Wyoming, Montana, Alberta, BC, etc. to eventually participate in the same "rockies" scope without putting Canada underneath "us". I’d still keep the IATA airport codes for the local regions since those are already recognizable and established.

  • "west" — Western North America
    • "rockies" — Rocky Mountain region
      • "us-co" — Colorado
        • "us-co-front-range"
          • "us-co-den" — Denver
          • "us-co-fnl" — Fort Collins / Northern Colorado
          • "us-co-cos" — Colorado Springs
          • "us-co-pub" — Pueblo
        • "us-co-western-slope"
          • "us-co-gjt" — Grand Junction
          • "us-co-mtj" — Montrose
          • "us-co-dro" — Durango
        • "us-co-central-mountains"
        • "us-co-eastern-plains"
        • "us-co-san-luis-valley"
          • "us-co-als" — Alamosa / San Luis Valley
      • "us-wy" — Wyoming
      • "us-mt" — Montana
      • "us-id" — Idaho
      • "us-ut" — Utah
      • "us-nm" — New Mexico
      • "ca-ab" — Alberta
      • "ca-bc" — British Columbia

Something like that.

- Add US National Grid codes
- Add neighboring state support
@zevaryx

zevaryx commented Sep 15, 2026

Copy link
Copy Markdown

I think that we should drop the iata and us-co prefixes, opting to keep things simpler. Maybe something like:

*                               Flood / any (default scope)
us                              Entire United States
└── west                        Western United States (+ Canada)
    └── co                      State of Colorado

            [GEOGRAPHIC ZONES]

        └── co-ws               Western Slope geographic zone
        └── co-fr               Front Range geographic zone
        └── co-ep               Eastern Plains geographic zone
        └── co-cm               Central Mountains geographic zone
        └── co-sl               San Luis Valley geographic zone
            
            [IATA / COLORADO MESH REGIONAL ZONES]
                
        └── ase              ASE IATA code / Aspen
        └── cos              COS IATA code / Colorado Springs
        └── cez              CEZ IATA code / Cortez
        └── den              DEN IATA code / Denver Metro
        └── dro              DRO IATA code / Durango
        └── ege              EGE IATA code / Eagle, Vail, Breckenridge
        └── gjt              GJT IATA code / Grand Junction
        └── guc              GUC IATA code / Gunnison, Crested Butte
        └── mtj              MTJ IATA code / Montrose
        └── fnl              FNL IATA code / Fort Collins, Loveland, Greeley
        └── pub              PUB IATA code / Pueblo
        └── als              ALS IATA code / San Luis Valley, Alamosa
        └── laa              LAA IATA code / Lamar, La Junta
        └── stk              STK IATA code / Sterling, Julesburg
        └── tex              TEX IATA code / Telluride, Ouray, Ridgway
        └── hdn              HDN IATA code / Yampa Valley, Hayden, Craig

            [CITY/COUNTY]

        └── city-denver      City of Denver
        └── city-loveland    City of Loveland
        └── cnty-larimer     Larimer County

We'd want to keep the co- prefix on geographic zones for clarity (2 characters = higher chance of collision)

I'm also 100% for a different way to differentiate city and county, but I wanted to put something out there for it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants