[ih] IPv8...

Vint Cerf vint at google.com
Sun Apr 19 03:34:40 PDT 2026


>From Gemini:

J.C.R. Licklider, often called the "Computing's Johnny Appleseed," didn't
just view electronic mail as a digital version of a post office. In his
seminal 1968 paper, *"The Computer as a Communication Device"* (co-authored
with Robert Taylor), he envisioned a future where email was the backbone of
collaborative intelligence.

Licklider’s scenarios for electronic mail weren't just about moving text;
they were about *distributed thinking.* Here are the key scenarios and
concepts he outlined:
------------------------------
1. The "OLIVER" (Automated Digital Assistants)

One of Licklider’s most prophetic scenarios involved what he called the
*OLIVER* (*On-Line Interactive Vicarious Expediter and Responder*).

   -

   *The Scenario:* He imagined a personalized program that would reside in
   the network to handle your mail.
   -

   *The Function:* The OLIVER would screen incoming messages, reply to
   routine inquiries on your behalf, and prioritize important data. This is
   essentially the 1960s vision of *AI-driven inbox management* and
   automated responders.

2. Communities of Common Interest

Licklider predicted that electronic mail would destroy the tyranny of
geography.

   -

   *The Scenario:* He argued that people would no longer be grouped by
   where they lived, but by what they cared about.
   -

   *The Impact:* He foresaw "online interactive communities" where
   specialists across the globe could exchange ideas instantly. To Licklider,
   email was the "glue" that would hold these non-geographic communities
   together.

3. Collaborative "Modeling"

For Licklider, communication wasn't just sending a message; it was about
*cooperation.*

   -

   *The Scenario:* He envisioned two researchers using the network to work
   on a shared "model" (data or a simulation).
   -

   *The Function:* Email and network messaging would allow people to send
   not just words, but executable programs and data sets. One person could
   "mail" a piece of code, and the receiver could run it immediately to see
   the sender’s logic.

4. Asynchronous Problem Solving

He recognized that human schedules are messy.

   -

   *The Scenario:* Licklider saw electronic mail as a way to facilitate
   "interpersonal communication" without requiring both parties to be present
   at the same time.
   -

   *The Value:* This would allow for a "more thoughtful and
   better-documented" exchange than a telephone call, as users could take time
   to research a response before sending it back through the system.

5. The "Information Utility"

Licklider compared the future of electronic communication to a public
utility, like electricity or water.

   -

   *The Scenario:* He imagined a world where everyone—not just
   scientists—had a terminal at home.
   -

   *The Daily Use:* People would use the "mail" system to check bank
   balances, schedule appointments, and engage in "the creative process" of
   social interaction.

------------------------------
Summary of Licklider’s Vision
*Feature* *Licklider's Prediction* *Modern Equivalent*
*Medium* "The message is the model" Shared Google Docs / GitHub
*Agent* The OLIVER AI Assistants (Copilot, Gemini)
*Geography* "Communities of interest" Subreddits / Discord / Slack
*Speed* "Interactive but asynchronous" Modern Email / Threaded messaging

"In a few years, men will be able to communicate more effectively through a
machine than face to face."

— *J.C.R. Licklider, 1968*

Licklider’s genius was realizing that the computer wasn't a "giant brain"
meant for calculating trajectories, but a *medium* meant for connecting
human minds.

On Sun, Apr 19, 2026 at 3:13 AM Greg Skinner via Internet-history <
internet-history at elists.isoc.org> wrote:

> On Apr 18, 2026, at 6:15 PM, Jack Haverty via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >
> >
> > On 4/18/26 14:38, Tony Li wrote:
> >> Hi Jack,
> >>
> >>> Somewhere in the timeline of Internet History, the notion of scenarios
> as drivers of technical choices must have disappeared.
> >> No, not at all.  In fact, it’s hard to get any solution through the
> IETF anymore without an independent “use cases” document.
> >>
> >> Regards,
> >> Tony
> >>
> > "Use Cases" and "Scenarios" are different things.   Both are needed.
> >
> > My understanding of "Use Cases" is that they serve to show how some
> particular technology (protocol, algorithm, whatever) can be actually used
> in the Internet.  In other words, they are driven from the technology side,
> explaining how a technology could be used.
> >
> > In contrast, "Scenarios" are driven from the end-users' perspective.
> They capture things that the end users need to be able to do, given the
> overall system of technologies that exist at the time.  The C3I scenario I
> described earlier captured one example of what the aggregate of military
> end-users needed to do, using the Internet to provide the communications
> infrastructure.   If there was a technological piece still missing, the
> scenario was not possible.
> >
> > A particular technology may be useful and even necessary.  But by itself
> it is likely insufficient to actually enable any but the simplest
> end-users' scenarios.  Other technologies may also be needed before a
> particular scenario is workable.   Sometimes many technologies have to
> exist and work together.
> >
> > It's also conceivable that some particular decision of a technology
> precludes ever reaching the goal of enabling a scenario.  A particular
> technology decision with a "use case" may rule out approaches to other
> technology issues that must also exist to enable the scenario.
> >
> > In the C3I example I described, lots of technology advances seemed to be
> likely needed.  Routing algorithms almost certainly needed to evolve.
> Congestion and flow control likely needed changes too.  In military
> contexts, security was always a requirement.   Techniques for prioritizing
> traffic flows were likely needed.  Techniques for compressing large
> documents, voice streams, et al had to be created.  Etc.   To meet the
> needs of the scenario, all the technical pieces had to exist and work
> together.
> >
> > I first encountered "scenarios" while I was a student, in Professor
> Licklider's group at MIT.  Lick was my adviser and later boss for several
> years in the 1970s.  About ten years earlier, Lick had written memos about
> his vision of a "galactic network" in which computers were available to
> humans everywhere, and were somehow interconnected so that they could
> communicate with each other.
> >
> > Lick's training was in psychology, so he thought from the human's
> end-user point of view.  He described the "scenario" of his "galactic
> network" vision as "computers everywhere helping humans do everything that
> humans do."  He understood that such a scenario was a bit too vague to
> serve as a specification.   But for a vision that was OK, and could serve
> to create other more detailed scenarios -- like the military ones.
> >
> > In the mid-70s, one of the network research topics focussed on what came
> to be called email on the ARPANET.  I recall lots of discussions with Lick
> and many others to define relevant and more detailed scenarios.  Lick's
> vision was broad, encompassing all sorts of human-human communication.
> Emails might be short notes or massive documents.  They might be urgent,
> and require mechanisms for tracking through delivery.  They might be
> multi-media, perhaps starting as text communications, switching to
> conversational voice, and even evolving into an interactive conferencing
> session using text and/or voice (video was just too hard to think about in
> the 1970s).  Interactions could be saved (such as on the "Datacomputer",
> which did exist on the ARPANET and our email system used it).  Long
> "conversations" could be related to each other as something like today's
> email "threads" and "forums".  Some communications might have to be
> private, protected from prying eyes along the way.  Some might need to have
> the author, and/or recipients, verified so that you could believe what you
> saw or heard came from where you thought it came from.   Some might be
> routed through a kind of "escrow agent", who could later independently
> testify that a document was real and had been authored, created, delivered,
> and handled at particular points in time.  The scenario for comprehensive
> human-human communications was very complex.
> >
> > We developed a rudimentary technical architecture for such a scenario,
> to at least serve as a starting point while computer technology advanced
> and more things became feasible.    Sadly it was probably never captured in
> any form more permanent than email archives, which are probably lost by
> now.  Lots of technologies would be needed.   It would take a while.
>  Research does.
> >
> > That human-human communications architecture was shelved by ARPA in the
> mid-1970s in favor of a much simpler approach, to provide an interim
> solution that we now would all recognize as today's electronic mail.   I
> think Lick's scenario is still a good target, but I don't think anyone's
> been working on it for the last 50 years.
> >
> > Anyway, I hope that explains the concept of "Scenario".....
> >
> > /Jack Haverty
> >
>
> Jack, you contributed regularly to the header-people and msggroup mailing
> lists, most of which are still available.  If you have time, can you review
> some of what you wrote about, and identify topics that reflected Lick’s
> vision of what human-human communication could be, based on scenarios?
> Offhand, I did see one in which you posted an example of how in the
> military, messages were required to be from the commander, with an address
> distinct from a person. [3]
>
> --gregbo
>
> [1]
> https://web.archive.org/web/20241123091106/http://www.chiappa.net/~jnc/tech/header/
> [2]
> https://web.archive.org/web/20241123091106/http://www.chiappa.net/~jnc/tech/msggroup/
> [3]
> https://web.archive.org/web/20250121110700/http://mercury.lcs.mit.edu/~jnc/tech/msggroup/msggroup0401-0500.txt
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> -
> Unsubscribe:
> https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice


More information about the Internet-history mailing list