Skip to main content
Pitch In Subscribe

Using RegionMesh Geographic Scoping

Using RegionMesh Geographic Scoping

RegionMesh is a third-party community naming convention for MeshCore (not Meshtastic), built around MeshCore's region/scope feature. It is documented at the community site regionmesh.com and is not an official MeshCore registry or a single operated national mesh. As participating communities grow, using a shared region name helps you manage channel capacity and create region-specific communications without flooding every reachable repeater.

A MeshCore "region" is simply an arbitrary, operator-chosen plain-text name (lowercase alphanumeric plus hyphens, maximum ~29 bytes UTF-8) that the firmware SHA-256-hashes into a 2-byte transport code. There is no ISO 3166-2 system, no built-in country/state code table, and no central firmware registry. A name like us or nd works only because it is a valid arbitrary string the firmware hashes — the firmware never interprets it as a standardized region code. RegionMesh is a convention for getting nearby operators to agree on the same names, adopted by local consensus rather than registered with any authority.

The Problem Scoping Solves

Within a connected MeshCore mesh, every message without a scope floods all repeaters it can reach. That flood is bounded by RF range and hop limit (and by MQTT bridging where enabled) — it does not literally travel coast-to-coast over the air, because LoRa nodes only relay within radio range. But on a dense local network, or across MQTT-bridged segments, unscoped traffic consumes channel capacity that nearby communities do not need to carry. A neighborhood alert in Fargo, ND does not need to be relayed by repeaters that only serve other metros.

How to Enable Regional Scoping

On each repeater, configure the relevant regions using the MeshCore CLI (these are MeshCore commands, not Meshtastic). A child region requires its parent as an argument, and you allow flood forwarding for each name before saving. Verify exact syntax against docs.meshcore.io and regionmesh.com, as the CLI evolves:

region put us
region put nd us
region allowf us
region allowf nd
region save

This example configures a North Dakota repeater to carry both national us traffic and a North Dakota-scoped nd region. The region put nd us form establishes nd as a child of us; the parent argument is required for the hierarchy to take effect. There is no advert step in this flow.

Creating a Regional Channel

When messages are scoped to your region (e.g., nd), they are only forwarded by repeaters that have that region configured. This creates an effective regional "channel" over shared infrastructure without requiring separate hardware or frequencies.

Choosing a Metro Code

If your community covers a metro area not well served by a state name alone (e.g., Dallas/Fort Worth), you can propose a community metro name. There is no central registry — codes are adopted by local consensus. A typical approach:

  1. Join the official MeshCore Discord at meshcore.gg (where much RegionMesh coordination happens), or check regionmesh.com
  2. Propose the name in the appropriate channel (format: lowercase alphanumeric and hyphens only, max 29 bytes UTF-8, e.g., dfw)
  3. Achieve consensus among local mesh operators
  4. The name is then documented and shared so nearby operators adopt the same one — there is no formal registration step

Existing Metro Codes

RegionMesh's documented metro names are bare strings with no us- prefix. Examples (confirm the current list at regionmesh.com rather than assuming):

See regionmesh.com or the official MeshCore Discord for the current complete list.

No comments to display

Back to top