Growing Your Community

Finding Volunteers and Repeater Sites

Finding Volunteers and Repeater Sites

The practical limit on any mesh network's coverage is the number and location of repeaters. Growing a community mesh means finding both people willing to host hardware and locations with good RF exposure.

Identifying Good Repeater Sites

The best repeater sites share these characteristics:

Where to Find Volunteers

The Repeater Volunteer Pitch

The cost and effort for a volunteer are minimal. Emphasize:

Coordinating Through the Community

If you are deploying as part of a regional MeshCore network like RegionMesh, coordinate through the official MeshCore Discord at meshcore.gg and the regionmesh.com community resources. There is no single official "5-step RegionMesh process"; practices vary by community and are set by local consensus. Sharing your repeater's location and settings with nearby operators helps the broader community find and route through it.

Tracking Your Network

As you grow, keep a simple inventory of deployed nodes: location, hardware, firmware version, radio settings, and host contact. This becomes critical for maintenance, upgrades, and troubleshooting.

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.

Onboarding New Members Effectively

Your onboarding process determines whether new members stay active or quietly disappear after their first week. A smooth, welcoming, and technically successful first experience converts curious newcomers into committed network participants.

The Onboarding Journey

  1. Discovery - They learn the network exists
  2. Acquisition - They obtain hardware
  3. Configuration - They get the node on the network
  4. First contact - They exchange messages with another member
  5. Deeper engagement - They explore features, attend events, consider contributing infrastructure

Hardware Recommendations

Standardize on 1-2 recommended hardware options. Prices below are approximate single-unit retail as of mid-2026 and vary by retailer and region. Current recommended starter kit:

Pre-Configured Firmware Distribution

First-Week Checklist for New Members

Assign a "buddy" - an experienced member who agrees to be on-call for a new member's first week. A quick DM check-in on day 3 dramatically improves retention.

Managing Stale and Orphaned Nodes

Every network accumulates abandoned nodes - nodes still visible on the map but owned by someone who has moved on. Management strategies:

Community Events and Meetups

Regular events keep the community engaged and accelerate network growth. Events serve three purposes: recruitment of new members, skill-sharing among existing members, and public demonstration of the network's value.

Build Nights

Monthly hands-on sessions where newcomers build their first node with help from experienced members. Format that works:

Document and promote the event on social media. "Before and after" photos of someone building their first node and seeing it appear on the map are highly shareable.

Annual Range Test

A fun event where participants drive, hike, or bike to test the limits of the network. Structure:

  1. Designate a base station at a high-elevation location
  2. Participants spread out across the coverage area with mobile nodes
  3. Track who can communicate from the farthest point
  4. Record SNR/RSSI at each test location
  5. Share results in a coverage report - excellent content for your community map

The range test also generates real coverage data that helps you identify gaps for future backbone expansion.

Tabletop Exercises

Simulate a disaster scenario where the mesh is used as a coordination tool. Good exercise scenarios:

Tabletop exercises reveal gaps - in coverage, in procedure, and in member skills - before they matter. Document findings and publish improvements.

Meetup Frequency Guidelines

Event TypeFrequencyTime Investment
Build night / intro sessionMonthly3-4 hrs to organize, 2-3 hrs to run
Infrastructure work partyQuarterlyFull day
Annual range testAnnuallyWeekend event
Tabletop exerciseAnnually (before storm season)Half day
Virtual sync callMonthly1 hr