You're fifteen years old, it's two thousand five, and you've just discovered FileZilla. You type in an IP address, username, password — no padlock in the corner, no certificate warnings, nothing. The files move. It works. You don't think about it again for twenty years. That protocol you were using — RFC nine fifty-nine, the File Transfer Protocol — was published in nineteen eighty-five. It predates the web. It predates most of the people who now warn you never to use it. And here's the thing: it's still not formally deprecated. You can fire up plain FTP right now and move data between two hosts. Every security professional on earth would tell you not to — but the IETF has never actually pulled the plug.
Daniel's been thinking about this, and he sent in a three-part puzzle. Part one: why does plain FTP still technically exist while something like Gopher was officially retired just two years ago? Part two: SSH was born in the same era as Telnet — why has it only grown more indispensable instead of being replaced? Part three: what happens when AI agents, not humans, become the primary consumers of these protocols? Because if you think authentication matters now, wait until a single coding agent is opening dozens of SSH connections per minute with no human in the loop.
So let's look at the graveyard, the living museum, and the quiet workhorses that still route the internet.
The scope here is important. We're not talking about TCP slash IP itself — that's deeper in the stack, older than most listeners, and not going anywhere. We're talking about the application and transport layer protocols we interact with directly. FTP, Telnet, SSH, HTTP, Gopher, SMTP. The tools you actually use.
And the core puzzle is genuinely weird. The internet in its modern form is about forty years old. Some protocols from the eighties are being actively retired — the IETF moved Gopher to Historic status in twenty twenty-four, meaning they no longer maintain it. Meanwhile, SSH is getting RFC updates in twenty twenty-five and twenty twenty-six. Same era, completely different trajectories.
So what separates them? Because it's not just age and it's not just security. Gopher wasn't insecure — it was just irrelevant. Plain FTP is wildly insecure and it's still not dead.
Right. I think there are three factors that explain most of what we see. One: technical adaptability — can the protocol evolve without breaking everything that already depends on it? Two: network effects — is there a critical mass of users and tooling that makes replacement impractical? Three: institutional sponsorship — who maintains it, and why do they keep showing up?
Those three things together do a better job of predicting protocol survival than any single factor. And the clearest way to see it is to look at the failures first.
Start with the graveyard then.
Gopher. Released in nineteen ninety-one at the University of Minnesota. It was a document retrieval protocol — hierarchical menus, text-based, very fast for its time. For a brief window in the early nineties, Gopher was more popular than the World Wide Web. Then the university announced they might charge licensing fees for the server software, and the entire user base fled to HTTP practically overnight.
The licensing thing is one of those historical pivot points that doesn't get enough attention. A single administrative decision killed a protocol that was winning.
And it never recovered. Gopher limped along for decades with a tiny enthusiast community, but by twenty twenty-four the IETF formally moved it to Historic status. The final RFC basically says: nobody uses this, we're not maintaining it anymore, it's over.
What's instructive is why. Gopher wasn't insecure. It wasn't badly designed for its era. It failed on network effects — the user base evaporated — and it failed on institutional sponsorship. The University of Minnesota walked away, and no one else picked it up with enough resources to matter.
And then there's Telnet. RFC eight fifty-four from nineteen eighty-three.
Telnet is the zombie protocol. It's dead for general remote access — no encryption, passwords in cleartext, the whole nightmare — but it refuses to fully die because it's embedded in too many places. Serial console access to networking equipment. Legacy industrial control systems. Lab equipment with embedded management interfaces that were manufactured twenty years ago and still work.
I've seen Telnet on brand new enterprise switches. It ships disabled by default now, but the option is there. Some network engineer somewhere is still using it because the script they wrote in two thousand three expects a Telnet session and nobody's paying them to rewrite it.
Telnet survives not because anyone wants it to, but because it's frozen into infrastructure that nobody wants to touch. It's the protocol equivalent of a COBOL mainframe — too expensive to replace, not important enough to modernize, so it just sits there.
Which brings us to the strangest case of all. Plain FTP.
RFC nine fifty-nine. Nineteen eighty-five. Still not deprecated by the IETF. You can download a client right now — FileZilla still supports it — and connect to a server with no encryption whatsoever. Username and password in the clear. Data in the clear. No integrity checking on the control channel.
And yet if you try to visit a plain HTTP site, your browser will put up a full-page warning and maybe refuse to load it at all. The web solved this. FTP didn't.
The reason FTP can't die is also the reason it can't thrive. It has no single owner. There's no upgrade path that preserves backward compatibility. And the security retrofit completely fragmented the ecosystem.
You've got three things now that people call FTP. There's plain FTP — the original, no encryption. There's FTPS — FTP with explicit TLS, which adds encryption but keeps the same problematic architecture. And there's SFTP — which isn't FTP at all, it's the SSH File Transfer Protocol, a completely different protocol that happens to move files.
So if you tell someone to use FTP securely, you have to specify which of three incompatible things you mean. And the original, the one that's actually called FTP, is the insecure one.
That fragmentation is fatal. When the security retrofit splits the user base instead of upgrading it, you lose the network effects. Plain FTP is stable in the worst sense — frozen, not durable. It fails on technical adaptability because the original design is a monolith. The control channel and data channel are tightly coupled. You can't swap out the authentication layer without redesigning the whole thing.
Now contrast with SSH. This is where the story flips completely.
Nineteen ninety-five. Tatu Ylönen is a researcher at Helsinki University of Technology. Someone runs a password sniffer on the university network and captures a bunch of credentials — including Ylönen's. His response is to design a secure replacement for Telnet and the Berkeley r-commands.
The protocol paper was circulated on the IETF mailing list in December nineteen ninety-four. The first release shipped in July nineteen ninety-five. And the architecture he chose is the reason we're still talking about it thirty-one years later.
Walk me through the architecture. What did he get right that FTP got wrong?
SSH separates three things. The transport layer handles encryption and server authentication. The authentication layer handles user authentication — passwords, public keys, whatever method you want. The connection layer handles channels — you can multiplex a shell session, a file transfer, and a port forward over a single encrypted connection.
Those are independent. You can swap out the crypto in the transport layer without touching authentication. You can add new authentication methods without changing how channels work. That modularity is the entire game.
So when SSHv1 had cryptographic weaknesses, they didn't have to redesign the protocol from scratch. They built SSHv2, published it as RFC forty-two fifty-one in two thousand six, and existing deployments could migrate incrementally.
And it kept going. Ed25519 key support got added. The IETF Secure Shell Working Group published a draft on post-quantum cryptography for SSH in early twenty twenty-six — they're working on making SSH resistant to quantum computer attacks before those attacks are practical. There's an August twenty twenty-six draft extending SSH for high-latency space links. Thirty-one years in, and the protocol is still absorbing new requirements without breaking.
Apply the three-factor model to SSH and it's almost a perfect score. Technical adaptability — the modular design made evolution possible. Network effects — every Linux server, every cloud instance, every network appliance ships with an SSH daemon. You cannot build modern infrastructure without it.
And institutional sponsorship. The OpenSSH project — born out of OpenBSD, now community-maintained — has provided continuous stewardship for over twenty-five years. That's not a small thing. Someone has to write the code, review the patches, respond to vulnerability reports, shepherd the RFC updates. OpenSSH has done that without a corporate owner and without fragmentation.
That's the graveyard and the exemplar. But the more interesting story is the one that's still being written — the protocols that refused to die and instead evolved.
And that brings us to the part of Daniel's question that I think is the most urgent. SSH was designed for a human at a terminal. You type a command, you get a response. The authentication model assumes a person typing a password or managing a key pair.
But the dominant use case in twenty twenty-six is machine-to-machine. CI slash CD pipelines. Infrastructure-as-code tools like Terraform and Ansible. Kubernetes cluster management. These aren't humans opening interactive shells — they're automated systems authenticating to other automated systems, often dozens of times per minute.
And now agentic AI is layering on top of that. A single coding agent — the kind of thing you'd use to fix bugs or deploy services — may open SSH connections to multiple hosts in rapid succession. It's not typing commands. It's programmatically establishing sessions, running scripts, transferring files, closing connections.
The SSH agent protocol was originally a convenience feature. You unlock your private key once, the agent holds it in memory, and subsequent connections don't prompt for a passphrase. For a human developer, that saves a few seconds per session.
For an AI agent, it becomes an architectural primitive. The agent authenticates once, and then it can establish connections at machine speed without re-authentication. That's not a nice-to-have — it's the only way the workflow functions at all.
But this also changes the threat model in ways the original designers never anticipated.
Dramatically. Traditional SSH keys are long-lived. You generate a key pair, you put the public key on the servers you need access to, and you rotate it... eventually. Maybe once a year. Maybe never.
I've seen SSH keys in production that are older than some of the junior engineers using them.
Right. And that's fine when a human is using them — the human is the rate limiter. But when an AI agent can open dozens of connections per minute with a long-lived key, the blast radius of a compromised key is enormous. It's not about preventing unauthorized access anymore — it's about managing authorized access at machine scale.
The IETF Secure Shell Working Group has been working on this since twenty twenty-five. The focus is on ephemeral certificates — short-lived SSH certificates tied to workload identities. Something like SPIFFE, the Secure Production Identity Framework for Everyone. The idea is that an AI agent doesn't get a permanent key. It gets a certificate that's valid for minutes or hours, scoped to exactly what it needs, and then it expires.
So the protocol is adapting to a use case that didn't exist when it was designed. That's the technical adaptability factor playing out in real time.
And OpenSSH nine point eight, released in April twenty twenty-six, added built-in session recording. This is a direct response to the machine-scale problem. When a human types commands, you can review the shell history. When an AI agent runs commands across fifty servers in thirty seconds, you need machine-parseable audit logs. The session recording feature makes that possible without third-party tools.
What's interesting to me is that SSH is filling a gap that HTTP-based authentication can't easily cover.
That's the key point. OAuth2, OpenID Connect, mutual TLS — these are designed for web APIs. They're great at what they do. But they're not designed for raw terminal access. They're not designed for port forwarding. They're not designed for multiplexing a shell, a file transfer, and a tunnel over a single encrypted connection.
SSH does all of that. And no HTTP-based protocol has emerged that can replace that multiplexing capability while maintaining the same level of strong authentication. That's a genuine moat.
GitHub figured this out early. They migrated from SSH keys to SSH certificates for machine users back in twenty twenty-three. The pattern is spreading to CI slash CD platforms — short-lived certificates, automated rotation, audit trails that are designed to be parsed by machines, not read by humans.
Which brings us back to the three-factor model, applied forward. If you want to predict which protocols survive the next decade, ask three questions.
One: can the protocol absorb AI-era requirements like ephemeral identities and machine-scale authentication? Two: is it already embedded in the toolchains that AI agents use? Three: is there a community actively maintaining it?
Let's run a few protocols through that lens. HTTP slash three.
Thriving. QUIC-based, actively developed, major browser and server support. It checks all three boxes. HTTP is the substrate of the web, and the web isn't going anywhere.
SMTP.
Stable but stagnant. Email isn't dying, but the protocol hasn't seen a major RFC update since DKIM in two thousand eight. It's frozen in place — not because it's perfect, but because changing email infrastructure is so painful that nobody wants to do it. It survives on network effects alone.
DNS.
Quietly evolving in ways most people don't notice. DNS-over-HTTPS and DNS-over-QUIC are real improvements — they encrypt DNS queries that have been sent in cleartext for decades. The protocol is adapting to privacy requirements without breaking the fundamental lookup mechanism. I'd bet on DNS outlasting most of the protocols we've talked about.
So that three-factor model explains the past. But what happens when we apply it to the present — specifically, to the way AI agents are about to change everything about authentication?
I think we're heading toward a world where the majority of SSH connections are never initiated by a human. And that raises a question the protocol's designers never had to answer: what does authentication mean when there's no human to verify?
Say more about that.
When a human types their password or unlocks their SSH key, there's an implicit verification step. The human is present. They intended to do this. If something goes wrong, they'll notice — eventually.
When an AI agent authenticates with a certificate that was issued automatically by a workload identity system, there's no human in the loop at all. The certificate is valid for ten minutes. The agent uses it, the session gets recorded, the certificate expires. If the agent does something wrong, you find out from the audit log after the fact.
So the security model shifts from prevention to detection and recovery.
And that's a fundamental shift. SSH was originally designed around prevention — keep the bad actors out. But at machine scale, with ephemeral identities, you can't prevent everything. You have to assume that authorized agents will sometimes do unauthorized things, and build the detection and recovery mechanisms into the protocol itself.
The session recording in OpenSSH nine point eight is a step toward that. Machine-parseable audit logs are another. The ephemeral certificate drafts are a third. SSH is evolving from a perimeter defense tool into a zero-trust authentication fabric.
And that's why it's hard to envision the internet without SSH. It's not just that there's no clearly better alternative — it's that SSH has been quietly absorbing new requirements for thirty-one years without anyone really noticing.
The protocol became invisible. That's the real victory. Nobody thinks about SSH when they deploy to AWS or push to GitHub. It just works. The authentication happens, the connection is encrypted, the data moves. The protocol disappeared into the infrastructure.
Which is exactly what a successful protocol looks like. You don't notice it until it breaks.
The ones we notice constantly — plain FTP with its security warnings, Telnet with its cleartext passwords — those are the ones that failed to evolve. They're visible because they're problems.
The protocols that survive aren't necessarily the best-designed. They're the ones that can evolve without breaking the world that depends on them.
SSH's modularity bought it thirty-one years of relevance. The question Daniel's really asking is whether that's enough for the next thirty, when the consumers aren't human at all.
I want to circle back to something you said about the SSH protocol paper circulating in December nineteen ninety-four. The first release was July ninety-five. That's six months from paper to working code.
Ylönen was motivated. Someone had just sniffed his password.
Sure, but it's also a reminder of how fast a well-designed protocol can go from concept to deployment when the architecture is clean. Thirty-one years later, we're still extending that same architecture for post-quantum cryptography and space links. That's not normal.
Most protocols don't survive their first major revision. SSH survived two — the v1 to v2 transition, and now the shift from human-interactive to machine-automated. Each time, the modular design absorbed the change without requiring a ground-up rewrite.
I keep thinking about the alternative universe where the University of Minnesota didn't threaten to charge for Gopher. Gopher was simpler than the early web. Faster. More structured. If they'd kept it free and open, we might be talking about Gopher the way we talk about SSH — an old protocol that quietly evolved and became invisible.
Instead, the user base fled to HTTP, and HTTP became the foundation of everything. Network effects are brutal. Once the critical mass tips, it almost never tips back.
FTP had the network effects. It was the default file transfer mechanism for decades. But the protocol couldn't evolve, so the network effects eroded. People didn't stop transferring files — they just stopped using FTP to do it.
They moved to HTTP-based downloads, to SFTP, to object storage APIs, to a dozen different things. FTP's monopoly on file transfer dissolved because the protocol couldn't keep up with the security requirements.
That's the lesson. Network effects buy you time, but they don't buy you forever. If the protocol can't adapt, the users will eventually find another way to solve the same problem.
Hilbert: Sixteen passwords in two hours.
...Say that again.
Hilbert: Sixteen passwords in two hours. That's what I pulled off the wire in nineteen ninety-nine. I was working sysadmin for a small ISP in Vermont — this is rural Vermont, maybe four hundred customers, dial-up modems, the whole thing. We had one server running Telnet for customer shell access. The owner didn't see the point of SSH. Said it was paranoid. Nobody's going to sniff passwords on our network.
So I ran tcpdump for a weekend. Sixteen passwords. One of them was the root password. I printed the whole thing out and put it on his desk Monday morning.
What did he do?
Hilbert: Told me I was being paranoid. I installed SSH anyway. Took the whole weekend, rebuilt the server, broke a bunch of customer scripts. Got yelled at. Six months later we got hacked — not through Telnet, through some vulnerable CGI script in the customer portal. But I never went back to Telnet after that weekend.
I still have the printout somewhere. In a box.
Of course you do.
Hilbert: The thing is, you said SSH was born in nineteen ninety-five. The first release was July ninety-five, but the paper describing the protocol was on the IETF list in December ninety-four. So it's technically older than most people think. By about seven months.
That's a good correction. December ninety-four to July ninety-five — six months from concept to working code.
Hilbert: Ylönen had just had his password sniffed. You work fast when it's personal.
I still run an SSH server at home. Raspberry Pi in the basement. My wife uses it to check the weather station data. She doesn't know what SSH is. She just clicks a bookmark on her laptop and the numbers show up. That's the real thing you said — when it becomes invisible. She has no idea she's using a protocol from nineteen ninety-five to check if it's going to rain.
The protocol disappeared into the bookmark.
Hilbert: That's the whole job. Make it work so well nobody has to know it's there.
The protocols that survive are the ones that become infrastructure. You don't think about the pipes until they burst.
The ones that stay visible — the ones with warning dialogs and deprecation notices and security advisories — those are the ones that failed to make the transition. They're still asking for attention because they never earned the right to be ignored.
The open question is what happens when the primary consumers of these protocols aren't humans clicking bookmarks, but AI agents that can't even see a bookmark. What does it mean for a protocol to become invisible to a machine?
I think it means the protocol has to be discoverable, negotiable, and self-describing in ways that SSH isn't quite yet. An AI agent needs to know what authentication methods a server supports without a human reading the documentation. It needs to negotiate parameters automatically. It needs structured error messages it can act on programmatically.
Some of that exists in SSH already — the authentication method negotiation, the channel mechanism. But a lot of it is still designed around the assumption that a human will read the error message and figure out what to do.
The post-quantum crypto work and the ephemeral certificate drafts are steps in the right direction. But I wonder if we'll eventually need protocols designed from scratch for machine-to-machine authentication — protocols that assume no human will ever see the handshake.
Or SSH will just keep absorbing requirements through modular evolution, the way it has for thirty-one years, and we'll wake up in twenty fifty-five still using it.
I wouldn't bet against SSH. It's survived everything so far.
If you want to dig into the actual RFCs, we'll link the SSH post-quantum draft and the Gopher retirement notice in the show notes. And if you have a protocol you think should have died but somehow didn't — send it to us. We might do a follow-up.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop for keeping the show running, and for the tcpdump printout that I want to see someday.
Find us at my weird prompts dot com. We'll be back soon.
