NWI Mesh Net

LOCAL ENCRYPTED CHANNEL

Local Encrypted Channel (Private NWI Mesh)

A Local Encrypted Channel is used for private group communication within Meshtastic. Unlike the Primary Channel, traffic on a Local Encrypted Channel is not public and is only readable by devices that share the same channel name and encryption key.

This channel is intended for private messages, coordination traffic, and any communication that should not be visible to the public mesh or internet services.

How Local Encrypted Channels Work

Meshtastic supports multiple channels at the same time. Each channel has:

  • A channel name
  • An encryption key
  • Its own privacy and MQTT behavior

All devices must use the exact same channel name and key to communicate on that channel.

The Primary Channel remains active for mesh coordination. Local Encrypted Channels operate alongside it and rely on the Primary Channel for routing.

What a Local Encrypted Channel Is Used For

Common use cases include:

  • Group coordination
  • Emergency response teams
  • Events or field operations
  • Club or family communication
  • Sensitive or private conversations

Messages sent on a Local Encrypted Channel are encrypted end to end and are not readable by nodes that do not have the correct key.

NWI Encrypted Channel Configuration

This is the official private encrypted channel for NWI Mesh members. Add this channel to communicate securely within the NWI inner circle.

Add this as Channel Slot 2.

  • Channel Role
    • Secondary
  • Channel Name
    • NWI
  • Pre Shared 256 bit Key
    • H1HDyEqg5W9XFilicVTIaoWYrs8URmWGo5fAYfbxQgo=
  • MQTT Uplink and Downlink
    • Disabled. Keep this channel radio only.

MQTT and Encrypted Channels

Encrypted channels should not be bridged to MQTT.

Recommended settings for Local Encrypted Channels:

  • Uplink Enabled: Off
  • Downlink Enabled: Off

This ensures private traffic stays on the local radio mesh and is not published to internet services.

Location Sharing on Encrypted Channels

Location sharing is usually not required on Local Encrypted Channels.

Best practice:

  • Enable location sharing on the Primary Channel only
  • Disable location sharing on encrypted channels

This reduces unnecessary traffic and limits location exposure.

Key Management and Security

Channel keys should be treated like passwords.

  • Do not post keys publicly
  • Change the key if it is accidentally shared
  • Update all participating nodes if the key changes
  • Remove access for lost or compromised devices

Nodes without the correct key will still receive encrypted packets but will not be able to decrypt or display them.

Creating Your Own Encrypted Channel

You can create your own Local Encrypted Channel for a club, group, or special purpose network.

This is useful for organizations, event teams, or any group that wants private communication without sharing traffic on the public mesh.

To create your own encrypted channel:

  • Open the Meshtastic app
  • Go to Settings
  • Select Channels
  • Add a new channel
  • Choose a unique channel name
  • Enable encryption
  • Generate or enter a pre shared key
  • Save and send the configuration

All participating devices must use the exact same channel name and key.

How Encrypted Traffic Is Forwarded

Encrypted channel traffic is still routed through the mesh even when intermediate nodes do not have the channel configured.

Important behavior to understand:

  • Routers and repeaters forward encrypted packets without decrypting them
  • Nodes do not need the channel key to retransmit traffic
  • Only devices with the correct key can read the messages

This means your encrypted channel will propagate across the mesh infrastructure, but message contents remain private.

Client nodes usually do not rebroadcast traffic unless explicitly configured, so mesh reach depends on router and repeater placement.

Best Practices for Custom Encrypted Channels

  • Use encrypted channels only when privacy is required
  • Do not enable MQTT unless you control the broker
  • Keep the number of encrypted channels reasonable
  • Distribute keys securely and intentionally
  • Do not assume encrypted channels reduce radio traffic

Common Mistakes to Avoid

  • Using the Primary Channel for private conversations
  • Enabling MQTT on encrypted channels
  • Assuming encrypted channels replace the Primary Channel
  • Forgetting to update all nodes after a key change

Summary

  • Encrypted channels are for private group communication
  • The Primary Channel is still required for routing
  • MQTT should remain disabled
  • Location sharing is usually unnecessary
  • Keys must be protected and managed carefully