https://www.robinsloan.com/lab/bad-hosts/ Home About New: Shadow Planet From: Robin Sloan To: the lab Sent: February 2022 Bad hosts, or: how I learned to stop worrying and love the overlay network A warm scene of a party in a cozy lounge, everyone in suits and gowns. Viggo Johansen, An Evening Party in the Artist's Home, 1889 Concluding my notes on Web3, I wrote that Ethereum should inspire anyone interested in the future(s) of the internet, because it proves, powerfully, that new protocols are still possible. and, accepting my own admonition, I have been tinkering on a new pro tocol -- simple and, shall we say, "hypermedia-ish"--that I hope will be interesting to others. More on that later this year. Today, I want to document a realization that struck along the way. The modern internet has rendered the figure of "an individual hosting a small internet service, all on their own" as antique as a blacksmith; this, I sorta knew. But where before I might have called it a matter of ergonomics or motivation, I now understand that it's deeper in the network. Really, I'm talking about just two things: IPv4 addresses and NAT. IPv4 addresses are the ones you know, with four blocks of digits; Google's is 142.250.189.206. There are 4.3 billion possible addresses of this kind ... which isn't nearly enough for all the computers that want to connect to the internet in 2022. The remedy, or hack, has been Network Address Translation, familiar to any home internet user: your modem and router are assigned a pub lic IPv4 address, reachable from anywhere on the internet, while your laptop and your phone -- and everything else connected in your home -- get a local address, a classic like 192.168.0.3 or 10.0.0.7. In this way, your router can use its single IPv4 address to "cover" all the computers in your home. When you open a website, issuing an HTTP request to that web server, the router uses NAT to relay its response to your laptop, rather than the Apple TV. Ah, but what if I sent an HTTP request to your public IPv4 address? It would arrive at your router, which wouldn't have any idea where to send it -- your laptop? the Apple TV? the refrigerator? -- and would, confused and/or suspicious, drop or refuse my request. NAT as one-way mirror. Critics of centralization will eagerly describe the centripetal forces sucking everyone and everything into the big platforms. Those forces are real! However, there ARE centrifugal forces -- political, moral, creative, artistic -- pushing back out, toward the edges ... it's just that those countervailing forces are cancelled almost totally by NAT. It's not impossible to host a small internet service from a computer in your home, but it does take some fairly intense tinkering and maintenance, so it remains the pastime of ... the fairly intense. Brit tle router admin is no match for the sleek, there-it-is seduction of a big platform and/or a cloud datacenter. Honestly, though, I am starting to think 50% of the ease and power of centralization is just a stable, public IPv4 address. This is all coming out of my own experience, my own thought experiments, as I sketch out protocols and apps, "ways of relating" across a network; and every time I muse about something decentral ized, I bump up against this barrier: a person connected to the inter net from home cannot host a small service of their own. There are workarounds for NAT, ubiquitous hacks, but they all require centralized intermediaries. Think of video chat. While we're chatting, the video is flowing straight from my computer to yours -- in a sense, we are each hosting a small internet service for each other! But we can't initiate that connection ourselves. It requires a third host, one with a public IPv4 address. That host "punches a hole" through our NAT layers and ties us together. The connection is ephemeral. Our video chat ends, and my Wi-Fi router's heart flutters, and you are lost to me again. The workarounds are fine as far as they go, but NAT tricks can't get us the one thing we really want, the foundational internet thing: the ability to simply listen for connections. Therefore, whole classes of possible services and relationships don't exist; a whole alternate internet history. As home internet users, we can only speak and request, not listen and serve. Computers with the ability to listen on the internet are called "hosts", and there's an interesting etymological implication there. Today, as home internet users, we are not hosts; and perhaps we are missing out, therefore, on a degree of etiquette, and conviviality, and satisfaction. I find it melancholy: all these powerful computers, my laptop and yours, not to mention the servers in my office, your supercomputer smartphone -- they could be doing interesting things together, shut tling data around in interesting ways. Back when most (of the rela tively few) internet users could host freely, none of them had a giga bit connection at home; now, many internet users have bandwidth and processor cycles to spare, but we can't host. Technological irony. What of the dream of IPv6? This is the newer scheme in which computers have longer addresses written with hex digits; Google's IPv6 address is 2607:f8b0:4005:812::200e. One of the great upsides of IPv6 is that there are more than enough addresses for every computer connected to the internet, so every com puter could be reachable from anywhere -- no NAT required. But, the rollout of IPv6 across the internet has been stubbornly slow. Computers support it -- odds are very good your phone and laptop speak IPv6 with perfect fluency. It's the home internet providers that have been conspicuous laggards; I get internet from both AT&T and Sonic, and neither of them support IPv6. I truly did not have an opinion on IPv6 before December 2021. Suddenly, I am a wild-eyed evangelist, because this scheme, which works and is widely supported but not widely deployed, supports an internet in which every computer can be a host, if it wants to be. For my part, I think an IPv6 internet would be almost unimaginably fertile and productive. New kinds of apps and services would bloom like weeds and wildflowers in a dry meadow after the rain. Ohhh welllll --------------------------------------------------------------------- The rise of "overlay networks" is a natural response to the limita tions and frustrations of the public IPv4 internet, and I think their acceleration in the last few years deserves more attention. These are illusory networks established on top of the public internet. Often, you install a small program on your computer, and it allows other applications to "see" a group of other computers as if they were right there on your local network, even if they're far away, deep in NAT hell, forsaken by the public internet. Here, I'll make it more concrete: For years, I was vexed by the task of reliably reaching the two servers in my office from anywhere outside, e.g. from home. The office doesn't have any fancy network hardware, just a Wi-Fi router, and the best I could manage was a brittle port-forwarding scheme that never worked for more than a couple of months at a time. Then I discovered ZeroTier, which allows you to create and manage these overlay networks. I installed it on my laptop, my old iMac, my two servers, as well as an EC2 instance, and ever since, I have hopped between them with ease, no matter where I am. Each computer has a stable IP address in the 10.0.0.0/8 range, reserved for private networks. It's fabulous. They are all hosts again. There's a similar service called Tailscale, along with Slack's some what more robotic Nebula, and I'm sure a ton more. I am the only inhabitant of my ZeroTier network, and I get the sense a lot of people use it that way, but both ZeroTier and Tailscale allow you to create overlay networks with many users -- hundreds or more. In those cases, the networks become little virtual internets for your coworkers, your group of friends, your pirate armada, whatever. ZeroTier's founder Adam Ierymenko sometimes calls the service a "planetary data center", with the implication that it ought to feel like every computer is in the same building, regardless of its actual location or network disposition. Along the same lines, one of Tailscale's founders, David Crawshaw, has a blog post, actually quite moving, titled Remembering the LAN. He writes: The LAN was a magical place to learn about computers. Besides the physical aspect of assembling and disassembling machines, I could safely do things unthinkable on the modern internet: permission-less file sharing, experimental servers with no security, shared software where any one machine could easily bring down the network by typing in an innocuous command. Even when I did bring down the network the impact never left the building. I knew who I had to apologize to. These new (old) "networks within networks" are, in 2022, both useful and evocative, and I think they open some VERY interesting space for work on peer-to-peer protocols and "ways of relating"--I keep writing that, I know it's vague -- that unfold on a "mini-internet" of only 50 or 100 people. I mean, you know I love computing at this scale. But, as cool and promising as the overlay networks are, I am not will ing to sacrifice "public" entirely, because what is the internet, if not an open invitation? And a suggestion, recurring, that you might not already know all the people you want to know. (If you've found your way to this newsletter, this web page, then you understand what I mean.) Again, I feel the resonance of the word "host", and again, I think about etiquette, and conviviality, and satisfaction. --------------------------------------------------------------------- There's also the peer-to-peer browser called Beaker, a powerfully cen trifugal project; the idea is, or was, that your browser might host a website as easily as it navigates to one. Very 1993! (Thanks to David for prompting this addition.) Its successor/inheritor/whatever, a protocol called Hypercore, nudges in the same direction. It's interesting: when you look at the code, you discover that it's like, all clever NAT negotiation, which, again, I find melancholy: so much time and energy and creativity, burned just to "get back to zero" on the internet, re-establishing the ability to listen. I mocked something up using Hypercore's great implementation of a peer-to-peer DHT swarm, the same technique (PDF) used to coordinate, among other things, the nodes of the Ethereum network. (There are rel atively few Ethereum nodes -- on the order of thousands.) It's an interesting and evocative technology, but/and, I found it really "heavy", and, call me greedy or unreasonable, but I just want the sim plicity of socket.listen which, when it works on the public internet, has decentralization built in. --------------------------------------------------------------------- My interest in all of this is a bit odd-angled, because I don't actu ally care about decentralization that much; or, I think it's inter esting, but I think a lot of things are interesting, and I'm willing to weigh them against each other, make some compromises. TONS of compromises. What I'm really interested in -- what I dream about -- is the opportu nity to play with new protocols without taking on, perforce, the burden of infrastructure. If we cast our gaze back to the early days of the World Wide Web, we find all these people coming up with cool new ideas for HTTP and HTML, writing new server software and new browsers with new features ... and very conspicuously not "operating the web". They didn't have that power or that burden. The web was ... out there. Pretty good deal if you can get it. Defining a protocol is challenging enough; programming a client appli cation more challenging still; but backing up the database? I am just terminally uninterested in that kind of work -- and stress. This, too, is part of Web3's appeal: you can invent new things with out running the infrastructure that supports them. Of course, it trades that stress for a new kind, the madness of immutable code, and charges you for every computation -- so, for me, it's a wash. --------------------------------------------------------------------- I have no great conclusion to offer, and I'm sure most of this is old news to those of you who have tangled with peer-to-peer protocols before. I guess the surprise, for me -- the thing I felt an urge to share -- was the realization that at least some of this tendency towards centralization is inherent in the present architecture of the internet itself. The trapdoor of IPv4 exhaustion delivered us to this place, stuck behind NAT, pounding on the door. It's a huge bummer! I should add, as a coda, that ZeroTier has an interesting offering, a set of public networks that anyone can join. Each only allows access to a particular range of ports -- you can choose -- via IPv6, which works for everyone, because it's virtualized through ZeroTier's soft ware; it's "fake IPv6", I guess. These networks are a lovely affordance, and there's a world in which your instruction manual for my new protocol begins with: "Step 1. Download ZeroTier and join pub lic network X." Voila, the NAT problem goes away; it's 1993 again; we can all see each other. The thing that stops me from doing this, for now, is the lingering sense that, come on, there must be a way to offer something interest ing that is not woven into the infrastructure and protocol of a par ticular company. But who knows! I might get over it! February 2022, Oakland I'm Robin Sloan, a fiction writer. You can subscribe to my lab newsletter here: [ ] [Subscribe] This website doesn't collect any information about you -- not even basic analytics. It aspires to the speed and privacy of the printed page. Don't miss the colophon.