Channel Strategy for Community Networks

Public Infrastructure Nodes

Nodes acting as public infrastructure (repeaters, routers) are commonly configured with the default public PSK on channel 0, which lets them participate in and originate traffic on the public channel. But relaying does not require sharing any channel's PSK. A node rebroadcasts any packet whose LoRa settings (modem preset and frequency) match its own, even packets it cannot decrypt - the packet header is unencrypted. So a node on a private-only channel still relays public-channel traffic. What actually extends range for every local Meshtastic user is matching the regional modem preset and frequency and keeping the default (open) rebroadcast mode - not the channel-0 PSK choice. Running the default public channel 0 governs whether the node can read and originate public traffic, not whether it relays.

Club and Group Channels

Add a secondary channel (index 1 or higher) with a private PSK for your group's internal communications. The node relays both the public channel 0 traffic and your private group traffic. Be aware there is a shared-airtime cost: a node relays all of its channels over one physical radio, so additional channel traffic adds to total airtime and raises channel utilization and contention. Members of your group get private messaging; the public mesh still benefits from your relay - but provision channels conservatively, since more traffic means more congestion on the same duty cycle.

EmComm Channel Strategy

A tiered channel layout works well for emergency communications deployments:

• Channel 0 (public PSK) - general mesh connectivity, open to all Meshtastic users. Use for public outreach and coordination with unknown operators.
• Channel 1 (group PSK) - EmComm team coordination. PSK known to all trained EmComm volunteers.
• Channel 2 (restricted PSK) - incident command. Tightly restricted to net control and command staff only.

This allows the same physical nodes to serve all three audiences without deploying separate hardware for each level. Note that this is access-control segregation only: all three channels share the same physical LoRa airtime, so PSK separation controls who can read each channel - it does not give each tier isolated bandwidth.

Security caution. Channel PSKs are shared symmetric keys with no per-user revocation and no forward secrecy - a leaked key, or a departed member's key, compromises all past captured traffic on that channel until you rotate it. Metadata (who is transmitting, and when) is plaintext on the RF regardless of which tier you use. And a single gateway that uplinks any of these channels to MQTT can leak that channel's content and metadata publicly. Do not treat any Meshtastic channel as secure for genuinely sensitive incident-command content, and make sure no gateway uplinks your command channels to MQTT.

Regional Preset Coordination

When establishing a community channel, document and distribute the following so newcomers can join successfully. Note that name and PSK are per-channel parameters, while modem preset and frequency slot are device-wide LoRa settings shared by all channels on a node:

1. Channel name - must match exactly (case-sensitive). The PRIMARY channel name also auto-derives the default frequency slot unless you explicitly override the slot.
2. PSK - share via QR code, not as a raw string.
3. Modem preset - e.g. LONG_FAST, LONG_SLOW, MEDIUM_FAST. This is part of each device's LoRa radio config (set per device), not channel metadata carried in the PSK/QR. Every node must independently be set to the same preset. Nodes on different presets use different spreading factor / bandwidth / coding and are physical-layer incompatible, so they cannot decode each other's packets.
4. Frequency slot - whether you use the regional default slot (derived from the primary channel name) or a specific slot. To guarantee nodes with different PRIMARY channel names transmit on the same frequency, set the LoRa frequency slot explicitly. Mismatched frequency = no communication.

Node Naming Conventions

Consistent naming makes map views and traceroutes readable. Recommended conventions:

• Long name: CALLSIGN-Location - e.g. KD9XYZ-Home, KD9XYZ-Mobile, MeshAmerica-SiteA. Using a callsign in a node name is purely a naming convention; Meshtastic on 902-928 MHz ISM is Part 15 unlicensed and carries no amateur (Part 97) obligation.
• Short name (4 characters, shown on maps): use callsign suffix or a meaningful location code - e.g. 9XYZ, STA, M001.
• Infrastructure nodes: prefix with the network name (e.g. MeshAmerica-) to distinguish them from personal nodes on map views.

Admin Channel Designation

A legacy approach is to designate one secondary channel as the admin-only channel with a tightly controlled PSK, then configure remote nodes with this channel during initial setup. Be clear about what this means: the admin PSK is itself a high-privilege credential - anyone holding it has full remote administrative control of every node that trusts that channel. It does not grant "admin without elevated access"; the PSK is the elevated access. Store the admin channel QR in a secure location (password manager or encrypted file) and restrict distribution strictly to network administrators. Modern Meshtastic prefers the current public-key remote-admin model (per-node admin public keys via admin_key) over a shared admin-channel PSK - prefer that where available.