Announcing Droplets

[Mark S. Miller]

Very cool!!  Congratulations Tyler!!!!

At 01:35 AM 9/27/99 , Tyler Close wrote:
>Droplets is a secure web based capability environment. I think it might be the
>world's first (Mark?).

As far as I know, it is indeed the world's first web based one.  Not that I 
know everything happening on the web ;)

>I've also provided Open Source implementations of Mark's ERTP and the e-gold
>Shopping Cart Interface (http://www.e-gold.com). This means that you can make
>applications that do secure transactions with real money.

Well, real gold.  Just like it's important that Schwab not call themselves 
a bank, let's be careful not to call gold money.

>Since ERTP supports
>secure anonymous transactions, Droplets might be the only currently deployed
>software that supports blind transactions.

I think I understand what Tyler means here, but let's be careful.  Within 
ERTP, someone can supply an Issuer that provides for blinded 
transfer.  When a client of ERTP performs a rights transfer 
(Assay.transfer()), if the Assay is from such an Issuer, then the client 
will cause the Assay to perform a blinded transfer.  The same client, given 
a non-blinding Assay, will perform a non-blinded transfer.

No one has yet written an ERTP Issuer that supports blinding.  Therefore, 
no rights transfers are blinded.  However, when such Issuers are created, 
Tyler's ERTP client code, without being changed, should be able to invoke 
their transfer operation, which will be blinded in that case.

>For the Xanadu buffs in the crowd, Droplets also has built in support for
>transclusion.

Cool!  I didn't know that was coming.

>I built Droplets with a few aims in mind. One of those aims was to create a
>precursor for full E. ...
>Most importantly, it allows programmers to deploy capability based solutions
>now.

I very much appreciate this, and think it's correct.  However, I have to 
quibble with an implication of the last sentence.  As MarcS's echat and 
edesk applications show, E is already up to allowing programmers to deploy 
capability based solutions as well.

Btw, in enumerating the capability security issues E addresses but Droplets 
don't, the most important is the issue of multiple TCBs vs shared trust in 
a single TCB.  E does the first & Droplets do the second.  Both are valid 
and valuable, it's just important to notice the difference.  The most 
important symptom of the difference is in the cryptographic encoding of a 
capability.  Droplets and E both use the swiss number technique.  E also 
has the VatID http://www.erights.org/elib/capability/ode/ode-protocol.html 
specifically to deal with inter-Vat mutual suspicion -- not an issue with 
Droplets.

>I hope that Droplets provides an easy way for programmers to get into the
>capabilities mindset, and that once there, they'll start demanding the 
>full set
>of functionality that environments like E provide.

Likewise!

>As Mark has been occasionally hinting at, I've got a 100% Java implemented
>object database. It stores everything in a single file, does generational
>garbage collection and has support for very large, deterministic collections.
>It's used for persistence in the Droplets environment. It's possible that it
>could be used for persistence in E.
>
>That said, getting to full E is a lot more work than making Droplets from
>scratch was. It's a large codebase and it hasn't really been conceived with a
>persistence solution in mind.

Well, actually E was conceived of with persistence in mind, and actually 
had it twice in its history.  Once, orthogonally by me, a mistake, and once 
state-bundle-based by Arturo.  However, in terms of the work that still 
needs to be done to get persistence back, E may as well not have been 
conceived with persistence in mind.

>There are also some unresolved persistence issues
>with E. We have to come up with a way of identifying objects which should be
>persistent. Some thought also needs to be given to E's transactional paradigm.
>When can an E object be sure that a given state has become durable?
>
>I have some ideas for the above problems and would like to see how they fit in
>with the current E code, but this is likely more work than I am willing to do
>for free. A possible solution would be for me to develop a commercial E 
>vat. The
>tl-E distribution would of course remain free. How much would people on this
>list pay for a full E vat?

Sorry, but E requires a persistence solution that's adequate, open-source, 
and free.  Without one, E will simply die.  I have been hoping that you 
would provide one, but if you don't, I'll do something else.  This would be 
a shame, as the one I'd expect to build instead would be merely adequate, 
whereas your works points at something much better than adequate.  If I 
build my adequate open source solution and you build a high quality 
proprietary solution, I sure hope they are compatible.  Otherwise, we have 
a disaster.

Btw, you and I have already privately talked about another form of 
compensation.  That offer is still on the table.

>We can kick around ideas for this, and I am going to spend a bit of time
>wandering around in the E code. In the meantime though, it would be great 
>if you
>could all help spread the word about Droplets.

Indeed!  I will modify the erights site accordingly.

>As a last word, I'd like to thank Mark for all the work he's done on E. A 
>lot of
>the design expertise that I used in making Droplets is newly acquired 
>expertise
>that I got from being exposed to E. Thanks Mark.

You're very welcome.  I'm proud to see it inspire such wonderful 
work.  However, please remember that the ideas you are being inspired by, 
the ideas embodied in E, are the result of contributions from a great many 
people.  I hope the attributions on the erights home page begins to spread 
this gratitude around appropriately.


-----------------------------------------------------------
Due to a bug (possibly at my ISP, but probably in Eudora 4.2.0.58), on 9/15
I lost 18 email messages.  If it's possible for you to check whether you
sent me something on that date, resending it would be great.  Otherwise,
please excuse my non-responsiveness to email you may have sent around that
time.  Sorry for the inconvenience, and thanks.

         Cheers,
         --MarkM