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