NYC Mesh: Ethnography of an Alternative Infrastructure
The roots of this project come from my time working as a software engineer. I always found it bizarre how a few lines of code and a few pushes of a button from my apartment in San Francisco could affect real, concrete processes across the country. I suppose this is a big reason why people are drawn to software development in the first place, but I wasn’t able to intuitively grasp the connection. Technically, I had an idea of what was happening, but it felt ghostly. I learned recently the word would be “dematerialized”. I became more interested in how the internet actually worked embedded in the real world, in structures around us, instead of in the air, cloud or wherever the internet lives in people’s imagination. I took a class with the School of Poetic Computation in New York titled “Solidarity Infrastructures.” One of the objectives of the class was to make the internet visible by highlighting the infrastructure required to connect someone’s home to the internet.
The class traced the skeleton of global internet connectivity; the undersea cable network, built over colonial telegraph networks, their entry into major cities in heavily guarded facilities, and the optic fiber that goes into everyone’s home monopolized by ISPs. One thing that became increasingly clear was that access to the internet, which is now an essential part of day to day life (and recognized as a human right), is, in many countries, subject to monopoly conditions with only 2-3 options on a national level. In the United States for example, a third of Americans only have access to one or no internet provider. ISP consolidation is also increasing with national players like Verizon and Spectrum buying local ISPs (Ali). This has many possible knock on effects. If you live in an area with only a couple of options, you’re completely at the whim of these ISPs, if they decide they don’t service your area, or the speeds are horrible or the repair workers don’t show up, you’re out of luck. With net neutrality struck down, your traffic is also at the whim of these ISPs, if, based on deals of their own, they decide your traffic to certain websites will be throttled or boosted, that is out of your control as well. Most importantly, it is possible for ISPs to block people off from the internet, both using their device’s IP addresses as well as more sophisticated methods. This is not common practice in the United States yet, but is not inconceivable to see a time where it might become widespread.
This is the backdrop against which I became interested in the NYC Mesh Network. NYC Mesh is a decentralized, community run mesh network that allows you to connect to the internet. The organization positions itself as directly opposed to the ISP monopolies established by Spectrum and Verizon in New York. One of the members told me unequivocally that while the NYC Mesh doesn’t have a formal political orientation, they tend to attract people that fall on the left wing of the political spectrum because of their fundamental critique of the market model. They are committed to bringing internet connectivity to neighborhoods historically underserved by traditional ISPs. They are also able to subsidize connections for people that are facing financial difficulties; notably they don’t remove internet access if someone stops paying for their connection altogether. They are decentralized both in infrastructural terms as well as organizational terms. Technically, this means that there is no one point in the infrastructure that can throttle traffic. Internet traffic has multiple paths to reach its destination, and all traffic is treated equally. On the organizational front, decentralization is slightly trickier. On paper this is supposed to mean that each member of the mesh has equal say in its future and there is no formalized authority structure. As we will see, this is difficult to follow though in practice.
The ambition of their mission, as well as the urgent need for alternative communication infrastructures drew me to this project. My guiding question at the beginning of the project was to try and understand how much a network like this could scale. I wanted to know whether this network could scale to cover the entire city, and what kind of challenges it would run up against in that process. On a more day to day note, I wanted to get a sense of how they were able to live up to their promises of accessibility, inclusion and decentralization as they expanded and maintained the network. Ethnography felt like an ideal method to understand this. Being a community network, they were fairly open to the idea and I had no trouble finding events to attend and people to interview. Observing how people talked about the mesh, how they discussed expansion and maintenance and how they went about their daily work gave me a feel for their work, its potential, structure and even limitations.
To structure my ethnography, I followed Jenna Burrell’s method on networked ethnographies. Instead of trying to grapple with the entire mesh network as a site, I found an entry point as a new volunteer (Burrell 10). I attended a new volunteer orientation and let myself be guided to NYC Mesh events through this pipeline. When thinking about the imaginary of the network and decentralization, I used Marcus’s suggestion to “Follow the Metaphor” to better understand how this idea of decentralization and the discourse surrounding it interacted with on the ground practice (Marcus 14).
Figure 1: Map of NYC Mesh coverage (areas of NY outside the map aren’t covered)
The Network and the City
The new volunteer coordinator suggested I go to a tabling event so I could get a better idea of how things worked. The first NYC Mesh event I attended in person was a tabling event for a community block party in Sunset Park, a neighborhood in South Brooklyn. Walking up to the NYC Mesh tabling booth, I was almost immediately confronted with what I realized later was a key challenge for the organization. Sunset Park has a large Chinese population, many of whom don’t speak English as their first language. Other organizations present had either people who spoke Mandarin, or flyers in Mandarin at the very least. Our booth, made up of myself, another new volunteer, and an experienced volunteer, had neither. Despite this, a few people stopped by, interested in the idea of “free WiFi.” I noticed that when these people approached us, the experienced volunteer with us immediately launched into a somewhat technical explanation of the devices and how they would be connected to the roof and so on. My sense was that this was an overwhelming amount of information for people hearing about the mesh for the first time, (I found myself feeling quite overwhelmed despite having read about it online beforehand) and they left without really engaging further. This was in sharp contrast to later in the day, when a few white Americans, fluent in English, stopped by. The same experienced volunteer was able to engage them in small talk, patiently explain how the mesh worked and what they would need to set it up. As a result, a couple of them left their contact information. Another interesting complication revealed itself during the lunch break at the block party. I questioned the experienced volunteer about promising “free WiFi” to members of the community, and whether he felt an added sense of responsibility for being in charge of such vital infrastructure, especially since most people at NYC Mesh worked day jobs, and were not able to dedicate all their time to the maintenance of the network. He shrugged and said that he didn’t feel a lot of responsibility because it was a “community network”, and they also had a responsibility to make sure it worked well in their area. It felt like there was a disconnect between what he described to me and what he described to the people at our booth. Most of the other stalls were focused on providing essential resources to the community. There were stalls with sets of subsidized groceries, basic medicinal kits and other day to day resources. It seemed to me that what NYC Mesh was offering, because of its affordability as well as the fact that it had recently expanded to most of Sunset Park, would actually have been useful to people there, but this fundamental communication gap made it so that the exact kinds of people the organization set out to help were excluded from it.
Figure 2: Flyers for the Block Party
My experiences at the volunteering event were put into perspective for me during an interview with a different member. She explained that NYC Mesh often relied on people living in a certain neighborhood to take on installation projects, assume responsibility for maintenance, and become the point of contact for queries. This meant that any neighborhood they were to expand into would need to have people with computer networking skills. Very often, she said, the neighborhoods that were underserved by traditional ISPs and in need of subsidized internet access also didn’t have many computer engineers to take up that responsibility. As I saw in Sunset Park, this was also complicated by the language barrier. Without being able to fluently communicate with members of a community, NYC Mesh would not be able to establish a foothold as a replacement for traditional ISPs.
Apart from its interaction with local communities, there is another prominent element to NYC Mesh’s relationship with the city; height. Spending time with people in the network, I noticed how central height was to the question of planning expansions to the network. Members frequently discussed how tall certain buildings were relative to others and whether a certain area had Line of Sight (LoS) or not. This is because of how the mesh works. Access to the internet comes from 5 supernodes embedded in major colocation datacenters across the city. These supernodes broadcast connections over the air to “Hubs” which in turn broadcast connections to individual buildings. Therefore, to connect your building to the mesh, you need to have a direct, unobstructed Line of Sight to the closest hub (or supernode!)
My second field visit with NYC Mesh was to the roof of Columbia Medical Hospital, a 15-plus story building overlooking Harlem. This was a significant work day, if successful, the set up on the roof would enable a large part of Harlem to access NYC Mesh. We started at 9 am, lugging steel pipes to mount routers on, drills to attach the pipes to the roof, and reels of cable to string it all together. Here, the materiality of the internet was made very explicit. It was the opposite feeling to the one I described at the beginning of the essay. Instead of feeling dematerialized, the internet almost felt toy-like in the assembly of equipment hacked together to make it work. I was grouped with the other newcomers and given the task of assembling certain structures that would eventually be used to mount other equipment on the roof. Reflecting on the experience, a couple of things stood out to me. It felt ironic to be standing on the roof of an Ivy League institution overlooking Harlem, promising widespread internet connectivity to the neighborhood, all the while standing on the roof of an institution known for causing widespread gentrification and displacement. There was a sense of the classic “gown and town” dynamic, a paternalistic approach to the community being helped. Further, because of the scale of this project, and the presence of other critical infrastructure on Columbia Medical’s roof, the last part of the project was going to be completed by contractors hired by the university. To be clear, NYC Mesh usually did all the requisite labor themselves, but in this case, I did find it interesting to think about another layer of labor that made this site possible.
Figure 3: View of Harlem and surrounding areas from the roof of Columbia Medical
Figure 4: Boxes I mounted to eventually run cable through
Taken together, these encounters point to a broader tension at the heart of NYC Mesh’s project. Their “imagination” of New York City as this place where traditional ISPs have a monopoly and neglect certain neighborhoods and their role as a corrective that can fill these gaps with volunteers with technical expertise, is a flattening of the problem, and insufficient model to grapple with actual complexities of the city. A neighborhood being infrastructurally “underserved” doesn’t mean that it just has bad wifi; it likely has other complicating factors - maybe a lack of other resources, a language barrier, and a healthy mistrust of outside organizations coming in with solutions to all their problems. These kinds of systemic issues cannot be easily resolved with technical fixes. The distinction between “community network” and “free WiFi” is also key here. Most people don’t have the time or energy to fix their internet connection or deal with their neighbors to figure it out. When people are promised “free WiFi”, they reasonably expect it to work more or less the same way a traditional internet connection works - something breaks, you call someone who comes to fix it for you. Making sure that this distinction is clearly explained is key to getting someone’s buy-in not just as users of NYC Mesh, but also as a part of the larger project. Further, their emphasis on height and connectivity means that they will often deal with organizations (universities, real estate companies, state governments, police departments) that have complicated relationships with the communities they are based in. This means the organization will have to be able to effectively acknowledge and debate these kinds of tradeoffs. Of course, the last tension between the imaginary of an egalitarian network and reality of the city is their entanglement with the data centers that allow for the final connection to the internet. One of the members told me that Verizon had them removed from a datacenter that would have otherwise proved to be a valuable supernode. This dependency creates both a point of entanglement with the larger commercial internet infrastructure, and a site of uncertainty where they can be pushed out at any moment.
Figure 5: 375 Pearl Street, one of the datacenters currently hosting NYC Mesh, also hosts NYPD offices
Figure 6: Another supernode for NYC Mesh, this one is in Brooklyn
Who’s in charge?
Decentralization is a central tenet of both the mythology and the functioning of NYC Mesh. When I asked a mesh member who was in charge of the Columbia Medical install, he pointed someone out, but said that it was only because that member lived in Harlem and had taken lead on this project, otherwise, he was quick to clarify, no one was in charge “we’re a mesh man”. This ethos is reflected in the technical design of the mesh as well. The way the network is set up, there is no single point of failure. Usually, traffic is routed from an apartment building to the nearest hub to the nearest supernode. If for whatever reason a supernode is down, it can reach the internet via another supernode by hopping across the network. The denser the network gets, the more paths there are for traffic to get around. NYC Mesh also commits to not prioritizing any traffic over the other. This design alleviates two of the major concerns brought up with traditional monopoly ISPs earlier. It means there is no single point that can be taken over to throttle internet access. In a condition of internet blackout (a tactic frequently used by governments worldwide in times of political turmoil), a traditional ISP can shut off internet access easily, as all traffic has to pass through a handful of key stations. NYC Mesh on the other hand is directly tapped into data centers across the city, meaning it would be a lot harder to completely halt internet connections. By giving equal priority to all traffic, it also ensures net neutrality, something that traditional ISPs are no longer obligated to respect, at least at the federal level.
Figure 7: A diagrammatic representation of the internal structure of the mesh network, excludes the supernodes. R = apartment rooftop
This kind of decentralized network structure is not easy to set up or maintain. It requires a group of people with enough technical and infrastructural knowhow to climb up roofs, set up routers and connect optic fiber into people’s apartments. It requires people with software knowledge to write routing protocols to make sure traffic flows smoothly. It also requires people to be available to troubleshoot in case things stop working. Understanding how NYC Mesh managed all these responsibilities with a group of volunteers in a decentralized organizational structure was an early preoccupation of mine when I started this project. The information presented in this section came mostly from interviews with members, where I asked about the affordances of a decentralized organizational structure as well as some of the challenges.
The way this structure is supposed to work in theory is as follows. Someone new joins the Mesh, they begin to attend meetings and installations with experienced members and slowly pick up the skills required to complete one or more of the tasks I described above. Over time, this person begins to be trusted with more independence, and is given access to resources. Eventually, once this person is well known in the mesh as a regular contributor, they are trusted to complete as well as initiate new projects entirely on their own, and they begin to mentor new members. This was described to me as a “do-ocracy” by one of the members. When I mentioned wanting to get involved with writing code, they told me that they could point me in the right direction but I had to mostly figure it out on my own. On one hand this sounds like a reasonable way of maintaining organizational structure while avoiding an explicit hierarchy and internal politics. However, my interviews with members of the mesh revealed that when things like resource allocation are left to implicit processes and not communicated, friction within the group can arise. Speaking from experience, having spent a better part of a decade surrounded by software engineers, they are not necessarily good at having open, potentially confrontational conversations, preferring instead to resort to avoidance or passive aggression, a sentiment shared by a member of the organization I interviewed.
A common source of miscommunication brought up independently by two experienced members of NYC Mesh was around the issue of gatekeeping. They said that as members grew more important in the Mesh network, they began to informally exercise control over certain areas, be it physical resources like optic fiber cables and routers, geographical access to certain neighborhood hubs or even access to certain passwords or accounts. The idea is that once someone proves themselves to be trustworthy, they should be able to access these things in an unfettered manner. Unfortunately, in practice this doesn’t always work smoothly, with people not always sharing resources, possibly out of a personal dislike, a disagreement with how that resource is best used or even a difference of political opinions. When there isn’t an obvious forum to address these issues, this implicit hierarchy dictates how decisions are made. The member I spoke to said that in a decentralized environment, conflict is either ignored entirely or leads to passive aggression, with people leaving the organization altogether after a dispute. However, as another member pointed out, a certain degree of gate-keeping is necessary to protect the mesh network. They narrated cases where outsiders showed up to meetings suddenly demanding access to multiple systems, only to later turn out to have malicious intentions. They also said that since the release of ChatGPT in 2022 they’ve had people show to the mesh convinced by their conversations with LLMs that they know best how to grow the network. This balance is also complicated by the presence of a Board of Directors, established so that the Mesh can have 501c non profit status and receive funding from grants and donors. This board has to vote on the disbursal of funds above a certain amount. It is made up of 5 people from the network and has not had an election in two years. It frequently delays approval of key projects. My interlocutor attributed this to the board being busy with their day jobs, not malicious intent, but he did seem frustrated at the situation.This balance between gatekeeping and protection can create a distrustful environment where a lot goes unsaid. This model also doesn’t necessarily lend itself to efficient utilization of resources.
Another topic related to decentralization that came up across multiple interviews was the idea of a “bus factor.” The bus factor is a crude formulation that depicts the number of people that would be able to replicate the knowledge lost if a certain person got hit by a bus. A high bus factor means the organization is truly decentralized and fault tolerant, as there is no one person that has a disproportionate amount of information. Both my interlocutors conceded that NYC Mesh has a low bus factor, meaning there are a few key people that possess an outsized amount of information. The perils of a low “bus factor” were highlighted when someone important to the organization left suddenly with important information, refusing to return calls or messages. Put concretely, according to my interviews, there are about 24 “core” members of NYC Mesh that are aware of all major goings on in the organization. There are about 15-20 “peripheral” members that are trusted but contribute less frequently. Members frequently switch between these two circles depending on their availability. An interlocutor revealed to me that the most active member on the NYC Mesh Slack troubleshooting channel no longer lives in NYC, he is a former contributor to the Mesh who continues to help out due to good will. He expressed that if this person stopped responding, it would significantly increase the troubleshooting burden on the rest of the active members. The relatively small number of contributors along with the internal dynamics described above make it a difficult environment for a new contributor to enter, complicating this narrative of a decentralized organization.
NYC Mesh currently serves around 2600 households in NYC and is rapidly growing. It is also trying to work with real estate developers, public housing and businesses to expand its reach. As the network expands, certain decisions on who to collaborate with and how best to utilize the limited resources of the mesh will have to be made. Maybe there is room for a democratic centralization of the organization while the network remains technically decentralized. When I posed this question to one of my interlocutors, he immediately said that he viewed some amount of centralization as necessary in the near future. Of course, others might say organizational and technical decentralization are inextricably linked.
Myth, Materiality and Knowledge Transfer
I conducted most of my interviews at a weekly meeting called “Open Mesh Night.” These meetings happened at the NYC Mesh “headquarters”, located in a basement beneath a bookstore in Lower Manhattan. To enter, I had to ring a barely perceptible doorbell, and someone let me in by swinging open a door that looked like a bookshelf. It was very secretive, I remember thinking it was the kind of hideout for hackers you would see in a movie. When I entered, I was struck by the amount of internet-related paraphernalia lying around. There were boxes and boxes of wires, some junk, some useful. There were extra routers that would one day be used to establish new connections, and a whole host of other technical looking stuff I didn’t recognize. I eventually settled next to someone “crimping” ethernet cables, which basically means configuring these cables so they work properly. They taught me how to do it, and by the end I was successfully able to crimp a few.
This pattern, of being surrounded by internet materials, and immediately getting a lesson of some sort in handling those materials, persisted through all of my field visits. At the Sunset Park tabling event, the experienced volunteer with us used the props he had brought for a demonstration to explain how to set up a connection on the roof of an apartment building. At the Columbia Medical Install, the new volunteers were set up in an assembly line, making structures that would help attach long poles to the wall, so routers could be dangled from them. Of course this is expected to some degree, training volunteers so they can perform basic tasks is the first step to making them full members; but what stuck out to me over those few instances was that this knowledge transfer was always mechanized and presented out of context. Even during the Columbia Med install, I had to ask several times to understand the purpose of the contraption I was building. I noticed this between other experienced members as well, one of the members showed another how to operate a certain type of drill at the other’s request, only for someone else to walk by later and ask about the same drill. Also, new volunteers join at different experience levels, someone who has a lot of experience with networking will presumably not be engaged by simple assembly tasks, and someone with no experience at all will likely want some background explanation on what they’re being trained to do.
Experienced members in NYC Mesh are clearly very capable. Yet, knowledge transfer in NYC Mesh happens in a very tacit, embodied way. There are no organized avenues for knowledge sharing, whether you learn something or not depends on whether you happened to be at a certain event at the right time. The idea is that if you attend enough events you should be able to cobble together a set of skills useful to the mesh, but to me it felt insufficient. It felt like more organized attempts at knowledge transfer would help keep new volunteers engaged (something they struggle with) as well as help solve their “bus factor” problem mentioned earlier. This is borne out by the fact that on the rare occasion that they do plan a learning event, people on Slack show a lot of enthusiasm and end up attending.
My intuition is that there is an aversion in the organization for this kind of project. The new volunteer coordinator described the NYC Mesh as an organization in-between a non profit and anarchist collective. I think here we see tendencies from the latter side creep in. Knowledge is seen as “earned” not just given, and this is tied into their mythos of a DIY, adventurous hacker culture. It also arises from the particular kind of materiality of the infrastructure. Earlier in this essay I described them as “toy-like”, and I think this quality of all their equipment also inspires a sense of “figuring it out” or just hacking it together. It doesn’t necessarily feel like something that has to be taught as opposed to just picked up, but as the mesh grows, there just aren’t enough people that can learn on the fly. If they have the skills already, the lack of an organized pathway is frustrating, and if they don’t, then their avenues to contribute are limited. Of course all of this is complicated by the fact that most people in this network are volunteers with day jobs, and are hyper focused on the technical side. There isn’t much room for this kind of meta-planing.
Figure 8: From left to right - the radar that picks up signal, the omni-router on the roof, the router at home
Reflections
These tensions revealed themselves to me after spending three months talking to people from the mesh and attending their events. They are a mix of the pressures arising from an attempt at constructing an “alternative infrastructure” in a city like New York, as well as organizational peculiarities that will have to be corrected in the future. Concepts like accessibility, affordability and decentralization are commendable goals, but they turn out to be far less straightforward when they come up against the realities of life in the city. Dealing with the diverse and heterogenous nature of local communities, messy institutional links or the complications of intra-organization politics will require a kind of systematic approach that idealism and techno-solutionism alone can’t provide. Further, clinging to these narratives without acknowledging these complications and avoiding conflict just serves to heighten them, as even solvable issues go unacknowledged. As it stands, the tensions described in the last three sections indicate a limit on how much farther this network can expand, how effectively it can maintain already existing connections and how many people it can train.
That being said, over time, I became less interested in whether or not the mesh could expand to cover larger parts of the city, instead I found myself drawn to the particular weaknesses and modes of failure I witnessed, the durability of the organization and infrastructure throughout, and the delicate balance between these two.
There are serious challenges facing the mesh that might well limit the network fundamentally and prove to be insurmountable in the long run, but what really jumped out to me after spending some time in the organization was how many of the challenges identified above were well within their reach to address. For example, creating a robust training pipeline for new volunteers doesn’t seem all that difficult to pull off. The mesh already has several talented people that spend a lot of time on the network, scheduling a monthly training session for new volunteers isn’t too much of an ask. Creating lists of opportunities for new volunteers, making the meetings a little more inclusive would go a long way in increasing the number of people that can meaningfully contribute to the organization. Similarly, creating a forum for discussing issues around resource utilization and bigger picture strategy seems like a good start to hashing out disagreements that are currently hidden.
The infrastructural element might also be durable enough to survive whatever organizational or social uncertainty lies in the organization's future. Once nodes are set up, they genuinely do not need excessive maintenance and can work uninterrupted for years at a time. Recently, an issue came up with one of the nodes in the Slack channel. Upon further investigation, it was revealed that the person living there, the one who set up the node, had moved out four years ago, and the node just kept chugging along without anyone noticing. It even came back online on its own. Even though the volunteers often drop off for periods at a time, many of them come back. A lot of people have stuck around since the organization was founded in 2014. There’s something compelling about this kind of infrastructure that exists with minimal interruptions to its surroundings, woven into the cityscape. In her chapter “Ether Ore”, Mattern says “Our acts of excavation, whether metaphorical or literal, have ethical and political implications for those who occupy or have some investment in those sites—as well as for those who administer and design their futures. Those envisioned futures, informed by an archaeological sensibility, will ideally be something more richly layered than the tabula rasa techno-solutionism of sites like Songdo or Hudson Yards” (Mattern 25). At its best, as it continues to struggle to integrate socially with local communities, NYC Mesh can be the kind of technical infrastructure that is informed by architectural sensibilities and layered into the city, instead of the totalizing, infrastructure heavy, top down approach taken by traditional ISPs.
In their piece on Wiindigo infrastructure, LaDuke and Cowen describe the process of First Nations in Canada becoming energy independent by developing solar energy infrastructure, thereby separating themselves from the “Wiindigo” or extractive energy industry they were reliant on before. Yet they acknowledge these solar panels are manufactured through exploitative processes, but ultimately conclude that the “the emergence of community-based energy cooperatives, holds out the promise of ‘democratization’ of energy generation, distribution and governance” (LaDuke and Cowen 16). Of course it goes without saying that energy access for the First Nations is far more critical than internet access in a big city, but this kind of argument about the “promise of democratization” can be applied to the efforts of the NYC Mesh as they deal with the myriad contradictions animating their organization.
As a closing thought, I wanted to bring up something my interlocutor said when I offered that NYC Mesh would always be compromised because of its reliance on datacenters. They said that they viewed NYC Mesh more as a community network than a source of internet, because even if they lost access to the datacenters, the rest of the network would remain connected. According to them, there was an inherent value in a network that connected large parts of a city. I thought that was an interesting way to frame the project and its potential.
References:
Marcus, George E. “Ethnography in/of the World System: The Emergence of Multi-Sited Ethnography.” Annual Review of Anthropology, vol. 24, 1995, pp. 95–117. JSTOR, http://www.jstor.org/stable/2155931. Accessed 16 Dec. 2025.
Mattern, Shannon. “Introduction: ETHER/ORE.” Code and Clay, Data and Dirt: Five Thousand Years of Urban Media, University of Minnesota Press, 2017, pp. vii–xl. JSTOR, https://doi.org/10.5749/j.ctt1pwt6rn.3. Accessed 16 Dec. 2025.
LaDuke, Winona, and Deborah Cowen. “Beyond Wiindigo Infrastructure.” South Atlantic Quarterly, vol. 119, no. 2, Apr. 2020, pp. 243–68. DOI.org (Crossref), https://doi.org/10.1215/00382876-8177747.
Burrell, Jenna. “The Field Site as a Network: A Strategy for Locating Ethnographic Research.” Field Methods, vol. 21, no. 2, May 2009, pp. 181–99. DOI.org (Crossref), https://doi.org/10.1177/1525822X08329699.
Ali, Christopher. “My Internet Provider Is a Monopoly and Yours Probably Is Too. Here’s What It Means for Your Broadband Bill.” CNET, www.cnet.com/home/internet/my-internet-provider-is-a-monopoly-heres-why-yours-probably-is-too/. Accessed 16 Dec. 2025.