A Conversation on the Early Days of Online Communication

When Ron was 12 years old, he first ventured into the online world, where he could communicate with "new" people from faraway places, play online games, and even set up his own BBS. Not content with the existing communication methods, he developed BBSNet and his own real-time chat system, which not only benefited many users at the time but also influenced his future work on video technology and network protocols.

In 1992, Ron released his "nv" (Network Video), a groundbreaking video conferencing tool that allowed users to send and receive videos over the Internet. Building on this innovation, he co-authored the Real-time Transport Protocol (RTP), a fundamental protocol that forms the backbone of real-time audio and video streaming on the Internet.

In the interview, Ron said that the projects he is most proud of are those that involved creating and fostering interpersonal connections between people and helping them to collaborate with one another.

And all of this became possible from the day he first went online.

▮ The Nexus: Could you please share your first experience of going online? 

Ron Frederick: At age 11, I got my first computer. It was a TRS-80 Model I, sold by Radio Shack. By that time, I had already gotten quite familiar with the TRS-80 by playing with the demo model Radio Shack had set up in their store for a year or two, so I knew exactly what I wanted to order. When I first got the machine, I didn’t get the support for connecting to other computers, but a year or so later I bought a serial (RS232) adapter card and my first modem. This allowed me to connect to other computers via telephone.

Ron Frederick at age 11

Back then, the typical modem speed was 300 baud, which was quite slow. It worked out to about 30 characters per second, meaning that sending one screenful of text took about 30 seconds, and this was on a machine where the screen could only display around 1,000 characters! Despite the slowness, though, there was something magical about being able to access another computer that could be almost anywhere in the world.

  TRS-80 Model I 

(By Rama & Musée Bolo - Own work, CC BY-SA 2.0 fr, https://commons.wikimedia.org/w/index.php?curid=37010666)

At the time, there was very little that could be classified as an "online" service. CompuServe Information Service was probably the first, coming into existence around 1979, but it really didn’t ramp up its number of users until a few years later. My early experiences with the modem were actually connecting directly to other people. It would start by dialing the other person using a normal telephone, and after talking for a bit we would tell our modems to connect to one another on the call we had already established and then hang up the phone to not introduce noise on the line. After that, we could continue our conversation by typing on the computer, or do other things like playing a multiplayer game.

▮ The Nexus: What online communication tools did you use before the Internet came along? What are the key differences between them and the platforms we use today?

The original 300-baud Hayes Smartmodem

(By Michael Pereckas from Milwaukee, WI, USA - Smartmodem, CC BY-SA 2.0, https://commons.wikimedia.org/w/index.php?curid=7248349)

Ron Frederick: When I first got a modem, there was very little software available which could use it. There were some basic "terminal" programs that would let you send characters you typed to the modem and display characters received on the screen and there was software to send and receive files, but not much else. As a result, I ended up writing my own software for it. One of the first such programs I wrote allowed two people to play chess, where each of them got to see a chess board on their local screen and had the ability to take turns entering moves they wanted to make via their keyboard. The software would then update the screen on both computers to reflect the moves each player made. The two players could also type messages to one another while playing.

Unlike the Internet today, there was no concept of anonymity in these early experiences. You met people in person first, usually through something like a local computer club or "user group", and you exchanged phone numbers with them. Connecting your two computers was something you did after calling them on the telephone, but you couldn’t talk on the phone and use the modem at the same time, at least not without buying a separate dedicated phone line just for the computer. More on this later!

The other big difference was that these direct connections meant you couldn’t connect more than two computers at a time. It didn’t take long for multi-user applications to appear through services like CompuServe, but in the beginning it was much more of a one-to-one experience.

▮ The Nexus: What types of users were active online during that period, and how would you describe the overall online atmosphere?

Ron Frederick: At this time, people I knew experimenting with modems were mostly micro-computer hobbyists, interested in exchanging tips and tricks and showing off cool things they were able to get their computers to do.

There were also some cases where people I knew had access to more powerful mini-computers or mainframes with modems attached, where one or more users could dial into these computers and use them remotely, much like how one might "telnet" or "ssh" into another computer today via the Internet. These systems usually had a bank of modems attached to them to allow many people to use them simultaneously, and this opened up the possibility for "multi-user" applications where users could interact with one another without knowing each other in advance.

▮ The Nexus:  In what ways did these online communication tools influence or alter the course of your life?

Ron Frederick: As I began to write software which took advantage of modems, I quickly became fascinated with the different ways that computers could "connect" people over great distances. No matter where you were, computers could make it almost as if you were in the same room, and this could be used for both work and play. While I look back at the projects I’ve worked on over the years, the ones I am most proud of are those that involved creating and fostering interpersonal connections between people and helping them to collaborate with one another.

▮ The Nexus: For many young readers, they may not be familiar with BBS. Could you give us an introduction to it and its main functions? 

Ron Frederick: Sure. The term BBS is an abbreviation for a "Bulletin Board System", which was a set of computer software which allowed users dialing into it using a modem to exchange messages or files with one another, or in some cases do other things such as playing online games. Messages could be directed privately to other individual users, or they could be public, associated with some topic. Users could decide which topics they wanted to read, and the BBS would remember the last message in each topic that the user had read, allowing them to pick up where they left off the next time they called in. The modern equivalent would be "forum" software like phpBB or vBulletin, but instead of getting at this software over a network, you connected to BBSes by dialing a specific telephone number with your modem, and then ran a "terminal" program on your computer to remotely access the BBS.

▮ The Nexus: Did using BBS require specific computer hardware or software?

Ron Frederick:In terms of hardware, the minimum requirement was that the computer needed a telephone line to receive calls and a modem with "auto answer" capabilities to be able to answer calls from other computers without human intervention.

The BBS software let users read and write messages and upload and download files, keeping track of new material which arrived since the last time a user accessed the system.

▮ The Nexus: Did you have any experience with running your own BBS? If so, how did you get your own BBS up and what features did you add to it?

Ron Frederick: I ran my own BBS for a few years starting in 1983, using software called "The Bread Board System" (TBBS) written by Phil Becker. This ran on the TRS-80, and provided a nice collection of features. I helped a local computer store set up a BBS for their customers to use, and once I was familiar with the software, I thought it would be fun to run my own BBS. This meant I needed to get my own dedicated phone line for the computer, but by then my parents were very happy I was no longer tying up their regular phone for hours at a time!

My BBS had forums for general discussion as well as more specific topics like for sale/wanted ads, gaming, and music. It also provided places for people to talk about their specific computer models. I also added the ability for users to play certain games that I hosted.

▮ The Nexus: Beyond running your own BBS, what else did you do with BBS?

Ron Frederick: One of the things I created around 1985-1986 was something I called "BBSNet". It was a way for users on one BBS to exchange messages with users on another, instead of being limited to only communicating with other users on the BBS they dialed into. BBSNet worked by having the BBSes call one another in the middle of the night when usage was low and deliver messages that were directed to each other’s users. I even experimented with creating a gateway between BBS users and some of the early email systems that were just starting to appear in universities and research labs.

▮ The Nexus: In your view, why were people so enthusiastic about BBSes? How did BBSes influence the way we interact online today?

Ron Frederick: Unlike the point to point interactions I talked about above, BBSes were one of the first ways for people to actually meet "new" people online. As long as you had the phone number for the BBS, you could exchange messages with anyone using that BBS without having to know them in advance. Some BBSes also allowed anonymity, allowing users to choose a name which wasn’t always their name in "real life".

Like the Internet today, BBSes were a terrific resource for getting technical questions answered. People would share details about what they wanted their computer to do and others would post messages about how to accomplish those things. Search capabilities were generally very limited, but the volume of content was so much lower that it was actually possible for people to read every post on the BBS, for topics that a user cared about.

While dial-up BBSes themselves have largely disappeared with the creation of the Internet, online forums are in many ways direct descendants, with many of the same basic capabilities. Things aren’t limited to plain text any more, and modern forum software has much richer sets of threading and searching capabilities, but it’s easy to see the parallels between the two.

▮ The Nexus: Could you share some of your early encounters with real-time chat services? 

Ron Frederick: The first real multi-user real-time chat I ran across was hosted on the CompuServe Information Service I mentioned earlier. It was an application called "CB Simulator", and it allowed plain text messages to be "broadcast" to multiple other users at once in real time, much like how physical CB (Citizen’s Band) radios did for voice. Like real CB, CompuServe’s simulator started out having 40 different channels that users could switch between, with anything a user sent going to other users tuned to that channel. However, unlike real CB radios which only worked over a limited distance, CompuServe’s CB Simulator could connect people all over the world. 

CompuServe’s CB Simulator very quickly became one of the biggest applications on the service, and it actually remained a part of the service for over two decades, shutting down only when CompuServe itself was shut down in 2009.

▮ The Nexus: During that time, how were real-time messages broadcasted to users on the platform? Were there any notable limitations while using real-time chat? 

Ron Frederick:  In order to send or receive messages in the CB Simulator, a user would need to dial into the CompuServe service, log in with their user ID and password, and then navigate to the "CB Simulator" application. Once there, they would decide what channel they wanted to "tune into", and the system would keep track of all of the users in each of the available channels. Whenever any user sent a message to the channel, a copy of that message would be sent to all the other channel users. So, there was no real "broadcast" happening here, but from the users’ perspective that’s what it felt like. 

The main "limitation" of the service was cost. In addition to a monthly membership fee, CompuServe charged by the hour to use their service. At the time I used it, rates were anywhere from $5.00/hour for off-peak using a 300 baud modem to over $20.00/hour for busier periods or when using a higher speed modem. This was on top of whatever fees the telephone company charged to dial in. If you spent several hours a night chatting on the CB Simulator, you could end up with a hefty bill at the end of the month!

▮ The Nexus:  Did you create your own real-time chat tool at the time? Were there any memorable or unique interactions you had with other users?

Ron Frederick:  I’ve actually built several real-time chat systems over the years, but the very first one I built was my own version of a "CB Simulator" that I modeled after the version I saw on CompuServe. I had gotten access to a PDP-11 minicomputer at a local college which had several terminals attached to it. Normally, each terminal operated independently, with each user having their own keyboard and display and each running its own programs. However, I figured out a way to allow a program started on one terminal to write output to other terminals, and turned that into a program that users could run to tune into different channels and send messages to other users in that channel just like the CompuServe service.

While working on this project, I mentioned it one night on CompuServe’s CB, and as it happened there were some college students online who had been experimenting with the same sort of thing on their school’s IBM mainframe. We had fun that night exchanging ideas about how to build such a system, and they even gave me a chance to try out a prototype they were building. I was only in my second year of high school at the time, but little did I know then that when I picked a college a few years later, this is the school I would choose, and some of the people I met on CompuServe years earlier were still students at that school when I got there!

A few months into my freshman year, some of those students and I built a much more extensive chat system on the mainframe called CONNECT. With the help of someone on the IT staff, we were able to use some special features of that system to scale up dramatically from the previous "CB Simulator", supporting hundreds of users on the system simultaneously and thousands of users overall. This service ran for about 5 years, shutting down only when the school limited student access to the mainframe. A follow-on system was built which ran on UNIX workstations, and now almost 40 years later a descendant of that is still running. In fact, I use it to talk daily with many of the people I know from when I went to school there!

▮ The Nexus:  Speaking of CONNECT, what were some of the unique features of CONNECT when it was created?

Ron Frederick:  When CONNECT was being built, there weren’t many other forms of real-time chat available yet. This was in 1986, a few years before Internet Relay Chat (IRC) appeared on the scene and more than a decade before commercial instant messaging systems from America Online, Microsoft, and Yahoo. Most versions of real-time chat at the time supported only private user-to-user chats, or public messages like the "channels" on CompuServe CB, where users could typically only send messages to one channel at a time, and users had to explicitly switch channels each time they wanted to send somewhere different.

CONNECT was one of the first systems to let you direct where your messages were delivered on a per-message basis. Messages could be private and addressed to specific users or they could be public and sent to "discussions" that users could join and quit depending on what topics interested them. Users could be a member of multiple discussions at once, receiving both private messages addressed directly to them and public messages to discussions they were a member of, and they could optionally specify a "send list" of where each message should be delivered to. This could include a mix of individual users and discussions the user was a member of, and when the message was delivered, the recipients could see all the users and discussions the message was addressed to. Each message could have a different "send list" associated with it. This was a great way to encourage people to join new discussions, as you could send something to a discussion and users who weren’t yet members of that discussion. If a recipient was interested in the topic, they could see the discussions the message was sent to and consider joining.

Another feature of CONNECT was the ability to play various online games with other users without actually leaving the chat system. In fact, gaming was tied to discussions, such that when a game was started in a discussion, all the members of the discussion could see all the game output. People could choose to be either active players of the game or observers, watching the game but not actually playing. As new cards were dealt or dice were rolled, everyone would see the results, and enforcing the rules of the game and the scoring were handled automatically by the chat system.

CONNECT also integrated with other services, like a student volunteer "consulting"service, where people would sign up for shifts to help answer technical questions from other users. Users with a problem could connect to the "CONSULT" service and their question would be added to a queue that the volunteer consultants could select from, starting up a person-to-person chat with the users asking the selected question. Consultants could also communicate with each other through a discussion on CONNECT, to help each other answer questions, and they could do all of this while chatting with other regular CONNECT users not using CONSULT.

The last interesting feature I’ll mention is the ability to log out from a terminal without actually exiting the CONNECT service. Instead, you could "detach" from CONNECT and it would allow you to keep receiving messages even when you weren’t online. Later, you could log in again (possibly from a different terminal) and see everything that happened while you were away, including both private messages sent to you and public messages sent to discussions you were a member of at the time you detached. This kind of mobility really didn’t exist in any of the other systems I’m aware of at that time.

▮ The Nexus:  As you can see, how did real-time chat compare to other forms of communication, such as BBSes or emails?

Ron Frederick:  I think each has its place. E-mail is great for longer messages, where you want to take your time deciding what to say, and potentially revising the message several times before actually sending it. With modern multimedia e-mail, you can also do things like include pictures or attach files to your message.

BBSes (or modern-day online forums) are nice because a group of users can communicate with each other without having to know the addresses of the other users in the group. It’s possible to do this with email using mailing lists, but forums typically add the ability for all the users to see a shared history of the discussion, and even allow things like shared editing of documents by members of the group.

Real-time chat tends to be a lot more informal. Messages are shorter and typically sent without much revision. A good chat system will let you join several multi-user chats at once, and also provide a history of recent conversations, so you can potentially catch up on things sent when you weren’t actually logged in. You get some of the same benefits of forums, but with conversation speeds that are closer to what you’d get if you were sitting in a room having a voice conversation with a group of other people. In fact, some real-time chat systems offer voice and video capabilities, as well as the ability to do things like share your screen with others just as you could if you met in person.

That said, text-based chat can have an advantage over voice/video, as recipients of a chat message can delay reading or responding to a message if they are busy. They can choose to ignore a telephone call if they’re busy, but there’s no way to know what the call was about in that case unless the sender leaves a voicemail or follows up with a text message. Also, it takes longer to listen to a voicemail message than it probably would to read that same content as text. Real-time chat systems provide a way to have delayed conversations much more smoothly.

▮ The Nexus: In the early days of online communication, did people engage anonymously or under their real identities? Did security issues exist during that time? 

Ron Frederick: In the very early days where people called one another on the telephone before starting up their modems, there really wasn’t much of a concept of anonymity or concerns about security. You knew who you were calling, and the person you were calling already knew you. However, once BBSes and auto-answer modems came onto the scene, it was up to the BBS operator to decide if people were required to use their real name or if they were allowed to pick a pseudonym that they used when they posted messages or otherwise made their identity available to other users. 

With online chat systems, it became much more common to use pseudonyms. CompuServe CB had a notion of a "handle" that you could specify, which came out of the way people talked on real CB radios, and most chat systems seemed to have some version of that.

With BBSes and other online services like CompuServe, security was definitely an issue from the beginning, especially in cases where anonymity was allowed. People found various ways to abuse the system, and there needed to be mechanisms in place to deal with that. Most systems had ways for users to block other people they didn’t want to see messages from, and if things got really bad, a system operator might get involved to restrict or even ban users who repeatedly misbehaved.

▮ The Nexus: Given the rapid advancement of AI technology, are there specific aspects of future online communication that excite or concern you? 

Ron Frederick: I think my biggest concern is around how good deep-fakes have gotten, not just in terms of creating spam emails which look more and more like legitimate messages, but also with audio and now even video recordings which are completely fabricated. How do you tell what’s real when technology like this exists?

I’ve seen some attempts to use AI to help detect whether something is a fake or not, so perhaps there will be technological solutions to this issue, but just as we’ve never been successful at completely eliminating "spam", I fully expect that any technology to detect fakes won’t be 100% reliable, and both sides will continue to tune their solutions to either make the fakes better or make detection of them better.