When someone shares a Meshtastic channel, they send you a link like https://meshtastic.org/e/#<data> — or the QR code that encodes the same thing. That link looks opaque, but it isn’t encrypted: everything after the # is a base64 (URL-safe) blob that anyone can decode. This reference explains exactly what is inside that blob, field by field, and — most importantly — what you reveal when you share a channel URL. Every structural detail here is drawn from the canonical Meshtastic Protobuf definitions (apponly.proto, channel.proto, config.proto).
The one-sentence version, if you read nothing else: a channel URL carries the channel’s pre-shared key in plaintext. Whoever holds the URL can decrypt that channel. Treat a channel link with the same care as the key it contains.
Try it: paste any channel link into our Meshtastic channel URL decoder to see its channels, key strength and MQTT flags — it runs entirely in your browser, so the key never leaves your device.
What the URL actually encodes: a ChannelSet
The fragment after # is a base64url-encoded ChannelSet message — Meshtastic’s compact representation of one primary channel plus any secondary channels. Its structure is small:
| Field # | Name | Type | Meaning |
|---|---|---|---|
| 1 | settings |
repeated ChannelSettings | One entry per channel being shared |
| 2 | lora_config |
Config.LoRaConfig | The radio settings (modem preset, region) |
So a shared URL is not just “a channel” — it can carry your whole channel set and your radio configuration.
Inside each channel: ChannelSettings
Each entry in settings is a ChannelSettings message. These are the fields that define a channel:
| Field # | Name | Type | What it holds |
|---|---|---|---|
| 1 | channel_num |
uint32 | Deprecated — legacy channel number. |
| 2 | psk |
bytes | The pre-shared key. 0, 16, or 32 bytes (see the key-strength table below). |
| 3 | name |
string | Short channel name, under 12 bytes (e.g. an empty name displays as the default “LongFast”). |
| 4 | id |
fixed32 | A globally unique channel identifier. |
| 5 | uplink_enabled |
bool | Forward this channel’s messages to the public internet (MQTT). |
| 6 | downlink_enabled |
bool | Forward messages from the internet back onto the mesh. |
| 7 | module_settings |
ModuleSettings | Per-channel module configuration. |
The uplink_enabled / downlink_enabled pair matters for privacy: a channel with uplink enabled is being bridged to an internet MQTT server, so its traffic leaves the local RF mesh entirely. If a shared URL has these set, you’re joining a channel that talks to the internet.
The PSK field: what “encrypted” really means here
The security of a channel lives entirely in that psk field, and its length tells you the key strength:
| PSK length | Meaning |
|---|---|
| 0 bytes (empty) | No channel-specific key set. |
| 16 bytes | AES-128 key. |
| 32 bytes | AES-256 key. |
There is also a widely-used single-byte shorthand the apps use to reference the well-known default key (the key behind the public “LongFast” channel), rather than embedding a full random key. That default-key convention — and why a channel using it is effectively public despite showing a lock icon — is the single biggest Meshtastic misconception, and we cover it in depth in our Meshtastic encryption guide. The structural point for this reference: because the PSK travels inside the URL, sharing the link shares the key. There is no separate “key exchange” — the URL is the key exchange.
Channel roles: PRIMARY vs SECONDARY
When channels are represented in the fuller Channel message (as opposed to the compact URL set), each carries a role:
| Role | Value | Behavior |
|---|---|---|
DISABLED |
0 | Channel not in use. |
PRIMARY |
1 | Sets the radio frequency slot — only one primary is allowed per device. |
SECONDARY |
2 | Used for encryption/decryption only; its radio settings are ignored (it rides on the primary’s frequency). |
This is why you can have several channels active at once: one PRIMARY defines the frequency the radio actually uses, and SECONDARY channels are just additional encryption contexts layered on top.
The radio settings: LoRaConfig
The lora_config half of a ChannelSet carries the radio parameters. Two fields matter most for interoperability — if two nodes don’t match on these, they won’t hear each other:
modem_preset(field 2) — the speed/range trade-off. The presets, by enum value, are:LONG_FAST(0, the default),LONG_SLOW(1),VERY_LONG_SLOW(2),MEDIUM_SLOW(3),MEDIUM_FAST(4),SHORT_SLOW(5),SHORT_FAST(6),LONG_MODERATE(7),SHORT_TURBO(8),LONG_TURBO(9), and further compact/narrow presets in later firmware. For what each preset means in practice, see our modem presets reference.region(field 7) — selects the regional frequency plan the device operates under. (A node must be set to a legal region for where it is; the region governs which frequencies and duty limits apply.)use_preset(field 1) — whether the device uses a named preset (true) or fully manual bandwidth/spread-factor/coding-rate values.
What sharing a channel URL exposes — the checklist
Put together, here is what a person receives when you hand them a channel link:
- The encryption key for every channel in the set — they can now read and send on those channels.
- The channel names and their unique IDs.
- Whether the channels bridge to the internet (uplink/downlink).
- Your radio configuration — modem preset and region.
The practical guidance: for anything private, generate a full 32-byte (AES-256) key rather than relying on the default, share the URL over a channel you already trust, and remember that revoking access means rotating the key and re-sharing a new URL — there is no per-member revocation. For the deeper cryptographic model, spoofing caveats, and the metadata that still leaks even on an encrypted channel, read the Meshtastic encryption guide. For the packet layer these channels ride on, see the packet structure reference, and for the wider vertical, the sovereign mesh hub.
Sources: Meshtastic Protobuf definitions — apponly.proto (ChannelSet), channel.proto (ChannelSettings, Channel, Role), and config.proto (LoRaConfig, ModemPreset). Field numbers and enum values reflect the current protobuf schema; confirm against your firmware version for edge cases.
