E language over I2P

I2P is a distributed network on top of the Internet that applications
can use to anonymously and securely send messages to each other [2].
I posted the below message to the I2P mailing list in 2004-09; I
wanted to post it here also, but the I2P people were not ready for
publicity.  I have not been paying much attention to E and none to I2P
the last years.  Sadly, the I2P project seems to be under difficulties
right now, and the original mailing-list and website seem to be gone.
See the 2nd half of the message for the ideas.

==========================================================

This is a nascent collection of ideas but I think the potential is awesome.

[You people can skip my E description]

The E language is "the secure distributed pure-object platform and p2p
scripting language for writing Capability-based Smart Contracts" [1].  I'm
going to assume the reader is somewhat familiar with E and how the
distributed object system works.

E Vats are interpreter/runtime processes identified by the hash of a public
key; E ObjIDs are large unguessable random numbers; together these two
constitute a globally unique unforgeable capability to an object, knowledge
of which is sufficient to use the object.  To send a message (invoke a
method) on a remote E object you locate the TCP/IP where the Vat currently is
at by using a Vat Location Service (VLS) (if you're not already connected to
it), do VatTP (encrypted byte stream transport) to that TCP/IP (using the
VatID for verification of the presented public key) and then do CapTP over
VatTP.  CapTP designates the unguessable ObjID, the method name, and sends
the parameters.  E has promises, pipelining, and partial ordering; I think
VatTP has nothing to do with these but I'm not positive.  CapTP requires a
reliable and ordered byte stream.

My idea is to use I2P destinations for VatIDs, I2P's DHT for VatID/destination
locating instead of VLS, and use I2P's (default encrypted, default
authenticating) streaming library instead of signed-DH VatID verification and
VatTP.

[END description]

E is perfectly suited to the latency and potential unreliability / failure /
disappearance of I2P destinations because of it's asynchronous method calls,
promises, and when-block promise resolution/smashing handling -- E makes no
assumptions about network reliability or continual Vat availability.  I2P is
perfectly suited to E because E is all about POLA (principle of least
authority) and reducing to the absolute minimum necessary what can be known
about what you're doing and I2P provides the missing inter-Vat
unsurveilability which TCP/IP cannot.  Without using something like I2P, E
use is vulnerable to linkability of participants, especially for well-known
Vats.

I've scanned the E API and I think implementing this will not be difficult and
will be transparent to most of the rest of the E interpreter.  I think all
that needs to be changed is the VatTP implementation to using I2P leaving the
API the same, extending E's URI capability references to support an I2P
destinations scheme, and not using VLS.

A cool thing I realized while playing around with I2P's current ministreaming
library is that you can initiate connections using a destination you are
simultaneously accepting connections on, as opposed to TCP/IP where
initiations of connections use a new random port number which requires E's
VatTP to tell the other end what VatID it is and then the other end has to
verify this and keep a record of it.  Using your VatID/destination to
initiate connections to other Vats automatically lets them know which Vat you
are and authenticates you.

I think the E guys would be interested in knowing more about I2P and doing E
on it but I haven't posted these ideas to their list yet because I'm not sure
if you I2P guys want the attention yet.

[1] http://www.erights.org/

==========================================================

[2] http://en.wikipedia.org/wiki/I2P

--Derick