# Channel Management

How Meshtastic channels and PSKs work, how to share them via QR code, and strategies for deploying channels in community networks.

# Understanding Channels and PSKs

## Overview

Meshtastic supports up to **8 simultaneous channels** (index 0 - 7). Channel 0 is the primary channel; channels 1 - 7 are secondary channels used for specific groups or purposes.

## Channel Anatomy

Every channel has three defining properties:

- **Name** - a human-readable label used to match channels between nodes.
- **PSK (Pre-Shared Key)** - a pre-shared key that is 0 bytes (no encryption), 16 bytes (AES-128), or 32 bytes (AES-256), used to encrypt and decrypt messages on that channel.
- **Role** - one of `PRIMARY`, `SECONDARY`, or `DISABLED`.

## AES-CTR Encryption per Channel

Each channel is encrypted independently with AES-CTR using its PSK. The key length depends on the PSK: the default public channel uses the built-in single-byte default key and is effectively AES-128, while a channel configured with a generated 32-byte PSK uses AES-256. All nodes that possess the matching channel settings and PSK can decrypt traffic on that channel. Relay nodes forward ciphertext blindly - they do not need the PSK to relay packets, only the destination nodes need it to decrypt.

## The Default "LongFast" Public Channel

**LongFast** is the default modem preset. The default primary channel uses the well-known, publicly documented default key (`AQ==`, a single 0x01 byte) and an empty/default name - it is intentionally not secret. Any Meshtastic device running stock firmware with default settings can read messages on this channel. It exists as a shared public mesh for interoperability.

## Creating a Private Channel

To create a private channel, set a custom name and generate a random PSK. Only the PSK provides confidentiality - the channel name and its derived hash are effectively public, so the name does not protect your messages. This protection is also defeated if a gateway on the channel uplinks to MQTT without `mqtt.encryption_enabled` set true, which republishes the traffic in cleartext. Share access via QR code (see page 2).

## Channel Roles

- **PRIMARY** - the node broadcasts NodeInfo, position packets, and telemetry on this channel. There is exactly one primary channel per node (index 0).
- **SECONDARY** - carries only messages explicitly addressed to or sent on that channel. No automatic position or telemetry broadcasts.
- **DISABLED** - the channel slot is configured but inactive.

## Running Multiple Channels Simultaneously

A single node can participate in up to 8 channels at once. A node floods and relays packets it hears (subject to channel-hash matching and duplicate suppression) independent of whether it holds the PSK - being configured with a channel governs whether it can decrypt that traffic, not whether it relays it. This makes it possible to bridge a private club channel and the public mesh on the same hardware - the node relays both transparently.

## Channel Index 0 vs. Named Secondary Channels

Index 0 (the primary channel) carries the majority of mesh traffic: NodeInfo, position, telemetry, and general messages. Indices 1 - 7 carry traffic only for the specific groups or functions those channels are assigned to. Most community deployments use channel 0 for public connectivity and one or more secondary channels for group communications.

# Sharing Channels via QR Code

## How Channel Sharing Works

Meshtastic encodes channel configuration as a URL containing a Base64-encoded protobuf payload (a `ChannelSet`). This URL can be displayed as a QR code or shared as a plain link. At minimum the payload encodes the channel definition(s) — channel name and PSK. The shared LoRa config, which includes the **modem preset**, is only included when you enable the “Add to URL” / share-full-config option; with a plain channel share it is **not** carried. If you share only the channel (no LoRa config), recipients must be told the modem preset separately, or they will be on the right channel but unable to communicate.

## Generating a QR Code

1. Open the [Meshtastic app](https://wiki.meshamerica.com/books/hardware-guide/page/meshtastic-app) and navigate to **Channels**.
2. Select the channel you want to share.
3. Tap the **Share** (QR icon) button.
4. The app displays a QR code and a shareable URL. (Enable the option to include LoRa config if you also want to share the modem preset.)

## Importing a Channel

To import a channel on another device:

- Scan the QR code directly from the Meshtastic app's channel import screen, *or*
- Navigate to the channel URL on a device that has the Meshtastic app installed - the app intercepts the URL and offers to import the channel.

## URL Format

Channel URLs follow this structure:

```
https://meshtastic.org/e/#<Base64-encoded channel data>
```

The fragment (`#...`) portion is the Base64-encoded protobuf. (Legacy links used a `/c/` path without the `#` fragment; `/e/#` is the current form.) Because it is a URL fragment, it is not included in the HTTP request line sent to the server, which reduces incidental exposure during a direct request. **This is not a strong privacy guarantee, however**: link-preview bots, browser history and account sync, and messaging clients can still capture the full URL including the PSK. Treat the link as equivalent to the key regardless of how it is transported.

## Security: What Sharing a QR Means

Sharing a channel QR code shares the encryption key. Anyone who receives the QR or link can decode all past and future messages on that channel if they have access to the ciphertext. Key management rules:

- Only share with people you intend to give channel access.
- Once a PSK is shared there is no revocation - the only way to remove access is to generate a new PSK and redistribute it to all authorized nodes.
- Treat a shared channel QR like a password: do not post it publicly, and remember that pasting the link into a chat or preview service can leak the PSK.

## Admin Channel QR

An admin channel PSK grants remote configuration access to a node. Store any admin channel QR securely and share it only with authorized administrators. If you lose admin access to a remote, unattended node you may lose the ability to remotely reconfigure it - physical access becomes necessary. Note that modern firmware (2.5 and later) uses public-key (PKC) admin keys for remote administration rather than a shared admin-channel PSK; the shared-PSK admin channel is the older mechanism.

## Multi-Channel QR Codes

The Meshtastic app can generate a single QR code that encodes multiple channel definitions simultaneously. This makes onboarding new nodes to a full community channel set (e.g., public + club + EmComm) a single scan rather than importing each channel individually.

# 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.