gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] [FOSDEM substitute] Brenschluss: Walking the Planck? Or


From: Thomas Lord
Subject: [Gnu-arch-users] [FOSDEM substitute] Brenschluss: Walking the Planck? Or has Conway Got Our Number?
Date: Mon, 20 Mar 2006 23:04:53 -0800

(skip to "~~~~~~" for the new content -- the header is just the
"table of contents" for the series.   Bored with the whole series?
(of course you are :-)  Just skip to the bitter end and follow the 
amazon reference -- there's at least some value contributed to
yr life there.)

Since I wasn't able to attend FOSDEM as invited I didn't prepare a
talk or slides.  I am, however, writing a brief series of short essays
about the topic I meant to speak about.

This is the sixth essay in the series.  The "cliff's notes" so far
are:


1. The King's English: What Do Links Point At?

   Today's links point at property.

   We don't really have hypertext.   All our links point to
   Internet real estate, not to documents.


2. The Literature Shelf is Not Literature

   True names would enable real hypertext.

   True names don't really exist but can be approximated.


3. Who Owns the Author?

   Authorship is the right to modulate a document's contents.

   Documents require access protection.  The right to modify
   can be shared, transferred, and subdivided.


4. "The Document" is Just a Hypothesis

  Documents are never tangible -- only signals about documents are
  "real".  We can possess evidence of a document but not the document
  itself.

  Software systems for hypertext should be about managing signals --
  not storing documents.


5. Loss, Corruption, Thievery, Confusion and Constraint

  Usenet counts as a global hypertext strawman, but points up some
  problems to solve.


6. Brenschluss: Walking the Planck?  Or has Conway Got Our Number?

   The most abstract and self-indulgent essay in the series.
   Worth reading for the final reference at the end.  

   Brass tacks really pick up on the way down, promise, assuming you
   are such a peasant as to not recognize them in this form :-)

   ("Modeling and embracing uncertainty" is the abstract topic.)


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  


   Brenschluss: Walking the Planck?  Or has Conway Got Our Number?

  So, a hypertext author is a world-line emitting signals.  We infer
  the existence of an author by observing signals on the Internet.

                Inferred      Observed
                ========      ========

                t0 *   ~~~~>  doc v0
                   |
                   |
                t1 *   ~~~~>  doc v1
                   |
                   |
                t2 *   ~~~~>  doc v2
                   |
                 (etc.)


   There are a few small problems here.

* Dropped Packets

  Suppose we actually observe this:

                        ~~~~>  doc v0

                        ~~~~>  doc v2

  Does there exist a "doc v1"?  Did we simply miss that
  packet or was no such version ever published?


* Conflicting Packets

  On the other hand, suppose we observe:


                         ~~~~>  doc v0

                   ~~~~>  doc v1  /  ~~~~>  doc v1'

                         ~~~~>  doc v2

  Is one of the two version 1 documents forged?  Or perhaps
  the author sent differing versions -- one from a laptop
  in Hong Kong, another from an office in Boston?  If both
  are valid, which is preferred?


* Forgeries

  What if we get the apparently clean signal from a single
  direction (aka, on a single channel):


                       ~~~~>  doc v0
                
                
                       ~~~~>  doc v1
                
                
                       ~~~~>  doc v2
                
  Is there a single author?   Which is the right explanation?:
   
      author A                       author A
      ========                       ========

      t0 *   ~~~~>  doc v0     -OR-    t0 *   ~~~~>  doc v0
         |                                |                  
         |                                |                  
      t1 *   ~~~~>  doc v1             t1 *   ~~~~>  doc v1
         |                                
         |                           author B   
      t2 *   ~~~~>  doc v2           ========
                                       t2 *   ~~~~>  doc v2



* These Confusions are Always Possible, Probable Even

  Nothing can be proposed that can eliminate the possibility of
  dropped, conflicting, or forged packets.  If you have a central
  authority to reduce the risk -- that central authority can be
  hacked.  If you have a "perfect" cryptographic system to reduce the
  risk -- the keys can be stolen.  Etc.

  The only thing engineering can do to trade the expense of operating
  the document system against the probability of confusion.
  Especially with regard to malicious attacks, we can only trade the
  expense of protection against the value of attack.

  Moreover, both dropped and conflicting packets may happen
  non-maliciously -- on purpose.  The author may be multiple persons
  who sometimes happen to post conflicting revisions to a document.
  An author may retract a version.  Things like that.

  There is no getting around dropped and conflicting packets (document
  versions) or the possibility of forgery.  It is better to embrace
  and deal with that circumstance than to deny it.


* Incomplete Information

  Suppose, at the moment, we have observed:


                              doc v0

                              doc v1

                              doc v2

  "Ah!", we might think, "No conflicting packets!  No dropped packets!"

  Supposing we proceed accordingly, what happens tomorrow when we
  receive a delayed delivery of:

                              doc v1'

  or

                              doc v1.5
  
  or both?

  Oops.


* A Question Without a Knowable Answer

  Consider this question:

        At his time, T_n, what was the latest version
        of this author's document?

  Perhaps the answer is "doc v_m" where "m <= n" but "m" is the
  greatest value less than or equal to "n" for which we've observed a
  document.  A dropped packet can make that assumption wrong.  So can
  a packet that hasn't arrived yet.  Forgery can also mess up that
  assumption -- perhaps there is no single author at all.

  So the answer to our considered question must always be prefixed:

        Current best guess is.....


* User Interfaces Are All About Telling the Truth

  A good user interface (in the case at hand, to a global hypertext
  system) doesn't create a truth so much as it accurately presents
  a truth to the user.

  End-users of the global hypertext must be made aware -- by means 
  of the interface -- of the possibility of dropped, conflicting, 
  and forged packets.

     User: "Hey, browser, get me `Doc A'!"

     Browser: "Which best guess would you like?  There's one from 
       the Weidner Library, another based on the `GPG coop',
       and a third from Google.  Unfortunately, all three differ."

  Worse case, sure, but true enough....

  It's *almost* worth making the worst case happen, just to maximize
  the number of people who get it.   Personally, I prefer just talking
  about it.


* References


  http://www.skyhunter.com/marcs/petnames/IntroPetNames.html
  http://www.zooko.com/distnames.html
  http://ono.cdlib.org/shimenawa/read20/jak_reading2.ppt



http://www.amazon.com/gp/product/1568811276/sr=8-3/qid=1142924166/ref=sr_1_3/102-4210439-6458555?%5Fencoding=UTF8
        (From a review: "read it before you die, and see how God
         created math." -- Scott Ryan (Silver Lake, OH)

         From another review: "Seriously his is a great book
         recommended for any person not just mathematicians"
         -- Weeam Afifi (Cairo, Egypt)

         From another review that tips a quiet hat to Knuth:
         "This is an all-time classic, a `desert island book'."
         -- Joseph L. Shipman (Rocky Hill, NJ)

         Average customer review: 5/5)









reply via email to

[Prev in Thread] Current Thread [Next in Thread]