Speaker 1: Welcome to tech Stuff, a production from iHeartRadio. Hey there,
Speaker 1: and welcome to tech Stuff. I'm your host, Jonathan Strickland.
Speaker 1: I'm an executive producer with iHeartRadio and how the tech
Speaker 1: are you? It is time for a tech Stuff classics episode.
Speaker 1: This episode is called What Was Gopher? And it originally
Speaker 1: published on April nineteenth, twenty seventeen. Hope you enjoy and
Speaker 1: you guys have been crushing at sending tons of suggestions
Speaker 1: my way, and I just want to say I really
Speaker 1: appreciate it. So remember, if you have a suggestion for
Speaker 1: a topic I should cover, send me the message the
Speaker 1: emails text stuff at hellstuffworks dot com. But this week's
Speaker 1: listener mail episode comes to us from Ryan, who says,
Speaker 1: please do an episode about the Gopher protocol, such a
Speaker 1: different approach to utilize the Internet that no one knows today.
Speaker 1: And so today we're gonna walk back in Internet history
Speaker 1: and learn all about the Gopher protocol. But first it
Speaker 1: kind of benefits us to remember what exactly the Internet is.
Speaker 1: And trust me, this is important in the grand scheme
Speaker 1: of things. But I'll be nice and high level and
Speaker 1: brief about it, so when you get down to it,
Speaker 1: the Internet is essentially just a bunch of computing devices
Speaker 1: that are all connected to each other, and that's it. Really.
Speaker 1: There's a lot of infrastructure there that allows this to happen,
Speaker 1: but ultimately it's a bunch of computers that are talking
Speaker 1: to each other. It's a network of networks using various
Speaker 1: types of connections and protocols to send and receive communications.
Speaker 1: But when you just break it down to its simplest
Speaker 1: of terms, you're really talking about a bunch of interconnected machines. Now,
Speaker 1: broadly speaking, we can classify most of these machines as
Speaker 1: either servers or clients. Now there are other machines as well,
Speaker 1: like route and switches and stuff, but I'm mostly talking
Speaker 1: about the devices that are directly communicating with each other
Speaker 1: rather than the ones that facilitate that communication. So as
Speaker 1: a server, well, it does exactly what it sounds like.
Speaker 1: It does. It serves information. Clients request information. So your
Speaker 1: smartphone or your computer or your tablet that you use
Speaker 1: to serf the Internet or read email or whatever it
Speaker 1: is you do online, that is a client. The servers
Speaker 1: are the machines that contain all the information you're looking
Speaker 1: at and serve it up to you. And the Internet
Speaker 1: is older than the World Wide Web. A lot of people,
Speaker 1: probably not as many today as were around for like
Speaker 1: the late nineties, but a lot of people would equate
Speaker 1: the World Wide Web with the Internet, like the two
Speaker 1: are synonymous, and that's not really true. The Web is
Speaker 1: really just a layer on top of the Internet. It's
Speaker 1: an interface that makes it easy to access and interact
Speaker 1: with information, but it's just one part of the Internet.
Speaker 1: Before it came along, people were facing a bit of
Speaker 1: a challenge. So imagine you've got this network of networks.
Speaker 1: Information is on thousands of servers around the world. You
Speaker 1: want to get access to some specific information, like a
Speaker 1: very particular file. There's one file that you want to get,
Speaker 1: But how do you track down that file? How do
Speaker 1: you know which computer out there in this vast network
Speaker 1: of networks. How do you know which one actually holds
Speaker 1: the file you want. You can't just scream out, hey,
Speaker 1: I need this one text file. You've got to know
Speaker 1: where it is in order to retrieve it. So the
Speaker 1: way this would work normally is that you'd send a
Speaker 1: message from your computer across the network to the specific
Speaker 1: server in question. So ideally you would know what computer
Speaker 1: hosts your file, and you would use some method of
Speaker 1: connecting to that server. Maybe you're using telnet, maybe you're
Speaker 1: using FTP file Transfer protocol, but you're using something to
Speaker 1: send a message to that server and then return the
Speaker 1: server responds to you, and then you request access to
Speaker 1: that file. It's really just that the message you send
Speaker 1: is just a request for information stored on that server.
Speaker 1: And if you have access authorized access to that information.
Speaker 1: In other words, if it's not protected by like a
Speaker 1: password or something that you don't have, the server would
Speaker 1: send that information back across the internet to you. But
Speaker 1: what happens if you don't know which computer holds the
Speaker 1: information you want, how do you get access to it?
Speaker 1: Back in the old days, this would be kind of
Speaker 1: like picking up a telephone to call somebody. Let's say
Speaker 1: you're trying to call me, only you don't have my
Speaker 1: phone number. I never gave it to you. I'm not
Speaker 1: listed anywhere, so how do you call me? There are
Speaker 1: millions of phone numbers out there. If you knew my
Speaker 1: phone number, everything would be just fine because you could
Speaker 1: just dial it directly. But since you don't know my
Speaker 1: number and there's no directory to consult, you're faced with
Speaker 1: a nearly impossible task. What do you do, just start
Speaker 1: randomly hitting buttons until the right person picks up. Well,
Speaker 1: that was the problem facing the Internet. It arose because
Speaker 1: the network became more complicated. Just as in the old days,
Speaker 1: you might have very few telephones in a single town.
Speaker 1: Like I'm talking the real old days. When telephones first
Speaker 1: became popular, you didn't need to worry about phone numbers.
Speaker 1: Maybe three people in town had a phone. These days
Speaker 1: you got to worry about it because millions of people
Speaker 1: have phones. Well, same thing was true with the network
Speaker 1: of networks. As more computers came online, as more systems
Speaker 1: joined the Internet, it became more difficult to track very
Speaker 1: specific stuff down. So before the Internet, there was a
Speaker 1: sort of a precursor, not really the Internet. Before there
Speaker 1: was an Internet, but it was a system of networked
Speaker 1: computers called ARPA NEET now the arpenet. That was a
Speaker 1: project from the Department of Defense in the United States
Speaker 1: and was something that required a bunch of computer scientists
Speaker 1: to sit down and work out protocols. It was essentially
Speaker 1: a big but relatively simple network of computers. Now I
Speaker 1: say simple because if you look at the Internet by
Speaker 1: comparison as a network of networks. It is far more
Speaker 1: complex than what Arpenet was, but I am not casting
Speaker 1: aspersions on arpenet. It was still incredibly sophisticated, particularly for
Speaker 1: its time. It allowed people working on different computers that
Speaker 1: used different operating systems, different languages, the ability to communicate
Speaker 1: with each other. And that's phenomenal because usually, you know,
Speaker 1: these are like computers that if you were to connect
Speaker 1: directly to one another, they would not be able to
Speaker 1: communicate with each other. They were fundamentally different. So they
Speaker 1: designers of the ARPINET had to figure out a set
Speaker 1: of rules that all these different types of computers could
Speaker 1: follow in order to exchange information with one another. So
Speaker 1: that required a lot of work to create these protocols
Speaker 1: or sets of rules to facilitate communication. And I've talked
Speaker 1: about arpinet before. If you want to hear a lot
Speaker 1: more about it, you can track down the classic episode.
Speaker 1: It originally published in twenty twelve. It was titled Happy
Speaker 1: Fathers of the Internet Day and then Chris Palette and
Speaker 1: I talked a lot about the people who designed the
Speaker 1: various protocols that allow Internet communication to happen. Well, anyway,
Speaker 1: two of the protocols in question during the days of
Speaker 1: ARPINET were the Transmission Control Protocol or TCP, developed in
Speaker 1: nineteen seventy five, and the Internet Protocol or IP in
Speaker 1: nineteen seventy eight. These are almost always grouped together whenever
Speaker 1: anyone talks about Internet protocols, they'll say TCPIP, But they
Speaker 1: are technically two different sets of rules that together end
Speaker 1: up guiding the computers on how to communicate across this
Speaker 1: network of networks. These are the rules that gave arpnet
Speaker 1: that ability to create global communication across various different computers.
Speaker 1: The two protocols were officially adopted by ARPINET in nineteen
Speaker 1: eighty three, so while they were developed in the seventies,
Speaker 1: it wasn't officially adopted until nineteen eighty three. Now, they
Speaker 1: were being used before that, but you know, ARPINET was
Speaker 1: a government thing, and just like you would suspect, it
Speaker 1: moves super fast because it's government. Well, the following year
Speaker 1: nineteen eighty four, a lot of things happen. We got
Speaker 1: that really killer Apple Mac commercial that was like the
Speaker 1: Orwellian nineteen eighty four that was phenomenal. But also Sun
Speaker 1: Microsystems unveiled a system called the Network Filing System or
Speaker 1: NFS that was sort of like a file directory and
Speaker 1: storage system for networked computers running on a heterogeneous Unix environment.
Speaker 1: So you had to have a bunch of computers running
Speaker 1: the same Unix implementation essentially, or same version I guess
Speaker 1: I should say not implementation, but the same version of
Speaker 1: Unix across all these different machines. And it was kind
Speaker 1: of like your basic file management system you'd have on
Speaker 1: a personal computer. So if you've ever used a computer
Speaker 1: that had a variation of this, like Windows File Explorer
Speaker 1: is a good example. You typically have a hierarchy of files.
Speaker 1: You'll have like a top level selection of files. If
Speaker 1: you go into one of those, you might see folders,
Speaker 1: like sub folders underneath that main heading. Go into that one,
Speaker 1: you'll see more sub folders, maybe some files, that kind
Speaker 1: of stuff. Well, it was essentially that, but for an
Speaker 1: entire network of computers. So you could share information between
Speaker 1: diferent computers on the system by saving files to this
Speaker 1: network drive, something that's very familiar to most of us today,
Speaker 1: but back then was really new. And then obviously you
Speaker 1: could retrieve files from the appropriate directory on that same system.
Speaker 1: Also in nineteen eighty four, a team over at Carnegie
Speaker 1: Mellon University released the Andrew File System or AFS. Now. Originally,
Speaker 1: the AFS provided Carnegie Mellon students a campus wide file
Speaker 1: directory system, and later on a company called Transarc sort
Speaker 1: of spun off and turned this into a commercial product. Now,
Speaker 1: these file systems allowed users to access files on other computers,
Speaker 1: but they also came with a really steep learning curve.
Speaker 1: If you weren't particularly computer savvy, it was really challenging
Speaker 1: to navigate through these file directories. It would be kind
Speaker 1: of like taking someone to a computer and it has
Speaker 1: all line commands and the person had never really worked
Speaker 1: with a line command interface. They'd only worked with graphics
Speaker 1: by line command. I mean, you have to type in
Speaker 1: the command and file names you want in order to
Speaker 1: access stuff. Well, if that's what you've been doing the
Speaker 1: whole time, it's not so bad. You start to pick
Speaker 1: up on it. Even as new systems are brought on,
Speaker 1: you can kind of adapt to it pretty quickly because
Speaker 1: you already have that basic level of knowledge. But for
Speaker 1: someone brand new to computers, it was really intimidating. It
Speaker 1: felt like you needed to have a lexicon of different
Speaker 1: commands at your disposal all the time, and a lot
Speaker 1: of people would have to use cheat sheets and take
Speaker 1: a look at those constantly so that they could figure
Speaker 1: out just how to navigate a computer. It wasn't very
Speaker 1: user friendly, and it was really hard to find what
Speaker 1: you were looking for if you didn't already know where
Speaker 1: to start from the beginning. The trick with filing systems
Speaker 1: is that you have to understand the organizational strategy. So
Speaker 1: not only do you have to understand the language to
Speaker 1: navigate the system, you also have to understand the person
Speaker 1: who set it up in the first place. So there's
Speaker 1: a bit of machine savvy you have to have, but
Speaker 1: there's also how well do I know the person who
Speaker 1: set up this filing system and how does that person's
Speaker 1: brain work, Because maybe they'll set things up in a
Speaker 1: different way then I would set it up, and if
Speaker 1: I were to try and navigate using my common sense,
Speaker 1: I might find it frustrating. So here's an example of
Speaker 1: what I mean. Back in the day, I used to
Speaker 1: organize all of my DVDs by genre and then by
Speaker 1: alphabetical order by title. So I had all my action
Speaker 1: films in one place, I had all my horror movies
Speaker 1: in another place, all my Tim Curry movies were together
Speaker 1: all that kind of thing. You know, Tim Curry is
Speaker 1: a genre unto himself National Treasure. But if you didn't
Speaker 1: know that I did that, and you didn't know where
Speaker 1: one section began or ended, you could have trouble finding
Speaker 1: a specific title. Maybe you would have had a totally
Speaker 1: different approach. You would have organized everything alphabetically from the start,
Speaker 1: so it didn't matter what genre is, and you would know,
Speaker 1: all right, well, the title i'm looking for starts with
Speaker 1: a D, so I need to find the d's and
Speaker 1: it's going to be there. Or maybe you would even
Speaker 1: have a more crazy organizational strategy, maybe you would organize
Speaker 1: everything chronologically by release date, which would confound everyone but
Speaker 1: the geekiest of film buffs. The point is that these
Speaker 1: file systems back in the day, with these network drives,
Speaker 1: they weren't always intuitive. Even if you weren't immediately put
Speaker 1: off by the interface, you might still not be able
Speaker 1: to find what you're looking for. Now. Later still came
Speaker 1: Alan Mtaje's Archie tool, and he was a University of
Speaker 1: Montreal employee student. You know, he had gone from one
Speaker 1: to the other really when he invented this tool to
Speaker 1: search for files on the Internet that would be transferred
Speaker 1: via FTP file Transfer Protocol. So instead of requiring the
Speaker 1: user to know a direct path, you just had to
Speaker 1: know the name of the file, how was the file named. Now,
Speaker 1: that still isn't ideal, because I'm sure you've encountered files
Speaker 1: that had weird or non intuitive names that may have
Speaker 1: had nothing to do with what the file actually was about.
Speaker 1: So you had to know precisely how the file was
Speaker 1: named or else it really didn't do you any good.
Speaker 1: But at least it didn't require you to also know
Speaker 1: the full path name of where a file was, and
Speaker 1: it allowed you to actually do a search across the Internet. Now,
Speaker 1: once the Web came along, and I'll talk a lot
Speaker 1: more about the World Wide Web later on in this episode,
Speaker 1: and once programmers began building search engines, this problem became
Speaker 1: less difficult. Right. Search engines started to make things much
Speaker 1: easier for people. The web made navigation more intuitive. It
Speaker 1: made it more accessible to people who weren't experienced with
Speaker 1: computers or had inside knowledge of directory organization. But in
Speaker 1: those in between times before the web up, but after
Speaker 1: the Internet came online, that's when Gopher emerged. Now, there
Speaker 1: were several developers behind Gopher. Really six people in total,
Speaker 1: and one of the more important ones I shouldn't even
Speaker 1: say it that way. One of the leads, I should say,
Speaker 1: because all six were important. One of the leads was
Speaker 1: Mark McHale, and Mkale attended the University of Minnesota. Actually
Speaker 1: they were all part of the University of Minnesota, but
Speaker 1: he had attended as a student, earning a bachelor's degree
Speaker 1: in chemistry in nineteen seventy nine. But while he earned
Speaker 1: his degree in chemistry, he would actually go on to
Speaker 1: join the campus microcomputer Center as a programmer, and by
Speaker 1: the late nineteen eighties he was leading a team of
Speaker 1: programmers and together they built an email client called pop mail,
Speaker 1: first for the Macintosh computer and then later on for
Speaker 1: the PC platform. The POP in pop mail stands for
Speaker 1: post Office Protocol. So the way worked was that you
Speaker 1: had a server that would kind of act like a
Speaker 1: virtual post office. You would whenever you were checking email
Speaker 1: or sending email, it would involve a virtual visit to
Speaker 1: this post office. You could drop off and receive mail there.
Speaker 1: So if you wanted to send a message through your
Speaker 1: popmail client, the client, as in your computer, the workstation
Speaker 1: you are using, would relay the message through the post
Speaker 1: office server, which would then direct the message onto your destination.
Speaker 1: When retreating messages, you would actually be going to this
Speaker 1: popmail server to pull the emails off of it in
Speaker 1: order to read them. So they were the ones who
Speaker 1: developed this, and it was a very popular type of
Speaker 1: way of getting a hold of email. The next big
Speaker 1: project that this team tackled was creating an interface for
Speaker 1: navigating the university's local network. So the question was, how
Speaker 1: can we find whatever we're looking for? How do we
Speaker 1: organize all this information we have in a way that
Speaker 1: makes sense because they could see that the Internet was
Speaker 1: creating this incredible opportunity to share information, but it was
Speaker 1: getting increasingly difficult to find stuff and to organize stuff
Speaker 1: properly because there were more and more computers coming onto
Speaker 1: the system and it just made things even more complicated.
Speaker 1: So together Mikhail Bob Alberti, Farad Anklesaria, Paul Linda, and
Speaker 1: Daniel Tory began to work to develop a solution, and
Speaker 1: as it turned out, their solution had applications far beyond
Speaker 1: the campus they worked on. In fact, it would turn
Speaker 1: out their solution had applications outside of the campus they
Speaker 1: worked on before it actually was implemented by the campus itself.
Speaker 1: It would work across the Internet in general. Now I'm
Speaker 1: going to jump into what they did in just a second,
Speaker 1: but before I do that, let's take a quick break
Speaker 1: to thank our sponsor. So the team got to work
Speaker 1: in nineteen ninety one. They knew that they wanted a
Speaker 1: system that could organize information in an intuitive way, giving
Speaker 1: users an opportunity to navigate the information they needed quickly.
Speaker 1: They wanted it to be a client server system. This
Speaker 1: was really important to them. What they perhaps the biggest
Speaker 1: decision they made, the most important one to them, was
Speaker 1: to not go a centralized mainframe organizational strategy. They wanted
Speaker 1: to get away from mainframe computers. They saw that the
Speaker 1: future was in desktops. But desktop machines, especially in ninety one,
Speaker 1: were slow, they had relatively limited capabilities, so whatever system
Speaker 1: they created had to be optimized for these less powerful machines.
Speaker 1: They also wanted to make this system scalable, with options
Speaker 1: to have various departments register servers with a top level server.
Speaker 1: So in other words, you could have different departments having
Speaker 1: their own networks, but have them linked to the main
Speaker 1: network so that you can navigate throughout all of these
Speaker 1: different systems, and that way, if you connected to that
Speaker 1: top level server, you could navigate to any lower department
Speaker 1: through a master menu. They also wanted the tool to
Speaker 1: be efficient and lightweight, meaning they didn't want it to
Speaker 1: tax those normal PCs and workstations. They didn't want a
Speaker 1: tool that would move at a snail's pace, and that
Speaker 1: was one of the reasons that they really focused on
Speaker 1: text based communications, because it doesn't require a whole lot
Speaker 1: of data to send text, and it meant that it
Speaker 1: could be relatively fast and informative. They also decided that
Speaker 1: the server would not retain states. Now that means that
Speaker 1: the server wouldn't need to keep a record of all
Speaker 1: the different information requests from multiple clients. Once a connection closed,
Speaker 1: the state was white, and it would close the connection
Speaker 1: after every transaction. Essentially, so together they worked on this
Speaker 1: tool and they decided to call it Gopher. The name,
Speaker 1: by the way, serves many purposes. For one, the mascot
Speaker 1: of the University of Minnesota is the Golden Gopher, Minnesota
Speaker 1: is the Gopher state. Also, the idea of a metaphorical
Speaker 1: gopher appealed to them. Gopher's tunnel and in a way,
Speaker 1: the Gopher protocol kind of tunnels through networks. They also
Speaker 1: started to refer to the networks that were using Gopher
Speaker 1: as Gopher space. And finally, gophers also the term for
Speaker 1: someone who runs errands and fetches things because the gopher
Speaker 1: will gopher like coffee or you know, you can go
Speaker 1: for snacks, that kind of stuff. The Classic Muppet Show
Speaker 1: series had Scooter who was a gopher. There were a
Speaker 1: lot of jokes about that about how Scooter was a
Speaker 1: gopher by job, but he wasn't a gopher by critter,
Speaker 1: like he was not the actual animal gopher. Anyway, here's
Speaker 1: the weird thing. So the team knew they were onto
Speaker 1: something when they designed Gopher, but it didn't get a
Speaker 1: lot of traction right out of the gate despite its utility,
Speaker 1: because the University of Minnesota they just didn't see how
Speaker 1: this would be useful. They didn't see the value in it,
Speaker 1: so they didn't really put any support behind it, and
Speaker 1: they didn't implement it at all. So the team decided
Speaker 1: to sidestep all that red tape, and one of the
Speaker 1: team members uploaded the software to an FTP server and
Speaker 1: then posted a message on an Internet mailing list saying, hey, guys,
Speaker 1: we developed this kind of cool tool. We think it
Speaker 1: is a great way to organize information on networks and
Speaker 1: allow people to find stuff. Give it a try. So
Speaker 1: people began to download it and put to use, and
Speaker 1: not long after that it started to take off. A
Speaker 1: lot of places were using it and they decided that
Speaker 1: it made a whole lot of sense, and eventually the
Speaker 1: University of Minnesota administration relented and implemented Gopher as well
Speaker 1: on their campus. Now let's go ahead and talk about
Speaker 1: Gopher implementations and what it was actually like. So there
Speaker 1: were two main ways you could interact with Gopher. One
Speaker 1: of them was to install software on your computer. And
Speaker 1: this is looking at interacting with Gopher as a user
Speaker 1: as opposed to as an administrator. So you want to
Speaker 1: use Gopher, well, one thing you could do is install
Speaker 1: software on your computer, and this was a client side
Speaker 1: Gopher application, which really is not that different from a
Speaker 1: web browser like Firefox or Chrome or Safari. It's essentially
Speaker 1: a similar thing. It's a program that runs on your
Speaker 1: computer that acts as the interface for this protocol. Those
Speaker 1: are all client side applications, just like the Gopher one was.
Speaker 1: But you didn't have to do that. What you could
Speaker 1: do instead is use a Telnet application. Telnet was another
Speaker 1: old protocol that's still used in some places. Tel Net
Speaker 1: would allow you to virtually log in to another terminal,
Speaker 1: and you just had to have the correct address and
Speaker 1: port number and everything in order to tell Net into
Speaker 1: that room. So you could use Telnet to log onto
Speaker 1: a remote server and use the server side Gopher client
Speaker 1: to access directories. And in that case, all the work
Speaker 1: is being done by the server and you don't have
Speaker 1: to actually have a client based application on your side.
Speaker 1: The style of the Gopher client really dependent upon its implementation.
Speaker 1: The team wanted to make sure that it was customizable,
Speaker 1: but it was always simple. There's always text based. It
Speaker 1: could be extremely simple where all you have are text
Speaker 1: options under a menu, or it could have some very
Speaker 1: primitive kind of graphic user interface elements in it. Graphic
Speaker 1: user interface also known as GUY but less what's the
Speaker 1: right word, less impressive or extensive as what you would
Speaker 1: find in the World Wide Web later. And there were
Speaker 1: two worlds in the Gopher verse, the world the client
Speaker 1: could see and the world the server worked with. So
Speaker 1: on the server side, every item within a Gopher directory
Speaker 1: would have certain elements to it, and that included a
Speaker 1: client visible name, a selector which was usually something that
Speaker 1: used the path name that would connect the server for
Speaker 1: location purposes. Then there would be a host name which
Speaker 1: would tell the top level server which computer actually contained
Speaker 1: the file in question, and an IP port number. Ports
Speaker 1: are kind of like telephone lines, so a computer I
Speaker 1: had to know which port it should use when contacting
Speaker 1: other computers. Now on the client side, on the user side,
Speaker 1: only those client visible names would show up. Everything else
Speaker 1: would be hidden. And to use an analogy, imagine that
Speaker 1: you go to a party and it's one of those
Speaker 1: super hip, geeky tech parties that I assume happened but
Speaker 1: I never get invited to anyway. Everyone gets a little
Speaker 1: name tag, and the name tag just has the person's
Speaker 1: name on it. That's it. That's the only information about
Speaker 1: the person that is visible to the average attendee. So
Speaker 1: when you walk around the party, you can see each
Speaker 1: person's name, but that's it. But let's say you're a
Speaker 1: super duper awesome VIP at this party, and all the
Speaker 1: super duper awesome VIPs at this particular party get a
Speaker 1: little swag bag that has a pair of smart glasses
Speaker 1: in them, and if you put the smart glasses on,
Speaker 1: you see projected above the name tag of each person
Speaker 1: more information, and it tells you where that person lives,
Speaker 1: what their phone number is, tells you about their favorite
Speaker 1: lunch spots. In other words, you know a few different
Speaker 1: ways you could reach those people if you needed to. Well,
Speaker 1: in the gover verse, that sort of same approach was
Speaker 1: applying but only to files, not to people, so there
Speaker 1: wasn't anything creepy going on. But Mikail and his group
Speaker 1: decided that users didn't need to see all the extra information.
Speaker 1: They don't need to know where a file is on
Speaker 1: a network. They don't care. They don't care if the
Speaker 1: file they want is on computer A or computer B.
Speaker 1: They just want access to that file. So they decided
Speaker 1: that all of that excess information would be invisible to
Speaker 1: the user. It would still be there for the servers
Speaker 1: because the servers would need to know where everything was
Speaker 1: in or to direct users to the right location, But
Speaker 1: to the users themselves, they don't care, So get rid
Speaker 1: of it, and ended up being a much more elegant
Speaker 1: system that way. So let's say you've logged into a
Speaker 1: college campus Gopher server because the tool was originally developed
Speaker 1: for colleges. So what would you actually see if you
Speaker 1: did this, Well, you'd start off with a menu of options.
Speaker 1: It's kind of like a table of contents, and that
Speaker 1: would allow you to explore different areas of the Gopher
Speaker 1: verse more thoroughly. A typical top level menu might include
Speaker 1: and by the way, I'm taking this largely from a
Speaker 1: request for comments that Mikhail and his group created in
Speaker 1: order to discuss what Gopher is, what it was meant for,
Speaker 1: and how it works. The first item might be something
Speaker 1: like about Internet Gopher, and it would literally just be
Speaker 1: that little phrase, and if you selected that one, it
Speaker 1: would open up something that would allow you to learn
Speaker 1: more about Internet Gopher. It would pull the files that
Speaker 1: could tell you about the version and Gopher in use
Speaker 1: and how best to navigate it. It may even tell
Speaker 1: you about the site administrator. And in fact, in that
Speaker 1: original request for comments, they suggested that every administrator for
Speaker 1: a Gopher server include his or her name, email address,
Speaker 1: and phone number so that you could get in contact
Speaker 1: with them should something go wrong. Yikes. Obviously, this was
Speaker 1: in the days when very few people comparatively speaking, were
Speaker 1: using an Internet tool. Because you could just imagine how
Speaker 1: much traffic you would get from various emails and phone numbers.
Speaker 1: If you just put your actual address out on a
Speaker 1: major website, that would be tough. The next element on
Speaker 1: this Gopher list might be something like around the campus,
Speaker 1: and that could include more directories that give you links
Speaker 1: to files about various areas of campus. You might get
Speaker 1: some menus of different options. For example, at University of Georgia,
Speaker 1: if I saw around the campus on a Gopher site
Speaker 1: and I clicked on that, it might take me to
Speaker 1: a couple of different sub menus, one for North campus
Speaker 1: and one for South campus, because the University of Georgia,
Speaker 1: at least at the time when I was attending it
Speaker 1: was roughly divided into North and South campuses. Another option
Speaker 1: might say courses, schedules and calendars, which would obviously take
Speaker 1: you to information about the classes offered by that college
Speaker 1: and when they happen, as well as a list of
Speaker 1: campus events throughout the year, and so on and so forth.
Speaker 1: Those are just the kind of basic table of content
Speaker 1: stuff you would see, and again it's all text based.
Speaker 1: Typically the options on any list would have indicators to
Speaker 1: let you know if you were looking at the name
Speaker 1: of a file or if you were looking at the
Speaker 1: name of another directory. So again, in an example given
Speaker 1: from that RFC paper that was written back in nineteen
Speaker 1: ninety three, the group showed directories as being followed by
Speaker 1: an ellipses and files were not. So if it said
Speaker 1: campus schedule with no ellipses, then you knew that clicking
Speaker 1: on that would give you a file with the schedule
Speaker 1: on it if you chose that option. But if you
Speaker 1: were looking at a list that said college activities dot
Speaker 1: dot dot, you knew that the dot dot dot that
Speaker 1: ellipses indicated that it was a link to another directory.
Speaker 1: So if you clicked on college activities, you would get
Speaker 1: another menu that would subdivide up college activities. Maybe it
Speaker 1: would be sports, after school activities, it might be extracurricular
Speaker 1: student groups, that kind of thing. Now, Gopher's design allows
Speaker 1: other servers to interact with a top level server, so
Speaker 1: it didn't have to just be a single computer running
Speaker 1: all of this information. In fact, that was beside the point.
Speaker 1: The whole purpose of this was to allow multiple servers
Speaker 1: to connect with each other and create an overall strategy
Speaker 1: for navigation to allow students or other users to learn
Speaker 1: more information so you could have say the Computer Science
Speaker 1: department server registered under a top level option for the
Speaker 1: entire university, and the English department could have its own server,
Speaker 1: and the Math department could have its own server, and
Speaker 1: so on and so on. So each departmental server would
Speaker 1: further point down the chain to specific files relevant to
Speaker 1: that department. And Gopher also included the ability to stack,
Speaker 1: meaning that you could actually retrace your steps, which is
Speaker 1: kind of like hitting the backbar or the back button
Speaker 1: rather on a browser. So if you went down one
Speaker 1: path and then decided, hey, I need to see something
Speaker 1: else that was further back in my browsing, you could
Speaker 1: back up the pathway until you got to that specific
Speaker 1: fork and then take the other fork. And that was
Speaker 1: actually pretty innovative in the early nineties. It wasn't like
Speaker 1: it was something that they were copying from other people.
Speaker 1: Unlike today's websites, the information on Gopher pages tended to
Speaker 1: remain fairly static, which actually was also a huge help
Speaker 1: for Gopher space. You didn't have to update things quite
Speaker 1: so frequently. Occasionally you might need to update a file,
Speaker 1: or you might need to add a file to a server,
Speaker 1: but that didn't happen at the frequency we see today
Speaker 1: on the web, there weren't a lot of dynamic pages
Speaker 1: out there. It was important for Gopher to be able
Speaker 1: to adapt to changes and evolving conditions, so the team
Speaker 1: designed a system that it would allow them to update
Speaker 1: files and path names and pieces so that you didn't
Speaker 1: have to do a full update of the whole system regularly.
Speaker 1: You could just focus on whichever sections had new information
Speaker 1: and just update those bits. Everything else could remain the same.
Speaker 1: That sped everything else up, Like if you are only
Speaker 1: making changes to two percent of your network, then there's
Speaker 1: no reason to update all one hundred percent. They could
Speaker 1: save time by just updating that two percent. They also
Speaker 1: made another very clever choice. They recommended that all top
Speaker 1: level servers have a clone and that way, if one
Speaker 1: server were to fail for whatever reason, another one could
Speaker 1: take over the job. Also, if you had a really
Speaker 1: busy network, you could have both servers acting at the
Speaker 1: same time, sharing the loads. So some users are using
Speaker 1: server A, some users are using server B, but both
Speaker 1: of them are identical. They have complete navigational tools to
Speaker 1: go through the whole network, and so it doesn't really
Speaker 1: matter which one you land on as a user, it's
Speaker 1: going to be the same experience, and since most of
Speaker 1: the files remain static, you didn't really have to worry
Speaker 1: about the two top level servers getting out of sync.
Speaker 1: They would be pretty much ready to go all the time.
Speaker 1: I mean, occasionally you'd have to update at least parts
Speaker 1: of the system, but it was pretty manageable, especially in
Speaker 1: those early days before things got super complicated now. The
Speaker 1: team also suggested that all registered servers in a system
Speaker 1: have an alias that the Gopher client could use to
Speaker 1: locate those servers, and this way the client would know
Speaker 1: each registered server by its alias, rather than the server's
Speaker 1: primary name, which was more or less unchangeable. Now why
Speaker 1: would you want to have an alias, Well, the reason
Speaker 1: was to improve portability. So if as an administrator, you
Speaker 1: decided that you needed to move files from one server
Speaker 1: to another server, that could be a huge headache because
Speaker 1: it would mean having to update all these different path
Speaker 1: names so that your top level machine knows where everything is. Now, right,
Speaker 1: if you had to say, oh, well, instead of being
Speaker 1: on this machine, it needs to be on this machine.
Speaker 1: I've got to update all these different files and these
Speaker 1: different path names so that people navigating the system will
Speaker 1: get to where they need to go using the alias
Speaker 1: was actually a very clever idea to get around this.
Speaker 1: Clients wouldn't require an update or any alteration. They don't
Speaker 1: need to know that computer one, which used to be
Speaker 1: known as Bob, has gone offline and now computer two
Speaker 1: has all of computer one's stuff. Instead, the administrator would
Speaker 1: just name computer two Bob. They would give computer two
Speaker 1: the alias of the old computer one, and then the
Speaker 1: clients would just end up going to computer two because
Speaker 1: they're not looking at one or two, They're just looking
Speaker 1: for Bob, and if computer two is Bob, now that's
Speaker 1: where they go. It was an ELI solution, particularly once
Speaker 1: network's got really complex. Now, the brilliant thing behind Gopher
Speaker 1: is that the end user didn't need to know any
Speaker 1: of this. That didn't matter to them. They just needed
Speaker 1: to have a simple interface to interact with. They needed
Speaker 1: to be able to see the choices they wanted to
Speaker 1: make a choice and follow that pathway, and it was
Speaker 1: very similar to kind of a choose your own adventure book.
Speaker 1: As long as the directories were clear and organization of
Speaker 1: the information made sense, it was easy to use. And
Speaker 1: then there was the killer app, the ability to search.
Speaker 1: So to search on Gopher, you had to set up
Speaker 1: an actual Gopher search server, it would be its own
Speaker 1: purpose was to essentially have all the different files that
Speaker 1: are connected to that particular Gopher space indexed, and these
Speaker 1: servers could perform full text searches in all the files
Speaker 1: on all the registered servers in that Gopher space. So,
Speaker 1: by default, search queries assumed that if you were to
Speaker 1: type in multiple words, the spaces between those words were
Speaker 1: an and in boolean logic. In other words, if you
Speaker 1: typed in Spanish dance in the query field, so you
Speaker 1: just have Spanish space dance, the search would actually assume
Speaker 1: what you are saying is give me all the files
Speaker 1: that have both the words Spanish and dance in them.
Speaker 1: Files that didn't meet that criteria would not be returned.
Speaker 1: So if there was a file that had the words
Speaker 1: Spanish in it, but dance never appeared in that file,
Speaker 1: you wouldn't get it. Same thing if it were dance
Speaker 1: but Spanish was never there, you wouldn't get it. Now,
Speaker 1: this structure only worked with servers that were registered to
Speaker 1: the same system, So these Gopher spaces were kind of
Speaker 1: like islands in the ocean. You could connect Gopher spaces together,
Speaker 1: you could end up registering the servers of different Gopher
Speaker 1: spaces so that they made larger networks, and that would
Speaker 1: allow users to navigate from one system of servers to another.
Speaker 1: But that wasn't necessarily the aim of Gopher. So if
Speaker 1: I did a search on a Gopher space for a
Speaker 1: specific term, like again at UGA, if UGA was its
Speaker 1: own contained system, its own network of servers throughout the campus,
Speaker 1: but none of those had connections to other campuses, I'm
Speaker 1: not going to find files that are stored at the
Speaker 1: University of Minnesota because the two systems are distinct. I'll
Speaker 1: only find files that are on UGA system. So it
Speaker 1: was a little different from the World Wide Web. It
Speaker 1: had these again, these kind of islands of information. Well,
Speaker 1: I've got some more to talk about, including the rise
Speaker 1: and fall of Gopher itself, but before I get into
Speaker 1: that section, let's take another quick break to thank our sponsor.
Speaker 1: All Right, we're talking about the nineteen nineties. Now, the
Speaker 1: Internet was still pretty darn young back then, especially an
Speaker 1: Internet that was accessible to people beyond the computer science field,
Speaker 1: and no one was really sure what it would evolve
Speaker 1: into in those early nineties. In nineteen ninety two, the
Speaker 1: Internet Engineering Task Force or IETF held a meeting in
Speaker 1: San Diego, and they invited McHale and also Anklesaria to
Speaker 1: come out and to speak to the group as a
Speaker 1: whole about the work they were doing with Gopher now.
Speaker 1: The meeting included a whole bunch of different important figures
Speaker 1: in Internet history, including Tim berners Lee, who is the
Speaker 1: guy who pioneered the World Wide Web. He built the
Speaker 1: first web page at CERN, that's the same organization that
Speaker 1: runs the Large Hadron Collider. So berners Lee was there
Speaker 1: to talk about his approach to Internet navigation using what
Speaker 1: he called the web and hypertext, which I'm sure you're
Speaker 1: familiar with because that's what everybody uses today. He also
Speaker 1: was very interested in trying to find a way for
Speaker 1: the Web and Gopher to work together. The folks over
Speaker 1: at Gopher they were looking at berners lee approach to
Speaker 1: navigation and they said, well, this doesn't make any sense
Speaker 1: using hypertext of different words to leap to connected but
Speaker 1: distinct ideas. That makes an organization impossible. It's like the
Speaker 1: opposite of what we're doing. We're trying to create hierarchies
Speaker 1: of information, and the web is a web. It's all
Speaker 1: this interconnectivity. So they never really got to work things
Speaker 1: out with berners Lee, something that they said in retrospect
Speaker 1: perhaps was a mistake, but they didn't know that at
Speaker 1: the time. No one was short at the time whose
Speaker 1: approach was going to work out best. So it was
Speaker 1: as a weird experience, right. And besides, the web programmers
Speaker 1: learned about other means of accessing and navigating the Internet.
Speaker 1: There were other ones like a Prospero and waste or
Speaker 1: wais so be. Clifford Noyman and was the pioneer behind Prospero,
Speaker 1: which was meant to create personalized directories of the Internet
Speaker 1: in response to user queries, so he could organize information
Speaker 1: and allow users to search grouping resources together so that
Speaker 1: users didn't have to go down several different individual paths
Speaker 1: and just hope for the best. Ways stood for Wide
Speaker 1: Area Information Server. It was a text searching system that
Speaker 1: could look for specific strings of text on files on
Speaker 1: a server, retrieving any hits that it might find. And
Speaker 1: so it was also very different from the Gopher approach
Speaker 1: or the Prospero approach. It was a pretty basic strategy
Speaker 1: to search and retrieval. So at this gathering, Mikhail discovered
Speaker 1: that people already knew a lot about Gopher. He thought
Speaker 1: he was going out there to tell people about a
Speaker 1: system that he had developed and kind of launched the
Speaker 1: year before. But everyone there seemed to really be familiar
Speaker 1: with it. A lot of them were running their own
Speaker 1: Gopher servers. They were really curious to hear more about
Speaker 1: the team behind Gopher. The software had spread rapidly because
Speaker 1: of its easy implementation and interface, and adoption was incredible.
Speaker 1: By nineteen ninety three, Gopher's traffic growth rate hit nine
Speaker 1: hundred ninety seven percent. Now that definitely sounds astronomical, but
Speaker 1: keep in mind percentages are tricksy. For example, if I
Speaker 1: sold one newspaper in a week, and then the following
Speaker 1: week I sold ten newspapers, I'd have a growth sales
Speaker 1: rate of nine hundred percent. So while nine hundred ninety
Speaker 1: seven percent growth is spectacular, we're not talking about enormous numbers.
Speaker 1: By April nineteen ninety four, the number of Gopher servers,
Speaker 1: or at least the ones that the team was aware of,
Speaker 1: had hit just under seven thousand servers. But Gopher did
Speaker 1: have a big head start on the web. It took
Speaker 1: the web a bit longer to catch on because you
Speaker 1: had to have the development of the clients that people
Speaker 1: could use to browse the web, and you had to
Speaker 1: have the development of the actual software people were using
Speaker 1: to create web servers. Gopher was popular enough for the
Speaker 1: team to start to hold conferences of their own called
Speaker 1: Gopher cons. They even created t shirts and merchandise with
Speaker 1: the Gopher logo on it. Colleges and companies were adopting it.
Speaker 1: Even the White House launched a Gopher site back in
Speaker 1: those days. But hot on the heels of Gopher was
Speaker 1: the Worldwide Web concept, which had its own compelling methods
Speaker 1: of navigating and presenting information. Even though it seemed non
Speaker 1: intuitive to the Gopher group, it turned out that people
Speaker 1: really like it. Anyone who spent a lot of time
Speaker 1: on a site like Wikipedia dancing from one topic to another,
Speaker 1: just diving down those rabbit holes, they know what I'm
Speaker 1: talking about. Someone, ironically, I would say Tim berners Lee
Speaker 1: actually was able to spread the word about the World
Speaker 1: Wide Web using a Gopher site. That's how people were
Speaker 1: able to get the files they needed to create web
Speaker 1: servers and web clients, as well as find more information
Speaker 1: about the web itself. And the Gover team was running
Speaker 1: into problems with the University of Minnesota as well. The
Speaker 1: administration was always something of a reluctant partner with this group.
Speaker 1: At first, the college had been a roadblock. You remember
Speaker 1: I mentioned they refused to implement Gopher in those early days.
Speaker 1: They only did it after it had already been implemented
Speaker 1: at other college campuses. Members of the gover development team
Speaker 1: were looking at the possibility of creating a private entity,
Speaker 1: like a spinoff company, to create Gopher as a commercial product.
Speaker 1: But back in those days, the Internet was still largely
Speaker 1: the domain of universities and government offices. In fact, a
Speaker 1: lot of people looked at the possibility of private enterprise
Speaker 1: getting involved with the Internet as something they did not want.
Speaker 1: A lot of people kind of compared it to public broadcasting.
Speaker 1: They said the Internet should remain like PBS and all
Speaker 1: these companies. That's like ads supported TV. We don't want
Speaker 1: that here. So there was a lot of resistance even
Speaker 1: among the group themselves. It's not everybody was in agreement
Speaker 1: that they should go the privatizer route. And remember the
Speaker 1: dot com era had not yet begun at this point. Then.
Speaker 1: The University of Minnesota instituted a licensing policy for Gopher.
Speaker 1: They said that any organization out there that was operating
Speaker 1: for profit would need to pay a license fee to
Speaker 1: the University of Minnesota in order to use Gopher, and
Speaker 1: the cost of this license fee was sliding. It depended
Speaker 1: upon the size and type of business in question, and
Speaker 1: the university was looking to keep all that money for themselves,
Speaker 1: really i Meanwhile, the development team found that the university
Speaker 1: still wanted them to do their regular desk jobs as
Speaker 1: programmers for the University of Minnesota, so they were supposed
Speaker 1: to both develop Gopher and work on their normal jobs,
Speaker 1: and they weren't really given any more resources to do this.
Speaker 1: It was still just the six of them, so their
Speaker 1: morale began to decline. And then they had the university
Speaker 1: expecting them to do these two jobs at once, as
Speaker 1: well as having an entire population of users out there
Speaker 1: who were angry about this licensing policy that the university
Speaker 1: has had put in place, and the team was kind
Speaker 1: of caught in the middle, and at one point, the
Speaker 1: university even considered outsourcing Gopher to other programmers, essentially taking
Speaker 1: it away from the team that created it and giving
Speaker 1: it to someone else. Meanwhile, the web was just getting started.
Speaker 1: Remember that I said, Gopher grew by nine hundred ninety
Speaker 1: seven percent back in nineteen ninety three. Well, the web
Speaker 1: also grew that year by three hundred forty one thousand,
Speaker 1: six hundred thirty four percent. I was also the first
Speaker 1: year of the commercial web browser, Mosaic. Mosaic proved that
Speaker 1: you could go commercial on the Internet. So while the
Speaker 1: Gopher group was reluctant the website, things were going in
Speaker 1: a very different direction, and the web was incorporating stuff
Speaker 1: that Gopher couldn't really support, like images on web pages. Now,
Speaker 1: as an image on a web page was not a
Speaker 1: huge asset because it took forever to render a picture
Speaker 1: on a screen, and it caused some people to say
Speaker 1: that WWW actually stood for worldwide Weight. But modem speeds
Speaker 1: were on the rise as well, and that helped reduce
Speaker 1: some of that loading time, And some of the Gopher
Speaker 1: team rather sardonically said, we knew the game was up
Speaker 1: when we realized that people could get naked photos on
Speaker 1: their computer screens using the World Wide Web, something that
Speaker 1: you could not be done with Gopher, and they were
Speaker 1: being pretty serious about it at the time. By the
Speaker 1: spring of nineteen ninety four, web traffic exceeded Gopher traffic.
Speaker 1: So even though Gopher had a headstart, Web had caught
Speaker 1: up and passed Gopher traffic. Companies were discovering that there
Speaker 1: were some possibilities on the web, though really web commerce
Speaker 1: was still a couple of years away from really taking off,
Speaker 1: but it offered opportunities beyond just sharing information, which was
Speaker 1: really the only thing Gopher was good for was really
Speaker 1: sharing information and distributing files. It wasn't meant to do
Speaker 1: really more than that. So the web had versatility on
Speaker 1: its side as well. And one of the big things
Speaker 1: that helped drive the knife home and Gopher had nothing
Speaker 1: to do with how people use the Internet. It had
Speaker 1: to do with a scandal unrelated to anyone on the
Speaker 1: Gopher team. Doctor John Nigerian, a transplant surgeon at the
Speaker 1: University of Minnesota, was accused of fraud, tax evasion, and embezzlement.
Speaker 1: The charges led the National Institutes of Health, which is
Speaker 1: a federal government office here in the United States, to
Speaker 1: withdraw funding to the university, and that was a serious
Speaker 1: blow to the school, so they went to emergency mode
Speaker 1: to try and fix the situation. They, as part of that,
Speaker 1: asked the Gopher team to create a new system to
Speaker 1: track accounts and file paperwork, because a large part of
Speaker 1: this accusation really dealt with the way paperwork was failing
Speaker 1: to be filed on time. So the team eventually developed
Speaker 1: a web based transaction program, which is also kind of
Speaker 1: ironic when you think about it. That was a web
Speaker 1: based approach. It was the world's first web based transaction program.
Speaker 1: But it also meant that while they were developing this,
Speaker 1: they could not continue working on Gopher because they just
Speaker 1: didn't have the time to do it. So by the
Speaker 1: time they finished the web based application, Gopher was dead
Speaker 1: in the water, or I guess dead under the ground,
Speaker 1: I suppose, if we want to stick with the metaphor anyway,
Speaker 1: It's not really dead dead. It's not entirely gone. There
Speaker 1: are still Gopher servers out there if you know where
Speaker 1: to look. But as an evolving entity, Gopher was essentially
Speaker 1: a thing of the past, and at some point ten
Speaker 1: no one's really sure when someone took the original Gopher
Speaker 1: server known as Mother Gopher, offline. The University of Minnesota
Speaker 1: supported it for several years after Gopher had clearly lost
Speaker 1: the race to the web, but that is no longer
Speaker 1: the case, as for Michael. He would go on to
Speaker 1: join Duke University, where he still works today, and other
Speaker 1: members of the team have gone on to do other things.
Speaker 1: Some of them retired, some of them album's working for Google.
Speaker 1: One of them stayed with the University of Minnesota, oh
Speaker 1: And doctor Nigerian, who was accused of those crimes, was
Speaker 1: ultimately exonerated of those accusations of fraud and embezzlement. The
Speaker 1: jury returned with a verdict of not guilty, but by
Speaker 1: then the damage was done in more ways than one.
Speaker 1: Gopher had faded away due to lack of support, and
Speaker 1: the university found itself struggling to regain the trust of
Speaker 1: the nih And that was the Textuff Classics episode What
Speaker 1: Was Gopher, which originally published April nineteenth, twenty seventeen. I
Speaker 1: hope you enjoyed that episode. For the older listeners out there,
Speaker 1: let me know if you used Gopher. I mean, some
Speaker 1: of the younger ones may have too. It's just less likely,
Speaker 1: I think, but yeah, let me know if you is
Speaker 1: Gopher and your thoughts on it. I would love to
Speaker 1: hear from you, and I hope you are all well
Speaker 1: and I will talk to you again really soon. Tech
Speaker 1: Stuff is an iHeartRadio production. For more podcasts from iHeartRadio,
Speaker 1: visit the iHeartRadio app, Apple Podcasts, or wherever you listen
Speaker 1: to your favorite shows.