[ih] IPv8...
Jack Haverty
jack at 3kitty.org
Sun Apr 19 16:05:16 PDT 2026
Wow. I'm impressed. I've been playing with various AIs to learn about
what they can do. But this Gemini summary is a very good breakdown of
some of the elements in Lick's vision. It would have taken me a while
to generate the categories and even longer to make them as concise.
Certainly it would take far longer than the few hundred milliseconds
Gemini probably spent thinking about it. I remember "OLIVERs" and even
built one into our own mail system back in the mid-1970s. But I
certainly couldn't say today how the OLIVER acronym expanded.
I wonder what was the "prompt" that Gemini was responding to.
Still, Gemini overlooked some aspects that seem important to me...
A major one is the notion that everyday people would "use the mail
system" to do their daily activities. Pretty much everyone does
probably now use their mail system daily. But they use a lot more
technology too, even just for human communications. Social media is
one. News apps are another. Many people interact using texting on
their phones. Or any of the multitude of conferencing technologies.
Lots of organizations and companies have their own private email system
and insist that you use it to interact with them. For example, my bank,
doctors, and others use my <jack at 3kitty.org> email address only to tell
me that I have a new message on their private email system, and I need
to log in there to actually see it.
Or any of the numerous "forums" operated by substack, reddit,
sourceforge, linkedin, and many others. In addition to communications,
they also use apps and web sites to buy things, make reservations, and
now even get a drone to drop a package onto your lawn from ten feet in
the air.
In Lick's vision, *all* such technologies would be integrated so that
the "galactic network" could coordinate them and make them all look like
one comprehensive technology for all sorts of human interactions. It
would also remember everything, make it remain accessible to the humans,
and use whatever was useful in its own tasks to actually take actions
that help humans do everything they do.
I have a recurring nightmare that a large semi parks at our driveway,
and I wonder if I clicked the wrong button somewhere when I ordered
something. I'm a long way from being comfortable hooking an AI up to my
Internet and giving it a credit card. It's probably possible even now,
but is it a good idea....?
Today, people on this list probably are well aware of what our
"Arpa-style email" is and what it can do. I find that misleading as a
representation of Lick's vision. The email system that is delivering
this diatribe to you is, IMHO, a poor instantiation of Lick's vision.
In the 1970s, the TV show "Star Trek" (the "original") was popular,
especially among the technorati of the day. The computer could do
pretty much anything the humans asked it to do, not limited to
communications. It obviously talked to lots of other computers and
coordinated activities across the galaxy. Somehow.
That was in effect an instantiation of Lick's vision. His group at MIT,
and others all around the ARPANET, simply had to figure out how to
implement it.
But I think everyone agreed not to forget about including fuses and
circuit breakers. The computer on Star Trek had a tendency to flare up
in a shower of sparks when under stress. We could certainly do better
than that!
Hmmmm. Does The Internet have circuit breakers today...??? What
happens when it is overloaded? Where do the sparks appear? Is The
Internet fireproof?
A second missing aspect from Lick's vision is the lack of methodology
for evolving from research to "utility" level of usage by everyday
humans -- i.e., how do you actually deploy a new "Information Utility"?
How do you deploy the "next release" of the pieces inside it?
Lick's view was that it was important to explore as many ideas as
possible. The "research environment" should be a platform on which many
ideas could be simultaneously tried and evaluated. But after the
research revealed what was the best approach, that one should become the
standard, so that other pieces could be built on top of it. An
"approach" should be adopted at a high level - e.g., closer to
architectures rather than protocols and packet formats. TCP? Or OSI?
Or Netware? Or SNA? Or ...?
Without picking a "winner" to serve as a foundation for future
additions, the overall system becomes unwieldy. Sometimes you might
pick poorly and have to regress. But if you don't narrow down the
technologies you get an environment which is too complex to function
well. Anyone old enough saw that happen through the 1980s and 1990s as
many companies and organizations defined and built their own network
technologies, creating a messy mix of incompatible and interfering
technologies in many user communities who were just trying to use their
computer stuff to do whatever they were trying to do. Running or even
just using a "multiprotocol network" was not fun in the 1990s. Today's
world of computers and human communications isn't very good either.
Lick was a driving force in the creation of the ARPANET, which became a
platform for trying out lots of research ideas. For anyone interested
in this aspect of History, I recommend highly the book "The Dream
Machine" by Mitch Waldrop -- essentially it's a biography of Lick. Some
of the book contents describe the time when I was in Lick's group, and I
found the book to accurately present what I remember happened. I also
learned a lot about why various things happened, that I wasn't aware of
at all before reading the book. For example, I didn't know that Lick had
spent parts of his career at MIT, ARPA (at least twice), and BBN.
It's worth a read to get more of the historical details. I suspect
Gemini has read it....
/Jack Haverty
On 4/19/26 03:34, Vint Cerf wrote:
> 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
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20260419/d66a61de/attachment-0001.asc>
More information about the Internet-history
mailing list