Meshtastic Channels, Encryption and Private Groups

The difference between LoRa radio settings and messaging channels, plus practical security and privacy guidance.

Meshtastic uses the word channel for a logical messaging group, while the radio also uses a frequency slot. These are not the same thing. A messaging channel has a name, role and pre-shared key. The modem preset and frequency slot define where and how the LoRa radio transmits. Confusing the two is a common reason otherwise healthy nodes cannot communicate.

A device can have one primary messaging channel and up to seven secondary channels. All of them share the same LoRa modem configuration and the same physical airtime. Adding a private group does not create more radio capacity; it only changes which nodes can decrypt and display particular payloads.

Primary and secondary channels

Channel index 0 is PRIMARY and cannot be disabled. Indices 1 through 7 can be SECONDARY or disabled, and active channels must be consecutive. Periodic traffic such as position and telemetry normally uses the primary channel, which makes primary-channel design important for privacy and network behavior.

Secondary channels are appropriate for a maintenance team, event group or local organization that needs private messages while keeping the radio interoperable with the public mesh.

Encryption and what it protects

A channel pre-shared key encrypts the application payload for members who possess the same key. It does not hide the existence, timing or approximate radio origin of transmissions from a capable observer. Node numbers and some protocol behavior can still support traffic analysis. Meshtastic should not be described as anonymous or as protection against a determined radio adversary.

The default public channel key is publicly known by design. It prevents accidental plain-text decoding by unrelated software, not access by the public. Treat messages on that channel as public.

Private groups on a public mesh

Nodes can retain LONG_FAST and the coordinated frequency slot while using a private secondary channel. Other compatible nodes may rebroadcast encrypted packets without reading them, depending on rebroadcast mode. This allows a private message group to benefit from shared radio infrastructure, but its traffic still consumes the public airtime budget.

Use a randomly generated key for genuinely private groups, share it through a trusted path and remove access when devices are lost or members leave. A channel QR code or URL contains configuration secrets; do not publish it casually.

The primary-channel frequency-slot trap

Meshtastic can derive the LoRa frequency slot from a hash of the primary channel name. Two devices with different primary names may therefore transmit on different frequencies even if their presets match. Communities that customize the primary name should explicitly coordinate the frequency slot.

For participation in the default public mesh, keeping the default primary channel and LONG_FAST is the least surprising choice. If a community needs a branded discussion group, a secondary channel avoids fragmenting the radio layer.

Administration is different from conversation

Administrative access deserves a separate, strong key and a limited operator list. Never reuse a public or broadly shared chat key for remote administration. Keep recovery procedures and local access for infrastructure in case a remote configuration change breaks connectivity.

When equipment changes ownership, rotate administrative credentials and review every stored channel. A factory reset before reassignment is safer than assuming an old key was removed.

A practical public-network pattern

Use the default public primary channel for discovery and ordinary community traffic. Add one or more private secondary channels only for groups that need them. Coordinate a single modem preset and frequency slot. Reduce position precision for public fixed nodes when exact coordinates would reveal a private rooftop or restricted site.

Document names and purposes without publishing keys: for example, Public Primary, Operations Secondary and Admin. This lets operators understand traffic policy while preserving secrets.

Threat model and key hygiene

Ask what the group is protecting. A family group may mainly want to prevent casual reading; an infrastructure team must also protect administrative authority if a handset is lost. No shared pre-shared key gives individual accountability: every holder can read the channel, and removing one member normally requires distributing a new key to everyone else.

Store an offline record of which devices and people received sensitive keys. Use distinct keys for chat, operations and administration. Rotation is disruptive, but that is preferable to leaving a known-compromised administration channel active.

Designing channel policy

A community can publish channel purposes without publishing secrets. Define what belongs on the default public channel, which team owns an operations channel, how keys are requested and what happens when a device is lost. Discourage many overlapping private channels on infrastructure nodes because configuration complexity becomes a maintenance risk.

When testing channel changes, confirm both readable messages and the physical frequency slot. Seeing node advertisements is not proof that two users share the intended encrypted group.

How these settings work together

No setting should be evaluated in isolation. A slower preset increases packet airtime; a larger hop limit multiplies that airtime across more relays; frequent position and telemetry packets create a permanent load; and privileged repeaters can produce additional copies. Conversely, a well-sited node using ordinary CLIENT behavior may extend the mesh effectively without special privileges.

For a public deployment, document the complete profile and the reason for every exception. Test delivery in both directions, during quiet and busy periods, and retain a way to reverse remote changes. Revisit the profile as the network grows.

Related configuration guides

Official sources

Meshtastic firmware and documentation change over time. Confirm setting names, defaults and regional requirements in the current official documentation before changing live infrastructure.