Skye
July 8, 2026, 7:52pm
50
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:
opened 08:17PM - 07 Jul 26 UTC
## 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.