From: eric@remailer.net (Eric Hughes)
Date: Thu, 17 Nov 94 14:20:07 PST
To: cypherpunks@toad.com
Subject: Re: Islands in the Net
In-Reply-To: <199411171923.LAA11063@netcom10.netcom.com>
Message-ID: <199411172218.OAA29675@largo.admate.com>
MIME-Version: 1.0
Content-Type: text/plain


   From: tcmay@netcom.com (Timothy C. May)

   Language is an example we ought to look at more closely, as both of us
   have noted. In contrast to the "data structures" we love so much,
   natural language is a way of creating a more fluid data structure, a
   more nuanced statement.

The version of language though, that I was referring to were formal
languages, the stuff of DFA's (deterministic finite automata) and
push-down automata.  The advantage here is entirely in their
formality, in that precise interpretations of a formal language can be
made.  A great benefit derives from the explicit formulation of the
semantic scope of particular representation.  A formal language _can_
"mean exactly what I want it to mean, neither less nor more."

The social process of creating these interpretations ("meanings") and
getting everyone to agree upon them, however, can be tortuous.  We in
the ASCII world all agree that the number 65 represents the capital
letter 'A', but the letter 'A' is a further abstraction, albeit
universally shared in the literate world.  Interpretations of data
structures almost universally share this trait; they are reductions of
one abstraction to another.

Two major problems about compatibility can be framed in terms of
formal languages: the need for well-formed data structures and
the coexistence of multiple data structures.

The formal language notion of recognition is merely an algorithm for
set membership, the set being called the "language".  "Is this string
of symbols a member of the language or not?"  Is layman's terms, the
problem is with data corruptions.  While everyone knows data
corruption is a problem, deciding what data is corrupt and what is not
is sometimes difficult; witness the habitual arguments between client
and server writers about whose implementation is wrong.  Even fairly
clear standards like RFC-822 (mail) leave wide holes in
interpretation.

The second problem is less immediately pressing and ultimately more
important.  Given a string of bits, what exactly _does_ it refer to?
One can pass it through all the recognizers one has, but it may still
not be uniquely determined as being a particular kind of data.
Compatibility between data of different types will be of vital
importance to achieve systemic robustness.

Any set of languages, though, can be made compatible by prepending a
common language which acts as a dynamic type specifier.  Unix has
the beginnings of this with its "#!" syntax for picking the
interpreter of an executable.  The problem with the Unix version
of this is that a particular interpretation binary is specified, not
an actual language specification.

   Natural language is often misinterpreted, hence the value of data
   structures. For example, I'm glad my financial accounting at my stock
   broker is handled with robust data structues, but I'm also glad to be
   able to communicate my goals and desires in a natural language.

Well, there's someone somewhere who understands both the formal
language and the natural language; it can be either oneself or an
intermediary.  Now the formal language may be quite flexible and
understandable and admit synonyms, but the contextual nature of human
languages mitigates against their strict interpretation.

One of the real-life characteristics of natural language which isn't
present in computer systems is a way of correcting misunderstandings.
If one person misunderstands another, further conversation can ensue.
If the computer interprets a command differently than the commander
intended, disaster can ensue.  Suppose I want to delete some data and
then I change my mind:

E: Computer, please get rid of this old correspondence.
C: OK, boss, all done.
E: No wait, I need one particular series of those back.
C: Sorry, all gone.
E: What do you mean, "all gone".
C: I destroyed them utterly.
E: Why?
C: You asked.

This stuff has been a theme in SF humor forever.  I find it highly
ironic that the computer industry, so steeped in SF themes, hasn't
thought more about how to alleviate this problem.

As a very basic example, consider the issue of data persistence.  No
standard operating system has at a deep level the notion of "backed-up
data".  The replication and redundancy could take many forms,
including tape, network disk, or data haven.  This particular issue is
going to be an obstacle for the widespread deployment of digital cash.
When a disk crash (hard or soft) means that you lose fungible money,
either the problem gets fixed or the system doesn't propagate.

   What's the common theme? Agents. Chunks of code which also have local
   processing power (brains, knowledge).

I don't think that agents have any relation to the problem of mapping
natural languages to formal languages.  Perhaps you mean something
else by this reference.

   Someone sent me private e-mail on this "Islands in the Net" topic, and
   talked about "payloads of data carrying their own instructions," in
   reference to the Telescript model of agents. (I wish he'd post his
   comments here!) This approach, also typified in some object-oriented
   approaches, seems to be the direction to go.

   > If steel were like software, there would be a knob on each beam that
   > allowed you to change, for example, the balance between hardness and
   > toughness.  Knobs mean random knob-twiddling.

   Actually, such "dynamic buildings" are becoming more common, I hear.

Now add knobs to the thermal expansion coefficients, the densities and
masses, the rates of oxidation, the stress-strain matrix elements,
etc.  If materials engineering were like software, we'd have _both_
nanotechnology and everybody living in trees because they didn't crash
so often.

   But the effect is to increase the "state space" which must be tested,
   and we are led to "testability" and "provable correctness" of
   programs, two interesting areas of programming. So far we've seen
   little application of these ideas to Cypherpunks interests.

Not unexpectedly, since these apply to all software, not just
cryptography software.

   > The more specific inspiration for the general form of the remailer
   > syntax is Jon Bentley's theme of "Little Languages".  

   I'm hopeful that the recent interest in TCL, Safe-TCL [...]

The "little" in little languages might be taken to mean "Not Turing
Complete".  His expository language, as I recall, is the language of
floating point numbers, which, alternately, is the question "how do
you write down a mantissa and an exponent."  Another little language
would be email addresses -- still not completely standardized,
although blessedly mostly so.


   We "locally clear" (approximately the same as "readable on its face")
   cash and commercial paper because of an assumption that forgery is
   difficult and unlikely. When forgery becomes common in some area,
   merchants carry lists of suspected numbers, IDs, etc., and the
   "readable on its face" criterion erodes.

These two are not the same at all!  "Readable on its face" means that
you can actually determine _entirely from the front side of the
document_ what the instrument says.  If there is an inclusion by
reference, then it's not readable on its face.  If there is a
condition external to the instrument, such as a condition of services
rendered, then it's not readable on its face, since some event
external to the instrument determines its value.

"Readable on its face" just means that one knows what is said, _not_
whether one believes it or not.  Those actions which turn the note
into a lie are called "conversions" as a group, and forgery is just
one form of conversion.  (Stealing a note is another.)

With a naive implementation of Chaum's blind signature, all you have
is a string of bits that can be verified only with some public key.
Nowhere in the bits themselves is there an explicit representation of
how much the bill is worth, what currency it's denominated in, when it
expires, who issued it, etc.  These signatures alone are not facially
readable.


   We need to find a way to get back to exploring the various nifty
   systems that are being described in the crypto papers, but which lack
   any real implementation. 

Fandom and enthusiasm will only carry so far in prototyping.  One of
the reasons that the remailers have attracted such interest is that
they do something proximately useful.  The questions of reliability
and utility that are mentioned here really are key to getting more
people trying out stuff.

Eric