# Using RegionMesh Geographic Scoping

## Using [RegionMesh](https://wiki.meshamerica.com/books/north-american-networks/page/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](https://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](https://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):

- `dfw` - Dallas/Fort Worth
- `bay-area` - [San Francisco Bay Area](https://wiki.meshamerica.com/books/north-american-networks/page/san-francisco-bay-area)
- `greater-atlanta` - Greater Atlanta

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