Re: E language over I2P

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?

Yes.

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/>