Public Meshtastic Network Etiquette

Practical social and technical behavior that keeps a shared mesh useful.

A public Meshtastic network is a shared radio system, not an unlimited chat server. Every transmitted packet uses common spectrum and may cause several other devices to transmit. Good etiquette is therefore partly social and partly engineering: identify yourself sensibly, avoid unnecessary traffic, protect other people’s privacy and coordinate infrastructure changes.

Public does not mean unowned. Nodes have hosts, power systems, maintenance costs and legal responsibilities. A community mesh works when users treat those contributions as shared infrastructure rather than anonymous free capacity.

Join before changing

Use the regional profile, LONG_FAST and the community’s coordinated frequency slot unless the network explicitly publishes another standard. Keep maximum hops at 3 and the CLIENT role on ordinary devices. Do not label a device ROUTER because it is stationary or because the name sounds important.

Observe the local mesh and read community documentation before proposing changes. A configuration that worked in an isolated test may be harmful in a populated region.

Use concise, relevant traffic

Avoid repetitive test messages, automated greetings, bots and high-frequency location updates on the public channel. Coordinate range tests, label them and turn the module off afterward. Do not use MQTT to inject a distant internet population into local RF without agreement.

Short operational messages are a better fit than large conversations. Move prolonged or high-volume discussion to an internet service when it is available.

Names and identity

Choose a stable long name and a useful four-character short name. Infrastructure names should indicate an area or function without revealing a private host’s exact address. Avoid impersonating emergency services, authorities or another operator.

A public node listing should have a maintainer contact or community route for reports, even if personal details are kept private.

Privacy and consent

Do not republish another person’s precise location, messages or node history without permission. A technically receivable packet is not automatically ethical to archive and profile. Use approximate public locations for sensitive fixed sites.

Private-channel users still consume shared radio airtime. Encryption protects content from casual reading but does not exempt a group from capacity etiquette.

Infrastructure changes

Announce planned preset, frequency-slot, hop-limit, MQTT or privileged-role changes. Test them in a defined window and retain a rollback path. One central router misconfiguration can affect a region.

If another node appears misconfigured, contact its maintainer respectfully with observations: timestamps, packet types, intervals and effects. Avoid public accusation based only on a busy node list.

Legal and safety behavior

Use the correct regional profile, legal effective radiated power and permitted antenna system. Do not override duty-cycle controls to improve convenience. Get permission for roofs, towers and power connections, and follow electrical and lightning-safety requirements.

Meshtastic is not a guaranteed emergency service. Do not create expectations of monitored distress response unless a qualified organization has explicitly established and staffed such a procedure.

Handling experiments responsibly

Experiments are part of community radio, but announce their duration and scope. Use a separate preset or slot when the test would generate sustained traffic, and return equipment to the published baseline afterward. Keep a local log so unusual packets can be explained rather than mistaken for network failure.

When demonstrating Meshtastic to newcomers, avoid asking everyone to enable maximum hops, routers or minute-level telemetry. Teach the shared-airtime model from the start.

Resolving disagreements

Communities should decide who can recommend standards without claiming ownership of unlicensed spectrum. Publish evidence, invite testing and distinguish a voluntary interoperability profile from law. A host always retains control of their equipment, while other operators remain free not to relay incompatible or harmful traffic.

Use specific, reversible proposals: reduce one interval for a week, remove one redundant router or restrict one MQTT downlink. Measured trials are more productive than arguments about whose node is strongest.

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.