Region Scopes

Contents

1. Status & honest summary
2. TL;DR
3. Practical takeaways
4. Firmware differences — v1.15 vs v1.16
5. What is a region scope?
6. The PUW region hierarchy
7. How scope is embedded in a packet
8. Route types — which can carry scope?
9. Channels vs direct messages
10. Scope filtering — isolation tests
11. Early experiment (superseded)
12. Node & region discovery
13. Scopes tracked by this observer
14. Open hypotheses & planned tests
15. References & evidence

Status & honest summary — June 22 2026

This page documents an in-progress investigation. Below is exactly what we've proven, what we haven't, and what's left. Testing is paused for now.

✓ Confirmed (two independent observers — CoreScope + Beacon — agree on every packet)

• Channel scopes are a cryptographic transport code (TC₁) in the packet, not a text label. Two observers reproduced identical TC₁ values for all 25+ test packets.
• Scopes are name-derived — the same scope name produces the same TC₁ everywhere. Provisioning is name-only; no shared password.
• Repeater-level filtering is real and happens at Kamiak (CD37). Scopes Kamiak actively forwards (puw, geg) reach Pullman-Obs-RF; palousetest2 (saved only on CB59, not Kamiak) never does.
• CB59 forwarded all scoped packets regardless of its configured region list — confirmed across three isolation-test rounds where its list was temporarily reduced to a single scope. The mechanism is not *: in MeshCore firmware, * is the reserved root region (RegionMap id 0) that governs unscoped ROUTE_TYPE_FLOOD legacy traffic only — it is not a pattern that matches all named regions. Whether unscoped floods propagate is controlled separately by region allowf / region denyf on the * entry (default: allow). CB59's forwarding of scoped TRANSPORT_FLOOD packets outside its region list is a distinct, unexplained behavior — possibly a firmware default or CB59-specific configuration not yet fully understood.[1]

◑ Strongly supported, not yet definitively proven

• Kamiak (firmware v1.15) appears to require a reboot to activate newly-added regions. palousetest and palousetest3 are saved on Kamiak, carry the flood (F) flag, and have matching name-derived keys — yet Kamiak drops them, while forwarding long-standing scopes and the identical palousetest on CB59 (v1.16). Every other cause (RF, key mismatch, missing flag, absence from list) has been ruled out. The remaining explanation: v1.15 loads its active forwarding table at boot, and these were saved but never rebooted in. Definitive proof requires rebooting Kamiak, which has not been done.

◯ Not done / open

• Reboot Kamiak and re-send palousetest — the one test that would confirm the v1.15 reboot theory. (Held off intentionally — don't want to bounce the production repeater.)
• palousetest4 discovery test — palousetest4 is on Kamiak only (saved, F flag, not rebooted). Pending: get within Kamiak's RF range, away from CB59, discover it from Kamiak, and send it in #test. If it dies, that's another data point that v1.15 doesn't forward saved-but-not-rebooted regions. Both CoreScope and Beacon are already configured to decode it.
• St. John propagation test — needs the St. John operator to add palousetest and a companion near St. John to originate a scoped message. Not yet coordinated.
• Pullman-side A/B — send palousetest from a Pullman companion (Test A: no local repeater config; Test B: add it to a Pullman repeater) to check propagation from that direction. Not done.
• Deny-flood behavior (region denyf on * or a named scope) and repeaters with no named regions configured — never tested; no such repeater available in the PUW area. Note: a region-less repeater is not the same as a * repeater — * controls unscoped flood policy only.
• TRANSPORT_DIRECT (route 0x03) — 0 captured in 24,000+ packets; still never observed.

Caveat: the isolation-test tables further down were built up across many config changes during a long session. The clean, trustworthy comparisons are the back-to-back sends where a working scope (puw/geg) and a failing one (palousetest) were transmitted seconds apart with the RF link demonstrably up. Single "not seen" results without a same-window control are weaker.

TL;DR

• Region scopes apply only to hashtag channels right now — not DMs or room-server paths. DMs use FLOOD/DIRECT routing with no transport-code field, so there's nothing to scope. The protocol does reserve TRANSPORT_DIRECT for possibly scoping direct messages in the future, but it has never been observed in any captured packet.[2][4]
• A scope is a name-derived cryptographic code, not a text label. TC₁ = 16-bit HMAC-SHA256 keyed on the scope name; the same name yields the same code on every node, so no shared password is needed. Repeaters recompute it locally to decide relay or drop.[1]
• Repeater-level filtering is real and happens at Kamiak (CD37). #puw reached Pullman-Obs-RF through Kamiak while #palousetest sent 12 seconds later died at CB59 — RF ruled out. Verified by two independent observers (CoreScope + Beacon).[3][7]
• * is not a "match everything" wildcard. In MeshCore firmware, * is the reserved root region (RegionMap id 0, name "*") — the bucket for unscoped ROUTE_TYPE_FLOOD legacy traffic only. It has no effect on scoped TRANSPORT_FLOOD packets, which still require a TC₁ match to a region the repeater explicitly carries. Whether the * bucket forwards unscoped floods is governed by region allowf / region denyf on that entry (default: allow). CB59's forwarding of scoped packets outside its region list is a separate unexplained behavior — not caused by *.[1]
• Region hierarchy — puw → e-wa → wa → pnw → west, with ie a cross-border scope (Spokane/CdA) directly under pnw. The hierarchy is administrative: a repeater only forwards scopes it explicitly carries. gessaman recommends every repeater carry its full ancestry regardless of antenna height — "limited RF range is not a reason to strip tags."[11]
• Kamiak also carries us, us-wa, and pnwd — a parallel US-format naming scheme alongside the PNW hierarchy. Full lists: Kamiak = puw ie geg wa us-wa us pnwd pnw e-wa palousetest palousetest3; CB59 = west pnw wa ie e-wa puw geg palousetest palousetest2 palousetest3 us-wa us-west.[9]

Practical takeaways — where regions actually matter

Honest framing after all this testing: region scoping is a minor factor in day-to-day use right now. What you actually touch is hashtag channels — #emergency, #thepalouse, and the like. A region scope just limits how far one of those channel floods travels.

• Private hashtag channels are already private. They're encrypted with their own channel key, so they're naturally "scoped" to whoever has the key — independent of region scoping.
• Region scoping only touches public hashtag channels today. DMs aren't region-scoped (they route by FLOOD/DIRECT with no scope field). A future TRANSPORT_DIRECT path could scope DMs, but it doesn't exist in practice yet.[2][4]
• Default scope vs. allow-flood scope is still fuzzy and untested. Best current understanding: setting a default scope (say puw) while still allowing geg floods probably does nothing to block geg. Denying geg would keep geg traffic off a public channel like #emergency — but should not block a DM from a geg node to a puw node, since DMs aren't scoped. This needs more digging; deny-flooding has not been tested.
• gessaman's guidance: every repeater should carry its full region ancestry regardless of antenna height or coverage — "limited RF range is not a reason to strip tags." A repeater's tags don't control how far its traffic travels; the message's scope and the mesh layout do.[11]
• Single- vs multi-metro is about geography, not antenna height. Two different axes: ancestry (the vertical chain west→pnw→wa→e-wa→puw) every node carries regardless of height; and sibling metros (horizontal, like puw + geg) which only a node that physically bridges two metro areas should carry. gessaman's generator approximates this via repeater type, but the deciding factor is location.[12] Locally:
  • Kamiak — a high-site, but sits in the middle of the Palouse. It covers puw widely but doesn't bridge to another metro → single-metro (puw + ancestry). The geg tag it currently also carries is optional/extra, not required by its position.
  • St. John — a high-site on the puw/geg border → a genuine bridge → multi-metro (puw + geg + ancestry).
  So a tall mast in the center of one metro is still single-metro; what earns the extra sibling tag is straddling a boundary.

Firmware matters — v1.15 vs v1.16 region handling

A concrete, reproducible difference surfaced during testing between the two firmware versions running on local repeaters.

Evidence: palousetest and palousetest3 are saved on Kamiak (v1.15) with the flood (F) flag and matching name-derived keys, yet Kamiak drops them — while CB59 (v1.16) forwards the identical name-only palousetest, and Kamiak forwards its long-standing scopes (puw, geg) that were present at last boot. Every other cause was ruled out: RF (a control scope went through in the same window), key mismatch (name-only provisioning, two observers decode it), missing flood flag (it has F), and absence from the list (it's there).

What is a region scope?

A region scope is a named geographic area that MeshCore uses to limit how far a channel message floods. When you tap "Set region scope" on a hashtag channel and pick puw, every repeater in range checks whether it's configured for the puw region — and only forwards the message if it is.

The scope is embedded in the radio packet itself as a cryptographic code. Repeaters don't read the message text; they just check the code against their own region list and decide to relay or drop.

The PUW region hierarchy

MeshCore regions form an administrative hierarchy, but parent/child relationships are not automatic. A repeater carrying wa does not automatically forward puw-scoped messages — it must explicitly carry puw too. By convention, every repeater should carry its full ancestry (e.g. a puw repeater carries west · pnw · wa · e-wa · puw), but this is operator responsibility, not firmware enforcement.

Hierarchy source: gessaman.com/meshcore/regions/ — confirmed full chain: west → pnw → wa → e-wa → puw. geg (Spokane metro) confirmed as child of e-wa. ie (Inland Empire) is a cross-border scope, direct child of pnw, carried by both Spokane WA and Coeur d'Alene ID repeaters. szt (Sandpoint ID) is part of the PNW hierarchy but not carried by repeaters in the PUW area. Note: "hierarchy is administrative, not functional" — a repeater must explicitly carry each scope, parent scopes do not automatically forward child traffic.

How scope is embedded in a packet

Every MeshCore radio packet starts with a 1-byte header. The two lowest bits of that byte define the route type, which determines whether transport codes (and therefore scope) are present.

Header byte — bit layout:

Bits 7–6: version  ·  Bits 5–2: payload type (GRP_TXT=5, TXT_MSG=2, ADVERT=4…)  ·  Bits 1–0: route type

Example above: 0x14 = ver 0 · GRP_TXT · TRANSPORT_FLOOD — a scoped channel message.

TRANSPORT_FLOOD packet — the only type channels use:

TC₁ (transport_code_1) is the scope filter — a 16-bit value derived from HMAC-SHA256 of the packet content, keyed with SHA256(region_name).[1] It is unique per packet even for the same scope. Repeaters recompute this value locally and compare it to their configured regions.[1] TC₂ is reserved for future use — 0x0000 in 385 of 386 captured packets.[2][5] The path length byte 0x40 encodes (hash_size−1) in bits 7–6 and hop count in bits 5–0; channel messages always start at 0 hops.[2]

Protocol reference: docs.meshcore.io/packet_format · deepwiki.com — Region Filtering & Transport Codes

Route types — which can carry scope?

Transport codes (and therefore scope) only exist in the packet when the route type is a TRANSPORT variant. FLOOD and DIRECT packets have no transport codes field at all.[2]

Counts from CoreScope DB query across 23,845 transmissions, 3 observers, June 10–22 2026.[3] TRANSPORT_DIRECT is defined in the protocol spec[2] but has not appeared in any captured packet.

Channels vs direct messages

These use fundamentally different routing mechanisms. Scope is a channel concept — it cannot be set on a DM from the standard app UI.

Hashtag channels — TRANSPORT_FLOOD · 0-hop path

When you send a message in #thepalouse or #test with a scope set, it goes out as TRANSPORT_FLOOD with the scope code in TC₁ and an empty hop list (0x40 = 0 hops). Repeaters that carry the matching region forward it; others drop it.[1] The scope is literally the routing table. All 265 GRP_TXT packets in our capture are TRANSPORT_FLOOD — no exceptions.[4]

Direct messages — FLOOD or DIRECT · no transport codes

When a DM's path is unknown it uses FLOOD (route bits 01) — no transport codes field exists at all. Once a path is established it switches to DIRECT (route bits 10) — also no transport codes. You cannot set a relay path on a channel, only on DMs and room servers.

*The 31 TRANSPORT_FLOOD TXT_MSG packets break down as: 25 pre-path-setup DMs from June 10–18 with explicit Kamiak hops (transport codes present but not matching any region scope), and 6 from June 22 scoped to #puw — likely from a node with v1.15.0's experimental "Default Region Scope" setting enabled, which applies scope to all outbound packets including DMs. This is opt-in and not standard behavior.

Scope filtering — isolation tests, June 22 2026 Complete

CB59's region list was the same throughout all tests. The rounds reflect which scope the companion app was actively sending with — set by discovering regions from CB59 and selecting one. The companion app's "Heard X Repeats" count in each message also corroborates Kamiak's filtering behavior.

Round A — Companion sending with puw scope (discovered from CB59)

Round B — Companion sending with geg scope (discovered from CB59)

Round C — Companion sending with palousetest scope (CB59 default)

All messages sent in #test channel. Transmitter: NOBBY-85ee. CB59 full region list: west · pnw · wa · ie · e-wa · puw · geg · palousetest · palousetest2 · palousetest3 · us-wa · us-west. Kamiak full region list: puw · ie · geg · wa · us-wa · us · pnwd · pnw · e-wa · palousetest · palousetest3. Deny-flooding and zero-region repeater behavior have not been tested.

Repeater-level scope filtering — early experiment Superseded

Scope filtering at the observer level — CoreScope decoding TC₁ and attributing a scope name — is easy to confirm. The harder question is whether scope actually gates forwarding at the repeater level: does a repeater without a given scope drop floods it would otherwise have forwarded?

To test this, two experimental scopes were created:

• palousetest — configured on Kamiak (CD37) and PALSWA-NBBY-NOBS / CB59
• palousetest2 — configured on node 9904 (a non-repeating node), not on CB59, and not on Kamiak

Both scopes added to CoreScope hashRegions and Beacon scope list so observations can be decoded and tracked by two independent data sources.

Test 1 — palousetest, June 22 2026 · 22:03:42

Test 2 — palousetest2 vs #wa, June 22 2026 · 22:23–22:25

Two messages sent 90 seconds apart. palousetest2 lives on node 9904 (a non-repeating node), not on CB59 and not on Kamiak. #wa is a standard scope all repeaters carry. (Note: the table below shows a CB59 path for palousetest2 — that detail conflicts with palousetest2 not being on CB59 and is unresolved; it's one reason this early card is superseded by the cleaner later tests.)

Node & region discovery — CONTROL / ANON_REQ / RESPONSE

When a node wants to discover nearby repeaters and learn their region config, it uses three packet types. Source-confirmed names and structure from DeepWiki MeshCore (Packet.h, Mesh.cpp, payloads.md).

Packet types — source-confirmed

Observed sequence — live captures, June 22 2026, 22:20 UTC[8]

1. CONTROL / DISCOVER_RESP (0x2E) · DIRECT — repeater broadcasts its identity with session tag and public key. Payload byte 0 = 0x92 (high bit set = sub-type). CB59 example: 2E 00 92 2E 2B A9 3A 89 CB59 5B17…
2. ANON_REQ (0x1E) · DIRECT — our node sends an encrypted anonymous request to that specific repeater. Exact request content unknown to observers (encrypted). Fires during "Discover Regions" and also during telemetry requests to a repeater.
3. RESPONSE (0x06) · DIRECT — repeater replies with encrypted application data. Content not visible to observers. Likely contains region list or transport key data, but application-defined.

One exchange per visible repeater per session. The "Discover Regions" action likely triggers this sequence for each known repeater. ANON_REQ also fires during telemetry requests — it appears to be the general mechanism for any secure peer-to-peer query, not region-exclusive.

Discover Repeaters — separate FLOOD broadcast

"Discover Repeaters" is distinct from region discovery. It sends an ADVERT (type 4, 0x11) on FLOOD — a broadcast that propagates outward hop by hop. Nearby repeaters reply with CONTROL / DISCOVER_RESP packets. In Kamiak's neighbor discovery session (22:48 UTC), CONTROL responses came back from nodes FDA5, 7522, 95FF, and CB59 announcing their identities — all within direct RF range of Kamiak.

DMs with Default Region Scope (v1.15.0+) — an experimental setting in the MeshCore companion app that applies a chosen scope to all outbound packets, including direct messages. Not standard behavior; opt-in only.

Scopes tracked by this observer

CoreScope is configured to recognize these region scope codes in captured packets. Any TRANSPORT_FLOOD packet whose TC₁ matches the HMAC derivation of one of these names is attributed to that scope.

Scope packets arriving with unrecognized TC₁ values are stored with scope_name = NULL. Adding a scope name to the observer config does not affect repeater behavior — it only affects what the observer can decode.

Open hypotheses & planned tests

What we still don't know, why it matters, and how to test it. Evidence listed under each item is what we have so far.

1. Definitive repeater filtering proof — pending St. John

Hypothesis: Kamiak (CD37) received the palousetest2 flood on June 22 and dropped it because palousetest2 is not in its region list.

Why it matters: Our current evidence is observational — we infer the drop from Pullman-Obs-RF not seeing palousetest2, while #wa went through Kamiak 90 seconds later. The Kamiak CLI confirms the config, but we never captured the packet at Kamiak itself.

Procedure — requires coordination:

1. St. John repeater operator adds palousetest to the St. John region list.
2. Companion near St. John does "Discover Regions" from St. John to pick up palousetest, then sends #palousetest scoped to it in #test. CoreScope logs it automatically — no one needs to be watching live.
3. Companion near Pullman (Test A — no repeater config): A companion in Pullman that has previously discovered palousetest (e.g. via CB59 when in range) sends #palousetest scoped to it — no Pullman repeater needs to carry it. CoreScope watches if it reaches Nobbserver via the reverse path.
4. Compare: if Pullman-Obs-RF sees the St. John transmission, the CB59→Kamiak→St. John chain is live. If the Pullman companion's transmission reaches Nobbserver, the reverse path through Kamiak works.

Pullman-Obs-RF is downstream of Kamiak via 95FF and is not directly reachable from CB59 — it serves as the "behind Kamiak" witness. A companion near St. John is required because the app can only send with scopes discovered from a local repeater — you cannot manually enter a scope.

Test B (later A/B): Add palousetest to a Pullman-area repeater, companion near Pullman discovers it from that repeater, sends again. Compare reach vs. Test A to see whether a local Pullman repeater carrying the scope changes propagation behavior from that direction.

2. Default region flooding — unconfigured repeater behavior CB59 confirmed

Hypothesis: Some repeaters forward all TRANSPORT_FLOOD packets regardless of TC₁ — regardless of which named regions they carry. A single such repeater in a path passes scoped traffic it was never intended to relay, defeating any scope-based containment on that hop.

Note on *: This behavior is not explained by the * root region. In MeshCore firmware, * (RegionMap id 0) is the reserved bucket for unscoped ROUTE_TYPE_FLOOD legacy traffic — it has no bearing on scoped TRANSPORT_FLOOD packets. Whether * passes unscoped floods is controlled by region allowf / region denyf (default: allow). CB59 forwarding scoped packets outside its region list is a separate, unexplained behavior.

Confirmed for CB59: Isolation tests across 3 rounds reduced CB59's configured region list to a single scope (puw, then geg, then palousetest). In every round CB59 relayed scopes outside its reduced list without exception. The configured region list appears to affect only ANON_REQ discovery responses — not TRANSPORT_FLOOD forwarding. What remains open: whether this is a firmware default for all repeaters, or specific to CB59's deployment or firmware version.

What hasn't been tested: Every repeater in the PUW area has at least some region scopes configured — no repeater with a completely empty region list has been observed or tested. Active deny-flooding (a repeater explicitly suppressing a scope it would otherwise pass) has also not been tested. Both are separate experiments for later.

3. TRANSPORT_DIRECT (0x03) — when is it used?

Hypothesis: TRANSPORT_DIRECT exists in the protocol spec for scoped direct messages — a DM that also carries a region scope. It may be used in very specific scenarios (e.g. room server delivery with a scope, or future firmware features) and is not yet implemented in v1.15–1.16.

Current evidence: 0 of 23,845 captured packets use route type 0x03. DeepWiki confirms the type exists structurally.

Procedure: Monitor captures across firmware upgrades. If TRANSPORT_DIRECT appears, record the payload type and path structure to determine the use case.

References & evidence

1. [1] DeepWiki — Region Filtering and Transport Codes (deepwiki.com/meshcore-dev/MeshCore/7.6). Source-derived documentation of TransportKey::calcTransportCode(), RegionMap::findMatch(), and the REGION_DENY_FLOOD flag. Confirms TC₁ = 16-bit HMAC-SHA256 of payload type + content; TC₂ = reserved. Confirms repeaters check allowPacketForward() using TC₁ match against their region list. Also documents wildcard.flags field in binary storage format (/regions2) — confirms * is persisted as RegionMap id 0. · gessaman.com — Region Strategy (gessaman.com/meshcore/regions/): "* is always present as the root of the region tree (RegionMap: id 0, name "*"). It is not a pattern that matches every configured region name; it is the bucket for unscoped flood traffic (ROUTE_TYPE_FLOOD). Whether such packets are forwarded is controlled by flood policy on that root entry (region allowf / region denyf for * — by default, flood is allowed)."
2. [2] DeepWiki — Network Protocol (deepwiki.com/meshcore-dev/MeshCore/7). Packet binary format: header byte field layout (bits 7–6 = version, bits 5–2 = payload type, bits 1–0 = route type), path length byte (getPathHashSize() = (path_len >> 6) + 1), route type enumeration. Confirms transport codes field (4 bytes) appears only on TRANSPORT_FLOOD (0x00) and TRANSPORT_DIRECT (0x03).
3. [3] CoreScope SQLite DB — /docker/meshmonitor/corescope/data/meshcore.db. 23,845 transmissions captured June 10–22 2026 across 3 observers: Nobbserver (NOBBY-85ee, Heltec V4.3), Pullman-Obs-RF (Heltec V3), KC7BIV Observer (Heltec T114). Route type breakdown: 386 TRANSPORT_FLOOD · 17,441 FLOOD · 6,018 DIRECT · 0 TRANSPORT_DIRECT. Query: SELECT route_type, COUNT(*) FROM transmissions GROUP BY route_type.
4. [4] CoreScope DB — GRP_TXT payload type. All 265 captured GRP_TXT packets (payload_type=5) use TRANSPORT_FLOOD (route_type=0). Zero GRP_TXT packets with any other route type. Query: SELECT COUNT(*) FROM transmissions WHERE route_type=0 AND payload_type=5 → 265; same count as all GRP_TXT.
5. [5] CoreScope DB — TC₂ field verification. 385 of 386 TRANSPORT_FLOOD packets have TC₂ = 0x0000 (bytes 3–4 of raw_hex). One exception: TC₂ = 7B92 (origin unknown, not yet attributed). Query: SELECT substr(raw_hex,7,4), COUNT(*) FROM transmissions WHERE route_type=0 GROUP BY substr(raw_hex,7,4).
6. [6] CoreScope DB — palousetest2 vs #wa comparison. Transmission id 23830: scope #palousetest2, channel #test, 2026-06-22 22:23:22 UTC, observer_idx=1 (Nobbserver) only, paths [] and ["CB59"]. Transmission id 23831: scope #wa, channel #test, 2026-06-22 22:24:53 UTC, Nobbserver (paths [] and ["CB59"]) plus Pullman-Obs-RF (path ["CB59","CD37","95FF"]). Kamiak hash = CD37.
7. [7] Beacon scope panel (beacon.palouse-mesh.net). Independent Postgres-backed observer tracking scopes across all configured region names. Both palousetest and palousetest2 appear in the Beacon scopes table for June 22 2026, with 1 packet and 1 observer each — consistent with CoreScope DB. Beacon runs on a separate Pi (192.168.1.62) with its own MQTT subscription.
8. [9] Kamiak (CD37) admin CLI — direct region verification. Command: region run on Kamiak repeater via admin access, June 22 2026. Full region list: ie geg wa us-wa us pnwd pnw e-wa palousetest. Confirms: (a) palousetest is configured, (b) palousetest2 is not configured, (c) previously undocumented scopes us, us-wa, and pnwd are active on Kamiak, (d) puw and west are not on Kamiak.
9. [8] Live packet capture — node discovery exchange. Observed by Nobbserver, June 22 2026 ~22:20 UTC. CONTROL (header 0x2E, DIRECT) from CB59 with session tag 2AA2FC1E — DISCOVER_RESP sub-type (payload[0]=0x92, high bit set per Mesh.cpp:69); ANON_REQ (header 0x1E, DIRECT) from NOBBY-85ee to CB59; RESPONSE (header 0x06, DIRECT) from CB59 to NOBBY-85ee. All DIRECT routing, 1-byte path hashes, 0 hops. Separate exchange observed to dest hash 94 in the same session.
10. [10] regionmesh.com — MeshCore Region Configuration (regionmesh.com/meshcore-region-configuration/). Documents a US-wide parallel naming convention: us (nationwide) → us-wa (Washington), us-co (Colorado), etc. CLI syntax: region put us-wa us. Explicitly states there is no single nationwide naming standard — local communities determine conventions. Kamiak carries both the PNW community names and this US-format scheme.
11. [11] gessaman.com — MeshCore Region Strategy (gessaman.com/meshcore/regions/). Full PNW region hierarchy: west → pnw → wa → e-wa → puw; ie as cross-border direct child of pnw; geg (Spokane metro) as child of e-wa. Confirms "hierarchy is administrative, not functional" — parent scopes do not automatically forward child-scoped traffic. Every repeater must explicitly carry its full ancestry. Note: us and us-wa are not part of the PNW community hierarchy — they belong to a separate US-wide naming scheme (us → us-wa) documented at regionmesh.com. Kamiak carries both naming systems in parallel.
12. [12] gessaman.com — Region Config Generator (gessaman.com/meshcore/regions/config/). Interactive tool that generates ready-to-paste region def CLI commands from a repeater's location and type. Repeater type drives the recommendation: Mountaintop / High-Site pre-selects multiple metros (multi-metro, e.g. puw + geg); Home / Residential uses a single metro with full ancestry. Notes region def defines the full hierarchy in one command on firmware v1.16.0+.

Packet type names confirmed from MeshCore source: PAYLOAD_TYPE_RESPONSE=0x01 (Packet.h:20), PAYLOAD_TYPE_ANON_REQ=0x07 (Packet.h:26), PAYLOAD_TYPE_CONTROL=0x0B (Packet.h:30). CONTROL DISCOVER sub-types gated by payload[0] & 0x80 (Mesh.cpp:69). Source analysis via DeepWiki MeshCore.