From channels to networks: information is a distributed problem

There is a habit of thought in publishing, in technology distribution, in humanitarian information work, and in internet freedom. The habit is to picture information as moving from a producer to an audience through a channel. You make the thing. You push it out. An audience receives it.

Our research on Iran's June 2025 internet shutdown with ASL19 shows how thoroughly that frame breaks down under pressure.

When Iran cut roughly 90% of international traffic while keeping the appearance of being online, the country was running on something else. Not the formal channel from publisher to reader, or from tool builder to user. The work was being done by ordinary people, embedded in everyday relationships, forwarding tools and information and trust through their own networks.

Among people who were aware of circumvention tools, 76% had helped someone else use them. Forty-seven percent recommended tools to others. Fourteen percent did hands-on setup help, sitting next to family members and configuring apps.

Twenty-eight percent of those who had a working setup ran some kind of infrastructure for others: a Telegram channel, a configuration guide, a server, a hotspot. Our rough estimate is that 25 to 40 million Iranians played some kind of helper role.

This is not a story about a few power users carrying everyone else. It is a dense, distributed, layered network. Family, friends, colleagues, communities. Tools fail. Servers go down. Channels get blocked. The social network that routes knowledge and trust around those failures is much harder to disrupt.

The same pattern shows up in any setting where formal channels are broken: censored countries, regions in conflict, displaced populations, exiled diaspora, minoritized language communities, communities that have lost trust in institutions. The official channel does not reach. The unofficial channel does.

For anyone building information products, this is a category-level shift in what the product actually is.

A media product built for the old model is a publication. Text, images, video, hosted on a domain or in a feed, addressed to a reader. The unit of work is the article. The unit of distribution is the channel.

A media product built for the new model is harder to describe in one word. Its unit of work is something that can be forwarded. Its unit of distribution is the relationship. Its primary user, in many cases, is not the reader but the person who is about to pass the thing on to the reader. The product's success is measured not by reach to an addressable audience, but by survival in the network: does the thing keep moving after it leaves the source?

This is why the helper frame from our Iran report matters well beyond Iran.

We identified three distinct kinds of helpers.

• Information sharers recommend or mention tools and content to others. They are the most common type and the most demographically inclusive. Women and lower-income users participate at high rates.
• Setup helpers install, configure, and troubleshoot for others. More technical, more time-intensive, dominated by younger and wealthier men.
• Infrastructure enablers run channels, groups, servers, and hubs that many people depend on. The most resource-intensive role, by far the most skewed demographically.

They need different things! The information sharer needs something to share: a short, Persian, screenshot-based guide that travels well in chat. The setup helper needs a one-tap install link that bundles app and config. The infrastructure enabler needs shareable subscriptions, ready-to-use configs, and safer ways to distribute resources at scale.

If we transplant this onto the editorial world, three roles map directly.

• The reader who recommends a story to a friend, with a one-line context, in a private message or a community chat. This is the most common act of distribution in our networks today and the one editorial organizations have done the least to support. The product feature is not "share to social." It is "summarize this so I can paste it to my mother."
• The reader who is the trusted family news explainer in their network: the friend who sends three relevant links and a synthesis when something happens, the family member who knows what to read. They need source material designed to be re-purposed, generous quoting permissions, clean exportable highlights, language adapted for forwarding.
• The reader who runs the village: a community moderator, a group admin, a teacher, a local newsletter author, a translator who maintains a feed for their community. They need archives, bulk access, syndication-friendly formats, in some cases editorial relationships with the publication itself.

These three users want very different things. They cannot be served by the same product surface. They certainly cannot be served by a homepage and a paywall.

This is also where service design enters. As a discipline, service design does not start with "what does the user see." It starts with "how does the whole service work, front-stage and backstage, and who are all the actors involved."

Supporting actors get the same design attention as primary users. In service design vocabulary, a journey is not one user's path through a product. It is a map of how a service moves across people and over time.

Applied to information, this gives us a different question to ask: less "what do you want to read." That is the old model. A better question is: what do you want to send. Who in your community is moving things on your behalf, and what would let them do that better.

The full report will be released June 1.