A New Layered Internet

The internet I build on for a living is getting worse, and I don't only mean the feeds. Imperva's latest bot report found that 53% of the web traffic it saw in 2025 was automated, and 40% came from bots it classifies as malicious. Graphite's ongoing crawl of newly published articles puts the share written mostly by AI at about half, and it has hovered there since early 2025. Underneath the content, the plumbing has concentrated. A 2020 study found that 89% of the top 100,000 websites critically depend on a third-party , or certificate provider, and that the top three providers alone could affect 50 to 70% of those sites.

So I've been running a thought experiment. Suppose a effectively took over the internet we have. What would need to already exist for a second one to take its place?

My first answer was a stack: an independent system at each critical layer, with as the keystone. Concretely, for content, a decentralized DNS for names and multipath transport underneath. All of it would be free of any central authority and, I assumed, would cost nothing in .

I spent some time checking that sketch against published measurements and incident reports. The keystone held up better than I expected. Several of the specific pieces I picked did not hold up as they stand, and one of them hits a deadline eight days from the day I'm writing this. Every one of those failures turned out to have a known fix, though, and the fixes all share the same shape. It starts from one idea:

Name things by what they are, and it stops mattering who delivers them. Once it stops mattering who delivers them, anyone can.

What a takeover would actually look like

"A botnet takes over the internet" sounds like a movie plot, so I tried to pin down what it would mean in practice. The record shows botnets getting there in two ways. They flood, and they move in.

Flooding is the familiar one. In October 2016 the Mirai botnet, built from hijacked devices, aimed its traffic at Dyn, a single DNS provider, and Twitter, Netflix, Reddit and became unreachable for many users across three waves of attack. Dyn estimated up to 100,000 malicious endpoints. The ceiling has risen a long way since then. The current public record is a 31.4 attack in late 2025 that Cloudflare attributes to the Aisuru-Kimwolf botnet, an estimated one to four million hosts made up primarily of Android TVs. It lasted 35 seconds.

Moving in is the part that changed how I think about this. The KV-botnet that the FBI disrupted in early 2024 lived on end-of-life Cisco and NetGear routers in homes and small offices. Those routers get no patches, and the operators later rebuilt the botnet. went further up the chain and targeted backbone, provider-edge and customer-edge routers at telecom carriers, with nine US carriers confirmed compromised by the end of 2024. That is an adversary living inside the network, and any design that assumes the pipes are neutral has to account for it.

Then there is the failure that needs no botnet at all. On November 18, 2025, a database permissions change doubled the size of a configuration file in Cloudflare's bot management system and crashed its proxies for hours. Cloudflare called it its worst outage since 2019. A month earlier, a race condition in the automation that manages DynamoDB's DNS records in AWS us-east-1 left an empty record behind, and the knock-on effects lasted about fifteen hours.

The common thread is concentration, and it sits higher in the stack than I first assumed. When cables in the Baltic Sea were cut in November 2024, found that "the Internet managed to route around the damage," with a little added latency and no visible packet loss. The pipes have held up. The fragile part is the handful of services that everyone resolves names and fetches content through. That shifted where I think a new internet most needs to be independent.

Why content addressing is the keystone

A names a location. https://example.com/report.pdf means "ask this server for whatever it currently calls report.pdf." To trust the answer you have to trust the DNS that found the server, the that vouched for it, every network in between and the server itself.

A content address names the bytes. The name is a of the content, so anyone can hand you the data and you can check it yourself:

Rust

/// Accept bytes from any peer, whether a cache or a stranger.
/// The name is the hash, so checking it needs nobody's permission.
fn verify(name: &blake3::Hash, bytes: &[u8]) -> bool {
    blake3::hash(bytes) == *name
}

That one comparison is why I think the keystone claim holds. Once verification happens at the edge, every layer underneath is allowed to be untrusted. A hostile router can drop your data but it can't swap it, and a copy on your neighbor's machine is exactly as good as the original. has worked this way for about twenty years: once you know a 's hash, you can fetch it from any mirror without trusting whoever runs the mirror.

flowchart TB subgraph byContent ["Fetch by content"] HASH["Content hash"] --> ANY["Any source cache, peer, mirror or stranger"] ANY --> CHECK{"Hash matches?"} CHECK -- no --> ANY CHECK -- yes --> VERIFIED["Bytes you verified"] end subgraph byLocation ["Fetch by location"] URL["https://example.com/report.pdf"] --> DNS["DNS resolver"] DNS --> CA["Certificate authority"] CA --> CDN["CDN edge"] CDN --> ORIGIN["Origin server"] ORIGIN --> TRUSTED["Bytes taken on trust"] end class CHECK,VERIFIED keystone class TRUSTED muted

A URL asks you to trust every hop on the way. A content address lets anyone answer, because the answer checks itself.

The broader version of the idea is what I'd put at the center. Content addressing is one case of a , a name that proves its own claim, and the same trick works at other layers. and derive a node's address from its public key, so nobody can take over an address without the matching private key. The , published as 9498 in 2023, does the same for naming: a zone's global name is its public key. If every layer names things this way, no layer has to take another's word for anything. Each one can check.

The through-line: trust problems become redundancy problems

Most of what makes today's internet fragile is that we have to trust specific parties, such as a particular DNS provider, CDN, certificate authority or origin server. Trust doesn't scale sideways. Adding a second resolver doesn't make the first one more honest, because the second one might lie too.

Verification changes that. Once a name proves its own content, a wrong answer costs nothing but the time it takes to check, so you can ask many sources at once and keep whichever one verifies first. A trust problem turns into a redundancy problem, and redundancy is something people already know how to build and pay for.

Redundancy has one blind spot. If an attacker can cheaply become most of your sources, adding sources stops helping, and a botnet is exactly that kind of attacker. For that case the design needs a second move, which is to lean on relationships. The 2006 paper put the reason in one sentence: "Malicious users can create many identities but few trust relationships." A botnet can mint a million keys. It can't get a million people to vouch for them.

Those two moves are the through-line. Verify, then diversify, and where diversity runs out, trust relationships. Every fix below is one of the two, and most of them are already running in production somewhere.

flowchart LR NAME["Self-certifying name"] --> RACE["Ask many sources"] RACE --> CHECK{"Verifies?"} CHECK -- yes --> USE["Use and serve it"] CHECK -- "no, maybe fakes" --> VOUCH["Ask sources that people you trust vouch for"] VOUCH --> RACE class RACE,VOUCH keystone

The through-line. Verification turns trust into redundancy, and relationships cover the one case redundancy cannot.

Where the first sketch breaks, and how to fix it

Latency: real on a cold fetch, and payable

I wanted independence to be free. For content nobody nearby has, it costs seconds. The 2022 measurement of IPFS put median retrieval at 2.90 seconds and found that most retrievals took at least four times as long as the equivalent HTTPS request. An 2024 paper co-written by engineers, titled "The Eternal Tussle: Exploring the Role of Centralization in IPFS," measured nearly the same thing, 2.72 seconds at the median. Part of that is by design: waits one second for already-connected peers before it starts searching the . Mutable names are slower again. reported median resolution at around 11 seconds in 2025, because a lookup waits for 16 responses.

The fix is to stop making every fetch start from zero. Most links are shared by someone who already knows where the content lives, so the link can carry that knowledge along with the hash. BitTorrent have done this for years. Alongside the content hash they can list trackers and peer addresses to try first:

Text

magnet:?xt=urn:btih:<info-hash>&tr=<tracker-url>&x.pe=<host:port>

An ticket goes further and bundles a hash with the public key and addresses of a node that has the data, so the fetcher can dial it directly with no lookup at all. A hint can be stale or even malicious and it doesn't matter, because the bytes still have to match the hash.

When there is no hint, race every route at once. Kubo already queries the DHT and the in parallel and takes whichever answers first. The same pattern extends to local peers, friends' nodes and several independent indexers, the way (RFC 8305) races IPv4 against IPv6 so nobody waits on the slower one.

sequenceDiagram participant You as Your node participant Hint as Hinted peer participant Index as Indexers and DHT participant Friend as Trusted friend Note over You: The link carries a hash and a hint par Dial the hint directly You->>Hint: Request by hash Hint-->>You: Bytes and Race the other routes You->>Index: Who has this hash? Index-->>You: Provider records You->>Friend: Do you have this hash? end You->>You: Check the bytes against the hash Note over You,Friend: The first copy that verifies wins, and the rest are cancelled

A fetch that starts from a link carrying a hint, while every other route races in case the hint has gone stale.

Mutable names get the same treatment. IPNS records are signed and carry a sequence number where the highest one wins, so a client doesn't need 16 peers to agree before it acts. It can accept the first valid record, show the content and quietly upgrade if a newer record turns up. Kubo already exposes the pieces: ipfs name resolve --stream returns records as they arrive, and --dht-record-count lowers the 16-response default.

Caching finishes the job. Every node that fetches something can serve it, because a copy is as good as the origin, and the NSDI study shows what that buys: cached lookups at a finished within 24 milliseconds at the 95th percentile, and at the median the gateway answered about a hundred times faster than the DHT. , on by default since Kubo 0.39, also cut publishing from about 20 seconds to about 0.7 at the median.

What stays slow is a fetch for content that arrived without a hint and that no nearby node or indexer knows about. That case will keep costing seconds. I think that's a fair price for a network that keeps working when the fast paths are gone, and in the scenario I care about, whether something arrives matters more than how quickly.

Sybil attacks: detect them, then lean on relationships

This surprised me most. A distributed hash table like the one IPFS uses finds content by asking the peers whose IDs sit closest to the content's hash. If an attacker can place enough fake peers near a given hash, they control the answer. In 2024 researchers showed they could censor a specific piece of content on IPFS with 45 fake peers running on a single machine that cost about $4 on AWS. John Douceur named the underlying problem the in 2002: without some logically central authority vouching for identities, a peer-to-peer system can't stop one party from pretending to be many. A botnet is an enormous supply of cheap identities.

The first defense comes free with content addressing, because censorship is detectable. You know exactly what you asked for, so silence or a wrong answer is a signal to go somewhere else. The same 2024 paper built on that. Its detector flagged 99.6% of attacks from the pattern of peer IDs clustered around the target, and its region-based fallback raised the share of downloaders who got the content, against the same 45 fake peers, from 0.44% to 100%. It hasn't shipped in Kubo, and a paper posted in 2025 describes an attack that gets past it about 80% of the time, so it isn't the last word. It does show the problem responds to engineering.

Older defenses are sitting on the shelf too. The 2007 paper proposed looking a key up along several disjoint paths, so that one poisoned neighborhood can't answer for all of them, and making node IDs expensive to generate with a crypto puzzle. The implementation of ships disjoint-path lookups as an option that is off by default. Turning on a defense that already exists is a configuration choice.

Some hardening doesn't transfer. Limiting how many peers can come from one IP range helps against a single attacker renting servers, and does little against a botnet whose members each sit on their own home connection. That is where relationships come in. SybilGuard's insight is that fake identities connect to the honest network through very few trust edges, because persuading real people to vouch is expensive. A node that prefers peers its owner knows, or peers vouched for by people they know, forces an attacker to compromise relationships instead of renting machines. is slower at reaching strangers, so it belongs in the race as one more route, and it's the one route a botnet can't flood.

flowchart LR subgraph honest ["People who know each other"] direction TB ANA([Ana]) --- BEN([Ben]) ANA --- CHO([Cho]) BEN --- DEV([Dev]) CHO --- DEV end subgraph botnet ["Botnet identities"] direction TB K1([key]) --- K2([key]) K1 --- K3([key]) K2 --- K4([key]) K3 --- K4 end honest -.-|"a rare trust edge"| botnet class K1,K2,K3,K4 hostile

SybilGuard's insight. A botnet can mint identities cheaply, but it reaches the honest network through very few trust edges.

With every route raced, an attacker has to win all of them at once: the DHT, every indexer, every hint in every link and every friend's cache.

IPFS re-centralized, so make every piece replaceable

The IPFS network that exists today leans on the kind of concentration I was trying to escape. A 2023 measurement found about 80% of DHT servers running in cloud data centers, with the top three providers hosting just over half of them, and 96% of content-resolution requests coming from Amazon's network. A 2025 study found that 5% of peers now host more than 80% of the content. The public gateways at ipfs.io and dweb.link were serving more than 500 million requests a day earlier this year. In the Eternal Tussle paper, writing as the core maintainers, the authors said they had "begun to explore more hybrid approaches" in response to the performance they measured.

Then, on August 24, announced that Protocol Labs would not renew its funding. Shipyard is the nonprofit that has maintained Kubo, and most of the rest of the IPFS stack since it spun out of Protocol Labs in 2024. Its last day of IPFS work is September 30, 2026. On that day it stops operating ipfs.io, dweb.link, delegated-ipfs.dev and the that new IPFS nodes use to find the network. Protocol Labs owns them and, in Shipyard's words, "will determine their future." As of mid-September nobody had named a successor.

The protocol will outlive this, and most of the fixes are already written down. The IPFS specification defines gateways that return raw blocks for the client to check, so it can verify the data "without delegating any trust to the gateway itself." The Service Worker Gateway does that verification inside the browser, and the IPFS project has started steering ipfs.io and dweb.link visitors to it at inbrowser.link. Once verification moves to the client, a gateway is just a cache, and anyone can run one.

Bootstrapping has a working model elsewhere. Bitcoin Core ships seven , each run by a different named person, and falls back to a hardcoded list of nodes if it hasn't found peers within a minute. Add local network discovery and peer exchange, and no single operator's shutdown can strand a new node.

The mirror model is older still. Debian's archive is served from 352 mirror sites, and none of them has to be trusted. A signed index lists the of every package, so rejects anything a compromised mirror slips in. That is content addressing with a signature on top, and it has worked quietly for years.

Plural implementations close the loop. Kubo, Helia and iroh already speak content addressing in different languages with different tradeoffs, and the keystone is the primitive they share. Two of those three lose their maintainer on the same day, which is exactly why the list needs to be longer. None of them individually has to survive for the primitive to survive.

flowchart TB subgraph impls ["Implementations"] KUBO["Kubo"] HELIA["Helia"] IROH["iroh"] NEXT["Whatever comes next"] end PRIMITIVE["Content addressing the primitive nobody owns"] impls --> PRIMITIVE PRIMITIVE --> GATEWAYS["Trustless gateways anyone can run one"] PRIMITIVE --> SEEDS["Many bootstrap seeds plus local discovery"] PRIMITIVE --> MIRRORS["Signed mirrors any host will do"] class PRIMITIVE keystone class NEXT muted

Every piece replaceable. Because clients verify, gateways, seeds, mirrors and implementations become interchangeable.

Naming: DNS as the introduction, keys as the identity

Around 2001 Zooko Wilcox-O'Hearn observed that a naming system can be decentralized, secure and human-meaningful, but only two at once, a tradeoff now called . Blockchain naming tried to buy all three with a ledger, and the record is rough. When Princeton researchers studied in 2015, 28 of roughly 120,000 registered names were not squatted and had nontrivial content. is winding down in the market: Namecheap dropped support for Handshake domains in June 2026, and Namebase is sunsetting its legacy platform.

is the success story, and it shows the other problem. Resolution always starts on Ethereum mainnet, which most clients reach through a few . MetaMask connects through Infura by default, and Brave resolved .eth names through Infura until it moved to Chainstack in January 2026. In February ENS scrapped its planned chain, and in March it announced plans to apply for .ens as a top-level domain in 's 2026 round. The most successful alternative naming system is applying for a seat in the root it set out to route around.

The fix starts by giving up on global human-readable names as the identity. The GNU Name System gives every zone a self-certifying name derived from its key and lets each person attach their own to the zones they care about, the way your phone's contacts map "Mom" to a number nobody else needs to agree on. The reserved the .alt suffix in RFC 9476 so systems like this can coexist with DNS without colliding.

Friendly names still matter, so use the DNS we already have as an introduction. Bluesky's works this way today. A handle is an ordinary domain name, a DNS TXT record at _atproto.<handle> points it at a , and the DID is the account's real identity. The spec describes handles as mutable and DIDs as "the long-term persistent identifiers." Once you've resolved someone, you hold their key, much as remembers a server's host key in known_hosts after the first connection and warns you if it ever changes. If DNS later goes down or gets hijacked, the key you already pinned keeps working.

The last piece keeps any registry honest. puts every publicly trusted certificate into public append-only logs, and Chrome has required it since 2018, so a certificate authority can't quietly issue a certificate for your domain. WhatsApp and Apple's iMessage both applied the same idea to messaging keys in 2023. A naming service that has to publish every binding in a log like that can still be wrong, but it can't be wrong in secret.

sequenceDiagram participant You participant DNS participant Log as Public binding log participant Them as Their node You->>DNS: Look up alice.example DNS-->>You: Points to a key-based identifier You->>Log: Has this binding been published? Log-->>You: Yes, with an inclusion proof You->>You: Pin the key Note over You,Them: Months later, DNS is hijacked or offline You->>Them: Connect using the pinned key Them-->>You: Proof signed with that key Note over You: The pinned key still verifies

How the naming pieces combine. DNS makes the introduction once, the pinned key becomes the identity, and a public log keeps the registry honest.

Multipath works when the paths differ in kind

Multipath transport is real and useful. has been a standards-track RFC since 2020, and was approved by the in March and is waiting on publication. The catch is written into the MPTCP architecture document: the network does not expose path diversity, so the protocol can only infer it from having more than one address. The InterTubes study mapped US long-haul fiber in 2015 and found single conduits shared by as many as 19 ISPs. Two paths through one trench are one path.

The fix is to choose paths that can't share a trench. Apple has run Multipath TCP in production since iOS 7 for Siri, and since iOS 13 for Maps and Music, across Wi-Fi and cellular, two media that fail for different reasons. Linux has had initial MPTCP support upstream since kernel 5.6 in 2020. Stretch the same idea across fiber from one carrier, a cellular modem, a satellite dish and a mesh radio, and the links stop failing together.

flowchart LR subgraph diverse ["Is diverse"] FIBER["Fiber"] --> DEST2["Destination"] CELL["Cellular"] --> DEST2 SAT["Satellite"] --> DEST2 MESH["Mesh radio"] --> DEST2 end subgraph shared ["Looks diverse"] ISPA["ISP A"] --> TRENCH["One shared conduit"] ISPB["ISP B"] --> TRENCH TRENCH --> DEST1["Destination"] end class TRENCH hostile

Two paths through one trench are one path. Links over different media fail for different reasons.

Endpoints can also check instead of assuming. The IETF has already specified how to tell from delay and loss statistics whether flows share a bottleneck (RFC 8382, written for real-time media). goes further and lets the sender choose among paths the network publishes, grouped into isolation domains that each keep their own roots of trust. It carries the Secure Swiss Finance Network, roughly 300 institutions, and started a SCION experiment in April. Its specifications are still in the RFC Editor queue, and Anapaya is the main commercial vendor.

Abuse: moderation that composes

Anything that resists takedown resists every takedown. When Google disrupted the Glupteba botnet in December 2021, about a million Windows machines, the operators had a backup plan: new addresses encoded in Bitcoin transactions. Within days they used it. kept its fallback servers on Emercoin's blockchain DNS, where no registrar could seize them. Kaspersky counted almost 400,000 phishing emails pointing at IPFS-hosted pages in February 2023 alone and noted that "you cannot delete files uploaded by third parties from IPFS." Hash help, though Kubo's own documentation calls them "whack-a-mole," and a 2024 study showed existing filters can be circumvented.

Email is the precedent that gives me the most confidence here. It has no center, it has been abused from the start, and it's still usable, largely because every mail operator chooses which to consult (RFC 5782 describes the practice) and lists like , founded in 1998, compete on accuracy. Bluesky built the same shape into its moderation in March 2024: anyone can run a , and users stack the ones they subscribe to. Content addressing sharpens this, because a label attached to a hash applies to every copy everywhere.

Signing keys supply the rest. When every author signs, reputation accrues to keys, and a network can give brand-new keys very little reach until someone vouches for them. A botnet's keys are free to create and worth almost nothing to use.

This doesn't make the Glupteba problem disappear. A network nobody can shut down is one a determined operator can hide in. What composable moderation gives you is a network where every community can refuse to carry what that operator publishes.

The stack, assembled

Putting it back together, this is the stack I'd defend now. Every layer follows the same rule: it's independent of the layers around it, and it names things in a way that proves itself. Two layers that share a failure are one layer.

Layer	Replacement	What proves itself	Weak point	What makes it viable
Physical	Community mesh, LoRa, satellite, sneakernet	Nothing, so treat it as hostile	Low bandwidth, patchy coverage	Media that fail differently, plus store-and-forward delivery (RFC 9171)
Addressing and routing	Key-derived overlays (Yggdrasil, cjdns, Reticulum), SCION	The address is a hash of a key	Young software	Run as an overlay on today's internet first while RPKI hardens BGP underneath
Transport	Multipath QUIC and MPTCP	Keyed, encrypted sessions	Paths that share a trench	Paths over different media, shared-bottleneck detection
Naming	Self-certifying zones with petnames	The name is a key	No global readable names	DNS as an introduction, pinned keys, transparency logs
Content	Content addressing	The name is a hash of the bytes	Cold-fetch discovery	Hints in links, raced routing, caching everywhere
Discovery	Open DHTs, several indexers, friend-to-friend routing	Signed provider records	Sybil attacks	Censorship detection, disjoint lookups, trust-weighted peers
Identity and provenance	Signing keys, web of trust, verifiable credentials	The author is a key	Key management	Passkey-style key handling, vouching by people you know
Moderation	Subscribable blocklists and labelers	Labels bound to hashes and keys	Whack-a-mole	Reputation on keys, operator-chosen lists as in email
Persistence	Pinning by communities and libraries	The hash	Someone pays for disks	Erasure coding across holders, library consortia like LOCKSS

Inside a single node, the layers meet like this:

flowchart TB APPS["Apps: browser, messenger, feeds"] subgraph node ["Your node"] NAMES["Name book petnames to pinned keys"] --> ROUTER["Router races hints, indexers, DHT and friends"] TRUST["Trust graph vouches, blocklists, labels"] --> ROUTER ROUTER --> VERIFY{"Verifier hashes and signatures"} VERIFY -- verified --> STORE["Content store everything named by hash"] end subgraph links ["Links: any mix, all untrusted"] FIBER["Fiber"] CELL["Cellular"] SAT["Satellite"] MESH["Mesh radio"] CARRY["Store and forward"] end APPS -->|"names and hashes"| node node <-->|"requests out, bytes in"| links class VERIFY keystone

Inside one node. Everything arriving from any link passes the verifier, so every source and every link can stay untrusted.

A few rows need more than a table cell.

The physical layer is the one no protocol fixes. has more than 2,000 active member nodes, and in Catalonia reported more than 37,000 in 2021. radios running can carry text across kilometers with no infrastructure at all, at about one kilobit per second on the default preset. Starlink adds a physically different path to more than 12 million customers, though it is one company's network. No single option is enough, and it doesn't need to be, because nothing above this layer cares which link carried the bytes. For links that come and go, the in RFC 9171 already defines store-and-forward delivery, and a hash is just as verifiable when it arrives a week late by on a USB stick.

routing is improving on its own. About 69% of routed now have records saying who may announce them, but by 's measurement only about 27% of users sit behind networks that drop routes failing that check, and , which would validate the rest of the path, is still an IETF draft. Key-derived sidestep the question for the traffic that uses them, because nobody can answer for an address without holding the key it was derived from. They can run on top of today's internet now and move onto other links as those appear.

Identity is the layer my original sketch was missing entirely, and it's where the degradation actually lives. A hash proves the bytes haven't changed since someone named them. It says nothing about whether a person wrote them. When most traffic is automated and half of new articles are generated, the scarce thing is knowing who stands behind a piece of content. Signing keys give content an author that can be checked, and a , the people I trust plus the people they vouch for, lets me decide which authors to listen to without a platform deciding for me. Where an institution's word is needed, W3C became a Recommendation in May 2025. For media, content credentials attach signed at capture, and Google's Pixel 10 signs every photo its camera app takes. Key management is the honest weak point, and are the evidence that it can be made invisible to ordinary people.

Persistence is the quiet one. Content addressing makes every copy interchangeable, but someone still has to keep a copy, which IPFS calls . A 2023 study found the assets behind about a quarter of Ethereum contracts were no longer accessible. Libraries worked out a version of this problem long ago. , started at Stanford in 1999, has libraries hold copies of the same material and periodically vote on hashes of it, and a library whose copy is outvoted treats it as damaged and repairs it from the others. , which the same Zooko worked on with Brian Warner, uses to split each file into ten pieces so any three can rebuild it, and the storage providers can neither read nor alter what they hold. Spread pieces across many holders and let institutions choose what to keep, and no single host's failure or business decision can make a file disappear.

What's true today

None of this replaces the internet today, and I'd rather say that plainly. Yggdrasil describes itself as an alpha-level research project. SCION's specifications and Multipath QUIC are still waiting on publication. The most widely used content-addressed network loses its maintainers in eight days. A LoRa mesh moves text at about a kilobit per second, and a cold fetch with no hints still costs seconds.

What's missing is mostly assembly. Nearly every fix above already runs in production somewhere: signed mirrors at Debian, multipath on the iPhone, transparency logs enforced by Chrome, operator-chosen blocklists in email, hash voting among libraries, hash-plus-hint links in BitTorrent. Nobody has put them in one stack whose defaults don't point every new node at a single organization.

What I think is realistic is a network that degrades gracefully. On a good day it rides the existing internet as an overlay, and content addressing makes it faster there, because any nearby copy is as good as the origin. On a bad day it falls back to local peers and whatever links still work, slower but still verifiable. That second mode is the whole point, and it only works if the keystone is in place before the bad day comes.

stateDiagram-v2 direction LR Overlay: Overlay on today's internet Local: Local peers and mesh Carried: Store and forward [*] --> Overlay Overlay --> Local: backbone or big services fail Local --> Carried: links come and go Carried --> Local: links return Local --> Overlay: internet restored

Graceful degradation. The same names and hashes work in every mode, and only the speed changes.

I also have to be honest about my premise. The pipes have proven more resilient than the services built on them. Cables get cut and traffic routes around them. The outages that actually hit people, Dyn in 2016 and Cloudflare and AWS in 2025, came from concentration at the naming and hosting layers. That is where independence buys the most, and it happens to be where content addressing and self-certifying names do their work.

The idea outlasted the parts

I started with a list of products. Most of them turned out weaker than the idea underneath. IPFS drifted back toward the cloud providers it was meant to route around, and the blockchain naming systems either stalled or went looking for ICANN's approval.

The idea held, and it carried the fixes with it. If the name proves the content, the road stops mattering, so you can have as many roads as you're able to build. Where more roads stop helping, relationships take over, because those are the one thing a botnet can't manufacture. Every layer I'd build now applies one of those two moves. I don't know whether the internet we have gets taken over. I do know the next one can be built from parts that already work, and I want it to be the kind you can check.

A New Layered Internet

A New Layered Internet

What a takeover would actually look like

Why content addressing is the keystone

The through-line: trust problems become redundancy problems

Where the first sketch breaks, and how to fix it

Latency: real on a cold fetch, and payable

Sybil attacks: detect them, then lean on relationships

IPFS re-centralized, so make every piece replaceable

Naming: DNS as the introduction, keys as the identity

Multipath works when the paths differ in kind

Abuse: moderation that composes

The stack, assembled

What's true today

The idea outlasted the parts

Sources

The threat

Content, latency and discovery

Naming

Transport and routing

Abuse, identity and persistence