The Lost Art of Internet Protocols
This post was written in early 2012, when the internet landscape was quite different. At the time, websites were becoming increasingly bloated with Flash content and heavy JavaScript, mobile responsiveness was still a major challenge, and SOPA/PIPA legislation threatened internet freedom. Social media was dominated by Facebook and Twitter, and "Web 2.0" was still a meaningful term.
Since then, many of the author's concerns proved prescient. We've seen the rise of platform monopolization, continued protocol stagnation despite technologies like WebRTC and HTTP/2, and growing awareness of how much the modern web's complexity costs users. The recent interest in decentralized protocols (ActivityPub, IPFS, Nostr) and the push for simpler, faster web experiences echoes many arguments made here over a decade ago.
A long time ago, on an operating system far, far away...
It was a period of protocol war.
Raw text connections sent
over the internet had
gained a strong following.
During this time, greater
needs and complexity arose
eventually leading to the
wide adoption of the hyper
text transport protocol
Knowledge of how the web worked
on these lower levels soon
vanished. It is up to you to
learn the old ways and restore
freedom to the internet...
There's something we lost when HTTP became the only game in town. Before the web browser dominated everything, the internet was a diverse ecosystem of protocols, each designed for specific purposes. We had telnet for raw connections, Gopher for clean content delivery, and text-based worlds that fostered creativity in ways the modern web struggles to match.
Understanding these "old ways" isn't just nostalgia. It reveals how much richer the internet could be, and why our current web-centric approach may be holding us back.
What Telnet Taught Us
Telnet gets a bad reputation today, dismissed as an insecure relic. But calling it just "telnet" misses the point—we're really talking about the foundation of all internet communication: sending raw text over TCP/IP. Every protocol, from HTTP to SMTP to IRC, builds on this simple concept.
This simplicity was educational. When you connected to a server via telnet, you weren't hidden behind layers of abstraction. You typed commands, got responses, and understood exactly what was happening. The internet wasn't a magic box that rendered HTML into pretty pictures. It was a conversation between computers using plain text.
The Rich World We Abandoned
Multi-User Worlds
One of the most engaging examples of pre-web internet culture was Multi-User Dungeons (MUDs, MOOs, MUSHes, and MUCKs). Born in the mid-1970s, these text-based virtual worlds had no graphics or special encodings. Just a stream of text that created immersive experiences for hours.
What made them special wasn't the technology, but the culture. Many MUD servers exposed programming languages to players. You could log in, write code that manipulated the game world, and watch other users discover and interact with your creations. We had user-generated content as the focus of the internet in the 1970s, decades before "Web 2.0" claimed to invent the concept.
I ran one of the most popular sites focused on Message Parsing Interpreter (MPI) when I was twelve. Players would write complex interactive objects and export that code to other servers. The Discworld MUD, based on Terry Pratchett's novels, has been online for almost 20 years with 50-150 players logged in at any time. These communities built lasting social connections around shared creativity and imagination.
Pure Content Delivery
Before HTTP conquered everything, we had Gopher: a protocol designed to deliver pure content without design chrome or spam. The Gopher manifesto reads like a post-mortem now, but its vision was compelling: just the knowledge, without the sparkling prettiness of bad web design and ad-filled "news" sites.
Gopher would have made our current "mobile site" problems irrelevant. When you're only delivering content rather than layouts, backgrounds, animations, and advertisements, everything works everywhere. It's tragic the protocol died, because had it evolved with the same effort as HTTP, we might have a cleaner internet today.
The few remaining Gopher servers exist in near-stasis since 1991, but they demonstrate what we lost: instant access to information without visual noise or commercial interruption.
Why HTTP Won (And What We Lost)
HTTP's dominance wasn't accidental. The web browser provided a unified interface for multiple protocols, solving real interoperability problems. Instead of needing different software for every service, users could access everything through one application.
But this convenience came with costs. We stopped innovating at the protocol level and started forcing everything through HTTP, regardless of whether it was the right tool. Today we have SOAP monsters and RESTful APIs trying to recreate functionality that specialized protocols handled more elegantly.
The deeper loss was educational. When protocols were visible and diverse, technically curious people learned how the internet actually worked. Now those mechanisms are hidden inside browsers, creating a generation that sees the internet as magic rather than engineering.
The Knowledge Gap
Most people don't understand internet protocols because they've been abstracted away. This isn't because protocols are complicated—SMTP is simple enough that you can manually send emails by typing commands. The complexity is hidden, tucked inside software that "just works."
This knowledge gap has serious implications. When politicians propose blocking DNS or making encryption illegal, those who understand the internet's architecture immediately recognize how misguided these policies are. But that understanding is becoming rare, concentrated among a shrinking group of specialists rather than being widely distributed.
Understanding protocols also reveals possibilities. If you know that HTTP is just text commands like "GET /Resource," you realize you could create something similar. The internet isn't a closed system. It's an open platform for experimentation.
What We Could Build
Imagine internet protocols designed for today's needs rather than retrofitted into HTTP:
- Efficient content delivery: Pre-computed DOM trees instead of HTML documents that require additional resource requests
- Batch communication: Multiple documents sent simultaneously rather than the current request-response cycle
- Purpose-built interfaces: Discussion protocols that work naturally in text environments, unwrapped from web browser chrome
- Structured data: Native JSON protocols instead of encoding everything in markup
- Academic publishing: Direct TeX format delivery for mathematical and scientific content
We don't pursue these possibilities because HTTP's inertia is massive. But that doesn't mean enthusiastic hackers can't reclaim some of that experimental spirit.
The Path Forward
I'm not suggesting we abandon the web. HTTP solved real problems and enabled unprecedented global communication. But we shouldn't let its success prevent us from exploring alternatives for specific use cases.
The protocols that built the early internet were designed by people who didn't know what was impossible. They experimented freely, creating tools that served distinct purposes rather than trying to make one protocol do everything.
Today's internet giants understand this. They've moved beyond HTTP for internal systems, using specialized protocols for performance and functionality. The rest of us are stuck in browsers, accepting the limitations of a document delivery system pressed into service as a universal application platform.
Learning these older protocols isn't just historical curiosity—it's preparation for building the next generation of internet tools. When you understand that the internet is bigger than the web, you start seeing possibilities that browser-based thinking misses.
The internet belongs to those who understand it. The more people who learn these fundamentals, the more likely we are to see real innovation rather than endless variations on HTTP-wrapped services.
Start with telnet. Pick a simple protocol like SMTP or IRC. Write a basic client. See how much you can accomplish with just text and creativity. The internet is still out there, waiting for the next generation of protocol pioneers.