Seeking designs for a capabilities-based multi-user system

[Mark S. Miller]

At 03:22 PM 7/19/00 , Steven J. Owens wrote:
>      I just joined the e-lang list, so I thought I'd say hello.
>Mostly I suspect I'll be fairly quiet - crypto is more of a spectator
>sport to me, I can't keep up with the math.

With posts like this, I hope you will be less quiet than you expect. ;) 
Please don't view the erights site as exclusively about crypto or 
programming language design.  The erights site is the home of E, and 
E-relevant topics -- including yours -- are welcome on the list.  Welcome!  
Glad to have you aboard.

>      I find e-lang and capabilities interesting, particularly in the
>potential for creating tools to enable people to evolve their own
>social systems (I found the power-point slides on "Contracting-out
>Contract Law" particularly interesting; I especially liked the
>subtitle, "Importing Trust Into Low-Trust Societies Electronically").

Thanks.  I actually think that this proposal would stand a good chance at 
lifting hundreds of millions of people up out of misery.  Unlike other 
save-the-world technologies, this would address much more than just their 
material misery.  If you like this proposal, you'd love "Trust" by Francis 
Fukuyama and "The Other Path" by Hernando DeSoto.  Both books have my 
highest recommendation, and both are great background for making progress on 
this proposal.  And neither book is about crypto or programming language 
design. ;)


>      I think, after reading some of the language tutorials and short
>articles at www.erights.org, that I understand the basic concept of
>capabilities.  If I can loosely summarize for the pop-science
>audience, a capability is sort of like a combination of:
>
>      a promise of some programmatic service or information 
>      a digital signature that identifies and verifies it
>      a URL (effectively) pointing to the object that can provide the service

Could you expand on this?  It's a sufficiently different take that I'm not 
sure how to respond until I understand it better.


>      I can see all sorts of nifty potentials for capabilities-based
>systems.  Having them available as part of the operating system or
>programing environment changes the ground rules in thinking about
>these things.  But one thing I'm still shallow on is how you'd use
>them in practice, how you'd design the implementation of a system
>using capabilities.

Good question.  It's hard to know where to start answering it.  Are you 
familiar with the "Design Patterns" literature in object-oriented 
programming (inspired, btw, by a "Patterns" literature in architecture")?  
We probably need a similar treatment exposition of patterns of capability 
programming.  My fantasy name for such a book: "Patterns of Cooperation 
without Vulnerability".  In any case, studying real capability programs, 
like the annotated echat http://www.skyhunter.com/marcs/echatIndex.html .


>      One reason I subscribed was a paragraph from the "E Language
>Design Goals" page (http://www.erights.org/e/e-goals.html):
>
>      ".... MOO experiences
>show this to be a compelling source of richness of the world."
>
>      It's this last sentence in particular that I'm interested in.
>I'm fascinated by potentials of user-programmable multi-user systems
>like MOO, particularly when the limits are really pushed.  

These goals are where E started.  However, I hope you won't be too 
disappointed to learn that this goals page is more historical than current, 
as is maintained out of affection for our origins.  E was developed at 
Communities.com (then called Electric Communities) as the infrastructure on 
which we built a rather amazing graphically-based fully decentralized 
capability-secure social virtual system, "EC Habitats".

E then went through a major redesign (the transition from "Original-E" to 
today's "E") in order to also support in-world casual but secure scripting.  
For both of these motivating goals, we took to heart the adage "For all 
purposes X, a good language for X must first of all be a good language."  In 
out case, "... a good secure language for ... a good secure language."  As a 
result, the language survived its original motivations.

Many of us associated with E, myself included, would dearly love to see it 
once again applied to such purposes.  But no one's currently working in that 
direction.


>... blurring of the line between the client and the server.

I don't know if the blurring you have in mind is the following, but E is 
technologically a pure symmetric peer-to-peer architecture.  Often 
distributed systems will wish to use this technology in an asymmetric 
pattern.  We called the pattern used by EC Habitats "hub & spoke", as in 
airports, not wheels.  Airports are also technologically symmetrical -- any 
plane can fly between any pair of airports.  But some airports are used more 
centrally by other airports.  In EC Habitats, every participating machine 
was a reality server.  The spokes -- normal clients -- generally hosted only 
their home turf, and they could invite people over to visit.  The hub 
machines hosted large gathering places.


>(like going to an event-based architecture 

Once again, I don't know if we mean the same thing.  But E does have a 
purely event-based architecture.


>      I've been thinking about alternatives.  There's a lot of nifty
>projects out there that overlap the problem space to some degree in
>one respect or another.  Momoko and SLIRC are two interesting ones,
>not to mention really cutting edge stuff like Freenet or the Freedom
>Net.  

I'm familiar with the last two, but not the first two.

>But the big thing that most of them seem to leave unaddressed is
>the multi-user programmable community aspect.  Designing and
>implementing a system that tries to allow many people to not only
>coexist on and use the server, but also to dynamically upload new code
>and run it, seems to be a hard task, even in java-based systems where
>there are some built-in mechanisms for security management.

I think you've put your finger on it.  OS types think about secure execution 
of untrusted code, but not much about cryptographic protocols.  Crypto types 
think about the latter, but not much about the former.  Those systems, like 
Java, that have mechanisms in support of both treat them as two unrelated 
problems.  In order to do flexible secure distributed computation -- 
sufficient to solve the decentralized extensible MOO problem and many 
others, you have to solve both problems together in an integrated fashion.  
Joule & E are the only systems I know designed to do this.


>      Has anybody coded, designed or done any brainstorming on how
>you'd do something like this?  I'd really be interested in reading it.

Chip, I think this one's for you.


         Cheers,
         --MarkM