Thoughts: Canadian Regions Strategy

Bobabate · June 14, 2026, 11:18pm

The more I think about it, the more just LO (Lake Ontario) makes sense to me for that mega region. It’s relevant for both sides of the border. Likely the same will go for any large body of water as it will cause the meshes that surround them to join together. Erie will be next.

anarcat · June 15, 2026, 8:56pm

thanks for the proposal! it generally makes sense to me, but i’ll speak about our little province over here a little bit:

YVR-CoalHarbour:

    qc                      Québec
        bsl                 Bas-Saint-Laurent
        saglac              Saguenay–Lac-Saint-Jean
        capnat              Capitale-Nationale
        maur                Mauricie
        estrie              Estrie
        mtl                 Montréal
        out                 Outaouais / Gatineau
        abt                 Abitibi-Témiscamingue
        cnord               Côte-Nord
        nqc                 Nord-du-Québec
        gasp                Gaspésie–Îles-de-la-Madeleine
        chapp               Chaudière-Appalaches
        laval               Laval
        lanau               Lanaudière
        laur                Laurentides
        mtrg                Montérégie
        cqc                 Centre-du-Québec
        (ncr)               carried by Gatineau-area repeaters; parented under on or qc locally

so i can’t speak for any of the regions listed above to see if those appelations make any sort of sense to them, but i know some of those could be tricky. naming “outaouais” just “out” seems a little offensive, for example. but trickery aside, one thing that strikes me is that we have a single region for “mtl”, and i bet we’re going to need more, just like Thoughts: Canadian Regions Strategy - #40 by emi introduced names for GTA…

i don’t have time to work on such a scheme now and the beauty of a flat scheme is that we can start with mtl and expand later.

but one thing I would say is this:

i think it’s best of regional names are defined by the folks in those regions, at least to a certain extent, with the understanding that they need to somehow register here to avoid conflicts. otherwise i fear that a top-down imposed naming like this simply won’t stick if the folks on the ground don’t have at a least a little bit of say into how things are organised.

that said, i’d say, to avoid any bikeshedding, LGTM.

YVR-CoalHarbour · June 20, 2026, 11:35pm

OK, here’s v1.1 which is not in English and French. I did change OUT to GATOUT, but didn’t do anything else on the QC side. @emi I did minor tweaks in Ontario (I lived in Hamiton for 15 years) and implemented the other comment on niagara. Just suggestions, as always folks who live there get first say :). @anarcat would love you to make changes as you see fit (assuming you agree with the base building blocks).

YVR-CoalHarbour · June 20, 2026, 11:41pm

I cen’t post a non-image file here, so I’ve moved it to Discord: Discord

anarcat · June 22, 2026, 3:30pm

hey, i’m going away for a 4-week vacation so i won’t be able to review this before i’m back.

anyone in quebec is of course free to review this!

anarcat · June 22, 2026, 3:37pm

@moderators can we fix this? it’s a PDF file, it would be nice to be able to upload PDFs here!

otherwise here’s a copy for folks not on discord: https://paste.anarc.at/publish/2026-06-22-fJkm9Ue_38OtPY1ofzIyID4Ugd31ZZB1cEY0-ZiTI1g/CanadaMeshCoreRegionStrategyv1.1.pdf

i tried to dump the whole text here, but it’s too long for what’s permitted here.

YVR-CoalHarbour · June 30, 2026, 4:33pm

@system how about it?

n30nex · July 3, 2026, 6:10pm

Skye · July 8, 2026, 7:52pm

Hello, great work on the regions strategy.

I recently submitted a feature request for a new Region Channel feature which I think would help greatly with region adoption (whatever scheme is used, central or local) by users, and as a result, help with traffic control as well.

Please give it a look, leave a thumbs up on GitHub to get the dev’s attention, or leave a comment there if you have suggestions:

github.com/meshcore-dev/MeshCore

[Feature Request] Region Channels

opened 08:17PM - 07 Jul 26 UTC

skyepn

## Summary Add a new "Region Channel" channel type that has region scope locked… to the same name as the channel, that can be easily discovered and added in client apps. ## Background Region scope adoption has been slow, largely due to end user (companion) confusion about when and how to apply region scope to channel messages. As a result, the majority of channel flood messages are still unscoped, contributing to mesh congestion. This problem is compounded by the lack of a uniform geographical region scheme, which is a very difficult problem to solve and may be unsolvable, as local meshes may ignore any central region authority and create their own regional scope scheme. Another problem is that when a user travels to a new location, the local region scheme and how those scopes are used can be difficult or impossible to learn without research on and off the mesh, negatively affecting portability. ## Proposed Solution The proprosed solution is a new "Region Channel" type, which has minimal code impact but provides major UX improvements. A Region Channel is a hashtag channel that always has the region scope locked to the channel name. Example: region channel "+bc" region scope "bc" (channel prefix discussed below). Region Channels do not require any centralized region schemes, local repeater owners can deploy any scheme they wish, organized locally or even on an ad hoc basis (eg for events). Region Channels can be detected and added easily in apps by using existing discovery packets. ## Changes to Firmware None that I can tell! ## Changes to Apps The companion protocol command CMD_GET_CHANNEL does not provide any metadata about a channel, apps must determine channel type (Public, private, hashtag) and the resulting channel behaviour from the channel name. As this proposal creates a new channel type that has different behaviour than hashtag channels ("#name"), a new channel prefix will be required to denote a Region Channel. I propose the channel prefix "+" to indicate it's a channel plus a region scope. As more repeaters turn off unscoped flood, the plus sign also indicates that the channel may "reach further" than an unscoped hashtag channel, which will probably be the most popular use case. Apps will be required to implement the following behaviour to support Region Channels: - When fetching channel list via companion protocol, any channel starting with the region channel prefix ("+") creates a Region Channel with region scope set to the name of the channel. The channel keys are set the same as hashtag channels, the first 16 bytes of SHA-256("+name"). - The region scope of Region Channels cannot be changed. - Region Channels are displayed in the Channel list with a different icon, and if the app has the ability to filter channels by type, the new Region Channel type should be added to the selector. - Add new menu item "Discover Region Channels" to Add Channel UI. This is the main way that people will add Region Channels, solving discoverability and portability. This should be added as part of the app's onboarding process for new radios. The app should send a zero hop ANON_REQ type 0x01 region discovery packet the same as "Discover Regions" does currently in the main app, but after it completes presents the user with a list of Region Channels that can be selected to add to the companion's channel list. The selected Region Channels are added as above. - Add new Region Channel type to Add Channel UI ("Join a Region Channel" in the main app) for manual Region Channel adding. ## Compatibility and Testing As there are no firmware changes required, and channel names are parsed at the app level, so Region Channels will work with any repeater and companion firmware version. Behaviour will vary across apps that do not support Region Channels, but I have tested the following: 1. Create a Region Channel with `meshcore-cli` using command `add_channel +test`: ```BE59D635> get_channels 0: Public [8b3387e9c5cdea6ac9e5edbaa115cd72] 2: +test [0800a352c8f9e7f930ced54f4caf31b8]``` 2. Connected the companion to a laptop and connected to https://app.meshcore.nz/ 3. Web app shows Region Channel "+test" as a Private Channel, presumably the keys are not set correctly and users will not be able to communicate with apps that do support Region Channels, untested. (see attached) <img width="346" height="347" alt="Image" src="https://github.com/user-attachments/assets/eb5a1b31-4e76-4a95-ad09-02a62811f156" /> It is currently possible to create a private channel named "#test" in the main MeshCore app, not sure how that's handled as it's closed source, perhaps by comparing the key to the SHA-256 of the channel name to detect if it's a hashtag channel or a private channel. The same logic should be applied to the creation of private channels named "+test", or to avoid confusion, apps should not allow private channels created with the first character in "#+$" (I believe $ is also reserved). ## Additional Background This proposal came about due to challenges our regional mesh has had during experiments with turning off unscoped flood to mitigate traffic. The problem arises in the case where a repeater is serving dual roles, both as a repeater for local traffic and as a link between regions. The repeater owner cannot turn off unscoped flood, because local flood messages will also be disabled. The addition of Region Channels will allow "dual role" repeater owners to turn off unscoped flood, while still providing a way for local and new users to communicate through the Region Channels discovery mechanism. Repeaters only need to be configured with one or more local scopes, and the onboarding discovery process will create "ready to use" channels with minimum friction.

Skye · July 14, 2026, 6:56pm

We are using region “bcint” for the BC interior (basically anything that isn’t swbc) how would I get that added to the official list? Should I draw a boundary?

What I’m seeing above is massive overkill for us, we only use regions “bc” (for an eventual connection to swbc) and “bcint”.

Magister · July 24, 2026, 11:56am

For Québec, especially great Montréal, some people are confused between what we call “montreal” and the island/city and the north/south neighbourhood.

I propose:

laur
- hlaur # hautes laurentides, think st-jerome and up
- blaur # basses laurentides, think the belt from oka to lorraine
gma # the great montreal area or “gmtl” if you prefer
- blaur
- laval
- mtl
- rsm # rive sud of montreal, think the belt from chateauguay to varennes
mtrg
- rsm
- mtrgs # monteregie sud, thinks st-hyacinthe

lharris · July 24, 2026, 10:14pm

Been looking at the discussion on region codes and was wondering if the Amature radio maiden head codes had been considered. They allow for broad regions down to very tight local areas. The system is already setup and works world wide. The tools exist to convert a map reference or geographic areas to a code.

so southern BC is cn, my area in Burnaby is cn89