Growing Your Network How to recruit hosts, run community events, document your network, and manage growth at scale. Running Mesh Events and Demonstrations The fastest way to grow a mesh community is to let people experience the network firsthand. Events and demonstrations convert curious bystanders into active participants in a way that no amount of documentation can match. The Mesh Meetup Format A mesh meetup requires no special venue and minimal equipment. The basic format: Gather 5 - 10 people at a park or open community space. Each participant brings or borrows a Meshtastic node. Power them on, watch the mesh form in real time. Run through the basics: send a message, observe who receives it, check the map to see each other's positions, walk to the edge of the park to test range. The goal is not to teach technical details - it's to create a "this actually works" moment that participants will describe to others. Keep it relaxed. Keep it short. Follow up with a Discord or group message so attendees can stay connected. Integration with Existing Events You do not need to organize a standalone event to demonstrate the mesh. Bring it to events that already draw the right audience: Ham radio field days - A natural fit. Many operators have never seen Meshtastic; a working demonstration at a field day generates more interest per hour than almost any other venue. CERT and ARES exercises - Emergency preparedness audiences respond strongly to a practical off-grid messaging tool. You do not need a full exercise; a side-table demo during setup or break time is enough. Maker faires - Technically curious attendees who enjoy seeing novel hardware in action. Outdoor clubs (hiking, camping) - Groups that go into areas with no cell coverage are immediately motivated by a reliable off-grid communication option. Bring 3 - 5 pre-configured nodes. Let people pick them up and try them. The hands-on experience is the entire pitch. EmComm Exercise Integration One of the highest-value moves for community credibility is proposing a mesh communications component to your county's next emergency management tabletop exercise or ARES drill. Contact your county emergency manager or ARES/RACES leadership and offer to run a Meshtastic messaging segment. Demonstrating value in a formal exercise context creates buy-in from officials who influence future infrastructure decisions. An emergency manager who has seen the mesh work in a controlled setting is far more likely to support permanent installations on municipal buildings. Demo Kit Maintain a dedicated loaner kit for events: 3 - 5 nodes, all pre-configured with your local channel settings Charged batteries or power banks for each node A one-page quick-start card: how to turn it on, how to send a message, what the map view shows A way to track who has each device (a simple sign-out sheet is enough) Get the kit back at the end of every event. Pre-configured nodes that leave your possession and are never returned are nodes that may end up causing interference or confusion on the network later. Online Presence A simple online presence makes it dramatically easier for newcomers to find your local mesh community, learn the channel settings, and get involved: Discord server - Many cities have active Meshtastic Discord channels. Search before creating a new one. If one exists, become active there; if not, a new server is easy to set up. Simple website - Even a single static page with your channel name, modem preset, and a contact link is sufficient. New participants should be able to find this without joining a private group first. The channel PSK should not be published publicly if channel security matters to your group. Share it via QR code to verified participants. Measuring Success Track concrete, observable metrics rather than relying on impressions: Node count on meshmap.net - Check month over month. A growing trend is the clearest indicator that the community is healthy. Active repeater count - Nodes that are consistently online over multiple weeks, not just at events. Set written goals - "10 active nodes in the metro area by year end, 3 hilltop repeaters." Goals create shared direction and make progress visible. Celebrate milestones publicly in your Discord or website. Recognition keeps volunteers engaged. Network Documentation Standards A community mesh network that isn't documented is one resignation or one hardware failure away from being unrecoverable. Documentation is not overhead - it's the infrastructure that makes the physical infrastructure maintainable. What to Document For every permanent repeater, record: Location - Address or GPS coordinates, plus a plain-language description (e.g., "roof of First Baptist Church, southwest corner") Hardware - Device model, enclosure type, antenna type and gain Firmware version - Current version and date of last update Channel configuration - Channel name, modem preset, and whether a custom PSK is in use (do not record the PSK in shared documentation) Power system - Solar + battery, wall power, PoE. Battery capacity if applicable. Maintainer contact - Name and contact method for the person responsible for this node Beyond individual nodes, document: Network topology - Which repeaters link to which under typical conditions. A simple diagram is worth pages of prose. Channel settings - The canonical record of your community's channel name and modem preset. This is what you share with newcomers. Coverage map - Based on tested range, not theoretical propagation. Mark areas where coverage has been verified by walking tests or field days. Using the Library Mesh America Library provides a repeater reference template. Fill one out for every permanent node in your network. Keeping this information in a shared wiki rather than a single operator's notes means the network survives personnel changes. Update the library entry whenever hardware changes, firmware is updated, or maintainer contact information changes. Stale documentation is worse than no documentation because it misleads the next person who needs to act on it. Repeater Naming Conventions Choose a consistent naming scheme before you deploy your first permanent repeater. Changing it later is painful - nodes appear on maps and in message logs, and inconsistency creates confusion. Common options: Location-based : MeshAmerica-WestHills-1 - Human-readable, easy to orient on a map Callsign-based : KD9XYZ-SiteA - Ties the node to a licensed operator, useful for EmComm accountability Sequential : PDX-Repeater-01 - Simple, scales cleanly Pick one scheme and document it. New nodes added by new community members should follow the same convention. Channel Documentation Publish your channel name and modem preset publicly - on your Discord, website, or wiki. New participants need this information to join the network. Do not publish the PSK publicly if your community uses a private channel for security. Share the PSK via QR code to verified participants only. The QR code contains the full channel configuration and is the standard mechanism for onboarding new nodes. Firmware Version Tracking Maintain a log of when each node was last updated. Meshtastic firmware is actively developed; nodes running outdated versions may miss bug fixes, compatibility improvements, or security patches. Schedule a quarterly firmware review: check each node's current version, identify which nodes need updates, and coordinate with site maintainers to get access for updates. A node that hasn't been updated in over a year should be treated as a maintenance priority. Incident Log When a node goes offline - whether due to weather, power failure, hardware failure, or vandalism - document: What happened When it was detected What was done to restore service What (if anything) changed to prevent recurrence This institutional knowledge prevents repeat failures. The second time a solar controller fails in a cold snap, the person responding should be able to find a record of what worked last time. Succession Planning Community networks outlast individual operators. Plan for turnover: Ensure at least two people have physical and administrative access to every critical node. Document access procedures (who has the key to the rooftop, who has the admin channel QR code). Store admin channel QR codes securely, with a trusted backup outside your own household. A fireproof envelope with a co-maintainer is a reasonable standard. Review the succession plan annually. People move, change jobs, and lose interest. The plan is only useful if it's current. Handling Network Growth and Congestion A Meshtastic network that works well with five nodes may behave poorly at fifty. Managing growth proactively - rather than reacting after congestion degrades performance - is what separates a durable community network from one that works great until it doesn't. Early Stage: 1 - 10 Nodes At this scale, almost any configuration works. Long Fast is a reasonable default - it has good range and is the most common preset, making it easy for newcomers to join. Focus at this stage belongs on placement, not optimization. A single well-placed repeater on a hilltop or water tower does more for network coverage than ten ground-level nodes. Get repeaters in good locations first. Growth Stage: 10 - 50 Nodes As the network grows, start monitoring channel utilization . The Meshtastic app displays this metric; check it periodically. Utilization consistently above 15% is a warning sign. Actions at this stage: Audit hop limits. High hop limits cause individual messages to generate multiple retransmissions across many nodes. A hop limit of 3 is appropriate for most community networks; higher values compound congestion. Review node density. Clusters of nodes in the same small area all hear and retransmit each other's traffic. Nodes that add density without extending coverage add congestion without benefit. Begin discussing a potential preset migration with the community before it becomes urgent. Scaling Stage: 50+ Nodes At this scale, Long Fast will likely show sustained high utilization. Seriously consider migrating to Medium Slow or Medium Fast, which use lower data rates (thus more airtime per message) in exchange for significantly better receiver sensitivity and range - the tradeoff that matters when node count is high and coverage gaps are the remaining problem. This migration must be coordinated as a community. All nodes must change simultaneously, or you split the network - nodes on different presets cannot communicate. Preset Migration Process Pick a date and time for the migration window. Announce in all community channels at least two weeks in advance. Post in Discord, on the website, and in any mailing lists. Include the specific preset being adopted. Document the change procedure - a step-by-step guide for changing the preset in the Meshtastic app, for both Android/iOS and the web client. Change infrastructure repeaters first. These are the reference points that participants will see when they join on the new preset. Ask all participants to update within the migration window. A specific two-hour window on a weekend afternoon works better than "sometime this week." Run a compatibility bridge temporarily. Leave one repeater on the old preset for 1 - 2 weeks after migration. This gives stragglers a way to see a message like "Network has migrated to Medium Slow - update your preset to rejoin" and self-serve the fix. Managing the Public Channel You cannot control what strangers do on the public channel. Trolling, spam messages, and misconfigured nodes that flood the network with repeated traffic are occasional realities on any open mesh. Mitigation strategies: Maintain a secondary private channel for your community's operational use, regardless of network size. The public channel is for newcomers and casual use; the private channel is for your community's serious coordination. Document and enforce a community hop limit recommendation . Infrastructure nodes can be configured to refuse to relay messages above a certain hop count, which limits cascading retransmissions. Treat persistent disruptive nodes as a maintenance issue, not a personal conflict. Document the node ID and behavior, and discuss with your community whether any technical mitigations are warranted. Tracking Growth Health Watch these indicators month over month: Node count visible on meshmap.net (total and always-online) Channel utilization during peak hours Ratio of infrastructure repeaters to client nodes (more repeaters relative to total nodes = better network health) Growth that outruns infrastructure is the most common failure mode for community meshes. Adding repeaters ahead of demand keeps the network healthy through growth phases.