<DIV>i'm creating a peer-to-peer commerce system for digital media. </DIV>

<DIV><BR><BR><B><I>Eugen Leitl &lt;eugen@leitl.org&gt;</I></B> wrote:</DIV>

<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">----- Forwarded message from jrandom <JRANDOM@I2P.NET>-----<BR><BR>From: jrandom <JRANDOM@I2P.NET><BR>Date: Mon, 11 Apr 2005 12:07:31 -0700<BR>To: i2p@i2p.net<BR>Subject: Re: [i2p] I2P Consumer Caveat<BR><BR>-----BEGIN PGP SIGNED MESSAGE-----<BR>Hash: SHA1<BR><BR>Hi Aum (et al)<BR><BR>Thanks for the note. I read the scrollback from the channel and I<BR>have to say that there's much I agree with you on. We must support<BR>users who don't have high capacity links, we must support users who<BR>cannot maintain reliable internet connectivity, and when I2P fails,<BR>it must fail gracefully. While we've come a long way, we've got a<BR>lot of work ahead of us.<BR><BR>Right now we do have users on dialup and low end pentiums running<BR>I2P. I know it can often be straining in those situations, but the<BR>hesitancy I have about stating a minimum set of requirements is that<BR>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<BR>is, well, a ball of duct tape. How would the config work - we'd<BR>add a new field to the I2PTunnel httpclient edit page to let them<BR>specify a destination, and end users copy and paste the destination<BR>from Q after they start it up? I'm not entirely sure I understand<BR>what the Q architecture is shaping up to look like - could you put<BR>together something describing what the components are and what<BR>protocols they speak between each other? In any case, I'm sure we<BR>can find something to let people have dirt easy Q URLs without<BR>mucking around too much.<BR><BR>=jr<BR>-----BEGIN PGP SIGNATURE-----<BR>Version: GnuPG v1.2.4 (GNU/Linux)<BR><BR>iD8DBQFCWruhWYfZ3rPnHH0RAlSfAJ9W6OlT2ABkUL4ZO2TK6YAowAIdkgCfTH09<BR>CwgbNJIe6VI1XaimX1v8DH8=<BR>=iBuO<BR>-----END PGP SIGNATURE-----<BR>_______________________________________________<BR>i2p mailing list<BR>i2p@i2p.net<BR>http://i2p.dnsalias.net/mailman/listinfo/i2p<BR><BR>----- End forwarded message -----<BR>--

 <BR>Eugen* Leitl <A href="http://leitl.org/">leitl</A><BR>______________________________________________________________<BR>ICBM: 48.07078, 11.61144 http://www.leitl.org<BR>8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE<BR>http://moleculardevices.org http://nanomachines.net<BR>_______________________________________________<BR>p2p-hackers mailing list<BR>p2p-hackers@zgp.org<BR>http://zgp.org/mailman/listinfo/p2p-hackers<BR>_______________________________________________<BR>Here is a web page listing P2P Conferences:<BR>http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences<BR></BLOCKQUOTE><BR><BR>You don't get no juice unless you squeeze<br>Lemon Obrien, the Third.<p>__________________________________________________<br>Do You Yahoo!?<br>Tired of spam?  Yahoo! Mail has the best spam protection around <br>http://mail.yahoo.com 