Every technology we have explored so far — mesh routers, LoRa radios, ad-hoc protocols, peer-to-peer overlays — is ultimately a means to an end. The end is not the technology itself. The end is people connecting to each other, sharing knowledge, coordinating action, accessing services, and participating in the digital world on their own terms. The technology is the scaffold; the community is the building.
This chapter is about what happens when communities stop waiting for a corporation to bring them connectivity and start building it themselves. Not as a weekend project, not as a proof of concept, but as a permanent, self-sustaining piece of civic infrastructure — owned, operated, and governed by the people it serves.
The idea is neither new nor radical. Before the telephone was a corporate monopoly, rural communities in the United States and Europe strung their own telephone lines and operated their own exchanges. Before the electrical grid reached every farmstead, rural cooperatives pooled their resources to build power systems that the investor-owned utilities refused to build. The Rural Electrification Administration of the 1930s did not bring electricity to rural America by building power plants — it provided loans and technical assistance to communities that built their own.
Community networks are the 21st-century equivalent of those rural telephone cooperatives and electrical co-ops. They are networks built, owned, and operated by the communities they serve. Some are tiny — a handful of rooftop antennas sharing a single internet connection across a neighborhood. Others are enormous — tens of thousands of nodes spanning entire regions, with governance structures, paid staff, and formal legal status. What they all share is a rejection of the premise that connectivity must be delivered by a profit-seeking corporation, and an embrace of the idea that communication infrastructure can be a commons — a shared resource, managed collectively, for the benefit of all.
This chapter examines the community network movement in depth: its history and philosophy, its most successful real-world examples, its technical architecture, its business models, and the practical steps required to start one from scratch. If the previous chapters gave you the technical tools to build networks, this chapter gives you the organizational tools to make them last.
The notion that communities should own their communication infrastructure predates the internet by a century. In the early 1900s, thousands of small telephone cooperatives operated across rural North America and Europe. These were not hobbyist projects — they were essential services, built because the Bell System and its European equivalents found it unprofitable to string copper to every farmhouse. Farmers literally hung wire on fence posts, pooled money to buy switchboard equipment, and hired a neighbor to operate the exchange.
The same pattern repeated with electricity. In the 1930s, roughly 90% of American farms had no electricity. Private utilities refused to extend their grids into sparsely populated areas where the return on investment was uncertain. The solution was not to force utilities to build — it was to empower communities to build for themselves. Between 1935 and 1960, over 900 rural electric cooperatives were formed in the United States, many of which still operate today, providing power to over 40 million people.
The internet is following the same arc, just on a compressed timeline. Commercial ISPs have connected the profitable areas — dense cities, affluent suburbs — and largely ignored the rest. In the United States, the Federal Communications Commission estimates that over 20 million people lack access to broadband. In Europe, rural connectivity gaps persist despite EU funding programs. In the Global South, the numbers are staggering: billions of people remain offline, not because the technology does not exist, but because no business case exists for connecting them.
Community networks emerge in this gap between need and market. They are, in many ways, the rural electric cooperatives of the digital age.
The philosophical foundation of the community network movement is the concept of the digital commons — the idea that communication infrastructure, like water, air, and public roads, should be treated as a shared resource rather than a private commodity.
This is not socialism, and it is not anarchism, though it shares elements with both. The commons is a distinct form of resource governance, distinct from both state ownership and private property. In a commons, the resource is collectively managed by its users according to rules they define together. The most influential scholar of commons governance, Elinor Ostrom, won the Nobel Prize in Economics in 2009 for demonstrating that communities can — and frequently do — manage shared resources sustainably without either privatization or government control.
Ostrom identified eight design principles for long-lasting commons institutions:
These principles map almost perfectly onto the challenges of managing a community network. A network has clearly defined boundaries (who can connect and what infrastructure is shared). It requires proportional contribution (those with more bandwidth or better antenna sites contribute more). It needs collective governance (decisions about routing policies, acceptable use, and investment must be made together). And successful community networks, as we will see in the case studies that follow, embody these principles whether or not their founders have ever heard of Elinor Ostrom.
Community networks organize themselves in several distinct legal and governance structures, each with trade-offs in terms of flexibility, accountability, and sustainability:
Cooperatives are formal organizations owned and governed by their members. Each member typically has one vote regardless of their level of investment or usage. Cooperatives have a long legal tradition in most countries, with established frameworks for incorporation, governance, and financial accountability. Rural electric cooperatives, credit unions, and agricultural cooperatives are well-known examples. A cooperative community network provides democratic governance, legal personhood (the ability to sign contracts, own property, hold bank accounts), and a structure that can survive the departure of any individual founder. The downside is administrative overhead — cooperatives require bylaws, elections, annual meetings, and financial reporting.
Nonprofit organizations (or associations, in European legal terminology) provide legal structure without the requirement of member ownership. A nonprofit community network is governed by a board of directors who are responsible for the organization’s mission but do not own shares. This model is common in larger community networks where the network serves a broader public purpose beyond just its members — for example, providing connectivity to schools, libraries, or public spaces. Nonprofits can more easily accept grants and donations, but they lack the direct democratic accountability of cooperatives.
Informal collectives operate without formal legal structure. A group of neighbors decides to share internet access, pools money for equipment, and operates the network by consensus. This is how most community networks begin — and how many small ones continue to operate indefinitely. The advantages are simplicity and speed: no incorporation fees, no bylaws, no tax filings. The disadvantages are significant: an informal collective cannot sign contracts in its own name, cannot open a bank account, cannot apply for grants, and has no mechanism for resolving disputes beyond personal relationships. When a key volunteer burns out, moves away, or has a falling-out with other members, the network can collapse.
Municipal or public networks are built and operated by local governments — cities, counties, or special districts. While not “community networks” in the grassroots sense, municipal broadband networks share the fundamental principle that connectivity should be a public service rather than a private commodity. Over 500 communities in the United States operate some form of municipal broadband, from small-town fiber networks to city-wide wireless systems. Municipal networks benefit from access to public rights-of-way, bonding authority, and existing staff, but they are subject to political pressures and, in some US states, face legal restrictions lobbied for by incumbent ISPs.
Hybrid models combine elements of the above. A common pattern is an informal collective that incorporates as a nonprofit once it grows beyond a certain size, or a cooperative that partners with a municipality for access to public buildings and utility poles. The Guifi.net model, which we will examine in detail, combines a nonprofit foundation with a commons license that any individual, cooperative, or company can join.
The story of Guifi.net begins in 2004 in the town of Gurb, a small municipality of about 2,500 people in the Osona comarca of Catalonia, Spain. Like many rural areas in southern Europe at the time, Gurb had no broadband internet. The nearest ADSL-enabled telephone exchange was too far away for the signal to reach, and no ISP had plans to invest in infrastructure for such a small market.
Ramon Roca, a local IT professional, decided that if no corporation would bring broadband to Gurb, the community would build it themselves. Drawing on the traditions of Catalan cooperativism — Catalonia has one of the densest cooperative movements in Europe, with roots stretching back to the 19th century — Roca began connecting neighbors using directional Wi-Fi links. The first nodes were commodity routers running open-source firmware, mounted on rooftops with homemade antennas fashioned from tin cans and satellite dishes.
What distinguished Guifi.net from the very beginning was not the technology — Wi-Fi mesh networks existed elsewhere — but the governance model. Roca and the early participants did not build a network that they owned. They built a network that nobody owned — or rather, that everybody owned, under the terms of a commons license inspired by the principles of open-source software.
From those first rooftop antennas in Gurb, Guifi.net grew with remarkable speed. By 2008, it had 6,000 nodes. By 2012, over 20,000. By 2020, it surpassed 40,000 active nodes, making it one of the largest community networks in the world. The network spans most of Catalonia and parts of Valencia, the Balearic Islands, and other regions of Spain, with experimental nodes in other countries.
The growth was not centrally planned. Guifi.net spread virally, community by community, rooftop by rooftop. A typical expansion pattern looked like this: someone in a town without broadband heard about Guifi.net, contacted existing participants, installed a directional link to the nearest node (often kilometers away, using high-gain antennas), and began offering connectivity to neighbors. Each new node extended the network’s reach and created new connection points for still more nodes.
The network’s infrastructure evolved as it grew. The earliest links were 2.4 GHz Wi-Fi using 802.11b — slow by modern standards, but revolutionary for communities that had no connectivity at all. Over time, the backbone upgraded to 5 GHz point-to-point links using devices like Ubiquiti NanoStation and NanoBridge units, capable of carrying hundreds of megabits per second over distances of several kilometers. Fiber optic links were added to the highest-traffic backbone segments. Today, Guifi.net’s infrastructure includes thousands of kilometers of fiber, hundreds of supernodes with backbone connectivity, and a diverse mix of wireless and wired technology.
The most important innovation of Guifi.net is not technical — it is institutional. The network operates under the Comuns Xarxa Oberta (XOLN) — the Network Commons License — a legal framework that defines the terms under which anyone can participate in the network.
The key principles of the commons license are:
This license draws a clear line between the infrastructure (which is commons) and the services running on that infrastructure (which can be commercial, nonprofit, or personal). Anyone can start a small ISP business using Guifi.net’s infrastructure, as long as they contribute to the maintenance and expansion of the commons. This is precisely analogous to how public roads work: anyone can start a delivery business that uses the road network, but no one can claim ownership of the roads themselves.
The Guifi.net Foundation, established in 2008, serves as the legal steward of the commons. It does not own or operate the network — it holds the commons license, mediates disputes, coordinates technical standards, and represents the network in legal and regulatory matters. The Foundation has a small paid staff and a large volunteer community. Its board is elected by the membership.
At a technical level, Guifi.net is organized into a hierarchy of three layers:
The backbone consists of high-capacity point-to-point links — both wireless (using 5 GHz and 60 GHz radios) and fiber optic — connecting major nodes across the region. These links carry aggregated traffic between zones and to the network’s internet gateways. Backbone links are maintained by volunteer “zone managers” or, in some cases, by professional ISPs operating on the Guifi.net commons.
The distribution layer connects backbone nodes to neighborhood-level access points. This layer typically uses 5 GHz point-to-multipoint radios (often Ubiquiti or MikroTik devices) serving clusters of users within a few kilometers of each distribution node.
The access layer is where individual users connect. This can be a directional antenna pointed at a distribution node, a mesh node on a rooftop, or an Ethernet cable from a fiber-connected building. Access layer technology varies enormously — Guifi.net does not mandate specific hardware, only interoperability standards.
IP address allocation is managed through a custom web-based tool that ensures unique addressing across the entire network. Routing uses a combination of BGP (Border Gateway Protocol) for inter-zone routing and OSPF (Open Shortest Path First) within zones, following standard internet routing practices.
import requests
def query_guifi_nodes(zone="gurb", limit=10):
"""Query the Guifi.net public API for node information."""
url = f"https://guifi.net/api/zones/{zone}/nodes"
try:
response = requests.get(url, timeout=10)
response.raise_for_status()
nodes = response.json().get("nodes", [])[:limit]
for node in nodes:
print(f"Node: {node.get('title', 'N/A')} "
f"| Status: {node.get('status', 'N/A')} "
f"| Links: {node.get('links', 0)}")
except requests.RequestException as e:
print(f"API query failed: {e}")
Two decades of Guifi.net have produced hard-won insights applicable to any community network:
The commons license is essential. Without a clear legal framework defining infrastructure as commons, successful community networks tend to evolve into de facto private networks controlled by whoever invested the most or maintained the most nodes. The commons license prevents enclosure — the process by which shared resources are gradually claimed as private property.
Professional services on commons infrastructure work. Guifi.net hosts multiple small ISPs, VoIP providers, and hosting services — all built on commons infrastructure. These businesses contribute to the maintenance of the commons and provide professional-grade services to users who want them, while the commons itself remains free and open. This hybrid model is more sustainable than either pure volunteerism or pure commercialism.
Zone-based governance scales. As the network grew beyond the capacity of any single governance body, Guifi.net adopted a zone-based structure where local communities manage their own section of the network within the framework of the commons license. This is Ostrom’s “nested enterprises” principle in action.
Technology must be politically neutral. Guifi.net deliberately avoids mandating specific hardware or software. Routers from Ubiquiti, MikroTik, TP-Link, and custom hardware all coexist. This prevents vendor lock-in and ensures that the network cannot be disrupted by any single manufacturer’s business decisions.
If Guifi.net demonstrates that community networks can serve rural areas ignored by commercial ISPs, NYC Mesh demonstrates that community networks can thrive in one of the most connected cities on Earth — and that even in Manhattan, there is demand for an alternative to corporate internet.
NYC Mesh was founded in 2013 by a small group of technologists in New York City who believed that internet access should be a public utility, not a product sold by monopolistic ISPs. New York City, despite its density and wealth, has significant connectivity gaps: public housing complexes with poor or no broadband, neighborhoods where the only option is a single overpriced cable provider, and residents who cannot afford the $60-80 per month that commercial ISPs charge for basic service.
NYC Mesh operates on a “pay what you can” model. There are no mandatory monthly fees. Users are asked to contribute a suggested amount — typically $20-60 per month — but the network serves anyone who wants to connect, regardless of their ability to pay. This is not charity; it is a fundamental design principle. The network is a commons, and access to the commons should not be gated by ability to pay.
NYC Mesh is built and maintained almost entirely by volunteers. The organization has minimal paid staff — primarily a small number of part-time coordinators. Everything else — installation, maintenance, network engineering, community outreach, fundraising — is done by volunteers who contribute their time and expertise.
The volunteer model imposes constraints. Installation requests sometimes wait weeks or months in the queue. Equipment purchases depend on donations and grants. Technical expertise is concentrated in a few key volunteers whose departure could create significant knowledge gaps. But the model also provides extraordinary advantages: low overhead means low costs for users, volunteer enthusiasm creates genuine community ownership, and the distributed nature of volunteer work makes the organization extremely resilient to any individual’s departure.
New volunteers go through an onboarding process that includes attending a monthly meetup (held in person and online), participating in installations alongside experienced members, and gradually taking on more responsibility. The community communicates primarily through Slack and GitHub, with technical documentation maintained on a wiki.
The technical backbone of NYC Mesh is its supernode architecture. Supernodes are high-capacity installations on tall buildings — apartment towers, commercial buildings, churches — equipped with sector antennas, point-to-point backbone links, and enterprise-grade networking equipment. A single supernode can serve hundreds of users within its radio coverage area.
As of the mid-2020s, NYC Mesh operates several supernodes, each serving a distinct geographic area:
The network uses a combination of Ubiquiti sector antennas for wide-area coverage, MikroTik routers for routing, and Ubiquiti LiteBeam or NanoBeam devices for point-to-point links between hubs and supernodes. Individual users connect via a directional antenna on their rooftop or window, pointed at the nearest hub or supernode.
Routing is handled by OSPF within the mesh and BGP for external connectivity. The network has its own Autonomous System Number (ASN) — AS395853 — which allows it to peer directly with upstream providers and at internet exchange points, just like a commercial ISP.
def estimate_supernode_coverage(height_m, frequency_ghz=5.0):
"""Estimate line-of-sight coverage radius for a supernode.
Uses simplified radio horizon formula accounting for
Earth curvature and typical urban clutter loss.
"""
import math
# Radio horizon in km (with 4/3 Earth radius refraction)
horizon_km = 4.12 * math.sqrt(height_m)
# Urban clutter reduces effective range significantly
urban_factor = 0.3 # ~30% of theoretical in dense urban
effective_range_km = horizon_km * urban_factor
print(f"Antenna height: {height_m}m")
print(f"Theoretical horizon: {horizon_km:.1f} km")
print(f"Effective urban range: {effective_range_km:.1f} km")
return effective_range_km
estimate_supernode_coverage(height_m=50)
NYC Mesh does not exist in isolation from the commercial internet — nor does it try to. The network’s primary value proposition for most users is internet access, and that access ultimately comes from commercial upstream providers. What NYC Mesh provides is community ownership of the last mile — the connection between the user’s home and the internet backbone.
This last-mile ownership has real consequences. NYC Mesh users are not subject to individual ISP contracts, data caps, or price increases. The network pays for upstream bandwidth in bulk and distributes it to users at cost. When a user has a problem, they contact a fellow community member, not a call center in another time zone. And when the network needs to change its upstream provider — as it has done multiple times — it can do so without affecting any individual user.
NYC Mesh also maintains peering relationships at internet exchange points, which means some traffic between NYC Mesh users and major content networks travels a very short path — often shorter than the path it would take through a commercial ISP. This can actually result in better performance for some services than the commercial alternatives.
NYC Mesh’s greatest strength — its volunteer model — is also its greatest vulnerability. The network faces ongoing challenges:
Key person dependency. A small number of highly skilled volunteers handle the most complex network engineering tasks. If these individuals burn out or move on, replacing their expertise is difficult.
Funding. Without mandatory membership fees, revenue is unpredictable. NYC Mesh relies on a combination of voluntary contributions, grants, and donations. This works, but it does not provide the financial stability needed for long-term capital investments like fiber optic buildouts.
Scale. As the network grows, the volunteer model strains. More nodes mean more maintenance, more support requests, and more coordination overhead. At some point, some functions may need to transition from volunteer to paid staff — but this requires sustainable revenue.
These are not hypothetical concerns — they are the active, daily reality of running a community network in one of the world’s most expensive cities.
Freifunk (literally “free radio” in German) is not a single network but a movement — a loose federation of over 400 local community wireless networks across Germany, Austria, and Switzerland. Each Freifunk community is independent, operating its own network in its own city or region, but all share a common philosophy, common software tools, and a common legal and organizational framework.
The Freifunk movement emerged in the early 2000s, inspired by the first generation of community wireless networks in the United States (such as Seattle Wireless and NYCwireless) and by the broader free software movement. The first Freifunk networks appeared in Berlin in 2003, and the movement spread rapidly across German-speaking countries.
What makes Freifunk distinctive is its radical commitment to decentralization. There is no central Freifunk organization. Each city’s Freifunk group is autonomous — setting its own policies, choosing its own technology, managing its own infrastructure, and making its own decisions. What holds the movement together is not institutional authority but shared values, shared software, and the Pico Peering Agreement.
The Pico Peering Agreement (PPA) is a remarkably elegant document — barely a page long — that defines the terms under which Freifunk nodes interconnect. It is the social contract of the Freifunk movement, and it is designed to be as minimal as possible while still enabling cooperation between autonomous networks.
The core terms of the PPA are:
The PPA is intentionally minimal. It does not address commercial use, content filtering, privacy, or any of the complex issues that larger governance frameworks tackle. This minimalism is by design — it keeps the barrier to participation as low as possible and avoids the endless debates over governance that have paralyzed other community networking efforts.
The technical glue of the Freifunk movement is Gluon — a modular firmware framework based on OpenWrt that any Freifunk community can customize for its own network. Gluon handles the complex task of turning a commodity router into a mesh node with minimal user configuration.
A typical Gluon-based Freifunk node operates in two modes simultaneously:
The user who sets up a Freifunk node needs to do almost nothing: flash the Gluon firmware, connect the router to their existing internet connection, and place it somewhere with reasonable Wi-Fi coverage. The firmware automatically discovers other Freifunk nodes in range, establishes mesh links, and begins routing traffic. Internet-connected nodes share their bandwidth with the mesh, providing internet access to any user connected to any node in the mesh.
Gluon is maintained as an open-source project with contributions from Freifunk communities across Germany. Each community maintains its own “site configuration” — a set of parameters that customizes Gluon for their specific network (SSID, IP ranges, VPN server addresses, etc.). This model ensures that all Freifunk communities benefit from shared development effort while maintaining local autonomy.
import json
def generate_gluon_site_config(community_name, city,
ip_prefix="10.42.0.0/16"):
"""Generate a basic Gluon site configuration for Freifunk."""
config = {
"community_name": community_name,
"city": city,
"ssid": f"freifunk-{city.lower()}",
"mesh_ssid": f"mesh-{city.lower()}",
"prefix4": ip_prefix,
"dns_servers": ["10.42.0.1"],
"mesh_protocol": "batman-adv",
"autoupdater_branch": "stable",
}
print(json.dumps(config, indent=2))
return config
generate_gluon_site_config("Freifunk Berlin", "Berlin")
Freifunk’s development in Germany was heavily influenced by a peculiar feature of German law: Störerhaftung (disturber liability). Under this legal doctrine, the operator of a Wi-Fi network could be held liable for illegal activity conducted by users on that network — even if the operator had no knowledge of or involvement in the activity. This was the legal equivalent of holding a road builder liable for a bank robber’s getaway.
Störerhaftung posed an existential threat to open wireless networks. If you opened your Wi-Fi to the public and someone used it to download copyrighted material, you — not the downloader — could receive a legal demand for damages. This chilled the entire community wireless movement in Germany for years.
Freifunk communities developed two strategies to work around this problem. The technical strategy was VPN tunneling: all traffic from Freifunk nodes was routed through VPN tunnels to servers operated by Freifunk-supporting organizations (notably Förderverein Freie Netzwerke e.V.), which assumed legal liability for the traffic. This added latency and complexity but provided legal protection to individual node operators.
The political strategy was advocacy. Freifunk communities lobbied persistently for legal reform, and in 2017, Germany finally amended its Telemedia Act to largely eliminate Störerhaftung for open Wi-Fi operators. This was a landmark victory — not just for Freifunk, but for the entire community networking movement in Germany. It demonstrated that community networks can change law, not just technology.
Sarantaporo.gr is a community network serving a cluster of 15 small villages in the rural Sarantaporo valley of Thessaly, Greece — an area of steep mountains, scattered settlements, and minimal commercial telecommunications infrastructure. Founded in 2010, the network connects communities where DSL was unavailable and cellular coverage was marginal.
The network uses a hub-and-spoke architecture with long-distance point-to-point wireless links connecting hilltop relay stations to village access points. A single backhaul connection to the commercial internet at a nearby town serves the entire valley. The project was built with grant funding, volunteer labor, and donated equipment, and it has been recognized by the European Commission as a model for rural digital inclusion.
Sarantaporo.gr’s significance lies in demonstrating that community networks can serve the most marginalized communities — elderly, rural populations with limited technical literacy — not just urban technologists. The project invests heavily in digital literacy training alongside network deployment, recognizing that connectivity without capability is insufficient.
Zenzeleni Networks (“do it yourself” in isiXhosa) operates in the rural Eastern Cape province of South Africa, one of the most economically disadvantaged regions in the country. Founded in 2012 as a research project at the University of the Western Cape, Zenzeleni has evolved into a community-owned cooperative providing affordable voice and data services to communities where commercial coverage is nonexistent or unaffordable.
Zenzeleni is notable for several innovations:
Zenzeleni demonstrates that the community network model is not limited to the Global North. With appropriate support — academic partnerships, regulatory accommodation, and initial funding — communities in the most underserved regions of the world can build and sustain their own telecommunications infrastructure.
Rhizomatica and its offspring Telecomunicaciones Indígenas Comunitarias (TIC) represent perhaps the most radical community network model in the world: indigenous communities in the mountains of Oaxaca, Mexico, building and operating their own cellular telephone networks.
Founded in 2009, Rhizomatica worked with indigenous Mixtec and Zapotec communities to deploy community-owned GSM cellular networks using open-source base station software (initially OpenBTS, later Osmocom). Each community operates its own cell tower, running on solar power, providing voice calls and SMS to hundreds of users. Calls within the community network are free; calls to external networks are routed through VoIP at minimal cost.
In 2014, the Mexican telecommunications regulator IFT granted an experimental spectrum license to TIC, making it the first indigenous-operated cellular network with official spectrum authorization in the Americas. By 2020, TIC was serving over 70 communities across Oaxaca and had become a model for community cellular networks worldwide.
Rhizomatica’s work challenges the most fundamental assumption of the telecommunications industry: that building and operating a cellular network requires millions of dollars in capital, hundreds of engineers, and a government-granted spectrum license designed for multinational corporations. In practice, a community can operate a cellular network for a few thousand dollars in equipment, a handful of trained local operators, and — if the regulatory framework permits — a community spectrum license.
AlterMundi operates in the rural Córdoba province of Argentina, building community networks in small towns and villages that lack commercial internet infrastructure. Founded in 2012, AlterMundi has developed its own mesh networking firmware called LibreRouter, designed specifically for the needs of community networks in the Global South.
The LibreRouter project — which includes both custom hardware and firmware — addresses a gap that AlterMundi identified through years of field experience: existing consumer routers were not designed for outdoor mesh networking in challenging environments. They overheat, their antennas are inadequate for long-range links, their firmware is difficult for non-technical users to configure, and they are not designed to be powered by solar panels or car batteries.
The LibreRouter is an open-source hardware design — a weatherproof, dual-band router with high-gain antennas, designed to be mounted outdoors and powered by 12V DC. The accompanying firmware, LibreMesh, provides zero-configuration mesh networking using a combination of BATMAN-adv (for Layer 2 mesh) and Babel (for Layer 3 routing). A non-technical user can set up a LibreRouter node by simply connecting power and pointing the antenna — no SSH, no command line, no network engineering knowledge required.
AlterMundi’s contribution to the community networking movement extends beyond technology. The organization has developed community organizing methodologies, training curricula, and governance models specifically adapted for rural Latin American communities, and it actively supports the creation of new community networks across the continent.
Before purchasing a single piece of equipment, you need to understand what problem you are solving and for whom. Community networks fail most often not because of technical issues but because of a mismatch between what the network provides and what the community actually needs.
Start by answering these questions:
What connectivity exists today? Survey the available options — commercial ISPs, cellular data, satellite. Understand not just availability but affordability and reliability. A community where everyone has $50/month broadband but it goes down frequently has different needs than a community with no connectivity at all.
What does the community actually want? Internet access is the most common answer, but it is not the only one. Some communities need local communication (intra-village voice and messaging), some need access to specific services (telemedicine, online education, government services), and some need resilient backup connectivity for emergencies. The answer shapes the technology choice.
What is the geography? Line-of-sight between nodes is the single most important factor for wireless community networks. Flat terrain with tall buildings is ideal; hilly, forested terrain is challenging. Survey the area with a combination of physical observation and digital elevation tools.
What local resources exist? Identify potential antenna sites (tall buildings, water towers, church steeples, grain silos), potential volunteers with technical skills, existing organizations (churches, schools, community centers) that could host equipment, and any local government officials who might support or oppose the project.
def assess_community_network_feasibility(
population, area_sq_km, existing_isp_count,
avg_monthly_cost, max_building_height_m,
volunteer_count):
"""Quick feasibility assessment for a community network."""
density = population / area_sq_km
score = 0
factors = []
if existing_isp_count <= 1:
score += 3
factors.append("Limited ISP competition (strong motivation)")
if avg_monthly_cost > 50:
score += 2
factors.append("High current costs (cost savings appeal)")
if max_building_height_m > 15:
score += 2
factors.append("Tall structures available (good antenna sites)")
if volunteer_count >= 3:
score += 2
factors.append("Volunteer base exists")
if density > 100:
score += 1
factors.append("Sufficient population density")
print(f"Feasibility score: {score}/10")
for f in factors:
print(f" ✓ {f}")
return score
Every community network begins with a small group of enthusiasts — rarely more than 5-10 people — who are willing to invest time, money, and rooftop access in an unproven project. Finding these early adopters is the most critical step in starting a community network.
Look for people who have:
The most effective recruitment channels are local: community meetings, neighborhood email lists, social media groups, bulletin boards at libraries and coffee shops. Present the project not as a technical experiment but as a community service — “we are building our own internet” is more compelling than “we are deploying a BATMAN-adv mesh network with BGP peering.”
Start small. The first installation should connect just two or three locations. The goal is to demonstrate that the technology works, build confidence, and create a visible proof of concept that attracts more participants. A working two-node link that provides internet access to a neighbor is worth more than a perfect 50-page network design document.
The technology choice depends on the deployment environment, the community’s technical capacity, and the scale of the planned network:
| Scenario | Recommended Technology | Why |
|---|---|---|
| Small neighborhood (< 20 nodes) | Mesh with BATMAN-adv (LibreMesh/Gluon) | Simple, self-configuring, low cost |
| Rural area with sparse population | Point-to-point links (Ubiquiti/MikroTik) | Long range, reliable, proven |
| Urban area with tall buildings | Supernode + sector antennas | High capacity, wide coverage |
| Off-grid / no internet available | LoRa mesh (Meshtastic) | No infrastructure needed, solar powered |
| Large network (100+ nodes) | Hybrid: PtP backbone + mesh access | Scalable, manageable, performant |
Do not over-engineer the initial deployment. The community network that starts with two Ubiquiti NanoStation devices on neighboring rooftops and actually provides service is infinitely more valuable than the one that spends a year designing the perfect architecture and never launches.
Before deploying any wireless equipment, understand the legal environment:
Spectrum regulations. In most countries, operating Wi-Fi equipment in the 2.4 GHz and 5 GHz ISM bands does not require a license, but there are limits on transmit power, antenna gain, and channel usage. Point-to-point links using higher-powered equipment may require registration or licensing. In the US, Part 15 of the FCC rules governs unlicensed operation; in Europe, the relevant framework is the Radio Equipment Directive.
Liability. If your network provides internet access, you may be considered an ISP under local law, with attendant obligations for data retention, lawful intercept, content filtering, or disability access. In some jurisdictions, operating an open Wi-Fi network creates liability for user actions (as Germany experienced with Störerhaftung). Consult a lawyer before launching — the cost of legal advice is far less than the cost of a lawsuit.
Incorporation. For anything beyond a small informal network, forming a legal entity — cooperative, nonprofit, or association — is strongly recommended. Legal personhood allows the network to sign contracts, hold bank accounts, apply for grants, purchase insurance, and shield individual members from personal liability.
Building permits and access. Mounting antennas on rooftops may require building permits, landlord permission, or compliance with homeowner association rules. Access to public buildings, utility poles, and rights-of-way may require agreements with municipal authorities.
Community networks need money — for equipment, for internet backhaul, for insurance, and eventually for paid staff. The funding landscape includes:
Self-funding. The earliest installations are almost always paid for by the founders themselves. A pair of Ubiquiti NanoStations and some Ethernet cable costs under $200 — well within the budget of most hobbyists.
Membership fees. Once the network serves enough users, regular contributions from members can cover ongoing costs. NYC Mesh’s “pay what you can” model generates significant revenue despite being voluntary. Fixed monthly fees provide more predictable revenue but may exclude community members who cannot afford them.
Grants. Government agencies, foundations, and international organizations fund community broadband projects. In the US, the USDA’s ReConnect Program, the FCC’s Emergency Connectivity Fund, and state broadband offices all provide funding. In Europe, the EU’s Connecting Europe Facility and national broadband programs fund rural connectivity projects. In the Global South, organizations like the Internet Society and the Association for Progressive Communications fund community network projects.
In-kind contributions. Community members may contribute rooftop access, equipment, electricity, or professional services (legal, accounting, web design) in lieu of cash. These contributions are real and should be tracked — they demonstrate community support to potential funders and establish a culture of shared responsibility.
Most successful community networks, regardless of their specific technology choices, converge on a three-layer architecture that mirrors the structure of commercial ISPs but at community scale:
Backbone layer. High-capacity links connecting major nodes across the network. These are typically point-to-point wireless links (using Ubiquiti airFiber, MikroTik, or similar equipment) or fiber optic connections. Backbone links carry aggregated traffic and provide redundant paths between network regions. A well-designed backbone can carry gigabits per second over distances of several kilometers.
Distribution layer. Mid-capacity links connecting backbone nodes to neighborhood access points. This layer uses point-to-multipoint radios (sector antennas serving multiple client devices) or short-range point-to-point links. The distribution layer is where bandwidth is shared among groups of users and where traffic shaping and quality-of-service policies are typically applied.
Access layer. The connections between individual users and the distribution layer. This can be a directional antenna on a user’s rooftop, a mesh node on a window sill, an Ethernet cable from a fiber-connected building, or an open Wi-Fi access point. The access layer is the most diverse and the most challenging to manage, because it involves equipment installed in homes and on rooftops of varying quality and accessibility.
Every community network that provides internet access needs one or more gateways — points where traffic exits the community network and enters the commercial internet. Gateway management is one of the most critical and complex aspects of community network operation.
Options for internet gateway connectivity include:
Bandwidth at the gateway is the scarcest and most expensive resource in most community networks. Effective gateway management includes:
import time
from collections import defaultdict
class BandwidthManager:
"""Simple per-user bandwidth tracking for a community gateway."""
def __init__(self, total_bandwidth_mbps, fair_share_pct=5):
self.total = total_bandwidth_mbps
self.fair_share = total_bandwidth_mbps * (fair_share_pct / 100)
self.usage = defaultdict(float)
def record_usage(self, user_id, megabytes):
self.usage[user_id] += megabytes
def get_allocation(self, user_id):
"""Return current bandwidth allocation in Mbps."""
active_users = len(self.usage) or 1
equal_share = self.total / active_users
return min(equal_share, self.fair_share)
def report(self):
print(f"Total bandwidth: {self.total} Mbps")
print(f"Active users: {len(self.usage)}")
for uid, used in sorted(self.usage.items()):
alloc = self.get_allocation(uid)
print(f" User {uid}: {used:.1f} MB used, "
f"{alloc:.1f} Mbps allocated")
bw = BandwidthManager(total_bandwidth_mbps=100)
bw.record_usage("alice", 450)
bw.record_usage("bob", 120)
bw.record_usage("carol", 800)
bw.report()
A community network needs a coherent IP addressing scheme that avoids conflicts, supports growth, and enables routing. The standard approach uses private IP address space (RFC 1918) internally, with NAT at the internet gateway:
For networks that want to participate in the global routing table — as NYC Mesh does — obtaining provider-independent (PI) IP addresses from a Regional Internet Registry (RIPE, ARIN, AFRINIC, etc.) and an Autonomous System Number (ASN) enables BGP peering and direct interconnection with the commercial internet.
import ipaddress
def plan_community_ip_space(base="10.0.0.0/8", zones=5,
subnets_per_zone=10):
"""Generate an IP addressing plan for a community network."""
network = ipaddress.ip_network(base)
# Allocate /16 per zone, /24 per subnet within zone
print(f"Base network: {network}")
print(f"Total addresses: {network.num_addresses:,}\n")
for zone in range(1, zones + 1):
zone_net = ipaddress.ip_network(f"10.{zone}.0.0/16")
print(f"Zone {zone}: {zone_net}")
for subnet in range(subnets_per_zone):
sub = ipaddress.ip_network(
f"10.{zone}.{subnet}.0/24")
print(f" Subnet {subnet}: {sub} "
f"({sub.num_addresses - 2} usable hosts)")
print()
plan_community_ip_space(zones=3, subnets_per_zone=3)
Without bandwidth management, a small number of heavy users can consume a disproportionate share of the gateway bandwidth, degrading service for everyone else. Community networks address this through a combination of technical and social mechanisms:
Traffic shaping uses queuing disciplines (tc/HTB on Linux, queues on MikroTik) to limit per-user or per-device bandwidth. A common approach is to guarantee each user a minimum bandwidth (e.g., 5 Mbps) and allow bursting above that when the network is lightly loaded.
Fair queuing algorithms like fq_codel or CAKE (Common Applications Kept Enhanced) distribute bandwidth fairly among active flows, preventing any single connection from starving others. These algorithms are especially effective in community networks because they require no per-user configuration — they operate automatically at each router.
Acceptable use policies define social norms around bandwidth usage. These are typically informal — “don’t run a torrent 24/7” — but they can be formalized in a network agreement that participants sign when joining.
Transparent monitoring lets all participants see network utilization, helping to create social accountability. When everyone can see that the network is congested and one user is consuming 60% of the bandwidth, peer pressure often resolves the problem without administrative intervention.
The most common cause of community network failure is not technical — it is organizational. A network built by enthusiastic volunteers can provide excellent service for months or even years, but eventually, equipment fails and needs replacement, volunteers burn out and are not replaced, and the network slowly degrades until it stops working.
Sustainability requires addressing three fundamental needs: money (for equipment, bandwidth, and eventually staff), people (volunteers or employees with the skills to maintain the network), and governance (a structure that survives the departure of any individual).
Donation-based. Members contribute whatever they choose, whenever they choose. This is the simplest model and works well for small networks where all participants know each other and social trust is high. The downside is unpredictable revenue — a network that depends on the goodwill of a few generous members is fragile.
Membership or subscription. Members pay a fixed monthly fee — typically $10-50, depending on the local cost of living and the service provided. This provides predictable revenue and a clear value exchange: you pay, you get internet. The downside is that fixed fees can exclude community members who cannot afford them, undermining the network’s mission of universal access.
Tiered service. Different service levels at different prices — for example, a basic tier at $10/month and a premium tier with higher bandwidth or priority support at $30/month. This model captures revenue from users willing to pay more without excluding those who cannot. Guifi.net’s model, where commercial ISPs can offer premium services on commons infrastructure, is a form of tiered service.
Grants and public funding. Government agencies, foundations, and international organizations provide grants for community broadband projects. Grant funding is excellent for capital expenditure (equipment, installation, initial setup) but rarely covers ongoing operational costs. A network that depends entirely on grants is on a treadmill — always chasing the next funding cycle, always at risk of collapse when the grant ends.
Hybrid models. The most sustainable community networks combine multiple revenue streams. A typical hybrid model might include modest membership fees for ongoing operations, grants for capital investment, voluntary donations for community access programs, and revenue from commercial services offered on the commons infrastructure.
Volunteers are the lifeblood of most community networks, but managing volunteers is fundamentally different from managing employees. Volunteers cannot be directed — they must be motivated. They cannot be fired — they can only leave. Their commitment fluctuates with their personal lives, their enthusiasm, and their perception that their contributions are valued.
Effective volunteer management in community networks includes:
Community wireless networks operate primarily in unlicensed spectrum — the 2.4 GHz and 5 GHz ISM (Industrial, Scientific, and Medical) bands where Wi-Fi operates. In most countries, anyone can deploy equipment in these bands without a license, subject to power and technical restrictions.
Key regulatory considerations:
Transmit power limits. Most jurisdictions limit effective isotropic radiated power (EIRP) in unlicensed bands. In the US, Part 15 rules allow up to 36 dBm (4 watts) EIRP in the 5 GHz band for point-to-point links — enough for links of several kilometers with directional antennas. In the EU, limits are generally lower (20-30 dBm depending on band and channel).
DFS (Dynamic Frequency Selection). In the 5 GHz band, many channels require DFS — a radar detection mechanism that forces the radio to vacate the channel if radar signals are detected. DFS channels are less crowded but can cause occasional disruptions. Community networks often use DFS channels for backbone links (where brief disruptions are acceptable) and non-DFS channels for user access.
The 6 GHz band (Wi-Fi 6E/7). Starting in 2020, regulators began opening the 6 GHz band for unlicensed use, providing over 1 GHz of new spectrum. This is a major opportunity for community networks — more spectrum means more capacity and less interference. However, 6 GHz equipment is still relatively expensive and its shorter range (compared to 5 GHz) limits its usefulness for long-distance links.
Licensed and lightly licensed spectrum. Some community networks have obtained licensed spectrum — Zenzeleni in South Africa being a notable example. In the US, the CBRS (Citizens Broadband Radio Service) band at 3.5 GHz offers a “lightly licensed” model where users can access spectrum through an automated system without traditional licensing. CBRS is increasingly interesting for community networks that need dedicated, interference-free spectrum.
In the United States, a significant legal barrier to community networks is the existence of state laws restricting municipal broadband. As of the mid-2020s, approximately 18 states have laws that limit or prohibit local governments from building or operating broadband networks. These laws were lobbied for by incumbent ISPs — primarily Comcast, AT&T, and Charter — to prevent competition from publicly owned networks.
These laws vary in severity:
Community networks organized as cooperatives or nonprofits are generally not affected by municipal broadband restrictions, since they are private organizations. However, the broader regulatory environment — including the attitude of state and local officials toward community infrastructure — affects the ease with which any community network can operate.
Community networks face an interesting relationship with net neutrality — the principle that all internet traffic should be treated equally. Most community networks enthusiastically embrace net neutrality as a philosophical matter: the network should carry all traffic without discrimination, just as roads carry all vehicles without asking where they are going.
In practice, however, community networks with limited bandwidth sometimes need to apply traffic management to ensure fair access. Prioritizing real-time traffic (video calls, VoIP) over bulk downloads, or limiting per-user bandwidth to prevent a single user from consuming the entire gateway — these are forms of traffic management that might technically violate a strict interpretation of net neutrality.
The resolution is transparency. Community networks that openly communicate their traffic management policies, apply them equally to all users, and make decisions collectively through their governance structures are fundamentally different from commercial ISPs that selectively degrade specific services to extract payment. The intent is equitable resource management, not commercial advantage.
When you operate a network that carries traffic for other people, you assume some degree of legal responsibility. The specifics depend on your jurisdiction, but common concerns include:
Safe harbor protections. In the US, Section 230 of the Communications Decency Act and the DMCA safe harbor provisions protect intermediaries (including ISPs) from liability for user-generated content, provided they meet certain conditions. Community networks should understand these protections and comply with their requirements — primarily, responding to valid takedown notices for copyright-infringing content.
Data retention. Some jurisdictions require ISPs to retain logs of user activity for a specified period. Whether a community network qualifies as an “ISP” under these laws depends on the jurisdiction and the network’s structure. In many cases, small community networks fall below the thresholds that trigger data retention obligations.
Law enforcement requests. Community networks may receive requests from law enforcement for information about users or traffic. Having a clear policy — drafted with legal counsel — for handling such requests is essential. The policy should specify who is authorized to respond, what information can be provided without a warrant, and how users will be notified.
As a community network grows beyond a handful of nodes, monitoring becomes essential. You need to know which nodes are up, which links are degraded, what the bandwidth utilization is across the network, and where problems are developing before users complain.
LibreNMS is the monitoring tool of choice for many community networks. It is an open-source, PHP-based network monitoring system that auto-discovers network devices via SNMP, tracks interface utilization, logs alerts, and provides a web-based dashboard. LibreNMS supports the full range of equipment found in community networks — Ubiquiti, MikroTik, Linux servers, and standard SNMP-enabled devices.
Zabbix is a more enterprise-oriented alternative with powerful alerting, templating, and data visualization capabilities. It is more complex to configure than LibreNMS but scales to very large networks and supports agent-based monitoring (where a small agent runs on each monitored device) in addition to SNMP.
Prometheus + Grafana is the modern cloud-native monitoring stack. Prometheus scrapes metrics from endpoints, stores them in a time-series database, and Grafana provides beautiful, customizable dashboards. This stack is popular with more technically sophisticated community networks and integrates well with custom monitoring scripts.
import subprocess
import json
from datetime import datetime
def check_node_status(nodes):
"""Check reachability of community network nodes via ping."""
results = []
for node in nodes:
name, ip = node["name"], node["ip"]
try:
output = subprocess.run(
["ping", "-c", "3", "-W", "2", ip],
capture_output=True, text=True, timeout=10)
up = output.returncode == 0
# Parse average RTT from ping output
rtt = None
if up:
for line in output.stdout.splitlines():
if "avg" in line:
rtt = float(line.split("/")[4])
results.append({"name": name, "ip": ip,
"up": up, "rtt_ms": rtt})
except (subprocess.TimeoutExpired, Exception) as e:
results.append({"name": name, "ip": ip,
"up": False, "rtt_ms": None})
print(f"Node Status Report — {datetime.now():%Y-%m-%d %H:%M}")
print("-" * 50)
for r in results:
status = "✓ UP" if r["up"] else "✗ DOWN"
rtt = f"{r['rtt_ms']:.1f}ms" if r["rtt_ms"] else "N/A"
print(f" {r['name']:20s} {r['ip']:15s} {status} {rtt}")
return results
nodes = [
{"name": "Gateway-Main", "ip": "10.0.0.1"},
{"name": "Supernode-North", "ip": "10.1.0.1"},
{"name": "Hub-Library", "ip": "10.2.1.1"},
]
check_node_status(nodes)
Community networks that provide open access — like most Freifunk networks — do not need user management. Anyone within range connects to the open SSID and is on the network. But networks that need to track membership, manage access, or display acceptable-use agreements need some form of user management.
Captive portals redirect new users to a web page where they can accept terms of use, register, or authenticate before being granted network access. Common captive portal solutions for community networks include:
For networks with paid membership, a RADIUS server (FreeRADIUS is the standard open-source implementation) provides centralized authentication and bandwidth accounting. Users authenticate with a username and password, and the RADIUS server tracks their usage and enforces bandwidth limits.
Knowing how much bandwidth each user or node consumes is essential for both technical management (identifying congestion points) and financial fairness (ensuring heavy users contribute proportionally).
SNMP polling from LibreNMS or Zabbix provides interface-level counters — total bytes in and out on each router port. This tells you how much traffic each link carries but not which users are responsible.
NetFlow/sFlow/IPFIX provides flow-level data — source IP, destination IP, port, protocol, and byte count for every flow through a router. MikroTik routers support traffic flow export; Linux routers can use softflowd or pmacctd to generate flow records. A flow collector like nfsen or Elasticsearch stores and visualizes the data.
Per-user accounting with RADIUS tracks each authenticated user’s bandwidth consumption. For networks using captive portals or WPA-Enterprise, this is the most straightforward approach.
import csv
from collections import defaultdict
from datetime import datetime
def generate_bandwidth_report(log_file, top_n=10):
"""Parse a simple bandwidth log and generate usage report.
Expected CSV format: timestamp,user_id,bytes_down,bytes_up
"""
usage = defaultdict(lambda: {"down": 0, "up": 0})
try:
with open(log_file) as f:
reader = csv.DictReader(f)
for row in reader:
uid = row["user_id"]
usage[uid]["down"] += int(row["bytes_down"])
usage[uid]["up"] += int(row["bytes_up"])
except FileNotFoundError:
print(f"Log file {log_file} not found — using sample data")
# Sample data for demonstration
sample = {"alice": (5_200_000_000, 320_000_000),
"bob": (1_800_000_000, 95_000_000),
"carol": (12_400_000_000, 2_100_000_000)}
for uid, (d, u) in sample.items():
usage[uid] = {"down": d, "up": u}
sorted_users = sorted(usage.items(),
key=lambda x: x[1]["down"], reverse=True)
print(f"Bandwidth Report — {datetime.now():%Y-%m-%d}")
print(f"{'User':15s} {'Download':>12s} {'Upload':>12s}")
print("-" * 42)
for uid, data in sorted_users[:top_n]:
down_gb = data["down"] / 1e9
up_gb = data["up"] / 1e9
print(f"{uid:15s} {down_gb:10.2f} GB {up_gb:10.2f} GB")
generate_bandwidth_report("bandwidth_log.csv")
As a community network grows, manual configuration becomes unsustainable. Python scripts can automate many routine tasks:
Automated node provisioning — when a new node is added to the network, a script can generate its configuration (IP address, routing settings, SSID, VPN credentials), push the configuration to the device, and register it in the monitoring system.
Health check scripts — periodic scripts that ping all nodes, check link quality metrics, verify routing tables, and alert administrators when problems are detected.
Certificate management — community networks using WPA-Enterprise or HTTPS need SSL/TLS certificates. Python scripts using the certbot library can automate Let’s Encrypt certificate issuance and renewal.
Inventory management — tracking which equipment is deployed where, who installed it, when, and what firmware version it runs. A simple SQLite database and a Python script to query and update it can replace a messy spreadsheet.
import sqlite3
from datetime import datetime
def init_inventory_db(db_path="network_inventory.db"):
"""Initialize a simple network equipment inventory."""
conn = sqlite3.connect(db_path)
conn.execute("""
CREATE TABLE IF NOT EXISTS nodes (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL,
ip_address TEXT,
mac_address TEXT,
model TEXT,
firmware TEXT,
location TEXT,
installed_date TEXT,
installed_by TEXT,
status TEXT DEFAULT 'active'
)""")
conn.commit()
return conn
def add_node(conn, name, ip, mac, model, location, installer):
conn.execute(
"INSERT INTO nodes (name, ip_address, mac_address, "
"model, location, installed_date, installed_by) "
"VALUES (?, ?, ?, ?, ?, ?, ?)",
(name, ip, mac, model, location,
datetime.now().isoformat(), installer))
conn.commit()
print(f"Added node: {name} ({ip}) at {location}")
conn = init_inventory_db(":memory:")
add_node(conn, "Hub-Library", "10.2.1.1", "AA:BB:CC:DD:EE:01",
"MikroTik hAP ac3", "Public Library rooftop", "Alice")
add_node(conn, "Node-School", "10.2.2.1", "AA:BB:CC:DD:EE:02",
"Ubiquiti NanoStation 5AC", "School building", "Bob")
Community networks are not a technology — they are a social practice that uses technology. The hardware and software are the easy part. The hard part is organizing people, sustaining volunteer energy, navigating legal complexity, managing shared resources fairly, and building institutions that outlast any individual’s enthusiasm.
The case studies in this chapter tell a consistent story. Guifi.net succeeded because it created a commons license that prevented enclosure and enabled commercial activity on shared infrastructure. NYC Mesh succeeded because it lowered the barrier to participation as far as possible — no mandatory fees, no technical prerequisites, just “pay what you can and show up.” Freifunk succeeded because it embraced radical decentralization, giving each city full autonomy within a shared philosophical and technical framework. Rhizomatica succeeded because it treated spectrum as a community resource and proved that indigenous communities could operate their own cellular networks.
These networks differ in almost every detail — geography, technology, governance, scale, funding — but they share the same foundational insight: communication infrastructure is too important to leave to the market alone. When communities take ownership of their connectivity, they gain not just internet access, but agency — the power to shape their own digital future.
The key takeaways for building your own community network:
In the next chapter, we will dive deep into the routing protocols that make these networks function — the algorithms that decide how data finds its way across a community mesh from source to destination, adapting in real time to the ever-changing topology of a network built by volunteers on rooftops.
| ← Previous: LoRa and LPWAN Networks | Table of Contents | Next: Routing Protocols for Alternative Networks → |