talk: the P2P chat from 1983 that a VPN brought back to life | Andros Fenollosa
Skip to content
Before the internet, people could already chat. It is a topic that has always intrigued me: how was it possible? As a kid I had already heard about a command called talk, and the most impressive part is that you can still use it today, with no sign-ups and straight from the terminal, even in workplaces where I work over a VPN. It is not dead: it is just that few people know its potential.
This article is to satisfy my own curiosity, and if someone learns something along the way: all the better. If you lived through the talk era and spot any inaccuracy, please write to me privately so I can fix it, since finding information has been hard.
How did people chat back then?
The way people chatted in the 80s does not resemble the experience we have today.
Two people shared the same screen and could watch each other type. I am not sure you realise what that means: in real time, letter by letter, each one saw how the other typed, deleted and hesitated. It was not a send-and-wait chat, but a living screen split in two.
Here you can see how the conversation is simulated with two Docker containers.
It all started by finding out whether the other person was available. For that you had the finger command, which told you if a user was connected and what they were doing. If you are interested, I have another article on what finger was and how it worked.
Then, if they were available, you ran the talk command in the terminal, followed by the user and host you wanted to talk to.
For example:
talk ana@library<br>ana would get a message in her terminal letting her know that someone wanted to talk to her. If she accepted, the screen split in two and the conversation began.
You were limited to talking with a single person at a time, and you needed an account on the same system as the other person, or on systems that could see each other: what you would call talking over a LAN today, a P2P communication with no central servers.
There was also no conversation history, no way to send files, and no authentication or encryption (anyone who could see the traffic could read it). It was a very basic chat, but a functional one.
The curious thing is that you can still do this today, and it works. The talk client ships out of the box on macOS and most Unix systems. On Debian or Ubuntu you install it with apt install talk talkd. Its daemon, ntalkd, is right there too.
Origin
It all began with two people who wanted to talk to each other through a machine they shared.
In 1965 MIT's CTSS had a WRITE command to send a line to another logged-in user, and systems like Multics, PLATO or NLS offered similar mechanisms.
In the 70s, Unix inherited and polished it. You copied lines of text straight onto another user's terminal. And to decide whether you wanted to be interrupted or not, there was mesg (from message), dated 3 November 1971, attributed to Dennis Ritchie and Ken Thompson. A mesg n and you closed the door; a mesg y and you opened it. There was also wall (write all), which shouted a message to every terminal at once. All quite crude by our standards, but shaped for its time.
The leap came in 1983 with 4.2BSD . That is where talk appeared as I have described it: split screen, simultaneous typing and, most importantly, able to connect two people on different machines across the network. It was no longer about talking to whoever shared your computer, but with anyone on a connected machine. The credit goes to Kipp Hickman, Clem Cole and Peter Moore.
The protocol
For two strangers on different machines to end up with their screens linked takes some engineering. There is no central server where both register, which forces a dance of requests. You need a middleman on each side: the talkd (or ntalkd) daemon.
Think of talkd as your machine's receptionist, with two jobs: it keeps the invitations you leave and notifies your users when someone from outside wants to talk to them:
Negotiation (finding each other and ringing the doorbell) goes over UDP .
The conversation itself, the stream of letters, goes over a direct TCP connection between the two clients.
To negotiate, clients and daemons send each other control messages:
LEAVE_INVITE (I leave an invitation)
LOOK_UP (I look for an invitation)
DELETE (I delete it)
ANNOUNCE (notify that person). With those four pieces the whole thing is built.
The conversation between Bob and Ana looks like this:
sequenceDiagram<br>participant A as Ana's talk<br>participant DA as Ana's talkd (UDP)<br>participant DB as Bob's talkd (UDP)<br>participant B as Bob's talk<br>A->>DB: LOOK_UP (has Bob invited me yet?)<br>DB->>A: NOT_HERE (not yet)<br>A->>DA: LEAVE_INVITE (I'm listening on this TCP port)<br>A->>DB: ANNOUNCE (notify Bob)<br>DB->>B: "talk: connection requested by ana@host. Reply with: talk ana@host"<br>B->>DA: LOOK_UP (where is Ana listening?)<br>DA->>B: Ana's TCP address<br>B->>A: direct TCP connection<br>Note over A,B: From...