[p2p-hackers] Re: [i2p] I2P Consumer Caveat (fwd from jrandom@i2p.net)

[Eugen Leitl]

----- Forwarded message from jrandom <jrandom at i2p.net> -----

From: jrandom <jrandom at i2p.net>
Date: Mon, 11 Apr 2005 12:07:31 -0700
To: i2p at i2p.net
Subject: Re: [i2p] I2P Consumer Caveat

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Aum (et al)

Thanks for the note.  I read the scrollback from the channel and I
have to say that there's much I agree with you on.  We must support
users who don't have high capacity links, we must support users who
cannot maintain reliable internet connectivity, and when I2P fails,
it must fail gracefully.  While we've come a long way, we've got a
lot of work ahead of us.

Right now we do have users on dialup and low end pentiums running
I2P.  I know it can often be straining in those situations, but the
hesitancy I have about stating a minimum set of requirements is that
we don't know the minimum requirements yet.  A while back, most
people were pushing 1-2KBps lifetime, and at another release, people
were pushing 8-12KBps.  Right now it seems 3-6KBps is the norm.  We
currently use TCP, so those values are off by a bit (since it
doesn't include ACKs and resends), but the move to UDP in 0.6 will
throw all those numbers out of wack yet again.

So, what are the bandwidth requirements going to be once 1.0 comes
out?  What affect will restricted routes have upon bandwidth usage
in 2.0?  What disk resources will be required for nontrivial delays
in 3.0?  I haven't the foggiest idea.  "As little as possible".

Our anonymity goals have us aiming at state level adversaries, but
to pull that off, we've got to get it working and kicking ass in
less hostile regimes first.  Along those same lines, our target
audience includes those without many resources, but we've got to
start somewhere.

As for the Q URLs, we've got lots of options.  The eepproxy itself
is, well, a ball of duct tape.  How would the config work - we'd
add a new field to the I2PTunnel httpclient edit page to let them
specify a destination, and end users copy and paste the destination
from Q after they start it up?  I'm not entirely sure I understand
what the Q architecture is shaping up to look like - could you put
together something describing what the components are and what
protocols they speak between each other?  In any case, I'm sure we
can find something to let people have dirt easy Q URLs without
mucking around too much.

=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCWruhWYfZ3rPnHH0RAlSfAJ9W6OlT2ABkUL4ZO2TK6YAowAIdkgCfTH09
CwgbNJIe6VI1XaimX1v8DH8=
=iBuO
-----END PGP SIGNATURE-----
_______________________________________________
i2p mailing list
i2p at i2p.net
http://i2p.dnsalias.net/mailman/listinfo/i2p

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050411/016bc647/attachment.pgp