[e-lang] E language over I2P
kpreid at mac.com
Sun Mar 2 07:49:14 EST 2008
On Mar 2, 2008, at 2:01, Derick Eddington wrote:
> 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?
To add a transport, you just write a maker of objects which connect
over that transport (when given the local vat key and the desired
remote VatID) and return message streams, define a syntax for
serializing its ID/lookup/location information in CapTP URL search-
paths, and tell the creator of your vat's CapTP subsystem to trust it.
Approximately. I haven't actually implemented this yet, so I can't
say this will be *exactly* how it works.
> 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?
Yes. I'd prefer to avoid that situation though.
Also, as Bill Frantz said:
> One could imagine some certificates which said the vatID x on
> network a is the same as vatID y on network b. If these
> certificates were signed with the private keys which generated the
> two vatIDs, this assertion could be believed, although the
> resulting system is somewhat more complex.
The way I see this working is that there is One True Vat Identity
(key-pair), which is used to sign statements (certificates?) of the
equivalence of a given other-transport-identifier.
>> What advantages do you see of using I2P instead of VatTP?
> Privacy. I2P is an anonymizing network.
That is worthwhile.
> 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).
CapTP requires ordered, reliable (e.g. dropping one message in the
sequence would invalidate the protocol) messages. Does I2P provide that?
>> (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 (?).
I don't think that's a problem. MarkM?
Kevin Reid <http://homepage.mac.com/kpreid/>
More information about the e-lang