[e-lang] E language over I2P
derick.eddington at gmail.com
Sun Mar 2 02:01:36 EST 2008
On Fri, 2008-02-29 at 10:52 -0500, Kevin Reid wrote:
> My implementation will include the feature that CapTP can use
> multiple secure transports (besides VatTP);
Cool. Will this be modularized so that new transports can be used?
With I2P, I wasn't initially thinking of replacing the default transport
but being able to have I2P as an additional transport that works with
the others, but that sounds like it won't work, see below.
> However, to be able to have consistent vat identities so that 3-party
> introduction always works, a vat must use the same VatID and
> associated key-pair no matter what transports it is using.
Oh. Right. I think this means I2P can't be a good fit with other
transports because it is its own entire secure transport, designation,
location, and authentication system. However, if the transport and
URI/referencing/introducing stuff is modularized and abstracted right,
would it be possible to swap I2P in and use it only, so that there could
be only-I2P-transport E-users networks, where all 3rd party
introductions are fine?
> What advantages do you see of using I2P instead of VatTP?
Privacy. I2P is an anonymizing network. Otherwise, participants can be
linked because someone can see 18.104.22.168 is connected to 22.214.171.124. This is
my main interest and why "I think the potential [of E over I2P] is
Also, I2P's base protocol is datagram based, which I thought could
eliminate having to do your own packet format over bytestreams for CapTP
messages. (I2P also has streaming connections (implemented over its
datagrams) over which the existing E packet format could be done).
> (Also, there is currently no implementation of the VLS concept.)
I2P provides destination (Vat) location resolving using a distributed
hashtable. Vat locating and authenticating is automatic when opening a
connection. Since it's a distributed hashtable, random participants
hold portions and so come to have knowledge of where VatID XYZ is at,
which I imagine is verboten for cap-sec (?).
Thanks for your time. I had been wanting to investigate this more.
More information about the e-lang