Throughout this book, we have built networks from the ground up. We have strung antennas between rooftops, configured mesh protocols on routers running open firmware, deployed LoRa radios across valleys, and set up decentralized applications that function without a single corporate server. Every chapter has dealt with technology that exists today — hardware you can buy, software you can install, protocols you can deploy this weekend.
This final chapter is different. Here, we look forward. Not into science fiction — there will be no speculation about quantum mesh networks or brain-computer internet interfaces — but into the near future: the technologies, protocols, hardware, and policy shifts that are either just emerging or on the cusp of mainstream availability, and that will fundamentally reshape what alternative networks can do in the next three to ten years.
Some of what follows is already here in early form. Reticulum is running on hobbyist networks right now. Wi-Fi 7 routers are on store shelves. RISC-V chips are shipping in production hardware. Other developments — widespread dynamic spectrum access, AI-driven mesh routing, self-sovereign identity as a default — are further out, but their trajectories are clear and their implications for alternative networks are profound.
What makes this moment particularly exciting is the convergence. For decades, alternative networking was a niche pursuit: ham radio operators, cypherpunks, a handful of community network activists, and academics publishing papers that nobody in industry read. The technologies were either too expensive, too complex, or too limited for anyone but dedicated enthusiasts. That has changed — rapidly and dramatically. The hardware is cheap. The software is maturing. The protocols are hardening. And, perhaps most importantly, the motivation has gone mainstream. After years of ISP monopoly abuses, social media platform collapses, government internet shutdowns, and pandemic-era infrastructure failures, millions of people who never thought about network architecture are now asking: “Is there another way?”
There is. And it is getting better every year. Let us see where it is going.
Wi-Fi 7, formally known as IEEE 802.11be, is not merely an incremental improvement over Wi-Fi 6 — it represents a fundamental rethinking of how wireless local area networks operate, and its implications for mesh networking are substantial.
The headline numbers are impressive but largely irrelevant for alternative networks: peak theoretical throughput of 46 Gbps, 320 MHz channel widths, 4096-QAM modulation. You will never see those numbers in a real-world mesh deployment, and frankly you do not need to. What matters for alternative networks are three specific features:
Multi-Link Operation (MLO) is the game-changer. Previous Wi-Fi generations forced a device to associate with an access point on a single band — you were connected on either 2.4 GHz, 5 GHz, or 6 GHz, and switching between them was a disruptive process involving deauthentication and reassociation. MLO allows a single logical connection to span multiple bands simultaneously. For mesh networks, this means a node can use 5 GHz for backhaul while simultaneously serving clients on 2.4 GHz, without the clunky band-steering hacks that current tri-band mesh systems rely on. A mesh node can even aggregate traffic across bands for a single client, dramatically improving throughput and reducing latency on congested networks.
Multi-Resource Unit (MRU) puncturing allows Wi-Fi 7 to use wide channels (160 or 320 MHz) while punching out sub-channels that are occupied by other users or radar. In previous generations, if any part of a wide channel was occupied, the entire channel was unusable. With puncturing, a Wi-Fi 7 radio can use a 320 MHz channel but skip the 20 MHz sub-channel where your neighbor’s legacy router is operating. For mesh networks in dense urban environments — exactly where community mesh networks like NYC Mesh and Freifunk operate — this dramatically increases the usable spectrum.
Deterministic latency through Restricted Target Wake Time (R-TWT) allows Wi-Fi 7 networks to guarantee bounded latency for specific traffic flows. This is designed for industrial IoT and time-sensitive networking, but it has direct relevance for mesh networks carrying real-time voice or video traffic. If your community mesh is carrying VoIP calls between neighbors, R-TWT can ensure those packets get consistent, low-latency treatment even on a congested mesh.
The practical impact for alternative mesh builders is this: as Wi-Fi 7 routers become the default consumer hardware (which they will by 2027–2028), the devices available for mesh building will be dramatically more capable. Mesh networks that currently struggle with the “three-hop problem” — where throughput degrades catastrophically beyond three wireless hops because each hop shares the same radio — will benefit enormously from MLO’s ability to use separate bands for separate links.
# Estimating effective throughput in a multi-hop Wi-Fi 7 mesh with MLO
# Each hop can use a dedicated band, avoiding the shared-medium penalty
def estimate_mlo_mesh_throughput(
single_link_mbps: float,
num_hops: int,
mlo_bands: int = 3 # 2.4, 5, 6 GHz
) -> dict:
"""Compare traditional single-band vs MLO mesh throughput."""
# Traditional: throughput halves with each hop (shared medium)
traditional = single_link_mbps / (num_hops + 1)
# MLO: each hop uses a separate band (up to mlo_bands)
if num_hops <= mlo_bands:
mlo = single_link_mbps # No contention
else:
mlo = single_link_mbps * mlo_bands / (num_hops + 1)
return {
"hops": num_hops,
"traditional_mbps": round(traditional, 1),
"mlo_mbps": round(mlo, 1),
"improvement_factor": round(mlo / traditional, 1),
}
for hops in range(1, 7):
result = estimate_mlo_mesh_throughput(600, hops)
print(f"{result['hops']} hops: traditional={result['traditional_mbps']} Mbps, "
f"MLO={result['mlo_mbps']} Mbps ({result['improvement_factor']}x)")
The opening of the 6 GHz band (5.925–7.125 GHz) to unlicensed use is the single largest spectrum allocation for Wi-Fi since the technology was invented. In the United States, the FCC made 1,200 MHz of spectrum available — more than doubling the total unlicensed spectrum accessible to Wi-Fi. Europe has allocated a more conservative 500 MHz, and other regions are still deciding, but the direction is clear: 6 GHz is becoming Wi-Fi territory worldwide.
For alternative networks, this matters for three reasons:
Clean spectrum. As of early 2026, the 6 GHz band is still relatively uncrowded. The 2.4 GHz band is a war zone — Bluetooth, Zigbee, baby monitors, microwave ovens, and decades’ worth of legacy Wi-Fi devices are all fighting for 80 MHz of usable spectrum. The 5 GHz band is better but increasingly congested in urban areas and complicated by DFS (Dynamic Frequency Selection) requirements to avoid radar. The 6 GHz band is a green field, and mesh networks that deploy there now will enjoy interference-free operation for years before the band fills up.
Wide channels without compromise. The 6 GHz band can support seven non-overlapping 160 MHz channels, or three 320 MHz channels. Compare this to the 5 GHz band, where you can fit at most two non-overlapping 160 MHz channels (and only if you are lucky with DFS). Wide channels mean higher throughput per hop, which directly translates to better mesh performance.
Shorter range is actually an advantage for dense mesh. Higher frequencies mean shorter range, which sounds like a disadvantage. But for urban mesh networks — where nodes are typically 50–200 meters apart — shorter range means less interference between nodes that are not direct neighbors. Each node’s transmissions are heard by fewer other nodes, which reduces contention and improves spatial reuse. In mesh networking terms, shorter range makes the network more efficient, not less, as long as node density is sufficient.
The caveat is that 6 GHz propagation through walls and vegetation is significantly worse than 5 GHz, which is in turn worse than 2.4 GHz. For outdoor mesh networks with clear line of sight, 6 GHz is excellent. For indoor coverage through multiple walls, you will still need 2.4 or 5 GHz. This is where MLO in Wi-Fi 7 comes in — use 6 GHz for high-speed backhaul between rooftop nodes and 2.4 GHz for penetrating walls to serve indoor clients.
Citizens Broadband Radio Service (CBRS) operates in the 3.5 GHz band (3550–3700 MHz) in the United States, and it represents a genuinely new model for spectrum management — one that is neither the traditional licensed model (where a carrier pays billions for exclusive access) nor the unlicensed model (where anyone can transmit and interference is a free-for-all).
CBRS uses a three-tier sharing framework:
A Spectrum Access System (SAS) — a cloud-based database — coordinates all of this in real time, telling each radio what frequencies it can use in its current location at the current time.
For community and alternative networks, CBRS GAA is extraordinary. You get access to mobile-quality spectrum — 3.5 GHz propagates much farther than Wi-Fi frequencies and penetrates buildings reasonably well — without purchasing a license. CBRS-capable radios from manufacturers like BaiCells, CableFree, and Tarana are available for a few hundred dollars, and they can deliver tens of megabits per second over distances of several kilometers. Community wireless ISPs like the ones described in Chapter 6 are already using CBRS GAA to provide last-mile connectivity in areas where traditional ISPs refuse to build.
The CBRS model is being watched closely internationally. If it succeeds — and early results are very promising — we will likely see similar shared-spectrum frameworks adopted in other bands and other countries, opening vast swaths of usable spectrum to community and alternative network operators.
TV White Spaces are the unused portions of the UHF television spectrum (typically 470–698 MHz), and they have properties that make them almost ideal for rural alternative networks. At these frequencies, radio signals travel long distances (10–20 km is routine) and penetrate vegetation and buildings far better than any Wi-Fi band. A single TVWS base station on a modest tower can cover an area that would require dozens of Wi-Fi access points.
TVWS devices use a geolocation database to determine which TV channels are unused in their area and dynamically select frequencies to avoid interfering with television broadcasts. This is essentially the same concept as CBRS’s SAS, but applied to the TV band.
Microsoft’s Airband Initiative has deployed TVWS networks in rural areas across multiple countries, demonstrating that the technology works for real-world last-mile connectivity. Projects in Kenya, Tanzania, and rural Virginia have provided internet access to communities that had no previous broadband option.
For alternative network builders, TVWS is particularly interesting for rural community networks. The range and penetration characteristics mean that a small number of nodes can cover a large geographic area — exactly the scenario where Wi-Fi mesh networks struggle because nodes are too far apart. The challenge is that TVWS hardware remains more expensive and less widely available than Wi-Fi equipment, but prices are dropping as the ecosystem matures.
LoRa has been the dominant sub-GHz technology in the alternative networking world, and deservedly so — its range, power efficiency, and community ecosystem (especially Meshtastic) are unmatched. But several other sub-GHz protocols are emerging that may complement or challenge LoRa’s position:
Amazon Sidewalk is a neighborhood-scale mesh network built into millions of Amazon Echo and Ring devices. It uses a combination of 900 MHz (LoRa-like) and Bluetooth LE to create a low-bandwidth mesh that extends the range of IoT devices. Sidewalk is proprietary and Amazon-controlled, which makes it antithetical to the philosophy of this book — but its widespread deployment means that the concept of neighborhood mesh is being validated at enormous scale. The lesson for alternative network builders is not to use Sidewalk, but to recognize that the hardware and protocols for neighborhood-scale sub-GHz mesh are becoming commodity items.
Wi-SUN (Wireless Smart Utility Network) is an open standard designed for utility-scale IoT mesh networks — smart meters, street lights, and infrastructure monitoring. It operates in sub-GHz bands, supports meshes of thousands of nodes, and has been deployed by major utilities worldwide. Wi-SUN’s relevance for alternative networks is that its hardware is becoming increasingly available, and its mesh stack is well-proven at scales that LoRa mesh networks have not yet demonstrated.
DECT-2020 NR is the newest entrant. It is a 5G-adjacent standard designed for private wireless networks and IoT, operating in the 1.9 GHz DECT band (which is unlicensed in most countries). It offers significantly higher data rates than LoRa (up to several megabits per second) while maintaining good range and low power consumption. DECT-2020 NR supports mesh topologies natively and includes modern security features. Nordic Semiconductor’s nRF9161 chip supports DECT-2020 NR, and early development boards are available. This technology is worth watching closely — it could fill the gap between LoRa (very long range, very low bandwidth) and Wi-Fi (high bandwidth, short range).
If there is one technology in this chapter that you should pay attention to above all others, it is Reticulum. Developed primarily by Mark Qvist (who also created the RNode hardware platform), Reticulum is a networking stack designed from the ground up for the exact scenarios this book is about: encrypted, self-configuring, multi-hop networking across any physical transport — LoRa, packet radio, serial links, Wi-Fi, Ethernet, the internet, or any combination thereof.
Reticulum is not a replacement for IP. It is a parallel network layer that does not depend on IP, DNS, or any centralized infrastructure. Every destination on a Reticulum network is identified by a cryptographic public key. There are no addresses to assign, no DNS to configure, no NAT to punch through. If you can physically deliver bits between two Reticulum nodes — by any means — they can communicate, and the communication is encrypted by default.
Key properties that make Reticulum compelling for alternative networks:
Transport agnosticism. A single Reticulum network can span LoRa links, packet radio, TCP/IP tunnels, serial connections, and anything else that can carry bytes. The application does not need to know or care which physical transport is in use. This means you can build a network that routes over LoRa in the countryside, Wi-Fi in the town, and the internet between towns — all transparently.
Cryptographic identity. Every node, every destination, every link is identified by cryptographic keys. There is no concept of an unencrypted Reticulum connection. This is not a bolt-on feature — it is the fundamental architecture. Discovery, routing, and data transfer are all built on top of the cryptographic layer.
Extreme efficiency. Reticulum is designed to work on links as slow as 500 bits per second. Its overhead is minimal — headers are small, retransmission is efficient, and the protocol does not assume reliable or ordered delivery at the transport level. This makes it suitable for the constrained links that alternative networks often deal with.
LXMF and Nomad Network. On top of Reticulum, the LXMF (Lightweight Extensible Message Format) protocol provides store-and-forward messaging, and Nomad Network is a terminal-based communication application that uses LXMF. Together, they provide a complete messaging system that works over any Reticulum transport — including LoRa links that can only carry a few bytes per second.
# Minimal Reticulum announce listener
# Demonstrates how Reticulum discovers destinations cryptographically
import RNS
def announce_handler(destination_hash, announced_identity, app_data):
print(f"Received announce from {RNS.prettyhexrep(destination_hash)}")
if app_data:
print(f" App data: {app_data.decode('utf-8')}")
reticulum = RNS.Reticulum()
identity = RNS.Identity()
destination = RNS.Destination(
identity, RNS.Destination.IN, RNS.Destination.SINGLE,
"example", "service"
)
RNS.Transport.register_announce_handler(announce_handler)
print(f"Listening for announces. This node: {destination}")
input("Press Enter to exit...\n")
Reticulum is still young — the API is stabilizing but not yet frozen, and the user tooling is minimal compared to mature networking stacks. But its architecture is sound, its design philosophy is perfectly aligned with alternative networking, and its community is growing rapidly. If you are building an alternative network today, Reticulum deserves a place in your architecture, at least experimentally.
We touched on Yggdrasil in earlier chapters as an overlay network that provides end-to-end encrypted IPv6 networking. Yggdrasil assigns every node a /64 IPv6 subnet derived from its cryptographic keys, routes traffic over a spanning tree topology, and works across any underlying network — local mesh, VPN, internet, or mixed.
Yggdrasil continues to evolve in ways that are directly relevant to alternative networks. The project has been working on improved peer discovery, better support for mobile and intermittently connected nodes, and reduced memory consumption for deployment on constrained hardware like routers and single-board computers. The core routing algorithm — based on a distributed spanning tree with source routing — has been refined for better convergence times and reduced path stretch (the tendency for spanning-tree routing to use longer paths than the optimal shortest path).
What makes Yggdrasil particularly valuable is that it provides a familiar interface — standard IPv6 — for applications. Any application that speaks IPv6 can work over Yggdrasil without modification. This dramatically reduces the barrier to deployment: you do not need Yggdrasil-specific software. Your existing web servers, SSH daemons, file sharing tools, and chat applications work unmodified. This pragmatic approach — providing a compatibility bridge between the decentralized network and existing software — is arguably more important than any protocol innovation.
NNCP (Node-to-Node Copy Protocol) is a spiritual successor to UUCP — the Unix-to-Unix Copy Protocol that connected the early internet before TCP/IP became universal. UUCP worked by store-and-forward: machines would dial each other periodically, exchange queued mail and files, and hang up. It was slow, it was high-latency, and it worked over the most unreliable, low-bandwidth links imaginable. It connected the world before the world was connected.
NNCP brings this model into the modern era with modern cryptography (NaCl/libsodium), modern compression, and support for modern transports (TCP, pipes, USB drives, or any other byte stream). It is designed for delay-tolerant networking — the scenario where two nodes may only be able to communicate intermittently, perhaps when someone physically carries a USB drive between them, or when a LoRa link has a few minutes of connectivity each day.
For alternative networks, NNCP fills a niche that most other protocols ignore: the very-high-latency, very-low-bandwidth, possibly-disconnected link. Want to exchange email between two villages that are connected by a weekly bus? Plug a USB drive into the NNCP node in Village A, put it on the bus, plug it in at Village B. NNCP handles the encryption, authentication, queuing, and deduplication. This is not a theoretical scenario — it is how many rural communities in developing countries actually communicate.
# Conceptual example: building an NNCP-style store-and-forward queue
import hashlib
import json
import time
from pathlib import Path
class StoreForwardQueue:
"""Simple store-and-forward message queue for delay-tolerant links."""
def __init__(self, spool_dir: str = "/var/spool/altnet"):
self.spool = Path(spool_dir)
self.spool.mkdir(parents=True, exist_ok=True)
def enqueue(self, destination: str, payload: bytes) -> str:
msg_id = hashlib.sha256(payload + str(time.time()).encode()).hexdigest()[:16]
msg = {"id": msg_id, "dst": destination, "ts": time.time(),
"size": len(payload), "delivered": False}
(self.spool / f"{msg_id}.meta").write_text(json.dumps(msg))
(self.spool / f"{msg_id}.dat").write_bytes(payload)
return msg_id
def pending(self, destination: str) -> list:
"""Return all undelivered messages for a destination."""
msgs = []
for meta_file in self.spool.glob("*.meta"):
meta = json.loads(meta_file.read_text())
if meta["dst"] == destination and not meta["delivered"]:
msgs.append(meta)
return sorted(msgs, key=lambda m: m["ts"])
Veilid (pronounced “vay-lid”) is a framework for building decentralized applications, developed by the team behind the Cult of the Dead Cow — one of the oldest and most respected hacking collectives. Veilid provides a peer-to-peer network layer with built-in encryption, identity management, and distributed storage, designed so that application developers can build decentralized apps without needing to understand the underlying peer-to-peer networking.
Think of Veilid as analogous to what IPFS provides for storage, but generalized to arbitrary application data and real-time communication. It uses a Kademlia-style distributed hash table (DHT) for node discovery and data routing, with multiple layers of encryption and onion routing for privacy. Every Veilid node contributes bandwidth and storage to the network, and applications built on Veilid benefit from the combined resources of all nodes.
The first application built on Veilid is VeilidChat, a secure messaging app. But the framework is designed to support any application — social networks, file sharing, collaborative tools — with the same decentralized, encrypted infrastructure. For alternative networks, Veilid is interesting because it provides application-layer infrastructure that is missing from most mesh and overlay protocols. Reticulum gives you encrypted transport. IPFS gives you content-addressed storage. Veilid gives you both, plus a higher-level application framework that handles the details of peer discovery, data replication, and connection management.
Veilid is still in active development and not yet suitable for production use, but the architecture is solid, the team is experienced, and the design goals align precisely with what alternative networks need.
Nostr takes a radically different approach to decentralization. Instead of building a complex peer-to-peer network, Nostr uses a simple client-relay model. Users sign messages with their cryptographic private keys and send them to relays — simple servers that accept and store signed messages. Anyone can run a relay. Clients connect to multiple relays simultaneously and aggregate the messages they receive.
The brilliance of Nostr is its simplicity. The protocol specification fits on a few pages. A relay is essentially a WebSocket server with a database. There is no consensus mechanism, no complex routing, no distributed hash table. Users are identified by their public keys. Messages are signed and therefore tamper-proof. And because clients connect to multiple relays, no single relay can censor a user — the user simply sends their messages to other relays.
Nostr’s relevance for alternative networks is twofold. First, its simplicity makes it deployable on constrained infrastructure — a Nostr relay can run on a Raspberry Pi with minimal resources, making it practical for community mesh networks. Second, the protocol’s relay model maps naturally to the kind of intermittent, multi-path connectivity that alternative networks provide. A Nostr client can sync with a local relay when on the mesh, and with internet-connected relays when internet access is available, seamlessly bridging the two worlds.
The Nostr ecosystem has grown rapidly since its emergence. Clients exist for every platform. Relay implementations exist in dozens of languages. And the protocol is being extended (via NIPs — Nostr Implementation Possibilities) to support not just text notes but also long-form content, encrypted direct messages, marketplace listings, and even live streaming. It is messy, it is chaotic, and it is one of the most vibrant decentralized protocol ecosystems in existence.
# Minimal Nostr event creation and signing
import json
import hashlib
import time
from secp256k1 import PrivateKey
def create_nostr_event(private_key_hex: str, content: str, kind: int = 1) -> dict:
"""Create and sign a Nostr event (NIP-01)."""
sk = PrivateKey(bytes.fromhex(private_key_hex))
pubkey = sk.pubkey.serialize()[1:].hex() # x-only public key
created_at = int(time.time())
tags = []
# Serialized event for hashing: [0, pubkey, created_at, kind, tags, content]
serialized = json.dumps([0, pubkey, created_at, kind, tags, content],
separators=(',', ':'), ensure_ascii=False)
event_id = hashlib.sha256(serialized.encode()).hexdigest()
sig = sk.schnorr_sign(bytes.fromhex(event_id), bip340tag=None).hex()
return {"id": event_id, "pubkey": pubkey, "created_at": created_at,
"kind": kind, "tags": tags, "content": content, "sig": sig}
Traditional mesh routing protocols — BATMAN, Babel, OLSR — use fixed algorithms to select paths. They measure link quality using metrics like packet loss, latency, or throughput, and they apply deterministic rules to select the best path. These algorithms work well in stable environments, but alternative networks are rarely stable. LoRa link quality fluctuates with weather, temperature, and foliage density. Wi-Fi mesh links degrade when neighbors start streaming video. Mobile nodes move in and out of range unpredictably.
Machine learning-based adaptive routing uses historical data about link performance to predict future link quality and make routing decisions proactively rather than reactively. Instead of waiting for a link to degrade and then reconverging, an ML-based routing system can predict that link quality typically drops on this particular LoRa path at 3 PM (when temperature-driven atmospheric conditions change propagation) and pre-emptively shift traffic to an alternative path.
This is not hypothetical research. Reinforcement learning approaches to network routing have been demonstrated in academic settings, and simplified versions are beginning to appear in commercial networking products. For alternative networks, where link conditions are often more variable and less predictable than in enterprise environments, ML-based routing could provide significant improvements in reliability and throughput.
The challenge is computational: running ML inference on the constrained hardware that alternative network nodes typically use (routers, Raspberry Pis, LoRa boards). But inference on small models is becoming increasingly feasible on low-power hardware, and the models needed for routing — which process relatively small feature sets (link metrics, time of day, weather) and produce simple outputs (path rankings) — are not large.
# Simplified ML-based link quality predictor for mesh routing
import numpy as np
from collections import deque
class LinkQualityPredictor:
"""Predict future link quality using exponential weighted features."""
def __init__(self, history_size: int = 100):
self.history = deque(maxlen=history_size)
self.weights = None
def record(self, timestamp: float, rssi: float, snr: float, loss_rate: float):
hour = (timestamp % 86400) / 3600 # Time of day feature
self.history.append([hour, rssi, snr, loss_rate])
def predict_quality(self, future_hour: float) -> float:
"""Predict link quality score (0-1) for a given hour."""
if len(self.history) < 20:
return 0.5 # Not enough data, return neutral
data = np.array(self.history)
# Simple: weighted average of quality at similar times of day
hours = data[:, 0]
time_diff = np.abs(hours - future_hour)
time_diff = np.minimum(time_diff, 24 - time_diff) # Circular
weights = np.exp(-time_diff) # Weight nearby times higher
quality = 1.0 - data[:, 3] # Quality = 1 - loss_rate
return float(np.average(quality, weights=weights))
Alternative network infrastructure is typically maintained by volunteers, not professional network operations teams. Nodes are installed on rooftops and forgotten about until they fail. Solar-powered nodes silently degrade as batteries age. Antenna connectors corrode. SD cards in Raspberry Pis wear out. By the time someone notices a problem, the node has been down for days or weeks.
Predictive maintenance uses machine learning to detect the subtle patterns that precede failure. A solar-powered node’s battery voltage profile changes gradually as the battery ages — daily charge/discharge cycles become shallower, and the battery struggles to maintain voltage during peak load. An ML model trained on voltage data from healthy and degrading batteries can flag a node for maintenance weeks before it actually fails.
Similarly, link quality degradation patterns often precede failure. A slowly rusting antenna connector shows up as gradually increasing packet loss over weeks. An overheating radio shows up as performance drops during afternoon hours that worsen over time. These patterns are difficult for humans to spot in dashboards (who monitors a community mesh dashboard daily?) but straightforward for time-series anomaly detection algorithms.
The practical implementation for alternative networks is a lightweight monitoring agent that runs on each node, collects key metrics (battery voltage, CPU temperature, link quality, uptime), and periodically feeds them to a central analysis service — which could be a Raspberry Pi running a simple anomaly detection model on the mesh’s local server.
As the radio environment becomes more complex — with Wi-Fi 7 nodes, LoRa devices, CBRS radios, and legacy equipment all operating in overlapping areas — manual spectrum management becomes impractical. Choosing Wi-Fi channels, selecting LoRa spreading factors, and coordinating CBRS frequency use currently requires expertise and manual configuration.
AI-driven spectrum management automates this process. A machine learning system monitors the radio environment (using spectrum scanning data from the network’s own radios or dedicated SDR sensors), identifies interference patterns, and dynamically reconfigures the network’s radios to minimize interference and maximize throughput. This is essentially what CBRS’s SAS does for the 3.5 GHz band, but generalized to all frequencies the network uses.
For a community mesh network, this might look like: an SDR dongle on the gateway node continuously scans the 2.4 GHz, 5 GHz, and 6 GHz bands. An ML model identifies which channels are congested and at what times. The system automatically reconfigures the mesh nodes’ channel assignments overnight, pushing updated configurations via the mesh itself. The result is a mesh that adapts to its radio environment without human intervention.
Perhaps the most immediately practical application of AI in alternative networks is natural language interfaces for network management. Configuring a mesh network currently requires comfort with command-line interfaces, understanding of networking concepts, and familiarity with multiple configuration file formats. This is a significant barrier for community networks where the technically skilled founder may eventually move away or lose interest.
Large language models can serve as natural-language front-ends to network management tools. Instead of remembering that the command to check BATMAN-adv neighbor status is sudo batctl n, a community member could type “show me which mesh nodes are online” into a chat interface and get a formatted, understandable response. Instead of editing /etc/config/wireless to add a new mesh node, they could describe what they want and have the LLM generate the appropriate configuration.
This is not a replacement for understanding — it is a force multiplier for communities where deep networking expertise is concentrated in one or two people. The LLM becomes institutional knowledge that is always available, infinitely patient, and never moves to another city.
RISC-V is an open-source instruction set architecture that is doing to processors what Linux did to operating systems: removing the proprietary lock-in that has characterized computing hardware for decades. Unlike ARM (which requires licensing from ARM Holdings) or x86 (controlled by Intel and AMD), RISC-V is free for anyone to implement, modify, and manufacture.
For alternative networks, RISC-V matters because it enables truly open hardware. Currently, every router, every single-board computer, and every embedded device in your mesh runs on a processor whose design is proprietary and whose firmware may contain opaque binary blobs. RISC-V-based networking hardware can be audited completely — from the instruction set through the operating system to the application code. There are no black boxes.
RISC-V networking hardware is already appearing. The Sipeed LicheeRV and StarFive VisionFive 2 are RISC-V single-board computers capable of running Linux. BananaPi has released RISC-V-based boards with integrated networking. While these early devices are not yet competitive with ARM-based alternatives on performance or power efficiency, the trajectory is clear: RISC-V will become a viable — and philosophically preferable — platform for alternative network infrastructure within the next few years.
The combination of RISC-V hardware, open-source firmware (OpenWrt, for instance, already has experimental RISC-V support), and open RF hardware creates the possibility of a network stack that is open and auditable from antenna to application. For communities and individuals who care about trust and transparency in their infrastructure — which is presumably most readers of this book — this is a meaningful development.
Espressif’s ESP32 family has been the workhorse of alternative networking hardware — Meshtastic runs on ESP32, countless LoRa projects use ESP32 boards, and the chip’s combination of Wi-Fi, Bluetooth, and general-purpose I/O at under $5 has made it the Arduino of wireless. The newest family members push capabilities significantly further.
The ESP32-S3 adds a vector instruction set for on-device machine learning inference, USB OTG for direct computer connectivity, and more GPIO pins. For alternative networks, the ML capability is the headline: running tiny models for link quality prediction, anomaly detection, or voice activity detection directly on the mesh node hardware.
The ESP32-C6 is the more transformative chip. It adds Wi-Fi 6 (802.11ax) support — the first sub-$10 chip to do so — and, critically, 802.15.4 radio support, which means it can run Thread and Zigbee natively alongside Wi-Fi. Thread is a mesh networking protocol for IoT that provides IPv6 connectivity over low-power radio. Having Wi-Fi 6 and Thread on a single $5 chip means you can build mesh nodes that bridge between Wi-Fi and Thread networks, creating multi-protocol mesh topologies that were previously impractical.
The ESP32-C6 also supports the Matter smart home protocol (which runs over Thread and Wi-Fi), creating an interesting possibility: alternative mesh networks that seamlessly integrate with the growing ecosystem of Matter-compatible smart home devices.
The ESP32-C5, expected in volume production in 2026, will add Wi-Fi 6 dual-band (2.4 and 5 GHz) support to this family, further closing the gap between maker hardware and commercial networking equipment.
Software-Defined Radio (SDR) replaces fixed-function radio hardware with software that can transmit and receive on virtually any frequency and with virtually any modulation scheme. An SDR can be a Wi-Fi radio, a LoRa radio, a TV receiver, a cellular modem, or a radio telescope — all in software.
SDR has been the province of experts and hobbyists, but several trends are pushing it toward mainstream relevance for alternative networks:
Cost collapse. The RTL-SDR blog V4 receiver costs $30. The HackRF One, a capable transmit-and-receive SDR, costs $300. The PlutoSDR costs $200. These prices continue to fall. For alternative network builders, affordable SDRs enable experimentation with protocols and frequencies that would otherwise require expensive single-purpose hardware.
Software maturity. GNU Radio, the open-source SDR framework, has matured significantly. It now includes well-tested implementations of many protocols relevant to alternative networks, and its companion ecosystem (gr-lora, gr-satellites, and others) provides ready-to-use implementations for decoding and generating signals.
FPGA acceleration. Low-cost FPGA boards (like the Lattice iCE40 series) can accelerate SDR processing, enabling real-time operation with protocols that would overwhelm a general-purpose CPU. Combined with open-source FPGA toolchains (Yosys, nextpnr), this creates the possibility of fully open, fully auditable radio hardware — from the antenna through the FPGA to the software.
For alternative networks, the long-term implication of SDR is protocol agility: mesh nodes that can switch between protocols based on conditions. Need long range? Switch to LoRa modulation. Need high bandwidth? Switch to Wi-Fi. Need to communicate with a legacy ham radio? Switch to AX.25. All on the same hardware. This is still largely experimental, but the pieces are falling into place.
The meta-trend underlying all hardware developments is the relentless decrease in cost and increase in capability of the components that alternative networks are built from:
| Component | 2020 | 2026 | Trend |
|---|---|---|---|
| LoRa transceiver module | $15 | $5 | Commoditizing |
| Wi-Fi 6 capable SoC | $25+ | $5 (ESP32-C6) | Democratizing |
| 4 GB SBC (Raspberry Pi class) | $55 | $35–45 | Slowly decreasing |
| Solar panel (5W) | $15 | $8 | Steadily declining |
| LiFePO4 battery (12V 6Ah) | $40 | $20 | Rapidly declining |
| SDR receiver | $25 | $15 | Approaching disposable |
| Outdoor LoRa gateway | $300 | $100 | Becoming accessible |
This cost trajectory means that deploying a mesh node — solar powered, with LoRa and Wi-Fi connectivity, running Linux — is approaching the $50–$75 range. A ten-node community mesh that would have cost thousands of dollars in 2020 can be built for a few hundred. This is the threshold at which alternative networks stop being technical projects and start being community utilities.
The traditional model of spectrum management — divide the radio spectrum into blocks and auction them to the highest bidder for exclusive use — is profoundly inefficient. Studies consistently show that most licensed spectrum is unused most of the time in most locations. A television broadcaster may have exclusive rights to a channel across an entire metropolitan area, but the actual transmissions occupy only a fraction of that coverage. The rest is wasted — unused spectrum that no one else is allowed to touch.
Dynamic Spectrum Access (DSA) replaces this static allocation with real-time sharing. Devices sense the spectrum environment, consult databases of licensed usage, and dynamically use whatever frequencies are available at their location and time. CBRS and TVWS are early examples, but the concept is being extended:
The FCC’s AFC (Automated Frequency Coordination) system for the 6 GHz band is essentially DSA: standard-power Wi-Fi 6E/7 devices must consult an AFC database to determine which 6 GHz channels they can use without interfering with incumbent fixed microwave links. As AFC systems become more sophisticated, they may enable more flexible and dynamic use of the 6 GHz band.
The European Union’s Licensed Shared Access (LSA) framework is being applied to additional bands, following the CBRS model but adapted to European regulatory traditions.
For alternative networks, the trend toward DSA is unambiguously positive. Every spectrum sharing framework that is adopted means more usable spectrum for community and unlicensed networks. The long-term trajectory — driven by the inefficiency of static allocation and the improving capability of DSA technology — points toward a future where most spectrum is shared rather than exclusively licensed.
A growing number of governments and regulatory bodies are explicitly recognizing community networks in their policy frameworks. This is a significant shift from the historical norm, where telecommunications regulation assumed that networks were built by corporations or governments.
The European Union has included community networks in its broadband strategy, and several EU member states provide funding and regulatory support for community broadband projects. Mexico created a specific license category for indigenous community telecommunications networks. Brazil’s ANATEL has simplified licensing for community ISPs. India’s PM-WANI framework enables anyone to become a Wi-Fi hotspot provider with minimal regulatory burden.
The Association for Progressive Communications (APC) and the Internet Society have been instrumental in advocating for community network-friendly regulations internationally, publishing model regulatory frameworks and providing technical assistance to community networks in developing countries.
For alternative network builders, this trend means that the regulatory environment is becoming more favorable — not everywhere, not quickly enough, but the direction is clear. Community networks are being recognized as legitimate and valuable components of the telecommunications landscape, not as rogue operators to be shut down.
The right to repair movement is relevant to alternative networks because network hardware — like all electronics — eventually breaks, and the ability to repair, modify, and repurpose hardware is essential for sustainable community infrastructure.
Legislation mandating repairability, access to spare parts, and publication of repair documentation is advancing in the EU (which has adopted right to repair rules for several product categories), in multiple U.S. states, and in other jurisdictions. For network hardware specifically, this means that routers, radios, and embedded devices may increasingly come with accessible firmware, documented hardware interfaces, and available spare parts.
The open hardware movement goes further, producing hardware designs that are published under open licenses. Projects like LibreRouter (a router designed specifically for community mesh networks, with open hardware design files) demonstrate that open hardware for networking is practical and that community-designed hardware can be optimized for community use cases in ways that commercial hardware is not.
The ongoing tension between law enforcement demands for exceptional access to encrypted communications and the technical reality that strong encryption does not admit backdoors will shape the future of alternative networks significantly.
Proposals like the EU’s Chat Control regulation, Australia’s Assistance and Access Act, and the UK’s Online Safety Act provisions on end-to-end encryption represent attempts to mandate that communications platforms provide government access to encrypted content. The technical consensus among cryptographers is clear: there is no way to provide this access without fundamentally weakening the encryption for everyone.
For alternative networks, which often use end-to-end encryption as a foundational architectural principle, these regulatory battles are existential. A legal mandate to backdoor encryption would compromise the security model that makes alternative networks trustworthy. The alternative networking community must engage with these policy debates — not just as technologists, but as citizens advocating for the right to private communication that has been a cornerstone of free societies.
On the positive side, there is growing recognition among policymakers that strong encryption is essential for cybersecurity, economic competitiveness, and human rights. The tension has not been resolved, and likely will not be fully resolved for years, but the technical arguments for strong encryption are increasingly well-understood in policy circles.
In centralized systems, your identity is whatever Google, Facebook, or your government says it is. They issue the identifier, they control the authentication, and they can revoke your identity at any time. On a community mesh network, this model is obviously unsuitable — you do not want your network identity to depend on a corporation or government that you are, by definition, operating independently of.
Decentralized Identifiers (DIDs) are a W3C standard for identifiers that are created, owned, and controlled by the subject — not by any central authority. A DID looks like did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK — an identifier derived from a cryptographic key pair that you generated yourself. No one issued it to you. No one can revoke it.
DIDs are accompanied by DID Documents — metadata that describes how to authenticate the DID subject, what services they offer, and how to communicate with them. DID Documents can be stored on blockchains, distributed hash tables, or any other resolvable storage — but critically, they can also be resolved without any global infrastructure, using the did:key or did:peer methods that derive all necessary information directly from the identifier itself.
For community mesh networks, DIDs provide a natural identity layer. Each node, each user, each service can have a DID that is self-issued, cryptographically verifiable, and does not depend on any external infrastructure. Combined with the cryptographic identity systems already built into protocols like Reticulum and Yggdrasil, DIDs provide a standardized way to manage identity across multiple protocols and applications.
Once you have decentralized identity, you need a way to make claims about that identity. In the centralized world, this is handled by certificates, API tokens, and database entries. In the decentralized world, the corresponding concept is Verifiable Credentials (VCs).
A VC is a cryptographically signed statement by an issuer about a subject. “This DID has completed the mesh network operator training.” “This node is authorized to participate in the community network.” “This user is a member of the neighborhood association that operates this mesh.” The credential is signed by the issuer’s DID and can be verified by anyone without contacting the issuer.
For community networks, VCs solve the access control problem. Who is allowed to use the mesh? Who can configure the gateway? Who has permission to run a Nostr relay on the community server? These are governance questions, and VCs provide a technical mechanism for implementing governance decisions without a centralized authority server that must be always-online and always-trusted.
# Conceptual Verifiable Credential for mesh network membership
import json
import time
def create_mesh_membership_vc(
issuer_did: str,
subject_did: str,
network_name: str,
role: str = "member"
) -> dict:
"""Create a W3C-style Verifiable Credential for mesh membership."""
return {
"@context": ["https://www.w3.org/2018/credentials/v1"],
"type": ["VerifiableCredential", "MeshNetworkMembership"],
"issuer": issuer_did,
"issuanceDate": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime()),
"credentialSubject": {
"id": subject_did,
"networkName": network_name,
"role": role,
"permissions": {
"data_transit": True,
"local_services": True,
"gateway_access": role in ("member", "admin"),
"admin_config": role == "admin",
}
}
}
# Example: community network admin issues membership
vc = create_mesh_membership_vc(
issuer_did="did:key:z6MkAdmin...",
subject_did="did:key:z6MkNewUser...",
network_name="Oakwood Neighborhood Mesh",
role="member"
)
print(json.dumps(vc, indent=2))
The combination of DIDs and VCs enables self-sovereign identity (SSI) — a model where individuals control their own digital identity without relying on any central authority. For community networks, SSI provides several concrete benefits:
Onboarding without a central server. New members can join the network by generating a DID, receiving a VC from an existing member who vouches for them, and presenting that VC to the network’s access control system. No central database needs to be consulted. No always-on authentication server is required.
Portable identity across networks. If a user’s DID is their identity, they can use the same identity across multiple community networks, mesh overlays, and decentralized services. Their reputation, their credentials, and their contact relationships travel with them.
Privacy-preserving authentication. VCs support selective disclosure — proving that you are authorized without revealing who you are. A mesh node can verify that an incoming connection holds a valid membership credential without learning the user’s name, address, or any other personal information. This is the kind of privacy that centralized systems cannot provide.
It would be irresponsible to write a chapter on future technologies without addressing Web3 — the constellation of technologies centered on blockchains, tokens, DAOs, and NFTs that has attracted enormous investment and equally enormous skepticism.
For alternative networks, the honest assessment is that most of Web3 is irrelevant or actively counterproductive. Proof-of-work blockchains consume enormous amounts of energy. Token economies create perverse incentives. DAOs have repeatedly demonstrated that decentralized governance is extraordinarily difficult. NFTs solved a problem that almost no one had. The financial speculation that drove the Web3 boom distracted from genuinely useful decentralized technology.
But there are useful elements worth salvaging:
Content addressing (as in IPFS) is genuinely valuable for alternative networks and does not require any blockchain.
Cryptographic identity (DIDs, key-based identity) is essential and does not require tokens or financial incentives.
Distributed consensus has specific, narrow use cases — for example, maintaining a community network’s membership registry or coordinating shared resources — where simple consensus protocols (not energy-hungry blockchains) are appropriate.
Smart contracts, stripped of the financial speculation, are essentially programmable governance rules. A community network that wants to automatically enforce bandwidth fairness, or automatically revoke access for nodes that violate network policies, could use contract-like logic — but running it on a local system, not on a global blockchain.
The principle is simple: adopt the cryptographic and architectural innovations; reject the financialization. Community networks should be built on shared ownership and mutual aid, not token economics and speculative profit.
One of the most significant developments for alternative networking is the quiet incorporation of mesh and peer-to-peer capabilities into mainstream consumer devices:
Apple’s ecosystem already includes significant mesh and peer-to-peer networking. AirDrop uses peer-to-peer Wi-Fi and Bluetooth for local file transfer. AirPlay uses peer-to-peer for screen mirroring. The Find My network is a massive Bluetooth LE mesh — every iPhone, iPad, and Mac silently participates in locating AirTags and other Find My-enabled devices. Apple’s Multipeer Connectivity Framework allows any app to discover and communicate with nearby devices over Wi-Fi and Bluetooth without any infrastructure. This framework has been used for everything from multiplayer games to protest communication tools.
Google’s Nearby Share (now Quick Share) provides peer-to-peer file transfer on Android. Google’s Thread implementation in Nest devices creates mesh networks in homes. Android’s Wi-Fi Aware API enables device-to-device communication without an access point.
The significance for alternative networks is not that Apple and Google are building alternative networks — they are not; their implementations are proprietary, closed, and designed to lock users into their respective ecosystems. The significance is that the hardware capabilities for mesh networking are now in billions of pockets. Every modern smartphone has the radios (Wi-Fi, Bluetooth LE, and increasingly UWB) needed for mesh networking. The constraint is software and willingness, not hardware.
Projects like Briar (which uses Wi-Fi and Bluetooth for peer-to-peer messaging on Android) and Bridgefy (which used Bluetooth mesh for messaging during the Hong Kong protests) demonstrate that these hardware capabilities can be accessed by alternative network software. As mesh-capable hardware becomes universal, the potential reach of alternative networks expands from “people who buy specialized equipment” to “everyone with a smartphone.”
Thread is a low-power mesh networking protocol for IoT, built on IEEE 802.15.4 (the same radio standard used by Zigbee). Thread provides IPv6 connectivity — real, routable IPv6 — over a self-healing mesh network. Unlike Zigbee, which uses a proprietary application layer, Thread is a pure networking protocol: it provides the mesh and the IP connectivity, and any application protocol can run on top.
Matter is the application layer — a unified smart home standard backed by Apple, Google, Amazon, Samsung, and hundreds of other companies. Matter runs over Thread (for low-power devices) and Wi-Fi (for higher-bandwidth devices), and it provides a standardized way for smart home devices to discover, authenticate, and communicate with each other.
For alternative networks, Thread and Matter are significant because they represent the mainstreaming of mesh networking in consumer hardware. Every Thread device is a mesh router. A home with a dozen Thread-enabled smart home devices has a twelve-node mesh network operating automatically, invisibly, and reliably. The technology works — Thread meshes self-configure, self-heal, and operate without any user intervention.
The lesson for alternative network builders is that mesh networking can be made invisible and reliable enough for non-technical users. Thread’s success demonstrates that the technology is not the barrier — the deployment model, the user experience, and the governance are the real challenges.
There is a scenario — not certain, but plausible — where the technologies described in this book stop being “alternative” and become simply how networks work. Consider the convergence:
In this convergence scenario, the “alternative internet” becomes a layer that coexists with — and in many cases replaces — the centralized internet for local communication. Your neighborhood mesh handles local traffic. LoRa handles environmental monitoring and emergency communication. The internet handles long-distance communication and access to global services. And all of it is encrypted, self-healing, and community-owned.
This is not utopian fantasy. Every component in that list either exists today or is in active development with clear timelines. The question is not whether these technologies will mature, but whether communities will organize to deploy them.
Technology changes. Protocols evolve. Hardware becomes obsolete. The network you build today will need to adapt over years or decades. Here are the principles that maximize your network’s ability to survive technological change:
Modularity over monoliths. Design your network as a collection of independent, interchangeable components rather than a tightly integrated system. If your mesh routing is BATMAN-adv today, it should be possible to swap it for a different protocol tomorrow without rebuilding the entire network. If your messaging runs on Matrix today, it should be possible to add Nostr or LXMF alongside it. Modularity means that any component can be upgraded, replaced, or removed without cascading failures.
Protocol agnosticism at the physical layer. Do not bet your network’s future on a single radio technology. A network that only works on Wi-Fi is fragile. A network that can use Wi-Fi, LoRa, Ethernet, and whatever comes next is resilient. This is why Reticulum’s transport-agnostic design is so appealing — it does not care what carries the bits, so your network survives the transition from one physical layer to another.
Encryption as a non-negotiable default. Every link, every message, every connection should be encrypted by default. Not because you have something to hide, but because encryption is the only technical guarantee of privacy and integrity. Protocols that are designed with encryption from the start (Reticulum, WireGuard, Noise Protocol Framework) are strongly preferable to protocols where encryption is an optional add-on.
Minimal external dependencies. Every dependency on external infrastructure — DNS, NTP, certificate authorities, cloud services — is a point of failure and a point of control. Prefer protocols and applications that function without external dependencies. Use local NTP sources. Use content-addressed or cryptographic naming instead of DNS. Use self-signed or peer-verified certificates instead of commercial CAs.
Document everything. The most future-proof thing you can do is write down how your network works: the topology, the configuration, the design decisions and the reasons behind them. People leave communities. Memory fades. Documentation survives. A well-documented network can be maintained by newcomers; an undocumented network dies with its creator’s involvement.
The most technically sophisticated alternative network in the world is worthless if the community that maintains it dissolves. Technical resilience — redundant links, self-healing routing, failover services — is necessary but not sufficient. You also need community resilience: the social structures and practices that keep the network maintained, funded, and relevant over time.
This means:
Distributing knowledge. If only one person knows how to configure the gateway, your network has a bus factor of one. Train multiple people. Write documentation (see above). Hold regular workshops where community members learn networking skills.
Establishing governance. Who decides whether to upgrade the firmware? Who approves new members? How are disputes resolved? Informal governance works for small groups but fails as networks grow. Consider adopting a simple governance framework — even a one-page document that describes decision-making processes — before you need it.
Planning for funding. Hardware breaks. Electricity costs money. Someone needs to buy replacement parts. A sustainable community network has a transparent funding model, whether it is member dues, grants, donations, or in-kind contributions.
Integrating with daily life. A network that is only useful during emergencies will not be maintained between emergencies. The most resilient community networks are the ones that people use every day — for sharing files, chatting with neighbors, accessing local services, or saving money on internet access. Daily use means daily testing, which means problems are caught early and motivation to maintain the network stays high.
# Community network health dashboard — key metrics to track
from dataclasses import dataclass
from datetime import datetime
@dataclass
class NetworkHealthMetrics:
"""Metrics that indicate community network sustainability."""
# Technical health
active_nodes: int
nodes_online_pct: float
avg_uptime_days: float
links_with_redundancy_pct: float
# Community health
active_maintainers: int
documented_procedures: int
last_training_date: datetime
monthly_active_users: int
# Financial health
monthly_cost_usd: float
monthly_funding_usd: float
reserve_months: float # How many months of reserves
def sustainability_score(self) -> float:
"""0-100 score indicating overall sustainability."""
tech = min(self.nodes_online_pct, 100) * 0.2
tech += min(self.links_with_redundancy_pct, 100) * 0.1
community = min(self.active_maintainers / 3, 1.0) * 25 # Want 3+
community += min(self.documented_procedures / 10, 1.0) * 10
financial = min(self.reserve_months / 6, 1.0) * 20 # Want 6+ months
financial += (1 if self.monthly_funding_usd >= self.monthly_cost_usd
else self.monthly_funding_usd / max(self.monthly_cost_usd, 1)) * 15
return round(tech + community + financial, 1)
This book has taken you on a journey from networking fundamentals to mesh protocols, from LoRa radios to decentralized applications, from antenna theory to community governance. If you have built any of the projects in the previous chapter, you have already created something that most people believe is impossible: a working communications network that you own, control, and operate without asking anyone’s permission.
That matters. It matters because the centralized internet, for all its wonders, is becoming less free, less open, and less resilient. ISP consolidation continues. Government surveillance expands. Platform monopolies tighten. Infrastructure that billions depend on is controlled by a handful of corporations whose incentives do not always align with their users’ interests. And the physical infrastructure — cell towers, fiber optic cables, data centers — remains vulnerable to natural disasters, conflict, and neglect in underserved areas.
Alternative networks are not about rejecting the internet. They are about ensuring that the ability to communicate — the most fundamental requirement of community, democracy, and human coordination — does not depend entirely on systems you cannot control, cannot inspect, and cannot repair.
Every mesh node you deploy is a statement: communication infrastructure can be owned by the people who use it. Every LoRa radio you configure is a proof of concept: long-range communication does not require a cell tower or a monthly bill. Every decentralized service you run is a demonstration: digital services can exist without corporate intermediaries.
The technology exists. The hardware is affordable. The software is open source. The protocols are maturing. What is needed now is people — people willing to learn, to build, to teach their neighbors, to make mistakes and share what they learn, to maintain infrastructure that serves their community.
Start small. Set up a two-node Meshtastic link with a friend. Deploy a Reticulum node and see what the network looks like. Flash OpenWrt on a spare router and configure BATMAN-adv. Run an IPFS node and pin something that matters to you. Set up a Matrix server and invite your family. Put a LoRa sensor on your roof and contribute weather data to your community.
Then expand. Connect your nodes to your neighbor’s nodes. Organize a workshop at your local library or hackerspace. Find the community networks near you — there are more than you think — and contribute your skills. Write documentation. File bug reports. Submit patches. Help someone who is newer than you.
The alternative internet is not a product to be consumed. It is infrastructure to be built, by communities, for communities. And the best time to start building it is now.
Communities and Organizations:
Technical Resources:
reticulum.network — Hardware-agnostic encrypted networkingmeshtastic.org — LoRa mesh communicationopenwrt.org — Open-source router firmwareipfs.tech — Decentralized storagematrix.org — Federated communicationnostr.com — Decentralized notes protocolveilid.com — Decentralized application frameworkHardware:
Books and Standards:
The future of networking is not a single, monolithic internet controlled by a few corporations. It is a fabric of interconnected networks — local meshes, long-range radio links, satellite connections, community infrastructure, and global internet — woven together by open protocols and maintained by the communities they serve.
You now have the knowledge to contribute a thread to that fabric. Go build.
| ← Previous: Practical Projects | Table of Contents |