Finished migration of meeting logs

This commit is contained in:
str4d
2012-09-13 02:52:36 +00:00
parent da424479f7
commit 51f3228d40
344 changed files with 33461 additions and 32830 deletions

View File

@@ -1,10 +1,3 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 1{% endblock %}
{% block content %}
<h3>I2P (invisiblenet) Development Meeting 1</h3>
<div class="irclog">
Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
--- Log opened Wed May 22 02:01:22 2002
02:01 <+logger> Logging started
02:01 <@nop> ok
@@ -700,5 +693,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
03:46 <@nop> night
03:47 <+logger> Ended logging
--- Log closed Wed May 22 03:47:55 2002
</div>
{% endblock %}

10
i2p2www/meetings/1.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, May 22, 2002
=============================
Quick recap
-----------
TODO
Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
------------

View File

@@ -1,10 +1,3 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 10{% endblock %}
{% block content %}
<h3>I2P (invisiblenet) Development Meeting 10</h3>
<div class="irclog">
Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
--- Log opened Tue Sep 03 23:55:46 2002
23:56 <@mids> test
--- Day changed Wed Sep 04 2002
@@ -167,5 +160,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
01:49 <@mids> I dont care what you do with it :)
02:00 -!- mode/#iip-dev [+o codeshark] by Trent
--- Log closed Wed Sep 04 07:03:17 2002
</div>
{% endblock %}

10
i2p2www/meetings/10.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, September 4 2002
=================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,195 +1,189 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 100{% endblock %}
{% block content %}<h3>I2P dev meeting, July 27 @ 21:00 GMT</h3>
<div class="irclog">
14:02 < jrandom> 0) hi</p>
14:02 < jrandom> 1) 0.3.3 &amp; current updates</p>
14:02 < jrandom> 2) NativeBigInteger</p>
14:03 < jrandom> 3) ???</p>
14:03 < jrandom> 0) hi</p>
14:03 * jrandom waves</p>
14:03 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2004-July/000372.html</p>
14:03 < jrandom> (thanks to hypercubus' prodding i got it out before the meeting :)</p>
14:04 < jrandom> ok, jumping on in</p>
14:04 < jrandom> 1) 0.3.3 &amp; current updates</p>
14:06 < jrandom> there's a truckload of info in the email describing whats going on, and there should be a substantial reduction in bandwidth usage coming up</p>
14:07 < jrandom> it won't be backwards compatible because it changes a lot of things, so the next release will be a bumpy upgrade as well, but c'est la vie</p>
14:08 < jrandom> anyone have any questions wrt the 0.3.3 rev or the things posted in the status notes?</p>
14:08 * dm waves</p>
14:08 * jrandom is seeing 23s lag here @ freenode</p>
14:09 * hypercubus sees 0.10 secs lag</p>
14:09 < jrandom> ah back to normal</p>
14:09 < jrandom> ok, if there's nthing, we can just jump in to 2) NativeBigInteger</p>
14:10 < jrandom> Iakin3 has modified some things so it'll be simpler to deploy the crypto code out of the box, which is Good</p>
14:10 < jrandom> every once in a while i look in the netDb and see some people with 2-400ms delays when doing ElGamal encryption, which means some people aren't using jbigi</p>
14:11 < jrandom> (and everyone should use jbigi)</p>
14:12 < deer> &lt;Nightblade&gt; how do you know they are not just on slow computers</p>
14:12 < Sonium> why isn't it use automaticaly?</p>
14:12 < hypercubus> because it must be custom compiled for each platform</p>
14:12 < jrandom> we might be able to get that deployed in this next rev, but we'll see</p>
14:12 < deer> &lt;oOo&gt; If the DLL is not present, the program continue using java-only code (needed for cross-platform support)</p>
14:12 < hypercubus> and currently the platform is not detected</p>
14:12 < jrandom> Nightblade: thats possible, of course</p>
14:13 < jrandom> oOo right, we definitely will keep that functionality</p>
14:13 < deer> &lt;oOo&gt; Nope, force the existence of the dll an .so files, even if empty or useless</p>
14:13 < jrandom> actually, thats another one of the things we're gaining with some of the current mods i'm working on - we only need to do half as many elGamal encryptions (since the sourceRouteBlock is gone)</p>
14:14 < jrandom> hmm oOo?</p>
14:14 < jrandom> why would we want to do that?</p>
14:15 < deer> &lt;oOo&gt; Force a check of the _existence_ of the library files. If they are not use, you most likely aren't on a x86 Win/Linux platform and are forced to use the Java code. Anyway you did your best to force the use of native stuff</p>
14:15 < jrandom> oh, right, we have always checked for libjbigi.so / jbigi.dll, the thing Iakin's code adds is the ability to package up a whole bunch of DLL and .so files into a jar and choose the *right* one at runtime</p>
14:16 < hypercubus> &lt;/obvious&gt;</p>
14:16 < jrandom> (falling back on pure java if none match)</p>
14:17 < jrandom> anyway, thats some good stuff that'll hopefully help new users out a bunch</p>
14:17 < jrandom> (and saves me the time of doing some ugly drop down boxes on the admin interface :)</p>
14:18 < jrandom> ok, if there's nothing more on that, i think thats all i've got</p>
14:18 < jrandom> so moving on to 3) ???</p>
14:18 < jrandom> anyone else have anything they want to bring up?</p>
14:18 < hypercubus> someone should run a spellchecker on the new website ;-)</p>
14:19 < jrandom> you've got cvs access now... :)</p>
14:19 < jrandom> (module: i2pwww)</p>
14:19 < hypercubus> damn</p>
14:19 < deer> &lt;oOo&gt; The corruption on big transfer, even local one, is under investigation (like grabbing several Mb from your own eepsite) ?</p>
14:20 < hypercubus> i've had many interrupted downloads of big files, but never a corruption</p>
14:20 < jrandom> hmm, most instances of that issue have been resolved, but i've heard reports recently about it. i haven't gone through the app layer and audited things yet again</p>
14:21 < jrandom> i consider interrupted downloads corrupted</p>
14:21 < jrandom> it must work first time, all the way through</p>
14:21 < hypercubus> well you can't help it, because that's what happens on the real WWW too ;-)</p>
14:21 < deer> &lt;oOo&gt; Not when the grabber is on the same computer then the server ^^</p>
14:22 < jrandom> oOo: can you reproduce that?</p>
14:22 < jrandom> (or is it intermittent?)</p>
14:22 < deer> &lt;oOo&gt; jrandom: Did twice, was thinking it was knowed, will try again</p>
14:23 < jrandom> thanks. if you can reproduce it, please let me know the details of the test and i'll dig further into it. </p>
14:23 < jrandom> (i've got to audit the app layer again anyway soo)</p>
14:23 < deer> &lt;oOo&gt; jrandom: No problem, thanks</p>
14:24 < jrandom> ok, anyone else have anything they want to ask/bring up?</p>
14:25 < cat-a-puss> I'm still interested in talking about how to do myI2P</p>
14:25 < cat-a-puss> I may be able to bring a few people in in a few months</p>
14:25 < jrandom> awesome!</p>
14:26 < hypercubus> a class project? ;-)</p>
14:26 < cat-a-puss> something like that ;-)</p>
14:27 < jrandom> i think once we get 0.4 out there with the new web interface, it should be much easier to put together apps (like myi2p) w/ a web frontend</p>
14:27 < cat-a-puss> so you think that can be done on the purely application layer?</p>
14:27 < jrandom> absolutely</p>
14:28 < jrandom> what else did you have in mind?</p>
14:28 < cat-a-puss> well the network DB could be used to store metadata</p>
14:28 < jrandom> ahh</p>
14:28 < cat-a-puss> would it have access to that?</p>
14:28 < hypercubus> *cough*</p>
14:28 < jrandom> no, nothing has access to the netDb</p>
14:29 < jrandom> we're able to work some magic in the netDb because its quite focused just on serving as our distributed routing table</p>
14:29 < hypercubus> cat-a-puss: what you want is the DHT that Nightblade is working on</p>
14:29 < jrandom> myi2p (et al) could certainly use a DHT on top of i2p though</p>
14:30 < hypercubus> (enclave)</p>
14:30 < jrandom> what sort of metadata were you thinking about?</p>
14:31 < cat-a-puss> well I invesioned doing something like chanels in Frost which runs off of an ssk in freenet</p>
14:31 < cat-a-puss> so you run the ssks on the DHT on top of I2p</p>
14:31 < jrandom> right</p>
14:31 < jrandom> that might be a bit of an overkill for some things though</p>
14:31 < cat-a-puss> but you still need a metakey that lists all the people's ssks that are subscribed to the channel</p>
14:32 < dm> dht over i2p... </p>
14:32 * dm doesn't see that working reliable any time soon.</p>
14:32 < Connelly> a generic DHT library would be nice</p>
14:32 < dm> reliably</p>
14:32 < deer> &lt;Nightblade&gt; what's a dht library</p>
14:32 < cat-a-puss> that needs to work diferently ...</p>
14:33 < jrandom> cat-a-puss: i suppose it depends on what sort of activity would go on, but while frost style boards might be good for some things, fmb style boards might be good for others, and blog aggregators might be good for still others</p>
14:34 < Connelly> well a kademlia implementation or somesuch</p>
14:34 < Connelly> I assume enclave would be something like it</p>
14:34 < deer> &lt;Nightblade&gt; i think i'm going to do some changes on LibSAM first</p>
14:34 < deer> &lt;Nightblade&gt; only two weeks of classes left, for me, counting this week</p>
14:34 < deer> &lt;Nightblade&gt; then I will be able to do some stuff I hope</p>
14:35 < jrandom> w00t! :)</p>
14:37 < cat-a-puss> jrandom: basicly the goal is to be all things to all people. If the network does not do everything, people will use something else. (and it needs to be better at it to attract cover traffic)</p>
14:38 < jrandom> i've worked on too many projects that try to do the 'swiss army knife' style - if you build it, they will come</p>
14:38 < hypercubus> the network is a transport layer, not the application layer ;-)</p>
14:38 < jrandom> it very, very, very rarely works out.</p>
14:38 < jrandom> the i2p transport layer should support all possible point to point comm, definitely</p>
14:38 < jrandom> but applications on top of i2p should be user friendly - meaning they address a specific user need and help them with it</p>
14:39 < jrandom> the masses don't want a comm layer, they want a way to talk to people, to read what people say, and to explore</p>
14:39 < Connelly> naw, we should create an XUL, and all new Gecko system</p>
14:39 < Connelly> then build a conglomerate of Mozilla programs on top of that</p>
14:39 < Connelly> then integrate collaborative systems into Mozilla ;)</p>
14:40 < cat-a-puss> great provided the app has enough control over the comm layer to make it do what it wants.</p>
14:40 < dm> Maxthon &gt; Mozilla</p>
14:40 < jrandom> cat-a-puss: absolutely. all apps using SAM, I2CP, or the SDK can do what every other app can do</p>
14:41 < jrandom> (which should be sufficient [the functionality / API is modelled after JMS and MOMs, which has been battle tested for well over a decade in industry])</p>
14:43 < cat-a-puss> ok, so I've essencialy got: Tcp, datagram, both of those + anonymity if I want it, and a DHT that operates above all that.</p>
14:44 < hypercubus> you have some anonymity, whether you like it or not ;-)</p>
14:44 < cat-a-puss> so the app cannot set the tunnel lenth to 0 even if it wants to?</p>
14:44 < jrandom> right - i2p itself is the TCP/datagram stuff, and the enclave DHT app could be used as a base for the data store</p>
14:44 < jrandom> absolutely</p>
14:45 < jrandom> in fact, with 0 hop tunnels and the defense Connelly outlined last week, it can be pretty anon vs some attackers</p>
14:45 < jrandom> er, i misread what you said. yes the app can set the tunnel length to 0, but in fact, that still provides some degree of anonymity</p>
14:46 < cat-a-puss> ok</p>
14:46 < jrandom> (sufficient for some people, but insufficient vs some statistical attacks)</p>
14:46 < hypercubus> if you wanted no anonymity, you shouldn't be running your traffic over i2p</p>
14:47 < cat-a-puss> and different apps on the same host/port I assume are just handled with seperate keys?</p>
14:47 < jrandom> exactly</p>
14:47 < deer> &lt;DrWoo&gt; low anonymity could be popular for running p2p over I2P ?</p>
14:47 < cat-a-puss> then the only question I have left is some sort of an "answering service"</p>
14:47 < jrandom> right DrWoo - filesharing / etc would probably be able to use 0 hop tunnels</p>
14:48 < deer> &lt;DrWoo&gt; hey soros!</p>
14:48 < hypercubus> i'm thinking BitTorrent-style apps on i2p would likely need 0-1 hop tunnels</p>
14:48 < Connelly> jrandom: which defense for 0 hop tunnels?</p>
14:48 < deer> &lt;soros&gt; hey woo :D</p>
14:48 < deer> &lt;DrWoo&gt; soros: you were hiding hehe</p>
14:48 < cat-a-puss> IE: set something up in the i2p database where my traffic goes to someone else while I am offline, and then when I come back up I contact them and they fill me in on what I missed?</p>
14:48 < cat-a-puss> they needn't be able to decrypt it</p>
14:48 < deer> &lt;soros&gt; gave up on iip for a few months</p>
14:48 < dm> soros and drwoo reunion...</p>
14:48 < dm> TEAR</p>
14:48 < hypercubus> cat-a-puss: again, app layer stuff</p>
14:49 < jrandom> cat-a-puss: i don't know, that sort of functionality i hadn't really envisioned w/ myi2p, but there are a few ways to do it</p>
14:49 < deer> &lt;soros&gt; is this going to freenode automatically ?</p>
14:49 < deer> &lt;soros&gt; oops.. this is i2p sorry</p>
14:49 < jrandom> Connelly: using strict ordering for the peers in the tunnel</p>
14:49 < deer> &lt;DrWoo&gt; soros: it's a little confusing lol</p>
14:50 < Connelly> ok</p>
14:50 < hypercubus> we need to run a poll on the forum to vote for a new name for myI2P ;-)</p>
14:51 < jrandom> betty</p>
14:51 < hypercubus> MyBetty?</p>
14:51 < dm> MY TOOPIE</p>
14:51 < jrandom> heh</p>
14:51 < deer> &lt;Nightblade&gt; how about acropolis....... was that it?</p>
14:51 < hypercubus> Betty Toop?</p>
14:51 < deer> &lt;soros&gt; MOAP2P</p>
14:51 < deer> &lt;DrWoo&gt; I2P H@ME</p>
14:51 < deer> &lt;soros&gt; Mother of all P2P</p>
14:52 < hypercubus> nightblade: yeah, acropolis</p>
14:52 < hypercubus> i like it</p>
14:53 < dm> How about: Pipi in your face</p>
14:53 < hypercubus> dm: you do know this is all going in the meeting log right? ;-)</p>
14:53 < Connelly> man, I got a great idea</p>
14:53 < deer> &lt;DrWoo&gt; Center of the Known I2P</p>
14:53 < dm> hypercubus: pipi in your face</p>
14:53 < Connelly> let's integrate a 3D user-programmable RPG into I2P H@ME</p>
14:53 < deer> &lt;soros&gt; call it HyperCube.</p>
14:54 < Connelly> and use Mozilla technology to do it :)</p>
14:54 < dm> Maxthon pipi on mozilla</p>
14:54 < Connelly> fine, Maxthon</p>
14:54 < hypercubus> you on a xul kick connelly? ;-)</p>
14:54 < Connelly> yeah!</p>
14:55 < Connelly> but we should create a whole XML-based programming language</p>
14:55 < Connelly> it would be more flexible that way</p>
14:55 < jrandom> and then lets build our own hardware too</p>
14:55 < hypercubus> i2p custom wireless mesh routers</p>
14:55 < jrandom> and put together a distribution company with ships and trains to get 'em out there! :)</p>
14:55 < dm> I know CPUs</p>
14:55 < dm> I build one</p>
14:56 < deer> &lt;mule&gt; plus build the chip production facilities ...</p>
14:56 < Connelly> yeah, an anonymous shipping corporation</p>
14:56 < hypercubus> call it WhoEx</p>
14:56 < Connelly> and use reflectors on the moon to beam laser internet traffic to each other!</p>
14:57 < hypercubus> time to boof the meeting i sense</p>
14:57 < jrandom> on that not..</p>
14:57 < jrandom> er, note</p>
14:57 < jrandom> anything else people want to bring up? if not, we've got the forums and the mailing list</p>
14:57 < jrandom> (and we're here all the time ;)</p>
14:57 * jrandom winds up</p>
14:57 < dm> not me, I have a life.</p>
14:57 < dm> LOSERS</p>
14:57 < dm> NEEEEEEEEEEEEEEEERRRRRRRRRDDDDDDDSSSSS</p>
14:57 * jrandom *baf*s dm on the head</p>
14:58 < jrandom> (closing the meeting)</p>
</div>
{% endblock %}
14:02 < jrandom> 0) hi
14:02 < jrandom> 1) 0.3.3 &amp; current updates
14:02 < jrandom> 2) NativeBigInteger
14:03 < jrandom> 3) ???
14:03 < jrandom> 0) hi
14:03 * jrandom waves
14:03 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2004-July/000372.html
14:03 < jrandom> (thanks to hypercubus' prodding i got it out before the meeting :)
14:04 < jrandom> ok, jumping on in
14:04 < jrandom> 1) 0.3.3 &amp; current updates
14:06 < jrandom> there's a truckload of info in the email describing whats going on, and there should be a substantial reduction in bandwidth usage coming up
14:07 < jrandom> it won't be backwards compatible because it changes a lot of things, so the next release will be a bumpy upgrade as well, but c'est la vie
14:08 < jrandom> anyone have any questions wrt the 0.3.3 rev or the things posted in the status notes?
14:08 * dm waves
14:08 * jrandom is seeing 23s lag here @ freenode
14:09 * hypercubus sees 0.10 secs lag
14:09 < jrandom> ah back to normal
14:09 < jrandom> ok, if there's nthing, we can just jump in to 2) NativeBigInteger
14:10 < jrandom> Iakin3 has modified some things so it'll be simpler to deploy the crypto code out of the box, which is Good
14:10 < jrandom> every once in a while i look in the netDb and see some people with 2-400ms delays when doing ElGamal encryption, which means some people aren't using jbigi
14:11 < jrandom> (and everyone should use jbigi)
14:12 < deer> <Nightblade> how do you know they are not just on slow computers
14:12 < Sonium> why isn't it use automaticaly?
14:12 < hypercubus> because it must be custom compiled for each platform
14:12 < jrandom> we might be able to get that deployed in this next rev, but we'll see
14:12 < deer> <oOo> If the DLL is not present, the program continue using java-only code (needed for cross-platform support)
14:12 < hypercubus> and currently the platform is not detected
14:12 < jrandom> Nightblade: thats possible, of course
14:13 < jrandom> oOo right, we definitely will keep that functionality
14:13 < deer> <oOo> Nope, force the existence of the dll an .so files, even if empty or useless
14:13 < jrandom> actually, thats another one of the things we're gaining with some of the current mods i'm working on - we only need to do half as many elGamal encryptions (since the sourceRouteBlock is gone)
14:14 < jrandom> hmm oOo?
14:14 < jrandom> why would we want to do that?
14:15 < deer> <oOo> Force a check of the _existence_ of the library files. If they are not use, you most likely aren't on a x86 Win/Linux platform and are forced to use the Java code. Anyway you did your best to force the use of native stuff
14:15 < jrandom> oh, right, we have always checked for libjbigi.so / jbigi.dll, the thing Iakin's code adds is the ability to package up a whole bunch of DLL and .so files into a jar and choose the *right* one at runtime
14:16 < hypercubus> </obvious>
14:16 < jrandom> (falling back on pure java if none match)
14:17 < jrandom> anyway, thats some good stuff that'll hopefully help new users out a bunch
14:17 < jrandom> (and saves me the time of doing some ugly drop down boxes on the admin interface :)
14:18 < jrandom> ok, if there's nothing more on that, i think thats all i've got
14:18 < jrandom> so moving on to 3) ???
14:18 < jrandom> anyone else have anything they want to bring up?
14:18 < hypercubus> someone should run a spellchecker on the new website ;-)
14:19 < jrandom> you've got cvs access now... :)
14:19 < jrandom> (module: i2pwww)
14:19 < hypercubus> damn
14:19 < deer> <oOo> The corruption on big transfer, even local one, is under investigation (like grabbing several Mb from your own eepsite) ?
14:20 < hypercubus> i've had many interrupted downloads of big files, but never a corruption
14:20 < jrandom> hmm, most instances of that issue have been resolved, but i've heard reports recently about it. i haven't gone through the app layer and audited things yet again
14:21 < jrandom> i consider interrupted downloads corrupted
14:21 < jrandom> it must work first time, all the way through
14:21 < hypercubus> well you can't help it, because that's what happens on the real WWW too ;-)
14:21 < deer> <oOo> Not when the grabber is on the same computer then the server ^^
14:22 < jrandom> oOo: can you reproduce that?
14:22 < jrandom> (or is it intermittent?)
14:22 < deer> <oOo> jrandom: Did twice, was thinking it was knowed, will try again
14:23 < jrandom> thanks. if you can reproduce it, please let me know the details of the test and i'll dig further into it.
14:23 < jrandom> (i've got to audit the app layer again anyway soo)
14:23 < deer> <oOo> jrandom: No problem, thanks
14:24 < jrandom> ok, anyone else have anything they want to ask/bring up?
14:25 < cat-a-puss> I'm still interested in talking about how to do myI2P
14:25 < cat-a-puss> I may be able to bring a few people in in a few months
14:25 < jrandom> awesome!
14:26 < hypercubus> a class project? ;-)
14:26 < cat-a-puss> something like that ;-)
14:27 < jrandom> i think once we get 0.4 out there with the new web interface, it should be much easier to put together apps (like myi2p) w/ a web frontend
14:27 < cat-a-puss> so you think that can be done on the purely application layer?
14:27 < jrandom> absolutely
14:28 < jrandom> what else did you have in mind?
14:28 < cat-a-puss> well the network DB could be used to store metadata
14:28 < jrandom> ahh
14:28 < cat-a-puss> would it have access to that?
14:28 < hypercubus> *cough*
14:28 < jrandom> no, nothing has access to the netDb
14:29 < jrandom> we're able to work some magic in the netDb because its quite focused just on serving as our distributed routing table
14:29 < hypercubus> cat-a-puss: what you want is the DHT that Nightblade is working on
14:29 < jrandom> myi2p (et al) could certainly use a DHT on top of i2p though
14:30 < hypercubus> (enclave)
14:30 < jrandom> what sort of metadata were you thinking about?
14:31 < cat-a-puss> well I invesioned doing something like chanels in Frost which runs off of an ssk in freenet
14:31 < cat-a-puss> so you run the ssks on the DHT on top of I2p
14:31 < jrandom> right
14:31 < jrandom> that might be a bit of an overkill for some things though
14:31 < cat-a-puss> but you still need a metakey that lists all the people's ssks that are subscribed to the channel
14:32 < dm> dht over i2p...
14:32 * dm doesn't see that working reliable any time soon.
14:32 < Connelly> a generic DHT library would be nice
14:32 < dm> reliably
14:32 < deer> <Nightblade> what's a dht library
14:32 < cat-a-puss> that needs to work diferently ...
14:33 < jrandom> cat-a-puss: i suppose it depends on what sort of activity would go on, but while frost style boards might be good for some things, fmb style boards might be good for others, and blog aggregators might be good for still others
14:34 < Connelly> well a kademlia implementation or somesuch
14:34 < Connelly> I assume enclave would be something like it
14:34 < deer> <Nightblade> i think i'm going to do some changes on LibSAM first
14:34 < deer> <Nightblade> only two weeks of classes left, for me, counting this week
14:34 < deer> <Nightblade> then I will be able to do some stuff I hope
14:35 < jrandom> w00t! :)
14:37 < cat-a-puss> jrandom: basicly the goal is to be all things to all people. If the network does not do everything, people will use something else. (and it needs to be better at it to attract cover traffic)
14:38 < jrandom> i've worked on too many projects that try to do the 'swiss army knife' style - if you build it, they will come
14:38 < hypercubus> the network is a transport layer, not the application layer ;-)
14:38 < jrandom> it very, very, very rarely works out.
14:38 < jrandom> the i2p transport layer should support all possible point to point comm, definitely
14:38 < jrandom> but applications on top of i2p should be user friendly - meaning they address a specific user need and help them with it
14:39 < jrandom> the masses don't want a comm layer, they want a way to talk to people, to read what people say, and to explore
14:39 < Connelly> naw, we should create an XUL, and all new Gecko system
14:39 < Connelly> then build a conglomerate of Mozilla programs on top of that
14:39 < Connelly> then integrate collaborative systems into Mozilla ;)
14:40 < cat-a-puss> great provided the app has enough control over the comm layer to make it do what it wants.
14:40 < dm> Maxthon > Mozilla
14:40 < jrandom> cat-a-puss: absolutely. all apps using SAM, I2CP, or the SDK can do what every other app can do
14:41 < jrandom> (which should be sufficient [the functionality / API is modelled after JMS and MOMs, which has been battle tested for well over a decade in industry])
14:43 < cat-a-puss> ok, so I've essencialy got: Tcp, datagram, both of those + anonymity if I want it, and a DHT that operates above all that.
14:44 < hypercubus> you have some anonymity, whether you like it or not ;-)
14:44 < cat-a-puss> so the app cannot set the tunnel lenth to 0 even if it wants to?
14:44 < jrandom> right - i2p itself is the TCP/datagram stuff, and the enclave DHT app could be used as a base for the data store
14:44 < jrandom> absolutely
14:45 < jrandom> in fact, with 0 hop tunnels and the defense Connelly outlined last week, it can be pretty anon vs some attackers
14:45 < jrandom> er, i misread what you said. yes the app can set the tunnel length to 0, but in fact, that still provides some degree of anonymity
14:46 < cat-a-puss> ok
14:46 < jrandom> (sufficient for some people, but insufficient vs some statistical attacks)
14:46 < hypercubus> if you wanted no anonymity, you shouldn't be running your traffic over i2p
14:47 < cat-a-puss> and different apps on the same host/port I assume are just handled with seperate keys?
14:47 < jrandom> exactly
14:47 < deer> <DrWoo> low anonymity could be popular for running p2p over I2P ?
14:47 < cat-a-puss> then the only question I have left is some sort of an "answering service"
14:47 < jrandom> right DrWoo - filesharing / etc would probably be able to use 0 hop tunnels
14:48 < deer> <DrWoo> hey soros!
14:48 < hypercubus> i'm thinking BitTorrent-style apps on i2p would likely need 0-1 hop tunnels
14:48 < Connelly> jrandom: which defense for 0 hop tunnels?
14:48 < deer> <soros> hey woo :D
14:48 < deer> <DrWoo> soros: you were hiding hehe
14:48 < cat-a-puss> IE: set something up in the i2p database where my traffic goes to someone else while I am offline, and then when I come back up I contact them and they fill me in on what I missed?
14:48 < cat-a-puss> they needn't be able to decrypt it
14:48 < deer> <soros> gave up on iip for a few months
14:48 < dm> soros and drwoo reunion...
14:48 < dm> TEAR
14:48 < hypercubus> cat-a-puss: again, app layer stuff
14:49 < jrandom> cat-a-puss: i don't know, that sort of functionality i hadn't really envisioned w/ myi2p, but there are a few ways to do it
14:49 < deer> <soros> is this going to freenode automatically ?
14:49 < deer> <soros> oops.. this is i2p sorry
14:49 < jrandom> Connelly: using strict ordering for the peers in the tunnel
14:49 < deer> <DrWoo> soros: it's a little confusing lol
14:50 < Connelly> ok
14:50 < hypercubus> we need to run a poll on the forum to vote for a new name for myI2P ;-)
14:51 < jrandom> betty
14:51 < hypercubus> MyBetty?
14:51 < dm> MY TOOPIE
14:51 < jrandom> heh
14:51 < deer> <Nightblade> how about acropolis....... was that it?
14:51 < hypercubus> Betty Toop?
14:51 < deer> <soros> MOAP2P
14:51 < deer> <DrWoo> I2P H@ME
14:51 < deer> <soros> Mother of all P2P
14:52 < hypercubus> nightblade: yeah, acropolis
14:52 < hypercubus> i like it
14:53 < dm> How about: Pipi in your face
14:53 < hypercubus> dm: you do know this is all going in the meeting log right? ;-)
14:53 < Connelly> man, I got a great idea
14:53 < deer> <DrWoo> Center of the Known I2P
14:53 < dm> hypercubus: pipi in your face
14:53 < Connelly> let's integrate a 3D user-programmable RPG into I2P H@ME
14:53 < deer> <soros> call it HyperCube.
14:54 < Connelly> and use Mozilla technology to do it :)
14:54 < dm> Maxthon pipi on mozilla
14:54 < Connelly> fine, Maxthon
14:54 < hypercubus> you on a xul kick connelly? ;-)
14:54 < Connelly> yeah!
14:55 < Connelly> but we should create a whole XML-based programming language
14:55 < Connelly> it would be more flexible that way
14:55 < jrandom> and then lets build our own hardware too
14:55 < hypercubus> i2p custom wireless mesh routers
14:55 < jrandom> and put together a distribution company with ships and trains to get 'em out there! :)
14:55 < dm> I know CPUs
14:55 < dm> I build one
14:56 < deer> <mule> plus build the chip production facilities ...
14:56 < Connelly> yeah, an anonymous shipping corporation
14:56 < hypercubus> call it WhoEx
14:56 < Connelly> and use reflectors on the moon to beam laser internet traffic to each other!
14:57 < hypercubus> time to boof the meeting i sense
14:57 < jrandom> on that not..
14:57 < jrandom> er, note
14:57 < jrandom> anything else people want to bring up? if not, we've got the forums and the mailing list
14:57 < jrandom> (and we're here all the time ;)
14:57 * jrandom winds up
14:57 < dm> not me, I have a life.
14:57 < dm> LOSERS
14:57 < dm> NEEEEEEEEEEEEEEEERRRRRRRRRDDDDDDDSSSSS
14:57 * jrandom *baf*s dm on the head
14:58 < jrandom> (closing the meeting)

10
i2p2www/meetings/100.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, July 27, XXXX
==============================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,221 +1,215 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 101{% endblock %}
{% block content %}<h3>I2P dev meeting, August 3 @ 21:00 GMT</h3>
<div class="irclog">
14:05 <jrandomi2p> 0) hi</p>
14:05 <jrandomi2p> 1) 0.3.4 status</p>
14:05 <hypercubus> i guarantee that on PDforge your project will be confirmed virtually immediately ;-)</p>
14:05 <jrandomi2p> 2) On deck for 0.3.4.1</p>
14:05 <jrandomi2p> 3) New web console / I2PTunnel controller</p>
14:05 <jrandomi2p> 4) 0.4 stuff</p>
14:05 <jrandomi2p> 5) Other development activities</p>
14:05 <jrandomi2p> 6) ???</p>
14:05 <jrandomi2p> 0) hi</p>
14:05 * jrandomi2p waves</p>
14:05 < mihi> lla ih</p>
14:05 * oOo goof</p>
14:06 <mihi> hi all</p>
14:06 <jrandomi2p> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2004-August/000388.html</p>
14:06 <jrandomi2p> jumping right in to 1) 0.3.4 status</p>
14:07 <jrandomi2p> the net seems generally functional, both for irc and eepsites</p>
14:07 <jrandomi2p> what kind of eepsite reliability / failures are y'all seeing?</p>
14:07 * jrandomi2p can see the irc failures here, as i see when people disconnect / etc</p>
14:08 <mule2p> in general good, got out-of-memory after approx 25MBytes</p>
14:08 <mule2p> but that should be fixed in cvs, as you mentioned</p>
14:08 <jrandomi2p> ah ok thats on a single 25MB download right?</p>
14:09 <mule2p> yes</p>
14:09 <jrandomi2p> right</p>
14:10 <jrandomi2p> large file transfers do still seem to have problems (disconnect over time, not corruption though). i think that may be fixed with the mod mentioned, but i'm not sure</p>
14:11 * jrandomi2p forgot to mention that oOo's roundtrip/connections_reliability.php includes both irc servers here, not just i2p, so doesnt really have the right data atm</p>
14:11 <jrandomi2p> oOo - any thoughts on what it'd take to get the bogobot code to ignore @irc.metropipe.net?</p>
14:12 < duck> kicking hypercubus</p>
14:12 < duck> and me to upgrade</p>
14:12 <oOo> Very few coding, a peer review by hypercubus and the update of bogobot by duke</p>
14:13 <jrandomi2p> ok cool</p>
14:13 <hypercubus> duke?</p>
14:13 <oOo> duck, sorry :p</p>
14:13 * jrandomi2p thinks that sort of statistical summary would be very helpful</p>
14:13 <jrandomi2p> duke duck</p>
14:14 <oOo> The stats are made on PHP, could be given to duck, too</p>
14:14 <jrandomi2p> ok, anyone have anything to bring up wrt 0.3.4?</p>
14:14 <jrandomi2p> w3rd</p>
14:15 <jrandomi2p> ok, moving on to 2) 0.3.4.1</p>
14:15 <jrandomi2p> i dont know what else to mention beyond whats mentioned in the mail</p>
14:16 <jrandomi2p> the StreamSinkServer and StreamSinkClient apps are compact demo apps for ministreaming (for any java devs who want to write streaming over i2p)</p>
14:16 <jrandomi2p> oh, and StreamSinkServer is kind of like aum's dropbox python app (it takes any data anyone sends it and writes it to a file)</p>
14:17 <jrandomi2p> (StreamSinkClient sends a fixed size of random data, so not too useful ;)</p>
14:17 <jrandomi2p> any thoughts / concerns / questions wrt 0.3.4.1?</p>
14:18 * jrandomi2p estimates it'll be out in a day or two</p>
14:19 <jrandomi2p> ok, moving on at a good clip to 3) New web console / I2PTunnel controller</p>
14:20 <jrandomi2p> as mentioned in the mail, we've got the new web console pretty much functional, and a simple web interface to control / edit / create i2ptunnel instances</p>
14:21 < protok0l> where can the protok0l get it</p>
14:22 < protok0l> and what do i do with jetty</p>
14:22 <jrandomi2p> its all in cvs now, but i need to put up some docs on how to set it up</p>
14:22 < protok0l> ok</p>
14:23 * jrandomi2p wrote up and posted a ~5 step process to the channel a few days ago, but we need a simpler proc (or at least a more clear one)</p>
14:23 < protok0l> i heard that CVS sucks</p>
14:23 <mule2p> ok, can tell you once i have the docs :)</p>
14:23 < protok0l> and there was some better CVS thingy</p>
14:23 * oOo logged only the first 2 steps before getting disconnected :p</p>
14:24 < protok0l> same thing with Vi</p>
14:24 < protok0l> lol</p>
14:24 <jrandomi2p> we'll eventually moving to have this new console be the 'standard', but that'll probably wait until we've got everything integrated with hypercubus' new installer</p>
14:26 <jrandomi2p> actually</p>
14:26 <jrandomi2p> for the brave, here's the ugly steps from before:</p>
14:26 <jrandomi2p> 20:19 &lt; jrandom&gt; w3rd hyper - could you pull latest from cvs, 'ant dist', grab build/*jar and toss them into your lib dir, mkdir $instDir/webapps/ ; cp build/routerconsole.war $instDir/webapps/ ; edit your router.config to uncomment the clientApp.3.* lines and update your classpath</p>
14:26 <jrandomi2p> 20:19 &lt; jrandom&gt; (in the classpath, set it to: lib/i2p.jar:lib/router.jar:lib/mstreaming.jar:lib/heartbeat.jar:lib/i2ptunnel.jar:lib/netmonitor.jar:lib/sam.jar:lib/timestamper.jar:lib/ant.jar:lib/jasper-compiler.jar:lib/jasper-runtime.jar:\</p>
14:26 <jrandomi2p> 20:19 &lt; jrandom&gt; lib/jnet.jar:lib/org.mortbay.jetty.jar:lib/routerconsole.jar:lib/xercesImpl.jar:lib/xml-apis.jar:lib/javax.servlet.jar</p>
14:26 < protok0l> ok screw it</p>
14:27 <jrandomi2p> in addition to that, there's a new i2ptunnel.war - take that and drop it into $instDir/webapps/ and go to http://localhost:7657/i2ptunnel/</p>
14:27 <jrandomi2p> yeah, as i said, its a pain</p>
14:27 <jrandomi2p> *but* its functional, and I dont really have either the time or the expertise to make it much better</p>
14:27 <oOo> That's all it needs to be done ?</p>
14:28 <jrandomi2p> yup</p>
14:28 <oOo> Ok, thanks</p>
14:28 <jrandomi2p> (you'll get something looking like http://dev.i2p.net/~jrandom/config.png when you go to http://localhost:7657/config.jsp</p>
14:29 <jrandomi2p> anyway, thats that</p>
14:29 <jrandomi2p> i'd appreciate if/when people can kick it around, and hopefully come up with ways to improve it :)</p>
14:30 <jrandomi2p> mihi: any thoughts on the whole web interface idea?</p>
14:30 < duck> nice layout</p>
14:31 <jrandomi2p> thought you'd like it duck ;)</p>
14:31 <mrflibble> nice</p>
14:31 * mihi likes the layout as well</p>
14:31 <mihi> web interfaces are always great</p>
14:32 <jrandomi2p> the one i put together for i2ptunnel.war is pretty bland... functional, but bland</p>
14:33 <jrandomi2p> ok, thats that - if/when people wanna chat about it further, we've got irc and the list, etc :)</p>
14:33 <mule2p> jrandomi2p: clientApp.3 is netmonitor for me</p>
14:34 <jrandomi2p> ah ok mule2p - check the router.config from cvs -</p>
14:34 <jrandomi2p> #clientApp.3.main=net.i2p.router.web.RouterConsoleRunner</p>
14:34 <jrandomi2p> #clientApp.3.name=webConsole</p>
14:34 <jrandomi2p> #clientApp.3.args=7657 127.0.0.1 ./webapps/</p>
14:34 <jrandomi2p> obviously change the 3 to 4 and uncomment :)</p>
14:35 <jrandomi2p> replace 127.0.0.1 if you want to be able to access it remotely</p>
14:35 <jrandomi2p> (and 7657 to use a different port)</p>
14:36 <mule2p> ok, thanks, have looked in the checked out i2p tree for a new router.config, but it may be elsewhere in cvs</p>
14:36 <jrandomi2p> ah sorry, yeah its i2p/installer/java/src/router.config.template</p>
14:37 <mule2p> k</p>
14:37 <jrandomi2p> ok, unless there's anything else, swinging on to 4) 0.4 stuff </p>
14:38 <jrandomi2p> hmm, i dont know if there's anything i can add to whats in that paragraph in the mail</p>
14:38 <jrandomi2p> basically just a bunch of entries on my todo list :)</p>
14:39 <jrandomi2p> anyone have any questions / concerns wrt things posted there?</p>
14:40 <oOo> How is the installer doing ? ^^</p>
14:40 <jrandomi2p> hypercubus? que tal?</p>
14:40 <hypercubus> patience, danielsan... good things come to those who chafe... uh, wait ;-)</p>
14:40 <jrandomi2p> hehe</p>
14:41 <jrandomi2p> no rush, just wondering how things are goin'</p>
14:41 <jrandomi2p> any problems you're running into, things we can help with, etc?</p>
14:41 <mihi> who is danielsan?</p>
14:41 <hypercubus> no problems, just the tedium of testing atm</p>
14:42 <jrandomi2p> w3rd</p>
14:42 <hypercubus> i should have written unit tests first, but oh well ;-)</p>
14:42 <jrandomi2p> hehe</p>
14:43 <hypercubus> java's supposed platform independence really breaks down in the area of installation tasks</p>
14:44 * jrandom senses a bulk disconnect</p>
14:45 <oOo> Uh oh</p>
14:45 <hypercubus_> hmmm, wonderful... what was the last thing i said?</p>
14:45 <oOo> &lt;hypercubus&gt; java's supposed platform independence really breaks down in the area of installation tasks</p>
14:46 <hypercubus> ok, who sabotaged the meeting? ;-)</p>
14:46 * jrandom blames jebus</p>
14:46 <hypercubus> maybe it was duke</p>
14:46 <mule> you don't want to tell me my router is that important :)</p>
14:46 < jrandom> heh</p>
14:47 <mihi> [23:46] * jrandomi2p has quit IRC (Client exited)</p>
14:47 <mihi> hehe...</p>
14:47 <mule> if so, sorry.</p>
14:47 <hypercubus> anyhow, no worries about the installer's progress, i fully expect it to be ready when 0.4 is</p>
14:47 < jrandom> duck: how many inbound tunnels do you have listening on irc.duck.i2p? </p>
14:47 <hypercubus> i'm not running into any head-scratchers</p>
14:47 < jrandom> cool hypercubus</p>
14:47 < hobbs> Reminds me -- is there a commandline-accessible way to spit out a new router.config from router.config.template?</p>
14:47 < jrandom> nope</p>
14:48 < jrandom> not afaik</p>
14:48 < mihi> run the installer and copy it</p>
14:48 < jrandom> other than java -jar install.jar </p>
14:48 < jrandom> heh</p>
14:48 < mihi> into a new dir i mean</p>
14:48 < cervantes> at least not the head scratching you're all thinking of</p>
14:48 < jrandom> ooh neat, my router dumped core</p>
14:48 < duck> jrandom: remind me how I know the hash of irc.duck.i2p</p>
14:48 * hypercubus wonders what cervantes means</p>
14:49 < jrandom> cd lib ; java -cp i2p.jar net.i2p.data.TestData display Destination ../irc.privKey</p>
14:49 < cervantes> hyper: you'd be more familiar with the term strunking :)</p>
14:49 <hypercubus> duck: try increasing to 3 or more inbound tunnels... seems to have helped me some</p>
14:50 < duck> *** Building a seperate global context!</p>
14:50 < duck> Log file logger.config does not exist</p>
14:50 < duck> 23:49:47.387 ERROR [main ] net.i2p.util.LogManager : Log file logger.config does not exist</p>
14:50 < duck> 23:49:49.589 CRIT [ 1 shutdown ] net.i2p.util.LogManager : Shutting down logger</p>
14:50 < jrandom> ah hrm</p>
14:50 <hypercubus> guess it couldn't handle your log *cough*</p>
14:51 < mihi> copy your logger.config everywhere ;)</p>
14:51 < mihi> at least everywhere where your pwd could be when you run any i2p app</p>
14:51 < duck> no I wont</p>
14:51 < jrandom> ok, echo logger.record.net.i2p.data.TestData=INFO &gt;&gt; logger.config</p>
14:52 < jrandom> actually, thats why i said (cd lib), but i forgot that i changed the default from DEBUG to ERROR in cvs</p>
14:52 < duck> 4 inbounds</p>
14:52 < jrandom> 4 current &amp; ready?</p>
14:52 < jrandom> or 2 not ready (or recently expired) and 2 ready?</p>
14:53 < duck> now it changed to 3 with 1 not ready</p>
14:53 < jrandom> 'k so its probably during tunnel expiration / replacement</p>
14:54 <jrandomi2p> if you update your router.config to specify 3 inbound tunnels that should help with reliability</p>
14:54 <jrandomi2p> (or you can use the new i2ptunnel web interface to do it ;)</p>
14:54 <hypercubus> perhaps tunnel expiration for a single client with multiple tunnels should be staggered</p>
14:55 <jrandomi2p> they are, generally - new tunnels are allocated &amp; a new leaseSet created 60s before tunnel expiration</p>
14:55 <hypercubus> ah</p>
14:55 <jrandomi2p> however, during tunnel failure it has to create a new leaseSet on demand which doesnt immediately propogate</p>
14:56 <jrandomi2p> (well, it goes out on the netDb, but clients wont get that for up to a few seconds)</p>
14:57 <jteitel> !who</p>
14:57 < alpaca_> Userlist for #i2p: [hobbs] [Iakin3] [duck] [pwk__] [Sonium] [jar] [alpaca_] [interrupt] [protok0l] [mihi] [aum] [Shaun-Away] [cervantes] [jrandom] [deer] [hirvox] [Bladenight] </p>
14:57 <bogobot> Userlist for #i2p: [shendaras] [duck] [josh] [mule2p] [aum] [mrflibble] [hypercubus] [TrueSeeker] [laggybot] [bogobot] [ion_] [mihi] [ion] [mule] [jteitel] [ant] [oOo_] [jrandomi2p] [dm] [ugha2p] [Ch0Hag] [jnk] [oOo] [soros] [bob] [revival] [DrWoo] [thetower] </p>
14:57 <jrandomi2p> there are some further optimizations that can be done to the tunnel pool, but i'm not sure how useful it'd be atm</p>
14:57 <jrandomi2p> ok, jumping back on track - anyone else have anything wrt 4) 0.4. stuff?</p>
14:57 <oOo> About 'large scale simulations' for 0.4, any way to prepare thus ? Need 'new' specifics applications/tools ? (transition to point 5 ? ;) )</p>
14:58 <jrandomi2p> actually, for the sim it would be great if someone could help mod the heartbeat (or a sam-powered app) to be kind of a scriptable client / server</p>
14:59 -!- Bladenight is now known as Nightblade</p>
14:59 <jrandomi2p> (e.g. rather than the current "every 30s, send 20KB to peer X", a "for 10 minutes, ask peer X for a 1MB file, and then pause for 60m, then ask peer Y for 1KB files" etc)</p>
15:00 <jrandomi2p> but if someone is interested in helping out with that, please let me know and we can chan</p>
15:00 <jrandomi2p> er, chat</p>
15:00 <jrandomi2p> taking that lead in, lets jump to 5) stuff y'all are doing :)</p>
15:01 <jrandomi2p> not sure how to go about covering this, lets just go down in the (arbitrary) order listed in the mail for updates?</p>
15:01 <jrandomi2p> i dont see sunshine here, and aum probably isn't up yet ;)</p>
15:02 <jrandomi2p> nightblade - how goes the battle? </p>
15:02 < Nightblade> i have some plans for making the libsam interface like bsd sockets</p>
15:02 < Nightblade> but i haven't done any coding on that part yet</p>
15:02 < duck> changed to tunnels.numInbound=3</p>
15:03 <jrandomi2p> cool duck (hopefully wait until after the meeting to restart your tunnel ;)</p>
15:03 < duck> oh, it doesnt detect the changes?</p>
15:03 <jrandomi2p> word nightblade - is there a problem w/ the way things are now?</p>
15:03 <hypercubus> not until you code it to ;-)</p>
15:03 <jrandomi2p> naw duck, the clientApp lines are only read on startup</p>
15:04 <jrandomi2p> (clientApp is really outside the control of the router - thats what the i2ptunnel web app is for)</p>
15:04 < Nightblade> no there is no problem with it the way it is now.... what i would be doing is in addition to the interface that is already there (developers could choose what they want to use)</p>
15:04 <jrandomi2p> wikked</p>
15:05 <jrandomi2p> ok, you're the boss. having variety is good, though variety means more code to maintain / etc, but its a balance</p>
15:06 <jrandomi2p> ok, moving on down the list - mule2p - how goes the outproxy stuff?</p>
15:07 <mule> nothing done beyond the patch you have</p>
15:07 <jrandomi2p> ah ok i thought you were working on a further mod</p>
15:07 <mule> need to find some spare time for real load balancing</p>
15:07 <jrandomi2p> w3rd</p>
15:08 <jrandomi2p> i'll get that patch applied then</p>
15:08 <mule> thanks. and include my outproxy in the client app :) seems to be faster</p>
15:08 <jrandomi2p> heh, well, of course your proxy will be faster for you, its local :)</p>
15:09 <oOo> And no one else use it ^^</p>
15:09 <mule> no, it isn't</p>
15:09 <jrandomi2p> ooh, its on a different router? cool</p>
15:09 <mule> yep, on a root server at an isp</p>
15:10 <jrandomi2p> the i2ptunnel web interface has a field for people to specify the list of outproxies, so it should be easy enough for people to tweak, but we'll get it out in the next rev &amp; release notes</p>
15:10 <jrandomi2p> nice</p>
15:11 <jrandomi2p> ok, nickster seems to be offline atm</p>
15:12 <jrandomi2p> are there any other active client development efforts going on?</p>
15:12 <jrandomi2p> (or are any of the paused ones active, etc?)</p>
15:13 <jrandomi2p> ok, if someone wants to mention anything else on that front, we've got the list and the channel, as always :)</p>
15:13 <jrandomi2p> moving on to 6) ???</p>
15:13 <jrandomi2p> anyone else have anything they want to bring up?</p>
15:14 < Nightblade> nope</p>
15:15 <mihi> duck has anything to bring down ;)</p>
15:15 <mihi> s/any/some/</p>
15:15 * jrandomi2p pingfloods mihi</p>
15:15 <jrandomi2p> ok, on that note</p>
15:15 * jrandomi2p winds up</p>
15:15 * jrandomi2p *baf*s the meeting closed</p>
</div>
{% endblock %}
14:05 <jrandomi2p> 0) hi
14:05 <jrandomi2p> 1) 0.3.4 status
14:05 <hypercubus> i guarantee that on PDforge your project will be confirmed virtually immediately ;-)
14:05 <jrandomi2p> 2) On deck for 0.3.4.1
14:05 <jrandomi2p> 3) New web console / I2PTunnel controller
14:05 <jrandomi2p> 4) 0.4 stuff
14:05 <jrandomi2p> 5) Other development activities
14:05 <jrandomi2p> 6) ???
14:05 <jrandomi2p> 0) hi
14:05 * jrandomi2p waves
14:05 < mihi> lla ih
14:05 * oOo goof
14:06 <mihi> hi all
14:06 <jrandomi2p> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2004-August/000388.html
14:06 <jrandomi2p> jumping right in to 1) 0.3.4 status
14:07 <jrandomi2p> the net seems generally functional, both for irc and eepsites
14:07 <jrandomi2p> what kind of eepsite reliability / failures are y'all seeing?
14:07 * jrandomi2p can see the irc failures here, as i see when people disconnect / etc
14:08 <mule2p> in general good, got out-of-memory after approx 25MBytes
14:08 <mule2p> but that should be fixed in cvs, as you mentioned
14:08 <jrandomi2p> ah ok thats on a single 25MB download right?
14:09 <mule2p> yes
14:09 <jrandomi2p> right
14:10 <jrandomi2p> large file transfers do still seem to have problems (disconnect over time, not corruption though). i think that may be fixed with the mod mentioned, but i'm not sure
14:11 * jrandomi2p forgot to mention that oOo's roundtrip/connections_reliability.php includes both irc servers here, not just i2p, so doesnt really have the right data atm
14:11 <jrandomi2p> oOo - any thoughts on what it'd take to get the bogobot code to ignore @irc.metropipe.net?
14:12 < duck> kicking hypercubus
14:12 < duck> and me to upgrade
14:12 <oOo> Very few coding, a peer review by hypercubus and the update of bogobot by duke
14:13 <jrandomi2p> ok cool
14:13 <hypercubus> duke?
14:13 <oOo> duck, sorry :p
14:13 * jrandomi2p thinks that sort of statistical summary would be very helpful
14:13 <jrandomi2p> duke duck
14:14 <oOo> The stats are made on PHP, could be given to duck, too
14:14 <jrandomi2p> ok, anyone have anything to bring up wrt 0.3.4?
14:14 <jrandomi2p> w3rd
14:15 <jrandomi2p> ok, moving on to 2) 0.3.4.1
14:15 <jrandomi2p> i dont know what else to mention beyond whats mentioned in the mail
14:16 <jrandomi2p> the StreamSinkServer and StreamSinkClient apps are compact demo apps for ministreaming (for any java devs who want to write streaming over i2p)
14:16 <jrandomi2p> oh, and StreamSinkServer is kind of like aum's dropbox python app (it takes any data anyone sends it and writes it to a file)
14:17 <jrandomi2p> (StreamSinkClient sends a fixed size of random data, so not too useful ;)
14:17 <jrandomi2p> any thoughts / concerns / questions wrt 0.3.4.1?
14:18 * jrandomi2p estimates it'll be out in a day or two
14:19 <jrandomi2p> ok, moving on at a good clip to 3) New web console / I2PTunnel controller
14:20 <jrandomi2p> as mentioned in the mail, we've got the new web console pretty much functional, and a simple web interface to control / edit / create i2ptunnel instances
14:21 < protok0l> where can the protok0l get it
14:22 < protok0l> and what do i do with jetty
14:22 <jrandomi2p> its all in cvs now, but i need to put up some docs on how to set it up
14:22 < protok0l> ok
14:23 * jrandomi2p wrote up and posted a ~5 step process to the channel a few days ago, but we need a simpler proc (or at least a more clear one)
14:23 < protok0l> i heard that CVS sucks
14:23 <mule2p> ok, can tell you once i have the docs :)
14:23 < protok0l> and there was some better CVS thingy
14:23 * oOo logged only the first 2 steps before getting disconnected :p
14:24 < protok0l> same thing with Vi
14:24 < protok0l> lol
14:24 <jrandomi2p> we'll eventually moving to have this new console be the 'standard', but that'll probably wait until we've got everything integrated with hypercubus' new installer
14:26 <jrandomi2p> actually
14:26 <jrandomi2p> for the brave, here's the ugly steps from before:
14:26 <jrandomi2p> 20:19 < jrandom> w3rd hyper - could you pull latest from cvs, 'ant dist', grab build/*jar and toss them into your lib dir, mkdir $instDir/webapps/ ; cp build/routerconsole.war $instDir/webapps/ ; edit your router.config to uncomment the clientApp.3.* lines and update your classpath
14:26 <jrandomi2p> 20:19 < jrandom> (in the classpath, set it to: lib/i2p.jar:lib/router.jar:lib/mstreaming.jar:lib/heartbeat.jar:lib/i2ptunnel.jar:lib/netmonitor.jar:lib/sam.jar:lib/timestamper.jar:lib/ant.jar:lib/jasper-compiler.jar:lib/jasper-runtime.jar:\
14:26 <jrandomi2p> 20:19 < jrandom> lib/jnet.jar:lib/org.mortbay.jetty.jar:lib/routerconsole.jar:lib/xercesImpl.jar:lib/xml-apis.jar:lib/javax.servlet.jar
14:26 < protok0l> ok screw it
14:27 <jrandomi2p> in addition to that, there's a new i2ptunnel.war - take that and drop it into $instDir/webapps/ and go to http://localhost:7657/i2ptunnel/
14:27 <jrandomi2p> yeah, as i said, its a pain
14:27 <jrandomi2p> *but* its functional, and I dont really have either the time or the expertise to make it much better
14:27 <oOo> That's all it needs to be done ?
14:28 <jrandomi2p> yup
14:28 <oOo> Ok, thanks
14:28 <jrandomi2p> (you'll get something looking like http://dev.i2p.net/~jrandom/config.png when you go to http://localhost:7657/config.jsp
14:29 <jrandomi2p> anyway, thats that
14:29 <jrandomi2p> i'd appreciate if/when people can kick it around, and hopefully come up with ways to improve it :)
14:30 <jrandomi2p> mihi: any thoughts on the whole web interface idea?
14:30 < duck> nice layout
14:31 <jrandomi2p> thought you'd like it duck ;)
14:31 <mrflibble> nice
14:31 * mihi likes the layout as well
14:31 <mihi> web interfaces are always great
14:32 <jrandomi2p> the one i put together for i2ptunnel.war is pretty bland... functional, but bland
14:33 <jrandomi2p> ok, thats that - if/when people wanna chat about it further, we've got irc and the list, etc :)
14:33 <mule2p> jrandomi2p: clientApp.3 is netmonitor for me
14:34 <jrandomi2p> ah ok mule2p - check the router.config from cvs -
14:34 <jrandomi2p> #clientApp.3.main=net.i2p.router.web.RouterConsoleRunner
14:34 <jrandomi2p> #clientApp.3.name=webConsole
14:34 <jrandomi2p> #clientApp.3.args=7657 127.0.0.1 ./webapps/
14:34 <jrandomi2p> obviously change the 3 to 4 and uncomment :)
14:35 <jrandomi2p> replace 127.0.0.1 if you want to be able to access it remotely
14:35 <jrandomi2p> (and 7657 to use a different port)
14:36 <mule2p> ok, thanks, have looked in the checked out i2p tree for a new router.config, but it may be elsewhere in cvs
14:36 <jrandomi2p> ah sorry, yeah its i2p/installer/java/src/router.config.template
14:37 <mule2p> k
14:37 <jrandomi2p> ok, unless there's anything else, swinging on to 4) 0.4 stuff
14:38 <jrandomi2p> hmm, i dont know if there's anything i can add to whats in that paragraph in the mail
14:38 <jrandomi2p> basically just a bunch of entries on my todo list :)
14:39 <jrandomi2p> anyone have any questions / concerns wrt things posted there?
14:40 <oOo> How is the installer doing ? ^^
14:40 <jrandomi2p> hypercubus? que tal?
14:40 <hypercubus> patience, danielsan... good things come to those who chafe... uh, wait ;-)
14:40 <jrandomi2p> hehe
14:41 <jrandomi2p> no rush, just wondering how things are goin'
14:41 <jrandomi2p> any problems you're running into, things we can help with, etc?
14:41 <mihi> who is danielsan?
14:41 <hypercubus> no problems, just the tedium of testing atm
14:42 <jrandomi2p> w3rd
14:42 <hypercubus> i should have written unit tests first, but oh well ;-)
14:42 <jrandomi2p> hehe
14:43 <hypercubus> java's supposed platform independence really breaks down in the area of installation tasks
14:44 * jrandom senses a bulk disconnect
14:45 <oOo> Uh oh
14:45 <hypercubus_> hmmm, wonderful... what was the last thing i said?
14:45 <oOo> <hypercubus> java's supposed platform independence really breaks down in the area of installation tasks
14:46 <hypercubus> ok, who sabotaged the meeting? ;-)
14:46 * jrandom blames jebus
14:46 <hypercubus> maybe it was duke
14:46 <mule> you don't want to tell me my router is that important :)
14:46 < jrandom> heh
14:47 <mihi> [23:46] * jrandomi2p has quit IRC (Client exited)
14:47 <mihi> hehe...
14:47 <mule> if so, sorry.
14:47 <hypercubus> anyhow, no worries about the installer's progress, i fully expect it to be ready when 0.4 is
14:47 < jrandom> duck: how many inbound tunnels do you have listening on irc.duck.i2p?
14:47 <hypercubus> i'm not running into any head-scratchers
14:47 < jrandom> cool hypercubus
14:47 < hobbs> Reminds me -- is there a commandline-accessible way to spit out a new router.config from router.config.template?
14:47 < jrandom> nope
14:48 < jrandom> not afaik
14:48 < mihi> run the installer and copy it
14:48 < jrandom> other than java -jar install.jar
14:48 < jrandom> heh
14:48 < mihi> into a new dir i mean
14:48 < cervantes> at least not the head scratching you're all thinking of
14:48 < jrandom> ooh neat, my router dumped core
14:48 < duck> jrandom: remind me how I know the hash of irc.duck.i2p
14:48 * hypercubus wonders what cervantes means
14:49 < jrandom> cd lib ; java -cp i2p.jar net.i2p.data.TestData display Destination ../irc.privKey
14:49 < cervantes> hyper: you'd be more familiar with the term strunking :)
14:49 <hypercubus> duck: try increasing to 3 or more inbound tunnels... seems to have helped me some
14:50 < duck> *** Building a seperate global context!
14:50 < duck> Log file logger.config does not exist
14:50 < duck> 23:49:47.387 ERROR [main ] net.i2p.util.LogManager : Log file logger.config does not exist
14:50 < duck> 23:49:49.589 CRIT [ 1 shutdown ] net.i2p.util.LogManager : Shutting down logger
14:50 < jrandom> ah hrm
14:50 <hypercubus> guess it couldn't handle your log *cough*
14:51 < mihi> copy your logger.config everywhere ;)
14:51 < mihi> at least everywhere where your pwd could be when you run any i2p app
14:51 < duck> no I wont
14:51 < jrandom> ok, echo logger.record.net.i2p.data.TestData=INFO >> logger.config
14:52 < jrandom> actually, thats why i said (cd lib), but i forgot that i changed the default from DEBUG to ERROR in cvs
14:52 < duck> 4 inbounds
14:52 < jrandom> 4 current &amp; ready?
14:52 < jrandom> or 2 not ready (or recently expired) and 2 ready?
14:53 < duck> now it changed to 3 with 1 not ready
14:53 < jrandom> 'k so its probably during tunnel expiration / replacement
14:54 <jrandomi2p> if you update your router.config to specify 3 inbound tunnels that should help with reliability
14:54 <jrandomi2p> (or you can use the new i2ptunnel web interface to do it ;)
14:54 <hypercubus> perhaps tunnel expiration for a single client with multiple tunnels should be staggered
14:55 <jrandomi2p> they are, generally - new tunnels are allocated &amp; a new leaseSet created 60s before tunnel expiration
14:55 <hypercubus> ah
14:55 <jrandomi2p> however, during tunnel failure it has to create a new leaseSet on demand which doesnt immediately propogate
14:56 <jrandomi2p> (well, it goes out on the netDb, but clients wont get that for up to a few seconds)
14:57 <jteitel> !who
14:57 < alpaca_> Userlist for #i2p: [hobbs] [Iakin3] [duck] [pwk__] [Sonium] [jar] [alpaca_] [interrupt] [protok0l] [mihi] [aum] [Shaun-Away] [cervantes] [jrandom] [deer] [hirvox] [Bladenight]
14:57 <bogobot> Userlist for #i2p: [shendaras] [duck] [josh] [mule2p] [aum] [mrflibble] [hypercubus] [TrueSeeker] [laggybot] [bogobot] [ion_] [mihi] [ion] [mule] [jteitel] [ant] [oOo_] [jrandomi2p] [dm] [ugha2p] [Ch0Hag] [jnk] [oOo] [soros] [bob] [revival] [DrWoo] [thetower]
14:57 <jrandomi2p> there are some further optimizations that can be done to the tunnel pool, but i'm not sure how useful it'd be atm
14:57 <jrandomi2p> ok, jumping back on track - anyone else have anything wrt 4) 0.4. stuff?
14:57 <oOo> About 'large scale simulations' for 0.4, any way to prepare thus ? Need 'new' specifics applications/tools ? (transition to point 5 ? ;) )
14:58 <jrandomi2p> actually, for the sim it would be great if someone could help mod the heartbeat (or a sam-powered app) to be kind of a scriptable client / server
14:59 -!- Bladenight is now known as Nightblade
14:59 <jrandomi2p> (e.g. rather than the current "every 30s, send 20KB to peer X", a "for 10 minutes, ask peer X for a 1MB file, and then pause for 60m, then ask peer Y for 1KB files" etc)
15:00 <jrandomi2p> but if someone is interested in helping out with that, please let me know and we can chan
15:00 <jrandomi2p> er, chat
15:00 <jrandomi2p> taking that lead in, lets jump to 5) stuff y'all are doing :)
15:01 <jrandomi2p> not sure how to go about covering this, lets just go down in the (arbitrary) order listed in the mail for updates?
15:01 <jrandomi2p> i dont see sunshine here, and aum probably isn't up yet ;)
15:02 <jrandomi2p> nightblade - how goes the battle?
15:02 < Nightblade> i have some plans for making the libsam interface like bsd sockets
15:02 < Nightblade> but i haven't done any coding on that part yet
15:02 < duck> changed to tunnels.numInbound=3
15:03 <jrandomi2p> cool duck (hopefully wait until after the meeting to restart your tunnel ;)
15:03 < duck> oh, it doesnt detect the changes?
15:03 <jrandomi2p> word nightblade - is there a problem w/ the way things are now?
15:03 <hypercubus> not until you code it to ;-)
15:03 <jrandomi2p> naw duck, the clientApp lines are only read on startup
15:04 <jrandomi2p> (clientApp is really outside the control of the router - thats what the i2ptunnel web app is for)
15:04 < Nightblade> no there is no problem with it the way it is now.... what i would be doing is in addition to the interface that is already there (developers could choose what they want to use)
15:04 <jrandomi2p> wikked
15:05 <jrandomi2p> ok, you're the boss. having variety is good, though variety means more code to maintain / etc, but its a balance
15:06 <jrandomi2p> ok, moving on down the list - mule2p - how goes the outproxy stuff?
15:07 <mule> nothing done beyond the patch you have
15:07 <jrandomi2p> ah ok i thought you were working on a further mod
15:07 <mule> need to find some spare time for real load balancing
15:07 <jrandomi2p> w3rd
15:08 <jrandomi2p> i'll get that patch applied then
15:08 <mule> thanks. and include my outproxy in the client app :) seems to be faster
15:08 <jrandomi2p> heh, well, of course your proxy will be faster for you, its local :)
15:09 <oOo> And no one else use it ^^
15:09 <mule> no, it isn't
15:09 <jrandomi2p> ooh, its on a different router? cool
15:09 <mule> yep, on a root server at an isp
15:10 <jrandomi2p> the i2ptunnel web interface has a field for people to specify the list of outproxies, so it should be easy enough for people to tweak, but we'll get it out in the next rev &amp; release notes
15:10 <jrandomi2p> nice
15:11 <jrandomi2p> ok, nickster seems to be offline atm
15:12 <jrandomi2p> are there any other active client development efforts going on?
15:12 <jrandomi2p> (or are any of the paused ones active, etc?)
15:13 <jrandomi2p> ok, if someone wants to mention anything else on that front, we've got the list and the channel, as always :)
15:13 <jrandomi2p> moving on to 6) ???
15:13 <jrandomi2p> anyone else have anything they want to bring up?
15:14 < Nightblade> nope
15:15 <mihi> duck has anything to bring down ;)
15:15 <mihi> s/any/some/
15:15 * jrandomi2p pingfloods mihi
15:15 <jrandomi2p> ok, on that note
15:15 * jrandomi2p winds up
15:15 * jrandomi2p *baf*s the meeting closed

10
i2p2www/meetings/101.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, August 3, XXXX @ 21:00 GMT
===========================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,120 +1,114 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 102{% endblock %}
{% block content %}<h3>I2P dev meeting, August 10 @ 21:00 GMT</h3>
<div class="irclog">
14:04 < jrandom> 0) hi</p>
14:04 < jrandom> 1) 0.3.4.1 status</p>
14:04 < jrandom> 2) Updated docs</p>
14:04 < jrandom> 3) 0.4 progress</p>
14:04 < jrandom> 4) ???</p>
14:04 < jrandom> 0) hi</p>
14:04 * jrandom waves</p>
14:04 < jrandom> weekly status notes just posted a few seconds ago @ http://dev.i2p.net/pipermail/i2p/2004-August/000404.html</p>
14:04 < deer> &lt;mrflibble&gt; ooh</p>
14:04 * jrandom will give y'all a sec to pull those up ;)</p>
14:05 < jrandom> anyway, while y'all are reading, might as well swing into 1) 0.3.4.1 status</p>
14:05 < jrandom> 0.3.4.1 is out, as you've seen</p>
14:06 < jrandom> its only been a day or two though, but its generally seemed to be going pretty well, at least, up through a few hours ago</p>
14:07 < jrandom> there are a pair of bugs just recently tracked down (and fixed locally, testing ongoing), and those are pretty substantial, so we'll be seeing a new release in a day or two</p>
14:07 < jrandom> has anyone had any problems with the new web console?</p>
14:07 < jrandom> (or, more specifically, has anyone tried it and had problems? :)(</p>
14:07 < deer> &lt;oOo&gt; Tried it, work well ^^</p>
14:07 < jrandom> w3rd</p>
14:08 < deer> &lt;oOo&gt; Even without any Java compiler ^^</p>
14:08 < jrandom> nice, yeah, it should precompile all the JSPs so people won't need javac</p>
14:08 < jrandom> thats one thing that web app devs will need to do, but its really really easy, especially with ant</p>
14:09 < jrandom> (template code to do it is in i2p/apps/routerconsole/java/build.xml in the 'precompilejsp' target)</p>
14:09 < deer> &lt;identiguy&gt; jrandom, what are your concerns about outproxies?</p>
14:09 < jrandom> i've also added in optional basic HTTP authentication to protect the console, so you'll be able to have it listen on 0.0.0.0 and access it remotely</p>
14:10 < jrandom> oh, my concerns w/ outproxies are threefold - the cost (technical and social) of maangement, the security (outproxies get cleartext), and the anonymity (when you leave a mixnet, you are much more vulnerable to attack)</p>
14:10 < deer> &lt;oOo&gt; The servlet console misses a few stats from :7655 (memory consumption), and may some other stuff (shitlist), but it's great ^^</p>
14:11 < deer> &lt;identiguy&gt; Thanks. Just wondering.</p>
14:11 < jrandom> "private" outproxies are different though - e.g. an anonymizer.i2p could work great without requiring trust</p>
14:11 < jrandom> (but still limiting access to pseudonymously known clients, etc)</p>
14:12 < jrandom> ah right oOo, I'm going to add in a new page that mirrors the old one</p>
14:12 < jrandom> or would you suggest a new page for more stats? could you draft up what you'd like it to look like?</p>
14:12 < jrandom> (or even code it? :)</p>
14:12 < deer> &lt;oOo&gt; Well, it could have been left as an exrcercice for the reader ;)</p>
14:12 < jrandom> lol</p>
14:13 < deer> &lt;oOo&gt; I was only thinking of memory consumption (on main page) and a Shitlist tab, that's all _I_ miss</p>
14:13 < deer> &lt;oOo&gt; Might need to add shitlist reason to shitlisting, BTW ;)</p>
14:13 < jrandom> we could probably toss the detailed shitlist into the peer profile page</p>
14:14 < jrandom> we dont actually keep track of that right now, but you're right, we could and it'd be nice</p>
14:14 < deer> &lt;oOo&gt; IMHO the peer profile page is too big to be really usefull :*)</p>
14:14 < deer> &lt;oOo&gt; And easy to do, every code to .addshitlist() stuff have good comments just the next line ;)</p>
14:14 < jrandom> any suggestions on improvement?</p>
14:15 < jrandom> heh :)</p>
14:15 < jrandom> (the netDb page imho is pretty nasty)</p>
14:16 < jrandom> hi fvw </p>
14:16 < fvw> heyas jrandom, everyone.</p>
14:16 < jrandom> ok, well, if anyone has any more suggestions for the web side, please let me know</p>
14:16 < jrandom> this new web console is really just a first pass at things, and most of my attention has been paid to the configuration side</p>
14:17 < jrandom> ok, anyone have anything else to bring up wrt 0.3.4.1?</p>
14:17 < jrandom> ok, moving on to 2) Updated docs</p>
14:17 < jrandom> [see email for list of updated pages]</p>
14:18 < jrandom> we've finally gotten all the details out of the paypal/e-gold accts as well (sorry for the delay!)</p>
14:19 < cervantes> w00t</p>
14:19 < jrandom> another aspect of the docs not mentioned is what we should ship with the router - on the new web console, we can easily package up any html / jsp files to serve as context sensitive help</p>
14:19 < cervantes> sheeeit....did I really donate all that</p>
14:20 < jrandom> cervantes definitely gets the cervantes++ this week :)</p>
14:20 < cervantes> must have miscounted my foreign currency ;-)</p>
14:20 < jrandom> lol</p>
14:20 * fvw cheers for cervantes.</p>
14:20 < jrandom> mos def</p>
14:20 < cervantes> btw I've found an old stash of hungarian dollars....</p>
14:21 < jrandom> lol do you keep these under your mattress or something?</p>
14:21 < cervantes> or forints ..</p>
14:21 < cervantes> I always overestimate my holiday spending ;-)</p>
14:21 < jrandom> heh</p>
14:22 < fvw> hmm, forints. How odd.</p>
14:22 * fvw mumbles "forinti=0..."</p>
14:23 < jrandom> (no wonder hungarian notation doesn't use 'i')</p>
14:23 < jrandom> &lt;/derail&gt;</p>
14:23 < fvw> hehe. Yes, getting back on track. New docs. very pretty.</p>
14:23 < jrandom> w3rd</p>
14:23 < deer> &lt;kling&gt; g`evening </p>
14:24 < jrandom> there is still much to be cleaned up, so hopefully people can take a page or two and give it a once over, sending in your results / updates</p>
14:24 < jrandom> hi kling</p>
14:24 < jrandom> ok, anything else wrt docs?</p>
14:24 < fvw> pweh</p>
14:25 < jrandom> if not, moving on to 3) 0.4 progress</p>
14:25 < fvw> perhaps not totally on topic, but the download page needs some work too.</p>
14:25 < jrandom> ah</p>
14:25 < jrandom> yeah</p>
14:25 < deer> &lt;oOo&gt; Missings Bounties deatails ? ;)</p>
14:25 < jrandom> that particular page i'm not /too/ worried about, since it'll all be changing with the new installer, so we'll have to rewrite it anyway</p>
14:25 < fvw> I'll kick it a bit and ask the necessary questions on the mailinglist.</p>
14:25 < jrandom> r0x0r fvw</p>
14:25 < fvw> oh, ok. Then I won't,.</p>
14:26 < deer> &lt;kling&gt; router still up nothing special to report Uptime 32h</p>
14:26 < jrandom> yeah, we'll still have some of that info, but most will change</p>
14:26 < jrandom> nice kling - are you on 0.3.4.1 or 0.3.4?</p>
14:26 < deer> &lt;kling&gt; .1</p>
14:26 < jrandom> oOo: unfortunately, we lost most of the details pages</p>
14:27 < jrandom> but you're right, we need some filler there</p>
14:27 < deer> &lt;oOo&gt; Ok, too bad but can live without them ^^</p>
14:27 < jrandom> or to remove the links</p>
14:27 < jrandom> that also reminds me that aum is now working on a DHT, and it seems Nightblade isn't anymore</p>
14:27 < jrandom> (so the distributed data store 'dev' should be updated)</p>
14:29 < jrandom> ok, anway, the 0.4 stuff is coming along - i smacked around a 100 router sim the other day with a few different bandwidth loads, and it held up pretty well</p>
14:29 < jrandom> also fixed a nasty bug in kaffe's jthread scheduler, but there is still some funkiness on fbsd there (but not on linux)</p>
14:30 < jrandom> i dont know how things are coming with the installer..</p>
14:30 < jrandom> but i do recall hypercubus working on it today, so i'm sure we'll find out more when more is ready to be found out</p>
14:31 < deer> &lt;oOo&gt; Hehe</p>
14:31 < jrandom> does anyone have any questions / concerns / suggestions wrt the 0.4 rev?</p>
14:31 < deer> &lt;oOo&gt; "When ?" J/K ;)</p>
14:32 < jrandom> we really don't have much more to add to the code before its ready for 0.4</p>
14:32 < jrandom> (but its not like 0.4 is the end game, we've got a truckload more to do after it)</p>
14:32 < deer> &lt;oOo&gt; To Infinity and Beyond !</p>
14:32 < jrandom> exactly ;)</p>
14:33 < jrandom> ok, I guess thats all I've got to bring up, so 4) ???</p>
14:33 < jrandom> anyone have anything they want to discuss?</p>
14:33 < deer> &lt;oOo&gt; i2pcvs.i2p revival ?</p>
14:34 < jrandom> yeah, i should probably start that up again</p>
14:34 < jrandom> probably will once we bundle the new router console as primary, with the i2ptunnel.cfg</p>
14:35 < deer> &lt;oOo&gt; Ok, thanks</p>
14:36 < jrandom> ok, if there's nothing else...</p>
14:36 * jrandom winds up</p>
14:36 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
14:04 < jrandom> 0) hi
14:04 < jrandom> 1) 0.3.4.1 status
14:04 < jrandom> 2) Updated docs
14:04 < jrandom> 3) 0.4 progress
14:04 < jrandom> 4) ???
14:04 < jrandom> 0) hi
14:04 * jrandom waves
14:04 < jrandom> weekly status notes just posted a few seconds ago @ http://dev.i2p.net/pipermail/i2p/2004-August/000404.html
14:04 < deer> <mrflibble> ooh
14:04 * jrandom will give y'all a sec to pull those up ;)
14:05 < jrandom> anyway, while y'all are reading, might as well swing into 1) 0.3.4.1 status
14:05 < jrandom> 0.3.4.1 is out, as you've seen
14:06 < jrandom> its only been a day or two though, but its generally seemed to be going pretty well, at least, up through a few hours ago
14:07 < jrandom> there are a pair of bugs just recently tracked down (and fixed locally, testing ongoing), and those are pretty substantial, so we'll be seeing a new release in a day or two
14:07 < jrandom> has anyone had any problems with the new web console?
14:07 < jrandom> (or, more specifically, has anyone tried it and had problems? :)(
14:07 < deer> <oOo> Tried it, work well ^^
14:07 < jrandom> w3rd
14:08 < deer> <oOo> Even without any Java compiler ^^
14:08 < jrandom> nice, yeah, it should precompile all the JSPs so people won't need javac
14:08 < jrandom> thats one thing that web app devs will need to do, but its really really easy, especially with ant
14:09 < jrandom> (template code to do it is in i2p/apps/routerconsole/java/build.xml in the 'precompilejsp' target)
14:09 < deer> <identiguy> jrandom, what are your concerns about outproxies?
14:09 < jrandom> i've also added in optional basic HTTP authentication to protect the console, so you'll be able to have it listen on 0.0.0.0 and access it remotely
14:10 < jrandom> oh, my concerns w/ outproxies are threefold - the cost (technical and social) of maangement, the security (outproxies get cleartext), and the anonymity (when you leave a mixnet, you are much more vulnerable to attack)
14:10 < deer> <oOo> The servlet console misses a few stats from :7655 (memory consumption), and may some other stuff (shitlist), but it's great ^^
14:11 < deer> <identiguy> Thanks. Just wondering.
14:11 < jrandom> "private" outproxies are different though - e.g. an anonymizer.i2p could work great without requiring trust
14:11 < jrandom> (but still limiting access to pseudonymously known clients, etc)
14:12 < jrandom> ah right oOo, I'm going to add in a new page that mirrors the old one
14:12 < jrandom> or would you suggest a new page for more stats? could you draft up what you'd like it to look like?
14:12 < jrandom> (or even code it? :)
14:12 < deer> <oOo> Well, it could have been left as an exrcercice for the reader ;)
14:12 < jrandom> lol
14:13 < deer> <oOo> I was only thinking of memory consumption (on main page) and a Shitlist tab, that's all _I_ miss
14:13 < deer> <oOo> Might need to add shitlist reason to shitlisting, BTW ;)
14:13 < jrandom> we could probably toss the detailed shitlist into the peer profile page
14:14 < jrandom> we dont actually keep track of that right now, but you're right, we could and it'd be nice
14:14 < deer> <oOo> IMHO the peer profile page is too big to be really usefull :*)
14:14 < deer> <oOo> And easy to do, every code to .addshitlist() stuff have good comments just the next line ;)
14:14 < jrandom> any suggestions on improvement?
14:15 < jrandom> heh :)
14:15 < jrandom> (the netDb page imho is pretty nasty)
14:16 < jrandom> hi fvw
14:16 < fvw> heyas jrandom, everyone.
14:16 < jrandom> ok, well, if anyone has any more suggestions for the web side, please let me know
14:16 < jrandom> this new web console is really just a first pass at things, and most of my attention has been paid to the configuration side
14:17 < jrandom> ok, anyone have anything else to bring up wrt 0.3.4.1?
14:17 < jrandom> ok, moving on to 2) Updated docs
14:17 < jrandom> [see email for list of updated pages]
14:18 < jrandom> we've finally gotten all the details out of the paypal/e-gold accts as well (sorry for the delay!)
14:19 < cervantes> w00t
14:19 < jrandom> another aspect of the docs not mentioned is what we should ship with the router - on the new web console, we can easily package up any html / jsp files to serve as context sensitive help
14:19 < cervantes> sheeeit....did I really donate all that
14:20 < jrandom> cervantes definitely gets the cervantes++ this week :)
14:20 < cervantes> must have miscounted my foreign currency ;-)
14:20 < jrandom> lol
14:20 * fvw cheers for cervantes.
14:20 < jrandom> mos def
14:20 < cervantes> btw I've found an old stash of hungarian dollars....
14:21 < jrandom> lol do you keep these under your mattress or something?
14:21 < cervantes> or forints ..
14:21 < cervantes> I always overestimate my holiday spending ;-)
14:21 < jrandom> heh
14:22 < fvw> hmm, forints. How odd.
14:22 * fvw mumbles "forinti=0..."
14:23 < jrandom> (no wonder hungarian notation doesn't use 'i')
14:23 < jrandom> </derail>
14:23 < fvw> hehe. Yes, getting back on track. New docs. very pretty.
14:23 < jrandom> w3rd
14:23 < deer> <kling> g`evening
14:24 < jrandom> there is still much to be cleaned up, so hopefully people can take a page or two and give it a once over, sending in your results / updates
14:24 < jrandom> hi kling
14:24 < jrandom> ok, anything else wrt docs?
14:24 < fvw> pweh
14:25 < jrandom> if not, moving on to 3) 0.4 progress
14:25 < fvw> perhaps not totally on topic, but the download page needs some work too.
14:25 < jrandom> ah
14:25 < jrandom> yeah
14:25 < deer> <oOo> Missings Bounties deatails ? ;)
14:25 < jrandom> that particular page i'm not /too/ worried about, since it'll all be changing with the new installer, so we'll have to rewrite it anyway
14:25 < fvw> I'll kick it a bit and ask the necessary questions on the mailinglist.
14:25 < jrandom> r0x0r fvw
14:25 < fvw> oh, ok. Then I won't,.
14:26 < deer> <kling> router still up nothing special to report Uptime 32h
14:26 < jrandom> yeah, we'll still have some of that info, but most will change
14:26 < jrandom> nice kling - are you on 0.3.4.1 or 0.3.4?
14:26 < deer> <kling> .1
14:26 < jrandom> oOo: unfortunately, we lost most of the details pages
14:27 < jrandom> but you're right, we need some filler there
14:27 < deer> <oOo> Ok, too bad but can live without them ^^
14:27 < jrandom> or to remove the links
14:27 < jrandom> that also reminds me that aum is now working on a DHT, and it seems Nightblade isn't anymore
14:27 < jrandom> (so the distributed data store 'dev' should be updated)
14:29 < jrandom> ok, anway, the 0.4 stuff is coming along - i smacked around a 100 router sim the other day with a few different bandwidth loads, and it held up pretty well
14:29 < jrandom> also fixed a nasty bug in kaffe's jthread scheduler, but there is still some funkiness on fbsd there (but not on linux)
14:30 < jrandom> i dont know how things are coming with the installer..
14:30 < jrandom> but i do recall hypercubus working on it today, so i'm sure we'll find out more when more is ready to be found out
14:31 < deer> <oOo> Hehe
14:31 < jrandom> does anyone have any questions / concerns / suggestions wrt the 0.4 rev?
14:31 < deer> <oOo> "When ?" J/K ;)
14:32 < jrandom> we really don't have much more to add to the code before its ready for 0.4
14:32 < jrandom> (but its not like 0.4 is the end game, we've got a truckload more to do after it)
14:32 < deer> <oOo> To Infinity and Beyond !
14:32 < jrandom> exactly ;)
14:33 < jrandom> ok, I guess thats all I've got to bring up, so 4) ???
14:33 < jrandom> anyone have anything they want to discuss?
14:33 < deer> <oOo> i2pcvs.i2p revival ?
14:34 < jrandom> yeah, i should probably start that up again
14:34 < jrandom> probably will once we bundle the new router console as primary, with the i2ptunnel.cfg
14:35 < deer> <oOo> Ok, thanks
14:36 < jrandom> ok, if there's nothing else...
14:36 * jrandom winds up
14:36 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/102.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, August 10, XXXX @ 21:00 GMT
============================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,217 +1,211 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 103{% endblock %}
{% block content %}<h3>I2P dev meeting, August 17, 2004</h3>
<div class="irclog">
14:05 < jrandom> 0) hi</p>
14:05 < jrandom> 1) Network status and 0.3.4.3</p>
14:05 < jrandom> 2) Stasher</p>
14:06 < jrandom> 3) ???</p>
14:06 < jrandom> 0) hi</p>
14:06 * jrandom waves to all the i[2i]p &amp; freenode gang</p>
14:06 * hypercubus waves</p>
14:06 < jrandom> weekly status notes posted a few seconds ago to http://dev.i2p.net/pipermail/i2p/2004-August/000409.html</p>
14:06 < deer> &lt;oOo_itwop&gt; It's Show Time !</p>
14:07 < deer> &lt;mule&gt; seems i2p irc doesn't love me. or it wants to keep me hot longer by regular interruptions</p>
14:07 < jrandom> heh, yeah, that actually leads us in to 1) Network status and 0.3.4.3 :)</p>
14:07 < jrandom> the network is pretty shitty right now</p>
14:07 < kaji> yep</p>
14:08 < jrandom> the problems are showing up largely from incompatabilities with the different releases that people are running, which has been injecting all sorts of neat ways to break things</p>
14:09 < jrandom> if you check the links in the email, you can see the flooding and netDb DoS that has gone on, but it has largely subsided</p>
14:09 < jrandom> we still do have a half dozen people running old releases (and probably 20-25 people running vanilla 0.3.4.2, with its own problems)</p>
14:10 < jrandom> i appreciate your patience as we move forward on this. i dont want to rush a new release without first being able to effeciently route around bad nodes</p>
14:10 < jrandom> in the past we have been able to route around bad nodes that merely perform poorly, but havent had to deal with nodes who do Bad Things</p>
14:11 < deer> &lt;oOo_itwop&gt; Guinea pigs bows to jrandom !</p>
14:11 < duck> will the next release be backward compatible?</p>
14:11 < jrandom> perhaps duck. if we can work around those old nodes, there's no reason to make it incompatible</p>
14:12 < duck> cool</p>
14:12 < jrandom> anyway, there's lots of activity going on, even though y'all aren't seeing any new releases yet</p>
14:13 < jrandom> i dont know when 0.3.4.3 will be out. perhaps tomorrow, or perhaps later this week.</p>
14:14 < jrandom> anyone have any questions / comments / concerns they'd like to bring up wrt network status?</p>
14:14 < kaji> will *.3 have hyper's new gui install?</p>
14:14 < jrandom> probably not</p>
14:14 < deer> &lt;mule&gt; the network looks good to me in the profiles of my boxes, just that i frequently drop</p>
14:15 < jrandom> yeah, i understand mule. the irc con has been pretty bad for me too, but its been getting better lately</p>
14:15 < deer> &lt;mule&gt; but i missed most of your discussion, so i'll shut up for now</p>
14:15 < jrandom> if you want to try pulling from CVS, that should have an improvement, but there are frequent updates so you may want to wait until the release</p>
14:16 < jrandom> ok anything else? if not, moving briskly along to 2) Stasher</p>
14:16 < kaji> woot stasher</p>
14:17 < jrandom> stasher is looking pretty cool. still quite limited functionality, but its making progress</p>
14:17 < jrandom> if aum were awake he could give us an update...</p>
14:17 < jrandom> aum: ping? :)</p>
14:17 < kaji> /kick aum</p>
14:18 < jrandom> (its early for him though, so he is probably still sleeping)</p>
14:18 < duck> how selfish</p>
14:18 < hypercubus> i'm impressed by it so far</p>
14:18 < jrandom> Anyway, installing and running stasher is pretty painless, so if you can help him test it out, that'd be great</p>
14:18 < jrandom> yeah, mos' def'</p>
14:18 < hypercubus> it has allowed me to pull off mass goatse'ing</p>
14:19 < jrandom> and whats an app without a goatse, 'eh? </p>
14:19 < hypercubus> you gotta love an app that lets you upload goatse to someone's drive ;-)</p>
14:19 < aum> pong</p>
14:19 < jrandom> w0ah </p>
14:19 < jrandom> 'mornin aum</p>
14:19 < deer> &lt;ardvark&gt; quick question: do I get stasher via i2p CVS?</p>
14:19 < aum> hi all</p>
14:19 < jrandom> ardvark: in i2p/apps/stasher/</p>
14:19 < aum> ardvark: hi!!!! :) long time!</p>
14:20 < deer> &lt;ardvark&gt; yes hi aum! good to see you mate!</p>
14:20 < aum> ardvark: prolly easier via tarball - http://stasher.i2p or http://www.freenet.org.nz/python/stasher</p>
14:21 < deer> &lt;ardvark&gt; ok aum, I got the tarball but needs other stuff it says? I'll not hold back the meeting, maybe I can contact you?</p>
14:21 < aum> sure thing</p>
14:22 < hypercubus> so, any update on stasher aum? ;-)</p>
14:23 < aum> small update, i've added a '-l' option which allows local-only get/put</p>
14:23 < aum> also, thinking of implementing a 'put' option which returns immediately </p>
14:24 < aum> last night, was thinking thru issues of implementing freenet keytypes</p>
14:24 < hypercubus> i'd like to request that successful put operations return a status... scp and many other command line net apps do this</p>
14:24 < jrandom> SSK would quite kick ass</p>
14:25 < jrandom> (while CHK is of course what imho is most essential)</p>
14:25 < MikeW> One thing I always found interesting about freenet was: It would tell you why there could be high CPU usage. Sometimes (usually at startup for a minute or two) and randomly, CPU usage spikes to 100%, perhaps a estimation why it thinks java is eating my cpu?</p>
14:25 < deer> &lt;oOo&gt; Splitfiles ^^</p>
14:26 < jrandom> MikeW: if i2p is eating your CPU there is most certainly something broken going on</p>
14:26 < aum> i've tentatively implemented splitfiles already, but haven't enabled it - want to test locally first</p>
14:26 < jrandom> MikeW: you can tell exactly whats going on in your router by looking at the 'current job' in the router console, which is (almost always) where the CPU crunch is</p>
14:26 < jrandom> ah cool aum</p>
14:27 < aum> due to a recursive algo, the splitfiles thing should allow unlimited file sizes when it's done</p>
14:27 < deer> &lt;oOo&gt; Great, splitfiles are mandatory for serious goatse and pr0n stuff...</p>
14:27 < deer> &lt;identiguy&gt; aum: does that include FEC?</p>
14:27 < aum> fec not needed</p>
14:27 < aum> fec is only required on flaky networks</p>
14:27 < deer> &lt;identiguy&gt; Ah, I see.</p>
14:27 < aum> i'm using kademlia, which has far better retrievability guarantee</p>
14:27 < duck> unless nodes go down</p>
14:28 < aum> plus, i can't be fscked doing fec anyway, it's a pain</p>
14:28 < aum> duck: there's redundancy - refer the 'k' value in kademlia</p>
14:28 < jrandom> duck: with a k of 20, even without any republishing it'd be ok ;)</p>
14:28 < duck> heh, okay</p>
14:28 < deer> &lt;mule&gt; aum: fec might help in case a number of nodes are removed</p>
14:28 < jrandom> (and with republishing, it'd only hurt if all k died at the same time)</p>
14:28 < aum> naah, i'll just increase k</p>
14:28 < jrandom> k of 20 imho is pretty substantial</p>
14:29 < jrandom> (since that means you have 20 full replicas of the file)</p>
14:29 < hypercubus> users can always use standalone fec tools</p>
14:29 < MikeW> jrandom: Under JobQueue, runners:1, active jobs:0, just finished:1, ready/waiting: 0, timed: 28</p>
14:29 < aum> that means 20 goatses, guys :P</p>
14:29 < hypercubus> and publish the results</p>
14:29 < duck> what about the britneyspears effect?</p>
14:29 < duck> of very popular keys ending up on 1 node</p>
14:29 < jrandom> (aka insert a 740MB file and you get 14.8GB of data you need to send)</p>
14:30 < aum> duck: popularity is not a concept in kademlia</p>
14:30 < duck> (ofcourse with 32KB keys that might not be terrible)</p>
14:30 < jrandom> ok cool MikeW, but is i2p eating your CPU now?</p>
14:30 < deer> &lt;ardvark&gt; all these kademlia messages I see on i2p are stasher related?</p>
14:30 < MikeW> jrandom: yes</p>
14:30 < aum> duck: and kademlia has no relaying</p>
14:30 < hypercubus> ardvark: the stuff in the router console is the netdb kad implementation</p>
14:31 < aum> the ideas of 'relaying', 'popularity', 'caching' etc are for freenet, which has to expose itself naked to the world, without the cloaking of I2P</p>
14:31 < deer> &lt;ardvark&gt; runnin i2p and tor here and my cpu usage is at 3% now so :/ *shrug*</p>
14:31 < jrandom> MikeW: then your router is unable to maintain connections and is gobbling CPU doing lots of concurrent connection establishment</p>
14:31 < duck> ok, my brain is rotten by freenet</p>
14:31 < duck> please have mercy :)</p>
14:31 < deer> * shendaras comforts.</p>
14:31 < jrandom> MikeW: if you can hang around after the meeting to debug, that'd be great</p>
14:32 < MikeW> will do</p>
14:32 < jrandom> ok cool aum, anything people can do to help?</p>
14:32 < jrandom> or should we just kick the tires and file bugs?</p>
14:33 < duck> I am trying to get used to leo</p>
14:33 < aum> yep, file bugs to the list, if that's ok people</p>
14:33 < duck> already like it more than eclipse</p>
14:33 < hypercubus> what's leo?</p>
14:33 < jrandom> (uh oh, here comes the rant ;)</p>
14:33 < aum> duck: i use nothing but leo these days - except emacs for quick hacks, and zile for even quicker hacks</p>
14:34 < hypercubus> as long as you're not using vi or emacs ;-)</p>
14:34 < aum> http://leo.sf.net - gives you an outline view of your code</p>
14:34 < hypercubus> but i'll have to try this leo myself</p>
14:34 < aum> leo even integrates with emacs if you want</p>
14:34 < hypercubus> it's not an editor?</p>
14:35 < aum> &lt;bile&gt;</p>
14:35 < aum> fucking msvc - it allows __int64 for 64-bit ints, but doesn't allow 'LL' or 'ULL' for 64-bit int literals</p>
14:35 < aum> !!</p>
14:35 < aum> &lt;/bile&gt;</p>
14:35 < hypercubus> ah i see</p>
14:37 < jrandom> ok, if thats that, then we've got nothing left and can move to 3) ???</p>
14:37 < jrandom> anyone have anything else they want to bring up?</p>
14:37 < hypercubus> yeah i guess i'll say a bit about the new direction of the installer</p>
14:37 < jrandom> ok word</p>
14:38 < hypercubus> from 0.4 onward, command line users will merely grab the i2p tarball and unpack it, then run a script to start the router and pop open the router console in lynx or whatever</p>
14:39 < hypercubus> so not much has changed, except you don't have to go through a silly Q/A session with an installer</p>
14:39 < hypercubus> you do all the configuration in the router console</p>
14:39 < hypercubus> for GUI users, we have something spiffy</p>
14:39 < jrandom> (w00t)</p>
14:40 < hypercubus> which you can preview at http://files.hypercubus.i2p/install.jar</p>
14:40 < jrandom> or from cvs (ant pkg ; java -jar install.jar) right?</p>
14:40 < aum> hypercubus: how are you going with the winstaller? does it autodetect/autodownload/autoinstall java ?</p>
14:41 < hypercubus> menu shortcuts are forthcoming, as well as systray integration and a way to install the router as a daemon</p>
14:41 < aum> daemon? as in windows 'service' ?</p>
14:41 < hypercubus> no, at least not for the forseeable future, they will need to click on a link on the i2p site that takes them to the official java download page</p>
14:42 < hypercubus> the installer requires java, but that's ok since i2p does as well</p>
14:42 < aum> hypercubus: sorry, but that'll lose 80% of users</p>
14:42 < hypercubus> name one java project that doesn't do that</p>
14:42 < jrandom> we'll have it eventually.</p>
14:42 < jrandom> just not now.</p>
14:42 < aum> freenet did it well - their winstaller takes you through the download</p>
14:43 < jrandom> (we have so many other more important fish to fry. we dont *want* thousands upon thousands of users now)</p>
14:43 < hypercubus> that's a consideration for 1.0</p>
14:43 < hypercubus> i have most of the code to pull it off done already</p>
14:43 < aum> jrandom: i thought you said it would be for 0.4</p>
14:43 < deer> &lt;mule&gt; so you should require that java is built from source :)</p>
14:44 < jrandom> the new installer will be for 0.4</p>
14:44 < hypercubus> we have scrapped all the code i have written thus far</p>
14:44 < hypercubus> in favor of IzPack</p>
14:44 < hypercubus> http://izpack.sf.net</p>
14:44 < jrandom> we can offer a 15MB download bundling the two as one, but most users who will use i2p prior to 1.0 will know what "java" is</p>
14:45 < hypercubus> this gives me time to perfect a fully public domain java installer framework which i eventually hope to move i2p back to</p>
14:45 < hypercubus> but the priority right now is to get rid of the awful current installer ;-)</p>
14:46 < hypercubus> (no offense to whoever hacked it together)</p>
14:46 < deer> &lt;shendaras&gt; Got a 404....</p>
14:46 < duck> http://www.izforge.com/izpack/</p>
14:46 < hypercubus> http://www.izforge.com/izpack/</p>
14:47 < hypercubus> sorry about that</p>
14:47 < hypercubus> anyhow, i would appreciate feedback on the preview installer i've put up on my eepsite</p>
14:48 < hypercubus> it's been tested on *nix and windows, it should work on os x and solaris too</p>
14:48 < jrandom> r0x0r</p>
14:48 < duck> its sweet</p>
14:48 < jrandom> yeah, it kicks ass</p>
14:49 < hypercubus> i may hack izpack to remove those dorky icons from the buttons</p>
14:49 < deer> &lt;mule&gt; hypercubus: will it destroy existing configurations or preserve them?</p>
14:49 < hypercubus> there are no config files contained in the package</p>
14:49 < hypercubus> so it will only overwrite jars and wars</p>
14:49 < jrandom> (at the moment ;)</p>
14:49 < hypercubus> well, we'll take configs into account</p>
14:49 < deer> &lt;mule&gt; k, thanks</p>
14:49 < duck> how will one start the whole jetty thang?</p>
14:50 < duck> still a sh/bat ?</p>
14:50 < jrandom> yes</p>
14:50 < jrandom> the router will start w/ a script, and/or a service (calling that script)</p>
14:50 < hypercubus> yes, and i'll throw in an exe for win users</p>
14:50 < jrandom> w00t</p>
14:50 < hypercubus> that will launch from the Start menu</p>
14:50 < hypercubus> the Windows Start menu</p>
14:51 < hypercubus> should have jetty working as a windows service by tomorrow</p>
14:51 * jrandom mumbles *its not jetty, its i2p*</p>
14:51 < hypercubus> ah right ;-)</p>
14:52 < hypercubus> jetty comes with a win32 service wrapper though</p>
14:52 < hypercubus> we can use it to wrap anything</p>
14:52 < jrandom> yeah, there are 3-4 PD/BSD java service wrappers out there</p>
14:52 < hypercubus> yeah, there are probably some for linux too</p>
14:53 < jrandom> well, linux service == init script :)</p>
14:53 < hypercubus> yeah but linux services are handled differently among even the major distros</p>
14:53 < hypercubus> for example, gentoo uses the rc-setup script scheme</p>
14:54 < jrandom> w3rd</p>
14:54 < hypercubus> anyhow, i'll get it working for all the major distros and *bsd's</p>
14:54 < hypercubus> if not more</p>
14:55 < hypercubus> oops, s/rc-setup/rc-update/</p>
14:55 < hypercubus> ok, that covers everything i guess</p>
14:55 < hypercubus> you guys can wake up now ;-)</p>
14:55 < deer> * shendaras yawns</p>
14:55 < jrandom> cool, thanks hyper, sounds good.</p>
14:56 < jrandom> anyone else have anything they want to bring up?</p>
14:56 < aum> sorry if i missed earlier discussion, but..</p>
14:56 < aum> what's the weather like vis a vis datagram latency etc?</p>
14:57 < jrandom> i dont know about datagrams - the only apps i use run on top of datagrams via streams</p>
14:57 < jrandom> network status is still pretty bad - see status notes @ http://dev.i2p.net/pipermail/i2p/2004-August/000409.html</p>
14:58 < aum> k</p>
14:58 < jrandom> ok, if there's nothing else...</p>
14:58 * jrandom winds up</p>
14:59 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
14:05 < jrandom> 0) hi
14:05 < jrandom> 1) Network status and 0.3.4.3
14:05 < jrandom> 2) Stasher
14:06 < jrandom> 3) ???
14:06 < jrandom> 0) hi
14:06 * jrandom waves to all the i[2i]p &amp; freenode gang
14:06 * hypercubus waves
14:06 < jrandom> weekly status notes posted a few seconds ago to http://dev.i2p.net/pipermail/i2p/2004-August/000409.html
14:06 < deer> <oOo_itwop> It's Show Time !
14:07 < deer> <mule> seems i2p irc doesn't love me. or it wants to keep me hot longer by regular interruptions
14:07 < jrandom> heh, yeah, that actually leads us in to 1) Network status and 0.3.4.3 :)
14:07 < jrandom> the network is pretty shitty right now
14:07 < kaji> yep
14:08 < jrandom> the problems are showing up largely from incompatabilities with the different releases that people are running, which has been injecting all sorts of neat ways to break things
14:09 < jrandom> if you check the links in the email, you can see the flooding and netDb DoS that has gone on, but it has largely subsided
14:09 < jrandom> we still do have a half dozen people running old releases (and probably 20-25 people running vanilla 0.3.4.2, with its own problems)
14:10 < jrandom> i appreciate your patience as we move forward on this. i dont want to rush a new release without first being able to effeciently route around bad nodes
14:10 < jrandom> in the past we have been able to route around bad nodes that merely perform poorly, but havent had to deal with nodes who do Bad Things
14:11 < deer> <oOo_itwop> Guinea pigs bows to jrandom !
14:11 < duck> will the next release be backward compatible?
14:11 < jrandom> perhaps duck. if we can work around those old nodes, there's no reason to make it incompatible
14:12 < duck> cool
14:12 < jrandom> anyway, there's lots of activity going on, even though y'all aren't seeing any new releases yet
14:13 < jrandom> i dont know when 0.3.4.3 will be out. perhaps tomorrow, or perhaps later this week.
14:14 < jrandom> anyone have any questions / comments / concerns they'd like to bring up wrt network status?
14:14 < kaji> will *.3 have hyper's new gui install?
14:14 < jrandom> probably not
14:14 < deer> <mule> the network looks good to me in the profiles of my boxes, just that i frequently drop
14:15 < jrandom> yeah, i understand mule. the irc con has been pretty bad for me too, but its been getting better lately
14:15 < deer> <mule> but i missed most of your discussion, so i'll shut up for now
14:15 < jrandom> if you want to try pulling from CVS, that should have an improvement, but there are frequent updates so you may want to wait until the release
14:16 < jrandom> ok anything else? if not, moving briskly along to 2) Stasher
14:16 < kaji> woot stasher
14:17 < jrandom> stasher is looking pretty cool. still quite limited functionality, but its making progress
14:17 < jrandom> if aum were awake he could give us an update...
14:17 < jrandom> aum: ping? :)
14:17 < kaji> /kick aum
14:18 < jrandom> (its early for him though, so he is probably still sleeping)
14:18 < duck> how selfish
14:18 < hypercubus> i'm impressed by it so far
14:18 < jrandom> Anyway, installing and running stasher is pretty painless, so if you can help him test it out, that'd be great
14:18 < jrandom> yeah, mos' def'
14:18 < hypercubus> it has allowed me to pull off mass goatse'ing
14:19 < jrandom> and whats an app without a goatse, 'eh?
14:19 < hypercubus> you gotta love an app that lets you upload goatse to someone's drive ;-)
14:19 < aum> pong
14:19 < jrandom> w0ah
14:19 < jrandom> 'mornin aum
14:19 < deer> <ardvark> quick question: do I get stasher via i2p CVS?
14:19 < aum> hi all
14:19 < jrandom> ardvark: in i2p/apps/stasher/
14:19 < aum> ardvark: hi!!!! :) long time!
14:20 < deer> <ardvark> yes hi aum! good to see you mate!
14:20 < aum> ardvark: prolly easier via tarball - http://stasher.i2p or http://www.freenet.org.nz/python/stasher
14:21 < deer> <ardvark> ok aum, I got the tarball but needs other stuff it says? I'll not hold back the meeting, maybe I can contact you?
14:21 < aum> sure thing
14:22 < hypercubus> so, any update on stasher aum? ;-)
14:23 < aum> small update, i've added a '-l' option which allows local-only get/put
14:23 < aum> also, thinking of implementing a 'put' option which returns immediately
14:24 < aum> last night, was thinking thru issues of implementing freenet keytypes
14:24 < hypercubus> i'd like to request that successful put operations return a status... scp and many other command line net apps do this
14:24 < jrandom> SSK would quite kick ass
14:25 < jrandom> (while CHK is of course what imho is most essential)
14:25 < MikeW> One thing I always found interesting about freenet was: It would tell you why there could be high CPU usage. Sometimes (usually at startup for a minute or two) and randomly, CPU usage spikes to 100%, perhaps a estimation why it thinks java is eating my cpu?
14:25 < deer> <oOo> Splitfiles ^^
14:26 < jrandom> MikeW: if i2p is eating your CPU there is most certainly something broken going on
14:26 < aum> i've tentatively implemented splitfiles already, but haven't enabled it - want to test locally first
14:26 < jrandom> MikeW: you can tell exactly whats going on in your router by looking at the 'current job' in the router console, which is (almost always) where the CPU crunch is
14:26 < jrandom> ah cool aum
14:27 < aum> due to a recursive algo, the splitfiles thing should allow unlimited file sizes when it's done
14:27 < deer> <oOo> Great, splitfiles are mandatory for serious goatse and pr0n stuff...
14:27 < deer> <identiguy> aum: does that include FEC?
14:27 < aum> fec not needed
14:27 < aum> fec is only required on flaky networks
14:27 < deer> <identiguy> Ah, I see.
14:27 < aum> i'm using kademlia, which has far better retrievability guarantee
14:27 < duck> unless nodes go down
14:28 < aum> plus, i can't be fscked doing fec anyway, it's a pain
14:28 < aum> duck: there's redundancy - refer the 'k' value in kademlia
14:28 < jrandom> duck: with a k of 20, even without any republishing it'd be ok ;)
14:28 < duck> heh, okay
14:28 < deer> <mule> aum: fec might help in case a number of nodes are removed
14:28 < jrandom> (and with republishing, it'd only hurt if all k died at the same time)
14:28 < aum> naah, i'll just increase k
14:28 < jrandom> k of 20 imho is pretty substantial
14:29 < jrandom> (since that means you have 20 full replicas of the file)
14:29 < hypercubus> users can always use standalone fec tools
14:29 < MikeW> jrandom: Under JobQueue, runners:1, active jobs:0, just finished:1, ready/waiting: 0, timed: 28
14:29 < aum> that means 20 goatses, guys :P
14:29 < hypercubus> and publish the results
14:29 < duck> what about the britneyspears effect?
14:29 < duck> of very popular keys ending up on 1 node
14:29 < jrandom> (aka insert a 740MB file and you get 14.8GB of data you need to send)
14:30 < aum> duck: popularity is not a concept in kademlia
14:30 < duck> (ofcourse with 32KB keys that might not be terrible)
14:30 < jrandom> ok cool MikeW, but is i2p eating your CPU now?
14:30 < deer> <ardvark> all these kademlia messages I see on i2p are stasher related?
14:30 < MikeW> jrandom: yes
14:30 < aum> duck: and kademlia has no relaying
14:30 < hypercubus> ardvark: the stuff in the router console is the netdb kad implementation
14:31 < aum> the ideas of 'relaying', 'popularity', 'caching' etc are for freenet, which has to expose itself naked to the world, without the cloaking of I2P
14:31 < deer> <ardvark> runnin i2p and tor here and my cpu usage is at 3% now so :/ *shrug*
14:31 < jrandom> MikeW: then your router is unable to maintain connections and is gobbling CPU doing lots of concurrent connection establishment
14:31 < duck> ok, my brain is rotten by freenet
14:31 < duck> please have mercy :)
14:31 < deer> * shendaras comforts.
14:31 < jrandom> MikeW: if you can hang around after the meeting to debug, that'd be great
14:32 < MikeW> will do
14:32 < jrandom> ok cool aum, anything people can do to help?
14:32 < jrandom> or should we just kick the tires and file bugs?
14:33 < duck> I am trying to get used to leo
14:33 < aum> yep, file bugs to the list, if that's ok people
14:33 < duck> already like it more than eclipse
14:33 < hypercubus> what's leo?
14:33 < jrandom> (uh oh, here comes the rant ;)
14:33 < aum> duck: i use nothing but leo these days - except emacs for quick hacks, and zile for even quicker hacks
14:34 < hypercubus> as long as you're not using vi or emacs ;-)
14:34 < aum> http://leo.sf.net - gives you an outline view of your code
14:34 < hypercubus> but i'll have to try this leo myself
14:34 < aum> leo even integrates with emacs if you want
14:34 < hypercubus> it's not an editor?
14:35 < aum> <bile>
14:35 < aum> fucking msvc - it allows __int64 for 64-bit ints, but doesn't allow 'LL' or 'ULL' for 64-bit int literals
14:35 < aum> !!
14:35 < aum> </bile>
14:35 < hypercubus> ah i see
14:37 < jrandom> ok, if thats that, then we've got nothing left and can move to 3) ???
14:37 < jrandom> anyone have anything else they want to bring up?
14:37 < hypercubus> yeah i guess i'll say a bit about the new direction of the installer
14:37 < jrandom> ok word
14:38 < hypercubus> from 0.4 onward, command line users will merely grab the i2p tarball and unpack it, then run a script to start the router and pop open the router console in lynx or whatever
14:39 < hypercubus> so not much has changed, except you don't have to go through a silly Q/A session with an installer
14:39 < hypercubus> you do all the configuration in the router console
14:39 < hypercubus> for GUI users, we have something spiffy
14:39 < jrandom> (w00t)
14:40 < hypercubus> which you can preview at http://files.hypercubus.i2p/install.jar
14:40 < jrandom> or from cvs (ant pkg ; java -jar install.jar) right?
14:40 < aum> hypercubus: how are you going with the winstaller? does it autodetect/autodownload/autoinstall java ?
14:41 < hypercubus> menu shortcuts are forthcoming, as well as systray integration and a way to install the router as a daemon
14:41 < aum> daemon? as in windows 'service' ?
14:41 < hypercubus> no, at least not for the forseeable future, they will need to click on a link on the i2p site that takes them to the official java download page
14:42 < hypercubus> the installer requires java, but that's ok since i2p does as well
14:42 < aum> hypercubus: sorry, but that'll lose 80% of users
14:42 < hypercubus> name one java project that doesn't do that
14:42 < jrandom> we'll have it eventually.
14:42 < jrandom> just not now.
14:42 < aum> freenet did it well - their winstaller takes you through the download
14:43 < jrandom> (we have so many other more important fish to fry. we dont *want* thousands upon thousands of users now)
14:43 < hypercubus> that's a consideration for 1.0
14:43 < hypercubus> i have most of the code to pull it off done already
14:43 < aum> jrandom: i thought you said it would be for 0.4
14:43 < deer> <mule> so you should require that java is built from source :)
14:44 < jrandom> the new installer will be for 0.4
14:44 < hypercubus> we have scrapped all the code i have written thus far
14:44 < hypercubus> in favor of IzPack
14:44 < hypercubus> http://izpack.sf.net
14:44 < jrandom> we can offer a 15MB download bundling the two as one, but most users who will use i2p prior to 1.0 will know what "java" is
14:45 < hypercubus> this gives me time to perfect a fully public domain java installer framework which i eventually hope to move i2p back to
14:45 < hypercubus> but the priority right now is to get rid of the awful current installer ;-)
14:46 < hypercubus> (no offense to whoever hacked it together)
14:46 < deer> <shendaras> Got a 404....
14:46 < duck> http://www.izforge.com/izpack/
14:46 < hypercubus> http://www.izforge.com/izpack/
14:47 < hypercubus> sorry about that
14:47 < hypercubus> anyhow, i would appreciate feedback on the preview installer i've put up on my eepsite
14:48 < hypercubus> it's been tested on *nix and windows, it should work on os x and solaris too
14:48 < jrandom> r0x0r
14:48 < duck> its sweet
14:48 < jrandom> yeah, it kicks ass
14:49 < hypercubus> i may hack izpack to remove those dorky icons from the buttons
14:49 < deer> <mule> hypercubus: will it destroy existing configurations or preserve them?
14:49 < hypercubus> there are no config files contained in the package
14:49 < hypercubus> so it will only overwrite jars and wars
14:49 < jrandom> (at the moment ;)
14:49 < hypercubus> well, we'll take configs into account
14:49 < deer> <mule> k, thanks
14:49 < duck> how will one start the whole jetty thang?
14:50 < duck> still a sh/bat ?
14:50 < jrandom> yes
14:50 < jrandom> the router will start w/ a script, and/or a service (calling that script)
14:50 < hypercubus> yes, and i'll throw in an exe for win users
14:50 < jrandom> w00t
14:50 < hypercubus> that will launch from the Start menu
14:50 < hypercubus> the Windows Start menu
14:51 < hypercubus> should have jetty working as a windows service by tomorrow
14:51 * jrandom mumbles *its not jetty, its i2p*
14:51 < hypercubus> ah right ;-)
14:52 < hypercubus> jetty comes with a win32 service wrapper though
14:52 < hypercubus> we can use it to wrap anything
14:52 < jrandom> yeah, there are 3-4 PD/BSD java service wrappers out there
14:52 < hypercubus> yeah, there are probably some for linux too
14:53 < jrandom> well, linux service == init script :)
14:53 < hypercubus> yeah but linux services are handled differently among even the major distros
14:53 < hypercubus> for example, gentoo uses the rc-setup script scheme
14:54 < jrandom> w3rd
14:54 < hypercubus> anyhow, i'll get it working for all the major distros and *bsd's
14:54 < hypercubus> if not more
14:55 < hypercubus> oops, s/rc-setup/rc-update/
14:55 < hypercubus> ok, that covers everything i guess
14:55 < hypercubus> you guys can wake up now ;-)
14:55 < deer> * shendaras yawns
14:55 < jrandom> cool, thanks hyper, sounds good.
14:56 < jrandom> anyone else have anything they want to bring up?
14:56 < aum> sorry if i missed earlier discussion, but..
14:56 < aum> what's the weather like vis a vis datagram latency etc?
14:57 < jrandom> i dont know about datagrams - the only apps i use run on top of datagrams via streams
14:57 < jrandom> network status is still pretty bad - see status notes @ http://dev.i2p.net/pipermail/i2p/2004-August/000409.html
14:58 < aum> k
14:58 < jrandom> ok, if there's nothing else...
14:58 * jrandom winds up
14:59 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/103.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, August 17, 2004
================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,422 +1,416 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 104{% endblock %}
{% block content %}<h3>I2P dev meeting, August 24, 2004</h3>
<div class="irclog">
14:01 < jrandom> 0) hi</p>
14:01 < jrandom> 1) 0.3.4.3 status</p>
14:01 < jrandom> 1.1) timestamper</p>
14:02 < jrandom> 1.2) new router console authentication</p>
14:02 < jrandom> 2) 0.4 status</p>
14:02 < jrandom> 2.1) service &amp; systray integration</p>
14:02 < jrandom> 2.2) jbigi &amp; jcpuid</p>
14:02 < jrandom> 2.3) i2paddresshelper</p>
14:02 < jrandom> 3) AMOC vs. restricted routes</p>
14:02 < jrandom> 4) stasher</p>
14:02 < jrandom> 5) pages of note</p>
14:02 < jrandom> 6) ???</p>
14:02 < jrandom> 0) hi</p>
14:02 * jrandom waves</p>
14:02 < deer> &lt;ugha2p&gt; Hi.</p>
14:02 < jrandom> weekly notes posted (waaay early) at http://dev.i2p.net/pipermail/i2p/2004-August/000419.html</p>
14:03 < jrandom> so i expect you've all done your homework and have read them diligently</p>
14:03 < jrandom> (or something)</p>
14:03 < jrandom> ok, 1) 0.3.4.3 status</p>
14:04 < kaji> (late hi)</p>
14:04 < jrandom> there are a few things adjusted since the 0.3.4.3 release came out last friday, but overall the rev seems pretty stable, from what i can tell</p>
14:04 < deer> &lt;luckypunk&gt; huh. whats going on?</p>
14:04 < deer> &lt;luckypunk&gt; Oh. Nm. sorry, i usually sleep thorugh the meeting though. Hi :)</p>
14:05 < jrandom> what are people's experiences with 0.3.4.3 with regards to eepsites / squid / etc?</p>
14:05 < luckypunk> very quick.</p>
14:05 < jrandom> (i can tell what people are seeing with irc)</p>
14:05 < luckypunk> Under 3 seconds page loading sometimes.</p>
14:06 < deer> &lt;oOo&gt; Jrandom do kick squid's router too often ;)</p>
14:06 < jrandom> cool lucky</p>
14:06 < deer> &lt;mule&gt; working well</p>
14:06 < luckypunk> i can open up 10 pages of things through the squid and I2P keeps up, pretty slowly though, on my 350 mhz.</p>
14:06 < deer> &lt;hypercubus&gt; snappiest it's ever been</p>
14:06 < jrandom> yeah, i do oOo, but thats why we have www1.squid.i2p :)</p>
14:06 < jrandom> r0x0r</p>
14:06 < jrandom> i've heard a few reports of excessive CPU usage - is that hitting people often?</p>
14:07 < deer> &lt;hypercubus&gt; not i... i suspect it's just the people with 386s *cough*lucky*cough*</p>
14:07 < deer> &lt;oOo&gt; Some very rare peaks here. Related to another erro, I might trace it back one day :p</p>
14:07 < deer> &lt;mule&gt; not here</p>
14:07 < luckypunk> I think, if its affecting all platforms and stuff, i would feel it hard, and no not really. Only when its serving the new config pages or downloading a lot of stuff does I2P pin my processor.</p>
14:08 < jrandom> ok cool. there are a few scenarios where i2p will be a bitch wrt CPU, but hopefully those are few and far between</p>
14:08 < jrandom> actually, that leads us in to 1.1) timestamper :)</p>
14:09 < jrandom> (one of the problems can occur when the timestamper gets goofy / loses track of the correct time)</p>
14:10 < jrandom> the whole timestamping stuff has been revamped and integrated into the router, thanks to Adam Buckley being kickass and releasing his work under the BSD license</p>
14:10 < jrandom> (yay Adam)</p>
14:11 < jrandom> we had previously used the SNTP code as a standalone client app, but we are not doing that anymore - instead we have a tight integration with the router</p>
14:11 < jrandom> (so people may need to update their config files as mentioned in the email)</p>
14:11 < jrandom> SNTP alone is only a part of the solution though</p>
14:12 < jrandom> long term we need some better (read: NTP) synchronization, as SNTP is prone to flux</p>
14:12 < jrandom> (especially in light of high network congestion)</p>
14:12 < jrandom> Adam sent me some code he has for dealing with it, but i dont really have the time to work through that side of things atm</p>
14:13 < deer> &lt;oOo&gt; Using SNTP only ?</p>
14:13 < jrandom> i dont recall - i think it may be ntp-esque via sntp queries</p>
14:13 < deer> &lt;oOo&gt; Ok, thanks</p>
14:14 < luckypunk> uh</p>
14:14 < luckypunk> i have a suggestion about that..</p>
14:14 < jrandom> anyway, if anyone ever feels bored and wants to do some crazy ntp hacking, that'd Rule</p>
14:14 < luckypunk> Maybe it's wrong though.</p>
14:14 < jrandom> mmhmm lucky?</p>
14:14 < luckypunk> use ntpdate -q</p>
14:14 < luckypunk> get the offset.</p>
14:14 < jrandom> ntpdate -q == SNTP</p>
14:14 < luckypunk> or something similar.</p>
14:14 < deer> &lt;oOo&gt; That is what the current code do, more or less ;)</p>
14:14 * cervantes catches up what he's mised</p>
14:14 < luckypunk> oh.</p>
14:15 < luckypunk> sorry.</p>
14:15 < cervantes> missed</p>
14:15 < deer> &lt;oOo&gt; But we need variable seconds length &amp; co ;)</p>
14:15 < cervantes> cpu usuage on my system is the lowest it's ever been....</p>
14:15 < jrandom> nice</p>
14:15 < cervantes> but I've got 700 odd java threads now and rising</p>
14:15 < jrandom> yeah oOo, and the skew detection / candidate selection</p>
14:16 < luckypunk> yes, last time i ran it, about a month ago, it seriously affected my usability of my box, now i don't even notice if I2P is running.</p>
14:16 < jrandom> yeah i've been looking into that cervantes</p>
14:16 < deer> &lt;oOo&gt; True, even if it's a weak part of the whole stuff ;)</p>
14:16 < luckypunk> i have about 200 threads.</p>
14:16 < luckypunk> 219, to be precise.</p>
14:16 < jrandom> cervantes: i've tracked down the threads to the transport layer (we do some *uuugly* stuff to get timeouts), and we can do some better cleanup later</p>
14:16 -!- TheCrypto__ is now known as thecrypto</p>
14:18 < jrandom> basically some oddities are occurring with the increased # of peers on the network &amp; the churn. all workable, but it can be annoying</p>
14:18 < jrandom> anyway, thats it for 1.1, now 1.2) new router console authentication :)</p>
14:19 < jrandom> (no one probably cares about this, but we have basic http authentication working. see the email for more info)</p>
14:19 < cervantes> cool</p>
14:19 < cervantes> despite that though the memory handling rocks... haven't had an oom in ages</p>
14:19 < jrandom> ah wikked</p>
14:20 < jrandom> actually, that gets us towards 2) 0.4 status</p>
14:22 < luckypunk> Yes. If I2P were a MS product, we'd be ready for 1.0 :)</p>
14:22 < jrandom> arggg, damn net connection dropped</p>
14:22 < jrandom> (screen++)</p>
14:23 < jrandom> ok, anyway, there has been a lot going on, and there are still a few more back end things left to do (some client tunnel pool management, as oOo is seeing, and some peer selection testing, as is in cvs)</p>
14:24 < jrandom> there's also been a lot of progress on the installer / service / systray side of things </p>
14:24 < jrandom> hypercubus: want to give us an update?</p>
14:24 < deer> &lt;hypercubus&gt; sure</p>
14:25 < deer> &lt;hypercubus&gt; the service wrapper installation is nearing completion, perhaps today or tomorrow... the service wrapper takes care of OOMs by automatically restarting the i2p router</p>
14:25 < jrandom> (yay)</p>
14:25 < deer> &lt;hypercubus&gt; so it covers our butts there somewhat</p>
14:26 < deer> &lt;hypercubus&gt; systray integration is complete and works great... it's only for Win32 currently, since the systray4j lib seems to have some bugs in its KDE implementation</p>
14:26 < deer> &lt;hypercubus&gt; i'll be tracking the KDE progress and hopefully we'll have that in the near future</p>
14:27 < deer> &lt;hypercubus&gt; the installer is almost complete as well, all that remains to be added are post-installation tasks</p>
14:27 < deer> &lt;hypercubus&gt; i expect that will be done by the weekend</p>
14:27 < deer> &lt;hypercubus&gt; (as it depends on the complete integration of the service wrapper)</p>
14:28 < jrandom> r0x0r</p>
14:28 < deer> &lt;hypercubus&gt; i'll be making available a pre-0.4 installer package for people to test</p>
14:28 < deer> &lt;hypercubus&gt; so i will let you all know when that's ready</p>
14:28 < luckypunk> What about GNOME?</p>
14:28 < cervantes> increment(hypercubus)</p>
14:28 < deer> &lt;hypercubus&gt; the systray4j project hasn't taken on gnome yet</p>
14:29 < deer> &lt;hypercubus&gt; we'll be adding additional desktop environments as becomes available with systray4j</p>
14:29 < luckypunk> well, no biggie, i'mm gonna switch once/if KDE compiles.</p>
14:30 < deer> &lt;hypercubus&gt; the systray icon is only for launching the router console in your browser anyhow</p>
14:30 < deer> &lt;hypercubus&gt; so its main use will be by windows users ;-)</p>
14:30 < jrandom> yeah, we expect *nix users to know how to bookmark ;)</p>
14:30 < deer> &lt;hypercubus&gt; but we will of course cater to the lazy *nix users when we can ;-)</p>
14:30 < deer> &lt;oOo&gt; N/C...</p>
14:30 < luckypunk> Oh, I have a link in my firefox link hings like, with slashdot and BSD Google.</p>
14:31 < deer> &lt;hypercubus&gt; but the icon does also serve as a convenient status indicator</p>
14:31 < jrandom> agreed</p>
14:31 < deer> &lt;hypercubus&gt; i.e. if the icon is gone, your router is gone too ;-)</p>
14:31 < deer> &lt;hypercubus&gt; unless of course you chose to hide the icon from your router console</p>
14:32 < deer> &lt;hypercubus&gt; which you can do, and it works great</p>
14:32 < deer> &lt;hypercubus&gt; ok, i think that's all, unless there are any questions</p>
14:33 < protok0l> whats a good PDA that runs linux well?</p>
14:33 < jrandom> word hyper</p>
14:33 < jrandom> proto: #i2p-chat (or after the meeting)</p>
14:33 < protok0l> oops</p>
14:33 < deer> &lt;hypercubus&gt; *snicker*</p>
14:33 < jrandom> ok, movin' on to 2.2) jbigi &amp; jcpuid</p>
14:34 < jrandom> iakin has put together some kickass JNI/asm code to detect the exact CPU architecture used (on x86 boxen), and he has jbigi rigged up for freenet to auto-select the right .so/.dll based on that</p>
14:35 < jrandom> he has also released that work into the public domain, and we've snagged a copy and integrated it back into i2p</p>
14:35 < luckypunk> So we won't have to chose which jbigi to download? Won't that make the install somewhat larger?</p>
14:35 < jrandom> correct</p>
14:35 < jrandom> yeah, it adds a few hundred KB</p>
14:36 < jrandom> but, well, the new install is, um, larger than the old one</p>
14:36 < luckypunk> oh, i thought it would be more than a few hundred kb.</p>
14:36 < luckypunk> Yea, between the new console...I'm guessing 6 - 10 mb?</p>
14:36 < deer> * Myo9 has only got 99 mb left on this drive.</p>
14:36 < deer> &lt;Myo9&gt; ;)</p>
14:36 < jrandom> (especially since i'm being an ass and insisting on .war support rather than direct servlets, requiring xerces, which weighs in at 800KB)</p>
14:36 < jrandom> the new install is looking ~4-6MB</p>
14:37 < jrandom> but the good thing is, only ~1MB of that is i2p specific, so updates will be lightweight ;)</p>
14:38 < deer> &lt;Myo9&gt; I2P hasn't got much publication has it?</p>
14:38 < deer> &lt;Myo9&gt; Compared to freenet and TOR?</p>
14:38 < jrandom> correct, we're staying fairly quiet</p>
14:38 < protok0l> is download size a real consern? most people have broadband</p>
14:38 < protok0l> i'm use it if it were 100megs</p>
14:38 < luckypunk> protok0l, most people don't, actually. Most people that'd use I2P do. though i think I2P still supports dialup (sort of)</p>
14:38 < deer> &lt;mule&gt; for i2p users it shouldn't</p>
14:39 < jrandom> in my view, the development effort is best served with gradual adoption after sufficient testing goes on at different crititcal points</p>
14:39 < luckypunk> yes. I2P isn't ready for 500 slashdot users :)</p>
14:39 < jrandom> though our recent growth has been good, helping to poke different parts of the system</p>
14:40 < jrandom> as we launch the 0.4 rev, we will want to move towards the 100-router mark</p>
14:40 < deer> &lt;mule&gt; ok, i'll set up another 50 :)</p>
14:40 < jrandom> plus, that'll give more incentive for client app devs to build client apps ;)</p>
14:40 < jrandom> lol mule :)</p>
14:41 < deer> &lt;ugha2p&gt; Arr.</p>
14:41 < cervantes> at the rate of adoption we could probably reach 100 in about a month</p>
14:41 < cervantes> without evangelising</p>
14:41 < jrandom> that would be a good rate of growth</p>
14:42 < jrandom> but anyway, back to the agenda :)</p>
14:42 < protok0l> i cant wait to evangelize</p>
14:42 < jrandom> jbigi + jcpuid == integrated (and see the mailing list if you want to run CVS HEAD) :)</p>
14:42 < jrandom> heh we can tell proto ;)</p>
14:42 < deer> &lt;hypercubus&gt; lucky: more than half of US internet users have broadband... report was released the other day</p>
14:43 < jrandom> and less than 1/10th of the world is in the us ;)</p>
14:43 < deer> &lt;oOo&gt; Who mind about the USA ? ^^</p>
14:43 < jrandom> but moving on to 2.3) i2paddresshelper</p>
14:44 < jrandom> oOo has put together yet another patch, this one letting people hit eepsites with linked pages without editing hosts.txt</p>
14:45 < jrandom> the details are listed in the weekly status notes</p>
14:45 < jrandom> oOo - is there anything you want to add?</p>
14:45 < deer> &lt;oOo&gt; Hum... Let's the eepsites number grow fast and Cervantes add his promised support :p</p>
14:46 < jrandom> ah, cervantes has already added the "Try it [i2p]" link :)</p>
14:46 < jrandom> (only people on CVS HEAD can use it, until 0.4 is out)</p>
14:46 < cervantes> :o)</p>
14:46 < jrandom> ((works great, btw))</p>
14:46 < deer> &lt;oOo&gt; Great ^^ Will play with it as soon as I manage to get my router back online ;)</p>
14:47 < kaji> you could password the client download and roll it gmail style</p>
14:47 < jrandom> hmm?</p>
14:48 < kaji> small base + invitation only</p>
14:48 < kaji> but that would take work</p>
14:48 < jrandom> oh, for 0.4 release? </p>
14:48 < kaji> oh, for the 1.0</p>
14:48 < jrandom> no, not worth the effort atm. if we get flooded with new users we may want to look at using certificates, etc</p>
14:48 < deer> &lt;oOo&gt; 1.0 is for mass audience :p</p>
14:49 < jrandom> well, for 1.0 we're going to be up past the 1000 user mark already</p>
14:49 < jrandom> (at least, thats my hope ;)</p>
14:49 * kaji thinks it would be fun to watch i2p go from 50 to 5000 node in 3 hours</p>
14:49 < jrandom> heh</p>
14:49 < deer> &lt;oOo&gt; And then down to 100 ;)</p>
14:49 < luckypunk> hypercubus, whoo hoo for americans! they're catching up ;)</p>
14:49 < jrandom> heh, thats one way to test churn ;)</p>
14:50 < cervantes> if aum gets stasher working...and hyper increases his goatse library then you'll see it jump 50 to 5000 is less than 3 hours ;-)</p>
14:50 < kaji> and then 50100 as the nsa brings their node onlin</p>
14:50 < jrandom> actually that kind of brings us forward to 3) AMOC vs. restricted routes</p>
14:51 < jrandom> one of the interesting aspects of restricted routes is the ability to mount a 'sybil' attack really, really, really easily.</p>
14:51 < jrandom> while mule was just mentioning a few minutes ago installing 50 new nodes, it'd be possible to bring online a significant number </p>
14:52 < jrandom> one of the ways to address this is through a certificate authority, limiting the introduction of new routerIdentity certificates</p>
14:52 < jrandom> another is through hashcash</p>
14:52 < jrandom> another is through morphmix/tarzan style ip prefix detection</p>
14:53 < jrandom> but, yet another is to say "fuck it" and hope we get sufficient 'good' peers to outnumber the 'bad' ones</p>
14:53 < fvw> I think that's ok for the time being yes.</p>
14:54 < protok0l> heres an idea</p>
14:54 < jrandom> yeah, its the simplest thing to do, and adding artificial barriers to join a p2p network at this stage seems... foolish</p>
14:54 < fvw> I think perhaps a mix of hashcash and ip-based would be nice to have for 1.0, but all in all you can't defend against a powerful enough adversary.</p>
14:54 < protok0l> cut off the inital noderef access</p>
14:54 < protok0l> if someone wants on, we can give them your noderefs</p>
14:54 < protok0l> *uor</p>
14:54 < fvw> and how would that help?</p>
14:55 < jrandom> right fvw, and we might be able to put it off until after 1.0, as well</p>
14:55 < fvw> depends on your definition of 1.0 :)</p>
14:55 < jrandom> proto: i'm not sure that'd help much</p>
14:55 < jrandom> heh fvw, we're not like freenet ;)</p>
14:56 < jrandom> 1.0 == functional, secure, [sufficiently] anonymous, and scalable</p>
14:56 < deer> &lt;oOo&gt; and well documented ;)</p>
14:56 < jrandom> documentation is a prerequisite to secure :)</p>
14:56 < deer> &lt;Myo9&gt; Are all users added to the noderef at the moment?</p>
14:57 < jrandom> Myo9: yes - http://dev.i2p.net/i2pdb/ is just a link into one of my router's netDb/ dir</p>
14:57 < jrandom> (so it will list everyone my router has a reference for, at any time)</p>
14:58 < jrandom> ((and everyone has a ref for people they talk to, which, at our current scale, is everyone))</p>
14:58 < jrandom> ok, but back to 3) AMOC vs. restricted routes</p>
14:59 < deer> &lt;Myo9&gt; Ok.</p>
14:59 < jrandom> as mentioned in the email, mule's ideas might be able to get us to drop the 0.4.2 AMOC transport and instead implement basic restricted route support, treating people behind NATs/firewalls as simply being behind a restricted route</p>
15:00 < fvw> it would be kind of cool</p>
15:00 < jrandom> yeah, and save us from writing yet another transport protocol</p>
15:01 < deer> &lt;ugha2p&gt; But how would make performing sybil attack that much easier?</p>
15:01 < jrandom> s/writing/designing,implementing,reviewing,debugging,deploying,debugging,debugging,debugging,debugging.../</p>
15:01 < deer> &lt;ugha2p&gt; how would it make*</p>
15:02 < jrandom> ugha2p: there is no way to tell how many *real* routers are behind a restricted route - all we know about them is that they have a unique router identity and are reachable through a certain router</p>
15:02 < deer> &lt;ugha2p&gt; Ah.</p>
15:03 < jrandom> that certain router could in fact be one sim instance, running 100 other routers in the same JVM, each pretending to be behind firwalls</p>
15:03 < deer> &lt;ugha2p&gt; Right.</p>
15:03 < deer> &lt;oOo&gt; They could as easily been using 100 ports on the same host...</p>
15:03 < fvw> however assuming you're willing to spend a few 100 euros on your attack, you can get a large number of spread out IPs anyway.</p>
15:03 < jrandom> agreed fvw</p>
15:04 < jrandom> oOo: true, though ports cost memory (and some CPU)</p>
15:04 < deer> &lt;ugha2p&gt; I don't think that presumption is going to stop more powerful enemies though.</p>
15:04 < jrandom> (which is why when i do larger sims, i need to switch from the TCP comm system to the VM comm system)</p>
15:04 < jrandom> agreed ugha2p</p>
15:04 < jrandom> it just makes it easier</p>
15:05 < fvw> I think we're going to have to assume that anybody with more than a bored-sunday-afternoon desire to attack the system is going to be able to get at least 10^3 nodes on the network easy.</p>
15:05 < deer> &lt;oOo&gt; Not *that* much</p>
15:05 < jrandom> right fvw</p>
15:05 < deer> &lt;oOo&gt; (+ easier)</p>
15:05 < fvw> and at that order of magnitude, nothing apart from central certification is going to stop them.</p>
15:06 < deer> &lt;ugha2p&gt; 100 open ports on one single host would be trivial to detect, but 100 restricted routes behind a machine might not be.</p>
15:06 < jrandom> well, thats open to debate fvw, but yeah, sybil is a bitch</p>
15:06 < deer> &lt;oOo&gt; 100 zombies are tricky to detect ;)</p>
15:06 < fvw> which means we ideally need a 10^4 network.</p>
15:06 < jrandom> definitely oOo</p>
15:06 < fvw> (loose estimates)</p>
15:07 < deer> &lt;ugha2p&gt; We'll ideally have a 10^4+ network.</p>
15:07 < jrandom> fvw: i'd go higher than that - imho we need to grow this into the millions</p>
15:07 < deer> &lt;oOo&gt; Ideally would be more then half available IPs ;)</p>
15:07 < jrandom> heh oOo</p>
15:07 < fvw> It'd be nice if we could yeah.</p>
15:08 < jrandom> (but, of course, to grow it into hte millions we need sufficient reason to do so. i think we will be able to make the case for that eventually though)</p>
15:08 < deer> &lt;ugha2p&gt; I'm not sure if Kademlia could be held in one piece for that long. ;)</p>
15:08 < fvw> at which point beating people up would definately become the low-cost attack. Which, unintuitively enough, would be a good thing.</p>
15:08 < jrandom> heh</p>
15:08 < deer> &lt;DrWoo&gt; jrandom: millions would need serious useability and benefit</p>
15:09 < jrandom> agreed DrWoo</p>
15:09 < fvw> luckily, a lot of (non-nice) people are working very hard on that now.</p>
15:09 < deer> &lt;oOo&gt; Pr0n for masses :p</p>
15:10 < deer> &lt;jrandom&gt; which is why imho we need a kickass filesharing app</p>
15:10 < deer> &lt;oOo&gt; "One human, One goatse", which lead us to stasher :p</p>
15:10 < cervantes> download-&gt;install-&gt;share musi</p>
15:10 < deer> &lt;DrWoo&gt; jrandom: it would have to be order of an anonymous kazza, luckily the motivation is being taken care of by the RIAA &amp; co.</p>
15:10 < fvw> pr0n is already easy to get (see usenet and such). I think big record company assocs and such are going to crack down a lot harder on p2p than pornographers ever could.</p>
15:10 < cervantes> music</p>
15:10 < fvw> but once again we drift offtopic.</p>
15:11 < fvw> "4) stasher"?</p>
15:11 < deer> &lt;oOo&gt; Yeah ! 4) !</p>
15:11 < jrandom> agreed - we can all think up some reasons to justify use, but first we need to get it *working* :)</p>
15:11 < cervantes> ah for once a non-tenuous link into the next item</p>
15:11 < jrandom> movin' to 4) stasher</p>
15:12 < jrandom> aum: you awake yet?</p>
15:12 * hypercubus chants auuuuuummmmmmmmm</p>
15:12 < jrandom> well, in case he isn't, i know he's been doing a lot of work on adding CHK and SVK support to stasher</p>
15:13 < jrandom> which is Cool</p>
15:13 < deer> &lt;oOo&gt; And splitfiles</p>
15:13 < jrandom> yeah, the splitfile support is interesting</p>
15:13 < fvw> in the 'interesting times' sense? </p>
15:14 < jrandom> thats one of the differences between freenet and stasher, in that stasher already has a fixed 31KB max size per key</p>
15:14 < deer> &lt;oOo&gt; "Useful, great, don't need anything from user application"</p>
15:14 < jrandom> (since afaik stasher uses SAM datagrams)</p>
15:14 < luckypunk> can't you impliment lik..split files?</p>
15:15 < jrandom> ooohhh! i just realized what bug he was running into wrt reliability! </p>
15:15 < jrandom> (fixed the other day in cvs, significantly killing the bug)</p>
15:15 < jrandom> yeah lucky</p>
15:15 < jrandom> but the splitfile implementation is inherently different from how freenet splitfiles work, due to max keysize limitations</p>
15:15 < deer> &lt;oOo&gt; So Stasher over-I2P just be healthy again ? ^^</p>
15:16 < jrandom> (if you read freenet devl or tech lately, you'll hear toad and hobx talking it over)</p>
15:16 < deer> &lt;oOo&gt; *should</p>
15:16 < jrandom> oOo: with HEAD, yeah</p>
15:16 * jrandom hasnt heard any reports of people even trying it since 0.3.4.3 came out (or was it 0.3.4.2)</p>
15:16 < jrandom> but anyway, he is planning on another new test build by end of the week</p>
15:17 < jrandom> anyone have anything to mention / discuss wrt stasher?</p>
15:17 < jrandom> (other than yay! go aum!)</p>
15:18 < deer> &lt;oOo&gt; Yeah, there is an urge to find non-goatse contents there ;)</p>
15:18 < jrandom> heh</p>
15:18 < deer> &lt;oOo&gt; ex-Freeneter, start your engines ;)</p>
15:18 < jrandom> yeah splitfile support should definitely help with that, as would ssk &amp; fcp support</p>
15:19 < fvw> I'd like to second the 'go aum!' if I may.</p>
15:19 < deer> &lt;oOo&gt; yay !</p>
15:19 < jrandom> motion is seconded, and thirded :)</p>
15:19 < jrandom> ok, swingin' forward to 5) pages of note</p>
15:20 < jrandom> i just wanted to point out three new pages</p>
15:20 < jrandom> DrWoo's safe browsing guide gives a pretty good rundown on the dangers of eepsites &amp; the outproxies</p>
15:20 < jrandom> the problems can be addressed in code, but we just havent had time to do it yet, so its Good to be informed</p>
15:21 < jrandom> lucky has also put together a good doc on the freebsd+java side of things as well</p>
15:21 * jrandom hasnt tried too many jvms on fbsd, just kaffe, so nag him if you have questions :)</p>
15:22 < jrandom> hyper has also put together the doc for upgrading to the 0.4 dev code, which he'll likely be updating once we want more people to test it ;)</p>
15:22 < hypercubus> my post on the forum covers installation of the service wrapper... the howto for the new router console is here --&gt; http://files.hypercubus.i2p/New_I2P_Router_Console_Howto.txt</p>
15:23 < jrandom> wr0d</p>
15:23 < jrandom> oh, there's also a new pretty picture &amp; some new text @ http://www.i2p.net/how_intro (hopefully making things a bit more clear)</p>
15:24 < fvw> ooh, that looks pretty. Who did that? Good work.</p>
15:25 < hypercubus> it was actually copied directly from a crop circle</p>
15:25 * fvw tries not to mention the resemblence between jrandom and Dave but fails miserably.</p>
15:25 < jrandom> heh</p>
15:25 < fvw> ah, that explains jrandom's feelers.</p>
15:25 < jrandom> the pic was beautified by our anonymous designer</p>
15:25 < jrandom> (thankfully so, my ms paint skills suck :)</p>
15:26 < hypercubus> we're still trying to decipher the significane of Charlie's long chin</p>
15:26 < deer> &lt;ugha2p&gt; Arr, this sucks.</p>
15:26 < jrandom> how about alice's skewed eyes? ;)</p>
15:26 < hypercubus> heh</p>
15:26 < deer> &lt;jrandom&gt; yeah, it'll be nice when we get irc.duck.i2p upgraded (if it hasnt been already..)</p>
15:27 < fvw> never mind that, she looks like she's doing a double alien-bursting-from-stomach-scene with her cheeks.</p>
15:27 < jrandom> lol</p>
15:27 < jrandom> *thats* why she is talking to dave</p>
15:27 < jrandom> well, anyway, i think this leads us to 6) ???</p>
15:27 < fvw> haha</p>
15:27 < jrandom> anyone have anything they want to bring up?</p>
15:28 < deer> &lt;oOo&gt; Can't you build the skeleton of certificates' stuff in I2P and let *others* fill it and have fun ? (Or his this already done ? :p)</p>
15:28 < deer> &lt;oOo&gt; Or is this absolutely useless ?</p>
15:28 < deer> &lt;oOo&gt; (for now)</p>
15:28 < jrandom> hmm? </p>
15:28 < jrandom> the hashcash / etc certificate stuff?</p>
15:28 < deer> &lt;oOo&gt; Ok, nevermind ^^</p>
15:28 < deer> &lt;oOo&gt; Yes</p>
15:29 < jrandom> ok yes, we already have the infrastructure for that</p>
15:29 < jrandom> (though things like libSAM will need to be modified to interpret the destination properly, since iirc nightblade assumed 384bytes always ;)</p>
15:30 < jrandom> but the router will handle different types of certificates transparently</p>
15:30 < deer> &lt;oOo&gt; The code is ready for this ? Just missing some 'content' ?</p>
15:31 < jrandom> yes - the RouterIdentity created currently always attaches a NullCertificate (certificate type == 0)</p>
15:31 < jrandom> if it attaches another type, another type of certificate is attached </p>
15:31 < jrandom> e.g. hashcash cert, CA signed cert, etc</p>
15:31 < jrandom> verification infrastructure is there as well (RouterInfo.verify)</p>
15:32 < deer> &lt;oOo&gt; Oh, great :)</p>
15:32 < deer> &lt;oOo&gt; So someone may play with this code and adding hashcash and stuff in advance ?</p>
15:32 < jrandom> if we had a flash flood i could probably lock down the net in a day or two</p>
15:32 < jrandom> right</p>
15:33 < jrandom> (though i think fvw is right in that it wont be pressing for at least a little while)</p>
15:33 < deer> &lt;oOo&gt; Ok. I don't volunteer ;) But someone might :p</p>
15:33 < Nightblade> on i2p.net, the aug 24 meeting log link is pointed at the aug 17 log</p>
15:33 < jrandom> right, sorry, meeting isn't over yet :)</p>
15:33 < Nightblade> oh haha</p>
15:34 < jrandom> so, anyone have anything else they want to bring up? :)</p>
15:34 < hypercubus> new rule... whoever edits the website: no smokin' the funny stuff while editing!</p>
15:34 < jrandom> uh oh...</p>
15:34 < jrandom> what'd i do?</p>
15:34 < hypercubus> i was referring to broken links ;-)</p>
15:34 < jrandom> oh</p>
15:35 < hypercubus> we need a full time web editor... i nominate lucky</p>
15:35 < jrandom> well, yeah, i updated the link to this weeks weekly status notes before the meeting, in case anyone went to the page ;)</p>
15:35 < jrandom> we certainly do need someone to keep track of the web site and poke people when things are funky</p>
15:36 < luckypunk> me? web enditor?</p>
15:36 < luckypunk> enditor haha</p>
15:36 < luckypunk> i dunno</p>
15:36 < Nightblade> spelchek reqwired</p>
15:36 < luckypunk> i'll probably be pretyt busy once school start.s</p>
15:36 < jrandom> bah, drop out! work on i2p fulltime!</p>
15:36 < luckypunk> if i drop out</p>
15:37 < luckypunk> my parents will make me get a job</p>
15:37 < deer> &lt;hypercubus&gt; excuses excuses ;-)</p>
15:37 < luckypunk> and i'm still busy</p>
15:37 < deer> &lt;hypercubus&gt; amen</p>
15:37 < deer> * oOo will happily renovate the English used on the website ;)</p>
15:37 < luckypunk> anyway, i don't think i'm gonna be allowed to drop out</p>
15:38 < luckypunk> they're raising the legal dropout age to 18</p>
15:38 < luckypunk> or high school diploma</p>
15:38 < luckypunk> whatever comes first. (usually the latter)</p>
15:38 < hypercubus> er</p>
15:38 < Nightblade> haha "legal dropout age" - what will they come up with next?</p>
15:38 < luckypunk> it's 16 now.</p>
15:38 < luckypunk> You can't leave school before that, else they'll arrest you.</p>
15:38 < jrandom> actually, thats a good point.. as we move towards 1.0 it'd be good to offer different translations of various pages</p>
15:39 * luckypunk can make a vague translation intro french, if absolutely required.</p>
15:39 < Nightblade> I'll do the Klingon and Ebonics translations</p>
15:39 < deer> &lt;oOo&gt; Yeah, Klingon translation of the website :p</p>
15:39 < hypercubus> yes, we can offer English, B0rk, and oOo-fried English</p>
15:39 < deer> &lt;oOo&gt; Damned, same idea &gt;&lt;</p>
15:39 < Nightblade> ooo, a mindreader</p>
15:39 < luckypunk> (with the theory that babelfish aided with a human is better than no translation at all.)</p>
15:39 < jrandom> i think we might be able to scam jar into updating his French translation lucky, but thanks ;)</p>
15:39 < deer> &lt;oOo&gt; hyper: will gladly for free like in beer :p</p>
15:40 < jrandom> thats actually one of the big things post 0.4 - getting the docs solid</p>
15:40 < luckypunk> hey, my french is completely intelligible to a french speaker</p>
15:40 < luckypunk> Though i probabxly sound equivilent to godmode0</p>
15:40 < hypercubus> the installer already has native language packs btw</p>
15:40 < jrandom> (perhaps a whitepaper or two on various aspects)</p>
15:40 < jrandom> w3rd hyper</p>
15:40 < deer> * oOo suspect we can master quite some language with the people online here ;)</p>
15:40 < jrandom> (yeah, it'll be tough to translate the paragraph license ;)</p>
15:40 < hypercubus> i could just make it throw up the panel to choose a language</p>
15:40 < jrandom> agreed oOo</p>
15:40 < hypercubus> heheh... libre: </p>
15:40 < jrandom> gratis:</p>
15:41 < luckypunk> gratis and libre</p>
15:41 < luckypunk> damn french and their ability to have two words.</p>
15:41 < jrandom> ok, anything else?</p>
15:41 < hypercubus> we have 10 words for everything</p>
15:41 < luckypunk> though libre also means free beer in quebec french. =(</p>
15:41 < luckypunk> so much for that theory.</p>
15:42 < jrandom> ok... if there's nothing else...</p>
15:42 * jrandom winds up</p>
15:42 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
14:01 < jrandom> 0) hi
14:01 < jrandom> 1) 0.3.4.3 status
14:01 < jrandom> 1.1) timestamper
14:02 < jrandom> 1.2) new router console authentication
14:02 < jrandom> 2) 0.4 status
14:02 < jrandom> 2.1) service &amp; systray integration
14:02 < jrandom> 2.2) jbigi &amp; jcpuid
14:02 < jrandom> 2.3) i2paddresshelper
14:02 < jrandom> 3) AMOC vs. restricted routes
14:02 < jrandom> 4) stasher
14:02 < jrandom> 5) pages of note
14:02 < jrandom> 6) ???
14:02 < jrandom> 0) hi
14:02 * jrandom waves
14:02 < deer> <ugha2p> Hi.
14:02 < jrandom> weekly notes posted (waaay early) at http://dev.i2p.net/pipermail/i2p/2004-August/000419.html
14:03 < jrandom> so i expect you've all done your homework and have read them diligently
14:03 < jrandom> (or something)
14:03 < jrandom> ok, 1) 0.3.4.3 status
14:04 < kaji> (late hi)
14:04 < jrandom> there are a few things adjusted since the 0.3.4.3 release came out last friday, but overall the rev seems pretty stable, from what i can tell
14:04 < deer> <luckypunk> huh. whats going on?
14:04 < deer> <luckypunk> Oh. Nm. sorry, i usually sleep thorugh the meeting though. Hi :)
14:05 < jrandom> what are people's experiences with 0.3.4.3 with regards to eepsites / squid / etc?
14:05 < luckypunk> very quick.
14:05 < jrandom> (i can tell what people are seeing with irc)
14:05 < luckypunk> Under 3 seconds page loading sometimes.
14:06 < deer> <oOo> Jrandom do kick squid's router too often ;)
14:06 < jrandom> cool lucky
14:06 < deer> <mule> working well
14:06 < luckypunk> i can open up 10 pages of things through the squid and I2P keeps up, pretty slowly though, on my 350 mhz.
14:06 < deer> <hypercubus> snappiest it's ever been
14:06 < jrandom> yeah, i do oOo, but thats why we have www1.squid.i2p :)
14:06 < jrandom> r0x0r
14:06 < jrandom> i've heard a few reports of excessive CPU usage - is that hitting people often?
14:07 < deer> <hypercubus> not i... i suspect it's just the people with 386s *cough*lucky*cough*
14:07 < deer> <oOo> Some very rare peaks here. Related to another erro, I might trace it back one day :p
14:07 < deer> <mule> not here
14:07 < luckypunk> I think, if its affecting all platforms and stuff, i would feel it hard, and no not really. Only when its serving the new config pages or downloading a lot of stuff does I2P pin my processor.
14:08 < jrandom> ok cool. there are a few scenarios where i2p will be a bitch wrt CPU, but hopefully those are few and far between
14:08 < jrandom> actually, that leads us in to 1.1) timestamper :)
14:09 < jrandom> (one of the problems can occur when the timestamper gets goofy / loses track of the correct time)
14:10 < jrandom> the whole timestamping stuff has been revamped and integrated into the router, thanks to Adam Buckley being kickass and releasing his work under the BSD license
14:10 < jrandom> (yay Adam)
14:11 < jrandom> we had previously used the SNTP code as a standalone client app, but we are not doing that anymore - instead we have a tight integration with the router
14:11 < jrandom> (so people may need to update their config files as mentioned in the email)
14:11 < jrandom> SNTP alone is only a part of the solution though
14:12 < jrandom> long term we need some better (read: NTP) synchronization, as SNTP is prone to flux
14:12 < jrandom> (especially in light of high network congestion)
14:12 < jrandom> Adam sent me some code he has for dealing with it, but i dont really have the time to work through that side of things atm
14:13 < deer> <oOo> Using SNTP only ?
14:13 < jrandom> i dont recall - i think it may be ntp-esque via sntp queries
14:13 < deer> <oOo> Ok, thanks
14:14 < luckypunk> uh
14:14 < luckypunk> i have a suggestion about that..
14:14 < jrandom> anyway, if anyone ever feels bored and wants to do some crazy ntp hacking, that'd Rule
14:14 < luckypunk> Maybe it's wrong though.
14:14 < jrandom> mmhmm lucky?
14:14 < luckypunk> use ntpdate -q
14:14 < luckypunk> get the offset.
14:14 < jrandom> ntpdate -q == SNTP
14:14 < luckypunk> or something similar.
14:14 < deer> <oOo> That is what the current code do, more or less ;)
14:14 * cervantes catches up what he's mised
14:14 < luckypunk> oh.
14:15 < luckypunk> sorry.
14:15 < cervantes> missed
14:15 < deer> <oOo> But we need variable seconds length &amp; co ;)
14:15 < cervantes> cpu usuage on my system is the lowest it's ever been....
14:15 < jrandom> nice
14:15 < cervantes> but I've got 700 odd java threads now and rising
14:15 < jrandom> yeah oOo, and the skew detection / candidate selection
14:16 < luckypunk> yes, last time i ran it, about a month ago, it seriously affected my usability of my box, now i don't even notice if I2P is running.
14:16 < jrandom> yeah i've been looking into that cervantes
14:16 < deer> <oOo> True, even if it's a weak part of the whole stuff ;)
14:16 < luckypunk> i have about 200 threads.
14:16 < luckypunk> 219, to be precise.
14:16 < jrandom> cervantes: i've tracked down the threads to the transport layer (we do some *uuugly* stuff to get timeouts), and we can do some better cleanup later
14:16 -!- TheCrypto__ is now known as thecrypto
14:18 < jrandom> basically some oddities are occurring with the increased # of peers on the network &amp; the churn. all workable, but it can be annoying
14:18 < jrandom> anyway, thats it for 1.1, now 1.2) new router console authentication :)
14:19 < jrandom> (no one probably cares about this, but we have basic http authentication working. see the email for more info)
14:19 < cervantes> cool
14:19 < cervantes> despite that though the memory handling rocks... haven't had an oom in ages
14:19 < jrandom> ah wikked
14:20 < jrandom> actually, that gets us towards 2) 0.4 status
14:22 < luckypunk> Yes. If I2P were a MS product, we'd be ready for 1.0 :)
14:22 < jrandom> arggg, damn net connection dropped
14:22 < jrandom> (screen++)
14:23 < jrandom> ok, anyway, there has been a lot going on, and there are still a few more back end things left to do (some client tunnel pool management, as oOo is seeing, and some peer selection testing, as is in cvs)
14:24 < jrandom> there's also been a lot of progress on the installer / service / systray side of things
14:24 < jrandom> hypercubus: want to give us an update?
14:24 < deer> <hypercubus> sure
14:25 < deer> <hypercubus> the service wrapper installation is nearing completion, perhaps today or tomorrow... the service wrapper takes care of OOMs by automatically restarting the i2p router
14:25 < jrandom> (yay)
14:25 < deer> <hypercubus> so it covers our butts there somewhat
14:26 < deer> <hypercubus> systray integration is complete and works great... it's only for Win32 currently, since the systray4j lib seems to have some bugs in its KDE implementation
14:26 < deer> <hypercubus> i'll be tracking the KDE progress and hopefully we'll have that in the near future
14:27 < deer> <hypercubus> the installer is almost complete as well, all that remains to be added are post-installation tasks
14:27 < deer> <hypercubus> i expect that will be done by the weekend
14:27 < deer> <hypercubus> (as it depends on the complete integration of the service wrapper)
14:28 < jrandom> r0x0r
14:28 < deer> <hypercubus> i'll be making available a pre-0.4 installer package for people to test
14:28 < deer> <hypercubus> so i will let you all know when that's ready
14:28 < luckypunk> What about GNOME?
14:28 < cervantes> increment(hypercubus)
14:28 < deer> <hypercubus> the systray4j project hasn't taken on gnome yet
14:29 < deer> <hypercubus> we'll be adding additional desktop environments as becomes available with systray4j
14:29 < luckypunk> well, no biggie, i'mm gonna switch once/if KDE compiles.
14:30 < deer> <hypercubus> the systray icon is only for launching the router console in your browser anyhow
14:30 < deer> <hypercubus> so its main use will be by windows users ;-)
14:30 < jrandom> yeah, we expect *nix users to know how to bookmark ;)
14:30 < deer> <hypercubus> but we will of course cater to the lazy *nix users when we can ;-)
14:30 < deer> <oOo> N/C...
14:30 < luckypunk> Oh, I have a link in my firefox link hings like, with slashdot and BSD Google.
14:31 < deer> <hypercubus> but the icon does also serve as a convenient status indicator
14:31 < jrandom> agreed
14:31 < deer> <hypercubus> i.e. if the icon is gone, your router is gone too ;-)
14:31 < deer> <hypercubus> unless of course you chose to hide the icon from your router console
14:32 < deer> <hypercubus> which you can do, and it works great
14:32 < deer> <hypercubus> ok, i think that's all, unless there are any questions
14:33 < protok0l> whats a good PDA that runs linux well?
14:33 < jrandom> word hyper
14:33 < jrandom> proto: #i2p-chat (or after the meeting)
14:33 < protok0l> oops
14:33 < deer> <hypercubus> *snicker*
14:33 < jrandom> ok, movin' on to 2.2) jbigi &amp; jcpuid
14:34 < jrandom> iakin has put together some kickass JNI/asm code to detect the exact CPU architecture used (on x86 boxen), and he has jbigi rigged up for freenet to auto-select the right .so/.dll based on that
14:35 < jrandom> he has also released that work into the public domain, and we've snagged a copy and integrated it back into i2p
14:35 < luckypunk> So we won't have to chose which jbigi to download? Won't that make the install somewhat larger?
14:35 < jrandom> correct
14:35 < jrandom> yeah, it adds a few hundred KB
14:36 < jrandom> but, well, the new install is, um, larger than the old one
14:36 < luckypunk> oh, i thought it would be more than a few hundred kb.
14:36 < luckypunk> Yea, between the new console...I'm guessing 6 - 10 mb?
14:36 < deer> * Myo9 has only got 99 mb left on this drive.
14:36 < deer> <Myo9> ;)
14:36 < jrandom> (especially since i'm being an ass and insisting on .war support rather than direct servlets, requiring xerces, which weighs in at 800KB)
14:36 < jrandom> the new install is looking ~4-6MB
14:37 < jrandom> but the good thing is, only ~1MB of that is i2p specific, so updates will be lightweight ;)
14:38 < deer> <Myo9> I2P hasn't got much publication has it?
14:38 < deer> <Myo9> Compared to freenet and TOR?
14:38 < jrandom> correct, we're staying fairly quiet
14:38 < protok0l> is download size a real consern? most people have broadband
14:38 < protok0l> i'm use it if it were 100megs
14:38 < luckypunk> protok0l, most people don't, actually. Most people that'd use I2P do. though i think I2P still supports dialup (sort of)
14:38 < deer> <mule> for i2p users it shouldn't
14:39 < jrandom> in my view, the development effort is best served with gradual adoption after sufficient testing goes on at different crititcal points
14:39 < luckypunk> yes. I2P isn't ready for 500 slashdot users :)
14:39 < jrandom> though our recent growth has been good, helping to poke different parts of the system
14:40 < jrandom> as we launch the 0.4 rev, we will want to move towards the 100-router mark
14:40 < deer> <mule> ok, i'll set up another 50 :)
14:40 < jrandom> plus, that'll give more incentive for client app devs to build client apps ;)
14:40 < jrandom> lol mule :)
14:41 < deer> <ugha2p> Arr.
14:41 < cervantes> at the rate of adoption we could probably reach 100 in about a month
14:41 < cervantes> without evangelising
14:41 < jrandom> that would be a good rate of growth
14:42 < jrandom> but anyway, back to the agenda :)
14:42 < protok0l> i cant wait to evangelize
14:42 < jrandom> jbigi + jcpuid == integrated (and see the mailing list if you want to run CVS HEAD) :)
14:42 < jrandom> heh we can tell proto ;)
14:42 < deer> <hypercubus> lucky: more than half of US internet users have broadband... report was released the other day
14:43 < jrandom> and less than 1/10th of the world is in the us ;)
14:43 < deer> <oOo> Who mind about the USA ? ^^
14:43 < jrandom> but moving on to 2.3) i2paddresshelper
14:44 < jrandom> oOo has put together yet another patch, this one letting people hit eepsites with linked pages without editing hosts.txt
14:45 < jrandom> the details are listed in the weekly status notes
14:45 < jrandom> oOo - is there anything you want to add?
14:45 < deer> <oOo> Hum... Let's the eepsites number grow fast and Cervantes add his promised support :p
14:46 < jrandom> ah, cervantes has already added the "Try it [i2p]" link :)
14:46 < jrandom> (only people on CVS HEAD can use it, until 0.4 is out)
14:46 < cervantes> :o)
14:46 < jrandom> ((works great, btw))
14:46 < deer> <oOo> Great ^^ Will play with it as soon as I manage to get my router back online ;)
14:47 < kaji> you could password the client download and roll it gmail style
14:47 < jrandom> hmm?
14:48 < kaji> small base + invitation only
14:48 < kaji> but that would take work
14:48 < jrandom> oh, for 0.4 release?
14:48 < kaji> oh, for the 1.0
14:48 < jrandom> no, not worth the effort atm. if we get flooded with new users we may want to look at using certificates, etc
14:48 < deer> <oOo> 1.0 is for mass audience :p
14:49 < jrandom> well, for 1.0 we're going to be up past the 1000 user mark already
14:49 < jrandom> (at least, thats my hope ;)
14:49 * kaji thinks it would be fun to watch i2p go from 50 to 5000 node in 3 hours
14:49 < jrandom> heh
14:49 < deer> <oOo> And then down to 100 ;)
14:49 < luckypunk> hypercubus, whoo hoo for americans! they're catching up ;)
14:49 < jrandom> heh, thats one way to test churn ;)
14:50 < cervantes> if aum gets stasher working...and hyper increases his goatse library then you'll see it jump 50 to 5000 is less than 3 hours ;-)
14:50 < kaji> and then 50100 as the nsa brings their node onlin
14:50 < jrandom> actually that kind of brings us forward to 3) AMOC vs. restricted routes
14:51 < jrandom> one of the interesting aspects of restricted routes is the ability to mount a 'sybil' attack really, really, really easily.
14:51 < jrandom> while mule was just mentioning a few minutes ago installing 50 new nodes, it'd be possible to bring online a significant number
14:52 < jrandom> one of the ways to address this is through a certificate authority, limiting the introduction of new routerIdentity certificates
14:52 < jrandom> another is through hashcash
14:52 < jrandom> another is through morphmix/tarzan style ip prefix detection
14:53 < jrandom> but, yet another is to say "fuck it" and hope we get sufficient 'good' peers to outnumber the 'bad' ones
14:53 < fvw> I think that's ok for the time being yes.
14:54 < protok0l> heres an idea
14:54 < jrandom> yeah, its the simplest thing to do, and adding artificial barriers to join a p2p network at this stage seems... foolish
14:54 < fvw> I think perhaps a mix of hashcash and ip-based would be nice to have for 1.0, but all in all you can't defend against a powerful enough adversary.
14:54 < protok0l> cut off the inital noderef access
14:54 < protok0l> if someone wants on, we can give them your noderefs
14:54 < protok0l> *uor
14:54 < fvw> and how would that help?
14:55 < jrandom> right fvw, and we might be able to put it off until after 1.0, as well
14:55 < fvw> depends on your definition of 1.0 :)
14:55 < jrandom> proto: i'm not sure that'd help much
14:55 < jrandom> heh fvw, we're not like freenet ;)
14:56 < jrandom> 1.0 == functional, secure, [sufficiently] anonymous, and scalable
14:56 < deer> <oOo> and well documented ;)
14:56 < jrandom> documentation is a prerequisite to secure :)
14:56 < deer> <Myo9> Are all users added to the noderef at the moment?
14:57 < jrandom> Myo9: yes - http://dev.i2p.net/i2pdb/ is just a link into one of my router's netDb/ dir
14:57 < jrandom> (so it will list everyone my router has a reference for, at any time)
14:58 < jrandom> ((and everyone has a ref for people they talk to, which, at our current scale, is everyone))
14:58 < jrandom> ok, but back to 3) AMOC vs. restricted routes
14:59 < deer> <Myo9> Ok.
14:59 < jrandom> as mentioned in the email, mule's ideas might be able to get us to drop the 0.4.2 AMOC transport and instead implement basic restricted route support, treating people behind NATs/firewalls as simply being behind a restricted route
15:00 < fvw> it would be kind of cool
15:00 < jrandom> yeah, and save us from writing yet another transport protocol
15:01 < deer> <ugha2p> But how would make performing sybil attack that much easier?
15:01 < jrandom> s/writing/designing,implementing,reviewing,debugging,deploying,debugging,debugging,debugging,debugging.../
15:01 < deer> <ugha2p> how would it make*
15:02 < jrandom> ugha2p: there is no way to tell how many *real* routers are behind a restricted route - all we know about them is that they have a unique router identity and are reachable through a certain router
15:02 < deer> <ugha2p> Ah.
15:03 < jrandom> that certain router could in fact be one sim instance, running 100 other routers in the same JVM, each pretending to be behind firwalls
15:03 < deer> <ugha2p> Right.
15:03 < deer> <oOo> They could as easily been using 100 ports on the same host...
15:03 < fvw> however assuming you're willing to spend a few 100 euros on your attack, you can get a large number of spread out IPs anyway.
15:03 < jrandom> agreed fvw
15:04 < jrandom> oOo: true, though ports cost memory (and some CPU)
15:04 < deer> <ugha2p> I don't think that presumption is going to stop more powerful enemies though.
15:04 < jrandom> (which is why when i do larger sims, i need to switch from the TCP comm system to the VM comm system)
15:04 < jrandom> agreed ugha2p
15:04 < jrandom> it just makes it easier
15:05 < fvw> I think we're going to have to assume that anybody with more than a bored-sunday-afternoon desire to attack the system is going to be able to get at least 10^3 nodes on the network easy.
15:05 < deer> <oOo> Not *that* much
15:05 < jrandom> right fvw
15:05 < deer> <oOo> (+ easier)
15:05 < fvw> and at that order of magnitude, nothing apart from central certification is going to stop them.
15:06 < deer> <ugha2p> 100 open ports on one single host would be trivial to detect, but 100 restricted routes behind a machine might not be.
15:06 < jrandom> well, thats open to debate fvw, but yeah, sybil is a bitch
15:06 < deer> <oOo> 100 zombies are tricky to detect ;)
15:06 < fvw> which means we ideally need a 10^4 network.
15:06 < jrandom> definitely oOo
15:06 < fvw> (loose estimates)
15:07 < deer> <ugha2p> We'll ideally have a 10^4+ network.
15:07 < jrandom> fvw: i'd go higher than that - imho we need to grow this into the millions
15:07 < deer> <oOo> Ideally would be more then half available IPs ;)
15:07 < jrandom> heh oOo
15:07 < fvw> It'd be nice if we could yeah.
15:08 < jrandom> (but, of course, to grow it into hte millions we need sufficient reason to do so. i think we will be able to make the case for that eventually though)
15:08 < deer> <ugha2p> I'm not sure if Kademlia could be held in one piece for that long. ;)
15:08 < fvw> at which point beating people up would definately become the low-cost attack. Which, unintuitively enough, would be a good thing.
15:08 < jrandom> heh
15:08 < deer> <DrWoo> jrandom: millions would need serious useability and benefit
15:09 < jrandom> agreed DrWoo
15:09 < fvw> luckily, a lot of (non-nice) people are working very hard on that now.
15:09 < deer> <oOo> Pr0n for masses :p
15:10 < deer> <jrandom> which is why imho we need a kickass filesharing app
15:10 < deer> <oOo> "One human, One goatse", which lead us to stasher :p
15:10 < cervantes> download->install->share musi
15:10 < deer> <DrWoo> jrandom: it would have to be order of an anonymous kazza, luckily the motivation is being taken care of by the RIAA &amp; co.
15:10 < fvw> pr0n is already easy to get (see usenet and such). I think big record company assocs and such are going to crack down a lot harder on p2p than pornographers ever could.
15:10 < cervantes> music
15:10 < fvw> but once again we drift offtopic.
15:11 < fvw> "4) stasher"?
15:11 < deer> <oOo> Yeah ! 4) !
15:11 < jrandom> agreed - we can all think up some reasons to justify use, but first we need to get it *working* :)
15:11 < cervantes> ah for once a non-tenuous link into the next item
15:11 < jrandom> movin' to 4) stasher
15:12 < jrandom> aum: you awake yet?
15:12 * hypercubus chants auuuuuummmmmmmmm
15:12 < jrandom> well, in case he isn't, i know he's been doing a lot of work on adding CHK and SVK support to stasher
15:13 < jrandom> which is Cool
15:13 < deer> <oOo> And splitfiles
15:13 < jrandom> yeah, the splitfile support is interesting
15:13 < fvw> in the 'interesting times' sense?
15:14 < jrandom> thats one of the differences between freenet and stasher, in that stasher already has a fixed 31KB max size per key
15:14 < deer> <oOo> "Useful, great, don't need anything from user application"
15:14 < jrandom> (since afaik stasher uses SAM datagrams)
15:14 < luckypunk> can't you impliment lik..split files?
15:15 < jrandom> ooohhh! i just realized what bug he was running into wrt reliability!
15:15 < jrandom> (fixed the other day in cvs, significantly killing the bug)
15:15 < jrandom> yeah lucky
15:15 < jrandom> but the splitfile implementation is inherently different from how freenet splitfiles work, due to max keysize limitations
15:15 < deer> <oOo> So Stasher over-I2P just be healthy again ? ^^
15:16 < jrandom> (if you read freenet devl or tech lately, you'll hear toad and hobx talking it over)
15:16 < deer> <oOo> *should
15:16 < jrandom> oOo: with HEAD, yeah
15:16 * jrandom hasnt heard any reports of people even trying it since 0.3.4.3 came out (or was it 0.3.4.2)
15:16 < jrandom> but anyway, he is planning on another new test build by end of the week
15:17 < jrandom> anyone have anything to mention / discuss wrt stasher?
15:17 < jrandom> (other than yay! go aum!)
15:18 < deer> <oOo> Yeah, there is an urge to find non-goatse contents there ;)
15:18 < jrandom> heh
15:18 < deer> <oOo> ex-Freeneter, start your engines ;)
15:18 < jrandom> yeah splitfile support should definitely help with that, as would ssk &amp; fcp support
15:19 < fvw> I'd like to second the 'go aum!' if I may.
15:19 < deer> <oOo> yay !
15:19 < jrandom> motion is seconded, and thirded :)
15:19 < jrandom> ok, swingin' forward to 5) pages of note
15:20 < jrandom> i just wanted to point out three new pages
15:20 < jrandom> DrWoo's safe browsing guide gives a pretty good rundown on the dangers of eepsites &amp; the outproxies
15:20 < jrandom> the problems can be addressed in code, but we just havent had time to do it yet, so its Good to be informed
15:21 < jrandom> lucky has also put together a good doc on the freebsd+java side of things as well
15:21 * jrandom hasnt tried too many jvms on fbsd, just kaffe, so nag him if you have questions :)
15:22 < jrandom> hyper has also put together the doc for upgrading to the 0.4 dev code, which he'll likely be updating once we want more people to test it ;)
15:22 < hypercubus> my post on the forum covers installation of the service wrapper... the howto for the new router console is here --> http://files.hypercubus.i2p/New_I2P_Router_Console_Howto.txt
15:23 < jrandom> wr0d
15:23 < jrandom> oh, there's also a new pretty picture &amp; some new text @ http://www.i2p.net/how_intro (hopefully making things a bit more clear)
15:24 < fvw> ooh, that looks pretty. Who did that? Good work.
15:25 < hypercubus> it was actually copied directly from a crop circle
15:25 * fvw tries not to mention the resemblence between jrandom and Dave but fails miserably.
15:25 < jrandom> heh
15:25 < fvw> ah, that explains jrandom's feelers.
15:25 < jrandom> the pic was beautified by our anonymous designer
15:25 < jrandom> (thankfully so, my ms paint skills suck :)
15:26 < hypercubus> we're still trying to decipher the significane of Charlie's long chin
15:26 < deer> <ugha2p> Arr, this sucks.
15:26 < jrandom> how about alice's skewed eyes? ;)
15:26 < hypercubus> heh
15:26 < deer> <jrandom> yeah, it'll be nice when we get irc.duck.i2p upgraded (if it hasnt been already..)
15:27 < fvw> never mind that, she looks like she's doing a double alien-bursting-from-stomach-scene with her cheeks.
15:27 < jrandom> lol
15:27 < jrandom> *thats* why she is talking to dave
15:27 < jrandom> well, anyway, i think this leads us to 6) ???
15:27 < fvw> haha
15:27 < jrandom> anyone have anything they want to bring up?
15:28 < deer> <oOo> Can't you build the skeleton of certificates' stuff in I2P and let *others* fill it and have fun ? (Or his this already done ? :p)
15:28 < deer> <oOo> Or is this absolutely useless ?
15:28 < deer> <oOo> (for now)
15:28 < jrandom> hmm?
15:28 < jrandom> the hashcash / etc certificate stuff?
15:28 < deer> <oOo> Ok, nevermind ^^
15:28 < deer> <oOo> Yes
15:29 < jrandom> ok yes, we already have the infrastructure for that
15:29 < jrandom> (though things like libSAM will need to be modified to interpret the destination properly, since iirc nightblade assumed 384bytes always ;)
15:30 < jrandom> but the router will handle different types of certificates transparently
15:30 < deer> <oOo> The code is ready for this ? Just missing some 'content' ?
15:31 < jrandom> yes - the RouterIdentity created currently always attaches a NullCertificate (certificate type == 0)
15:31 < jrandom> if it attaches another type, another type of certificate is attached
15:31 < jrandom> e.g. hashcash cert, CA signed cert, etc
15:31 < jrandom> verification infrastructure is there as well (RouterInfo.verify)
15:32 < deer> <oOo> Oh, great :)
15:32 < deer> <oOo> So someone may play with this code and adding hashcash and stuff in advance ?
15:32 < jrandom> if we had a flash flood i could probably lock down the net in a day or two
15:32 < jrandom> right
15:33 < jrandom> (though i think fvw is right in that it wont be pressing for at least a little while)
15:33 < deer> <oOo> Ok. I don't volunteer ;) But someone might :p
15:33 < Nightblade> on i2p.net, the aug 24 meeting log link is pointed at the aug 17 log
15:33 < jrandom> right, sorry, meeting isn't over yet :)
15:33 < Nightblade> oh haha
15:34 < jrandom> so, anyone have anything else they want to bring up? :)
15:34 < hypercubus> new rule... whoever edits the website: no smokin' the funny stuff while editing!
15:34 < jrandom> uh oh...
15:34 < jrandom> what'd i do?
15:34 < hypercubus> i was referring to broken links ;-)
15:34 < jrandom> oh
15:35 < hypercubus> we need a full time web editor... i nominate lucky
15:35 < jrandom> well, yeah, i updated the link to this weeks weekly status notes before the meeting, in case anyone went to the page ;)
15:35 < jrandom> we certainly do need someone to keep track of the web site and poke people when things are funky
15:36 < luckypunk> me? web enditor?
15:36 < luckypunk> enditor haha
15:36 < luckypunk> i dunno
15:36 < Nightblade> spelchek reqwired
15:36 < luckypunk> i'll probably be pretyt busy once school start.s
15:36 < jrandom> bah, drop out! work on i2p fulltime!
15:36 < luckypunk> if i drop out
15:37 < luckypunk> my parents will make me get a job
15:37 < deer> <hypercubus> excuses excuses ;-)
15:37 < luckypunk> and i'm still busy
15:37 < deer> <hypercubus> amen
15:37 < deer> * oOo will happily renovate the English used on the website ;)
15:37 < luckypunk> anyway, i don't think i'm gonna be allowed to drop out
15:38 < luckypunk> they're raising the legal dropout age to 18
15:38 < luckypunk> or high school diploma
15:38 < luckypunk> whatever comes first. (usually the latter)
15:38 < hypercubus> er
15:38 < Nightblade> haha "legal dropout age" - what will they come up with next?
15:38 < luckypunk> it's 16 now.
15:38 < luckypunk> You can't leave school before that, else they'll arrest you.
15:38 < jrandom> actually, thats a good point.. as we move towards 1.0 it'd be good to offer different translations of various pages
15:39 * luckypunk can make a vague translation intro french, if absolutely required.
15:39 < Nightblade> I'll do the Klingon and Ebonics translations
15:39 < deer> <oOo> Yeah, Klingon translation of the website :p
15:39 < hypercubus> yes, we can offer English, B0rk, and oOo-fried English
15:39 < deer> <oOo> Damned, same idea ><
15:39 < Nightblade> ooo, a mindreader
15:39 < luckypunk> (with the theory that babelfish aided with a human is better than no translation at all.)
15:39 < jrandom> i think we might be able to scam jar into updating his French translation lucky, but thanks ;)
15:39 < deer> <oOo> hyper: will gladly for free like in beer :p
15:40 < jrandom> thats actually one of the big things post 0.4 - getting the docs solid
15:40 < luckypunk> hey, my french is completely intelligible to a french speaker
15:40 < luckypunk> Though i probabxly sound equivilent to godmode0
15:40 < hypercubus> the installer already has native language packs btw
15:40 < jrandom> (perhaps a whitepaper or two on various aspects)
15:40 < jrandom> w3rd hyper
15:40 < deer> * oOo suspect we can master quite some language with the people online here ;)
15:40 < jrandom> (yeah, it'll be tough to translate the paragraph license ;)
15:40 < hypercubus> i could just make it throw up the panel to choose a language
15:40 < jrandom> agreed oOo
15:40 < hypercubus> heheh... libre:
15:40 < jrandom> gratis:
15:41 < luckypunk> gratis and libre
15:41 < luckypunk> damn french and their ability to have two words.
15:41 < jrandom> ok, anything else?
15:41 < hypercubus> we have 10 words for everything
15:41 < luckypunk> though libre also means free beer in quebec french. =(
15:41 < luckypunk> so much for that theory.
15:42 < jrandom> ok... if there's nothing else...
15:42 * jrandom winds up
15:42 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/104.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, August 24, 2004
================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,225 +1,219 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 105{% endblock %}
{% block content %}<h3>I2P dev meeting, August 31, 2004</h3>
<div class="irclog">
14:04 < jrandom> 0) hi</p>
14:04 < jrandom> 1) 0.3.4.3</p>
14:04 < jrandom> 2) 0.3.5 and 0.4</p>
14:04 < jrandom> 3) docs</p>
14:04 < jrandom> 4) stasher update</p>
14:04 < jrandom> 5) ???</p>
14:04 < jrandom> 0) hi</p>
14:04 * jrandom waves</p>
14:05 < deer> * Pseudonym waves</p>
14:05 * hypercubus flaps</p>
14:05 < deer> * detonate waves</p>
14:05 < jrandom> weekly status notes @ http://dev.i2p.net/pipermail/i2p/2004-August/000425.html</p>
14:05 < jrandom> moving on to 1) 0.3.4.3</p>
14:06 < jrandom> as it says in the notes, and as you all know from firsthand experience, the net isn't too healthy atm</p>
14:06 < jrandom> lots of messages are lost, and people are often seeing warnings about their leases having expired a while back</p>
14:07 < jrandom> this is unfortunate, and largely addressed in CVS, which will be rolled out when we can (see item 2)</p>
14:07 < kaji> (late) hi</p>
14:08 < jrandom> anyway, i think thats all i've got to mention on 0.3.4.3, beyond whats in the email. i appreciate your patience as we move forward through the rough patches</p>
14:08 < jrandom> swinging on up to 2) 0.3.5 and 0.4 (unless someone has anything else they'd like to add..?)</p>
14:09 < deer> &lt;oOo&gt; So 90% of broken nodes can knock down the network ^^</p>
14:09 < deer> * Pseudonym eagerly awaits the release of 0.3.5</p>
14:09 < kaji> who was running the dos? they did a good job</p>
14:10 < jrandom> well, I can reach squid consistently from my other CVS HEAD boxes</p>
14:10 < jrandom> so the network isn't 'knocked out' for people on cvs head :)</p>
14:10 * lucky is having partial success with .3.4.3 still.</p>
14:10 < jrandom> but yeah, the old peer selection algorithm did some Stupid Things</p>
14:10 < deer> &lt;oOo&gt; I'm on CVS head and lost suid.i2p a lot of time ;)</p>
14:11 < jrandom> hmm</p>
14:11 < jrandom> what are you seeing for a tunnel failure rate? </p>
14:12 < jrandom> (total # events at /routerStats.html#tunnel.failAfterTime compared with total # events at #tunnel.buildFrequency )</p>
14:13 < deer> &lt;oOo&gt; lifetime average value: 288 268,91 over 339,00 events</p>
14:13 < jrandom> and tunnel.buildFrequency?</p>
14:14 < deer> &lt;oOo&gt; But you might have been restarting your router too much while repairing thread leaks ;)</p>
14:14 < jrandom> what is your lifetime # of tunnel.buildFrequency?</p>
14:14 < deer> &lt;oOo&gt; 24h frequency: avg per period: (2,76, max 2,76, current is 100,00% of max) strict average per period: 5 645,58 events (averaged using the lifetime of 5 729,00 events)</p>
14:14 < deer> &lt;oOo&gt; 24h ~= router lifetime</p>
14:15 < jrandom> so ~5% tunnel failure</p>
14:15 < jrandom> thats about what i've been seeing on CVS HEAD, as opposed to the 40-60% tunnel failure of 0.3.4.3</p>
14:16 < deer> &lt;oOo&gt; Let's swing on up to 2) then ;)</p>
14:16 < jrandom> consider it swung</p>
14:16 < jrandom> ok, as mentioned in the email, the next rev will be 0.3.5, not 0.4</p>
14:16 < jrandom> it'll have all the goodies y'all have been waiting for, but it won't have the "0.4 stamp of approval" ;)</p>
14:17 < deer> &lt;Pseudonym&gt; 0.4.rc-1</p>
14:17 < jrandom> well, i considered going down the rc road, but I dont want to be overconfident</p>
14:17 < kaji> 0.4.rc-0.9</p>
14:17 < deer> &lt;Pseudonym&gt; heh</p>
14:18 < kaji> beta</p>
14:18 < jrandom> while 0.3.5 is out, I'm going to see if we can mount the DoS again, as well as a variety of new issues that we should be able to come up with</p>
14:18 < lucky> we have to keep DoSing it till it works while being DoSed</p>
14:18 < jrandom> right</p>
14:19 < kaji> dos it till it cant be dosed no more</p>
14:19 < deer> &lt;Pseudonym&gt; but no new features between 0.3.5 and 0.4 right?</p>
14:19 < jrandom> perhaps someone can be inspired to help out with implementing some churn and fail cases in the simulator, so we can test this stuff more easily and automatically... ;)</p>
14:20 < jrandom> correct Pseudonym, I do not expect any significant new features to come during 0.3.5</p>
14:20 < jrandom> at least, from an app user perspective</p>
14:20 < jrandom> perhaps some developer will take this time to improve upon the eepproxy, a transparent webserver, help out aum, etc </p>
14:21 * jrandom pokes at someone hacking on an irc proxy w/ DCC support ;)</p>
14:21 < deer> &lt;duck&gt; a public inproxy for i2p/tor is in the make</p>
14:21 < jrandom> ah nice, html specific, or bitpipe?</p>
14:21 < jrandom> er, web specific, that is</p>
14:22 < deer> &lt;duck&gt; web specific</p>
14:22 < jrandom> w3rd</p>
14:22 < deer> &lt;duck&gt; the idea being that an ISP can put up some gateways to specific sites</p>
14:22 < deer> &lt;duck&gt; so the world can access alexandria</p>
14:23 < jrandom> ooh, what would *really* rule is if those gateways could act as vhosts</p>
14:23 < jrandom> (maybe thats what you're talking about anyway)</p>
14:23 < deer> &lt;duck&gt; http://anonygateway.com/home.duck.i2p/~alexandria/</p>
14:23 < jrandom> ah ok</p>
14:23 < jrandom> still cool</p>
14:23 < deer> &lt;duck&gt; http://anonygateway.com/6sxoyfb3h2nvok2d.onion/</p>
14:24 < deer> &lt;duck&gt; virtual host is also possible; just for a next iteration</p>
14:24 < jrandom> (though 6sxoyfb3h2nvok2d.onion.anonygateway.com would be cooler ;)</p>
14:24 < jrandom> right right</p>
14:24 < deer> &lt;duck&gt; easy to do with a mod_rewrite ofcourse</p>
14:25 < cervantes> or just set up a subdomain :)</p>
14:25 < kaji> hah vhost a bittorent seed</p>
14:25 < deer> &lt;duck&gt; I am paying dev out of my pocket; patch will be pub domain</p>
14:25 < jrandom> duck++</p>
14:26 < deer> &lt;duck&gt; also talking with an ISP who might want to offer it as a paid service</p>
14:26 < jrandom> nice</p>
14:26 < deer> &lt;duck&gt; ofcourse it is better when anarchistgang.org does so</p>
14:26 < deer> &lt;duck&gt; but you know the stability of those types</p>
14:26 < jrandom> *cough*</p>
14:27 < cervantes> their quackers</p>
14:27 < cervantes> *they're</p>
14:27 < deer> &lt;jon2&gt; hi!!!!!!</p>
14:27 * hypercubus snickers</p>
14:27 < jrandom> hi jon2</p>
14:27 < deer> &lt;jon2&gt; I like meeting &gt;:-D</p>
14:28 < jrandom> i think after the net is settled down a bit more (once 0.3.5 is out there), we'll want to reevaluate some app level activities</p>
14:28 < deer> &lt;duck&gt; *cough* myi2p?</p>
14:28 < jrandom> heh</p>
14:29 < kaji> what about access behind a firewall?</p>
14:29 < deer> &lt;jon2&gt; yes, firewall access :)</p>
14:29 < jrandom> we need something rock solid, usable, *and* secure, that provides functionality that people want (and hopefully, that we can use to encourage community)</p>
14:30 < deer> * duck points at 0.4.2 @ http://www.i2p.net/roadmap</p>
14:30 < jrandom> believe me, i want access behind firewalls / uncontrollable NATs / etc just as much as the rest of you.</p>
14:30 < deer> &lt;jon2&gt; I can do the secure part, I know cryptophagy.</p>
14:30 < jrandom> (someone has to add that as a quote ;)</p>
14:30 * hypercubus wonders what a cryptophage is</p>
14:31 < jrandom> jon2 - we definitely need help on this stuff and would love to snag some of your time!</p>
14:31 * kaji just started back to school, he would like to take i2p with him ;)</p>
14:31 < aum> morning all</p>
14:31 < cervantes> btw I'm wondering if any devs miss their little i2p blogs.... if perhaps they should get devoted forum sections, at least in the short term...</p>
14:31 < cervantes> *if so</p>
14:31 < deer> &lt;jon2&gt; cryptophagy, science of security.</p>
14:31 < jrandom> 'mornin aum</p>
14:32 < hypercubus> jon2: do you also know cryptography?</p>
14:32 < deer> &lt;jon2&gt; Good morning aum.</p>
14:32 < jrandom> cervantes: i'm holding off until i can get a blog of my own, which hopefully wont be too far off</p>
14:32 < deer> &lt;jon2&gt; no :-(</p>
14:33 < cervantes> jrandom: and everyone else?</p>
14:33 < jrandom> nightblade has been using his blog @ cashdollar.org</p>
14:33 < deer> &lt;jon2&gt; I have a blog on blogs.aspnet.com</p>
14:33 < jrandom> though i suppose it'd be cool to have people posting on the forum</p>
14:34 < cervantes> ah good...well it seems most have found alternatives....but it's a same they've become fragmented</p>
14:34 < jrandom> yeah</p>
14:34 < cervantes> *shame</p>
14:34 < cervantes> darn fingerzzz</p>
14:34 < lucky> well, a phage is part oft he immune system.</p>
14:34 < jrandom> i liked having the devblogs on the site. we'll get something back eventually</p>
14:34 < hypercubus> jon2: funny, blogs.aspnet.com is an unclaimed domain</p>
14:34 < jrandom> ok, anyway, anything else for 2) 0.3.5 and 0.4 ?</p>
14:35 < hypercubus> yeah</p>
14:35 < hypercubus> i've got the firefox problem solved now, in cvs</p>
14:35 < jrandom> w000t</p>
14:36 < deer> &lt;jon2&gt; I am asp developer.</p>
14:36 < hypercubus> reads the default from the registry</p>
14:36 < cervantes> :)</p>
14:36 < deer> &lt;jon2&gt; sorry.. I mean blogs.asp.net</p>
14:36 < hypercubus> no you don't</p>
14:36 < deer> &lt;jon2&gt; weblogs.asp.net</p>
14:36 < jrandom> ah, great hypercubus. so we're almost there for the 0.3.5 release</p>
14:37 < cervantes> shudder....asp</p>
14:37 < hypercubus> yes i can feel it getting close</p>
14:37 < jrandom> ok, moving on to 3) docs</p>
14:37 < jrandom> well, I dont have anything to add beyond my request in the email</p>
14:38 < jrandom> (send in your questions! post 'em to the list, send 'em in email, post 'em on the forum)</p>
14:38 < deer> &lt;oOo&gt; Yeah, anonymously use the forum and make Cervantes happy ;)</p>
14:39 * cervantes gets all tingly</p>
14:39 * hypercubus adjusts the rabbit ears</p>
14:40 < nicktastic> haha</p>
14:40 < deer> &lt;jon2&gt; I liked this meeting..</p>
14:40 < cervantes> you said that...</p>
14:40 < cervantes> &lt;deer&gt; &lt;jon2&gt; I like meeting &gt;:-D</p>
14:40 < hypercubus> great, you get to buy the donuts next time ;-)</p>
14:40 < jrandom> ok, if there's nothing else, 4) stasher update</p>
14:41 < jrandom> aum seems to have awoken early... you still 'round?</p>
14:41 < deer> &lt;jon2&gt; GREAT MEETING!</p>
14:41 * hypercubus wonders if dm has children</p>
14:41 < jrandom> heh, yeah, he's back ;)</p>
14:41 < cervantes> I'd think it's an impossibility</p>
14:42 < hypercubus> guess aum missed that first cuppa</p>
14:42 < jrandom> ok, maybe he'll swing back to the term</p>
14:42 < jrandom> anyway, his general update was posted in the email</p>
14:42 < jrandom> looks like there's lots of progress going on</p>
14:43 < jrandom> some questions remain, but ever onward </p>
14:43 < deer> &lt;oOo&gt; But no release date given ;)</p>
14:43 < hypercubus> how many people are testing it atm?</p>
14:43 < jrandom> i dont know if the code he has now w/ the things mentioned is public yet</p>
14:43 < hypercubus> ah</p>
14:44 < deer> &lt;jon2&gt; BAF BAF BAF BAF BAF</p>
14:44 < kaji> whats new about stasher?</p>
14:44 < jrandom> kaji: see the http://dev.i2p.net/pipermail/i2p/2004-August/000425.html</p>
14:45 < deer> &lt;oOo&gt; It now use less water to wash the dishes</p>
14:45 < hypercubus> i've been waiting for that feature</p>
14:45 * jrandom too</p>
14:45 < jrandom> ok</p>
14:45 < jrandom> if aum is still afk, swinging on to 5) ???</p>
14:45 < jrandom> does anyone else have something they want to bring up?</p>
14:45 * cervantes puts on a tin hat</p>
14:46 < lucky> How's jetta for serving web pages coming along?</p>
14:46 < jrandom> i dont know of anyone working on an app to safely allow people to host pages with jetty</p>
14:46 < jrandom> (host pages that can be served as an eepsite, that is)</p>
14:47 < jrandom> jetty does allow people to deploy client applications (though i dont know anyone working on a web based app yet either)</p>
14:47 < hypercubus> i'd like to say something about systray4j vs. SWT</p>
14:47 < jrandom> mmhmm?</p>
14:47 < hypercubus> the cost of ditching systray4j for SWT: we'd be dropping systray4j.jar and systray4j.dll, shedding 147 KB from our distribution size -- and replacing that with swt.jar (885 KB) + native libs (332 KB on Win, 639 KB on *nix), a net difference of 1.2-1.5 MB, but with that we gain systray icons on KDE, Gnome, and OS X as well as Win32, and also launch icons for plain X environments a la NextStep/GNUstep</p>
14:48 < hypercubus> and this will give us the ability to add other GUI components later, independent of the JRE the user has (otherwise, accomodating Kaffe users would limit us to using AWT only)</p>
14:48 < hypercubus> just food for thought... maybe down the road</p>
14:48 < jrandom> worth discussing, down the road, as users demand it</p>
14:49 < jrandom> if the value is there, the value is there</p>
14:49 < deer> &lt;oOo&gt; Web interface is intend to be the GUI, isn't it ?</p>
14:49 < hypercubus> cervantes had a cool idea to make further use of SWT</p>
14:49 < hypercubus> an I2P dashboard ;-)</p>
14:49 < jrandom> yes oOo</p>
14:49 < hypercubus> oh, and skins! j/k</p>
14:49 < jrandom> i'd really much rather have that sort of functionality built into the router console, if you mean what i think you mean</p>
14:50 < hypercubus> point is...</p>
14:50 < cervantes> it might also encourage application development if i2p comes with a nice set of SWT libraries</p>
14:50 < hypercubus> it seems development on systray4j is winding down or otherwise mired</p>
14:50 < deer> &lt;oOo&gt; As long as systray and GUI stuff aren't mandatory to have a fully working router...</p>
14:50 < jrandom> right oOo</p>
14:50 < hypercubus> i don't see them fixing the KDE version anytime soon</p>
14:51 < hypercubus> correct, we could just add a hook in the router's systray class</p>
14:51 < hypercubus> and the user could optionally download the systray/SWT stuff</p>
14:51 < jrandom> hypercubus: personally, i'm not entirely 100% sure the user base will even need a systray. i think we need to deploy it and get feedback to know the value</p>
14:51 < jrandom> cervantes: client application developers can absolutely bundle SWT with their app</p>
14:51 < jrandom> (or say "get SWT")</p>
14:51 < hypercubus> i suspect we'll get requests for expanded systray options</p>
14:52 < jrandom> and if a client app dev gets something we want to bundle with the router, we'll deploy swt with the bundle</p>
14:52 < jrandom> (etc)</p>
14:52 < deer> &lt;oOo&gt; Too late to split the console/status monitor/whatever from the really-routing-stuff ?</p>
14:52 < jrandom> really routing stuff?</p>
14:52 < jrandom> the router console is a fully seperate client application</p>
14:53 < jrandom> (apps/routnerconsole/)</p>
14:53 < deer> &lt;oOo&gt; The stuff needed to have the bytes anonymously flowing</p>
14:53 < jrandom> i do think down the line we will want to have a minimal-router install as well</p>
14:53 < jrandom> (with nothing in clients.config, etc)</p>
14:53 < jrandom> but we dont have the developer hours to maintain multiple sets of things</p>
14:55 < jrandom> ok, anyone else have anything they want to bring up?</p>
14:57 < jrandom> if not</p>
14:57 * jrandom winds up</p>
14:57 < deer> &lt;oOo&gt; 0.3.5, when ? ;)</p>
14:57 < jrandom> it'll be out hopefully this week</p>
14:57 < jrandom> (in the next day or two if all goes well)</p>
14:57 < deer> &lt;oOo&gt; Ok ^^</p>
14:57 * jrandom stops winding up</p>
14:57 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
14:04 < jrandom> 0) hi
14:04 < jrandom> 1) 0.3.4.3
14:04 < jrandom> 2) 0.3.5 and 0.4
14:04 < jrandom> 3) docs
14:04 < jrandom> 4) stasher update
14:04 < jrandom> 5) ???
14:04 < jrandom> 0) hi
14:04 * jrandom waves
14:05 < deer> * Pseudonym waves
14:05 * hypercubus flaps
14:05 < deer> * detonate waves
14:05 < jrandom> weekly status notes @ http://dev.i2p.net/pipermail/i2p/2004-August/000425.html
14:05 < jrandom> moving on to 1) 0.3.4.3
14:06 < jrandom> as it says in the notes, and as you all know from firsthand experience, the net isn't too healthy atm
14:06 < jrandom> lots of messages are lost, and people are often seeing warnings about their leases having expired a while back
14:07 < jrandom> this is unfortunate, and largely addressed in CVS, which will be rolled out when we can (see item 2)
14:07 < kaji> (late) hi
14:08 < jrandom> anyway, i think thats all i've got to mention on 0.3.4.3, beyond whats in the email. i appreciate your patience as we move forward through the rough patches
14:08 < jrandom> swinging on up to 2) 0.3.5 and 0.4 (unless someone has anything else they'd like to add..?)
14:09 < deer> <oOo> So 90% of broken nodes can knock down the network ^^
14:09 < deer> * Pseudonym eagerly awaits the release of 0.3.5
14:09 < kaji> who was running the dos? they did a good job
14:10 < jrandom> well, I can reach squid consistently from my other CVS HEAD boxes
14:10 < jrandom> so the network isn't 'knocked out' for people on cvs head :)
14:10 * lucky is having partial success with .3.4.3 still.
14:10 < jrandom> but yeah, the old peer selection algorithm did some Stupid Things
14:10 < deer> <oOo> I'm on CVS head and lost suid.i2p a lot of time ;)
14:11 < jrandom> hmm
14:11 < jrandom> what are you seeing for a tunnel failure rate?
14:12 < jrandom> (total # events at /routerStats.html#tunnel.failAfterTime compared with total # events at #tunnel.buildFrequency )
14:13 < deer> <oOo> lifetime average value: 288 268,91 over 339,00 events
14:13 < jrandom> and tunnel.buildFrequency?
14:14 < deer> <oOo> But you might have been restarting your router too much while repairing thread leaks ;)
14:14 < jrandom> what is your lifetime # of tunnel.buildFrequency?
14:14 < deer> <oOo> 24h frequency: avg per period: (2,76, max 2,76, current is 100,00% of max) strict average per period: 5 645,58 events (averaged using the lifetime of 5 729,00 events)
14:14 < deer> <oOo> 24h ~= router lifetime
14:15 < jrandom> so ~5% tunnel failure
14:15 < jrandom> thats about what i've been seeing on CVS HEAD, as opposed to the 40-60% tunnel failure of 0.3.4.3
14:16 < deer> <oOo> Let's swing on up to 2) then ;)
14:16 < jrandom> consider it swung
14:16 < jrandom> ok, as mentioned in the email, the next rev will be 0.3.5, not 0.4
14:16 < jrandom> it'll have all the goodies y'all have been waiting for, but it won't have the "0.4 stamp of approval" ;)
14:17 < deer> <Pseudonym> 0.4.rc-1
14:17 < jrandom> well, i considered going down the rc road, but I dont want to be overconfident
14:17 < kaji> 0.4.rc-0.9
14:17 < deer> <Pseudonym> heh
14:18 < kaji> beta
14:18 < jrandom> while 0.3.5 is out, I'm going to see if we can mount the DoS again, as well as a variety of new issues that we should be able to come up with
14:18 < lucky> we have to keep DoSing it till it works while being DoSed
14:18 < jrandom> right
14:19 < kaji> dos it till it cant be dosed no more
14:19 < deer> <Pseudonym> but no new features between 0.3.5 and 0.4 right?
14:19 < jrandom> perhaps someone can be inspired to help out with implementing some churn and fail cases in the simulator, so we can test this stuff more easily and automatically... ;)
14:20 < jrandom> correct Pseudonym, I do not expect any significant new features to come during 0.3.5
14:20 < jrandom> at least, from an app user perspective
14:20 < jrandom> perhaps some developer will take this time to improve upon the eepproxy, a transparent webserver, help out aum, etc
14:21 * jrandom pokes at someone hacking on an irc proxy w/ DCC support ;)
14:21 < deer> <duck> a public inproxy for i2p/tor is in the make
14:21 < jrandom> ah nice, html specific, or bitpipe?
14:21 < jrandom> er, web specific, that is
14:22 < deer> <duck> web specific
14:22 < jrandom> w3rd
14:22 < deer> <duck> the idea being that an ISP can put up some gateways to specific sites
14:22 < deer> <duck> so the world can access alexandria
14:23 < jrandom> ooh, what would *really* rule is if those gateways could act as vhosts
14:23 < jrandom> (maybe thats what you're talking about anyway)
14:23 < deer> <duck> http://anonygateway.com/home.duck.i2p/~alexandria/
14:23 < jrandom> ah ok
14:23 < jrandom> still cool
14:23 < deer> <duck> http://anonygateway.com/6sxoyfb3h2nvok2d.onion/
14:24 < deer> <duck> virtual host is also possible; just for a next iteration
14:24 < jrandom> (though 6sxoyfb3h2nvok2d.onion.anonygateway.com would be cooler ;)
14:24 < jrandom> right right
14:24 < deer> <duck> easy to do with a mod_rewrite ofcourse
14:25 < cervantes> or just set up a subdomain :)
14:25 < kaji> hah vhost a bittorent seed
14:25 < deer> <duck> I am paying dev out of my pocket; patch will be pub domain
14:25 < jrandom> duck++
14:26 < deer> <duck> also talking with an ISP who might want to offer it as a paid service
14:26 < jrandom> nice
14:26 < deer> <duck> ofcourse it is better when anarchistgang.org does so
14:26 < deer> <duck> but you know the stability of those types
14:26 < jrandom> *cough*
14:27 < cervantes> their quackers
14:27 < cervantes> *they're
14:27 < deer> <jon2> hi!!!!!!
14:27 * hypercubus snickers
14:27 < jrandom> hi jon2
14:27 < deer> <jon2> I like meeting >:-D
14:28 < jrandom> i think after the net is settled down a bit more (once 0.3.5 is out there), we'll want to reevaluate some app level activities
14:28 < deer> <duck> *cough* myi2p?
14:28 < jrandom> heh
14:29 < kaji> what about access behind a firewall?
14:29 < deer> <jon2> yes, firewall access :)
14:29 < jrandom> we need something rock solid, usable, *and* secure, that provides functionality that people want (and hopefully, that we can use to encourage community)
14:30 < deer> * duck points at 0.4.2 @ http://www.i2p.net/roadmap
14:30 < jrandom> believe me, i want access behind firewalls / uncontrollable NATs / etc just as much as the rest of you.
14:30 < deer> <jon2> I can do the secure part, I know cryptophagy.
14:30 < jrandom> (someone has to add that as a quote ;)
14:30 * hypercubus wonders what a cryptophage is
14:31 < jrandom> jon2 - we definitely need help on this stuff and would love to snag some of your time!
14:31 * kaji just started back to school, he would like to take i2p with him ;)
14:31 < aum> morning all
14:31 < cervantes> btw I'm wondering if any devs miss their little i2p blogs.... if perhaps they should get devoted forum sections, at least in the short term...
14:31 < cervantes> *if so
14:31 < deer> <jon2> cryptophagy, science of security.
14:31 < jrandom> 'mornin aum
14:32 < hypercubus> jon2: do you also know cryptography?
14:32 < deer> <jon2> Good morning aum.
14:32 < jrandom> cervantes: i'm holding off until i can get a blog of my own, which hopefully wont be too far off
14:32 < deer> <jon2> no :-(
14:33 < cervantes> jrandom: and everyone else?
14:33 < jrandom> nightblade has been using his blog @ cashdollar.org
14:33 < deer> <jon2> I have a blog on blogs.aspnet.com
14:33 < jrandom> though i suppose it'd be cool to have people posting on the forum
14:34 < cervantes> ah good...well it seems most have found alternatives....but it's a same they've become fragmented
14:34 < jrandom> yeah
14:34 < cervantes> *shame
14:34 < cervantes> darn fingerzzz
14:34 < lucky> well, a phage is part oft he immune system.
14:34 < jrandom> i liked having the devblogs on the site. we'll get something back eventually
14:34 < hypercubus> jon2: funny, blogs.aspnet.com is an unclaimed domain
14:34 < jrandom> ok, anyway, anything else for 2) 0.3.5 and 0.4 ?
14:35 < hypercubus> yeah
14:35 < hypercubus> i've got the firefox problem solved now, in cvs
14:35 < jrandom> w000t
14:36 < deer> <jon2> I am asp developer.
14:36 < hypercubus> reads the default from the registry
14:36 < cervantes> :)
14:36 < deer> <jon2> sorry.. I mean blogs.asp.net
14:36 < hypercubus> no you don't
14:36 < deer> <jon2> weblogs.asp.net
14:36 < jrandom> ah, great hypercubus. so we're almost there for the 0.3.5 release
14:37 < cervantes> shudder....asp
14:37 < hypercubus> yes i can feel it getting close
14:37 < jrandom> ok, moving on to 3) docs
14:37 < jrandom> well, I dont have anything to add beyond my request in the email
14:38 < jrandom> (send in your questions! post 'em to the list, send 'em in email, post 'em on the forum)
14:38 < deer> <oOo> Yeah, anonymously use the forum and make Cervantes happy ;)
14:39 * cervantes gets all tingly
14:39 * hypercubus adjusts the rabbit ears
14:40 < nicktastic> haha
14:40 < deer> <jon2> I liked this meeting..
14:40 < cervantes> you said that...
14:40 < cervantes> <deer> <jon2> I like meeting >:-D
14:40 < hypercubus> great, you get to buy the donuts next time ;-)
14:40 < jrandom> ok, if there's nothing else, 4) stasher update
14:41 < jrandom> aum seems to have awoken early... you still 'round?
14:41 < deer> <jon2> GREAT MEETING!
14:41 * hypercubus wonders if dm has children
14:41 < jrandom> heh, yeah, he's back ;)
14:41 < cervantes> I'd think it's an impossibility
14:42 < hypercubus> guess aum missed that first cuppa
14:42 < jrandom> ok, maybe he'll swing back to the term
14:42 < jrandom> anyway, his general update was posted in the email
14:42 < jrandom> looks like there's lots of progress going on
14:43 < jrandom> some questions remain, but ever onward
14:43 < deer> <oOo> But no release date given ;)
14:43 < hypercubus> how many people are testing it atm?
14:43 < jrandom> i dont know if the code he has now w/ the things mentioned is public yet
14:43 < hypercubus> ah
14:44 < deer> <jon2> BAF BAF BAF BAF BAF
14:44 < kaji> whats new about stasher?
14:44 < jrandom> kaji: see the http://dev.i2p.net/pipermail/i2p/2004-August/000425.html
14:45 < deer> <oOo> It now use less water to wash the dishes
14:45 < hypercubus> i've been waiting for that feature
14:45 * jrandom too
14:45 < jrandom> ok
14:45 < jrandom> if aum is still afk, swinging on to 5) ???
14:45 < jrandom> does anyone else have something they want to bring up?
14:45 * cervantes puts on a tin hat
14:46 < lucky> How's jetta for serving web pages coming along?
14:46 < jrandom> i dont know of anyone working on an app to safely allow people to host pages with jetty
14:46 < jrandom> (host pages that can be served as an eepsite, that is)
14:47 < jrandom> jetty does allow people to deploy client applications (though i dont know anyone working on a web based app yet either)
14:47 < hypercubus> i'd like to say something about systray4j vs. SWT
14:47 < jrandom> mmhmm?
14:47 < hypercubus> the cost of ditching systray4j for SWT: we'd be dropping systray4j.jar and systray4j.dll, shedding 147 KB from our distribution size -- and replacing that with swt.jar (885 KB) + native libs (332 KB on Win, 639 KB on *nix), a net difference of 1.2-1.5 MB, but with that we gain systray icons on KDE, Gnome, and OS X as well as Win32, and also launch icons for plain X environments a la NextStep/GNUstep
14:48 < hypercubus> and this will give us the ability to add other GUI components later, independent of the JRE the user has (otherwise, accomodating Kaffe users would limit us to using AWT only)
14:48 < hypercubus> just food for thought... maybe down the road
14:48 < jrandom> worth discussing, down the road, as users demand it
14:49 < jrandom> if the value is there, the value is there
14:49 < deer> <oOo> Web interface is intend to be the GUI, isn't it ?
14:49 < hypercubus> cervantes had a cool idea to make further use of SWT
14:49 < hypercubus> an I2P dashboard ;-)
14:49 < jrandom> yes oOo
14:49 < hypercubus> oh, and skins! j/k
14:49 < jrandom> i'd really much rather have that sort of functionality built into the router console, if you mean what i think you mean
14:50 < hypercubus> point is...
14:50 < cervantes> it might also encourage application development if i2p comes with a nice set of SWT libraries
14:50 < hypercubus> it seems development on systray4j is winding down or otherwise mired
14:50 < deer> <oOo> As long as systray and GUI stuff aren't mandatory to have a fully working router...
14:50 < jrandom> right oOo
14:50 < hypercubus> i don't see them fixing the KDE version anytime soon
14:51 < hypercubus> correct, we could just add a hook in the router's systray class
14:51 < hypercubus> and the user could optionally download the systray/SWT stuff
14:51 < jrandom> hypercubus: personally, i'm not entirely 100% sure the user base will even need a systray. i think we need to deploy it and get feedback to know the value
14:51 < jrandom> cervantes: client application developers can absolutely bundle SWT with their app
14:51 < jrandom> (or say "get SWT")
14:51 < hypercubus> i suspect we'll get requests for expanded systray options
14:52 < jrandom> and if a client app dev gets something we want to bundle with the router, we'll deploy swt with the bundle
14:52 < jrandom> (etc)
14:52 < deer> <oOo> Too late to split the console/status monitor/whatever from the really-routing-stuff ?
14:52 < jrandom> really routing stuff?
14:52 < jrandom> the router console is a fully seperate client application
14:53 < jrandom> (apps/routnerconsole/)
14:53 < deer> <oOo> The stuff needed to have the bytes anonymously flowing
14:53 < jrandom> i do think down the line we will want to have a minimal-router install as well
14:53 < jrandom> (with nothing in clients.config, etc)
14:53 < jrandom> but we dont have the developer hours to maintain multiple sets of things
14:55 < jrandom> ok, anyone else have anything they want to bring up?
14:57 < jrandom> if not
14:57 * jrandom winds up
14:57 < deer> <oOo> 0.3.5, when ? ;)
14:57 < jrandom> it'll be out hopefully this week
14:57 < jrandom> (in the next day or two if all goes well)
14:57 < deer> <oOo> Ok ^^
14:57 * jrandom stops winding up
14:57 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/105.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, August 31, 2004
================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,476 +1,470 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 106{% endblock %}
{% block content %}<h3>I2P dev meeting, September 7, 2004</h3>
<div class="irclog">
14:09 < jrandom> 0) hi</p>
14:09 < jrandom> 1) 0.4</p>
14:09 < jrandom> 2) Capacity and overload</p>
14:09 * cervantes pulls up a bar stool</p>
14:09 < jrandom> 3) Website updates</p>
14:09 < jrandom> 4) I2PTunnel web interface</p>
14:09 < jrandom> 5) Roadmap and todo</p>
14:09 < jrandom> 6) ???</p>
14:09 < jrandom> 0) hi</p>
14:09 < nicktastic> ugha, Ah, -x isn't even necessary to see what's being resolved - silly me</p>
14:09 < cervantes> hullo</p>
14:09 * nicktastic resumes lurking</p>
14:10 < jrandom> 'lo all, sorry for the delay in the notes - http://dev.i2p.net/pipermail/i2p/2004-September/000437.html</p>
14:10 * jrandom just had to reply to Derick's E post :)</p>
14:10 < deer> &lt;ugha2p&gt; nicktastic: Right. The meeting already started though. :)</p>
14:10 < luckypunk> h wow, i didn't miss it.</p>
14:10 < jrandom> !hi5</p>
14:10 < jrandom> ok, swinging on in to 1) 0.4</p>
14:11 < jrandom> we finally got it out the door, and it doesn't seem to have bitten us too bad</p>
14:12 < jrandom> the network is larger than its ever been (I counted 60 TCP connections a few hours back), eepsites are retrievable, and irc is often usable</p>
14:12 < dm> hey!! meeting?</p>
14:12 < jrandom> hypercubus has done some great work with the new install, systray, and service manager, which I know has helped us out a bunch</p>
14:13 < modulus> yay</p>
14:13 < hypercubus> still a ways to go though</p>
14:13 < hypercubus> but i think we're getting somewhere now</p>
14:13 < jrandom> agreed, ever onwards :)</p>
14:14 < jrandom> this release also has the widespread deployment of oOo's ?i2paddresshelper </p>
14:14 < jrandom> we covered that a bit the other week [http://dev.i2p.net/pipermail/i2p/2004-August/000419.html item 2.3], but now its probably a good idea for people to consider using it for their links</p>
14:15 < hypercubus> does it work with name-based vhosts?</p>
14:15 < jrandom> the i2ptunnel httpclient still correctly sends Host: $base64dest</p>
14:17 < jrandom> on that note, there has been some more talk about using the bundled webserver to serve some eepsites, and i think if someone has some time to figure out the configuration necessary, that'd be pretty kickass (saving us from the vhost / apache config problems)</p>
14:18 < jrandom> ok, anyone else have anything to bring up about 0.4?</p>
14:18 < deer> &lt;baffled&gt; is this web server in cvs?</p>
14:18 < demonic_1> ?</p>
14:18 < hypercubus> the web server is in 0.4</p>
14:18 < demonic_1> what i miss</p>
14:18 < deer> &lt;ugha2p&gt; baffled: It's going to be.</p>
14:18 < hypercubus> hence CVS</p>
14:18 < jrandom> baffled: yeah, its all in cvs (lib/org.mortbay.*)</p>
14:18 < cervantes> btw I experimented with window's url protocol handers... it's very easy to set the registry up so "i2p://base64" will launch in a browser with a http://site.i2p?i2paddresshelper=base64 ...</p>
14:19 < deer> &lt;ugha2p&gt; Oh, it already is.</p>
14:19 < dm> this is all very very cool</p>
14:19 < hypercubus> i already wrote registry interfacing code</p>
14:19 < hypercubus> we can use that to set up an .i2p association</p>
14:19 < fvw> cervantes: i2p:// wouldn't be quite right I think. After all, it's http over i2p; just as you could have irc:// over i2p.</p>
14:19 < cervantes> you can also specify security and proxy settings on a per protocol basis</p>
14:19 < jrandom> cervantes: does firefox/etc honor those?</p>
14:19 < cervantes> yup</p>
14:20 -!- shardy_ is now known as shardy</p>
14:20 < jrandom> woah, hi shardy_ </p>
14:20 < shardy> hey jrandom, long time no talk</p>
14:20 < cervantes> although admittedly I need more testing...</p>
14:20 < nicktastic> konqueror should, too</p>
14:20 < cervantes> I was just playing in a spare moment ;-)</p>
14:20 < deer> &lt;ugha2p&gt; Opera doesn't.</p>
14:20 < cervantes> although I doubt firefox takes any notice of windows proxy and security settings</p>
14:20 < hypercubus> you can set it in opera's ini file</p>
14:21 < hypercubus> i did that to opera so ed2k:// would work</p>
14:21 < deer> &lt;ugha2p&gt; hypercubus: Ah, cool.</p>
14:21 < fvw> only up to a point. You can't turn URL handlers into http:// handlers handled by opera itsself alas.</p>
14:21 < hypercubus> though they don't document it very well</p>
14:21 < deer> &lt;duck&gt; really, what benefit does i2p:// give?</p>
14:22 < fvw> hypercube: You're handing it off to a helper app I suppose? I did much the same, but I couldn't find a way to make opera display a "download started" page.</p>
14:22 < hypercubus> yes, it gets handed to eMule</p>
14:22 < dm> yes, who wants to pee in public anyway?</p>
14:22 < hypercubus> we could hand i2p:// to the eeproxy</p>
14:22 < hypercubus> then you web guys can figure out the rest from there ;-)</p>
14:22 < Sciatica> is https not http over, uh, "s"?</p>
14:23 < jrandom> but, as i think duck is getting at, we'll already be tied in to the eepproxy anyway?</p>
14:23 < deer> &lt;ugha2p&gt; Sciatica: It's HTTP over SSL, yes. :)</p>
14:23 < jrandom> Sciatica: http over i2p (well, anything over i2p) is secure and authenticated. what happens after it reaches the other side is outside i2p's scope</p>
14:23 < deer> &lt;ugha2p&gt; But that's an established convention.</p>
14:24 < Sciatica> yes, I knew that. I'm just saying that the argument against i2p:// isn't as clear as "isn't it juts http _over_ i2p?"</p>
14:24 < dm> htt2p</p>
14:24 < hypercubus> i don't know if i2p:// is necessary, but i do believe it's possbile to get the major browsers at least to work with it</p>
14:24 < deer> &lt;ugha2p&gt; jrandom: I think he just referred to the 'https://' prefix.</p>
14:24 < jrandom> ah, sorry.</p>
14:24 < deer> &lt;duck&gt; we need an anonymizing filter plus http://127.0.0.1:7657/www.duck.i2p/ anyway</p>
14:25 < deer> &lt;duck&gt; with those you dont need to tweak browser settings</p>
14:25 < jrandom> but yeah, I agree with fvw, this sounds like excessive overloading of the url protocol</p>
14:25 < demonic_1> not here &gt;&gt; as a lame use i feel i2p:// links would rule &lt;&lt; not here</p>
14:25 < jrandom> right duck</p>
14:25 < jrandom> hehe</p>
14:25 < cervantes> perhaps i2p:// could me made to operate as a protocol arbiter: i2p://irc/base64</p>
14:26 < fvw> ungh, that's ugly and abusing URLs in the worst possible way.</p>
14:26 < deer> &lt;ugha2p&gt; cervantes: How would that work in IRC's case?</p>
14:26 < deer> &lt;duck&gt; URIs :)</p>
14:26 < cervantes> that way you can launch different apps based on a single url standard</p>
14:26 < fvw> (not that there's anything wrong with that)</p>
14:26 < jrandom> wouldn't the more appropriate URL mod be irc://i2p/base64/#i2p ?</p>
14:27 < jrandom> but, ok, we're a bit off track..</p>
14:27 < jrandom> anything else on 0.4? :)</p>
14:28 < fvw> I don't think that URI's allow for specifying transport mechanism seperately from protocol, which is a shame really.</p>
14:28 < dm> you can use the filesystem</p>
14:28 < fvw> Yes, sort of: *applause*</p>
14:28 < dm> c:\i2p\irc #i2p</p>
14:29 < dm> ha! I confused you all</p>
14:29 < deer> * mule_iip agrees with fvw</p>
14:29 < fvw> dm: I'm going to seriously hurt you. Maybe not today, maybe not tomorrow, but soon and for the rest of your life.</p>
14:29 < jrandom> :) thanks, we do our best</p>
14:29 < fvw> &lt;/pinky and the brain&gt;</p>
14:29 < jrandom> heh</p>
14:29 < jrandom> ok, jumping on to 2) Capacity and overload</p>
14:30 < deer> &lt;DrVince&gt; Hi everyone</p>
14:30 < jrandom> i'd rather not just copy out what was posted in the notes, so review whats there :)</p>
14:30 < dm> hi</p>
14:30 < hypercubus> welcome to our meeting DrVince ;-)</p>
14:30 < deer> &lt;ugha2p&gt; Hi, DrVince.</p>
14:31 < jrandom> one thing I'd like to mention wrt 2) was something a few people have seen - severe skew in participating tunnels</p>
14:31 < jrandom> e.g. someone with DSL had 300+ tunnels the other day</p>
14:31 < dm> me</p>
14:31 < modulus> yeah</p>
14:31 < jrandom> (and when they go down, that breaks a *lot* of tunnels)</p>
14:31 < jrandom> the problem is tunnels are really lightweight - 2-20bps on average</p>
14:31 < cervantes> and my OC3 has practically nada</p>
14:31 < hypercubus> i only have 8 atm</p>
14:32 < dm> i had 270+, and I am on 150kbps</p>
14:32 < jrandom> overall, the network has ~ 20*n tunnels on average at any given time</p>
14:32 < jrandom> (where n = # nodes in the network)</p>
14:32 < jrandom> at an average of 2 hops per node, that means every node participates in an average of 40 tunnels</p>
14:33 < hypercubus> ideally ;-)</p>
14:33 < jrandom> well, thats the thing, balancing like that *isnt* ideal</p>
14:33 < jrandom> since not all nodes are as fast or have as much bandwidth</p>
14:33 < jrandom> on the ohter hand, balancing the tunnels so they all go through 2 or 3 really fast peers also sucks</p>
14:33 < jrandom> since if one of those go down, *boom*</p>
14:34 < hypercubus> right, so why is dm's inferior DSL connection so overloaded, while my much faster DSL connection has been under-utilized?</p>
14:34 < Sciatica> will this problem go away as the # of nodes in the network grows beyond 100, 200, etc.?</p>
14:34 < dm> inferior? :'(</p>
14:34 < jrandom> hypercubus: because i2p is currently nonresponsive to the bandwidth available, unless people turn on bandwidth limiting</p>
14:34 < hypercubus> dm: technically speaking ;-)</p>
14:34 < hypercubus> ok i have bandwidth limiting enabled... dm must not?</p>
14:35 < Sciatica> (at some point won't the number of nodes a server can host be greatly dwarfed compared the the number of total nodes [e.g., tunnels]?</p>
14:35 < ugha_node> Arrr!</p>
14:35 < ugha_node> '(the local message processing time exceeds 1s)' -- I don't think we should program any such constants into the router. I think all such values should be taken from the (I2P network) environment, so it would still work in case the router lands in an unexpected enviromnent.</p>
14:35 < dm> yeah, I don't, also my uplink is decent: 256kbps (downlink 150kbps)</p>
14:35 < Sciatica> bad terminiology -- I type too slow for such issues :-)</p>
14:35 < jrandom> Sciatica: it isn't a problem, is just a reality. if every node maintains 20 tunnels at any given time, with each tunnel an average of 2 hops, no matter how large the network is, it averages out</p>
14:36 < jrandom> ugha_node: agreed - the 1s thing is random #, but how can we derive the "right" value? what amount of delay is "a lot"?</p>
14:37 < jrandom> we do have some code in the RouterThrottleImpl that tracks "how much bandwidth we've agreed to allocate"</p>
14:37 < jrandom> but at the moment, it doesn't throttle based on that</p>
14:37 < dm> hmmmm I don't like these overload discussions... flashbacks of freenet.</p>
14:37 < jrandom> (bandwidth agreed to == # participating tunnels * # messages per tunnel on average * # bytes per message on average)</p>
14:37 < dm> Maybe we should use estimators?</p>
14:38 * jrandom kicks dm</p>
14:38 < hypercubus> dm: are you using bandwidth limiting in your router?</p>
14:38 < dm> hypercubus: no</p>
14:38 < hypercubus> dm: i highly recommend using it ;-)</p>
14:38 < dm> jrandom: three words... NGR</p>
14:38 < fvw> It's really up to the node that requested the tunnel, right? What kind of lag are they willing to put up with? Would it be viable to make it one of the tunnel parameters?</p>
14:39 * fvw wonders if dm is trying to scare us or if it's merely an added benefit.</p>
14:39 < jrandom> hmm, that has potential</p>
14:39 < dm> errr.. won't that just move the arbitrary threshold to the requesting router? ;)</p>
14:39 < dm> I don't want to choose, you choose!</p>
14:40 < jrandom> yes dm, but the requesting router knows what the tunnel will be used for (irc w/ low lag vs bulk w/ high lag and high throughput)</p>
14:40 < fvw> yes, but for some things 10s lag is no problem (think file transfers), whereas other stuff (irc) needs low latency.</p>
14:40 < dm> yeah, so you have the app layer decide the threshold?</p>
14:40 < jrandom> that is, however, dangerous</p>
14:40 < fvw> the only problem is using high-latency links will not increase capacity, so in the end file transfers get all the resources.</p>
14:41 < cat-a-puss> can you really trust any load claims made by the router, otherwise a malicious preson could try to get another nodes traffic to go through all their routers</p>
14:41 < jrandom> cat-a-puss: these are only used to reject requests to participate, not to solicit</p>
14:41 < ugha_node> You can't.</p>
14:41 < cat-a-puss> ok</p>
14:42 < jrandom> a malicious user can of course accept tunnels when they're totally overloaded, but we'll detect that when the tunnel fails</p>
14:42 < jrandom> (and the freeloader can reject the tunnel when they arent loaded, but, c'est la vie)</p>
14:43 < jrandom> the throttle based on local overload is pretty effective though. however, that isn't enough</p>
14:43 < dm> greedy bastard</p>
14:43 < jrandom> i've been trying to find out an ideal way to work out whether to accept it or not, and i think that there is some potential for probabalistically rejecting requests we would otherwise accept, based on how many tunnels we are already in</p>
14:44 < jrandom> the concept there is that the peer wants other people to take on some load</p>
14:44 < cat-a-puss> should we run as many virtual routers as avalable bandwidth?</p>
14:44 < jrandom> (so as to distribute the failure)</p>
14:44 < jrandom> hmm cat-a-puss?</p>
14:44 < jrandom> are you running the sim on the live net?</p>
14:45 < jrandom> in any case, no, a single router should be able to address the local capacity</p>
14:46 < deer> &lt;mule_iip&gt; problem is that bandwidth used in a tunnel may change significantly over time, right?</p>
14:46 < cervantes> which is not currently happening...at least not for me</p>
14:46 < cat-a-puss> well if it's all random how can you take advantage of an oc3 any more than some poor guy on a 56k? You ether have to advertise: problematic, or run virtual routers, ether way I think a malicious party could try to encircle a node for some sort of stistical attack</p>
14:46 < jrandom> right mule_i2p. we need to do some more monitoring of the tunnel activity</p>
14:46 < cervantes> 14 participents each have 11.5mbit ... that's a bit of a waste :)</p>
14:47 < jrandom> cat-a-puss: probabalistic != random :) </p>
14:47 < jrandom> heh cervantes </p>
14:48 < jrandom> the basic idea behind probabalistically rejecting would be to spread the load out to other peers. however, if the network really is saturated, the probability won't be a problem as people will just ask again</p>
14:48 < jrandom> the issue is that we currently have an overwhelming *excess* of capacity</p>
14:48 < Sugadude> Poor i2p, having *too* much capacity. Don't worry, I'm on it. ;)</p>
14:49 < fvw> assuming everyone is wellbehaved, you could perhaps not reject from people who come back within a short interval of being probabilisticly rejected?</p>
14:49 < deer> &lt;mule_iip&gt; so fill any tunnel with some cover traffic</p>
14:49 < jrandom> heh Sugadude :)</p>
14:49 < cervantes> that's because everyone's requests are being handled by dm's router ;-)</p>
14:49 < jrandom> fvw: we dont know who requests a tunnel</p>
14:49 < fvw> hmm, good point. *screws head back on*</p>
14:50 < jrandom> fvw: probabalistically, subsequent requests would be accepted - we'd want the 'reject' factor to stay low enough</p>
14:50 < deer> &lt;mule_iip&gt; which will increase anonymity and make load calculation easier</p>
14:51 < jrandom> true mule_iip, but it'd be nice to actually have the net operate effectively without requiring high load :)</p>
14:51 < jrandom> but that is definitely a worthwhile scenario for the sim</p>
14:51 < deer> &lt;mule_iip&gt; effectively make i2p use a constant bitrate with cover traffic. but that was for a future release, i guess :)</p>
14:52 < jrandom> we *could* use ATM-style allocation</p>
14:52 < fvw> Doesn't bandwidth usage vary too much for that to be viable?</p>
14:52 < jrandom> e.g. assume 5 messages per minute per tunnel @ 32KB each, and compare that with the bandwidth limits, and reject accordingly</p>
14:52 < cervantes> hyper has some ascii we can use to pad the messages out</p>
14:52 < hypercubus> hmmmm, i don't like that constant bitrate idea... i2p would be filtered by ISPs very quickly if that were implemented</p>
14:53 < jrandom> heh cervantes </p>
14:53 < deer> &lt;kaji&gt; yes</p>
14:53 * hypercubus doesn't know what cervantes is talking about</p>
14:53 * hypercubus hides his floppy</p>
14:53 < jrandom> fvw: padding? or allocation?</p>
14:53 < fvw> allocation</p>
14:53 < cervantes> ah ya plausable deniability huh</p>
14:54 < jrandom> hmm fvw. perhaps, but I think we can monitor them statistically and compensate</p>
14:54 < deer> &lt;kaji&gt; constant bitrate sounds like Waste</p>
14:54 < jrandom> for instance, http://localhost:7657/oldstats.jsp#tunnel.bytesAllocatedAtAccept</p>
14:54 < hypercubus> hence its name ;-)</p>
14:55 < jrandom> that stat monitors how much bandwidth we have agreed to pass on for other people's tunnels</p>
14:55 < jrandom> (using the last 10 minutes as a guideline)</p>
14:56 < jrandom> so my peer with 85 tunnels says it will transfer 3,676,945.65 bytes over the next 10 minutes for all of those tunnels, combined</p>
14:56 < deer> &lt;mule_iip&gt; kaji: it is waste, and we probably should use it only for the more severe threat models. but would be nice for low latency like irc.</p>
14:56 < jrandom> thats 72bps each, but I'm not sure how skewed it is (probably *very*)</p>
14:57 < jrandom> however, if all of those tunnels started using lots and lots of bandwidth, the total value would shoot up, and we could throttle it</p>
14:57 * fvw nods. </p>
14:57 * fvw notes this is in fact a wildly interesting problem, theoreticly speaking.</p>
14:57 < fvw> (but maybe that's just me being weird)</p>
14:57 < jrandom> agreed</p>
14:58 < jrandom> (to both ;)</p>
14:58 < jrandom> but yeah, we dont have the Right Answer yet. but its something to be worked on</p>
14:59 < jrandom> ok, unless there's anything else on that, moving on to 3) Website updates</p>
14:59 < fvw> We could ofcourse go totally lossy and just drop datagrams when we're overloaded, and make people run something like tcp over that.</p>
14:59 < jrandom> we tried that, and lots and lots and lots of tunnels failed</p>
15:00 < jrandom> (since if a tunnel drops 1 message, we mark it as failed)</p>
15:00 < fvw> yes, you shouldn't do that if you take that approach.</p>
15:00 < jrandom> ((and when we tried not being such fascists, we didn't notice when a tunnel *really* fails))</p>
15:00 * fvw nods and strokes his beard. Good point. (mental note to self: grow beard to stroke in situations like this)</p>
15:01 < jrandom> heh</p>
15:01 < jrandom> ok, anyway, as you've all seen, our new installer and new web interface is completely different from the old way of doing things</p>
15:01 * hypercubus gives fvw his beard</p>
15:02 < jrandom> while that is Good, since the old way was Painful, all our old docs are now wildly incorrect</p>
15:02 < fvw> could we stick on 2) a few minutes longer? I still have a few bad ideas I want you to shoot down.</p>
15:02 < jrandom> sure</p>
15:02 < dm> I can't use the internet... </p>
15:02 < dm> Bandwidth in/out</p>
15:02 < dm> 1m: 13.32/11.98KBps</p>
15:02 < dm> 5m: 10.74/9.46KBps</p>
15:02 < jrandom> how many tunnels dm?</p>
15:02 < hypercubus> dm: that's why i suggested you turn on i2p's bandwidth limiting ;-)</p>
15:02 < dm> only 166</p>
15:02 < jrandom> yeah, throttle it down to 6KBps</p>
15:02 < jrandom> lol</p>
15:03 < dm> (participating)</p>
15:03 < jrandom> (or maybe 8KBps if you're nice)</p>
15:03 < dm> I'll leave it as is, I just need to view this one page</p>
15:03 < jrandom> btw, the 13.32 vs 11.98 lets us know you're downloading approximately 1KBps locally</p>
15:03 < jrandom> (through i2p)</p>
15:03 < fvw> What happens if we just time-out tunnels at a reasonably large idle-time? Say 30 mins or something. The next protocol up would have to do keepalives, but wouldn't that solve the not-detecting-dead-tunnels thing?</p>
15:03 < hypercubus> he's downloading far more than that actually</p>
15:04 < jrandom> ((though that 1KBps might be small enough to be netDb))</p>
15:04 < dm> hypercubus: our transfer is stalling badly, actually.</p>
15:04 < jrandom> fvw: tunnels expire after 10 minutes</p>
15:04 < deer> &lt;kaji&gt; hold it, is bandwidth working now? if so what sould i turn it to?</p>
15:04 < dm> dissapointed in the getright/i2p combo</p>
15:04 < jrandom> they're not long lived fvw, unlike TOR</p>
15:04 < fvw> and that had most tunnels failing, even with keepalives?</p>
15:04 < hypercubus> dm: periodically yes... i think the solution would be to limit your upstream to about 8KB/s</p>
15:04 < jrandom> kaji: http://localhost:7657/</p>
15:05 < hypercubus> since it seems you're saturated</p>
15:05 < jrandom> er, /config.jsp</p>
15:05 < fvw> ok, but you don't want them dissapearing in flurries of packet loss.</p>
15:05 < jrandom> every minute (on average) each peer tests each tunnel to make sure its alive (so that other people can send us data - without tunnels, we're fucked)</p>
15:06 < fvw> Ok. I need to read more of how i2p currently works. On to 3) as far as I'm concerned.</p>
15:06 < deer> &lt;kaji&gt; right now its set on the default -1 but I dont know what a 1.5/750@1.2ghz connections translates to from maximum tunnel partisipation</p>
15:07 < deer> &lt;kaji&gt; i seem to be participation in 166</p>
15:07 < jrandom> kaji: your router will never get so many tunnels that it'll be CPU congested ;)</p>
15:07 < deer> &lt;mule_iip&gt; off-topic: don't you need a tunnel to be fucked :)</p>
15:07 < deer> &lt;kaji&gt; *ing</p>
15:07 < jrandom> heh</p>
15:07 * fvw votes "nay"</p>
15:08 < deer> &lt;kaji&gt; jrandom, i just finnished reading the letter about tunnels without bandwidth, i just didnt know what to set the limmit to</p>
15:08 < jrandom> ok, i agree, lots more to be done to figure this stuff out</p>
15:08 < jrandom> ok cool kaji, just enable your bandwidth limiter to something like 8KBps</p>
15:08 < jrandom> (or 12 if you're nice :)</p>
15:09 < deer> &lt;kaji&gt; &lt;/oftopic&gt;</p>
15:09 < jrandom> ok, on to 3) website updates</p>
15:09 < deer> &lt;kaji&gt; inbound and outbound?</p>
15:09 < jrandom> yes kaji</p>
15:09 < jrandom> ok, as I said, we need help with the docs</p>
15:09 < jrandom> (heeeeeeeeelp!)</p>
15:09 < hypercubus> i move we fill the long-vacant team positions of Webmaster and Web Editor</p>
15:10 * jrandom seconds that motion</p>
15:10 < jrandom> (now all we need is someone to volunteer ;)</p>
15:10 < hypercubus> i know cervantes is a busy guy</p>
15:10 < jrandom> its more up to the invidual to volunteer /themselves/ hyper ;)</p>
15:10 < hypercubus> i nominate Curiosity for Webmaster or Web Editor, or both if she's up for it ;-)</p>
15:11 < deer> &lt;ugha2p&gt; Uhh.</p>
15:11 < dm> Man, even my CPU is starting to max out because of I2P...</p>
15:11 < dm> You love, you REALLY love me :'(</p>
15:11 < dm> oops, :')</p>
15:12 * cervantes feels someone pushing him into the bull ring</p>
15:12 < jrandom> i think we can use all the help we can get, and if she is up for helping, we'd love it</p>
15:13 < hypercubus> i've seen her web designs and can vouch for her work</p>
15:13 < hypercubus> and she expressed interest, i don't know what she finally decided however</p>
15:13 < jrandom> ok great</p>
15:13 < dm> she?</p>
15:13 < cervantes> I'm sure she can devote far more care and attention to it than I ever could</p>
15:14 < dm> that word must not be used in our world</p>
15:14 < fvw> never mind that, he said 'care and attention'.</p>
15:15 * jrandom groans</p>
15:15 < fvw> present company excluded ofcourse.</p>
15:15 < jrandom> ok, in any case, we'll need some people to help out on the docs - generating new walk throughs, intro docs, etc</p>
15:16 < jrandom> we'll chat with Curiosity about what we can get her to hack on :)</p>
15:16 < hypercubus> i can take on the installation related stuff</p>
15:16 < hypercubus> s/on/of/</p>
15:16 < hypercubus> i know how everyone loves to read these baroque howto's that i write ;-)</p>
15:16 < jrandom> :)</p>
15:17 < jrandom> an install guide / walkthrough would KickAss</p>
15:17 < fvw> that's not how you spell 'broke'.</p>
15:17 < jrandom> heh</p>
15:17 * hypercubus snickers, then steals fvw's wallet</p>
15:17 < hypercubus> that's how you spell "broke" ;-)</p>
15:17 < deer> &lt;kaji&gt; hyper what system are you on? i'll take a crack on the winxp version but im not very reliable, i may see something shiny and quit</p>
15:17 < deer> * Curiosity is away for a bit...</p>
15:18 < hypercubus> kaji: ?</p>
15:18 < deer> &lt;kaji&gt; hyper, i was asking what OS you are using</p>
15:18 < hypercubus> OSes</p>
15:18 < deer> &lt;kaji&gt; OSESES</p>
15:19 < hypercubus> i have vmware, so i can run all the windowses and freebsd and such</p>
15:19 < hypercubus> also have pearpc, so i can run OS X</p>
15:20 < jrandom> ok, if there's nothing else on the web side</p>
15:20 < jrandom> moving on to * 4) I2PTunnel web interface</p>
15:21 * jrandom declares the i2ptunnel web interface shitty. functional. but shitty.</p>
15:21 < deer> &lt;DrVince&gt; I could dig in for french translation if interest may be</p>
15:21 < jrandom> duck had a few ideas for improving it, but he had to jet, so let me paste a few lines</p>
15:21 < hypercubus> again, we need more web devs ;-)</p>
15:21 < jrandom> oh, translating web pages to french would rule</p>
15:22 < jrandom> s/french/french and other langs/</p>
15:22 < jrandom> here are some duck-isms:</p>
15:22 < jrandom> &lt;duck&gt; reduce data load on general page; use tables/div to order stuff</p>
15:22 < jrandom> &lt;duck&gt; provide a edit/detailed page with info most dont care about, tunnels, dest hash, full key</p>
15:22 < jrandom> &lt;duck&gt; feedback after clicking buttons, 'item saved' etc. give dest as output when new one created</p>
15:22 < jrandom> &lt;duck&gt; (hide under edit/details otherwise)</p>
15:22 < jrandom> &lt;duck&gt; tag the top messages as being 'log'; sometimes confusing</p>
15:22 < jrandom> &lt;duck&gt; make clear that 'confirm' is only needed for remove, not save</p>
15:22 * jrandom agrees with what he says</p>
15:23 < jrandom> there have been a slew of bugfixes behind the scenes in the /i2ptunnel/ web interface since 0.4 too, so the functional kinks should be cleaned up</p>
15:24 < jrandom> the code implementing those pages are pretty ugly though</p>
15:24 < jrandom> probably the best approach would be to write up the screens in plain html / css / images / etc, then give it to one of the java devs to integrate</p>
15:25 < hypercubus> whatever happened to the days when there was an overabundance of web devs? ;-)</p>
15:25 < jrandom> they're all working at mcdonalds</p>
15:25 < hypercubus> ah right</p>
15:25 < deer> * Curiosity is back :)</p>
15:25 < jrandom> anyway, if anyone is interested in helping out, or has further suggestions, please get in touch</p>
15:25 < jrandom> wb Curiosity</p>
15:26 < deer> &lt;Curiosity&gt; should i bring up the idea i told oyu about jrandom?</p>
15:26 < cat-a-puss> I know someone who might be able to help with the web stuff</p>
15:26 < jrandom> ah, the live cd?</p>
15:27 < jrandom> great cat-a-puss, we need all the help we can get</p>
15:27 < deer> &lt;Curiosity&gt; teah :)</p>
15:27 < deer> &lt;Curiosity&gt; err yeah</p>
15:27 < jrandom> Curiosity: yeah, please bring that up when we get to item 6) ???</p>
15:28 < deer> &lt;Curiosity&gt; okay :)</p>
15:28 < cat-a-puss> ok, I'll get them on the list, and give them jrandom's e-mail (curiosity I don't know your email)</p>
15:28 < jrandom> ok, does anyone have anything else to mention regarding the I2PTunnel web interface?</p>
15:28 < jrandom> r0x0r cat-a-puss</p>
15:29 < deer> &lt;Curiosity&gt; also, i don't mind helping wiht the web editing, etc. also :)</p>
15:29 < jrandom> ok, if there's nothing else, 5) Roadmap and todo</p>
15:30 < jrandom> awesome Curiosity, thanks! we can chat a bit after the meeting about taking over the world^W^W^W^Wweb stuff</p>
15:30 < deer> &lt;Curiosity&gt; okies :)</p>
15:30 < jrandom> as y'all probably saw, there's a new big scary page on the website (http://www.i2p.net/todo)</p>
15:31 < jrandom> that covers the big scary issues we have ahead of us (and doesnt even touch on all the client apps we need, etc)</p>
15:31 < jrandom> as you can see, we've got a shitload to do, but the good news is, we dont have to have it all done right away. </p>
15:32 < jrandom> in fact, those things are really just the bullet items from the roadmap page (with a heap of text introducing each)</p>
15:33 < jrandom> while i know thats a lot to sort through, what would be great is if people could let me know if they come across something that we will need to deal with that isn't on that page</p>
15:34 < jrandom> that isn't necessary today or this week even, just a general "hey, let us know"</p>
15:35 < jrandom> with mule's suggestion (http://www.i2p.net/todo#nat) i've been doing a lot of soul searching, and the roadmap will likely be moved around a bit</p>
15:35 < jrandom> but we'll see.</p>
15:36 < jrandom> if you have any strong feelings on certain issues ("omg we *cannot* function without X, Y, and Z!"), please let me know or post onto the list</p>
15:36 < jrandom> while i'm no champion of democracy, i am open to reason :)</p>
15:37 < jrandom> ok, thats all i've got to say about that.. anyone have anything to throw out there?</p>
15:37 < deer> &lt;Curiosity&gt; benevolent dictatorship :)</p>
15:37 -!- Sonium_ is now known as Sonium</p>
15:37 < jrandom> bah, i'm no dictator - i dont control what other people code :)</p>
15:37 < cervantes> tranquil hegemony</p>
15:37 < cat-a-puss> I've aquired two more developers</p>
15:37 < jrandom> w00t!</p>
15:38 < cat-a-puss> and have grand plans for a distributed search engine</p>
15:38 < jrandom> oh, kickass</p>
15:38 < jrandom> would that be something http://files.i2p/ could tie into?</p>
15:38 < jrandom> or, well, let me just say, oh, kickass :)</p>
15:38 < cat-a-puss> er: I can't get there (hostile enviroment)</p>
15:39 < jrandom> ah 'k</p>
15:39 < cat-a-puss> anyway, some CVS space would be nice, once we get there</p>
15:40 < jrandom> certainly, space on cvs.i2p is available</p>
15:40 < jrandom> either within the i2p/apps/ directory or your own module, if preferred</p>
15:40 < jrandom> (cvs.i2p == cvs.i2p.net)</p>
15:40 < cat-a-puss> I should probably talk to the people working on the dht huh?</p>
15:41 < cat-a-puss> what is the status of that thusfar</p>
15:41 < jrandom> :)</p>
15:41 < jrandom> i haven't heard any status updates from aum in the last few days, but i'm sure he's churning away</p>
15:42 < jrandom> last update was in http://dev.i2p.net/pipermail/i2p/2004-August/000425.html</p>
15:43 < jrandom> ok, i guess that moves us on to * 6) ???</p>
15:44 < jrandom> Curiosity was bouncing around the idea of a 'live cd' idea with i2p</p>
15:44 < jrandom> which i think is pretty cool, and something we will want</p>
15:44 < deer> &lt;Curiosity&gt; kewl :)</p>
15:44 < jrandom> though we aren't really stable enough for that yet, with a release every 2 weeks or so</p>
15:44 < hypercubus> agreed... it could even be integrated into a Knoppix ISO</p>
15:45 < deer> &lt;Curiosity&gt; ?</p>
15:45 < hypercubus> Knoppix, a livecd distro of linux</p>
15:45 < hypercubus> very user friendly</p>
15:45 < deer> &lt;Curiosity&gt; k</p>
15:45 < jrandom> though once we have the Really Simple Update functionality that is a one click download from http://dev.i2p/i2p/i2pupdate.tar.bz2, it might not be too bad</p>
15:46 < jrandom> Curiosity: do you have anything else you want to discuss about that?</p>
15:46 < fvw> ...and as soon as it becomes widely used, anyone controlling dev.i2p can compromise the network.</p>
15:47 < jrandom> as long as people use that Really Simple Update functionality</p>
15:47 * fvw nods.</p>
15:47 < deer> &lt;Curiosity&gt; i just wanted a way for people to run it w/o having to download a bunch of stuff onto their computer</p>
15:47 < jrandom> (and if dev.i2p is compromised, we put up a new hosts.txt entry for dev.i2p)</p>
15:48 < hypercubus> a knoppix i2p livecd would be prime for cybercafe use</p>
15:48 < deer> &lt;mule_iip&gt; jarndom: won't a real i2p user grab the source, study the diff against the latest peer reviewed version and build from source :)</p>
15:48 < fvw> yes but people will just hit 'update'; They won't listen to discussions about whether the new version might have vulnerabilities...</p>
15:48 < demonic_1> is there anyway to not need hosts file. u know like a dns server?</p>
15:48 < deer> &lt;Curiosity&gt; yeah... riiiight mule_iip. lol</p>
15:49 < fvw> but anyway, I'll be very happy when we get to the stage where this becomes a problem.</p>
15:49 < fvw> demonic_l: It's possible, but there'd still be a central authority.</p>
15:49 < hypercubus> demonic_1: there are currently a couple of proposals for such functionality, but global names have been ruled out</p>
15:49 < jrandom> demonic_1: yes, see the mailing list (recent discussions on http://dev.i2p.net/pipermail/i2p/2004-September/000432.html )</p>
15:49 < jrandom> (and my take @ http://dev.i2p.net/pipermail/i2p/2004-September/000435.html :)</p>
15:50 < hypercubus> *globally unique names</p>
15:50 < demonic_1> k </p>
15:51 < jrandom> ok, anyone have anything else they want to bring up?</p>
15:52 < deer> &lt;Curiosity&gt; I would also like ot suggest putting service only items into a service folder... i was trying to uninstall i2p (one time of many) and was hitting the wrong uninstall thingie</p>
15:52 < hypercubus> Curiosity: that's being done</p>
15:52 < jrandom> w3rd</p>
15:52 < hypercubus> the installer will install shortcuts for i2p to the Start menu in Windows</p>
15:52 < hypercubus> and optionally on your desktop</p>
15:52 < deer> &lt;Curiosity&gt; okies :)</p>
15:52 < hypercubus> among them will be "uninstall"</p>
15:53 < deer> &lt;Curiosity&gt; i was talking about when i go into program files/i2p </p>
15:53 < hypercubus> you don't need to from there</p>
15:54 < hypercubus> Windows users don't ever go into the program folders ;-)</p>
15:54 < demonic_1> :/</p>
15:54 < deer> &lt;Curiosity&gt; i do! :P</p>
15:54 < jrandom> we could perhaps add a bin/ dir with all the scripts</p>
15:54 < jrandom> er, nm</p>
15:54 < hypercubus> then you would have seen the folder called "Uninstall" ;-)</p>
15:54 * jrandom remembers the paths</p>
15:54 < hypercubus> which is where the uninstaller is located</p>
15:54 < jrandom> we can move the service scripts into lib though</p>
15:54 < hypercubus> i'm not sure we can</p>
15:55 < cervantes> you could go the 'doze method and have the "uninstall" option in the installer ;-)</p>
15:55 < hypercubus> wrapper is very particular about where you put those</p>
15:55 < jrandom> at the very least they can "cd .." first</p>
15:55 < hypercubus> i'll look into changing their location</p>
15:55 < hypercubus> but it might not be doable</p>
15:55 < jrandom> cool, thanks. it'd be nice to remove some of the clutter in the install dir</p>
15:55 < hypercubus> agreed</p>
15:55 < jrandom> (most of which is my fautlt with all those .config files :)</p>
15:56 < hypercubus> we could have a config dir i guess</p>
15:56 < cervantes> ./conf ?</p>
15:56 < jrandom> c'mon, we're geeks. etc/ :)</p>
15:56 < jrandom> that would be Really Easy though</p>
15:56 < jrandom> (just a few -D parameters on the CLI)</p>
15:56 < hypercubus> then we'll have to field questions from Windows users that "etc" isn't obvious enough ;-)</p>
15:56 < jrandom> people shouldnt need to touch their config</p>
15:57 < jrandom> thats what the web is for</p>
15:57 < cervantes> I've always gone for the blatant: ./configuration/</p>
15:57 < hypercubus> right, but Windows users shouldn't need to launch the uninstaller from their program directory either heheh</p>
15:57 < jrandom> ./thesefilestellstufftodothings/</p>
15:57 < cervantes> ./scripts/</p>
15:57 < cervantes> ./asciipr0n</p>
15:57 < jrandom> ok, but yeah, some work we can flesh out</p>
15:57 < deer> &lt;Curiosity&gt; lol</p>
15:58 < jrandom> anyone have anything else to bring up for the meeting?</p>
15:58 < jrandom> if not</p>
15:58 * jrandom winds up</p>
15:59 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
14:09 < jrandom> 0) hi
14:09 < jrandom> 1) 0.4
14:09 < jrandom> 2) Capacity and overload
14:09 * cervantes pulls up a bar stool
14:09 < jrandom> 3) Website updates
14:09 < jrandom> 4) I2PTunnel web interface
14:09 < jrandom> 5) Roadmap and todo
14:09 < jrandom> 6) ???
14:09 < jrandom> 0) hi
14:09 < nicktastic> ugha, Ah, -x isn't even necessary to see what's being resolved - silly me
14:09 < cervantes> hullo
14:09 * nicktastic resumes lurking
14:10 < jrandom> 'lo all, sorry for the delay in the notes - http://dev.i2p.net/pipermail/i2p/2004-September/000437.html
14:10 * jrandom just had to reply to Derick's E post :)
14:10 < deer> <ugha2p> nicktastic: Right. The meeting already started though. :)
14:10 < luckypunk> h wow, i didn't miss it.
14:10 < jrandom> !hi5
14:10 < jrandom> ok, swinging on in to 1) 0.4
14:11 < jrandom> we finally got it out the door, and it doesn't seem to have bitten us too bad
14:12 < jrandom> the network is larger than its ever been (I counted 60 TCP connections a few hours back), eepsites are retrievable, and irc is often usable
14:12 < dm> hey!! meeting?
14:12 < jrandom> hypercubus has done some great work with the new install, systray, and service manager, which I know has helped us out a bunch
14:13 < modulus> yay
14:13 < hypercubus> still a ways to go though
14:13 < hypercubus> but i think we're getting somewhere now
14:13 < jrandom> agreed, ever onwards :)
14:14 < jrandom> this release also has the widespread deployment of oOo's ?i2paddresshelper
14:14 < jrandom> we covered that a bit the other week [http://dev.i2p.net/pipermail/i2p/2004-August/000419.html item 2.3], but now its probably a good idea for people to consider using it for their links
14:15 < hypercubus> does it work with name-based vhosts?
14:15 < jrandom> the i2ptunnel httpclient still correctly sends Host: $base64dest
14:17 < jrandom> on that note, there has been some more talk about using the bundled webserver to serve some eepsites, and i think if someone has some time to figure out the configuration necessary, that'd be pretty kickass (saving us from the vhost / apache config problems)
14:18 < jrandom> ok, anyone else have anything to bring up about 0.4?
14:18 < deer> <baffled> is this web server in cvs?
14:18 < demonic_1> ?
14:18 < hypercubus> the web server is in 0.4
14:18 < demonic_1> what i miss
14:18 < deer> <ugha2p> baffled: It's going to be.
14:18 < hypercubus> hence CVS
14:18 < jrandom> baffled: yeah, its all in cvs (lib/org.mortbay.*)
14:18 < cervantes> btw I experimented with window's url protocol handers... it's very easy to set the registry up so "i2p://base64" will launch in a browser with a http://site.i2p?i2paddresshelper=base64 ...
14:19 < deer> <ugha2p> Oh, it already is.
14:19 < dm> this is all very very cool
14:19 < hypercubus> i already wrote registry interfacing code
14:19 < hypercubus> we can use that to set up an .i2p association
14:19 < fvw> cervantes: i2p:// wouldn't be quite right I think. After all, it's http over i2p; just as you could have irc:// over i2p.
14:19 < cervantes> you can also specify security and proxy settings on a per protocol basis
14:19 < jrandom> cervantes: does firefox/etc honor those?
14:19 < cervantes> yup
14:20 -!- shardy_ is now known as shardy
14:20 < jrandom> woah, hi shardy_
14:20 < shardy> hey jrandom, long time no talk
14:20 < cervantes> although admittedly I need more testing...
14:20 < nicktastic> konqueror should, too
14:20 < cervantes> I was just playing in a spare moment ;-)
14:20 < deer> <ugha2p> Opera doesn't.
14:20 < cervantes> although I doubt firefox takes any notice of windows proxy and security settings
14:20 < hypercubus> you can set it in opera's ini file
14:21 < hypercubus> i did that to opera so ed2k:// would work
14:21 < deer> <ugha2p> hypercubus: Ah, cool.
14:21 < fvw> only up to a point. You can't turn URL handlers into http:// handlers handled by opera itsself alas.
14:21 < hypercubus> though they don't document it very well
14:21 < deer> <duck> really, what benefit does i2p:// give?
14:22 < fvw> hypercube: You're handing it off to a helper app I suppose? I did much the same, but I couldn't find a way to make opera display a "download started" page.
14:22 < hypercubus> yes, it gets handed to eMule
14:22 < dm> yes, who wants to pee in public anyway?
14:22 < hypercubus> we could hand i2p:// to the eeproxy
14:22 < hypercubus> then you web guys can figure out the rest from there ;-)
14:22 < Sciatica> is https not http over, uh, "s"?
14:23 < jrandom> but, as i think duck is getting at, we'll already be tied in to the eepproxy anyway?
14:23 < deer> <ugha2p> Sciatica: It's HTTP over SSL, yes. :)
14:23 < jrandom> Sciatica: http over i2p (well, anything over i2p) is secure and authenticated. what happens after it reaches the other side is outside i2p's scope
14:23 < deer> <ugha2p> But that's an established convention.
14:24 < Sciatica> yes, I knew that. I'm just saying that the argument against i2p:// isn't as clear as "isn't it juts http _over_ i2p?"
14:24 < dm> htt2p
14:24 < hypercubus> i don't know if i2p:// is necessary, but i do believe it's possbile to get the major browsers at least to work with it
14:24 < deer> <ugha2p> jrandom: I think he just referred to the 'https://' prefix.
14:24 < jrandom> ah, sorry.
14:24 < deer> <duck> we need an anonymizing filter plus http://127.0.0.1:7657/www.duck.i2p/ anyway
14:25 < deer> <duck> with those you dont need to tweak browser settings
14:25 < jrandom> but yeah, I agree with fvw, this sounds like excessive overloading of the url protocol
14:25 < demonic_1> not here >> as a lame use i feel i2p:// links would rule << not here
14:25 < jrandom> right duck
14:25 < jrandom> hehe
14:25 < cervantes> perhaps i2p:// could me made to operate as a protocol arbiter: i2p://irc/base64
14:26 < fvw> ungh, that's ugly and abusing URLs in the worst possible way.
14:26 < deer> <ugha2p> cervantes: How would that work in IRC's case?
14:26 < deer> <duck> URIs :)
14:26 < cervantes> that way you can launch different apps based on a single url standard
14:26 < fvw> (not that there's anything wrong with that)
14:26 < jrandom> wouldn't the more appropriate URL mod be irc://i2p/base64/#i2p ?
14:27 < jrandom> but, ok, we're a bit off track..
14:27 < jrandom> anything else on 0.4? :)
14:28 < fvw> I don't think that URI's allow for specifying transport mechanism seperately from protocol, which is a shame really.
14:28 < dm> you can use the filesystem
14:28 < fvw> Yes, sort of: *applause*
14:28 < dm> c:\i2p\irc #i2p
14:29 < dm> ha! I confused you all
14:29 < deer> * mule_iip agrees with fvw
14:29 < fvw> dm: I'm going to seriously hurt you. Maybe not today, maybe not tomorrow, but soon and for the rest of your life.
14:29 < jrandom> :) thanks, we do our best
14:29 < fvw> </pinky and the brain>
14:29 < jrandom> heh
14:29 < jrandom> ok, jumping on to 2) Capacity and overload
14:30 < deer> <DrVince> Hi everyone
14:30 < jrandom> i'd rather not just copy out what was posted in the notes, so review whats there :)
14:30 < dm> hi
14:30 < hypercubus> welcome to our meeting DrVince ;-)
14:30 < deer> <ugha2p> Hi, DrVince.
14:31 < jrandom> one thing I'd like to mention wrt 2) was something a few people have seen - severe skew in participating tunnels
14:31 < jrandom> e.g. someone with DSL had 300+ tunnels the other day
14:31 < dm> me
14:31 < modulus> yeah
14:31 < jrandom> (and when they go down, that breaks a *lot* of tunnels)
14:31 < jrandom> the problem is tunnels are really lightweight - 2-20bps on average
14:31 < cervantes> and my OC3 has practically nada
14:31 < hypercubus> i only have 8 atm
14:32 < dm> i had 270+, and I am on 150kbps
14:32 < jrandom> overall, the network has ~ 20*n tunnels on average at any given time
14:32 < jrandom> (where n = # nodes in the network)
14:32 < jrandom> at an average of 2 hops per node, that means every node participates in an average of 40 tunnels
14:33 < hypercubus> ideally ;-)
14:33 < jrandom> well, thats the thing, balancing like that *isnt* ideal
14:33 < jrandom> since not all nodes are as fast or have as much bandwidth
14:33 < jrandom> on the ohter hand, balancing the tunnels so they all go through 2 or 3 really fast peers also sucks
14:33 < jrandom> since if one of those go down, *boom*
14:34 < hypercubus> right, so why is dm's inferior DSL connection so overloaded, while my much faster DSL connection has been under-utilized?
14:34 < Sciatica> will this problem go away as the # of nodes in the network grows beyond 100, 200, etc.?
14:34 < dm> inferior? :'(
14:34 < jrandom> hypercubus: because i2p is currently nonresponsive to the bandwidth available, unless people turn on bandwidth limiting
14:34 < hypercubus> dm: technically speaking ;-)
14:34 < hypercubus> ok i have bandwidth limiting enabled... dm must not?
14:35 < Sciatica> (at some point won't the number of nodes a server can host be greatly dwarfed compared the the number of total nodes [e.g., tunnels]?
14:35 < ugha_node> Arrr!
14:35 < ugha_node> '(the local message processing time exceeds 1s)' -- I don't think we should program any such constants into the router. I think all such values should be taken from the (I2P network) environment, so it would still work in case the router lands in an unexpected enviromnent.
14:35 < dm> yeah, I don't, also my uplink is decent: 256kbps (downlink 150kbps)
14:35 < Sciatica> bad terminiology -- I type too slow for such issues :-)
14:35 < jrandom> Sciatica: it isn't a problem, is just a reality. if every node maintains 20 tunnels at any given time, with each tunnel an average of 2 hops, no matter how large the network is, it averages out
14:36 < jrandom> ugha_node: agreed - the 1s thing is random #, but how can we derive the "right" value? what amount of delay is "a lot"?
14:37 < jrandom> we do have some code in the RouterThrottleImpl that tracks "how much bandwidth we've agreed to allocate"
14:37 < jrandom> but at the moment, it doesn't throttle based on that
14:37 < dm> hmmmm I don't like these overload discussions... flashbacks of freenet.
14:37 < jrandom> (bandwidth agreed to == # participating tunnels * # messages per tunnel on average * # bytes per message on average)
14:37 < dm> Maybe we should use estimators?
14:38 * jrandom kicks dm
14:38 < hypercubus> dm: are you using bandwidth limiting in your router?
14:38 < dm> hypercubus: no
14:38 < hypercubus> dm: i highly recommend using it ;-)
14:38 < dm> jrandom: three words... NGR
14:38 < fvw> It's really up to the node that requested the tunnel, right? What kind of lag are they willing to put up with? Would it be viable to make it one of the tunnel parameters?
14:39 * fvw wonders if dm is trying to scare us or if it's merely an added benefit.
14:39 < jrandom> hmm, that has potential
14:39 < dm> errr.. won't that just move the arbitrary threshold to the requesting router? ;)
14:39 < dm> I don't want to choose, you choose!
14:40 < jrandom> yes dm, but the requesting router knows what the tunnel will be used for (irc w/ low lag vs bulk w/ high lag and high throughput)
14:40 < fvw> yes, but for some things 10s lag is no problem (think file transfers), whereas other stuff (irc) needs low latency.
14:40 < dm> yeah, so you have the app layer decide the threshold?
14:40 < jrandom> that is, however, dangerous
14:40 < fvw> the only problem is using high-latency links will not increase capacity, so in the end file transfers get all the resources.
14:41 < cat-a-puss> can you really trust any load claims made by the router, otherwise a malicious preson could try to get another nodes traffic to go through all their routers
14:41 < jrandom> cat-a-puss: these are only used to reject requests to participate, not to solicit
14:41 < ugha_node> You can't.
14:41 < cat-a-puss> ok
14:42 < jrandom> a malicious user can of course accept tunnels when they're totally overloaded, but we'll detect that when the tunnel fails
14:42 < jrandom> (and the freeloader can reject the tunnel when they arent loaded, but, c'est la vie)
14:43 < jrandom> the throttle based on local overload is pretty effective though. however, that isn't enough
14:43 < dm> greedy bastard
14:43 < jrandom> i've been trying to find out an ideal way to work out whether to accept it or not, and i think that there is some potential for probabalistically rejecting requests we would otherwise accept, based on how many tunnels we are already in
14:44 < jrandom> the concept there is that the peer wants other people to take on some load
14:44 < cat-a-puss> should we run as many virtual routers as avalable bandwidth?
14:44 < jrandom> (so as to distribute the failure)
14:44 < jrandom> hmm cat-a-puss?
14:44 < jrandom> are you running the sim on the live net?
14:45 < jrandom> in any case, no, a single router should be able to address the local capacity
14:46 < deer> <mule_iip> problem is that bandwidth used in a tunnel may change significantly over time, right?
14:46 < cervantes> which is not currently happening...at least not for me
14:46 < cat-a-puss> well if it's all random how can you take advantage of an oc3 any more than some poor guy on a 56k? You ether have to advertise: problematic, or run virtual routers, ether way I think a malicious party could try to encircle a node for some sort of stistical attack
14:46 < jrandom> right mule_i2p. we need to do some more monitoring of the tunnel activity
14:46 < cervantes> 14 participents each have 11.5mbit ... that's a bit of a waste :)
14:47 < jrandom> cat-a-puss: probabalistic != random :)
14:47 < jrandom> heh cervantes
14:48 < jrandom> the basic idea behind probabalistically rejecting would be to spread the load out to other peers. however, if the network really is saturated, the probability won't be a problem as people will just ask again
14:48 < jrandom> the issue is that we currently have an overwhelming *excess* of capacity
14:48 < Sugadude> Poor i2p, having *too* much capacity. Don't worry, I'm on it. ;)
14:49 < fvw> assuming everyone is wellbehaved, you could perhaps not reject from people who come back within a short interval of being probabilisticly rejected?
14:49 < deer> <mule_iip> so fill any tunnel with some cover traffic
14:49 < jrandom> heh Sugadude :)
14:49 < cervantes> that's because everyone's requests are being handled by dm's router ;-)
14:49 < jrandom> fvw: we dont know who requests a tunnel
14:49 < fvw> hmm, good point. *screws head back on*
14:50 < jrandom> fvw: probabalistically, subsequent requests would be accepted - we'd want the 'reject' factor to stay low enough
14:50 < deer> <mule_iip> which will increase anonymity and make load calculation easier
14:51 < jrandom> true mule_iip, but it'd be nice to actually have the net operate effectively without requiring high load :)
14:51 < jrandom> but that is definitely a worthwhile scenario for the sim
14:51 < deer> <mule_iip> effectively make i2p use a constant bitrate with cover traffic. but that was for a future release, i guess :)
14:52 < jrandom> we *could* use ATM-style allocation
14:52 < fvw> Doesn't bandwidth usage vary too much for that to be viable?
14:52 < jrandom> e.g. assume 5 messages per minute per tunnel @ 32KB each, and compare that with the bandwidth limits, and reject accordingly
14:52 < cervantes> hyper has some ascii we can use to pad the messages out
14:52 < hypercubus> hmmmm, i don't like that constant bitrate idea... i2p would be filtered by ISPs very quickly if that were implemented
14:53 < jrandom> heh cervantes
14:53 < deer> <kaji> yes
14:53 * hypercubus doesn't know what cervantes is talking about
14:53 * hypercubus hides his floppy
14:53 < jrandom> fvw: padding? or allocation?
14:53 < fvw> allocation
14:53 < cervantes> ah ya plausable deniability huh
14:54 < jrandom> hmm fvw. perhaps, but I think we can monitor them statistically and compensate
14:54 < deer> <kaji> constant bitrate sounds like Waste
14:54 < jrandom> for instance, http://localhost:7657/oldstats.jsp#tunnel.bytesAllocatedAtAccept
14:54 < hypercubus> hence its name ;-)
14:55 < jrandom> that stat monitors how much bandwidth we have agreed to pass on for other people's tunnels
14:55 < jrandom> (using the last 10 minutes as a guideline)
14:56 < jrandom> so my peer with 85 tunnels says it will transfer 3,676,945.65 bytes over the next 10 minutes for all of those tunnels, combined
14:56 < deer> <mule_iip> kaji: it is waste, and we probably should use it only for the more severe threat models. but would be nice for low latency like irc.
14:56 < jrandom> thats 72bps each, but I'm not sure how skewed it is (probably *very*)
14:57 < jrandom> however, if all of those tunnels started using lots and lots of bandwidth, the total value would shoot up, and we could throttle it
14:57 * fvw nods.
14:57 * fvw notes this is in fact a wildly interesting problem, theoreticly speaking.
14:57 < fvw> (but maybe that's just me being weird)
14:57 < jrandom> agreed
14:58 < jrandom> (to both ;)
14:58 < jrandom> but yeah, we dont have the Right Answer yet. but its something to be worked on
14:59 < jrandom> ok, unless there's anything else on that, moving on to 3) Website updates
14:59 < fvw> We could ofcourse go totally lossy and just drop datagrams when we're overloaded, and make people run something like tcp over that.
14:59 < jrandom> we tried that, and lots and lots and lots of tunnels failed
15:00 < jrandom> (since if a tunnel drops 1 message, we mark it as failed)
15:00 < fvw> yes, you shouldn't do that if you take that approach.
15:00 < jrandom> ((and when we tried not being such fascists, we didn't notice when a tunnel *really* fails))
15:00 * fvw nods and strokes his beard. Good point. (mental note to self: grow beard to stroke in situations like this)
15:01 < jrandom> heh
15:01 < jrandom> ok, anyway, as you've all seen, our new installer and new web interface is completely different from the old way of doing things
15:01 * hypercubus gives fvw his beard
15:02 < jrandom> while that is Good, since the old way was Painful, all our old docs are now wildly incorrect
15:02 < fvw> could we stick on 2) a few minutes longer? I still have a few bad ideas I want you to shoot down.
15:02 < jrandom> sure
15:02 < dm> I can't use the internet...
15:02 < dm> Bandwidth in/out
15:02 < dm> 1m: 13.32/11.98KBps
15:02 < dm> 5m: 10.74/9.46KBps
15:02 < jrandom> how many tunnels dm?
15:02 < hypercubus> dm: that's why i suggested you turn on i2p's bandwidth limiting ;-)
15:02 < dm> only 166
15:02 < jrandom> yeah, throttle it down to 6KBps
15:02 < jrandom> lol
15:03 < dm> (participating)
15:03 < jrandom> (or maybe 8KBps if you're nice)
15:03 < dm> I'll leave it as is, I just need to view this one page
15:03 < jrandom> btw, the 13.32 vs 11.98 lets us know you're downloading approximately 1KBps locally
15:03 < jrandom> (through i2p)
15:03 < fvw> What happens if we just time-out tunnels at a reasonably large idle-time? Say 30 mins or something. The next protocol up would have to do keepalives, but wouldn't that solve the not-detecting-dead-tunnels thing?
15:03 < hypercubus> he's downloading far more than that actually
15:04 < jrandom> ((though that 1KBps might be small enough to be netDb))
15:04 < dm> hypercubus: our transfer is stalling badly, actually.
15:04 < jrandom> fvw: tunnels expire after 10 minutes
15:04 < deer> <kaji> hold it, is bandwidth working now? if so what sould i turn it to?
15:04 < dm> dissapointed in the getright/i2p combo
15:04 < jrandom> they're not long lived fvw, unlike TOR
15:04 < fvw> and that had most tunnels failing, even with keepalives?
15:04 < hypercubus> dm: periodically yes... i think the solution would be to limit your upstream to about 8KB/s
15:04 < jrandom> kaji: http://localhost:7657/
15:05 < hypercubus> since it seems you're saturated
15:05 < jrandom> er, /config.jsp
15:05 < fvw> ok, but you don't want them dissapearing in flurries of packet loss.
15:05 < jrandom> every minute (on average) each peer tests each tunnel to make sure its alive (so that other people can send us data - without tunnels, we're fucked)
15:06 < fvw> Ok. I need to read more of how i2p currently works. On to 3) as far as I'm concerned.
15:06 < deer> <kaji> right now its set on the default -1 but I dont know what a 1.5/750@1.2ghz connections translates to from maximum tunnel partisipation
15:07 < deer> <kaji> i seem to be participation in 166
15:07 < jrandom> kaji: your router will never get so many tunnels that it'll be CPU congested ;)
15:07 < deer> <mule_iip> off-topic: don't you need a tunnel to be fucked :)
15:07 < deer> <kaji> *ing
15:07 < jrandom> heh
15:07 * fvw votes "nay"
15:08 < deer> <kaji> jrandom, i just finnished reading the letter about tunnels without bandwidth, i just didnt know what to set the limmit to
15:08 < jrandom> ok, i agree, lots more to be done to figure this stuff out
15:08 < jrandom> ok cool kaji, just enable your bandwidth limiter to something like 8KBps
15:08 < jrandom> (or 12 if you're nice :)
15:09 < deer> <kaji> </oftopic>
15:09 < jrandom> ok, on to 3) website updates
15:09 < deer> <kaji> inbound and outbound?
15:09 < jrandom> yes kaji
15:09 < jrandom> ok, as I said, we need help with the docs
15:09 < jrandom> (heeeeeeeeelp!)
15:09 < hypercubus> i move we fill the long-vacant team positions of Webmaster and Web Editor
15:10 * jrandom seconds that motion
15:10 < jrandom> (now all we need is someone to volunteer ;)
15:10 < hypercubus> i know cervantes is a busy guy
15:10 < jrandom> its more up to the invidual to volunteer /themselves/ hyper ;)
15:10 < hypercubus> i nominate Curiosity for Webmaster or Web Editor, or both if she's up for it ;-)
15:11 < deer> <ugha2p> Uhh.
15:11 < dm> Man, even my CPU is starting to max out because of I2P...
15:11 < dm> You love, you REALLY love me :'(
15:11 < dm> oops, :')
15:12 * cervantes feels someone pushing him into the bull ring
15:12 < jrandom> i think we can use all the help we can get, and if she is up for helping, we'd love it
15:13 < hypercubus> i've seen her web designs and can vouch for her work
15:13 < hypercubus> and she expressed interest, i don't know what she finally decided however
15:13 < jrandom> ok great
15:13 < dm> she?
15:13 < cervantes> I'm sure she can devote far more care and attention to it than I ever could
15:14 < dm> that word must not be used in our world
15:14 < fvw> never mind that, he said 'care and attention'.
15:15 * jrandom groans
15:15 < fvw> present company excluded ofcourse.
15:15 < jrandom> ok, in any case, we'll need some people to help out on the docs - generating new walk throughs, intro docs, etc
15:16 < jrandom> we'll chat with Curiosity about what we can get her to hack on :)
15:16 < hypercubus> i can take on the installation related stuff
15:16 < hypercubus> s/on/of/
15:16 < hypercubus> i know how everyone loves to read these baroque howto's that i write ;-)
15:16 < jrandom> :)
15:17 < jrandom> an install guide / walkthrough would KickAss
15:17 < fvw> that's not how you spell 'broke'.
15:17 < jrandom> heh
15:17 * hypercubus snickers, then steals fvw's wallet
15:17 < hypercubus> that's how you spell "broke" ;-)
15:17 < deer> <kaji> hyper what system are you on? i'll take a crack on the winxp version but im not very reliable, i may see something shiny and quit
15:17 < deer> * Curiosity is away for a bit...
15:18 < hypercubus> kaji: ?
15:18 < deer> <kaji> hyper, i was asking what OS you are using
15:18 < hypercubus> OSes
15:18 < deer> <kaji> OSESES
15:19 < hypercubus> i have vmware, so i can run all the windowses and freebsd and such
15:19 < hypercubus> also have pearpc, so i can run OS X
15:20 < jrandom> ok, if there's nothing else on the web side
15:20 < jrandom> moving on to * 4) I2PTunnel web interface
15:21 * jrandom declares the i2ptunnel web interface shitty. functional. but shitty.
15:21 < deer> <DrVince> I could dig in for french translation if interest may be
15:21 < jrandom> duck had a few ideas for improving it, but he had to jet, so let me paste a few lines
15:21 < hypercubus> again, we need more web devs ;-)
15:21 < jrandom> oh, translating web pages to french would rule
15:22 < jrandom> s/french/french and other langs/
15:22 < jrandom> here are some duck-isms:
15:22 < jrandom> <duck> reduce data load on general page; use tables/div to order stuff
15:22 < jrandom> <duck> provide a edit/detailed page with info most dont care about, tunnels, dest hash, full key
15:22 < jrandom> <duck> feedback after clicking buttons, 'item saved' etc. give dest as output when new one created
15:22 < jrandom> <duck> (hide under edit/details otherwise)
15:22 < jrandom> <duck> tag the top messages as being 'log'; sometimes confusing
15:22 < jrandom> <duck> make clear that 'confirm' is only needed for remove, not save
15:22 * jrandom agrees with what he says
15:23 < jrandom> there have been a slew of bugfixes behind the scenes in the /i2ptunnel/ web interface since 0.4 too, so the functional kinks should be cleaned up
15:24 < jrandom> the code implementing those pages are pretty ugly though
15:24 < jrandom> probably the best approach would be to write up the screens in plain html / css / images / etc, then give it to one of the java devs to integrate
15:25 < hypercubus> whatever happened to the days when there was an overabundance of web devs? ;-)
15:25 < jrandom> they're all working at mcdonalds
15:25 < hypercubus> ah right
15:25 < deer> * Curiosity is back :)
15:25 < jrandom> anyway, if anyone is interested in helping out, or has further suggestions, please get in touch
15:25 < jrandom> wb Curiosity
15:26 < deer> <Curiosity> should i bring up the idea i told oyu about jrandom?
15:26 < cat-a-puss> I know someone who might be able to help with the web stuff
15:26 < jrandom> ah, the live cd?
15:27 < jrandom> great cat-a-puss, we need all the help we can get
15:27 < deer> <Curiosity> teah :)
15:27 < deer> <Curiosity> err yeah
15:27 < jrandom> Curiosity: yeah, please bring that up when we get to item 6) ???
15:28 < deer> <Curiosity> okay :)
15:28 < cat-a-puss> ok, I'll get them on the list, and give them jrandom's e-mail (curiosity I don't know your email)
15:28 < jrandom> ok, does anyone have anything else to mention regarding the I2PTunnel web interface?
15:28 < jrandom> r0x0r cat-a-puss
15:29 < deer> <Curiosity> also, i don't mind helping wiht the web editing, etc. also :)
15:29 < jrandom> ok, if there's nothing else, 5) Roadmap and todo
15:30 < jrandom> awesome Curiosity, thanks! we can chat a bit after the meeting about taking over the world^W^W^W^Wweb stuff
15:30 < deer> <Curiosity> okies :)
15:30 < jrandom> as y'all probably saw, there's a new big scary page on the website (http://www.i2p.net/todo)
15:31 < jrandom> that covers the big scary issues we have ahead of us (and doesnt even touch on all the client apps we need, etc)
15:31 < jrandom> as you can see, we've got a shitload to do, but the good news is, we dont have to have it all done right away.
15:32 < jrandom> in fact, those things are really just the bullet items from the roadmap page (with a heap of text introducing each)
15:33 < jrandom> while i know thats a lot to sort through, what would be great is if people could let me know if they come across something that we will need to deal with that isn't on that page
15:34 < jrandom> that isn't necessary today or this week even, just a general "hey, let us know"
15:35 < jrandom> with mule's suggestion (http://www.i2p.net/todo#nat) i've been doing a lot of soul searching, and the roadmap will likely be moved around a bit
15:35 < jrandom> but we'll see.
15:36 < jrandom> if you have any strong feelings on certain issues ("omg we *cannot* function without X, Y, and Z!"), please let me know or post onto the list
15:36 < jrandom> while i'm no champion of democracy, i am open to reason :)
15:37 < jrandom> ok, thats all i've got to say about that.. anyone have anything to throw out there?
15:37 < deer> <Curiosity> benevolent dictatorship :)
15:37 -!- Sonium_ is now known as Sonium
15:37 < jrandom> bah, i'm no dictator - i dont control what other people code :)
15:37 < cervantes> tranquil hegemony
15:37 < cat-a-puss> I've aquired two more developers
15:37 < jrandom> w00t!
15:38 < cat-a-puss> and have grand plans for a distributed search engine
15:38 < jrandom> oh, kickass
15:38 < jrandom> would that be something http://files.i2p/ could tie into?
15:38 < jrandom> or, well, let me just say, oh, kickass :)
15:38 < cat-a-puss> er: I can't get there (hostile enviroment)
15:39 < jrandom> ah 'k
15:39 < cat-a-puss> anyway, some CVS space would be nice, once we get there
15:40 < jrandom> certainly, space on cvs.i2p is available
15:40 < jrandom> either within the i2p/apps/ directory or your own module, if preferred
15:40 < jrandom> (cvs.i2p == cvs.i2p.net)
15:40 < cat-a-puss> I should probably talk to the people working on the dht huh?
15:41 < cat-a-puss> what is the status of that thusfar
15:41 < jrandom> :)
15:41 < jrandom> i haven't heard any status updates from aum in the last few days, but i'm sure he's churning away
15:42 < jrandom> last update was in http://dev.i2p.net/pipermail/i2p/2004-August/000425.html
15:43 < jrandom> ok, i guess that moves us on to * 6) ???
15:44 < jrandom> Curiosity was bouncing around the idea of a 'live cd' idea with i2p
15:44 < jrandom> which i think is pretty cool, and something we will want
15:44 < deer> <Curiosity> kewl :)
15:44 < jrandom> though we aren't really stable enough for that yet, with a release every 2 weeks or so
15:44 < hypercubus> agreed... it could even be integrated into a Knoppix ISO
15:45 < deer> <Curiosity> ?
15:45 < hypercubus> Knoppix, a livecd distro of linux
15:45 < hypercubus> very user friendly
15:45 < deer> <Curiosity> k
15:45 < jrandom> though once we have the Really Simple Update functionality that is a one click download from http://dev.i2p/i2p/i2pupdate.tar.bz2, it might not be too bad
15:46 < jrandom> Curiosity: do you have anything else you want to discuss about that?
15:46 < fvw> ...and as soon as it becomes widely used, anyone controlling dev.i2p can compromise the network.
15:47 < jrandom> as long as people use that Really Simple Update functionality
15:47 * fvw nods.
15:47 < deer> <Curiosity> i just wanted a way for people to run it w/o having to download a bunch of stuff onto their computer
15:47 < jrandom> (and if dev.i2p is compromised, we put up a new hosts.txt entry for dev.i2p)
15:48 < hypercubus> a knoppix i2p livecd would be prime for cybercafe use
15:48 < deer> <mule_iip> jarndom: won't a real i2p user grab the source, study the diff against the latest peer reviewed version and build from source :)
15:48 < fvw> yes but people will just hit 'update'; They won't listen to discussions about whether the new version might have vulnerabilities...
15:48 < demonic_1> is there anyway to not need hosts file. u know like a dns server?
15:48 < deer> <Curiosity> yeah... riiiight mule_iip. lol
15:49 < fvw> but anyway, I'll be very happy when we get to the stage where this becomes a problem.
15:49 < fvw> demonic_l: It's possible, but there'd still be a central authority.
15:49 < hypercubus> demonic_1: there are currently a couple of proposals for such functionality, but global names have been ruled out
15:49 < jrandom> demonic_1: yes, see the mailing list (recent discussions on http://dev.i2p.net/pipermail/i2p/2004-September/000432.html )
15:49 < jrandom> (and my take @ http://dev.i2p.net/pipermail/i2p/2004-September/000435.html :)
15:50 < hypercubus> *globally unique names
15:50 < demonic_1> k
15:51 < jrandom> ok, anyone have anything else they want to bring up?
15:52 < deer> <Curiosity> I would also like ot suggest putting service only items into a service folder... i was trying to uninstall i2p (one time of many) and was hitting the wrong uninstall thingie
15:52 < hypercubus> Curiosity: that's being done
15:52 < jrandom> w3rd
15:52 < hypercubus> the installer will install shortcuts for i2p to the Start menu in Windows
15:52 < hypercubus> and optionally on your desktop
15:52 < deer> <Curiosity> okies :)
15:52 < hypercubus> among them will be "uninstall"
15:53 < deer> <Curiosity> i was talking about when i go into program files/i2p
15:53 < hypercubus> you don't need to from there
15:54 < hypercubus> Windows users don't ever go into the program folders ;-)
15:54 < demonic_1> :/
15:54 < deer> <Curiosity> i do! :P
15:54 < jrandom> we could perhaps add a bin/ dir with all the scripts
15:54 < jrandom> er, nm
15:54 < hypercubus> then you would have seen the folder called "Uninstall" ;-)
15:54 * jrandom remembers the paths
15:54 < hypercubus> which is where the uninstaller is located
15:54 < jrandom> we can move the service scripts into lib though
15:54 < hypercubus> i'm not sure we can
15:55 < cervantes> you could go the 'doze method and have the "uninstall" option in the installer ;-)
15:55 < hypercubus> wrapper is very particular about where you put those
15:55 < jrandom> at the very least they can "cd .." first
15:55 < hypercubus> i'll look into changing their location
15:55 < hypercubus> but it might not be doable
15:55 < jrandom> cool, thanks. it'd be nice to remove some of the clutter in the install dir
15:55 < hypercubus> agreed
15:55 < jrandom> (most of which is my fautlt with all those .config files :)
15:56 < hypercubus> we could have a config dir i guess
15:56 < cervantes> ./conf ?
15:56 < jrandom> c'mon, we're geeks. etc/ :)
15:56 < jrandom> that would be Really Easy though
15:56 < jrandom> (just a few -D parameters on the CLI)
15:56 < hypercubus> then we'll have to field questions from Windows users that "etc" isn't obvious enough ;-)
15:56 < jrandom> people shouldnt need to touch their config
15:57 < jrandom> thats what the web is for
15:57 < cervantes> I've always gone for the blatant: ./configuration/
15:57 < hypercubus> right, but Windows users shouldn't need to launch the uninstaller from their program directory either heheh
15:57 < jrandom> ./thesefilestellstufftodothings/
15:57 < cervantes> ./scripts/
15:57 < cervantes> ./asciipr0n
15:57 < jrandom> ok, but yeah, some work we can flesh out
15:57 < deer> <Curiosity> lol
15:58 < jrandom> anyone have anything else to bring up for the meeting?
15:58 < jrandom> if not
15:58 * jrandom winds up
15:59 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/106.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, September 7, 2004
==================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,500 +1,494 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 107{% endblock %}
{% block content %}<h3>I2P dev meeting, September 14, 2004</h3>
<div class="irclog">
14:06 < jrandom> 0) hi</p>
14:06 < jrandom> 1) 0.4.0.1</p>
14:06 < jrandom> 2) Threat model updates</p>
14:06 < jrandom> 3) Website updates</p>
14:06 < jrandom> 4) Roadmap</p>
14:06 < jrandom> 5) Client apps</p>
14:06 < jrandom> 6) ???</p>
14:06 < jrandom> 0) hi</p>
14:06 * jrandom waves</p>
14:06 < cervantes> evening</p>
14:06 < jrandom> weekly status notes posted to http://dev.i2p.net/pipermail/i2p/2004-September/000444.html</p>
14:07 < jrandom> (before the meeting this time too ;)</p>
14:07 < deer> &lt;jrand0m&gt; woah, 30 people over here</p>
14:07 -!- Irssi: #i2p: Total of 21 nicks [0 ops, 0 halfops, 0 voices, 21 normal]</p>
14:07 < jrandom> ok, anyway, lets jump right in to 1) 0.4.0.1</p>
14:08 < jrandom> the release is out and things seem to be working more or less</p>
14:09 < jrandom> i see a variety of connection times on irc, though in discussions with people, it seems there are congestion issues when e.g. downloading large files and using irc at the same time</p>
14:09 < jrandom> are many people running into that?</p>
14:10 < jrandom> i guess not</p>
14:11 < cervantes> I've been doing various bandwidth tests recently and haven't encounter problems in that area yet...although I'm not using the bandwidth limiter</p>
14:11 * nicktastic hasn't downloaded much since raiding alexandria weeks ago</p>
14:11 < dm> I remember getting disconnect more often on IRC when I was using eepsites, but that was 2 months ago</p>
14:11 < dm> disconnected</p>
14:11 < dm> not sure if it still happens</p>
14:11 < jrandom> ah, yeah, we need to harass the alexandria folks to give us more books :)</p>
14:12 < Nightblade> thanks for keeping us up to date dm</p>
14:12 < jrandom> i've had good luck w/ irc while downloading some large files from thetower, but, like cervantes, i dont have bandwidth limiting set</p>
14:13 < jrandom> (though that router's bw average was a steady 11KBps at the time, while downloading 8KBps of music)</p>
14:13 * nicktastic finds something to download</p>
14:13 * jrandom watches your irc.duck.i2p connection quickly get dropped ;)</p>
14:13 < jrandom> ok, anyway, does anyone have anything else they want to bring up wrt 0.4.0.1?</p>
14:14 < dm> Nightblade: hehe, no problem :)</p>
14:14 < dm> jrandom: good work, ever onwards</p>
14:14 < fvw> the installer is pretty? (not sure if that's new in .1?)</p>
14:14 < jrandom> gracias dm</p>
14:15 < jrandom> fvw: same as 0.4, but i agree, hyper did some great work there (as did our anonymous designer!)</p>
14:15 < fvw> also, I'm not going to commit myself as to pretty _what_ it is :)</p>
14:15 < jrandom> sonofabi...</p>
14:16 < jrandom> ok, moving on to 2) Threat model updates</p>
14:16 < cervantes> yes well done.. :) writing documentation always sucks </p>
14:17 < jrandom> yeah, it was a painful 2-3 days</p>
14:17 < jrandom> i'm not sure if any of y'all have read http://www.i2p.net/how_threatmodel but if you ever want to know wtf we're talking about when we say "anonymous", thats what we mean</p>
14:18 < jrandom> most of the categories there were just ripped from http://citeseer.ist.psu.edu/454354.html (linked to on the page)</p>
14:18 < jrandom> there's a lot more i'd like to do in the threat model, but i just dont have the time.</p>
14:18 < jrandom> i'd love to see a matrix of those threats vs cost of mounting them vs the type of user who cares about them</p>
14:19 < jrandom> (e.g. joe sixpack does't care about global active adversaries)</p>
14:19 < jrandom> so if anyone is bored... ;)</p>
14:19 < cervantes> something that occurred to me whilst reading your doc... we need a decent glossary...</p>
14:20 < fvw> doesn't he? joe sixpack likes to download mp3s...</p>
14:20 < jrandom> someone just published one iirc...</p>
14:20 < cervantes> really?</p>
14:20 < cervantes> on an eep?</p>
14:20 < jrandom> no, some research paper</p>
14:20 < jrandom> its not on freehaven yet, lemmie dig it up</p>
14:21 < jrandom> bugger, i dont seem to have my copy anymore. </p>
14:21 < jrandom> i'll try to track it down after the meeting</p>
14:22 < cervantes> does it tackle i2p specific concepts to?</p>
14:22 < jrandom> oh, no</p>
14:22 < jrandom> its just a general glossary for anonymous networks, dealing with mixes, cascades, attackers, etc</p>
14:22 < jrandom> no garlic routing or tunnels ;)</p>
14:23 < cervantes> a nice single paragraph summary of all "in" buzzwords so people can quickly see the difference between onion and garlic routing (for example) withou having to read the whole "how" document</p>
14:23 < jrandom> you realize a glossary would be larger than the how_* pages combined, right? </p>
14:23 < jrandom> but yeah, i agree, we should do that</p>
14:23 < cervantes> sure... but.. ;)</p>
14:23 * jrandom volunteers cervantes to work on it ;)</p>
14:23 * dm concurs</p>
14:23 < cervantes> hehe I don't know what half that shit means :)</p>
14:24 < jrandom> write up what you do know and ask me questions</p>
14:24 < cervantes> I'll have a crack at it</p>
14:24 < jrandom> w00t! cervantes++</p>
14:24 < cervantes> if I put it on the forum then others can contribute...</p>
14:24 < jrandom> good idea</p>
14:24 < deer> * Pseudonym cheers</p>
14:25 < cervantes> _but_ that doc you mentioned would be handy :o)</p>
14:25 < dm> tunnel: artificial underground passage</p>
14:25 < jrandom> agreed, i'll try to find it again</p>
14:25 < cervantes> I'll do a special version for you dm</p>
14:25 < dm> yay!</p>
14:26 < jrandom> ok, anything else on the threat model, or shall we move on to 3) Website updates ?</p>
14:27 < jrandom> ok, as anyone who has been to the site today has seen, Curiosity has come up with some nice usability updates</p>
14:27 < dm> I think cervantes and I are the only ones still awake.</p>
14:27 < korkakak> I think that in threat models</p>
14:28 < korkakak> you should add some mixnetwork attacks</p>
14:28 < jrandom> what sort of mix attacks?</p>
14:28 * dm loads up www.i2p.net</p>
14:28 < korkakak> like collusion attacks</p>
14:28 < jrandom> thats the thing that sucks about the taxonomies i used. they're all pretty much collusion attacks.</p>
14:29 < korkakak> With mix attacks i mean attacks that may happen in a mix network</p>
14:29 < korkakak> ah ok sorry</p>
14:29 < jrandom> (and most can be used for either probabalistic or confirmation attacks, etc)</p>
14:29 < dm> I like the increasing-in-size paragraphs. Helps drag people in. Far too technical for a front page though.</p>
14:29 < korkakak> Another 5 cents from me: Can i2p detect a collusion automatically?</p>
14:30 < jrandom> but if you have some suggestions for things we need to add, please, let me know</p>
14:30 < jrandom> oh, definitely not. we haven't imported morphmix's algorithms</p>
14:30 < korkakak> I c</p>
14:30 < korkakak> ok keep on</p>
14:30 < jrandom> though theirs wouldn't really fly with us though, since we're a free route mixnet</p>
14:31 < korkakak> Well yes and no</p>
14:31 < korkakak> but it is ok. SOrry for the interrutp</p>
14:32 < cat-a-puss> It might also be a good idea to mention up frount some of the obvious attacks that I2p is NOT vunerable to</p>
14:32 < jrandom> hmm? their algorithms are based off detecting the influence of colluding peers in the peer selection - within i2p, the local router explicitly defines the entire peer selection algorithm</p>
14:33 < korkakak> I guess that this is true due to the size of todays network</p>
14:33 < jrandom> ah, thats a good idea cat-a-puss, w/ MITM/etc. would you be interested in posting up some ideas for that?</p>
14:33 < cat-a-puss> sure</p>
14:33 < dm> MITM?</p>
14:33 < dm> Ah, man in the middle.</p>
14:33 < jrandom> muchas gracias cat-a-puss!</p>
14:34 * cervantes jots down MITM for the glossary</p>
14:34 < jrandom> korkakak: hmm. i'm not sure how that aspect is affected by the size of the net, but there may be things we can learn from morphmix's collusion detection, certainly</p>
14:34 < jrandom> (perhaps wrt the netDb responses, for instance)</p>
14:34 < korkakak> wrt = ?</p>
14:35 < dm> hehee</p>
14:35 < jrandom> sorry, with regards to</p>
14:35 < dm> I know that one!</p>
14:36 < jrandom> we would certainly benefit from more discussion on the threat model. perhaps we can start up a thread on the list or in the forum?</p>
14:36 < dm> "The result is that the number of peers relaying each end to end message is the absolute minimum necessary to meet both the sender's and the receiver's threat model."</p>
14:36 < dm> I like this way of looking at it.</p>
14:37 < dm> Although it's not true.</p>
14:37 < jrandom> hmm? </p>
14:37 < jrandom> if both sender and receiver want only plausible deniability, they can talk directly</p>
14:37 < jrandom> (etc)</p>
14:37 < dm> The absolute minimum number of peers required to meet the threat model of A and B is the number of peers required by A or B, whichever has more stringent requirements :)</p>
14:38 < jrandom> not true dm</p>
14:38 < jrandom> if they both require 2 hop tunnels to defend against colluding attackers in their tunnels, they can't both have 1 hop tunnels</p>
14:39 < dm> If A is willing to talk to someone with 10 indirections, and B is willing with 5, the minimum needed is 10, not 15!?</p>
14:39 < jrandom> no, 15. B shouldn't trust A's tunnels.</p>
14:39 < dm> Yeah, he shouldn't.</p>
14:39 < dm> But theoratically.. Anyway, stupid discussion. I like that sentence though.</p>
14:40 < jrandom> its one of the more important design decisions in i2p ;)</p>
14:40 < jrandom> anyway, back to 3) Website updates</p>
14:41 < deer> &lt;nicktastic&gt; (fyi - irc dropped while downloading two large files, but latency to the server is as it was before the downloads started, so could've been a fluke (ungraceful shutdown somewhere?))</p>
14:41 < jrandom> Curiosity and I discussed the length of the new homepage, and while we all agree that its a little long, its better than the old 1 liner</p>
14:41 < cervantes> agreed</p>
14:42 < jrandom> ah ok. perhaps even network congestion while downloading, since the eepproxy and the irc client use the same I2P destination (by default)</p>
14:42 < nicktastic> Aaah....</p>
14:42 < jrandom> (so both would be trying to use the same pair of inbound tunnels)</p>
14:42 < nicktastic> I was wondering why only one showed up</p>
14:43 < jrandom> yeah, thats the default within I2PTunnel and the ministreaming lib. perhaps if someone cares we can expose a way to configure that ;)</p>
14:43 < nicktastic> sorry to interrupt</p>
14:43 < deer> * Pseudonym cares</p>
14:43 < dm> such polite lads we have in this room</p>
14:43 < interrupt> you are forgiven</p>
14:44 < interrupt> ;)</p>
14:44 * nicktastic rolls eyes</p>
14:44 < jrandom> patches welcome Pseudonym ;) (naw, i'll see if i can find an easy way.. shouldnt be too hard)</p>
14:44 < jrandom> ok, anyway</p>
14:44 < deer> &lt;Pseudonym&gt; good, 'cause I don't know crap about how to code in java</p>
14:45 < jrandom> there may be further website updates, but if anyone has any suggestions, please post 'em to the forum or the list, or point 'em out to Curiosity on irc and we'll get things rolling</p>
14:45 < jrandom> anyone have anything they want to bring up wrt the website?</p>
14:45 < cervantes> umm bouties perhaps</p>
14:46 < cervantes> although maybe that's best saved for 5</p>
14:46 < jrandom> prolly so</p>
14:46 < jrandom> ok, moving on to 4) Roadmap</p>
14:46 < jrandom> lots of updates. see the email for info</p>
14:47 < jrandom> (or look at the pretty gantt chart ;)</p>
14:47 < dm> Was that done in MS Project?</p>
14:47 < jrandom> http://ganttproject.sourceforge.net/</p>
14:47 < cervantes> eerm gantt :)</p>
14:47 < dm> oh.. gantt is a product. My bad.</p>
14:48 < dm> Nice to see there are no dependencies in the roadmap.</p>
14:48 < jrandom> i've posted a few different revs of the roadmap over the last few days, but this one seems to be solid</p>
14:48 < cervantes> it's all dependant on jrandom ;-)</p>
14:48 * jrandom whimpers</p>
14:48 < fvw> 3.0 in febuary? Wow.</p>
14:48 < jrandom> the 2.0 and 3.0 releases are really just 1 (big) feature each</p>
14:48 < dm> Don't forget: exponential versioning</p>
14:49 < jrandom> heh</p>
14:49 < jrandom> yeah, we'll be 1183 by next july</p>
14:50 < dm> Well, it's more interesting than the abritrary +0.1 per build of most projects, so I'm not complaining.</p>
14:50 < jrandom> the 2.0 and 3.0 releases may be delayed to stay in line with other apps though. e.g. 3.0 would work great with an email app</p>
14:51 < jrandom> the release criteria for 1.0 has been the usual - functional, secure, scalable, and anonymous</p>
14:51 < jrandom> thats why i moved the udp transport in, as our current tcp transport would shit bricks if we had a few thousand peers</p>
14:51 < dm> so we should have a 0.9 - The Slashdot</p>
14:51 < dm> if it survives we can check off scalable and move to 1.0</p>
14:51 < jrandom> heh</p>
14:52 * jrandom would rather grow organically, thankyouverymuch</p>
14:52 < cervantes> we don't to tell _them_ about it</p>
14:52 < cervantes> *don't want</p>
14:52 < korkakak> btw may i say something about the global timing?</p>
14:52 < cervantes> let them all stay on the internet while we move here</p>
14:52 < jrandom> sure korkakak</p>
14:53 < korkakak> As far as i am concerned you cannot simulate a synchronus network over an asynchronous</p>
14:53 < korkakak> it is just bad design and should lead to network splits [i think] in the way it is used</p>
14:54 < korkakak> as a timestamp for UDP packets</p>
14:54 < jrandom> the timing is not synchronized for messaging, merely to help us know the freshness of data</p>
14:54 < korkakak> yes that's the point</p>
14:54 < jrandom> without knowing the freshness of the netDb entries, you're vulnerable to a whole slew of attacks</p>
14:55 < korkakak> Yes</p>
14:55 < korkakak> but imagine a growing network</p>
14:55 < korkakak> a huge network</p>
14:55 < jrandom> like the internet</p>
14:55 < dm> bigger!</p>
14:55 < fvw> two internets tied together with bits of string!</p>
14:55 < jrandom> that has a network time protocol for scaling to such sizes... ;)</p>
14:56 < korkakak> I don't think I understand your point but</p>
14:56 < dm> korkakak: what are you trying to say?</p>
14:57 < korkakak> that net splits may happend due to invalid timestamps</p>
14:58 * dm is not sure how syncing works currently</p>
14:58 < korkakak> the case is called localization effect [english translation from greek]</p>
14:58 < deer> &lt;soros&gt; i hear i2p's anonymity has been cracked</p>
14:59 < deer> &lt;soros&gt; true ?</p>
14:59 < jrandom> i believe we can address the time sync issue the same way the NTP networks do. there are a massive number of tier 2 and 3 NTP hosts, and while our current SNTP implementation is of course unsuitable for congested environments, there is no reason to believe time synchronization isn't possible</p>
14:59 < jrandom> heh soros</p>
14:59 < jrandom> soros: the thread you're referring to (someone else mentioned it to me) on devl was talking about JAP being compromised, not I2P.</p>
15:00 < dm> so all I2P nodes must stay synced at all times for it to work?</p>
15:00 < korkakak> NTP nets are synhcronus networks over synchronus networks ;-)</p>
15:00 < jrandom> but if someone has a compromise for I2P, I would certainly love to hear about it</p>
15:00 < deer> &lt;soros&gt; i have one but i'm keeping it a secret</p>
15:00 < jrandom> at various levels of abstraction korkakak, sure. my ethernet cable is synchronized too</p>
15:01 < deer> &lt;soros&gt; :)</p>
15:01 < jrandom> yes dm, synchronized to the network time</p>
15:01 < korkakak> jrandom it is nick or korki :-)</p>
15:01 < jrandom> (the point is that we dont use synchronous messaging)</p>
15:01 < jrandom> :) 'k</p>
15:01 < jrandom> (please dont be offended if i dont tell you my name ;)</p>
15:02 < korkakak> No I am not</p>
15:02 < dm> His name is Abdul</p>
15:02 < jrandom> ok where were we</p>
15:02 < nicktastic> 4)</p>
15:03 < jrandom> ok right, thanks. the roadmap</p>
15:03 < jrandom> anyone have any concerns / ideas / suggestions?</p>
15:03 < dm> so when you say some work is going to be done on the transport, do you mean reworking TCP, or moving to UDP?</p>
15:04 < jrandom> UDP is 0.4.4</p>
15:05 < dm> I thought I saw something about work on the transport layer</p>
15:05 < dm> in the near future</p>
15:05 < jrandom> yes, 0.4.1 will be a revamp of the TCP transport</p>
15:05 < dm> why revamp TCP in 0.4.1 if going UDP in 0.4.4?</p>
15:05 < dm> We'll need both?</p>
15:05 < cervantes> only to point out that your are still the only resource in the project plan... ...are we suffering from a lack of contributors or just project fragmentation?</p>
15:06 < jrandom> dm: some people cannot use UDP</p>
15:06 < dm> firewalls?</p>
15:06 < jrandom> cervantes: we certainly could parallelize many of those tasks with more contributors</p>
15:07 < jrandom> (but the roadmap does not assume more)</p>
15:07 < cervantes> so hopefully it represents the worse case scenario</p>
15:07 < jrandom> there is however other important work going on not reflected on the roadmap, such as client mods, services on top of i2p, etc</p>
15:08 < cervantes> asside from you being assassinated</p>
15:08 < dm> I wish we could afford toad</p>
15:08 < deer> &lt;Pseudonym&gt; now that 0.4 is out and pretty much working, should we announce somewhere (not necessarily /.) to try to increase the number of developers/testers/donors?</p>
15:08 < jrandom> more contributors would certainly be welcome</p>
15:08 * korkakak farewells all. REady to go to his bed. It is late at korkakak lands...</p>
15:08 < korkakak> bye gayz</p>
15:08 < cervantes> g'night</p>
15:08 < jrandom> thanks for swinging by nick, ttyl</p>
15:10 < dm> nite</p>
15:10 < jrandom> a /. would probably be premature, but it would be good to bring new folks on board through other means</p>
15:10 < dm> You're very open to Pseudonym's suggestion. I thought you were going to freak out.</p>
15:10 < jrandom> but i think through word of mouth we're growing steadily</p>
15:11 < deer> &lt;Pseudonym&gt; and if we do want to announce, where should we do it?</p>
15:11 < jrandom> i dont think we should have any announcements yet, not till 1.0</p>
15:11 < deer> &lt;Pseudonym&gt; seems like we could use an influx of cash/talent</p>
15:11 < jrandom> but if you hear someone talking about how they wish there were some way to help do stuff anonymously, point 'em at i2p ;)</p>
15:12 < deer> * DrWoo suggests a whisper campaign</p>
15:12 < cervantes> we have a fair amount of unnallocated cash already...</p>
15:12 < jrandom> we're an open team, but you only have one chance to make a first impression.</p>
15:13 < cat-a-puss> I would not recomend going from no publicity to /. there needs to be an intermediate step to make sure we can handel the load</p>
15:13 < deer> &lt;Pseudonym&gt; then we should allocate it to bounties we think are important</p>
15:13 < dm> We need to hire a full-time dev or find someone REALLY REALLY bored</p>
15:13 < jrandom> agreed. i'd like to see at least 500 routers online prior</p>
15:13 < jrandom> actually, y'all are moving us right along to 5) Client apps :)</p>
15:14 < jrandom> we do have ~300 in the pot at the moment (well, almost, but thats another story)</p>
15:14 < deer> &lt;Pseudonym&gt; any suggestions on what the intermediate step could be?</p>
15:14 < jrandom> pseudonym: we can't have 1000s of nodes until 0.4.4</p>
15:15 < jrandom> (and we'd want to stress test the net out first)</p>
15:15 < fvw> Actually, we probably can on most unices. Needs adjusting the rlimits though.</p>
15:15 < jrandom> right right</p>
15:15 < jrandom> it'd be painful, anyway ;)</p>
15:16 < deer> &lt;Pseudonym&gt; right. so no /. but it seems like there should be somewhere we can get a couple hundred</p>
15:16 < jrandom> we can do larger sims though</p>
15:16 < deer> &lt;Pseudonym&gt; does anyone know someone at the EFF? maybe they have a mailing list</p>
15:17 < jrandom> yeah, i've spoken with some eff folks about some things</p>
15:17 < fvw> I think any announcement will cause it to filter through to slashdot. I agree with jrandom, a little waiting isn't bad at this time.</p>
15:18 < dm> you have to be aware that if you hit 200-300 nodes, you're most likely to get an automatic /. mention ;)</p>
15:18 < jrandom> (especially since we've been going for ~ 15 months already)</p>
15:18 < dm> critical mass/hype and all that</p>
15:18 < jrandom> well, thats also another thing that leads in to 5) Client apps</p>
15:19 < jrandom> i'm watching some stats and it seems probably 1/4th of the routers out there aren't even really doing any client activity</p>
15:19 < jrandom> which is great and wonderful that people are willing to donate their resources to act as I2P routers, but its too bad that we dont have something to suck them in :)</p>
15:19 < fvw> Yeah, I'd like to do a proper chat app (as in irc, but in a way that makes sense for i2p), but this is very much a long term thing, no time the next few months...</p>
15:20 < jrandom> we have had an influx of kickass eepsites recently though</p>
15:20 < jrandom> ah cool fvw</p>
15:20 < cervantes> many people run more than 1 router though</p>
15:20 < jrandom> a solid IM/group chat for I2P would certainly rule</p>
15:20 < nicktastic> fvw: Instant messenger with multi-user chat, perhaps?</p>
15:20 < deer> &lt;mrflibble&gt; dudes, in 0.4.0.1, how do i allow the router to listen on more than just localhost?</p>
15:20 < cat-a-puss> hey, could someone write a gaim plugin? that would be a good way to do it</p>
15:20 < jrandom> right cervantes </p>
15:20 < cervantes> they maybe use 1 for apps...and donate the others</p>
15:21 < jrandom> mrflibble: http://localhost:7657/i2ptunnel/ to configure the http and irc proxies to listen on "any interface"</p>
15:21 < fvw> which reminds me: could we do something multicastish for outbound tunnels? ie have one message delivered to multiple inbouds?</p>
15:21 < nicktastic> cat-a-puss: Certainly possible</p>
15:21 < fvw> yeah, in essence there's not much difference between irc and im, apart from the user interface.</p>
15:22 < jrandom> fvw: yes and no. it wouldn't offer much savings (as messages are end to end encrypted, so you'd have to garlic wrap the message to the outbound tunnel's endpoint and direct the cloves seperately from there)</p>
15:22 < jrandom> imho multicast would want to use an application layer overlay</p>
15:22 < deer> &lt;mrflibble&gt; oh, thanks jrandom!</p>
15:22 < fvw> what do you mean by application layer overlay?</p>
15:22 < jrandom> ala shoutcast/etc</p>
15:23 < hypercubus> he means do the multicasting in the applcation layer</p>
15:23 < hypercubus> not in the i2p layer</p>
15:23 < cervantes> 'lo hyper</p>
15:23 < fvw> yes ok. Fair enough.</p>
15:24 < jrandom> ok, I ranted enough in the email about the client apps, so I'm not going to repeat myself here.</p>
15:25 * fvw pouts and puts away the popcorn.</p>
15:25 * jrandom !thwaps the wiseass</p>
15:26 < jrandom> but, basically I think before we go "live", we need something engaging to go live *with*</p>
15:26 < dm> If you build it, they will come...</p>
15:26 < dm> hahaha, or not!!!</p>
15:26 < fvw> yes. Though we could probably pull quite some crowd from freenet just by having dynamic (not to mention _working_) freesites.</p>
15:27 < deer> &lt;Pseudonym&gt; what about using some of the money in the general fund to create/increase bounties for the engaging stuff</p>
15:27 < nicktastic> ...and dht</p>
15:27 < cervantes> I have no knowledge of freenet... how do freesites differ to eepsites?</p>
15:27 < cervantes> if they are in any way the same</p>
15:27 < deer> &lt;Pseudonym&gt; eepsites work</p>
15:28 < deer> &lt;soros&gt; heh</p>
15:28 < hypercubus> imo you guys are impatient</p>
15:28 < cervantes> apart from that</p>
15:28 < nicktastic> hypercubus: How's that?</p>
15:28 < hypercubus> contribute to the project, or shut up</p>
15:28 < deer> &lt;soros&gt; freesites are static.</p>
15:28 < jrandom> bounties/voting some of the general fund to give $$$ to service providers / eepsites that do kickass things does sound like a good idea</p>
15:28 * jrandom is the impatient one hypercubus ;)</p>
15:28 < jrandom> Pseudonym: is that what you mean?</p>
15:28 < cervantes> these applications are certainly not going to materialise overnight</p>
15:29 < jrandom> right, thats why we need to talk about it now</p>
15:29 < jrandom> duck: you 'round?</p>
15:29 < hypercubus> it's these people pushing for public announcements</p>
15:29 < fvw> I doubt you'll get more eepsites with bounties. The people who build them do it because it's fun, I doubt we could pay those who don't find it fun enough.</p>
15:29 < deer> &lt;soros&gt; dynamic freesites can be updated, but only once a day... </p>
15:29 < jrandom> probably true fvw</p>
15:29 < deer> &lt;Pseudonym&gt; I was thinking more of using the general fund to support bounties for apps, not services/eepsites</p>
15:29 < fvw> nobody's pushing for announcements, it was just discussed briefly.</p>
15:30 < hypercubus> the project is evolving and growing naturally, have patience</p>
15:30 < jrandom> ok word Pseudonym. </p>
15:30 * fvw nods at pseudonym. That might be good yes.</p>
15:30 < jrandom> what would y'all suggest?</p>
15:30 < nicktastic> hypercubus: They're just brainstorming ways to grow the network without GROWING the network ;)</p>
15:30 < jrandom> the entire donation pool is available to be applied wherever we see fit</p>
15:30 < fvw> though I think small bug or feature bounties have the greatest chance of actually causing stuff to happen as opposed to being a nice gift for the person who happened to do it anyway.</p>
15:31 < deer> &lt;Pseudonym&gt; small bounties don't seem to be working. how about we push a bunch of money into the MyI2p pot</p>
15:32 < hypercubus> how about you donate?</p>
15:32 < nicktastic> jrandom: Well, for swarming file transfer and dds to be useful, we need streams faster than 4kbyte/sec, so two bounties are fairly dependent on the streaming library bounty</p>
15:32 < nicktastic> jrandom: But from earlier discussion, that sounds rather trivial</p>
15:32 < cervantes> throwing money at things isn't going to make stuff appear overnight either :)</p>
15:32 < deer> &lt;Pseudonym&gt; I have donated</p>
15:32 < deer> &lt;soros&gt; just announce i2p to slashdot</p>
15:32 < deer> &lt;soros&gt; thats all you need</p>
15:33 < hypercubus> that is exactly the opposite of what we need</p>
15:33 < deer> &lt;Pseudonym&gt; not overnight, but maybe somebody will start working on it</p>
15:33 < jrandom> nicktastic: the streaming lib will be lots of work, but thats the 0.4.3 release :)</p>
15:34 * nicktastic consults roadmap</p>
15:34 < jrandom> but I agree with cervantes, $$ doesn't make code, coders make code.</p>
15:34 < deer> &lt;soros&gt; is i2p listed on freshmeat ?</p>
15:34 < jrandom> if only there were some magic way to get in touch with hackers without letting general users know ;)</p>
15:34 < jrandom> not to my knowledge soros</p>
15:34 < fvw> cross-post to other anonymity-related software mailinglists?</p>
15:35 < fvw> actually, I think most of the people where already involved with freenet or gnunet, and have become aware of i2p already.</p>
15:35 < cervantes> hack into their inferior anonymity networks and say "hi come and work for us"</p>
15:35 < jrandom> we do get a good # of hits from gnunet's links page</p>
15:35 < jrandom> heh cervantes </p>
15:35 < deer> &lt;demonic_1&gt; there r some ng's i would think</p>
15:36 < cervantes> (work for us or we'll give your ip to big brother)</p>
15:36 < cat-a-puss> you could put refrences to I2p in wikis talking about related things</p>
15:36 < deer> &lt;baffled&gt; I think one thing we need is some way to get mail in to i2p and anonymously out of it.</p>
15:36 < jrandom> i think someone has already placed i2p at various spots in wikipedia, though i dont know about iA lately</p>
15:36 * fvw doesn't see why you couldn't run smtp over a tunnel.</p>
15:37 < jrandom> agreed baffled, a solid way to do mail *securely* would be great</p>
15:37 < cervantes> is that possible though</p>
15:37 < fvw> we must be careful not to spam though.</p>
15:37 < jrandom> fvw: do you trust your mail client?</p>
15:37 < jrandom> however, a mixminion/mixmaster outbound gateway would *rule*</p>
15:37 < jrandom> (so someone go set up a web interface to one of those. please :)</p>
15:37 < fvw> jrandom: as much as I trust any other client software... Do you trust your IRC client? your web browser? ...</p>
15:38 < cervantes> you'd have to trust the guy who owns the gateway isn't reading your mail</p>
15:38 < jrandom> fvw: no.</p>
15:38 < jrandom> fvw: and thats a problem.</p>
15:38 < jrandom> fvw: a problem we must fix before we can recommend that people use I2P for anything beyond testing.</p>
15:39 < fvw> How do you suggest making mail clients "more anonymous"?</p>
15:39 < jrandom> it'd need to be a local SMTP/POP3 "server" that reads from the client, parses, interprets, and acts accordingly.</p>
15:39 < cervantes> you'd need a bespoke mail application for a start</p>
15:39 < jrandom> (there are a few apps out there that do that already)</p>
15:39 < cervantes> (client)</p>
15:40 * cervantes apologies for saying "bespoke"</p>
15:40 < cervantes> *apologises</p>
15:40 < jrandom> but that gets to one of the points in the weekly status notes - there are just so many important things that need to get done</p>
15:40 < fvw> jrandom: That'd be very easy, at least on unix. Just hack up a sendmail drop in and something that does fetchmail and you're there. Could be done in shell scripts if you wanted to.</p>
15:40 < deer> &lt;duck&gt; me hears an echo of his name</p>
15:40 < jrandom> we need to focus if the bounties are going to be sufficient</p>
15:40 < jrandom> oh, heya duck</p>
15:41 < deer> &lt;duck&gt; sorry, I was euh.. drinking'</p>
15:41 < jrandom> duck: just wanted to check in to see if there was any update on that web gateway thingy? and/or whether it might be something normal i2p users could use?</p>
15:41 < jrandom> heh, cheers</p>
15:41 < nicktastic> drunken duck</p>
15:41 < cervantes> pond water?</p>
15:41 < jrandom> fvw: get coding :)</p>
15:42 < deer> &lt;duck&gt; nope, the dev did freeze up. will have to find someone else</p>
15:42 < jrandom> ok, sorry to hear that</p>
15:42 < deer> &lt;baffled&gt; We told you not to keep putting them in the closet to protect them.</p>
15:43 < deer> &lt;duck&gt; my initial specs: http://duck.i2p/files/anonyproxy.txt</p>
15:44 < deer> &lt;baffled&gt; Is getting mail in/out of i2p as easy as some type of interface web/tunnel to one of these mixmaster thingies?</p>
15:44 < jrandom> perhaps we can work on a revamp of the spec for that and see if it could serve the needs of normal eepsites (with i2p general funds pitching in)</p>
15:44 < jrandom> oh ok cool duck, i'll check that out</p>
15:44 < jrandom> baffled: out of i2p? yes. in to i2p? probably more work</p>
15:44 < fvw> baffled: Why do you want to add mixmaster? Everything mixmaster offers we already have.</p>
15:45 < jrandom> fvw: mixmaster has a network of outproxies, plus nontrivial delays</p>
15:45 < jrandom> ah ok duck, spec glanced over. we may be able to figure something</p>
15:45 < deer> &lt;baffled&gt; I don't, jrandom suggested setting up a web interface to it not me.</p>
15:46 < jrandom> (though it seems to have some heavyweight requirements, so maybe not. unsure, we can see)</p>
15:46 < deer> &lt;duck&gt; its very easy; expectation was 1.5h study of ingredients and then 3-4h patching</p>
15:46 < fvw> outproxies would be useful yes. As for nontrivial delays, someone who's not already using i2p isn't going to use i2p just for mail when there's mixmaster, whereas someone already using i2p is going to be compromised elsewhere by our lack of delays (if this is possible) anyway</p>
15:46 < jrandom> right right, plus ship perl, privoxy, and apache duck ;)</p>
15:47 < jrandom> perhaps fvw. (though i2p 3.0 blah blah blah)</p>
15:47 < fvw> hehe, I hesitate to say "good point", but I get what you mean.</p>
15:48 < nicktastic> FYI, JES (Java Email Server) provides SMTP and POP3 servers under the GPL</p>
15:49 < jrandom> ok, perhaps there should be some more discussion on the list or on the forum about what one or two client apps we should explore focusing on</p>
15:49 < jrandom> word nicktastic, there's also a kickass one from apache too</p>
15:49 < nicktastic> Nice, know what its called?</p>
15:49 < jrandom> http://james.apache.org/</p>
15:49 < nicktastic> Thanks</p>
15:50 < jrandom> (nntp too (drooool))</p>
15:50 < nicktastic> Wow</p>
15:50 * nicktastic gets a stiffy</p>
15:51 * fvw has joined #i2p-porn. Or at least it feels like that.</p>
15:51 < fvw> Ok, next?</p>
15:51 < jrandom> ok, we can continue client app discussions and strategizing on the list and in the forums</p>
15:51 < nicktastic> Yes</p>
15:52 < jrandom> but for now, moving on to 6) ???</p>
15:52 < nicktastic> Or during non-meeting hours ;P</p>
15:52 < jrandom> anyone have anything else they want to bring up?</p>
15:52 * fvw nods. It is worth some discussion on-list.</p>
15:52 < deer> &lt;duck&gt; little explanation to the www-inproxy: the idea was to get some ISP(s) to offer such a gateway as a service</p>
15:52 < fvw> nah, the list is good. Gives everyone a chance to chime in, not just those who happen to be awake.</p>
15:52 < jrandom> word duck, which is quite cool</p>
15:52 < deer> &lt;duck&gt; so joe i2p-less-sixpack can access it using his MSIE</p>
15:52 < deer> &lt;duck&gt; but the host is anonymous</p>
15:52 < deer> &lt;soros&gt; http://it.slashdot.org/article.pl?sid=04/09/14/2226226&amp;threshold=0&amp;tid=172&amp;tid=128&amp;tid=201&amp;tid=218 (ugly new exploit for windows xp)</p>
15:52 < jrandom> i2pless! heretic! burn them!</p>
15:53 < deer> &lt;duck&gt; ISP takes part of the risk, hence the whitelist requirement</p>
15:53 < deer> &lt;duck&gt; and ofcourse payment for domain etz</p>
15:53 < fvw> hehe. Then suddenly we plaster child porn all over the famous eepsites and watch half the people get arrested and the other half install i2p.</p>
15:53 < jrandom> heh</p>
15:53 < deer> * duck calls the AIVD</p>
15:54 < fvw> duck is dutch? *ponders*</p>
15:55 < deer> &lt;duck&gt; I think many clientapps are not really killer</p>
15:55 < jrandom> ok, anyone else have anything they want to bring up?</p>
15:55 < jrandom> agreed duck, but we need *something* </p>
15:55 < deer> &lt;duck&gt; some self-made smtp tunnel thing is not going to be a big thing</p>
15:56 < deer> &lt;duck&gt; myi2p with IOU accounting</p>
15:56 < deer> &lt;duck&gt; fvw: Bedankt foor die bloumen</p>
15:57 < deer> &lt;soros&gt; "After complaints to NIC.CX (the regulation authority of .cx domains) by an office worker named Rhonda Clarke of Christmas Island, the site goatse.cx was taken down Friday, January 16, 2004. (Goat.cx and Hick.org/Goat remain active.) A petition has even been launched to bring goatse.cx back. " </p>
15:57 < deer> &lt;soros&gt; i've lost faith in humanity</p>
15:57 < deer> &lt;duck&gt; small thing about the site: I2P was added to the &lt;title&gt; of each page for google purposes</p>
15:57 < deer> &lt;soros&gt; sorry wrong window</p>
15:57 < jrandom> ah ok duck</p>
15:57 < deer> &lt;duck&gt; but I dont keep up with the latest google-dance, so it might be worthless.</p>
15:57 < jrandom> perhaps if there were a way to explicitly not include it?</p>
15:58 < jrandom> (e.g. so we can say "Welcome to I2P.net" instead of "I2P - Welcome to I2P.net", etc)</p>
15:58 < deer> &lt;duck&gt; that is ofcourse possible</p>
15:58 < deer> * duck looks on the fun-o-meter</p>
15:58 < jrandom> we can always just add title = "I2P - How does it work" to menu.ini</p>
15:58 < deer> &lt;duck&gt; nope, not today</p>
15:58 < deer> &lt;thetower&gt; Oh oh, isn't there some way we can get google to crawl i2p? Like some sort of reverse proxy or something?</p>
15:58 < jrandom> yeah, not worth it</p>
15:58 < jrandom> thetower with duck's thingamabob, probably.</p>
15:59 < deer> &lt;duck&gt; yeah</p>
15:59 < fvw> but as mentioned, you probably don't want to be the one running it.</p>
15:59 < deer> &lt;thetower&gt; Seems like if eepsites were coming up in google searches that would be good advertising right there.</p>
16:00 < deer> &lt;duck&gt; fvw: I have contacted an isp who is interested</p>
16:00 < deer> &lt;duck&gt; but he is not going to build it</p>
16:00 < jrandom> thetower: perhaps if an ht://dig were hooked up to files.i2p, and if files.i2p exposed the database as big file with html links, that could be mirrored..?</p>
16:00 < fvw> duck: really? How large and in which country?</p>
16:00 < cervantes> how about a cache instead of a proxy</p>
16:00 < cervantes> ah</p>
16:00 < deer> &lt;duck&gt; 20cm</p>
16:00 < fvw> If I were an ISP and not afraid of the legal problems, I'd still not be interested until I2P was a lot bigger.</p>
16:01 < jrandom> a cache would be interesting too, a swarm of squids, etc</p>
16:01 < deer> &lt;duck&gt; skynet</p>
16:01 < fvw> that's pretty big. Did you give them a phone book to sit on?</p>
16:01 < nicktastic> hehe</p>
16:01 < deer> &lt;duck&gt; fvw: they'll likely scan the site before adding it</p>
16:01 < deer> &lt;duck&gt; so you'll have to find another place for your nasty stuff</p>
16:01 < fvw> Once or every update?</p>
16:02 < fvw> the latter seems a lot of work for very little content.</p>
16:02 < deer> &lt;duck&gt; every 2nd sunday of a month with an x in it</p>
16:02 < deer> &lt;duck&gt; geeh</p>
16:03 < jrandom> ok, we've gone past the two hour mark, does anyone else have something to bring up, or should we continue further discussions on the list / in the forum / etc?</p>
16:03 < fvw> I just find it highly unlikely that a serious ISP will commit resources to I2P at this point.</p>
16:03 * cervantes covers his head with a saucepan</p>
16:03 < deer> &lt;duck&gt; fvw: your emotions are noted.</p>
16:03 * fvw nods at jrandom. I need a drink. Keep up the good work.</p>
16:03 < deer> &lt;duck&gt; when will we go for the 24h meeting?</p>
16:04 < jrandom> perhaps next week duck </p>
16:04 * jrandom winds up</p>
16:04 < deer> &lt;duck&gt; oh boy!</p>
16:04 < fvw> duck: my emotions? You haven't even begun to see my emotions. Let me get a few drinks though.. *grin*</p>
16:04 * jrandom *baf*s cervantes on the head, closing the meeting</p>
</div>
{% endblock %}
14:06 < jrandom> 0) hi
14:06 < jrandom> 1) 0.4.0.1
14:06 < jrandom> 2) Threat model updates
14:06 < jrandom> 3) Website updates
14:06 < jrandom> 4) Roadmap
14:06 < jrandom> 5) Client apps
14:06 < jrandom> 6) ???
14:06 < jrandom> 0) hi
14:06 * jrandom waves
14:06 < cervantes> evening
14:06 < jrandom> weekly status notes posted to http://dev.i2p.net/pipermail/i2p/2004-September/000444.html
14:07 < jrandom> (before the meeting this time too ;)
14:07 < deer> <jrand0m> woah, 30 people over here
14:07 -!- Irssi: #i2p: Total of 21 nicks [0 ops, 0 halfops, 0 voices, 21 normal]
14:07 < jrandom> ok, anyway, lets jump right in to 1) 0.4.0.1
14:08 < jrandom> the release is out and things seem to be working more or less
14:09 < jrandom> i see a variety of connection times on irc, though in discussions with people, it seems there are congestion issues when e.g. downloading large files and using irc at the same time
14:09 < jrandom> are many people running into that?
14:10 < jrandom> i guess not
14:11 < cervantes> I've been doing various bandwidth tests recently and haven't encounter problems in that area yet...although I'm not using the bandwidth limiter
14:11 * nicktastic hasn't downloaded much since raiding alexandria weeks ago
14:11 < dm> I remember getting disconnect more often on IRC when I was using eepsites, but that was 2 months ago
14:11 < dm> disconnected
14:11 < dm> not sure if it still happens
14:11 < jrandom> ah, yeah, we need to harass the alexandria folks to give us more books :)
14:12 < Nightblade> thanks for keeping us up to date dm
14:12 < jrandom> i've had good luck w/ irc while downloading some large files from thetower, but, like cervantes, i dont have bandwidth limiting set
14:13 < jrandom> (though that router's bw average was a steady 11KBps at the time, while downloading 8KBps of music)
14:13 * nicktastic finds something to download
14:13 * jrandom watches your irc.duck.i2p connection quickly get dropped ;)
14:13 < jrandom> ok, anyway, does anyone have anything else they want to bring up wrt 0.4.0.1?
14:14 < dm> Nightblade: hehe, no problem :)
14:14 < dm> jrandom: good work, ever onwards
14:14 < fvw> the installer is pretty? (not sure if that's new in .1?)
14:14 < jrandom> gracias dm
14:15 < jrandom> fvw: same as 0.4, but i agree, hyper did some great work there (as did our anonymous designer!)
14:15 < fvw> also, I'm not going to commit myself as to pretty _what_ it is :)
14:15 < jrandom> sonofabi...
14:16 < jrandom> ok, moving on to 2) Threat model updates
14:16 < cervantes> yes well done.. :) writing documentation always sucks
14:17 < jrandom> yeah, it was a painful 2-3 days
14:17 < jrandom> i'm not sure if any of y'all have read http://www.i2p.net/how_threatmodel but if you ever want to know wtf we're talking about when we say "anonymous", thats what we mean
14:18 < jrandom> most of the categories there were just ripped from http://citeseer.ist.psu.edu/454354.html (linked to on the page)
14:18 < jrandom> there's a lot more i'd like to do in the threat model, but i just dont have the time.
14:18 < jrandom> i'd love to see a matrix of those threats vs cost of mounting them vs the type of user who cares about them
14:19 < jrandom> (e.g. joe sixpack does't care about global active adversaries)
14:19 < jrandom> so if anyone is bored... ;)
14:19 < cervantes> something that occurred to me whilst reading your doc... we need a decent glossary...
14:20 < fvw> doesn't he? joe sixpack likes to download mp3s...
14:20 < jrandom> someone just published one iirc...
14:20 < cervantes> really?
14:20 < cervantes> on an eep?
14:20 < jrandom> no, some research paper
14:20 < jrandom> its not on freehaven yet, lemmie dig it up
14:21 < jrandom> bugger, i dont seem to have my copy anymore.
14:21 < jrandom> i'll try to track it down after the meeting
14:22 < cervantes> does it tackle i2p specific concepts to?
14:22 < jrandom> oh, no
14:22 < jrandom> its just a general glossary for anonymous networks, dealing with mixes, cascades, attackers, etc
14:22 < jrandom> no garlic routing or tunnels ;)
14:23 < cervantes> a nice single paragraph summary of all "in" buzzwords so people can quickly see the difference between onion and garlic routing (for example) withou having to read the whole "how" document
14:23 < jrandom> you realize a glossary would be larger than the how_* pages combined, right?
14:23 < jrandom> but yeah, i agree, we should do that
14:23 < cervantes> sure... but.. ;)
14:23 * jrandom volunteers cervantes to work on it ;)
14:23 * dm concurs
14:23 < cervantes> hehe I don't know what half that shit means :)
14:24 < jrandom> write up what you do know and ask me questions
14:24 < cervantes> I'll have a crack at it
14:24 < jrandom> w00t! cervantes++
14:24 < cervantes> if I put it on the forum then others can contribute...
14:24 < jrandom> good idea
14:24 < deer> * Pseudonym cheers
14:25 < cervantes> _but_ that doc you mentioned would be handy :o)
14:25 < dm> tunnel: artificial underground passage
14:25 < jrandom> agreed, i'll try to find it again
14:25 < cervantes> I'll do a special version for you dm
14:25 < dm> yay!
14:26 < jrandom> ok, anything else on the threat model, or shall we move on to 3) Website updates ?
14:27 < jrandom> ok, as anyone who has been to the site today has seen, Curiosity has come up with some nice usability updates
14:27 < dm> I think cervantes and I are the only ones still awake.
14:27 < korkakak> I think that in threat models
14:28 < korkakak> you should add some mixnetwork attacks
14:28 < jrandom> what sort of mix attacks?
14:28 * dm loads up www.i2p.net
14:28 < korkakak> like collusion attacks
14:28 < jrandom> thats the thing that sucks about the taxonomies i used. they're all pretty much collusion attacks.
14:29 < korkakak> With mix attacks i mean attacks that may happen in a mix network
14:29 < korkakak> ah ok sorry
14:29 < jrandom> (and most can be used for either probabalistic or confirmation attacks, etc)
14:29 < dm> I like the increasing-in-size paragraphs. Helps drag people in. Far too technical for a front page though.
14:29 < korkakak> Another 5 cents from me: Can i2p detect a collusion automatically?
14:30 < jrandom> but if you have some suggestions for things we need to add, please, let me know
14:30 < jrandom> oh, definitely not. we haven't imported morphmix's algorithms
14:30 < korkakak> I c
14:30 < korkakak> ok keep on
14:30 < jrandom> though theirs wouldn't really fly with us though, since we're a free route mixnet
14:31 < korkakak> Well yes and no
14:31 < korkakak> but it is ok. SOrry for the interrutp
14:32 < cat-a-puss> It might also be a good idea to mention up frount some of the obvious attacks that I2p is NOT vunerable to
14:32 < jrandom> hmm? their algorithms are based off detecting the influence of colluding peers in the peer selection - within i2p, the local router explicitly defines the entire peer selection algorithm
14:33 < korkakak> I guess that this is true due to the size of todays network
14:33 < jrandom> ah, thats a good idea cat-a-puss, w/ MITM/etc. would you be interested in posting up some ideas for that?
14:33 < cat-a-puss> sure
14:33 < dm> MITM?
14:33 < dm> Ah, man in the middle.
14:33 < jrandom> muchas gracias cat-a-puss!
14:34 * cervantes jots down MITM for the glossary
14:34 < jrandom> korkakak: hmm. i'm not sure how that aspect is affected by the size of the net, but there may be things we can learn from morphmix's collusion detection, certainly
14:34 < jrandom> (perhaps wrt the netDb responses, for instance)
14:34 < korkakak> wrt = ?
14:35 < dm> hehee
14:35 < jrandom> sorry, with regards to
14:35 < dm> I know that one!
14:36 < jrandom> we would certainly benefit from more discussion on the threat model. perhaps we can start up a thread on the list or in the forum?
14:36 < dm> "The result is that the number of peers relaying each end to end message is the absolute minimum necessary to meet both the sender's and the receiver's threat model."
14:36 < dm> I like this way of looking at it.
14:37 < dm> Although it's not true.
14:37 < jrandom> hmm?
14:37 < jrandom> if both sender and receiver want only plausible deniability, they can talk directly
14:37 < jrandom> (etc)
14:37 < dm> The absolute minimum number of peers required to meet the threat model of A and B is the number of peers required by A or B, whichever has more stringent requirements :)
14:38 < jrandom> not true dm
14:38 < jrandom> if they both require 2 hop tunnels to defend against colluding attackers in their tunnels, they can't both have 1 hop tunnels
14:39 < dm> If A is willing to talk to someone with 10 indirections, and B is willing with 5, the minimum needed is 10, not 15!?
14:39 < jrandom> no, 15. B shouldn't trust A's tunnels.
14:39 < dm> Yeah, he shouldn't.
14:39 < dm> But theoratically.. Anyway, stupid discussion. I like that sentence though.
14:40 < jrandom> its one of the more important design decisions in i2p ;)
14:40 < jrandom> anyway, back to 3) Website updates
14:41 < deer> <nicktastic> (fyi - irc dropped while downloading two large files, but latency to the server is as it was before the downloads started, so could've been a fluke (ungraceful shutdown somewhere?))
14:41 < jrandom> Curiosity and I discussed the length of the new homepage, and while we all agree that its a little long, its better than the old 1 liner
14:41 < cervantes> agreed
14:42 < jrandom> ah ok. perhaps even network congestion while downloading, since the eepproxy and the irc client use the same I2P destination (by default)
14:42 < nicktastic> Aaah....
14:42 < jrandom> (so both would be trying to use the same pair of inbound tunnels)
14:42 < nicktastic> I was wondering why only one showed up
14:43 < jrandom> yeah, thats the default within I2PTunnel and the ministreaming lib. perhaps if someone cares we can expose a way to configure that ;)
14:43 < nicktastic> sorry to interrupt
14:43 < deer> * Pseudonym cares
14:43 < dm> such polite lads we have in this room
14:43 < interrupt> you are forgiven
14:44 < interrupt> ;)
14:44 * nicktastic rolls eyes
14:44 < jrandom> patches welcome Pseudonym ;) (naw, i'll see if i can find an easy way.. shouldnt be too hard)
14:44 < jrandom> ok, anyway
14:44 < deer> <Pseudonym> good, 'cause I don't know crap about how to code in java
14:45 < jrandom> there may be further website updates, but if anyone has any suggestions, please post 'em to the forum or the list, or point 'em out to Curiosity on irc and we'll get things rolling
14:45 < jrandom> anyone have anything they want to bring up wrt the website?
14:45 < cervantes> umm bouties perhaps
14:46 < cervantes> although maybe that's best saved for 5
14:46 < jrandom> prolly so
14:46 < jrandom> ok, moving on to 4) Roadmap
14:46 < jrandom> lots of updates. see the email for info
14:47 < jrandom> (or look at the pretty gantt chart ;)
14:47 < dm> Was that done in MS Project?
14:47 < jrandom> http://ganttproject.sourceforge.net/
14:47 < cervantes> eerm gantt :)
14:47 < dm> oh.. gantt is a product. My bad.
14:48 < dm> Nice to see there are no dependencies in the roadmap.
14:48 < jrandom> i've posted a few different revs of the roadmap over the last few days, but this one seems to be solid
14:48 < cervantes> it's all dependant on jrandom ;-)
14:48 * jrandom whimpers
14:48 < fvw> 3.0 in febuary? Wow.
14:48 < jrandom> the 2.0 and 3.0 releases are really just 1 (big) feature each
14:48 < dm> Don't forget: exponential versioning
14:49 < jrandom> heh
14:49 < jrandom> yeah, we'll be 1183 by next july
14:50 < dm> Well, it's more interesting than the abritrary +0.1 per build of most projects, so I'm not complaining.
14:50 < jrandom> the 2.0 and 3.0 releases may be delayed to stay in line with other apps though. e.g. 3.0 would work great with an email app
14:51 < jrandom> the release criteria for 1.0 has been the usual - functional, secure, scalable, and anonymous
14:51 < jrandom> thats why i moved the udp transport in, as our current tcp transport would shit bricks if we had a few thousand peers
14:51 < dm> so we should have a 0.9 - The Slashdot
14:51 < dm> if it survives we can check off scalable and move to 1.0
14:51 < jrandom> heh
14:52 * jrandom would rather grow organically, thankyouverymuch
14:52 < cervantes> we don't to tell _them_ about it
14:52 < cervantes> *don't want
14:52 < korkakak> btw may i say something about the global timing?
14:52 < cervantes> let them all stay on the internet while we move here
14:52 < jrandom> sure korkakak
14:53 < korkakak> As far as i am concerned you cannot simulate a synchronus network over an asynchronous
14:53 < korkakak> it is just bad design and should lead to network splits [i think] in the way it is used
14:54 < korkakak> as a timestamp for UDP packets
14:54 < jrandom> the timing is not synchronized for messaging, merely to help us know the freshness of data
14:54 < korkakak> yes that's the point
14:54 < jrandom> without knowing the freshness of the netDb entries, you're vulnerable to a whole slew of attacks
14:55 < korkakak> Yes
14:55 < korkakak> but imagine a growing network
14:55 < korkakak> a huge network
14:55 < jrandom> like the internet
14:55 < dm> bigger!
14:55 < fvw> two internets tied together with bits of string!
14:55 < jrandom> that has a network time protocol for scaling to such sizes... ;)
14:56 < korkakak> I don't think I understand your point but
14:56 < dm> korkakak: what are you trying to say?
14:57 < korkakak> that net splits may happend due to invalid timestamps
14:58 * dm is not sure how syncing works currently
14:58 < korkakak> the case is called localization effect [english translation from greek]
14:58 < deer> <soros> i hear i2p's anonymity has been cracked
14:59 < deer> <soros> true ?
14:59 < jrandom> i believe we can address the time sync issue the same way the NTP networks do. there are a massive number of tier 2 and 3 NTP hosts, and while our current SNTP implementation is of course unsuitable for congested environments, there is no reason to believe time synchronization isn't possible
14:59 < jrandom> heh soros
14:59 < jrandom> soros: the thread you're referring to (someone else mentioned it to me) on devl was talking about JAP being compromised, not I2P.
15:00 < dm> so all I2P nodes must stay synced at all times for it to work?
15:00 < korkakak> NTP nets are synhcronus networks over synchronus networks ;-)
15:00 < jrandom> but if someone has a compromise for I2P, I would certainly love to hear about it
15:00 < deer> <soros> i have one but i'm keeping it a secret
15:00 < jrandom> at various levels of abstraction korkakak, sure. my ethernet cable is synchronized too
15:01 < deer> <soros> :)
15:01 < jrandom> yes dm, synchronized to the network time
15:01 < korkakak> jrandom it is nick or korki :-)
15:01 < jrandom> (the point is that we dont use synchronous messaging)
15:01 < jrandom> :) 'k
15:01 < jrandom> (please dont be offended if i dont tell you my name ;)
15:02 < korkakak> No I am not
15:02 < dm> His name is Abdul
15:02 < jrandom> ok where were we
15:02 < nicktastic> 4)
15:03 < jrandom> ok right, thanks. the roadmap
15:03 < jrandom> anyone have any concerns / ideas / suggestions?
15:03 < dm> so when you say some work is going to be done on the transport, do you mean reworking TCP, or moving to UDP?
15:04 < jrandom> UDP is 0.4.4
15:05 < dm> I thought I saw something about work on the transport layer
15:05 < dm> in the near future
15:05 < jrandom> yes, 0.4.1 will be a revamp of the TCP transport
15:05 < dm> why revamp TCP in 0.4.1 if going UDP in 0.4.4?
15:05 < dm> We'll need both?
15:05 < cervantes> only to point out that your are still the only resource in the project plan... ...are we suffering from a lack of contributors or just project fragmentation?
15:06 < jrandom> dm: some people cannot use UDP
15:06 < dm> firewalls?
15:06 < jrandom> cervantes: we certainly could parallelize many of those tasks with more contributors
15:07 < jrandom> (but the roadmap does not assume more)
15:07 < cervantes> so hopefully it represents the worse case scenario
15:07 < jrandom> there is however other important work going on not reflected on the roadmap, such as client mods, services on top of i2p, etc
15:08 < cervantes> asside from you being assassinated
15:08 < dm> I wish we could afford toad
15:08 < deer> <Pseudonym> now that 0.4 is out and pretty much working, should we announce somewhere (not necessarily /.) to try to increase the number of developers/testers/donors?
15:08 < jrandom> more contributors would certainly be welcome
15:08 * korkakak farewells all. REady to go to his bed. It is late at korkakak lands...
15:08 < korkakak> bye gayz
15:08 < cervantes> g'night
15:08 < jrandom> thanks for swinging by nick, ttyl
15:10 < dm> nite
15:10 < jrandom> a /. would probably be premature, but it would be good to bring new folks on board through other means
15:10 < dm> You're very open to Pseudonym's suggestion. I thought you were going to freak out.
15:10 < jrandom> but i think through word of mouth we're growing steadily
15:11 < deer> <Pseudonym> and if we do want to announce, where should we do it?
15:11 < jrandom> i dont think we should have any announcements yet, not till 1.0
15:11 < deer> <Pseudonym> seems like we could use an influx of cash/talent
15:11 < jrandom> but if you hear someone talking about how they wish there were some way to help do stuff anonymously, point 'em at i2p ;)
15:12 < deer> * DrWoo suggests a whisper campaign
15:12 < cervantes> we have a fair amount of unnallocated cash already...
15:12 < jrandom> we're an open team, but you only have one chance to make a first impression.
15:13 < cat-a-puss> I would not recomend going from no publicity to /. there needs to be an intermediate step to make sure we can handel the load
15:13 < deer> <Pseudonym> then we should allocate it to bounties we think are important
15:13 < dm> We need to hire a full-time dev or find someone REALLY REALLY bored
15:13 < jrandom> agreed. i'd like to see at least 500 routers online prior
15:13 < jrandom> actually, y'all are moving us right along to 5) Client apps :)
15:14 < jrandom> we do have ~300 in the pot at the moment (well, almost, but thats another story)
15:14 < deer> <Pseudonym> any suggestions on what the intermediate step could be?
15:14 < jrandom> pseudonym: we can't have 1000s of nodes until 0.4.4
15:15 < jrandom> (and we'd want to stress test the net out first)
15:15 < fvw> Actually, we probably can on most unices. Needs adjusting the rlimits though.
15:15 < jrandom> right right
15:15 < jrandom> it'd be painful, anyway ;)
15:16 < deer> <Pseudonym> right. so no /. but it seems like there should be somewhere we can get a couple hundred
15:16 < jrandom> we can do larger sims though
15:16 < deer> <Pseudonym> does anyone know someone at the EFF? maybe they have a mailing list
15:17 < jrandom> yeah, i've spoken with some eff folks about some things
15:17 < fvw> I think any announcement will cause it to filter through to slashdot. I agree with jrandom, a little waiting isn't bad at this time.
15:18 < dm> you have to be aware that if you hit 200-300 nodes, you're most likely to get an automatic /. mention ;)
15:18 < jrandom> (especially since we've been going for ~ 15 months already)
15:18 < dm> critical mass/hype and all that
15:18 < jrandom> well, thats also another thing that leads in to 5) Client apps
15:19 < jrandom> i'm watching some stats and it seems probably 1/4th of the routers out there aren't even really doing any client activity
15:19 < jrandom> which is great and wonderful that people are willing to donate their resources to act as I2P routers, but its too bad that we dont have something to suck them in :)
15:19 < fvw> Yeah, I'd like to do a proper chat app (as in irc, but in a way that makes sense for i2p), but this is very much a long term thing, no time the next few months...
15:20 < jrandom> we have had an influx of kickass eepsites recently though
15:20 < jrandom> ah cool fvw
15:20 < cervantes> many people run more than 1 router though
15:20 < jrandom> a solid IM/group chat for I2P would certainly rule
15:20 < nicktastic> fvw: Instant messenger with multi-user chat, perhaps?
15:20 < deer> <mrflibble> dudes, in 0.4.0.1, how do i allow the router to listen on more than just localhost?
15:20 < cat-a-puss> hey, could someone write a gaim plugin? that would be a good way to do it
15:20 < jrandom> right cervantes
15:20 < cervantes> they maybe use 1 for apps...and donate the others
15:21 < jrandom> mrflibble: http://localhost:7657/i2ptunnel/ to configure the http and irc proxies to listen on "any interface"
15:21 < fvw> which reminds me: could we do something multicastish for outbound tunnels? ie have one message delivered to multiple inbouds?
15:21 < nicktastic> cat-a-puss: Certainly possible
15:21 < fvw> yeah, in essence there's not much difference between irc and im, apart from the user interface.
15:22 < jrandom> fvw: yes and no. it wouldn't offer much savings (as messages are end to end encrypted, so you'd have to garlic wrap the message to the outbound tunnel's endpoint and direct the cloves seperately from there)
15:22 < jrandom> imho multicast would want to use an application layer overlay
15:22 < deer> <mrflibble> oh, thanks jrandom!
15:22 < fvw> what do you mean by application layer overlay?
15:22 < jrandom> ala shoutcast/etc
15:23 < hypercubus> he means do the multicasting in the applcation layer
15:23 < hypercubus> not in the i2p layer
15:23 < cervantes> 'lo hyper
15:23 < fvw> yes ok. Fair enough.
15:24 < jrandom> ok, I ranted enough in the email about the client apps, so I'm not going to repeat myself here.
15:25 * fvw pouts and puts away the popcorn.
15:25 * jrandom !thwaps the wiseass
15:26 < jrandom> but, basically I think before we go "live", we need something engaging to go live *with*
15:26 < dm> If you build it, they will come...
15:26 < dm> hahaha, or not!!!
15:26 < fvw> yes. Though we could probably pull quite some crowd from freenet just by having dynamic (not to mention _working_) freesites.
15:27 < deer> <Pseudonym> what about using some of the money in the general fund to create/increase bounties for the engaging stuff
15:27 < nicktastic> ...and dht
15:27 < cervantes> I have no knowledge of freenet... how do freesites differ to eepsites?
15:27 < cervantes> if they are in any way the same
15:27 < deer> <Pseudonym> eepsites work
15:28 < deer> <soros> heh
15:28 < hypercubus> imo you guys are impatient
15:28 < cervantes> apart from that
15:28 < nicktastic> hypercubus: How's that?
15:28 < hypercubus> contribute to the project, or shut up
15:28 < deer> <soros> freesites are static.
15:28 < jrandom> bounties/voting some of the general fund to give $$$ to service providers / eepsites that do kickass things does sound like a good idea
15:28 * jrandom is the impatient one hypercubus ;)
15:28 < jrandom> Pseudonym: is that what you mean?
15:28 < cervantes> these applications are certainly not going to materialise overnight
15:29 < jrandom> right, thats why we need to talk about it now
15:29 < jrandom> duck: you 'round?
15:29 < hypercubus> it's these people pushing for public announcements
15:29 < fvw> I doubt you'll get more eepsites with bounties. The people who build them do it because it's fun, I doubt we could pay those who don't find it fun enough.
15:29 < deer> <soros> dynamic freesites can be updated, but only once a day...
15:29 < jrandom> probably true fvw
15:29 < deer> <Pseudonym> I was thinking more of using the general fund to support bounties for apps, not services/eepsites
15:29 < fvw> nobody's pushing for announcements, it was just discussed briefly.
15:30 < hypercubus> the project is evolving and growing naturally, have patience
15:30 < jrandom> ok word Pseudonym.
15:30 * fvw nods at pseudonym. That might be good yes.
15:30 < jrandom> what would y'all suggest?
15:30 < nicktastic> hypercubus: They're just brainstorming ways to grow the network without GROWING the network ;)
15:30 < jrandom> the entire donation pool is available to be applied wherever we see fit
15:30 < fvw> though I think small bug or feature bounties have the greatest chance of actually causing stuff to happen as opposed to being a nice gift for the person who happened to do it anyway.
15:31 < deer> <Pseudonym> small bounties don't seem to be working. how about we push a bunch of money into the MyI2p pot
15:32 < hypercubus> how about you donate?
15:32 < nicktastic> jrandom: Well, for swarming file transfer and dds to be useful, we need streams faster than 4kbyte/sec, so two bounties are fairly dependent on the streaming library bounty
15:32 < nicktastic> jrandom: But from earlier discussion, that sounds rather trivial
15:32 < cervantes> throwing money at things isn't going to make stuff appear overnight either :)
15:32 < deer> <Pseudonym> I have donated
15:32 < deer> <soros> just announce i2p to slashdot
15:32 < deer> <soros> thats all you need
15:33 < hypercubus> that is exactly the opposite of what we need
15:33 < deer> <Pseudonym> not overnight, but maybe somebody will start working on it
15:33 < jrandom> nicktastic: the streaming lib will be lots of work, but thats the 0.4.3 release :)
15:34 * nicktastic consults roadmap
15:34 < jrandom> but I agree with cervantes, $$ doesn't make code, coders make code.
15:34 < deer> <soros> is i2p listed on freshmeat ?
15:34 < jrandom> if only there were some magic way to get in touch with hackers without letting general users know ;)
15:34 < jrandom> not to my knowledge soros
15:34 < fvw> cross-post to other anonymity-related software mailinglists?
15:35 < fvw> actually, I think most of the people where already involved with freenet or gnunet, and have become aware of i2p already.
15:35 < cervantes> hack into their inferior anonymity networks and say "hi come and work for us"
15:35 < jrandom> we do get a good # of hits from gnunet's links page
15:35 < jrandom> heh cervantes
15:35 < deer> <demonic_1> there r some ng's i would think
15:36 < cervantes> (work for us or we'll give your ip to big brother)
15:36 < cat-a-puss> you could put refrences to I2p in wikis talking about related things
15:36 < deer> <baffled> I think one thing we need is some way to get mail in to i2p and anonymously out of it.
15:36 < jrandom> i think someone has already placed i2p at various spots in wikipedia, though i dont know about iA lately
15:36 * fvw doesn't see why you couldn't run smtp over a tunnel.
15:37 < jrandom> agreed baffled, a solid way to do mail *securely* would be great
15:37 < cervantes> is that possible though
15:37 < fvw> we must be careful not to spam though.
15:37 < jrandom> fvw: do you trust your mail client?
15:37 < jrandom> however, a mixminion/mixmaster outbound gateway would *rule*
15:37 < jrandom> (so someone go set up a web interface to one of those. please :)
15:37 < fvw> jrandom: as much as I trust any other client software... Do you trust your IRC client? your web browser? ...
15:38 < cervantes> you'd have to trust the guy who owns the gateway isn't reading your mail
15:38 < jrandom> fvw: no.
15:38 < jrandom> fvw: and thats a problem.
15:38 < jrandom> fvw: a problem we must fix before we can recommend that people use I2P for anything beyond testing.
15:39 < fvw> How do you suggest making mail clients "more anonymous"?
15:39 < jrandom> it'd need to be a local SMTP/POP3 "server" that reads from the client, parses, interprets, and acts accordingly.
15:39 < cervantes> you'd need a bespoke mail application for a start
15:39 < jrandom> (there are a few apps out there that do that already)
15:39 < cervantes> (client)
15:40 * cervantes apologies for saying "bespoke"
15:40 < cervantes> *apologises
15:40 < jrandom> but that gets to one of the points in the weekly status notes - there are just so many important things that need to get done
15:40 < fvw> jrandom: That'd be very easy, at least on unix. Just hack up a sendmail drop in and something that does fetchmail and you're there. Could be done in shell scripts if you wanted to.
15:40 < deer> <duck> me hears an echo of his name
15:40 < jrandom> we need to focus if the bounties are going to be sufficient
15:40 < jrandom> oh, heya duck
15:41 < deer> <duck> sorry, I was euh.. drinking'
15:41 < jrandom> duck: just wanted to check in to see if there was any update on that web gateway thingy? and/or whether it might be something normal i2p users could use?
15:41 < jrandom> heh, cheers
15:41 < nicktastic> drunken duck
15:41 < cervantes> pond water?
15:41 < jrandom> fvw: get coding :)
15:42 < deer> <duck> nope, the dev did freeze up. will have to find someone else
15:42 < jrandom> ok, sorry to hear that
15:42 < deer> <baffled> We told you not to keep putting them in the closet to protect them.
15:43 < deer> <duck> my initial specs: http://duck.i2p/files/anonyproxy.txt
15:44 < deer> <baffled> Is getting mail in/out of i2p as easy as some type of interface web/tunnel to one of these mixmaster thingies?
15:44 < jrandom> perhaps we can work on a revamp of the spec for that and see if it could serve the needs of normal eepsites (with i2p general funds pitching in)
15:44 < jrandom> oh ok cool duck, i'll check that out
15:44 < jrandom> baffled: out of i2p? yes. in to i2p? probably more work
15:44 < fvw> baffled: Why do you want to add mixmaster? Everything mixmaster offers we already have.
15:45 < jrandom> fvw: mixmaster has a network of outproxies, plus nontrivial delays
15:45 < jrandom> ah ok duck, spec glanced over. we may be able to figure something
15:45 < deer> <baffled> I don't, jrandom suggested setting up a web interface to it not me.
15:46 < jrandom> (though it seems to have some heavyweight requirements, so maybe not. unsure, we can see)
15:46 < deer> <duck> its very easy; expectation was 1.5h study of ingredients and then 3-4h patching
15:46 < fvw> outproxies would be useful yes. As for nontrivial delays, someone who's not already using i2p isn't going to use i2p just for mail when there's mixmaster, whereas someone already using i2p is going to be compromised elsewhere by our lack of delays (if this is possible) anyway
15:46 < jrandom> right right, plus ship perl, privoxy, and apache duck ;)
15:47 < jrandom> perhaps fvw. (though i2p 3.0 blah blah blah)
15:47 < fvw> hehe, I hesitate to say "good point", but I get what you mean.
15:48 < nicktastic> FYI, JES (Java Email Server) provides SMTP and POP3 servers under the GPL
15:49 < jrandom> ok, perhaps there should be some more discussion on the list or on the forum about what one or two client apps we should explore focusing on
15:49 < jrandom> word nicktastic, there's also a kickass one from apache too
15:49 < nicktastic> Nice, know what its called?
15:49 < jrandom> http://james.apache.org/
15:49 < nicktastic> Thanks
15:50 < jrandom> (nntp too (drooool))
15:50 < nicktastic> Wow
15:50 * nicktastic gets a stiffy
15:51 * fvw has joined #i2p-porn. Or at least it feels like that.
15:51 < fvw> Ok, next?
15:51 < jrandom> ok, we can continue client app discussions and strategizing on the list and in the forums
15:51 < nicktastic> Yes
15:52 < jrandom> but for now, moving on to 6) ???
15:52 < nicktastic> Or during non-meeting hours ;P
15:52 < jrandom> anyone have anything else they want to bring up?
15:52 * fvw nods. It is worth some discussion on-list.
15:52 < deer> <duck> little explanation to the www-inproxy: the idea was to get some ISP(s) to offer such a gateway as a service
15:52 < fvw> nah, the list is good. Gives everyone a chance to chime in, not just those who happen to be awake.
15:52 < jrandom> word duck, which is quite cool
15:52 < deer> <duck> so joe i2p-less-sixpack can access it using his MSIE
15:52 < deer> <duck> but the host is anonymous
15:52 < deer> <soros> http://it.slashdot.org/article.pl?sid=04/09/14/2226226&amp;threshold=0&amp;tid=172&amp;tid=128&amp;tid=201&amp;tid=218 (ugly new exploit for windows xp)
15:52 < jrandom> i2pless! heretic! burn them!
15:53 < deer> <duck> ISP takes part of the risk, hence the whitelist requirement
15:53 < deer> <duck> and ofcourse payment for domain etz
15:53 < fvw> hehe. Then suddenly we plaster child porn all over the famous eepsites and watch half the people get arrested and the other half install i2p.
15:53 < jrandom> heh
15:53 < deer> * duck calls the AIVD
15:54 < fvw> duck is dutch? *ponders*
15:55 < deer> <duck> I think many clientapps are not really killer
15:55 < jrandom> ok, anyone else have anything they want to bring up?
15:55 < jrandom> agreed duck, but we need *something*
15:55 < deer> <duck> some self-made smtp tunnel thing is not going to be a big thing
15:56 < deer> <duck> myi2p with IOU accounting
15:56 < deer> <duck> fvw: Bedankt foor die bloumen
15:57 < deer> <soros> "After complaints to NIC.CX (the regulation authority of .cx domains) by an office worker named Rhonda Clarke of Christmas Island, the site goatse.cx was taken down Friday, January 16, 2004. (Goat.cx and Hick.org/Goat remain active.) A petition has even been launched to bring goatse.cx back. "
15:57 < deer> <soros> i've lost faith in humanity
15:57 < deer> <duck> small thing about the site: I2P was added to the <title> of each page for google purposes
15:57 < deer> <soros> sorry wrong window
15:57 < jrandom> ah ok duck
15:57 < deer> <duck> but I dont keep up with the latest google-dance, so it might be worthless.
15:57 < jrandom> perhaps if there were a way to explicitly not include it?
15:58 < jrandom> (e.g. so we can say "Welcome to I2P.net" instead of "I2P - Welcome to I2P.net", etc)
15:58 < deer> <duck> that is ofcourse possible
15:58 < deer> * duck looks on the fun-o-meter
15:58 < jrandom> we can always just add title = "I2P - How does it work" to menu.ini
15:58 < deer> <duck> nope, not today
15:58 < deer> <thetower> Oh oh, isn't there some way we can get google to crawl i2p? Like some sort of reverse proxy or something?
15:58 < jrandom> yeah, not worth it
15:58 < jrandom> thetower with duck's thingamabob, probably.
15:59 < deer> <duck> yeah
15:59 < fvw> but as mentioned, you probably don't want to be the one running it.
15:59 < deer> <thetower> Seems like if eepsites were coming up in google searches that would be good advertising right there.
16:00 < deer> <duck> fvw: I have contacted an isp who is interested
16:00 < deer> <duck> but he is not going to build it
16:00 < jrandom> thetower: perhaps if an ht://dig were hooked up to files.i2p, and if files.i2p exposed the database as big file with html links, that could be mirrored..?
16:00 < fvw> duck: really? How large and in which country?
16:00 < cervantes> how about a cache instead of a proxy
16:00 < cervantes> ah
16:00 < deer> <duck> 20cm
16:00 < fvw> If I were an ISP and not afraid of the legal problems, I'd still not be interested until I2P was a lot bigger.
16:01 < jrandom> a cache would be interesting too, a swarm of squids, etc
16:01 < deer> <duck> skynet
16:01 < fvw> that's pretty big. Did you give them a phone book to sit on?
16:01 < nicktastic> hehe
16:01 < deer> <duck> fvw: they'll likely scan the site before adding it
16:01 < deer> <duck> so you'll have to find another place for your nasty stuff
16:01 < fvw> Once or every update?
16:02 < fvw> the latter seems a lot of work for very little content.
16:02 < deer> <duck> every 2nd sunday of a month with an x in it
16:02 < deer> <duck> geeh
16:03 < jrandom> ok, we've gone past the two hour mark, does anyone else have something to bring up, or should we continue further discussions on the list / in the forum / etc?
16:03 < fvw> I just find it highly unlikely that a serious ISP will commit resources to I2P at this point.
16:03 * cervantes covers his head with a saucepan
16:03 < deer> <duck> fvw: your emotions are noted.
16:03 * fvw nods at jrandom. I need a drink. Keep up the good work.
16:03 < deer> <duck> when will we go for the 24h meeting?
16:04 < jrandom> perhaps next week duck
16:04 * jrandom winds up
16:04 < deer> <duck> oh boy!
16:04 < fvw> duck: my emotions? You haven't even begun to see my emotions. Let me get a few drinks though.. *grin*
16:04 * jrandom *baf*s cervantes on the head, closing the meeting

10
i2p2www/meetings/107.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, September 14, 2004
===================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,40 +1,34 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 108{% endblock %}
{% block content %}<h3>I2P dev meeting, September 21, 2004</h3>
<div class="irclog">
14:06 < jrandom> 0) hi</p>
14:06 < jrandom> 1) Dev status</p>
14:06 < jrandom> 2) New userhosts.txt vs. hosts.txt</p>
14:06 < jrandom> 3) ???</p>
14:06 < jrandom> 0) hi</p>
14:06 * jrandom waves</p>
14:06 < jrandom> brief weekly status notes @ http://dev.i2p.net/pipermail/i2p/2004-September/000449.html</p>
14:06 < jrandom> (and probably brief meeting logs to be posted once this is over ;)</p>
14:07 * jrandom gives y'all a good 30s to read those notes</p>
14:07 < jrandom> anyway, moving on to 1) dev status</p>
14:07 < jrandom> basic overview of whats up is in that email</p>
14:08 < jrandom> one thing you may notice is that i won't be missing random letters in my text anymore, as my laptop has been a bitch lately</p>
14:09 < jrandom> so i'm in the process of moving entirely over to my server (w/ the laptop as backup for windows testing, etc)</p>
14:09 < jrandom> thats all i've got to say on that front</p>
14:10 < jrandom> anyone have anything they want to bring up wrt 0.4.0.1 or the dev activity?</p>
14:11 < deer> &lt;jrandom&gt; no jrandom, we're just lurking</p>
14:11 < jrandom> ok, moving on to 2) new userhosts.txt vs. hosts.txt</p>
14:11 < protok0l> yey!</p>
14:11 < jrandom> minor new feature so people can modify their local naming while still pulling down hosts.txt</p>
14:12 < protok0l> which file has priority if they conflict? user i would assume</p>
14:13 < jrandom> it'll be rolled out in the next release, so basically just put your local changes in userhosts.txt as hosts.txt will be overridden</p>
14:13 < jrandom> userhosts.txt has first preference</p>
14:15 < jrandom> ok, thats all i've got for 2, so moving on quickly to our last point- 3) ???</p>
14:15 < jrandom> anyone have anything else they want to discuss?</p>
14:16 < deer> &lt;Pseudonym&gt; timetable for 0.4.1?</p>
14:17 < jrandom> should be out this week, but maybe not until the weekend.</p>
14:17 < deer> &lt;Pseudonym&gt; cool</p>
14:17 < jrandom> i finally gave up the battle with my laptop after the spacebar died</p>
14:17 < jrandom> (codingWithoutSpaces==lame;)</p>
14:18 < jrandom> ok, anyone else have anything they want to bring up? i think we're going for a record meeting time here</p>
14:18 < jrandom> (not that thats a problem)</p>
14:19 < jrandom> ok, if not</p>
14:19 * jrandom winds up</p>
14:19 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
14:06 < jrandom> 0) hi
14:06 < jrandom> 1) Dev status
14:06 < jrandom> 2) New userhosts.txt vs. hosts.txt
14:06 < jrandom> 3) ???
14:06 < jrandom> 0) hi
14:06 * jrandom waves
14:06 < jrandom> brief weekly status notes @ http://dev.i2p.net/pipermail/i2p/2004-September/000449.html
14:06 < jrandom> (and probably brief meeting logs to be posted once this is over ;)
14:07 * jrandom gives y'all a good 30s to read those notes
14:07 < jrandom> anyway, moving on to 1) dev status
14:07 < jrandom> basic overview of whats up is in that email
14:08 < jrandom> one thing you may notice is that i won't be missing random letters in my text anymore, as my laptop has been a bitch lately
14:09 < jrandom> so i'm in the process of moving entirely over to my server (w/ the laptop as backup for windows testing, etc)
14:09 < jrandom> thats all i've got to say on that front
14:10 < jrandom> anyone have anything they want to bring up wrt 0.4.0.1 or the dev activity?
14:11 < deer> <jrandom> no jrandom, we're just lurking
14:11 < jrandom> ok, moving on to 2) new userhosts.txt vs. hosts.txt
14:11 < protok0l> yey!
14:11 < jrandom> minor new feature so people can modify their local naming while still pulling down hosts.txt
14:12 < protok0l> which file has priority if they conflict? user i would assume
14:13 < jrandom> it'll be rolled out in the next release, so basically just put your local changes in userhosts.txt as hosts.txt will be overridden
14:13 < jrandom> userhosts.txt has first preference
14:15 < jrandom> ok, thats all i've got for 2, so moving on quickly to our last point- 3) ???
14:15 < jrandom> anyone have anything else they want to discuss?
14:16 < deer> <Pseudonym> timetable for 0.4.1?
14:17 < jrandom> should be out this week, but maybe not until the weekend.
14:17 < deer> <Pseudonym> cool
14:17 < jrandom> i finally gave up the battle with my laptop after the spacebar died
14:17 < jrandom> (codingWithoutSpaces==lame;)
14:18 < jrandom> ok, anyone else have anything they want to bring up? i think we're going for a record meeting time here
14:18 < jrandom> (not that thats a problem)
14:19 < jrandom> ok, if not
14:19 * jrandom winds up
14:19 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/108.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, September 21, 2004
===================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,119 +1,113 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 109{% endblock %}
{% block content %}<h3>I2P dev meeting, September 28, 2004</h3>
<div class="irclog">
14:08 < jrandom> 0) hi</p>
14:08 < jrandom> 1) New transport</p>
14:08 < jrandom> 2) 0.4.1 status</p>
14:08 < jrandom> 3) ???</p>
14:08 < jrandom> 0) hi</p>
14:08 < duck> hi</p>
14:09 < jrandom> heya</p>
14:09 < deer> &lt;ugha2p&gt; Hi.</p>
14:09 < deer> &lt;pseudonym&gt; hi</p>
14:09 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2004-September/000454.html</p>
14:09 < deer> * ugha2p is looking for the weekly status notes.</p>
14:09 < jrandom> (hey, i'm psychic)</p>
14:10 < jrandom> ok, jumping in to 1) New transport</p>
14:10 < jrandom> the message pretty much covers the main bits</p>
14:11 < jrandom> its all working atm, but obviously wont talk to anyone else until the new release is out</p>
14:12 < jrandom> i've kicked the tires on it a bit, but its pretty hard to simulate all the possible kooky network problems that occur at the transport level</p>
14:12 < deer> &lt;pseudonym&gt; does it include windowsize?</p>
14:12 < deer> &lt;ugha2p&gt; However, if you leave that blank, your router will let the first peer it contacts tell it what its IP address is, which it will then start listening on (after adding that to its own RouterInfo and placing that in the network database).</p>
14:12 < deer> &lt;ugha2p&gt; Sounds like a potential security hole.</p>
14:12 < jrandom> oh, no, this is just the inter-router transport, not the streaming lib, unfortunately</p>
14:12 < deer> &lt;pseudonym&gt; ok</p>
14:12 < jrandom> in a way ugha, yes</p>
14:12 < jrandom> (which is why if people *can* set their IP, they should)</p>
14:13 < jrandom> ugha: however, it only 'believes' someone if they have NO connections that work</p>
14:13 < deer> &lt;ugha2p&gt; Shouldn't the router listen on 0.0.0.0 in any case?</p>
14:13 < jrandom> but someone pretty smart could probabalistically do some evil things</p>
14:14 < jrandom> ugha: it does that (almost always)</p>
14:14 < jrandom> however, we need to know our IP address so we can put it in our RouterInfo</p>
14:14 < jrandom> (since our RouterInfo is verified whenever we contact someone)</p>
14:14 < deer> &lt;ugha2p&gt; Ah, ok.</p>
14:15 < deer> &lt;ugha2p&gt; I'm sure there are ways to make this more secure (rely on more routers for detecting the IP), but I'm not sure if this is feasible.</p>
14:15 < jrandom> yeah ugha, there's trouble down that path, but its a numbers game</p>
14:16 < deer> &lt;ugha2p&gt; Anyhow, that was just a suggestion. We can move on.</p>
14:16 < jrandom> (however, they could just sybil you and mess up whatever #s you're trying)</p>
14:16 < deer> &lt;ugha2p&gt; Right.</p>
14:17 < deer> &lt;ugha2p&gt; What if the router loses all connections (eg, network failure)?</p>
14:17 < deer> &lt;ugha2p&gt; Does it redetect its IP?</p>
14:18 < jrandom> the IP is transmitted as part of the protocol on all connection attempts, the peer just decides to honor it if 1) no ip was explicitly set 2) there are no active TCP connections</p>
14:18 < deer> &lt;ugha2p&gt; (This would be the case with dynamic IPs)</p>
14:18 < jrandom> right, it'll work fine with that</p>
14:18 < deer> &lt;ugha2p&gt; Ah, ok.</p>
14:19 < jrandom> (see ourAddressReceived(String addr) in TCPTransport.java for the details)</p>
14:19 < deer> &lt;pseudonym&gt; what happens when reported IPs don't match?</p>
14:19 < jrandom> pseudonym: if you already have active TCP connections, you ignore what other people tell you</p>
14:20 < jrandom> if you dont have active TCP connections, you tear down the old listener and start up a new one with the new address given</p>
14:20 < jrandom> (updating your routerInfo)</p>
14:22 < deer> &lt;pseudonym&gt; if there are active conns, it seems like a mismatch should be a red flag</p>
14:22 < deer> &lt;pseudonym&gt; (I'm not sure what to do with it)</p>
14:22 < jrandom> if someone gives us the wrong IP address (and we *know* its the wrong IP address, since we already have the right one - that *works*) we ignore it</p>
14:23 < deer> &lt;ugha2p&gt; Too bad we can no longer reduce the router's reliability ranking.</p>
14:23 < jrandom> we can add that to the list of connection errors though</p>
14:24 < jrandom> ugha: but we can shitlist 'em ;)</p>
14:24 < jrandom> (and we do)</p>
14:24 < deer> &lt;pseudonym&gt; how do we know the one we already have is "right"? maybe the existing conns are from black hats</p>
14:24 < deer> &lt;pseudonym&gt; especially if we have few or only recent conns</p>
14:24 < jrandom> pseudonym: the existing connections are "right" in that they can send and receive data</p>
14:24 < deer> &lt;ugha2p&gt; pseudonym: We can be sure when we get new inbound connections, although those can be spoofed as well.</p>
14:25 < jrandom> right, if we're talking about someone concerned with an active IP spoofing attack in addition to sybil...</p>
14:25 < jrandom> well, that person can simply set their IP address ;)</p>
14:25 < deer> &lt;ugha2p&gt; :)</p>
14:26 < deer> &lt;pseudonym&gt; but what's the likelyhood that the operator will even know what's happening</p>
14:26 < deer> &lt;pseudonym&gt; if we get a lot of mismatches there should be some active alert</p>
14:27 < deer> &lt;pseudonym&gt; (this may be something to worry about in a later release, but since it came up...)</p>
14:27 < jrandom> we can add an explicit message to the list of connection errors</p>
14:27 < jrandom> the only real concern here is that we're trying to prevent a restricted route from being formed</p>
14:27 < jrandom> (and the extreme of that being a full network partition)</p>
14:30 < jrandom> thats about all i can see us working to deal with for now, at least until the 2.0 rev when we need to worry beyond the restricted route</p>
14:30 < jrandom> ok, anyone else have anything wrt the new transport?</p>
14:31 < jrandom> if not, moving on to 2) 0.4.1 status</p>
14:31 < jrandom> all the "necessary" stuff is done, but theres still some debugging and minor updates to get in</p>
14:32 < jrandom> current target is a thursday release, but we'll see what gets added or removed from the rev ;)</p>
14:33 < jrandom> one thing that would be cool is if someone could download a jetty install, check out the jetty.xml config file, and could write up some docs on how to run a jetty instance (for an eepsite/etc) with what is shipped with i2p</p>
14:33 < deer> &lt;ugha2p&gt; Does 0.4.1 include other updates than the new TCP transport?</p>
14:33 < jrandom> not really ugha :)</p>
14:34 < deer> &lt;pseudonym&gt; is it backward compatible?</p>
14:34 < jrandom> (see: www.i2p.net/roadmap )</p>
14:34 < jrandom> no, it is not backwards compatible</p>
14:34 < deer> &lt;ugha2p&gt; :)</p>
14:36 < jrandom> ok, thats all ive got to mention wrt 0.4.1.. anything else on that?</p>
14:36 < jrandom> if not, we're on to ol' faithful: 3) ???</p>
14:36 < deer> &lt;ugha2p&gt; *silence*</p>
14:37 < jrandom> anyone have anything else (i2p related) they want to bring up?</p>
14:37 < jrandom> we're already twice as long as last week's meeting ;)</p>
14:37 < deer> &lt;ugha2p&gt; Well, I could mention that thanks to cervantes, my Wiki now has an outproxy to the real world, through http://ugha.ath.cx/</p>
14:38 < deer> * pseudonym is a troublemaker</p>
14:38 < jrandom> ooh right, v.cool</p>
14:38 < jrandom> s/outproxy/inproxy/ :)</p>
14:38 * jrandom sends the troublemaker to the corner</p>
14:38 < deer> &lt;ugha2p&gt; Right, inproxy. :)</p>
14:40 < jrandom> ok, if there's nothing else</p>
14:40 < deer> &lt;pseudonym&gt; I think the new mail service from the postmaster is pretty cool</p>
14:40 < jrandom> oh, definitely agreed</p>
14:40 < deer> &lt;pseudonym&gt; er, postman</p>
14:41 < deer> * ugha2p has yet to sign up.</p>
14:41 < deer> &lt;baffled&gt; has anyone heard anything of stasher recently?</p>
14:41 < jrandom> its nice that it works with both telnet and kmail:)</p>
14:41 < jrandom> naw baffled, havent heard a peep</p>
14:42 < deer> &lt;baffled&gt; I guess aum needs a boot to the head.</p>
14:42 < deer> &lt;ugha2p&gt; I would probably write a page about EepMailAnonymity, but I don't know too much about SMTP/POP3/IMAP/other e-mail-related stuff.</p>
14:42 < jrandom> not the head, the butt ;)</p>
14:43 < jrandom> ugha: www.postman.i2p has a few pages about that</p>
14:43 < deer> &lt;ugha2p&gt; Ah.</p>
14:43 < deer> &lt;baffled&gt; they may be the same.</p>
14:45 < deer> * ugha2p taps his fingers waiting for the baf.</p>
14:45 < jrandom> sorry, nearly passed out here (loong day)</p>
14:46 < jrandom> anything else? if not, we've got the forum and the list</p>
14:46 < duck> thanks to Mi-Go we have an updated i2ptunnel page</p>
14:46 < duck> it is almost perfect</p>
14:46 < jrandom> ooh nice</p>
14:46 < duck> but if someone has some improvements, you know where to find me</p>
14:47 * jrandom traceroutes</p>
14:47 * jrandom winds up</p>
14:47 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
14:08 < jrandom> 0) hi
14:08 < jrandom> 1) New transport
14:08 < jrandom> 2) 0.4.1 status
14:08 < jrandom> 3) ???
14:08 < jrandom> 0) hi
14:08 < duck> hi
14:09 < jrandom> heya
14:09 < deer> <ugha2p> Hi.
14:09 < deer> <pseudonym> hi
14:09 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2004-September/000454.html
14:09 < deer> * ugha2p is looking for the weekly status notes.
14:09 < jrandom> (hey, i'm psychic)
14:10 < jrandom> ok, jumping in to 1) New transport
14:10 < jrandom> the message pretty much covers the main bits
14:11 < jrandom> its all working atm, but obviously wont talk to anyone else until the new release is out
14:12 < jrandom> i've kicked the tires on it a bit, but its pretty hard to simulate all the possible kooky network problems that occur at the transport level
14:12 < deer> <pseudonym> does it include windowsize?
14:12 < deer> <ugha2p> However, if you leave that blank, your router will let the first peer it contacts tell it what its IP address is, which it will then start listening on (after adding that to its own RouterInfo and placing that in the network database).
14:12 < deer> <ugha2p> Sounds like a potential security hole.
14:12 < jrandom> oh, no, this is just the inter-router transport, not the streaming lib, unfortunately
14:12 < deer> <pseudonym> ok
14:12 < jrandom> in a way ugha, yes
14:12 < jrandom> (which is why if people *can* set their IP, they should)
14:13 < jrandom> ugha: however, it only 'believes' someone if they have NO connections that work
14:13 < deer> <ugha2p> Shouldn't the router listen on 0.0.0.0 in any case?
14:13 < jrandom> but someone pretty smart could probabalistically do some evil things
14:14 < jrandom> ugha: it does that (almost always)
14:14 < jrandom> however, we need to know our IP address so we can put it in our RouterInfo
14:14 < jrandom> (since our RouterInfo is verified whenever we contact someone)
14:14 < deer> <ugha2p> Ah, ok.
14:15 < deer> <ugha2p> I'm sure there are ways to make this more secure (rely on more routers for detecting the IP), but I'm not sure if this is feasible.
14:15 < jrandom> yeah ugha, there's trouble down that path, but its a numbers game
14:16 < deer> <ugha2p> Anyhow, that was just a suggestion. We can move on.
14:16 < jrandom> (however, they could just sybil you and mess up whatever #s you're trying)
14:16 < deer> <ugha2p> Right.
14:17 < deer> <ugha2p> What if the router loses all connections (eg, network failure)?
14:17 < deer> <ugha2p> Does it redetect its IP?
14:18 < jrandom> the IP is transmitted as part of the protocol on all connection attempts, the peer just decides to honor it if 1) no ip was explicitly set 2) there are no active TCP connections
14:18 < deer> <ugha2p> (This would be the case with dynamic IPs)
14:18 < jrandom> right, it'll work fine with that
14:18 < deer> <ugha2p> Ah, ok.
14:19 < jrandom> (see ourAddressReceived(String addr) in TCPTransport.java for the details)
14:19 < deer> <pseudonym> what happens when reported IPs don't match?
14:19 < jrandom> pseudonym: if you already have active TCP connections, you ignore what other people tell you
14:20 < jrandom> if you dont have active TCP connections, you tear down the old listener and start up a new one with the new address given
14:20 < jrandom> (updating your routerInfo)
14:22 < deer> <pseudonym> if there are active conns, it seems like a mismatch should be a red flag
14:22 < deer> <pseudonym> (I'm not sure what to do with it)
14:22 < jrandom> if someone gives us the wrong IP address (and we *know* its the wrong IP address, since we already have the right one - that *works*) we ignore it
14:23 < deer> <ugha2p> Too bad we can no longer reduce the router's reliability ranking.
14:23 < jrandom> we can add that to the list of connection errors though
14:24 < jrandom> ugha: but we can shitlist 'em ;)
14:24 < jrandom> (and we do)
14:24 < deer> <pseudonym> how do we know the one we already have is "right"? maybe the existing conns are from black hats
14:24 < deer> <pseudonym> especially if we have few or only recent conns
14:24 < jrandom> pseudonym: the existing connections are "right" in that they can send and receive data
14:24 < deer> <ugha2p> pseudonym: We can be sure when we get new inbound connections, although those can be spoofed as well.
14:25 < jrandom> right, if we're talking about someone concerned with an active IP spoofing attack in addition to sybil...
14:25 < jrandom> well, that person can simply set their IP address ;)
14:25 < deer> <ugha2p> :)
14:26 < deer> <pseudonym> but what's the likelyhood that the operator will even know what's happening
14:26 < deer> <pseudonym> if we get a lot of mismatches there should be some active alert
14:27 < deer> <pseudonym> (this may be something to worry about in a later release, but since it came up...)
14:27 < jrandom> we can add an explicit message to the list of connection errors
14:27 < jrandom> the only real concern here is that we're trying to prevent a restricted route from being formed
14:27 < jrandom> (and the extreme of that being a full network partition)
14:30 < jrandom> thats about all i can see us working to deal with for now, at least until the 2.0 rev when we need to worry beyond the restricted route
14:30 < jrandom> ok, anyone else have anything wrt the new transport?
14:31 < jrandom> if not, moving on to 2) 0.4.1 status
14:31 < jrandom> all the "necessary" stuff is done, but theres still some debugging and minor updates to get in
14:32 < jrandom> current target is a thursday release, but we'll see what gets added or removed from the rev ;)
14:33 < jrandom> one thing that would be cool is if someone could download a jetty install, check out the jetty.xml config file, and could write up some docs on how to run a jetty instance (for an eepsite/etc) with what is shipped with i2p
14:33 < deer> <ugha2p> Does 0.4.1 include other updates than the new TCP transport?
14:33 < jrandom> not really ugha :)
14:34 < deer> <pseudonym> is it backward compatible?
14:34 < jrandom> (see: www.i2p.net/roadmap )
14:34 < jrandom> no, it is not backwards compatible
14:34 < deer> <ugha2p> :)
14:36 < jrandom> ok, thats all ive got to mention wrt 0.4.1.. anything else on that?
14:36 < jrandom> if not, we're on to ol' faithful: 3) ???
14:36 < deer> <ugha2p> *silence*
14:37 < jrandom> anyone have anything else (i2p related) they want to bring up?
14:37 < jrandom> we're already twice as long as last week's meeting ;)
14:37 < deer> <ugha2p> Well, I could mention that thanks to cervantes, my Wiki now has an outproxy to the real world, through http://ugha.ath.cx/
14:38 < deer> * pseudonym is a troublemaker
14:38 < jrandom> ooh right, v.cool
14:38 < jrandom> s/outproxy/inproxy/ :)
14:38 * jrandom sends the troublemaker to the corner
14:38 < deer> <ugha2p> Right, inproxy. :)
14:40 < jrandom> ok, if there's nothing else
14:40 < deer> <pseudonym> I think the new mail service from the postmaster is pretty cool
14:40 < jrandom> oh, definitely agreed
14:40 < deer> <pseudonym> er, postman
14:41 < deer> * ugha2p has yet to sign up.
14:41 < deer> <baffled> has anyone heard anything of stasher recently?
14:41 < jrandom> its nice that it works with both telnet and kmail:)
14:41 < jrandom> naw baffled, havent heard a peep
14:42 < deer> <baffled> I guess aum needs a boot to the head.
14:42 < deer> <ugha2p> I would probably write a page about EepMailAnonymity, but I don't know too much about SMTP/POP3/IMAP/other e-mail-related stuff.
14:42 < jrandom> not the head, the butt ;)
14:43 < jrandom> ugha: www.postman.i2p has a few pages about that
14:43 < deer> <ugha2p> Ah.
14:43 < deer> <baffled> they may be the same.
14:45 < deer> * ugha2p taps his fingers waiting for the baf.
14:45 < jrandom> sorry, nearly passed out here (loong day)
14:46 < jrandom> anything else? if not, we've got the forum and the list
14:46 < duck> thanks to Mi-Go we have an updated i2ptunnel page
14:46 < duck> it is almost perfect
14:46 < jrandom> ooh nice
14:46 < duck> but if someone has some improvements, you know where to find me
14:47 * jrandom traceroutes
14:47 * jrandom winds up
14:47 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/109.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, September 28, 2004
===================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,10 +1,3 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 11{% endblock %}
{% block content %}
<h3>I2P (invisiblenet) Development Meeting 11</h3>
<div class="irclog">
Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
--- Log opened Tue Sep 17 22:59:26 2002
23:01 -!- mode/#iip-dev [+v logger] by mids
23:54 * Roto waves
@@ -157,5 +150,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
01:37 <+logger> official part is over, if you got more questions; ask here or in #iip
01:37 <+logger> cya next week
--- Log closed Wed Sep 18 01:37:46 2002
</div>
{% endblock %}

10
i2p2www/meetings/11.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, September 18, 2002
===================================
Quick recap
-----------
TODO
Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
------------

View File

@@ -1,186 +1,180 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 110{% endblock %}
{% block content %}<h3>I2P dev meeting, October 5, 2004</h3>
<div class="irclog">
14:05 < jrandom> 0) hi</p>
14:05 < jrandom> 1) 0.4.1.1 status</p>
14:05 < jrandom> 2) Pretty pictures</p>
14:05 < jrandom> 3) 0.4.1.2 and 0.4.2</p>
14:05 < jrandom> 4) Bundled eepserver</p>
14:05 < jrandom> 5) ???</p>
14:05 < jrandom> 0) hi</p>
14:05 * jrandom waves</p>
14:05 < jrandom> weekly status notes are available at http://dev.i2p.net/pipermail/i2p/2004-October/000461.html</p>
14:06 < jrandom> (i cant believe its october)</p>
14:06 < cervantes> it's december</p>
14:06 * jrandom disconnects from cervantes. excess clock skew</p>
14:06 < deer> &lt;baffled&gt; could we have summer back now?</p>
14:07 < cervantes> damn...lost your pr0n feed</p>
14:07 < jrandom> sure. its a few thousand KM south of you baffled</p>
14:07 < jrandom> ok, jumping into 1) 0.4.1.1 status</p>
14:07 < deer> &lt;baffled&gt; will you let me know when I get there?</p>
14:07 < cervantes> heh</p>
14:07 < jrandom> click your heels three times...</p>
14:08 < jrandom> ok, the 0.4.1 and 0.4.1.1 revs are out, and things are pretty much working again</p>
14:08 < deer> &lt;baffled&gt; no, no, I don't want to go home it's cold there.</p>
14:08 < jrandom> ;)</p>
14:08 < jrandom> the autodetection of the external IP address seems to be working for the most part</p>
14:09 < jrandom> (there have been a few quirks though, due to b0rked connections that don't hang up properly)</p>
14:09 < jrandom> have people been using that, or had good/bad experiences with the autodetection?</p>
14:10 < jrandom> guess not</p>
14:10 < jrandom> ok, anyone have any comments/questions/concerns wrt 0.4.1.1?</p>
14:11 < cervantes> no complaints here....</p>
14:11 < dm> Haven't tried it yet, but it's on my agenda!</p>
14:11 < jrandom> if not, swingin on to 2) pretty pictures</p>
14:11 < jrandom> !thwap dm</p>
14:12 < deer> &lt;Jake&gt; dunno about autodetection, but i tried using the 'guess' button or whatever on my natted windows box and it guessed the ip right...... if thats what wer're talking bout</p>
14:12 < jrandom> ah ok, naw, the 'guess' button just tries to guess your IP by querying www.whatismyip.com</p>
14:13 < jrandom> the autodetection is where you leave the IP address field blank and it figures it out by itself</p>
14:13 < jrandom> most existing I2P users won't need it, since we're all used to either dyndns or static IPs anyway</p>
14:13 < jrandom> it'll probably only matter for new users</p>
14:14 < deer> &lt;demonic_1&gt; yea that worked a little slow for me</p>
14:14 < deer> &lt;demonic_1&gt; but it did work</p>
14:15 < jrandom> ok cool</p>
14:15 < jrandom> anyway, i dont want to rehash what i posed in this weeks email wrt the stats gathered</p>
14:16 < jrandom> instead, does anyone have any questions/comments/concerns about them?</p>
14:17 < jrandom> i was pretty glad to see the 20h summary had only 500-something send failures out of 30,000-ish</p>
14:17 < cervantes> how much load does the stats collecting generate?</p>
14:17 < cervantes> I know the filesizes...but will it impact on performance having it ticking in the background</p>
14:18 < jrandom> should be ~= 0. there's no memory allocation in the stat gathering (as we use preallocated events) and everything is async</p>
14:18 < cervantes> cool</p>
14:18 -!- Sugadude [random@badfish.securityminded.net] has joined #i2p</p>
14:18 -!- cat-a-puss [~tom@152.228.242.159] has joined #i2p</p>
14:19 < jrandom> once 0.4.1.2 is outi'll probably nag some more people to gather various stats at times</p>
14:19 < deer> &lt;mule_iip&gt; you're welcome</p>
14:19 < cervantes> I'm happy to start collecting now... I'm already on 0.4.1.1-6</p>
14:20 < jrandom> w3wt</p>
14:21 < jrandom> ok, thats all i've got for the stats, unless anyone has anything to add?</p>
14:21 < jrandom> if not, 3) 0.4.1.2 and 0.4.2</p>
14:21 < deer> &lt;baffled&gt; You have my vote for streaming first.</p>
14:22 < jrandom> cool</p>
14:22 < jrandom> does anyone think we should keep the tunnel mods first?</p>
14:22 < deer> &lt;mule_iip&gt; streaming first</p>
14:23 < cervantes> doing the tunnel stuff now would likely cause more network distruption....it's probably good to have a breather ;-)</p>
14:23 < jrandom> true</p>
14:23 < deer> &lt;mule_iip&gt; all of those here today have been identified by the black hats anyhow :)</p>
14:23 < jrandom> though i was thinking the other day about how we could do the tunnel mods without incompatabilities</p>
14:23 < deer> &lt;baffled&gt; Comeon admit it, you just want to get your audio p0rn faster.</p>
14:23 < duck> (me too on streaming first)</p>
14:23 < jrandom> hehe</p>
14:24 < cervantes> hehe</p>
14:24 < cervantes> baffled: only if you source more of it ;-)</p>
14:24 < dm> I think we should stick to the tunnel stuff first</p>
14:24 < dm> get it out of the way...</p>
14:24 < cat-a-puss> how is the new encryption stuff going to be different?</p>
14:24 * jrandom kicks dm</p>
14:25 < jrandom> cat-a-puss: right now, we have blanket tunnel encryption - messages passed within the same tunnel look the same at each hop</p>
14:25 < deer> &lt;baffled&gt; I think I can get a bit more.</p>
14:25 < cat-a-puss> oh!</p>
14:26 < cervantes> http://www.i2p.net/todo#tunnelId</p>
14:26 < jrandom> it isn't so bad since an alice--&gt;bob message goes through two tunnels with different encryption, but it does b0rk us for colluding attackers</p>
14:27 < jrandom> the per-hop tunnelId stuff is also necessary to keep harvesting from messing with predecessors (/etc)</p>
14:27 < dm> Yeah, we should definitely fix that first.</p>
14:27 < deer> &lt;mule_iip&gt; i vote for dm to do it</p>
14:28 < deer> &lt;fidd&gt; did i miss the meeting? ;)</p>
14:28 < jrandom> i was just about to suggest that mule :)</p>
14:28 < cervantes> I vote for dm not to have anything to do with it</p>
14:28 < jrandom> heh</p>
14:28 < jrandom> nope fidd, we're on item 3 of the agenda</p>
14:29 < jrandom> ok, if there are no objections to dm's suggestion (other than his own), i think we'll go ahead and move the streaming lib updates to 0.4.2 </p>
14:29 < dm> sweet</p>
14:30 < jrandom> ok, moving on to 4) Bundled eepserver</p>
14:30 < jrandom> if you haven't noticed, there's a bundled eepserver.</p>
14:30 < cervantes> "just put the war files in the webapps directory and you're ready to go"</p>
14:30 < jrandom> heh</p>
14:30 < jrandom> for sufficiently well coded .war files :)</p>
14:31 < cervantes> ooh does such a think exist?</p>
14:31 < cervantes> *thing</p>
14:31 < jrandom> but from a practical perspective, "just edit ./eepsite/docroot/index.html"</p>
14:31 < deer> &lt;baffled&gt; One question I have is are you wishing people would use the eepserver or use a standard httpd server?</p>
14:31 < cat-a-puss> do the ones generated by kde work?</p>
14:31 < jrandom> cervantes: phttprelay.war, i2ptunnel.war, routerconsole.war :)</p>
14:31 < dm> ah yes.. war. One of those J2EE things that requires 20 years experience at manually editing xml files.</p>
14:31 < cervantes> touche</p>
14:32 < jrandom> baffled: i really don't care. if people have a webserver installed that can accept requests from kooky Host: lines, great</p>
14:32 < jrandom> the eepserver is just for convenience</p>
14:32 < jrandom> cat-a-puss: hmm, kde .war files?</p>
14:32 < protok0l> monoculture... monoculture...</p>
14:33 < deer> &lt;duck&gt; when playing with wars, I miss the feature to only restart jetty; which is unfortunately needed for a lot of deployment stuff</p>
14:33 < cat-a-puss> yeah, you need kdeaddons installed, just go to a webpage and then click archive and it makes a .war file</p>
14:34 < jrandom> duck: ah, thats true. simply pull out the lines starting the eepserver from clients.config and put them into a shell script</p>
14:34 < jrandom> (with the same classpath as the router)</p>
14:34 < dm> can we integrate i2p into jboss and bundle that before 1.0?</p>
14:34 < jrandom> ooh, cool cat-a-puss </p>
14:35 < cervantes> I take it the missing webdefault.xml has been fixed in cvs?</p>
14:35 < deer> &lt;detonate&gt; actually, jetty.xml has</p>
14:35 < jrandom> find us a compelling .ear dm :)</p>
14:35 < jrandom> cervantes: what detonate said. (i messed up the jetty.xml)</p>
14:36 < cervantes> yup... think I mentioned somewhere about removing the reference in the jetty.xml so it uses it the one inside the jetty archive</p>
14:36 < jrandom> wr0d</p>
14:37 < cervantes> just wanted to check that's been fixed in cvs ;-)</p>
14:37 < jrandom> si sr</p>
14:37 < cervantes> cool</p>
14:37 < jrandom> (though the 0.4.1.2 release update will not overwrite people's eepsite)</p>
14:37 < jrandom> ((0.4.1.2+ clean installs will of course include it though))</p>
14:38 < cervantes> oh and did we discover the cause of DrWoo's missing eepsite keys?</p>
14:38 < jrandom> actually, on that note, i just want to mention that everyone should upgrade whenever there is a new release, as if you don't, you might not have an upgrade procedure</p>
14:38 < jrandom> no cervantes, nor a reproducable bug :/</p>
14:39 < cervantes> ah good we can blame user error ;-)</p>
14:39 < deer> &lt;DrWoo&gt; cervantes: almost certainly something klutzy I did</p>
14:39 < cervantes> :o)</p>
14:39 * jrandom blames the gremlins</p>
14:40 < deer> &lt;Jake&gt; http://en.wikipedia.org/wiki/User:Kmweber/List_of_Everyone_Who_Has_Ever_Lived</p>
14:40 < jrandom> ok, moving on to 5) ???</p>
14:40 < jrandom> heh</p>
14:40 < jrandom> well, yes, that certainly qualifies as "other"</p>
14:40 < jrandom> anyone have anything they want to bring up?</p>
14:41 < dm> I'd like to put forward, at this point, that I am pleased with the new outlook the I2P community is showing towards my suggestions.</p>
14:41 < dm> Kind Regards</p>
14:41 < cat-a-puss> oh oh pick me! I have the base code for a distrubuted search.</p>
14:41 < deer> &lt;demonic_1&gt; yea why do i2p after running 30 + hours go up to 100% cpu</p>
14:41 < dm> dm</p>
14:41 < deer> &lt;Jake&gt; yes, i want to bring up the issue of encryption inheritence based on 4th order gamal fractal equations and how it would apply to i2p</p>
14:41 < deer> &lt;demonic_1&gt; and most of it system?</p>
14:41 < jrandom> ooh kickass cat-a-puss!</p>
14:41 < cat-a-puss> I anounced it here the other day, nobody noticed</p>
14:41 < deer> &lt;baffled&gt; only tangentially jake.</p>
14:42 < cat-a-puss> anyway, could use come cvs space</p>
14:42 < deer> &lt;DrWoo&gt; cat-a-puss: do you have an eepsite for that?</p>
14:42 < jrandom> demonic_1: hmm, there have been some critical bugs in the last release or two. are you on 0.4.1.1?</p>
14:42 < cat-a-puss> and I can start testing in about 2 weeks</p>
14:42 < cat-a-puss> DrWoo: nope</p>
14:42 < deer> &lt;Jake&gt; baffled, HaH !</p>
14:43 < deer> &lt;demonic_1&gt; 0.4.1.1-3</p>
14:43 < jrandom> cat-a-puss: r0x0r, not a problem. bounce me an email with the name of the module you'd like it called & your pgp key and we'll get something sorted</p>
14:44 < cat-a-puss> jrandom: alright</p>
14:44 < jrandom> cat-a-puss: what sort of searching does it do?</p>
14:44 < jrandom> demonic_1: did it consume that much CPU prior to 0.4.1?</p>
14:44 < cervantes> (proxies to MSN)</p>
14:44 < deer> &lt;mule_iip&gt; demonic_1: and you get 1 meg of log every minute? sounds familiar.</p>
14:45 < deer> &lt;demonic_1&gt; no</p>
14:45 < jrandom> heh mule, yeah the bug you found was a nasty fast-busy</p>
14:45 < cat-a-puss> jrandom: it's basic keywork search, you need to specify the words to index under, and it will store the URL</p>
14:45 < jrandom> demonic is more likely being hit by one of the NPEs in the tcp.ConnectionBuilder</p>
14:46 < deer> &lt;baffled&gt; Well, it's dindin time so I'll go hunt up some more slut sounds in preparation for the streaming updates and chat with you all anon.</p>
14:46 < cat-a-puss> jrandom: It should eventualy scale well, and all that jazz, but right now, all the servers need to be connected and nobody can join or leave, and there is no way to insert content yet, but all that will get fixed</p>
14:46 < jrandom> ah cool, does it work with a distributed db, or is it more of a search-against-spidered?</p>
14:47 < jrandom> ok cool</p>
14:47 < cervantes> later baffled</p>
14:47 < jrandom> lol, ttyl baffled</p>
14:47 < cervantes> baffled: how do we know they're slut sounds, and not you on the end of your microphone?</p>
14:47 < protok0l> ALL RIGHT!</p>
14:47 < protok0l> i2p works again</p>
14:47 < jrandom> w3wt</p>
14:48 < jrandom> what was wrong?</p>
14:49 < jrandom> ok, anyone else have anything they want to bring up for the meeting?</p>
14:49 < deer> &lt;Jake&gt; can announce i2p to slashdot after the new streaming protocol is implemented ?</p>
14:49 < dm> preferably before</p>
14:49 < dm> but after will do</p>
14:49 < jrandom> !thwap^2</p>
14:50 < protok0l> POSTMAN!</p>
14:50 < jrandom> ok, if there's nothing else..</p>
14:50 * jrandom winds up</p>
14:51 < deer> * Jake kisses jrandom </p>
14:51 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
14:05 < jrandom> 0) hi
14:05 < jrandom> 1) 0.4.1.1 status
14:05 < jrandom> 2) Pretty pictures
14:05 < jrandom> 3) 0.4.1.2 and 0.4.2
14:05 < jrandom> 4) Bundled eepserver
14:05 < jrandom> 5) ???
14:05 < jrandom> 0) hi
14:05 * jrandom waves
14:05 < jrandom> weekly status notes are available at http://dev.i2p.net/pipermail/i2p/2004-October/000461.html
14:06 < jrandom> (i cant believe its october)
14:06 < cervantes> it's december
14:06 * jrandom disconnects from cervantes. excess clock skew
14:06 < deer> <baffled> could we have summer back now?
14:07 < cervantes> damn...lost your pr0n feed
14:07 < jrandom> sure. its a few thousand KM south of you baffled
14:07 < jrandom> ok, jumping into 1) 0.4.1.1 status
14:07 < deer> <baffled> will you let me know when I get there?
14:07 < cervantes> heh
14:07 < jrandom> click your heels three times...
14:08 < jrandom> ok, the 0.4.1 and 0.4.1.1 revs are out, and things are pretty much working again
14:08 < deer> <baffled> no, no, I don't want to go home it's cold there.
14:08 < jrandom> ;)
14:08 < jrandom> the autodetection of the external IP address seems to be working for the most part
14:09 < jrandom> (there have been a few quirks though, due to b0rked connections that don't hang up properly)
14:09 < jrandom> have people been using that, or had good/bad experiences with the autodetection?
14:10 < jrandom> guess not
14:10 < jrandom> ok, anyone have any comments/questions/concerns wrt 0.4.1.1?
14:11 < cervantes> no complaints here....
14:11 < dm> Haven't tried it yet, but it's on my agenda!
14:11 < jrandom> if not, swingin on to 2) pretty pictures
14:11 < jrandom> !thwap dm
14:12 < deer> <Jake> dunno about autodetection, but i tried using the 'guess' button or whatever on my natted windows box and it guessed the ip right...... if thats what wer're talking bout
14:12 < jrandom> ah ok, naw, the 'guess' button just tries to guess your IP by querying www.whatismyip.com
14:13 < jrandom> the autodetection is where you leave the IP address field blank and it figures it out by itself
14:13 < jrandom> most existing I2P users won't need it, since we're all used to either dyndns or static IPs anyway
14:13 < jrandom> it'll probably only matter for new users
14:14 < deer> <demonic_1> yea that worked a little slow for me
14:14 < deer> <demonic_1> but it did work
14:15 < jrandom> ok cool
14:15 < jrandom> anyway, i dont want to rehash what i posed in this weeks email wrt the stats gathered
14:16 < jrandom> instead, does anyone have any questions/comments/concerns about them?
14:17 < jrandom> i was pretty glad to see the 20h summary had only 500-something send failures out of 30,000-ish
14:17 < cervantes> how much load does the stats collecting generate?
14:17 < cervantes> I know the filesizes...but will it impact on performance having it ticking in the background
14:18 < jrandom> should be ~= 0. there's no memory allocation in the stat gathering (as we use preallocated events) and everything is async
14:18 < cervantes> cool
14:18 -!- Sugadude [random@badfish.securityminded.net] has joined #i2p
14:18 -!- cat-a-puss [~tom@152.228.242.159] has joined #i2p
14:19 < jrandom> once 0.4.1.2 is outi'll probably nag some more people to gather various stats at times
14:19 < deer> <mule_iip> you're welcome
14:19 < cervantes> I'm happy to start collecting now... I'm already on 0.4.1.1-6
14:20 < jrandom> w3wt
14:21 < jrandom> ok, thats all i've got for the stats, unless anyone has anything to add?
14:21 < jrandom> if not, 3) 0.4.1.2 and 0.4.2
14:21 < deer> <baffled> You have my vote for streaming first.
14:22 < jrandom> cool
14:22 < jrandom> does anyone think we should keep the tunnel mods first?
14:22 < deer> <mule_iip> streaming first
14:23 < cervantes> doing the tunnel stuff now would likely cause more network distruption....it's probably good to have a breather ;-)
14:23 < jrandom> true
14:23 < deer> <mule_iip> all of those here today have been identified by the black hats anyhow :)
14:23 < jrandom> though i was thinking the other day about how we could do the tunnel mods without incompatabilities
14:23 < deer> <baffled> Comeon admit it, you just want to get your audio p0rn faster.
14:23 < duck> (me too on streaming first)
14:23 < jrandom> hehe
14:24 < cervantes> hehe
14:24 < cervantes> baffled: only if you source more of it ;-)
14:24 < dm> I think we should stick to the tunnel stuff first
14:24 < dm> get it out of the way...
14:24 < cat-a-puss> how is the new encryption stuff going to be different?
14:24 * jrandom kicks dm
14:25 < jrandom> cat-a-puss: right now, we have blanket tunnel encryption - messages passed within the same tunnel look the same at each hop
14:25 < deer> <baffled> I think I can get a bit more.
14:25 < cat-a-puss> oh!
14:26 < cervantes> http://www.i2p.net/todo#tunnelId
14:26 < jrandom> it isn't so bad since an alice-->bob message goes through two tunnels with different encryption, but it does b0rk us for colluding attackers
14:27 < jrandom> the per-hop tunnelId stuff is also necessary to keep harvesting from messing with predecessors (/etc)
14:27 < dm> Yeah, we should definitely fix that first.
14:27 < deer> <mule_iip> i vote for dm to do it
14:28 < deer> <fidd> did i miss the meeting? ;)
14:28 < jrandom> i was just about to suggest that mule :)
14:28 < cervantes> I vote for dm not to have anything to do with it
14:28 < jrandom> heh
14:28 < jrandom> nope fidd, we're on item 3 of the agenda
14:29 < jrandom> ok, if there are no objections to dm's suggestion (other than his own), i think we'll go ahead and move the streaming lib updates to 0.4.2
14:29 < dm> sweet
14:30 < jrandom> ok, moving on to 4) Bundled eepserver
14:30 < jrandom> if you haven't noticed, there's a bundled eepserver.
14:30 < cervantes> "just put the war files in the webapps directory and you're ready to go"
14:30 < jrandom> heh
14:30 < jrandom> for sufficiently well coded .war files :)
14:31 < cervantes> ooh does such a think exist?
14:31 < cervantes> *thing
14:31 < jrandom> but from a practical perspective, "just edit ./eepsite/docroot/index.html"
14:31 < deer> <baffled> One question I have is are you wishing people would use the eepserver or use a standard httpd server?
14:31 < cat-a-puss> do the ones generated by kde work?
14:31 < jrandom> cervantes: phttprelay.war, i2ptunnel.war, routerconsole.war :)
14:31 < dm> ah yes.. war. One of those J2EE things that requires 20 years experience at manually editing xml files.
14:31 < cervantes> touche
14:32 < jrandom> baffled: i really don't care. if people have a webserver installed that can accept requests from kooky Host: lines, great
14:32 < jrandom> the eepserver is just for convenience
14:32 < jrandom> cat-a-puss: hmm, kde .war files?
14:32 < protok0l> monoculture... monoculture...
14:33 < deer> <duck> when playing with wars, I miss the feature to only restart jetty; which is unfortunately needed for a lot of deployment stuff
14:33 < cat-a-puss> yeah, you need kdeaddons installed, just go to a webpage and then click archive and it makes a .war file
14:34 < jrandom> duck: ah, thats true. simply pull out the lines starting the eepserver from clients.config and put them into a shell script
14:34 < jrandom> (with the same classpath as the router)
14:34 < dm> can we integrate i2p into jboss and bundle that before 1.0?
14:34 < jrandom> ooh, cool cat-a-puss
14:35 < cervantes> I take it the missing webdefault.xml has been fixed in cvs?
14:35 < deer> <detonate> actually, jetty.xml has
14:35 < jrandom> find us a compelling .ear dm :)
14:35 < jrandom> cervantes: what detonate said. (i messed up the jetty.xml)
14:36 < cervantes> yup... think I mentioned somewhere about removing the reference in the jetty.xml so it uses it the one inside the jetty archive
14:36 < jrandom> wr0d
14:37 < cervantes> just wanted to check that's been fixed in cvs ;-)
14:37 < jrandom> si sr
14:37 < cervantes> cool
14:37 < jrandom> (though the 0.4.1.2 release update will not overwrite people's eepsite)
14:37 < jrandom> ((0.4.1.2+ clean installs will of course include it though))
14:38 < cervantes> oh and did we discover the cause of DrWoo's missing eepsite keys?
14:38 < jrandom> actually, on that note, i just want to mention that everyone should upgrade whenever there is a new release, as if you don't, you might not have an upgrade procedure
14:38 < jrandom> no cervantes, nor a reproducable bug :/
14:39 < cervantes> ah good we can blame user error ;-)
14:39 < deer> <DrWoo> cervantes: almost certainly something klutzy I did
14:39 < cervantes> :o)
14:39 * jrandom blames the gremlins
14:40 < deer> <Jake> http://en.wikipedia.org/wiki/User:Kmweber/List_of_Everyone_Who_Has_Ever_Lived
14:40 < jrandom> ok, moving on to 5) ???
14:40 < jrandom> heh
14:40 < jrandom> well, yes, that certainly qualifies as "other"
14:40 < jrandom> anyone have anything they want to bring up?
14:41 < dm> I'd like to put forward, at this point, that I am pleased with the new outlook the I2P community is showing towards my suggestions.
14:41 < dm> Kind Regards
14:41 < cat-a-puss> oh oh pick me! I have the base code for a distrubuted search.
14:41 < deer> <demonic_1> yea why do i2p after running 30 + hours go up to 100% cpu
14:41 < dm> dm
14:41 < deer> <Jake> yes, i want to bring up the issue of encryption inheritence based on 4th order gamal fractal equations and how it would apply to i2p
14:41 < deer> <demonic_1> and most of it system?
14:41 < jrandom> ooh kickass cat-a-puss!
14:41 < cat-a-puss> I anounced it here the other day, nobody noticed
14:41 < deer> <baffled> only tangentially jake.
14:42 < cat-a-puss> anyway, could use come cvs space
14:42 < deer> <DrWoo> cat-a-puss: do you have an eepsite for that?
14:42 < jrandom> demonic_1: hmm, there have been some critical bugs in the last release or two. are you on 0.4.1.1?
14:42 < cat-a-puss> and I can start testing in about 2 weeks
14:42 < cat-a-puss> DrWoo: nope
14:42 < deer> <Jake> baffled, HaH !
14:43 < deer> <demonic_1> 0.4.1.1-3
14:43 < jrandom> cat-a-puss: r0x0r, not a problem. bounce me an email with the name of the module you'd like it called & your pgp key and we'll get something sorted
14:44 < cat-a-puss> jrandom: alright
14:44 < jrandom> cat-a-puss: what sort of searching does it do?
14:44 < jrandom> demonic_1: did it consume that much CPU prior to 0.4.1?
14:44 < cervantes> (proxies to MSN)
14:44 < deer> <mule_iip> demonic_1: and you get 1 meg of log every minute? sounds familiar.
14:45 < deer> <demonic_1> no
14:45 < jrandom> heh mule, yeah the bug you found was a nasty fast-busy
14:45 < cat-a-puss> jrandom: it's basic keywork search, you need to specify the words to index under, and it will store the URL
14:45 < jrandom> demonic is more likely being hit by one of the NPEs in the tcp.ConnectionBuilder
14:46 < deer> <baffled> Well, it's dindin time so I'll go hunt up some more slut sounds in preparation for the streaming updates and chat with you all anon.
14:46 < cat-a-puss> jrandom: It should eventualy scale well, and all that jazz, but right now, all the servers need to be connected and nobody can join or leave, and there is no way to insert content yet, but all that will get fixed
14:46 < jrandom> ah cool, does it work with a distributed db, or is it more of a search-against-spidered?
14:47 < jrandom> ok cool
14:47 < cervantes> later baffled
14:47 < jrandom> lol, ttyl baffled
14:47 < cervantes> baffled: how do we know they're slut sounds, and not you on the end of your microphone?
14:47 < protok0l> ALL RIGHT!
14:47 < protok0l> i2p works again
14:47 < jrandom> w3wt
14:48 < jrandom> what was wrong?
14:49 < jrandom> ok, anyone else have anything they want to bring up for the meeting?
14:49 < deer> <Jake> can announce i2p to slashdot after the new streaming protocol is implemented ?
14:49 < dm> preferably before
14:49 < dm> but after will do
14:49 < jrandom> !thwap^2
14:50 < protok0l> POSTMAN!
14:50 < jrandom> ok, if there's nothing else..
14:50 * jrandom winds up
14:51 < deer> * Jake kisses jrandom
14:51 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/110.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, October 5, 2004
================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,201 +1,195 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 111{% endblock %}
{% block content %}<h3>I2P dev meeting, October 12, 2004</h3>
<div class="irclog">
14:04 < jrandom> 0) hi</p>
14:04 < jrandom> 1) 0.4.1.2</p>
14:04 < jrandom> 2) 0.4.1.3</p>
14:05 < jrandom> 3) 0.4.2</p>
14:05 < jrandom> 4) mail discussions</p>
14:05 < jrandom> 5) ???</p>
14:05 < jrandom> 0) hi</p>
14:05 * jrandom waves</p>
14:05 < Janonymous> hello</p>
14:05 < jrandom> lots of #s in our agenda this week</p>
14:05 < jrandom> weekly status notes up @ http://i2p.net/pipermail/i2p/2004-October/000466.html</p>
14:05 < jrandom> (posted a min or three ago)</p>
14:05 < deer> * cervantes has brought a pillow</p>
14:06 < jrandom> oh i hope it won't be that boring ;)</p>
14:06 < jrandom> anyway, jumping on in to the good stuff: 1) 0.4.1.2</p>
14:06 < deer> &lt;cervantes&gt; make me up after the statistal analysis section</p>
14:06 < jrandom> the release is out and everyone should upgrade</p>
14:06 < jrandom> heh</p>
14:06 < deer> &lt;cervantes&gt; eerm wake</p>
14:07 < jrandom> there are some bugs with the watchdog code, which will kill your router poorly (rather than restart it when bad stuff happens)</p>
14:07 < jrandom> but hopefully those situations are few and far between</p>
14:07 < deer> &lt;mule_iip&gt; nope :(</p>
14:08 < jrandom> well, it varies by the user</p>
14:08 < jrandom> i'm trying to find the cause, as its been around forever and its pretty annoying</p>
14:08 < jrandom> (the actual hang, not the watchdog code that detects the hang)</p>
14:09 < jrandom> the current CVS rev (0.4.1.2-1) has the 'meat' of the watchdog disabled - it monitors, but oesn't shut down the router</p>
14:10 < jrandom> but 0.4.1.2 should be fine for everyone (except mule ;)</p>
14:10 < jrandom> oh, as mentioned before, start up some logging and send me some data, per http://dev.i2p.net/pipermail/i2p/2004-October/000465.html</p>
14:11 < jrandom> the more data the better - if you can leave it running overnight, that'd be great (a 20h run on duck's box generated ~60MB of data)</p>
14:11 < jrandom> ok, moving on to 2) 0.4.1.3</p>
14:12 < jrandom> well, there's not really anything i want to mention beyond wahts in the email</p>
14:12 < jrandom> anyone have anything they want to say re: 0.4.1.3?</p>
14:12 < Janonymous> nah</p>
14:13 < deer> &lt;postman&gt; no</p>
14:13 < Janonymous> backwards compatable?</p>
14:13 < jrandom> certainly</p>
14:13 < jrandom> ok, moving on to * 3) 0.4.2</p>
14:14 < jrandom> again, another "see the email" :)</p>
14:14 < Janonymous> xpc vs. tcp ??</p>
14:14 < jrandom> i've never implemented a tcp stack before, so any guidance would be appreciated</p>
14:15 < jrandom> xcp has better handling in networks with high delays</p>
14:15 < jrandom> (for congestion control)</p>
14:15 < Janonymous> does that include fec?</p>
14:15 < jrandom> no</p>
14:16 < Janonymous> k, cause I've been researching that some</p>
14:17 < jrandom> cool</p>
14:17 < jrandom> anything good you've found?</p>
14:17 < deer> &lt;cervantes&gt; most GET requests are sub 32kb...and your average html page should be around that size...so I'd imagine eepsurfing will be much improved... - I wouldn't mind seeing an improvement in per-tunnel throughput though...will the new stack improve upon that?</p>
14:17 < Janonymous> fec is used a lot for high latency/high throughput networks</p>
14:18 < deer> &lt;mule_iip&gt; jrandom: nor have i, but i could tell a folk here to support you</p>
14:18 < Janonymous> jrandom: some.. I'll report back</p>
14:18 < deer> &lt;mule_iip&gt; at least it would be a good learning experience for him and another pair of eyes</p>
14:18 < jrandom> great Janonymous </p>
14:18 < jrandom> oh kickass mule</p>
14:18 < jrandom> cervantes: per-tunnel throughput would improve with &gt;1 message windows</p>
14:19 < jrandom> (i expect we'll be able to even start with &gt;1 as a window size, depending upon what we can gleam from the router)</p>
14:19 < jrandom> ((ecn++))</p>
14:19 < deer> &lt;cervantes&gt; grand</p>
14:20 < jrandom> ok, anything else on 0.4.2 stuff?</p>
14:20 < Janonymous> fresh stack.. fresh laptop.. *drools*</p>
14:21 < jrandom> heh</p>
14:21 < Janonymous> yea</p>
14:21 < Janonymous> one thing</p>
14:22 < Janonymous> this will implement the new short handshake?</p>
14:22 < jrandom> hmm?</p>
14:22 < jrandom> we have the low-cpu TCP reconnection code in the 0.4.1 transport</p>
14:22 < Janonymous> ah, in the email, you mention the alice-&gt; bob handshake</p>
14:23 < Janonymous> ah</p>
14:23 < Janonymous> still catching up</p>
14:23 < jrandom> oh. yeah, whatever 0.4.2 comes up with, it'll support a packet sequence like the one in the email</p>
14:24 < Janonymous> k</p>
14:24 < jrandom> we'll probably control it largely through socket options (e.g. set the stream to interactive and it sends asap, set the stream to bulk and it only sends when the buffer is full or itsflushed [or it needs to ack])</p>
14:25 < jrandom> ok, swinging on to 4) mail discussion</p>
14:25 < jrandom> postman - you 'round?</p>
14:26 < deer> &lt;postman&gt; ya</p>
14:26 < jrandom> word, wanna give us a run down / update wrt the mail stuff?</p>
14:27 < deer> &lt;postman&gt; hmm, ok tho i am quite shy talking in front of that many ppl :)</p>
14:27 < jrandom> heh just imagine we're all nak^H^H^Her... nm</p>
14:28 * Janonymous gets popcorn out</p>
14:28 < deer> &lt;postman&gt; since the 20th od september there is a SMTP/POP Service running - accessible with normal smtp/pop3 MUAs</p>
14:29 < deer> &lt;postman&gt; i put quite some efforts in it in a way that i analyzed the potential risks that normal mail clients bear</p>
14:29 < Janonymous> what about inproxies/outproxies?</p>
14:29 < deer> &lt;postman&gt; put it all together on a website </p>
14:29 < deer> &lt;postman&gt; for those who haven't done so: www.postman.i2p</p>
14:29 * Janonymous has not access to the network currently</p>
14:30 < deer> &lt;postman&gt; there's a proposal on the website that tries to comprehend all the common problems dealing with anonymity and reliability of a mailservice when doing a bridging between i2p and internet</p>
14:30 < deer> &lt;postman&gt; out/inproxy does not run yet but is in the planning</p>
14:30 < Janonymous> I think I caught some of the discussion on the maillist or the forum</p>
14:30 < Janonymous> out would be more dangerous than in, right?</p>
14:31 < deer> &lt;postman&gt; first i want a commonly accepted concept</p>
14:31 < deer> &lt;postman&gt; generally YES, but i think we found a way that spam and the likes won't be sent outward</p>
14:31 < jrandom> what'd be neat is if the mx.postman.i2p in/outproxy could dispatch to different (or multiple redundant) pop3 accts</p>
14:31 < deer> &lt;postman&gt; simply by putting a quota on every user trying to send mails out</p>
14:32 < jrandom> (that way it wouldn't be tied to a particular mailhost)</p>
14:32 < deer> &lt;postman&gt; jrandom2p: please explain further</p>
14:33 < Janonymous> could the seperate mailhosts be syncronized too?</p>
14:33 < deer> &lt;postman&gt; jrandom2p: it's a question of account based routing</p>
14:33 < jrandom> right postman</p>
14:33 < jrandom> probably lots of work, i dont know much about the MTAs you're working on</p>
14:33 < deer> &lt;postman&gt; jrandom2p: the out/in proxy could easily handle more than one internal mailsystem - even could arrange a fallback kind of delivery </p>
14:34 < jrandom> 'k, great</p>
14:34 < Janonymous> Q wrt in/out</p>
14:34 < deer> &lt;postman&gt; janonymous: i did not understand your question - please explain</p>
14:34 * jrandom dreams up uucp-style offline fetch from mx.postman :)</p>
14:35 < Janonymous> would mandatory mailbox to mailbox encryption make in/out sending less dangerous?</p>
14:35 < deer> &lt;postman&gt; jrandom: haha, uucp is not needed i think - maybe ETRN is sexier :)</p>
14:35 < deer> &lt;postman&gt; janonymous: right now the system works only internaly - everyone is free to apply PGP or sth similiar</p>
14:36 < jrandom> Janonymous: you should swing by www.postman.i2p - he's put up a chunk of ideas / issues on there</p>
14:36 < Janonymous> mandatory encryption/signatures is also an antispam method I believe</p>
14:36 < deer> &lt;Ragnarok&gt; would it be possible to serve the postman.i2p address book using LDAP?</p>
14:36 < Janonymous> I will once my laptop comes in</p>
14:37 < deer> &lt;postman&gt; rag: there's an addressbook already - it is based on SQL tho - a transfer to LDAP os possible</p>
14:38 < Janonymous> = server hosted address book?</p>
14:38 < deer> * postman invites everybody to contribute own ideas to the ideas/concepts html document</p>
14:38 < Janonymous> will do postman</p>
14:38 < deer> * cervantes spiders the address book and starts writing penis enlargement pharmacutical mails </p>
14:39 < deer> &lt;postman&gt; janonymous: well, ALL mailusers are SQL based - thus the "addressbook" is just a view on that table</p>
14:39 < deer> &lt;postman&gt; cervantes: btw, every user can chose whether he wants to be visible or not</p>
14:39 < Janonymous> ah</p>
14:40 < Janonymous> how about selective groups ;)</p>
14:40 < deer> &lt;cervantes&gt; postman: yup I've signed up already ;-)</p>
14:40 < deer> &lt;postman&gt; cervantes: and since we HAVE a mailidentidy system , you cannot forge your senderaddress - we know it has been YOU :)</p>
14:40 < deer> &lt;postman&gt; janonymous: yeah, it's planned for version 2.0 :)</p>
14:41 < deer> &lt;cervantes&gt; postman: but I'll just spam every ircnym@postman.i2p ;-)</p>
14:41 < deer> &lt;postman&gt; cervantes: this is technically possible, yes :)</p>
14:42 < deer> &lt;postman&gt; cervantes: i hope you're able to deliver those pills too :)</p>
14:42 < Janonymous> sounds like a much needed and long expected development for i2p</p>
14:42 < Janonymous> the new email system</p>
14:42 < deer> &lt;cervantes&gt; postman: and on the sender thing..the "Cervantes' penis enlargement elixir" would indicate the sender too :)</p>
14:42 < deer> &lt;postman&gt; janonyous: i cannot tell about every detail implemented</p>
14:43 < deer> &lt;postman&gt; jan: the website is best suited for this</p>
14:43 < deer> &lt;postman&gt; cervantes: indeed - but this could be forged :)</p>
14:43 < Janonymous> alrighty.. I'll get there asap</p>
14:43 < jrandom> ok, great. so, yeah, y'all should review whats up on www.postman.i2p and send in your ideas/comments</p>
14:43 < deer> * postman nods and sits down again</p>
14:44 < jrandom> (postman++)</p>
14:44 < jrandom> ok that brings us to 5) ???</p>
14:44 < jrandom> anyone have anything else they want to bring up?</p>
14:44 < jrandom> (i2p related)</p>
14:44 < deer> &lt;postman&gt; :)</p>
14:44 < Janonymous> just a thought</p>
14:45 < Janonymous> possible uses for I2P.. we know its a "distributed anonymous network layer"</p>
14:45 < deer> &lt;Jake&gt; my node is down :( moving equipment to a different part of the house</p>
14:46 < Janonymous> but what can that be used for.. particularly, those "common good" issues</p>
14:46 < Janonymous> Oppressive third world countries, freedom of speech.. etc.. thats one of the primary things that got me so interested in i2p to start with</p>
14:47 < Janonymous> and freenet for that matter</p>
14:47 < deer> &lt;Jake&gt; oppressed 1st world countries like the u.s.</p>
14:47 < Janonymous> so, I thought maybe some extrapolation on those issues, maybe starting on the forum, then some words on the site</p>
14:48 < jrandom> we've got a lot of work to do before we can claim any relevence for people in china</p>
14:48 < Janonymous> heh, yea, wouldn't want to make any false promises, but..</p>
14:48 * jrandom will not say we're safe when there has been so little peer review (and there are still so many outstanding issues)</p>
14:49 < deer> &lt;fidd&gt; how hard will it be for china to censor i2p?</p>
14:49 < deer> &lt;cervantes&gt; I think applications will begin to surface more readily once the underlying network has stopped "shapeshifting"</p>
14:49 < Janonymous> but those issues to me are one of the main things that makes i2p so exciting</p>
14:49 < jrandom> fidd: censor has many definitions. in the sense "stop specific content from being transferred", pretty much impossible, short of making i2p illegal</p>
14:50 < Janonymous> how about, "detect i2p on networks in china"</p>
14:50 < Janonymous> stego?</p>
14:51 < jrandom> exciting, yes. important? yes. necessary? yes. but since there's so much work to do before we're relevent, its just depressing to talk about it.</p>
14:51 < Janonymous> my bad :) </p>
14:51 < deer> &lt;cervantes&gt; once the base network is solid, then we could probably do with some nice toys to play with - eg filesharing apps, IM systems etc. Hopefully the userbase will swell at that point....before this happens there just won't be enough peers to guarantee anonymity for people who live in oppressive systems</p>
14:52 < jrandom> its always important to keep your eyes on the real goals Janonymous, and i appreciate that</p>
14:52 < Janonymous> yea, numbers of nodes has a lot to do with it</p>
14:52 < modulus> imo until there is stego and things like random noise to defeat traffic analysis people in oppressive countries should stay away for a while.</p>
14:53 < deer> &lt;cervantes&gt; no..they should stay here and help :)</p>
14:53 < modulus> :-)</p>
14:53 * jrandom will not describe in detail why those aspects won't be necessary, as the 3.0 rev will take care of 'em :)</p>
14:53 < modulus> 3.0? sounds long-term ;-)</p>
14:53 < jrandom> i have ~= 0 faith in stego transports for public networks</p>
14:54 < jrandom> it aint tomorrow, thats for sure.</p>
14:54 < Janonymous> word? huh</p>
14:54 < Janonymous> jrandom: whys that (wrt stego)?</p>
14:55 < jrandom> how to defeat stego on public networks with open source software: download the source, review the stego generation code, write detection code, deploy.</p>
14:56 < jrandom> how to defeat stego on public networks with closed source software: kidnap the dev's family, subvert the code. deploy.</p>
14:56 < Janonymous> ah.. yea.. random inputs? eh.. I just read this article talking like it was the future or something</p>
14:56 < jrandom> how to defeat stego on private networks: laugh at the 5 people using it, and arrest 'em all.</p>
14:56 < modulus> well, what about anonymous closed-source software? of course it could be a trojan ;-)</p>
14:57 < deer> &lt;Jake&gt; jrandom: if you're ever kidnapped, you can let us know by telling us "my dog fido is really upset about the food he's eating today"</p>
14:57 < deer> &lt;Jake&gt; that will be the giveaway and we'll know</p>
14:57 < deer> &lt;cervantes&gt; %s!dev's family!jrandom</p>
14:57 < jrandom> heh jake</p>
14:58 < Janonymous> whens the eta for 4.2?</p>
14:58 < jrandom> Janonymous: the #1 feature of anonymity or security software: snake oil.</p>
14:58 < jrandom> 0.4.2? sometime this month</p>
14:58 < jrandom> prolly near the end</p>
14:58 < Janonymous> heheh. </p>
14:58 < jrandom> 0.4.1.3 will prolly be out later this week or the weekend</p>
14:58 < deer> &lt;cervantes&gt; Jake: that would never work, we'll juist think you've poisoned his dog</p>
14:58 < deer> &lt;cervantes&gt; *just</p>
14:58 < Janonymous> I should be back on the net in a week or two</p>
14:59 < jrandom> r0x0r</p>
14:59 < jrandom> ok, anyone else have something to bring up?</p>
14:59 < deer> &lt;Jake&gt; cervantes :)</p>
15:00 < jrandom> if not..</p>
15:00 * jrandom winds up</p>
15:00 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
14:04 < jrandom> 0) hi
14:04 < jrandom> 1) 0.4.1.2
14:04 < jrandom> 2) 0.4.1.3
14:05 < jrandom> 3) 0.4.2
14:05 < jrandom> 4) mail discussions
14:05 < jrandom> 5) ???
14:05 < jrandom> 0) hi
14:05 * jrandom waves
14:05 < Janonymous> hello
14:05 < jrandom> lots of #s in our agenda this week
14:05 < jrandom> weekly status notes up @ http://i2p.net/pipermail/i2p/2004-October/000466.html
14:05 < jrandom> (posted a min or three ago)
14:05 < deer> * cervantes has brought a pillow
14:06 < jrandom> oh i hope it won't be that boring ;)
14:06 < jrandom> anyway, jumping on in to the good stuff: 1) 0.4.1.2
14:06 < deer> <cervantes> make me up after the statistal analysis section
14:06 < jrandom> the release is out and everyone should upgrade
14:06 < jrandom> heh
14:06 < deer> <cervantes> eerm wake
14:07 < jrandom> there are some bugs with the watchdog code, which will kill your router poorly (rather than restart it when bad stuff happens)
14:07 < jrandom> but hopefully those situations are few and far between
14:07 < deer> <mule_iip> nope :(
14:08 < jrandom> well, it varies by the user
14:08 < jrandom> i'm trying to find the cause, as its been around forever and its pretty annoying
14:08 < jrandom> (the actual hang, not the watchdog code that detects the hang)
14:09 < jrandom> the current CVS rev (0.4.1.2-1) has the 'meat' of the watchdog disabled - it monitors, but oesn't shut down the router
14:10 < jrandom> but 0.4.1.2 should be fine for everyone (except mule ;)
14:10 < jrandom> oh, as mentioned before, start up some logging and send me some data, per http://dev.i2p.net/pipermail/i2p/2004-October/000465.html
14:11 < jrandom> the more data the better - if you can leave it running overnight, that'd be great (a 20h run on duck's box generated ~60MB of data)
14:11 < jrandom> ok, moving on to 2) 0.4.1.3
14:12 < jrandom> well, there's not really anything i want to mention beyond wahts in the email
14:12 < jrandom> anyone have anything they want to say re: 0.4.1.3?
14:12 < Janonymous> nah
14:13 < deer> <postman> no
14:13 < Janonymous> backwards compatable?
14:13 < jrandom> certainly
14:13 < jrandom> ok, moving on to * 3) 0.4.2
14:14 < jrandom> again, another "see the email" :)
14:14 < Janonymous> xpc vs. tcp ??
14:14 < jrandom> i've never implemented a tcp stack before, so any guidance would be appreciated
14:15 < jrandom> xcp has better handling in networks with high delays
14:15 < jrandom> (for congestion control)
14:15 < Janonymous> does that include fec?
14:15 < jrandom> no
14:16 < Janonymous> k, cause I've been researching that some
14:17 < jrandom> cool
14:17 < jrandom> anything good you've found?
14:17 < deer> <cervantes> most GET requests are sub 32kb...and your average html page should be around that size...so I'd imagine eepsurfing will be much improved... - I wouldn't mind seeing an improvement in per-tunnel throughput though...will the new stack improve upon that?
14:17 < Janonymous> fec is used a lot for high latency/high throughput networks
14:18 < deer> <mule_iip> jrandom: nor have i, but i could tell a folk here to support you
14:18 < Janonymous> jrandom: some.. I'll report back
14:18 < deer> <mule_iip> at least it would be a good learning experience for him and another pair of eyes
14:18 < jrandom> great Janonymous
14:18 < jrandom> oh kickass mule
14:18 < jrandom> cervantes: per-tunnel throughput would improve with >1 message windows
14:19 < jrandom> (i expect we'll be able to even start with >1 as a window size, depending upon what we can gleam from the router)
14:19 < jrandom> ((ecn++))
14:19 < deer> <cervantes> grand
14:20 < jrandom> ok, anything else on 0.4.2 stuff?
14:20 < Janonymous> fresh stack.. fresh laptop.. *drools*
14:21 < jrandom> heh
14:21 < Janonymous> yea
14:21 < Janonymous> one thing
14:22 < Janonymous> this will implement the new short handshake?
14:22 < jrandom> hmm?
14:22 < jrandom> we have the low-cpu TCP reconnection code in the 0.4.1 transport
14:22 < Janonymous> ah, in the email, you mention the alice-> bob handshake
14:23 < Janonymous> ah
14:23 < Janonymous> still catching up
14:23 < jrandom> oh. yeah, whatever 0.4.2 comes up with, it'll support a packet sequence like the one in the email
14:24 < Janonymous> k
14:24 < jrandom> we'll probably control it largely through socket options (e.g. set the stream to interactive and it sends asap, set the stream to bulk and it only sends when the buffer is full or itsflushed [or it needs to ack])
14:25 < jrandom> ok, swinging on to 4) mail discussion
14:25 < jrandom> postman - you 'round?
14:26 < deer> <postman> ya
14:26 < jrandom> word, wanna give us a run down / update wrt the mail stuff?
14:27 < deer> <postman> hmm, ok tho i am quite shy talking in front of that many ppl :)
14:27 < jrandom> heh just imagine we're all nak^H^H^Her... nm
14:28 * Janonymous gets popcorn out
14:28 < deer> <postman> since the 20th od september there is a SMTP/POP Service running - accessible with normal smtp/pop3 MUAs
14:29 < deer> <postman> i put quite some efforts in it in a way that i analyzed the potential risks that normal mail clients bear
14:29 < Janonymous> what about inproxies/outproxies?
14:29 < deer> <postman> put it all together on a website
14:29 < deer> <postman> for those who haven't done so: www.postman.i2p
14:29 * Janonymous has not access to the network currently
14:30 < deer> <postman> there's a proposal on the website that tries to comprehend all the common problems dealing with anonymity and reliability of a mailservice when doing a bridging between i2p and internet
14:30 < deer> <postman> out/inproxy does not run yet but is in the planning
14:30 < Janonymous> I think I caught some of the discussion on the maillist or the forum
14:30 < Janonymous> out would be more dangerous than in, right?
14:31 < deer> <postman> first i want a commonly accepted concept
14:31 < deer> <postman> generally YES, but i think we found a way that spam and the likes won't be sent outward
14:31 < jrandom> what'd be neat is if the mx.postman.i2p in/outproxy could dispatch to different (or multiple redundant) pop3 accts
14:31 < deer> <postman> simply by putting a quota on every user trying to send mails out
14:32 < jrandom> (that way it wouldn't be tied to a particular mailhost)
14:32 < deer> <postman> jrandom2p: please explain further
14:33 < Janonymous> could the seperate mailhosts be syncronized too?
14:33 < deer> <postman> jrandom2p: it's a question of account based routing
14:33 < jrandom> right postman
14:33 < jrandom> probably lots of work, i dont know much about the MTAs you're working on
14:33 < deer> <postman> jrandom2p: the out/in proxy could easily handle more than one internal mailsystem - even could arrange a fallback kind of delivery
14:34 < jrandom> 'k, great
14:34 < Janonymous> Q wrt in/out
14:34 < deer> <postman> janonymous: i did not understand your question - please explain
14:34 * jrandom dreams up uucp-style offline fetch from mx.postman :)
14:35 < Janonymous> would mandatory mailbox to mailbox encryption make in/out sending less dangerous?
14:35 < deer> <postman> jrandom: haha, uucp is not needed i think - maybe ETRN is sexier :)
14:35 < deer> <postman> janonymous: right now the system works only internaly - everyone is free to apply PGP or sth similiar
14:36 < jrandom> Janonymous: you should swing by www.postman.i2p - he's put up a chunk of ideas / issues on there
14:36 < Janonymous> mandatory encryption/signatures is also an antispam method I believe
14:36 < deer> <Ragnarok> would it be possible to serve the postman.i2p address book using LDAP?
14:36 < Janonymous> I will once my laptop comes in
14:37 < deer> <postman> rag: there's an addressbook already - it is based on SQL tho - a transfer to LDAP os possible
14:38 < Janonymous> = server hosted address book?
14:38 < deer> * postman invites everybody to contribute own ideas to the ideas/concepts html document
14:38 < Janonymous> will do postman
14:38 < deer> * cervantes spiders the address book and starts writing penis enlargement pharmacutical mails
14:39 < deer> <postman> janonymous: well, ALL mailusers are SQL based - thus the "addressbook" is just a view on that table
14:39 < deer> <postman> cervantes: btw, every user can chose whether he wants to be visible or not
14:39 < Janonymous> ah
14:40 < Janonymous> how about selective groups ;)
14:40 < deer> <cervantes> postman: yup I've signed up already ;-)
14:40 < deer> <postman> cervantes: and since we HAVE a mailidentidy system , you cannot forge your senderaddress - we know it has been YOU :)
14:40 < deer> <postman> janonymous: yeah, it's planned for version 2.0 :)
14:41 < deer> <cervantes> postman: but I'll just spam every ircnym@postman.i2p ;-)
14:41 < deer> <postman> cervantes: this is technically possible, yes :)
14:42 < deer> <postman> cervantes: i hope you're able to deliver those pills too :)
14:42 < Janonymous> sounds like a much needed and long expected development for i2p
14:42 < Janonymous> the new email system
14:42 < deer> <cervantes> postman: and on the sender thing..the "Cervantes' penis enlargement elixir" would indicate the sender too :)
14:42 < deer> <postman> janonyous: i cannot tell about every detail implemented
14:43 < deer> <postman> jan: the website is best suited for this
14:43 < deer> <postman> cervantes: indeed - but this could be forged :)
14:43 < Janonymous> alrighty.. I'll get there asap
14:43 < jrandom> ok, great. so, yeah, y'all should review whats up on www.postman.i2p and send in your ideas/comments
14:43 < deer> * postman nods and sits down again
14:44 < jrandom> (postman++)
14:44 < jrandom> ok that brings us to 5) ???
14:44 < jrandom> anyone have anything else they want to bring up?
14:44 < jrandom> (i2p related)
14:44 < deer> <postman> :)
14:44 < Janonymous> just a thought
14:45 < Janonymous> possible uses for I2P.. we know its a "distributed anonymous network layer"
14:45 < deer> <Jake> my node is down :( moving equipment to a different part of the house
14:46 < Janonymous> but what can that be used for.. particularly, those "common good" issues
14:46 < Janonymous> Oppressive third world countries, freedom of speech.. etc.. thats one of the primary things that got me so interested in i2p to start with
14:47 < Janonymous> and freenet for that matter
14:47 < deer> <Jake> oppressed 1st world countries like the u.s.
14:47 < Janonymous> so, I thought maybe some extrapolation on those issues, maybe starting on the forum, then some words on the site
14:48 < jrandom> we've got a lot of work to do before we can claim any relevence for people in china
14:48 < Janonymous> heh, yea, wouldn't want to make any false promises, but..
14:48 * jrandom will not say we're safe when there has been so little peer review (and there are still so many outstanding issues)
14:49 < deer> <fidd> how hard will it be for china to censor i2p?
14:49 < deer> <cervantes> I think applications will begin to surface more readily once the underlying network has stopped "shapeshifting"
14:49 < Janonymous> but those issues to me are one of the main things that makes i2p so exciting
14:49 < jrandom> fidd: censor has many definitions. in the sense "stop specific content from being transferred", pretty much impossible, short of making i2p illegal
14:50 < Janonymous> how about, "detect i2p on networks in china"
14:50 < Janonymous> stego?
14:51 < jrandom> exciting, yes. important? yes. necessary? yes. but since there's so much work to do before we're relevent, its just depressing to talk about it.
14:51 < Janonymous> my bad :)
14:51 < deer> <cervantes> once the base network is solid, then we could probably do with some nice toys to play with - eg filesharing apps, IM systems etc. Hopefully the userbase will swell at that point....before this happens there just won't be enough peers to guarantee anonymity for people who live in oppressive systems
14:52 < jrandom> its always important to keep your eyes on the real goals Janonymous, and i appreciate that
14:52 < Janonymous> yea, numbers of nodes has a lot to do with it
14:52 < modulus> imo until there is stego and things like random noise to defeat traffic analysis people in oppressive countries should stay away for a while.
14:53 < deer> <cervantes> no..they should stay here and help :)
14:53 < modulus> :-)
14:53 * jrandom will not describe in detail why those aspects won't be necessary, as the 3.0 rev will take care of 'em :)
14:53 < modulus> 3.0? sounds long-term ;-)
14:53 < jrandom> i have ~= 0 faith in stego transports for public networks
14:54 < jrandom> it aint tomorrow, thats for sure.
14:54 < Janonymous> word? huh
14:54 < Janonymous> jrandom: whys that (wrt stego)?
14:55 < jrandom> how to defeat stego on public networks with open source software: download the source, review the stego generation code, write detection code, deploy.
14:56 < jrandom> how to defeat stego on public networks with closed source software: kidnap the dev's family, subvert the code. deploy.
14:56 < Janonymous> ah.. yea.. random inputs? eh.. I just read this article talking like it was the future or something
14:56 < jrandom> how to defeat stego on private networks: laugh at the 5 people using it, and arrest 'em all.
14:56 < modulus> well, what about anonymous closed-source software? of course it could be a trojan ;-)
14:57 < deer> <Jake> jrandom: if you're ever kidnapped, you can let us know by telling us "my dog fido is really upset about the food he's eating today"
14:57 < deer> <Jake> that will be the giveaway and we'll know
14:57 < deer> <cervantes> %s!dev's family!jrandom
14:57 < jrandom> heh jake
14:58 < Janonymous> whens the eta for 4.2?
14:58 < jrandom> Janonymous: the #1 feature of anonymity or security software: snake oil.
14:58 < jrandom> 0.4.2? sometime this month
14:58 < jrandom> prolly near the end
14:58 < Janonymous> heheh.
14:58 < jrandom> 0.4.1.3 will prolly be out later this week or the weekend
14:58 < deer> <cervantes> Jake: that would never work, we'll juist think you've poisoned his dog
14:58 < deer> <cervantes> *just
14:58 < Janonymous> I should be back on the net in a week or two
14:59 < jrandom> r0x0r
14:59 < jrandom> ok, anyone else have something to bring up?
14:59 < deer> <Jake> cervantes :)
15:00 < jrandom> if not..
15:00 * jrandom winds up
15:00 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/111.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, October 12, 2004
=================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,272 +1,268 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 112{% endblock %}
{% block content %}<h3>I2P dev meeting, October 19, 2004</h3>
<div class="irclog">
14:03 < jrandom> 1) 0.4.1.3</p>
14:03 < jrandom> 2) Tunnel test time, and send processing time</p>
14:03 < jrandom> 3) Streaming lib</p>
14:03 < jrandom> 4) files.i2p</p>
14:03 < jrandom> 5) ???</p>
14:03 < jrandom> 0) hi</p>
14:03 * jrandom waves</p>
14:04 < modulus> hi hi</p>
14:04 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2004-October/000469.html</p>
14:04 < deer_> &lt;fidd&gt; howdy</p>
14:04 < jrandom> i didn't spend much time on the notes, so they're pretty brief</p>
14:05 < jrandom> but, c'est la vie</p>
14:05 < jrandom> moving on to 1) 0.4.1.3</p>
14:05 < jrandom> the release came out the other day and its been.. well... largely like before</p>
14:05 < jrandom> working good enough for most things, but not as reliable as we'd like</p>
14:06 < jrandom> throughput is still low, but thats a know issue to be dealt with in 0.4.2</p>
14:06 < jrandom> as mentioned in the email, I dont expect there to be any more 0.4.1.* releases</p>
14:07 < jrandom> I dont have much more to say on that - anyone have any comments / concerns?</p>
14:07 < deer_> &lt;newsbyte&gt; yes: what about the freeze-up?</p>
14:09 < jrandom> I'm not going to discount the possibility that your machine hung due to I2P, but I severely doubt it</p>
14:09 < jrandom> no one else has ever reported that happening on any platform</p>
14:09 < deer_> &lt;newsbyte&gt; well...it must be related to it somehow, if not directly, IMHO</p>
14:09 < deer_> &lt;newsbyte&gt; maybe the java?</p>
14:10 < jrandom> you're on 1.5 on w2k?</p>
14:10 < jrandom> or 1.4.2_05?</p>
14:10 < deer_> &lt;newsbyte&gt; nope, 1.5</p>
14:10 < jrandom> ok</p>
14:10 < deer_> &lt;newsbyte&gt; I can't exclude it's something else, ofcourse</p>
14:11 < deer_> &lt;newsbyte&gt; could be coincidence it happend two times</p>
14:11 < jrandom> well, we can discuss further how to find out the cause after the meeting if you'd like</p>
14:11 < deer_> &lt;newsbyte&gt; but the last time..I dunno...nothing much else was running, then</p>
14:11 < deer_> &lt;dinoman&gt; 1.5 on w2k works good for me :)</p>
14:11 < deer_> &lt;newsbyte&gt; indeed, though</p>
14:11 < deer_> &lt;newsbyte&gt; isn't there a simple debug log or something?</p>
14:11 < jrandom> if it happens again, please send me wrapper.log and logs/log-router-*.txt</p>
14:11 < deer_> &lt;newsbyte&gt; that might be usefull when it freezes</p>
14:11 < jrandom> there are more logs than dirt ;)</p>
14:12 < jrandom> ok cool dinoman</p>
14:12 < jrandom> perhaps it was some interaction with your software firewall</p>
14:12 < deer_> &lt;newsbyte&gt; maybe</p>
14:12 < jrandom> but, yeah,bounce me logs if it happens again</p>
14:12 < jrandom> (please :)</p>
14:12 < deer_> &lt;newsbyte&gt; well, that it would get blocked, I would understand</p>
14:12 < deer_> &lt;newsbyte&gt; but a total freeze...dunno...was creepy</p>
14:13 < deer_> &lt;newsbyte&gt; on the bright side: I've 27/63 now</p>
14:13 < jrandom> great</p>
14:13 < jrandom> ok, anyone else have any questions/comments/concerns with 0.4.1.3?</p>
14:13 < deer_> &lt;newsbyte&gt; I'll guees I'll ask Whoo to guide my through the eep thingy</p>
14:13 < deer_> &lt;dinoman&gt; just don't use it with Sygate Personal Firewall bad bad</p>
14:13 < deer_> &lt;newsbyte&gt; why?</p>
14:14 < deer_> &lt;dinoman&gt; crash</p>
14:14 < deer_> &lt;newsbyte&gt; yes; you forgot 6) profit!!</p>
14:14 < deer_> &lt;newsbyte&gt; ;-)</p>
14:14 < deer_> &lt;newsbyte&gt; crash?</p>
14:14 < deer_> &lt;newsbyte&gt; ermm</p>
14:14 < jrandom> dinoman: it crashes your OS? the firewall? I2P?</p>
14:14 < deer_> &lt;newsbyte&gt; well, wouldn't that explain it, then? ;-)</p>
14:15 < jrandom> newsbyte: are you running Sygate Personal Firewall?</p>
14:15 < deer_> &lt;newsbyte&gt; indeed</p>
14:15 < deer_> &lt;newsbyte&gt; well, not on my router</p>
14:15 < deer_> &lt;newsbyte&gt; but on the puter, yes</p>
14:15 < deer_> &lt;newsbyte&gt; seems we're on to something</p>
14:16 < deer_> &lt;DrWoo&gt; newsbyte: /join #i2p-chat so jrandom can get through his meeting</p>
14:16 < deer_> &lt;newsbyte&gt; though it doesn't crash/freeze immediately, apperently</p>
14:16 < deer_> &lt;dinoman&gt; os it crashes windows</p>
14:16 < deer_> &lt;newsbyte&gt; ?</p>
14:16 < deer_> &lt;newsbyte&gt; jrand is already here</p>
14:16 < deer_> &lt;dinoman&gt; sorry looked away</p>
14:16 < jrandom> ok, perhaps we can look into what SPF is b0rking on</p>
14:16 < jrandom> if there's nothing else on 0.4.1.3, moving on to 2) Tunnel test time, and send processing time</p>
14:17 < jrandom> there was some discussion yesterday exploring some of the timeouts, and basically things just occationally take too long</p>
14:17 < jrandom> i dont think the spikes you can see in http://dev.i2p.net/~jrandom/processingTime.png are legitimate though</p>
14:18 < jrandom> well, they're real - it really does take that long</p>
14:18 < jrandom> what i mean is, we should be able to get rid of them</p>
14:18 < jrandom> some queueing is going to happen, but if we are more careful with what we accept, we should be able to reduce it</p>
14:19 < jrandom> the delays are also likely due to some occational spikes in job processing time, which we can tune the fsck out of</p>
14:20 < jrandom> in general though, the message queueing seems all right, even if it spikes up some tunnel tests</p>
14:20 < deer_> &lt;newsbyte&gt; darn..I wish freenet and i2p could really merge...seems like progress would be a lot faster, possibly beneficial to both</p>
14:20 < deer_> &lt;Ragnarok&gt; yeah, I don't see why fsck would be useful for jon processing :)</p>
14:20 < deer_> &lt;Ragnarok&gt; s/jon/job/</p>
14:21 < jrandom> there is much potential for collaboration, but the two projects have very different aims</p>
14:21 < jrandom> !thwap Ragnarok</p>
14:21 < deer_> &lt;newsbyte&gt; ermm</p>
14:21 < jrandom> oh, one thing I mentioned yesterday </p>
14:21 < deer_> &lt;newsbyte&gt; I don't think the projects' goals, however, are all that different...</p>
14:22 < deer_> &lt;DrWoo&gt; jrandom: technical goals</p>
14:22 < jrandom> newsbyte: we can discuss that in 5) ??? or later if you prefer, we're on 2) right now</p>
14:22 < deer_> &lt;DrWoo&gt; oops newsbyte: technical goals</p>
14:22 < deer_> &lt;Ragnarok&gt; hehe</p>
14:22 < deer_> &lt;newsbyte&gt; yes, and 3)profit! according to /. traditions!</p>
14:22 < deer_> &lt;newsbyte&gt; :-)</p>
14:22 < deer_> &lt;Demokritos&gt; I can't believe Tor is not backwards compatible from 0.0.8 to 0.0.8.1</p>
14:23 < jrandom> with the tunnel testing, there is a floor to the test period - currently set to 5 seconds by default</p>
14:23 < jrandom> the previous release had a hard limit of 30 seconds, but you can configure your own tunnel test time by updating http://localhost:7657/configadvanced.jsp and adding "router.tunnelTestMinimum=10000" (or whatever - that value is in milliseconds)</p>
14:23 < deer_> &lt;newsbyte&gt; those seconds, are they alchimagical?</p>
14:24 < jrandom> the 5s default should be fine though</p>
14:24 < deer_> &lt;Demokritos&gt; I actually upgraded Tor the day before yesterday because it stopped working, and now the network is telling me again, I have a non compatible version... what the.. </p>
14:24 < deer_> &lt;Demokritos&gt; oh... hello everyone :)</p>
14:24 < jrandom> newsbyte: the tunnel test time is MAX(avgTunnelTestTime*2, minTunnelTestTime)</p>
14:25 < jrandom> (we have the minTunnelTestTime because otherwise a series of fast tests could cause a cascading failure)</p>
14:26 < jrandom> more details can be found in http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD</p>
14:26 < deer_> &lt;newsbyte&gt; hmm</p>
14:26 < deer_> &lt;Demokritos&gt; this is really funny... a job agency wants me to use Internet Explorer, otherwise I'm not able to register an application</p>
14:27 < jrandom> *cough* y'all realize these meeting logs go on the web, right? :)</p>
14:27 < deer_> &lt;Demokritos&gt; &lt;-- not too good in english</p>
14:27 < deer_> &lt;newsbyte&gt; they do?!</p>
14:27 < deer_> &lt;newsbyte&gt; Hi mum!</p>
14:27 < deer_> &lt;newsbyte&gt; ;-)</p>
14:27 < deer_> &lt;Demokritos&gt; um, sorry. .I'm disturbing the meeting.. I'm off</p>
14:28 < jrandom> naw, please stay, but discuss i2p stuff ;)</p>
14:28 < deer_> &lt;newsbyte&gt; don't worry; disturbing is an art, just keep an eye on me, and you'll learn</p>
14:28 < deer_> &lt;newsbyte&gt; ;-)</p>
14:28 < jrandom> ok, anything else on 2) Tunnel test time, and send processing time ?</p>
14:28 < deer_> &lt;Ragnarok&gt; focus people</p>
14:29 -!- znation [~znation@ip68-226-31-250.tc.ph.cox.net] has quit [Read error: 60 (Operation timed out)]</p>
14:29 < jrandom> if not, moving on to 3) Streaming lib</p>
14:29 < jrandom> as mentioned in the status notes, lots of progress</p>
14:29 -!- znation [~znation@ip68-226-31-250.tc.ph.cox.net] has joined #i2p</p>
14:29 < deer_> &lt;newsbyte&gt; done by you?</p>
14:29 < jrandom> still not there yet, but I hope to be doing some live tests in the next week</p>
14:30 < jrandom> i've been working on the streaming lib, yeah</p>
14:30 < jrandom> i finally got it ping()ing earlier today ;)</p>
14:30 < deer_> &lt;Ragnarok&gt; nice :)</p>
14:31 < jrandom> ok, i dont really have anything else to add about that</p>
14:31 < jrandom> anyone have any questions / comments / concerns?</p>
14:31 < deer_> &lt;newsbyte&gt; ermm...speed?</p>
14:31 < jrandom> speed is fine</p>
14:31 < deer_> &lt;baffled&gt; what type of speed up/through put do you expect?</p>
14:31 < jrandom> i expect significant throughput improvements</p>
14:32 < deer_> &lt;newsbyte&gt; he expects a fine, he said</p>
14:32 < deer_> &lt;newsbyte&gt; for speeding</p>
14:32 < deer_> &lt;newsbyte&gt; ;-)</p>
14:32 < jrandom> in addition, for small request/response connections, the latency will be dramatically reduced</p>
14:32 < jrandom> (cut in half)</p>
14:32 < deer_> &lt;dinoman&gt; wow</p>
14:32 < deer_> &lt;dinoman&gt; is that using udp?</p>
14:33 < jrandom> the new lib exposes all the neat tunable parameters for normal TCP stacks too, so apps will be able to tweak out their own setup</p>
14:33 < jrandom> no dinoman, this works on top of i2p's I2CP</p>
14:33 < deer_> &lt;dinoman&gt; wow x2</p>
14:33 < jrandom> (though we'll be writing similar code in a month or so to get the UDP transport..)</p>
14:34 < jrandom> but, well, we'll see.</p>
14:34 < deer_> &lt;newsbyte&gt; because...?</p>
14:34 < jrandom> there's still a lot of work to do</p>
14:34 < jrandom> because what?</p>
14:34 < deer_> &lt;newsbyte&gt; well, can't tcp do it as well?</p>
14:35 < jrandom> oh, why we're going to go UDP? http://www.i2p.net/todo#transport</p>
14:35 < deer_> &lt;newsbyte&gt; I remember the same discussion on freenet too, but they sticked to tcp as yet</p>
14:35 < jrandom> plus TCP is a general purpose streaming transport - we can dramatically simplify it, since we can put up with a certain degree of out of order</p>
14:35 < deer_> &lt;newsbyte&gt; not that all decisions they make are good ;-)</p>
14:36 < jrandom> newsbyte: i've followed those discussions and we're going to go udp</p>
14:36 < jrandom> (that doesnt mean freenet is wrong - they've got different constraints)</p>
14:37 < deer_> &lt;Ragnarok&gt; i2p should not be compared too closely to freenet. They're very different technically.</p>
14:37 < deer_> &lt;newsbyte&gt; (or: they ARE wrong ;-)</p>
14:37 < jrandom> i dont think their use of TCP right now is wrong, just as I dont think I2P's previous use of TCP is wrong. progress requires small steps</p>
14:38 < deer_> &lt;mule_iip&gt; newsbyte makes sure the meetings don't get too short</p>
14:38 < jrandom> heh</p>
14:38 < deer_> &lt;newsbyte&gt; yeah, nothing worse then short meetings</p>
14:38 < deer_> &lt;newsbyte&gt; you can't eat all the popcorn and drink all the beer, then</p>
14:38 < jrandom> ok, anything else on 3) Streaming lib ?</p>
14:39 < jrandom> if not, 4) files.i2p</p>
14:39 < deer_> &lt;Ragnarok&gt; I think we're cool</p>
14:39 < deer_> &lt;newsbyte&gt; well, I know I am</p>
14:39 < deer_> &lt;newsbyte&gt; ;-)</p>
14:39 < deer_> &lt;newsbyte&gt; and funny too</p>
14:39 < deer_> &lt;newsbyte&gt; most of the time</p>
14:39 < deer_> &lt;newsbyte&gt; and also annoying</p>
14:39 < deer_> &lt;newsbyte&gt; ;-)</p>
14:39 < jrandom> well, i just wanted to point out files.i2p - a new search engine on i2p</p>
14:40 < deer_> &lt;newsbyte&gt; ah, I see</p>
14:40 < deer_> &lt;newsbyte&gt; I was hoping it would be about putting eepsites up</p>
14:40 < jrandom> one interesting thing to note is that you can reach eepsites that aren't up anymore with it, since it caches</p>
14:41 < deer_> &lt;baffled&gt; does it cache everything?</p>
14:41 < deer_> &lt;newsbyte&gt; all searchengines thusfar are server-side?</p>
14:41 < deer_> &lt;Ragnarok&gt; interesting. Shouldn't be too hard, these days :).</p>
14:41 < jrandom> baffled: caches text/html from what i can tell</p>
14:42 < deer_> &lt;mule_iip&gt; at least it has limits on file size and types, so won't cache movies</p>
14:42 < deer_> &lt;baffled&gt; Auh, that's what I thought not binary.</p>
14:42 < deer_> &lt;newsbyte&gt; I mean, they are not in js, I suppose?</p>
14:43 < jrandom> it uses nutch if anyone wants to look into it further. or i'm sure we'll get the site author to put up a feedback form or something ;)</p>
14:43 < jrandom> newsbyte: correct, this is just a normal website hosted anonymously</p>
14:43 < jrandom> the site contains a search engine (like google)</p>
14:44 < jrandom> anyway, i just wanted to mention it</p>
14:44 < jrandom> there have also been a lot of blogs popping up lately, which imho is really cool</p>
14:44 < jrandom> my 'eep' bookmark folder almost fills a screen :)</p>
14:44 < deer_> &lt;Ragnarok&gt; hehe, myi2p is happening all by itself :)</p>
14:45 < jrandom> you just have to bring up the sore points, dont ya ragnarok? ;)</p>
14:45 < deer_> &lt;Ragnarok&gt; sorry :)</p>
14:46 < jrandom> ok, anyone have any questions/comments/concerns wrt files.i2p?</p>
14:46 < jrandom> if not, let me move on to 4.1) biff</p>
14:46 * jrandom almost forgot biff</p>
14:46 < jrandom> postman, you arond?</p>
14:47 < deer_> &lt;newsbyte&gt; I think he's biffed up</p>
14:47 < jrandom> well, if not, biff is this new kickass mail notification bot</p>
14:47 < jrandom> if you've got an email acct at mail.i2p, you can tell biff to notify you when you get new mail</p>
14:47 < deer_> &lt;newsbyte&gt; does it has archives?</p>
14:48 < jrandom> newsbyte: biff is just a notification bot, the mail is stored on the mail server (and accessed with your normal mail reader - kmail, etc)</p>
14:48 < jrandom> see http://www.postman.i2p/</p>
14:49 < jrandom> ok, so, yeah, go to the eepsite or check out #mail.i2p over there</p>
14:49 < deer_> &lt;newsbyte&gt; I will, as soon as I get my eepsite on</p>
14:49 * jrandom doesnt really know much more wrt biff - redirect any questions to postman</p>
14:50 < jrandom> instead, we can move on to 5) ???</p>
14:50 < deer_> &lt;newsbyte&gt; indeed</p>
14:50 < jrandom> does anyone have anything else they want to bring up?</p>
14:50 < deer_> * mule_iip raising hand to get voice: would like to recall my persistent FCP over I2P problems. but probably that can wait and will automagically be solved by 0.4.2.</p>
14:50 < deer_> &lt;newsbyte&gt; yes, and the freeze</p>
14:50 < jrandom> i hope so mule_iip</p>
14:50 < deer_> &lt;mule_iip&gt; ok, will be your test platform :)</p>
14:50 < jrandom> newsbyte: is there anything we need to discuss about it? could you just email me your logs if it happens again?</p>
14:51 < jrandom> ooh mule, that'd rule</p>
14:51 * jrandom will definitelytake you up on that</p>
14:51 < deer_> &lt;newsbyte&gt; well...can i still send those, if everything is frozen?</p>
14:51 < jrandom> the files are written to disk. </p>
14:51 < jrandom> when you restart, send me the logs</p>
14:51 < deer_> &lt;newsbyte&gt; I mean, in that case, I could send it now, since they should be somewhere </p>
14:51 < jrandom> (please)</p>
14:51 < deer_> &lt;dinoman&gt; i was in the forum and see that the jabber service is gone. was thaat of us to anyone if it was i would like to run one if it would be cool?</p>
14:51 < jrandom> the files rotate though newsbyte</p>
14:52 < jrandom> duck and demonic_1 have had jabber servers at various times, but it seems most of the i2p IM activity has been on irc</p>
14:52 < deer_> &lt;newsbyte&gt; the files rotate? surely it stores quite some data before it starts deleting?</p>
14:53 < jrandom> newsbyte: ok, send me your logs, maybe it has something in it</p>
14:53 < deer_> &lt;newsbyte&gt; good</p>
14:53 < deer_> &lt;newsbyte&gt; ermm</p>
14:54 < deer_> &lt;newsbyte&gt; darn</p>
14:54 < deer_> &lt;newsbyte&gt; a lot of .logs</p>
14:54 < deer_> &lt;dinoman&gt; ok</p>
14:54 < deer_> &lt;newsbyte&gt; a noob is never gonna follow this</p>
14:54 < deer_> &lt;newsbyte&gt; I guess you're right in not making a /. article yet</p>
14:55 < jrandom> we're in no rush</p>
14:55 < deer_> &lt;newsbyte&gt; log-router.txt?</p>
14:55 < jrandom> wrapper.log and logs/log-router-*.txt</p>
14:56 < deer_> &lt;newsbyte&gt; and the mailaddy to use would be...?</p>
14:56 < deer_> &lt;fidd&gt; dinoman, a jabber server would be cool imo</p>
14:56 < jrandom> jrandom@i2p.net</p>
14:56 < deer_> &lt;newsbyte&gt; accessible by i2p, I hope?</p>
14:56 < deer_> &lt;newsbyte&gt; ;-)</p>
14:56 < jrandom> newsbyte: you can put your logs on your eepsite and msg me the url</p>
14:57 < jrandom> or you can send mail to jrandom@mail.i2p</p>
14:57 < deer_> &lt;newsbyte&gt; indeed!</p>
14:57 < deer_> &lt;newsbyte&gt; a good idea!</p>
14:57 < deer_> &lt;newsbyte&gt; there is only one little problem with it: It's not up yet</p>
14:57 < jrandom> ok, anyone else have anything they want to bring up?</p>
14:57 < jrandom> well, we can work on that newsbyte</p>
14:57 < jrandom> (after the meeting)</p>
14:59 < deer_> &lt;newsbyte&gt; thnks, but whoo is already helping</p>
14:59 < jrandom> if there's nothing else...</p>
14:59 < deer_> &lt;newsbyte&gt; we need a detailed howto/wiki/helpsite/something, though</p>
14:59 * jrandom winds up</p>
14:59 < deer_> &lt;Jake_&gt; i'd like to say, for the meeting, if a public release of i2p can be made before the u.s. election on november 2nd, this would go a long way to helping ensure a stable democracy </p>
14:59 < deer_> &lt;newsbyte&gt; what about 6)?</p>
14:59 < jrandom> newsbyte: would you like to work on that?</p>
15:00 < jrandom> newsbyte: i do agree it'd be great to get some more howtos and help info</p>
15:00 < deer_> &lt;Ragnarok&gt; 6) There is no.... number 6</p>
15:00 < deer_> &lt;newsbyte&gt; well, yeah, sort of, but it's a strange thing, with me</p>
15:00 < deer_> &lt;newsbyte&gt; I'm pro-wiki and public thingy and free for everyone and all that</p>
15:00 < deer_> &lt;newsbyte&gt; but my ego protests and wants minimal control</p>
15:00 < jrandom> great</p>
15:00 < deer_> &lt;newsbyte&gt; go figger</p>
15:00 < jrandom> heh</p>
15:01 < jrandom> well, if you'd like to make your own eepsite into a wiki you control, that'd be great too</p>
15:01 < deer_> &lt;newsbyte&gt; indeed</p>
15:01 < jrandom> though ugha.i2p has a pretty good uptime</p>
15:01 < deer_> &lt;newsbyte&gt; I'll think about it</p>
15:01 < jrandom> cool</p>
15:02 < deer_> &lt;newsbyte&gt; 6 would be the freenet-i2p thingy</p>
15:02 * jrandom winds up </p>
15:02 * jrandom *baf*s the meeting closed </p>
14:03 < jrandom> 1) 0.4.1.3
14:03 < jrandom> 2) Tunnel test time, and send processing time
14:03 < jrandom> 3) Streaming lib
14:03 < jrandom> 4) files.i2p
14:03 < jrandom> 5) ???
14:03 < jrandom> 0) hi
14:03 * jrandom waves
14:04 < modulus> hi hi
14:04 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2004-October/000469.html
14:04 < deer_> <fidd> howdy
14:04 < jrandom> i didn't spend much time on the notes, so they're pretty brief
14:05 < jrandom> but, c'est la vie
14:05 < jrandom> moving on to 1) 0.4.1.3
14:05 < jrandom> the release came out the other day and its been.. well... largely like before
14:05 < jrandom> working good enough for most things, but not as reliable as we'd like
14:06 < jrandom> throughput is still low, but thats a know issue to be dealt with in 0.4.2
14:06 < jrandom> as mentioned in the email, I dont expect there to be any more 0.4.1.* releases
14:07 < jrandom> I dont have much more to say on that - anyone have any comments / concerns?
14:07 < deer_> <newsbyte> yes: what about the freeze-up?
14:09 < jrandom> I'm not going to discount the possibility that your machine hung due to I2P, but I severely doubt it
14:09 < jrandom> no one else has ever reported that happening on any platform
14:09 < deer_> <newsbyte> well...it must be related to it somehow, if not directly, IMHO
14:09 < deer_> <newsbyte> maybe the java?
14:10 < jrandom> you're on 1.5 on w2k?
14:10 < jrandom> or 1.4.2_05?
14:10 < deer_> <newsbyte> nope, 1.5
14:10 < jrandom> ok
14:10 < deer_> <newsbyte> I can't exclude it's something else, ofcourse
14:11 < deer_> <newsbyte> could be coincidence it happend two times
14:11 < jrandom> well, we can discuss further how to find out the cause after the meeting if you'd like
14:11 < deer_> <newsbyte> but the last time..I dunno...nothing much else was running, then
14:11 < deer_> <dinoman> 1.5 on w2k works good for me :)
14:11 < deer_> <newsbyte> indeed, though
14:11 < deer_> <newsbyte> isn't there a simple debug log or something?
14:11 < jrandom> if it happens again, please send me wrapper.log and logs/log-router-*.txt
14:11 < deer_> <newsbyte> that might be usefull when it freezes
14:11 < jrandom> there are more logs than dirt ;)
14:12 < jrandom> ok cool dinoman
14:12 < jrandom> perhaps it was some interaction with your software firewall
14:12 < deer_> <newsbyte> maybe
14:12 < jrandom> but, yeah,bounce me logs if it happens again
14:12 < jrandom> (please :)
14:12 < deer_> <newsbyte> well, that it would get blocked, I would understand
14:12 < deer_> <newsbyte> but a total freeze...dunno...was creepy
14:13 < deer_> <newsbyte> on the bright side: I've 27/63 now
14:13 < jrandom> great
14:13 < jrandom> ok, anyone else have any questions/comments/concerns with 0.4.1.3?
14:13 < deer_> <newsbyte> I'll guees I'll ask Whoo to guide my through the eep thingy
14:13 < deer_> <dinoman> just don't use it with Sygate Personal Firewall bad bad
14:13 < deer_> <newsbyte> why?
14:14 < deer_> <dinoman> crash
14:14 < deer_> <newsbyte> yes; you forgot 6) profit!!
14:14 < deer_> <newsbyte> ;-)
14:14 < deer_> <newsbyte> crash?
14:14 < deer_> <newsbyte> ermm
14:14 < jrandom> dinoman: it crashes your OS? the firewall? I2P?
14:14 < deer_> <newsbyte> well, wouldn't that explain it, then? ;-)
14:15 < jrandom> newsbyte: are you running Sygate Personal Firewall?
14:15 < deer_> <newsbyte> indeed
14:15 < deer_> <newsbyte> well, not on my router
14:15 < deer_> <newsbyte> but on the puter, yes
14:15 < deer_> <newsbyte> seems we're on to something
14:16 < deer_> <DrWoo> newsbyte: /join #i2p-chat so jrandom can get through his meeting
14:16 < deer_> <newsbyte> though it doesn't crash/freeze immediately, apperently
14:16 < deer_> <dinoman> os it crashes windows
14:16 < deer_> <newsbyte> ?
14:16 < deer_> <newsbyte> jrand is already here
14:16 < deer_> <dinoman> sorry looked away
14:16 < jrandom> ok, perhaps we can look into what SPF is b0rking on
14:16 < jrandom> if there's nothing else on 0.4.1.3, moving on to 2) Tunnel test time, and send processing time
14:17 < jrandom> there was some discussion yesterday exploring some of the timeouts, and basically things just occationally take too long
14:17 < jrandom> i dont think the spikes you can see in http://dev.i2p.net/~jrandom/processingTime.png are legitimate though
14:18 < jrandom> well, they're real - it really does take that long
14:18 < jrandom> what i mean is, we should be able to get rid of them
14:18 < jrandom> some queueing is going to happen, but if we are more careful with what we accept, we should be able to reduce it
14:19 < jrandom> the delays are also likely due to some occational spikes in job processing time, which we can tune the fsck out of
14:20 < jrandom> in general though, the message queueing seems all right, even if it spikes up some tunnel tests
14:20 < deer_> <newsbyte> darn..I wish freenet and i2p could really merge...seems like progress would be a lot faster, possibly beneficial to both
14:20 < deer_> <Ragnarok> yeah, I don't see why fsck would be useful for jon processing :)
14:20 < deer_> <Ragnarok> s/jon/job/
14:21 < jrandom> there is much potential for collaboration, but the two projects have very different aims
14:21 < jrandom> !thwap Ragnarok
14:21 < deer_> <newsbyte> ermm
14:21 < jrandom> oh, one thing I mentioned yesterday
14:21 < deer_> <newsbyte> I don't think the projects' goals, however, are all that different...
14:22 < deer_> <DrWoo> jrandom: technical goals
14:22 < jrandom> newsbyte: we can discuss that in 5) ??? or later if you prefer, we're on 2) right now
14:22 < deer_> <DrWoo> oops newsbyte: technical goals
14:22 < deer_> <Ragnarok> hehe
14:22 < deer_> <newsbyte> yes, and 3)profit! according to /. traditions!
14:22 < deer_> <newsbyte> :-)
14:22 < deer_> <Demokritos> I can't believe Tor is not backwards compatible from 0.0.8 to 0.0.8.1
14:23 < jrandom> with the tunnel testing, there is a floor to the test period - currently set to 5 seconds by default
14:23 < jrandom> the previous release had a hard limit of 30 seconds, but you can configure your own tunnel test time by updating http://localhost:7657/configadvanced.jsp and adding "router.tunnelTestMinimum=10000" (or whatever - that value is in milliseconds)
14:23 < deer_> <newsbyte> those seconds, are they alchimagical?
14:24 < jrandom> the 5s default should be fine though
14:24 < deer_> <Demokritos> I actually upgraded Tor the day before yesterday because it stopped working, and now the network is telling me again, I have a non compatible version... what the..
14:24 < deer_> <Demokritos> oh... hello everyone :)
14:24 < jrandom> newsbyte: the tunnel test time is MAX(avgTunnelTestTime*2, minTunnelTestTime)
14:25 < jrandom> (we have the minTunnelTestTime because otherwise a series of fast tests could cause a cascading failure)
14:26 < jrandom> more details can be found in http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD
14:26 < deer_> <newsbyte> hmm
14:26 < deer_> <Demokritos> this is really funny... a job agency wants me to use Internet Explorer, otherwise I'm not able to register an application
14:27 < jrandom> *cough* y'all realize these meeting logs go on the web, right? :)
14:27 < deer_> <Demokritos> <-- not too good in english
14:27 < deer_> <newsbyte> they do?!
14:27 < deer_> <newsbyte> Hi mum!
14:27 < deer_> <newsbyte> ;-)
14:27 < deer_> <Demokritos> um, sorry. .I'm disturbing the meeting.. I'm off
14:28 < jrandom> naw, please stay, but discuss i2p stuff ;)
14:28 < deer_> <newsbyte> don't worry; disturbing is an art, just keep an eye on me, and you'll learn
14:28 < deer_> <newsbyte> ;-)
14:28 < jrandom> ok, anything else on 2) Tunnel test time, and send processing time ?
14:28 < deer_> <Ragnarok> focus people
14:29 -!- znation [~znation@ip68-226-31-250.tc.ph.cox.net] has quit [Read error: 60 (Operation timed out)]
14:29 < jrandom> if not, moving on to 3) Streaming lib
14:29 < jrandom> as mentioned in the status notes, lots of progress
14:29 -!- znation [~znation@ip68-226-31-250.tc.ph.cox.net] has joined #i2p
14:29 < deer_> <newsbyte> done by you?
14:29 < jrandom> still not there yet, but I hope to be doing some live tests in the next week
14:30 < jrandom> i've been working on the streaming lib, yeah
14:30 < jrandom> i finally got it ping()ing earlier today ;)
14:30 < deer_> <Ragnarok> nice :)
14:31 < jrandom> ok, i dont really have anything else to add about that
14:31 < jrandom> anyone have any questions / comments / concerns?
14:31 < deer_> <newsbyte> ermm...speed?
14:31 < jrandom> speed is fine
14:31 < deer_> <baffled> what type of speed up/through put do you expect?
14:31 < jrandom> i expect significant throughput improvements
14:32 < deer_> <newsbyte> he expects a fine, he said
14:32 < deer_> <newsbyte> for speeding
14:32 < deer_> <newsbyte> ;-)
14:32 < jrandom> in addition, for small request/response connections, the latency will be dramatically reduced
14:32 < jrandom> (cut in half)
14:32 < deer_> <dinoman> wow
14:32 < deer_> <dinoman> is that using udp?
14:33 < jrandom> the new lib exposes all the neat tunable parameters for normal TCP stacks too, so apps will be able to tweak out their own setup
14:33 < jrandom> no dinoman, this works on top of i2p's I2CP
14:33 < deer_> <dinoman> wow x2
14:33 < jrandom> (though we'll be writing similar code in a month or so to get the UDP transport..)
14:34 < jrandom> but, well, we'll see.
14:34 < deer_> <newsbyte> because...?
14:34 < jrandom> there's still a lot of work to do
14:34 < jrandom> because what?
14:34 < deer_> <newsbyte> well, can't tcp do it as well?
14:35 < jrandom> oh, why we're going to go UDP? http://www.i2p.net/todo#transport
14:35 < deer_> <newsbyte> I remember the same discussion on freenet too, but they sticked to tcp as yet
14:35 < jrandom> plus TCP is a general purpose streaming transport - we can dramatically simplify it, since we can put up with a certain degree of out of order
14:35 < deer_> <newsbyte> not that all decisions they make are good ;-)
14:36 < jrandom> newsbyte: i've followed those discussions and we're going to go udp
14:36 < jrandom> (that doesnt mean freenet is wrong - they've got different constraints)
14:37 < deer_> <Ragnarok> i2p should not be compared too closely to freenet. They're very different technically.
14:37 < deer_> <newsbyte> (or: they ARE wrong ;-)
14:37 < jrandom> i dont think their use of TCP right now is wrong, just as I dont think I2P's previous use of TCP is wrong. progress requires small steps
14:38 < deer_> <mule_iip> newsbyte makes sure the meetings don't get too short
14:38 < jrandom> heh
14:38 < deer_> <newsbyte> yeah, nothing worse then short meetings
14:38 < deer_> <newsbyte> you can't eat all the popcorn and drink all the beer, then
14:38 < jrandom> ok, anything else on 3) Streaming lib ?
14:39 < jrandom> if not, 4) files.i2p
14:39 < deer_> <Ragnarok> I think we're cool
14:39 < deer_> <newsbyte> well, I know I am
14:39 < deer_> <newsbyte> ;-)
14:39 < deer_> <newsbyte> and funny too
14:39 < deer_> <newsbyte> most of the time
14:39 < deer_> <newsbyte> and also annoying
14:39 < deer_> <newsbyte> ;-)
14:39 < jrandom> well, i just wanted to point out files.i2p - a new search engine on i2p
14:40 < deer_> <newsbyte> ah, I see
14:40 < deer_> <newsbyte> I was hoping it would be about putting eepsites up
14:40 < jrandom> one interesting thing to note is that you can reach eepsites that aren't up anymore with it, since it caches
14:41 < deer_> <baffled> does it cache everything?
14:41 < deer_> <newsbyte> all searchengines thusfar are server-side?
14:41 < deer_> <Ragnarok> interesting. Shouldn't be too hard, these days :).
14:41 < jrandom> baffled: caches text/html from what i can tell
14:42 < deer_> <mule_iip> at least it has limits on file size and types, so won't cache movies
14:42 < deer_> <baffled> Auh, that's what I thought not binary.
14:42 < deer_> <newsbyte> I mean, they are not in js, I suppose?
14:43 < jrandom> it uses nutch if anyone wants to look into it further. or i'm sure we'll get the site author to put up a feedback form or something ;)
14:43 < jrandom> newsbyte: correct, this is just a normal website hosted anonymously
14:43 < jrandom> the site contains a search engine (like google)
14:44 < jrandom> anyway, i just wanted to mention it
14:44 < jrandom> there have also been a lot of blogs popping up lately, which imho is really cool
14:44 < jrandom> my 'eep' bookmark folder almost fills a screen :)
14:44 < deer_> <Ragnarok> hehe, myi2p is happening all by itself :)
14:45 < jrandom> you just have to bring up the sore points, dont ya ragnarok? ;)
14:45 < deer_> <Ragnarok> sorry :)
14:46 < jrandom> ok, anyone have any questions/comments/concerns wrt files.i2p?
14:46 < jrandom> if not, let me move on to 4.1) biff
14:46 * jrandom almost forgot biff
14:46 < jrandom> postman, you arond?
14:47 < deer_> <newsbyte> I think he's biffed up
14:47 < jrandom> well, if not, biff is this new kickass mail notification bot
14:47 < jrandom> if you've got an email acct at mail.i2p, you can tell biff to notify you when you get new mail
14:47 < deer_> <newsbyte> does it has archives?
14:48 < jrandom> newsbyte: biff is just a notification bot, the mail is stored on the mail server (and accessed with your normal mail reader - kmail, etc)
14:48 < jrandom> see http://www.postman.i2p/
14:49 < jrandom> ok, so, yeah, go to the eepsite or check out #mail.i2p over there
14:49 < deer_> <newsbyte> I will, as soon as I get my eepsite on
14:49 * jrandom doesnt really know much more wrt biff - redirect any questions to postman
14:50 < jrandom> instead, we can move on to 5) ???
14:50 < deer_> <newsbyte> indeed
14:50 < jrandom> does anyone have anything else they want to bring up?
14:50 < deer_> * mule_iip raising hand to get voice: would like to recall my persistent FCP over I2P problems. but probably that can wait and will automagically be solved by 0.4.2.
14:50 < deer_> <newsbyte> yes, and the freeze
14:50 < jrandom> i hope so mule_iip
14:50 < deer_> <mule_iip> ok, will be your test platform :)
14:50 < jrandom> newsbyte: is there anything we need to discuss about it? could you just email me your logs if it happens again?
14:51 < jrandom> ooh mule, that'd rule
14:51 * jrandom will definitelytake you up on that
14:51 < deer_> <newsbyte> well...can i still send those, if everything is frozen?
14:51 < jrandom> the files are written to disk.
14:51 < jrandom> when you restart, send me the logs
14:51 < deer_> <newsbyte> I mean, in that case, I could send it now, since they should be somewhere
14:51 < jrandom> (please)
14:51 < deer_> <dinoman> i was in the forum and see that the jabber service is gone. was thaat of us to anyone if it was i would like to run one if it would be cool?
14:51 < jrandom> the files rotate though newsbyte
14:52 < jrandom> duck and demonic_1 have had jabber servers at various times, but it seems most of the i2p IM activity has been on irc
14:52 < deer_> <newsbyte> the files rotate? surely it stores quite some data before it starts deleting?
14:53 < jrandom> newsbyte: ok, send me your logs, maybe it has something in it
14:53 < deer_> <newsbyte> good
14:53 < deer_> <newsbyte> ermm
14:54 < deer_> <newsbyte> darn
14:54 < deer_> <newsbyte> a lot of .logs
14:54 < deer_> <dinoman> ok
14:54 < deer_> <newsbyte> a noob is never gonna follow this
14:54 < deer_> <newsbyte> I guess you're right in not making a /. article yet
14:55 < jrandom> we're in no rush
14:55 < deer_> <newsbyte> log-router.txt?
14:55 < jrandom> wrapper.log and logs/log-router-*.txt
14:56 < deer_> <newsbyte> and the mailaddy to use would be...?
14:56 < deer_> <fidd> dinoman, a jabber server would be cool imo
14:56 < jrandom> jrandom@i2p.net
14:56 < deer_> <newsbyte> accessible by i2p, I hope?
14:56 < deer_> <newsbyte> ;-)
14:56 < jrandom> newsbyte: you can put your logs on your eepsite and msg me the url
14:57 < jrandom> or you can send mail to jrandom@mail.i2p
14:57 < deer_> <newsbyte> indeed!
14:57 < deer_> <newsbyte> a good idea!
14:57 < deer_> <newsbyte> there is only one little problem with it: It's not up yet
14:57 < jrandom> ok, anyone else have anything they want to bring up?
14:57 < jrandom> well, we can work on that newsbyte
14:57 < jrandom> (after the meeting)
14:59 < deer_> <newsbyte> thnks, but whoo is already helping
14:59 < jrandom> if there's nothing else...
14:59 < deer_> <newsbyte> we need a detailed howto/wiki/helpsite/something, though
14:59 * jrandom winds up
14:59 < deer_> <Jake_> i'd like to say, for the meeting, if a public release of i2p can be made before the u.s. election on november 2nd, this would go a long way to helping ensure a stable democracy
14:59 < deer_> <newsbyte> what about 6)?
14:59 < jrandom> newsbyte: would you like to work on that?
15:00 < jrandom> newsbyte: i do agree it'd be great to get some more howtos and help info
15:00 < deer_> <Ragnarok> 6) There is no.... number 6
15:00 < deer_> <newsbyte> well, yeah, sort of, but it's a strange thing, with me
15:00 < deer_> <newsbyte> I'm pro-wiki and public thingy and free for everyone and all that
15:00 < deer_> <newsbyte> but my ego protests and wants minimal control
15:00 < jrandom> great
15:00 < deer_> <newsbyte> go figger
15:00 < jrandom> heh
15:01 < jrandom> well, if you'd like to make your own eepsite into a wiki you control, that'd be great too
15:01 < deer_> <newsbyte> indeed
15:01 < jrandom> though ugha.i2p has a pretty good uptime
15:01 < deer_> <newsbyte> I'll think about it
15:01 < jrandom> cool
15:02 < deer_> <newsbyte> 6 would be the freenet-i2p thingy
15:02 * jrandom winds up
15:02 * jrandom *baf*s the meeting closed
</div>
{% endblock %}
{% endblock %}

10
i2p2www/meetings/112.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, October 19, 2004
=================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,273 +1,267 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 113{% endblock %}
{% block content %}<h3>I2P dev meeting, October 26, 2004</h3>
<div class="irclog">
14:04 < jrandom> 0) hi</p>
14:04 < jrandom> 1) Net status</p>
14:04 < jrandom> 2) Streaming lib</p>
14:04 < jrandom> 3) mail.i2p progress</p>
14:05 < jrandom> 4) ???</p>
14:05 < jrandom> 0) hi</p>
14:05 * jrandom waves</p>
14:05 < jrandom> weekly status notes posted to http://dev.i2p.net/pipermail/i2p/2004-October/000474.html</p>
14:06 * jrandom will let y'all read ahead (damn you, read ahead!)</p>
14:06 < jrandom> jumping in to 1) net status</p>
14:07 < jrandom> i guess the email covers what i wanted to mention. nice fix wrt resume duck, and thanks for reporting it ardvark and ragnarok!</p>
14:07 < jrandom> does anyone have anything they want to bring up about the network status?</p>
14:08 < modulus> it rules.</p>
14:08 < deer> &lt;postman&gt; hi</p>
14:08 < jrandom> w3wt</p>
14:09 < jrandom> there is something funky w/ lag going on lately though, but it seems to be the same as what we discussed last week</p>
14:09 < jrandom> (especially since i haven't done any work on the core since then)</p>
14:09 < deer> &lt;clayboy&gt; i think everybody agrees that it has been stable and usable.</p>
14:09 < deer> &lt;clayboy&gt; i miss my 10-16 hours connected time on irc though, not important</p>
14:10 < deer> &lt;jrandom2p&gt; i'm on for 20h here</p>
14:10 < deer> &lt;jrandom2p&gt; but yeah, it varies (which hopefully agenda item 2) will help with)</p>
14:10 < deer> &lt;clayboy&gt; i can hardly get &gt; 2h, but i always reconnect in an instant, so it's still usable</p>
14:11 < jrandom> cool</p>
14:11 < jrandom> still not good enough, but sufficient</p>
14:11 < jrandom> (for the time being)</p>
14:11 < deer> &lt;clayboy&gt; agreed</p>
14:12 < jrandom> ok, anyone have anything else, or shall we move on to 2) streaming lib?</p>
14:13 < jrandom> [consider us moved]</p>
14:13 < jrandom> the email gives a rundown of how the progress is coming</p>
14:14 < jrandom> the message sequences are 'correct' in most cases (matching the ones discussed before)</p>
14:14 < jrandom> e.g. short request/response gets the requestee a response in a single round trip</p>
14:15 < jrandom> i'm working on the profile=bulk right now, going through the sliding windows under lag and failure conditions</p>
14:15 < jrandom> still some things to clean up, and nothing ready for use, but its progress</p>
14:16 < deer> &lt;clayboy&gt; so is 0.4.2 with streaming lib en route for october? it seems like an unnecessary rush.</p>
14:16 < jrandom> i dont think we'll have the streaming lib ready for final deployment by next week, no</p>
14:17 < jrandom> so there'll be some schedule slippage, i'm not sure to what extent yet</p>
14:17 < deer> &lt;duck&gt; any test classes we can run for kicks?</p>
14:18 < jrandom> i havent committed the build.xml file yet to keep people from using it ;) but i'll commit what i've got later tonight, and you can try out http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/apps/streaming/java/test/net/i2p/client/streaming/StreamSinkTest.java?rev=1.1&content-type=text/x-cvsweb-markup</p>
14:19 < deer> &lt;duck&gt; h0t</p>
14:19 < jrandom> one thing is that this new streaming lib doesn't use the old mode=guaranteed anymore since it has its own ACK/NACK setup</p>
14:20 < jrandom> that means that after the lib works perfectly, there's still going to be some work to be done in the router itself, as the client sending tasks are designed for 'guaranteed' delivery, bundling a roundtrip message in the garlic to confirm session tag delivery</p>
14:21 < jrandom> we don't actually have to fix that right away though - the bandwidth usage on that DeliveryStatusMessage is... trivial</p>
14:21 < jrandom> but we'll want to sooner rather than later</p>
14:22 < jrandom> ok, thats all i've got to say on that</p>
14:22 < jrandom> anyone have anything to bring up wrt the streaming lib?</p>
14:23 < jrandom> if not, 3) mail.i2p progress</p>
14:23 < jrandom> postman, you 'round?</p>
14:23 < deer> &lt;postman&gt; ya</p>
14:24 < jrandom> any update for us, or shall we wait until there's more news?</p>
14:24 < deer> &lt;postman&gt; ok</p>
14:24 < deer> &lt;postman&gt; shall i?</p>
14:24 < jrandom> the mic is yours</p>
14:24 < deer> * gott awakens.</p>
14:24 < deer> &lt;postman&gt; 1.) the in/out proxy facility is being installed/tested atm </p>
14:25 < deer> &lt;postman&gt; 2.) within the next 10 days we'll have a gateway service from and to the internet for emails</p>
14:25 < modulus> cool!</p>
14:25 < jrandom> cool^2!</p>
14:25 < deer> &lt;clayboy&gt; indeed</p>
14:25 < deer> &lt;postman&gt; 3.) the implementation will follow the ideas/concepts of the ideas.html document on my websote</p>
14:25 < deer> &lt;gott&gt; bravo !</p>
14:26 < deer> &lt;postman&gt; means: hashcash/recipient based quotas and all the fancy stuff</p>
14:26 < deer> &lt;postman&gt; the service should not be abused by its fellow anonymous users</p>
14:26 < deer> &lt;postman&gt; :)</p>
14:26 < deer> &lt;postman&gt; well there'e another point</p>
14:26 < deer> &lt;postman&gt; the question for webmail interfaces</p>
14:26 < deer> &lt;postman&gt; right now i don't want to host itz on my servers</p>
14:27 < deer> &lt;postman&gt; since i don't know about potential security problems</p>
14:27 < deer> &lt;postman&gt; the system that runs now is verified by me - i know the source and the security risks</p>
14:28 < deer> &lt;postman&gt; adding php and dynamic stuff and a webmail application FOR ALL users makes it much more difficult </p>
14:28 < deer> &lt;postman&gt; the idea ( thanks jr) is:</p>
14:28 < deer> &lt;postman&gt; what if the user got his own webmail interface installed as aonthr optional jetty or whatever instance?</p>
14:29 < modulus> like a pop3 -&gt; webmail thing?</p>
14:29 < jrandom> 'zactly</p>
14:29 < deer> &lt;postman&gt; and this local webmail application uses the postman.i2p tunnels to do smtp and pop3</p>
14:29 < modulus> sounds good.</p>
14:29 < deer> &lt;postman&gt; but i need help in evaluating</p>
14:30 < deer> &lt;postman&gt; right now i am quite busy with real life stuff and the in/out proxies</p>
14:30 < jrandom> (eww, real life!)</p>
14:30 < deer> &lt;postman&gt; and i got a peanut sized brain - so i am not good in java at all</p>
14:31 < deer> &lt;postman&gt; i need sbdy helping how this can be done as a local/optional service </p>
14:31 < modulus> may there be something that does this already on tcp? if so it could be used.</p>
14:31 < deer> &lt;DrWoo&gt; postman: I doubt it's peanut sized, I think it takes walnut sized just to breath ;)</p>
14:32 < jrandom> after a quick glance through hotscripts, i saw one that did pop3, though i dont know if it did authenticated smtp</p>
14:32 < deer> &lt;postman&gt; modulus: i assume there's something in the wild that can be used / adapted - it would be sexy to let it run in an own jetty instance</p>
14:32 < jrandom> i'm sure there is something out there, we just need an adventurous soul to go find it :)</p>
14:32 < deer> &lt;postman&gt; jrandom2p: this can be hacked quite easily i think</p>
14:33 < jrandom> exactly - in an ideal world, someone can just grab a mywebmail.war and save it to the webapps/ directory and jump into http://localhost:7657/mywebmail/</p>
14:33 < deer> &lt;postman&gt; well, i leave this issue to you to think about it :)</p>
14:33 < modulus> even if it's a stand-alone app, it should be fine, with i2ptunel</p>
14:33 < jrandom> right modulus </p>
14:33 < deer> &lt;postman&gt; yep :)</p>
14:34 < jrandom> and local &gt;&gt; remote, as the local side can do things like access your GPG keyrings or whatever</p>
14:34 < deer> &lt;postman&gt; i will do anything thats needed to support such a system on the server side</p>
14:34 < modulus> which hopefully would be very little.</p>
14:36 < deer> &lt;postman&gt; of course there will be an official announcement as soon as internet access is available - so stay tuned - maybe there will be some progress on the webmail idea as well</p>
14:36 < deer> &lt;postman&gt; so much for my department</p>
14:36 < deer> * postman sits down again and sips on his coffee</p>
14:36 < modulus> could you do something about filtering anon-revealing data?</p>
14:36 < jrandom> kickass, thanks postman! sounds exciting</p>
14:36 < modulus> some MUAs are very misbehaved in this way.</p>
14:37 < deer> &lt;postman&gt; modules: please look at the webpage - there is a multipage sermon about that</p>
14:37 < jrandom> :)</p>
14:37 < modulus> ok</p>
14:37 < jrandom> http://www.postman.i2p/sec.html to start</p>
14:37 < modulus> i read that, i just thought maybe some fields could be filtered.</p>
14:37 < modulus> maybe i trust postman but not other ppl.</p>
14:38 < deer> &lt;postman&gt; modulus: They ARE filtred</p>
14:38 < modulus> ok, last time i treid it they weren't.</p>
14:38 < modulus> sorry about that.</p>
14:38 < deer> &lt;postman&gt; modulus: sec2.html describes WHAT headerlines are filtered or changed</p>
14:38 < deer> &lt;postman&gt; modulus: what headerlines are you refrring to?</p>
14:38 < modulus> from domain (IP) kind of thing</p>
14:39 < jrandom> it would be good if a local webmail script did the filtering locally</p>
14:39 < jrandom> (in addition to any filtering done @ smtp.postman.i2p)</p>
14:39 < deer> &lt;postman&gt; modulus: lets talk about that in pm, ok? :)</p>
14:40 < deer> &lt;postman&gt; jrandom2p: of course - i am happy about every client doing its homework</p>
14:40 < modulus> sure, sorry.</p>
14:41 < jrandom> ok, do we have anything else for mail.i2p discussions?</p>
14:41 < jrandom> if not, 4) ???</p>
14:41 < deer> * duck has something for #4</p>
14:42 < jrandom> sup duck?</p>
14:42 < deer> &lt;duck&gt; the HD of home.duck.i2p blew up</p>
14:42 < jrandom> (d'oh)</p>
14:42 < deer> &lt;duck&gt; luckily the hosting accounts were not really used, except for alexandria</p>
14:42 < deer> &lt;duck&gt; did anybody here leach all the ebooks? :)</p>
14:43 < deer> &lt;duck&gt; if so, I got some missing so msg me please</p>
14:43 < jrandom> actually, i think thetower did</p>
14:43 < deer> &lt;duck&gt; I know that hypercubus also has them</p>
14:43 < deer> &lt;postman&gt; damn</p>
14:43 < jrandom> i saw a mirror on his site a while back</p>
14:43 < deer> &lt;postman&gt; :/</p>
14:43 < deer> &lt;duck&gt; cool</p>
14:43 < jrandom> i dont know if it has everything though, or how up to date it was</p>
14:43 < deer> &lt;duck&gt; alexandria is now on http://duck.i2p/alexandria/</p>
14:44 < deer> &lt;duck&gt; and I am going back to being ashamed</p>
14:44 < deer> &lt;duck&gt; .</p>
14:44 < jrandom> no need to be ashamed, you've provided a kickass free service!</p>
14:45 < jrandom> perhaps now is the chance for some geocities.i2p site ;)</p>
14:46 < deer> &lt;duck&gt; oh, I made a yodel webfrontend @ http://duck.i2p/yodel/</p>
14:46 < jrandom> oh, one thing i didn't have in the agenda is BT related stuff. i know dinoman is doing some hacking on that - perhaps he wants to mention something?</p>
14:46 < jrandom> ah nice</p>
14:48 * jrandom notes that thetower's alexandria mirror link 404s</p>
14:48 < deer> &lt;gott&gt; I have something to suggest.</p>
14:48 < jrandom> sup gott?</p>
14:48 < deer> &lt;gott&gt; I think it would be a nice feature for 0.4.2 to add a link to one of the sitelists on pages such as thetower's, baffled or mine.</p>
14:49 < jrandom> thats a good idea</p>
14:49 < jrandom> perhaps all three</p>
14:49 < deer> &lt;gott&gt; This is to (a) keep a list of active eepsites and (b) form an index for i2p similar to FIND / Dolphin</p>
14:49 < jrandom> yours is nice w/ the links to the eepsites too</p>
14:49 < deer> &lt;gott&gt; the one located at http://gott.i2p/sites.html is being kept up-to-date </p>
14:49 < deer> &lt;gott&gt; and the script is run every day</p>
14:49 < deer> &lt;gott&gt; I can add optional descriptions to the links ( thanx to baffled's script )</p>
14:50 < deer> &lt;gott&gt; which would make it an index</p>
14:50 < jrandom> perhaps it'd be neat to have a "recently added" or "recently removed" marker too?</p>
14:50 < jrandom> word</p>
14:51 < deer> &lt;gott&gt; quite good.</p>
14:51 < deer> &lt;gott&gt; that's all I had to say for now.</p>
14:51 < deer> &lt;gott&gt; oh, another thing</p>
14:51 < deer> &lt;gott&gt; snipsnap works well under i2p</p>
14:52 < deer> &lt;gott&gt; so we might see kuro5hin-style eepsites being brought up sometime a la SCUM</p>
14:52 < jrandom> kickass</p>
14:52 < deer> &lt;gott&gt; *except more devious a la SCUM</p>
14:52 < jrandom> a howto for setting that up would be great</p>
14:52 < deer> &lt;gott&gt; you put the .war in webapps</p>
14:52 < deer> &lt;gott&gt; it's pretty straightforward ;-)</p>
14:53 < deer> &lt;polecat&gt; snipsnap...SCUM...?</p>
14:53 < jrandom> its really that easy? booyeah!</p>
14:53 < jrandom> polecat - http://snipsnap.org/space/start</p>
14:53 < deer> &lt;gott&gt; I have finished my discourse.</p>
14:53 < deer> * gott retires.</p>
14:53 < jrandom> thanks gott</p>
14:54 < jrandom> nickster was using snipsnap for a while</p>
14:54 < jrandom> ok, anyone have anything else to bring up?</p>
14:55 * jrandom notes that we're near the hour mark even *without* newsbyte ;)</p>
14:55 < deer> &lt;polecat&gt; I like pie!</p>
14:55 < deer> &lt;gott&gt; I have another thing.</p>
14:55 < deer> &lt;duck&gt; oh, orz is awake</p>
14:55 < deer> &lt;gott&gt; I would like to announce that soon after 0.4.2 release I will publish an interview on jrandom on i2p-related things.</p>
14:55 < deer> &lt;polecat&gt; I wasn't aware this a formal meeting. Might mention my ideas about name servers...</p>
14:56 < deer> &lt;duck&gt; I suggest all japanese ppl to check out his eepsite/ircserver</p>
14:56 < deer> &lt;gott&gt; Nothing specific to be said on it until the questions are asked and answered but you have something to look forward to.</p>
14:56 < deer> &lt;gott&gt; it will be on my eeplog and if jrandom thinks good enough, probably featured somewhere on i2p.net</p>
14:57 < deer> * gott retires again.</p>
14:57 < deer> &lt;postman&gt; modulus: </p>
14:57 < jrandom> yeah, orz's site and irc server work great, i just dont know what it says :)</p>
14:58 < modulus> YES?</p>
14:58 < modulus> sorry for caps.</p>
14:58 < deer> &lt;DrWoo&gt; polecat: so about nameserver?</p>
14:58 < deer> * gott unretires</p>
14:58 < deer> &lt;gott&gt; duck: does he speak english ?</p>
14:59 < jrandom> oh polecat, whats up?</p>
14:59 < jrandom> polecat: we have our weekly meting every tuesday at 9p GMT</p>
14:59 < deer> &lt;gott&gt; I assume he does to have set everything up so well.</p>
14:59 < jrandom> (logs posted @ http://www.i2p/meetings once they're done ;)</p>
15:00 < deer> &lt;polecat&gt; Yes. Well I was thinking a name server might be a good idea. But not DNS. c.c I had an idea for a server that did nothing but translate between Protocol Specific Addresses and human readable names.</p>
15:00 < jrandom> so a URI--&gt;URL resolver, kinda?</p>
15:01 < deer> &lt;polecat&gt; That would replace hosts.txt, and eventually replace DNS itself once it supports ipv4 and ipv6.</p>
15:01 < deer> &lt;polecat&gt; name =&gt; hash in the case of i2p. Like duck.i2p =&gt; gobbledygook</p>
15:02 < jrandom> right right</p>
15:02 < deer> &lt;polecat&gt; Trouble with DNS is it has "requirements" (i.e. hacks) like MX servers, and root hierarchy, and nasty stuff like that. The hackiness of DNS puts even Usenet to shame.</p>
15:03 < deer> &lt;polecat&gt; I was talking about this earlier, and someone mentioned http://distributeddns.sourceforge.net/</p>
15:03 < deer> &lt;polecat&gt; I haven't had a chance to look at that site though.</p>
15:05 < jrandom> there are lots of things to keep in mind when working through a naming system, and in turn, there are lots of tradeoffs to be made. there have also been lots of discussions of improvements over the years (not just within i2p) to address many of the issues, but a concrete solution would be great</p>
15:05 < deer> &lt;gott&gt; quite good, quite good.</p>
15:07 < jrandom> i've got my own views, but thats where one of i2p's strong points comes out - my own views are irrelevent :) any sort ofnaming srevice can be used by client apps, as all of that functionality is outside of the core scope</p>
15:08 < jrandom> i know nano is working on something too - there's some entries @ nano.i2p, though i dont know how thats progressing</p>
15:08 < deer> &lt;polecat&gt; Agreed; you could write clients to use a ddns server as much as you could write them to parse the local hosts.txt</p>
15:08 < deer> &lt;gott&gt; jrandom: I dread the day when hosts.txt or equivalent naming system begins to show << enlarge.your.penis.i2p >></p>
15:09 < deer> &lt;polecat&gt; Just might be easier; at the current standing only I2PTunnel has the ability to understand hosts.txt. Plus if we're going to compete with ipv4 and ipv6 we can't compromise limited functionality when they don't.</p>
15:10 < jrandom> a while back mihi factored out the naming hooks in i2ptunnel - anything that implements http://dev.i2p.net/javadoc/net/i2p/client/naming/NamingService.html can be used transparently</p>
15:10 < jrandom> (and that includes I2PTunnel and SAM)</p>
15:10 < deer> &lt;polecat&gt; Really? I'll have to look at that too...</p>
15:11 < jrandom> well, they trade off functionality for security and identity</p>
15:11 < deer> &lt;polecat&gt; And also since i2p has such long hashes, for cryptographic security, having a name server is even more important since most people cannot remember the full i2p hash address.</p>
15:11 < jrandom> e.g. the jackboots can kick down $domainOwner's door</p>
15:11 < jrandom> (and someone can spoof dns without much trouble)</p>
15:12 < jrandom> but having some sort of name --&gt; location resolution functionality is definitely important</p>
15:13 < deer> &lt;polecat&gt; Without a centralized server, you can't have a unique human readable name anyway. Even if they're cryptographically signed, they still can be duplicated on the part that is comprehensible to us.</p>
15:14 < lucky> ugh.</p>
15:14 < lucky> Why don't you have deer block gott out?</p>
15:14 < jrandom> there are many tradeoffs</p>
15:14 < jrandom> i've outlined my preference at http://dev.i2p.net/pipermail/i2p/2004-February/000135.html</p>
15:15 < jrandom> but i'm not goingto write a naming service anytime soon, so whatever an implementer wants to do, they're free to :)</p>
15:15 < lucky> heh. I thought that was in response to the Gott question.</p>
15:15 < jrandom> heh</p>
15:15 < jrandom> naw, gott has been contributing positively as of late</p>
15:16 < jrandom> ok, in any case polecat, you should put up an eepsite with your ideas</p>
15:16 < lucky> god, what is the world coming to?</p>
15:16 < deer> &lt;polecat&gt; I'm thinking of writing a naming service myself. I'd like to know what everyone else prefers, and get as much guidance as possible how to implement it in a way that works really really well.</p>
15:16 < lucky> Oh, how can i contribute?</p>
15:16 < lucky> I know some java know. Like variable assigning.</p>
15:16 < lucky> And what ++j means</p>
15:17 < deer> &lt;polecat&gt; Ugh... an eepsite...</p>
15:17 < deer> &lt;polecat&gt; ++j is the post-increment operator on variable j?</p>
15:18 < jrandom> polecat: you can post to the mailing list or forum, as well. perhaps make a poll in the forum if you want to see what sort of preferences people have?</p>
15:18 < deer> &lt;polecat&gt; Trouble is this computer I'm on gets reset into Windoze frequently, and so unless I put my eepsite on a vfat partition, I can't share its info between operating systems.</p>
15:19 < jrandom> 'k, then its prolly best to have the naming stuff on the forum instead of an eepsite :)</p>
15:20 < deer> &lt;polecat&gt; Where's the forum again...?</p>
15:20 < jrandom> http://forum.i2p/</p>
15:20 < jrandom> and http://forum.i2p.net/</p>
15:20 < jrandom> (isnt naming wonderful? :)</p>
15:21 < deer> &lt;gott&gt; I have always contributed positively.</p>
15:21 < deer> &lt;polecat&gt; Yes, except we all still wget the hosts.txt file from a centralized sources. ;3</p>
15:22 * jrandom uses cp, not wget ;)</p>
15:22 < jrandom> ok, anyone have anything else to bring up?</p>
15:23 * jrandom doesnt mean to shut down the naming discussion, its just that we can discuss that for weeks on end</p>
15:23 < deer> &lt;DrWoo&gt; dinoman is working on a cvs server in i2p?</p>
15:23 < jrandom> well, there already *is* a cvs server in i2p (cvs.i2p)</p>
15:24 < jrandom> but thats right - dinoman was working on a full blown gforge in i2p iirc</p>
15:24 < deer> &lt;DrWoo&gt; jrandom: sorryt,I mean a fully anonymous cvs ;)</p>
15:25 < jrandom> hey, cvs.i2p is fully anonymous cvs :) i2p is completely self hosting, but without all the goodies for adding on lots of other projects</p>
15:25 < jrandom> (and having a gforge on i2p would Kick Ass)</p>
15:26 < deer> &lt;DrWoo&gt; jrandom: doesn't cvs.i2p run on the public server?</p>
15:26 < deer> &lt;polecat&gt; gforge... dunno that...</p>
15:27 < jrandom> DrWoo: maaaybe ;)</p>
15:27 < jrandom> DrWoo: but the key is that developers can be anonymous and develop for i2p through i2p</p>
15:27 < jrandom> if the machine that cvs.i2p is physically located on is under attack, we can just move the destination somewhere else</p>
15:28 < deer> &lt;polecat&gt; Yes, so while the i2p source itself is vulnerable to being confiscated by the Long Arm of the Law, its developers are immune to a certain extent through anonymity.</p>
15:28 < jrandom> let 'em have the source, its free! :)</p>
15:29 < deer> &lt;DrWoo&gt; jrandom: ya, i see what you're saying, but it still is at the risk of something like the indymedia thing</p>
15:30 < jrandom> if the jackboots kicked down the door of the colo where cvs.i2p is, i'd simply install cvs somewhere else, deploy a backup of the cvs there, and run an i2prouter with the cvs.i2p private key </p>
15:30 < jrandom> (and *not* tell peole that cvs.i2p == cvs.i2p.net ;)</p>
15:32 < jrandom> ok, anyone else have soemthing to bring up for the meeting?</p>
15:32 < deer> &lt;polecat&gt; Hee, that's pretty cool.</p>
15:33 < jrandom> if not</p>
15:33 * jrandom winds up</p>
15:34 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
14:04 < jrandom> 0) hi
14:04 < jrandom> 1) Net status
14:04 < jrandom> 2) Streaming lib
14:04 < jrandom> 3) mail.i2p progress
14:05 < jrandom> 4) ???
14:05 < jrandom> 0) hi
14:05 * jrandom waves
14:05 < jrandom> weekly status notes posted to http://dev.i2p.net/pipermail/i2p/2004-October/000474.html
14:06 * jrandom will let y'all read ahead (damn you, read ahead!)
14:06 < jrandom> jumping in to 1) net status
14:07 < jrandom> i guess the email covers what i wanted to mention. nice fix wrt resume duck, and thanks for reporting it ardvark and ragnarok!
14:07 < jrandom> does anyone have anything they want to bring up about the network status?
14:08 < modulus> it rules.
14:08 < deer> <postman> hi
14:08 < jrandom> w3wt
14:09 < jrandom> there is something funky w/ lag going on lately though, but it seems to be the same as what we discussed last week
14:09 < jrandom> (especially since i haven't done any work on the core since then)
14:09 < deer> <clayboy> i think everybody agrees that it has been stable and usable.
14:09 < deer> <clayboy> i miss my 10-16 hours connected time on irc though, not important
14:10 < deer> <jrandom2p> i'm on for 20h here
14:10 < deer> <jrandom2p> but yeah, it varies (which hopefully agenda item 2) will help with)
14:10 < deer> <clayboy> i can hardly get > 2h, but i always reconnect in an instant, so it's still usable
14:11 < jrandom> cool
14:11 < jrandom> still not good enough, but sufficient
14:11 < jrandom> (for the time being)
14:11 < deer> <clayboy> agreed
14:12 < jrandom> ok, anyone have anything else, or shall we move on to 2) streaming lib?
14:13 < jrandom> [consider us moved]
14:13 < jrandom> the email gives a rundown of how the progress is coming
14:14 < jrandom> the message sequences are 'correct' in most cases (matching the ones discussed before)
14:14 < jrandom> e.g. short request/response gets the requestee a response in a single round trip
14:15 < jrandom> i'm working on the profile=bulk right now, going through the sliding windows under lag and failure conditions
14:15 < jrandom> still some things to clean up, and nothing ready for use, but its progress
14:16 < deer> <clayboy> so is 0.4.2 with streaming lib en route for october? it seems like an unnecessary rush.
14:16 < jrandom> i dont think we'll have the streaming lib ready for final deployment by next week, no
14:17 < jrandom> so there'll be some schedule slippage, i'm not sure to what extent yet
14:17 < deer> <duck> any test classes we can run for kicks?
14:18 < jrandom> i havent committed the build.xml file yet to keep people from using it ;) but i'll commit what i've got later tonight, and you can try out http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/apps/streaming/java/test/net/i2p/client/streaming/StreamSinkTest.java?rev=1.1&content-type=text/x-cvsweb-markup
14:19 < deer> <duck> h0t
14:19 < jrandom> one thing is that this new streaming lib doesn't use the old mode=guaranteed anymore since it has its own ACK/NACK setup
14:20 < jrandom> that means that after the lib works perfectly, there's still going to be some work to be done in the router itself, as the client sending tasks are designed for 'guaranteed' delivery, bundling a roundtrip message in the garlic to confirm session tag delivery
14:21 < jrandom> we don't actually have to fix that right away though - the bandwidth usage on that DeliveryStatusMessage is... trivial
14:21 < jrandom> but we'll want to sooner rather than later
14:22 < jrandom> ok, thats all i've got to say on that
14:22 < jrandom> anyone have anything to bring up wrt the streaming lib?
14:23 < jrandom> if not, 3) mail.i2p progress
14:23 < jrandom> postman, you 'round?
14:23 < deer> <postman> ya
14:24 < jrandom> any update for us, or shall we wait until there's more news?
14:24 < deer> <postman> ok
14:24 < deer> <postman> shall i?
14:24 < jrandom> the mic is yours
14:24 < deer> * gott awakens.
14:24 < deer> <postman> 1.) the in/out proxy facility is being installed/tested atm
14:25 < deer> <postman> 2.) within the next 10 days we'll have a gateway service from and to the internet for emails
14:25 < modulus> cool!
14:25 < jrandom> cool^2!
14:25 < deer> <clayboy> indeed
14:25 < deer> <postman> 3.) the implementation will follow the ideas/concepts of the ideas.html document on my websote
14:25 < deer> <gott> bravo !
14:26 < deer> <postman> means: hashcash/recipient based quotas and all the fancy stuff
14:26 < deer> <postman> the service should not be abused by its fellow anonymous users
14:26 < deer> <postman> :)
14:26 < deer> <postman> well there'e another point
14:26 < deer> <postman> the question for webmail interfaces
14:26 < deer> <postman> right now i don't want to host itz on my servers
14:27 < deer> <postman> since i don't know about potential security problems
14:27 < deer> <postman> the system that runs now is verified by me - i know the source and the security risks
14:28 < deer> <postman> adding php and dynamic stuff and a webmail application FOR ALL users makes it much more difficult
14:28 < deer> <postman> the idea ( thanks jr) is:
14:28 < deer> <postman> what if the user got his own webmail interface installed as aonthr optional jetty or whatever instance?
14:29 < modulus> like a pop3 -> webmail thing?
14:29 < jrandom> 'zactly
14:29 < deer> <postman> and this local webmail application uses the postman.i2p tunnels to do smtp and pop3
14:29 < modulus> sounds good.
14:29 < deer> <postman> but i need help in evaluating
14:30 < deer> <postman> right now i am quite busy with real life stuff and the in/out proxies
14:30 < jrandom> (eww, real life!)
14:30 < deer> <postman> and i got a peanut sized brain - so i am not good in java at all
14:31 < deer> <postman> i need sbdy helping how this can be done as a local/optional service
14:31 < modulus> may there be something that does this already on tcp? if so it could be used.
14:31 < deer> <DrWoo> postman: I doubt it's peanut sized, I think it takes walnut sized just to breath ;)
14:32 < jrandom> after a quick glance through hotscripts, i saw one that did pop3, though i dont know if it did authenticated smtp
14:32 < deer> <postman> modulus: i assume there's something in the wild that can be used / adapted - it would be sexy to let it run in an own jetty instance
14:32 < jrandom> i'm sure there is something out there, we just need an adventurous soul to go find it :)
14:32 < deer> <postman> jrandom2p: this can be hacked quite easily i think
14:33 < jrandom> exactly - in an ideal world, someone can just grab a mywebmail.war and save it to the webapps/ directory and jump into http://localhost:7657/mywebmail/
14:33 < deer> <postman> well, i leave this issue to you to think about it :)
14:33 < modulus> even if it's a stand-alone app, it should be fine, with i2ptunel
14:33 < jrandom> right modulus
14:33 < deer> <postman> yep :)
14:34 < jrandom> and local >> remote, as the local side can do things like access your GPG keyrings or whatever
14:34 < deer> <postman> i will do anything thats needed to support such a system on the server side
14:34 < modulus> which hopefully would be very little.
14:36 < deer> <postman> of course there will be an official announcement as soon as internet access is available - so stay tuned - maybe there will be some progress on the webmail idea as well
14:36 < deer> <postman> so much for my department
14:36 < deer> * postman sits down again and sips on his coffee
14:36 < modulus> could you do something about filtering anon-revealing data?
14:36 < jrandom> kickass, thanks postman! sounds exciting
14:36 < modulus> some MUAs are very misbehaved in this way.
14:37 < deer> <postman> modules: please look at the webpage - there is a multipage sermon about that
14:37 < jrandom> :)
14:37 < modulus> ok
14:37 < jrandom> http://www.postman.i2p/sec.html to start
14:37 < modulus> i read that, i just thought maybe some fields could be filtered.
14:37 < modulus> maybe i trust postman but not other ppl.
14:38 < deer> <postman> modulus: They ARE filtred
14:38 < modulus> ok, last time i treid it they weren't.
14:38 < modulus> sorry about that.
14:38 < deer> <postman> modulus: sec2.html describes WHAT headerlines are filtered or changed
14:38 < deer> <postman> modulus: what headerlines are you refrring to?
14:38 < modulus> from domain (IP) kind of thing
14:39 < jrandom> it would be good if a local webmail script did the filtering locally
14:39 < jrandom> (in addition to any filtering done @ smtp.postman.i2p)
14:39 < deer> <postman> modulus: lets talk about that in pm, ok? :)
14:40 < deer> <postman> jrandom2p: of course - i am happy about every client doing its homework
14:40 < modulus> sure, sorry.
14:41 < jrandom> ok, do we have anything else for mail.i2p discussions?
14:41 < jrandom> if not, 4) ???
14:41 < deer> * duck has something for #4
14:42 < jrandom> sup duck?
14:42 < deer> <duck> the HD of home.duck.i2p blew up
14:42 < jrandom> (d'oh)
14:42 < deer> <duck> luckily the hosting accounts were not really used, except for alexandria
14:42 < deer> <duck> did anybody here leach all the ebooks? :)
14:43 < deer> <duck> if so, I got some missing so msg me please
14:43 < jrandom> actually, i think thetower did
14:43 < deer> <duck> I know that hypercubus also has them
14:43 < deer> <postman> damn
14:43 < jrandom> i saw a mirror on his site a while back
14:43 < deer> <postman> :/
14:43 < deer> <duck> cool
14:43 < jrandom> i dont know if it has everything though, or how up to date it was
14:43 < deer> <duck> alexandria is now on http://duck.i2p/alexandria/
14:44 < deer> <duck> and I am going back to being ashamed
14:44 < deer> <duck> .
14:44 < jrandom> no need to be ashamed, you've provided a kickass free service!
14:45 < jrandom> perhaps now is the chance for some geocities.i2p site ;)
14:46 < deer> <duck> oh, I made a yodel webfrontend @ http://duck.i2p/yodel/
14:46 < jrandom> oh, one thing i didn't have in the agenda is BT related stuff. i know dinoman is doing some hacking on that - perhaps he wants to mention something?
14:46 < jrandom> ah nice
14:48 * jrandom notes that thetower's alexandria mirror link 404s
14:48 < deer> <gott> I have something to suggest.
14:48 < jrandom> sup gott?
14:48 < deer> <gott> I think it would be a nice feature for 0.4.2 to add a link to one of the sitelists on pages such as thetower's, baffled or mine.
14:49 < jrandom> thats a good idea
14:49 < jrandom> perhaps all three
14:49 < deer> <gott> This is to (a) keep a list of active eepsites and (b) form an index for i2p similar to FIND / Dolphin
14:49 < jrandom> yours is nice w/ the links to the eepsites too
14:49 < deer> <gott> the one located at http://gott.i2p/sites.html is being kept up-to-date
14:49 < deer> <gott> and the script is run every day
14:49 < deer> <gott> I can add optional descriptions to the links ( thanx to baffled's script )
14:50 < deer> <gott> which would make it an index
14:50 < jrandom> perhaps it'd be neat to have a "recently added" or "recently removed" marker too?
14:50 < jrandom> word
14:51 < deer> <gott> quite good.
14:51 < deer> <gott> that's all I had to say for now.
14:51 < deer> <gott> oh, another thing
14:51 < deer> <gott> snipsnap works well under i2p
14:52 < deer> <gott> so we might see kuro5hin-style eepsites being brought up sometime a la SCUM
14:52 < jrandom> kickass
14:52 < deer> <gott> *except more devious a la SCUM
14:52 < jrandom> a howto for setting that up would be great
14:52 < deer> <gott> you put the .war in webapps
14:52 < deer> <gott> it's pretty straightforward ;-)
14:53 < deer> <polecat> snipsnap...SCUM...?
14:53 < jrandom> its really that easy? booyeah!
14:53 < jrandom> polecat - http://snipsnap.org/space/start
14:53 < deer> <gott> I have finished my discourse.
14:53 < deer> * gott retires.
14:53 < jrandom> thanks gott
14:54 < jrandom> nickster was using snipsnap for a while
14:54 < jrandom> ok, anyone have anything else to bring up?
14:55 * jrandom notes that we're near the hour mark even *without* newsbyte ;)
14:55 < deer> <polecat> I like pie!
14:55 < deer> <gott> I have another thing.
14:55 < deer> <duck> oh, orz is awake
14:55 < deer> <gott> I would like to announce that soon after 0.4.2 release I will publish an interview on jrandom on i2p-related things.
14:55 < deer> <polecat> I wasn't aware this a formal meeting. Might mention my ideas about name servers...
14:56 < deer> <duck> I suggest all japanese ppl to check out his eepsite/ircserver
14:56 < deer> <gott> Nothing specific to be said on it until the questions are asked and answered but you have something to look forward to.
14:56 < deer> <gott> it will be on my eeplog and if jrandom thinks good enough, probably featured somewhere on i2p.net
14:57 < deer> * gott retires again.
14:57 < deer> <postman> modulus:
14:57 < jrandom> yeah, orz's site and irc server work great, i just dont know what it says :)
14:58 < modulus> YES?
14:58 < modulus> sorry for caps.
14:58 < deer> <DrWoo> polecat: so about nameserver?
14:58 < deer> * gott unretires
14:58 < deer> <gott> duck: does he speak english ?
14:59 < jrandom> oh polecat, whats up?
14:59 < jrandom> polecat: we have our weekly meting every tuesday at 9p GMT
14:59 < deer> <gott> I assume he does to have set everything up so well.
14:59 < jrandom> (logs posted @ http://www.i2p/meetings once they're done ;)
15:00 < deer> <polecat> Yes. Well I was thinking a name server might be a good idea. But not DNS. c.c I had an idea for a server that did nothing but translate between Protocol Specific Addresses and human readable names.
15:00 < jrandom> so a URI-->URL resolver, kinda?
15:01 < deer> <polecat> That would replace hosts.txt, and eventually replace DNS itself once it supports ipv4 and ipv6.
15:01 < deer> <polecat> name => hash in the case of i2p. Like duck.i2p => gobbledygook
15:02 < jrandom> right right
15:02 < deer> <polecat> Trouble with DNS is it has "requirements" (i.e. hacks) like MX servers, and root hierarchy, and nasty stuff like that. The hackiness of DNS puts even Usenet to shame.
15:03 < deer> <polecat> I was talking about this earlier, and someone mentioned http://distributeddns.sourceforge.net/
15:03 < deer> <polecat> I haven't had a chance to look at that site though.
15:05 < jrandom> there are lots of things to keep in mind when working through a naming system, and in turn, there are lots of tradeoffs to be made. there have also been lots of discussions of improvements over the years (not just within i2p) to address many of the issues, but a concrete solution would be great
15:05 < deer> <gott> quite good, quite good.
15:07 < jrandom> i've got my own views, but thats where one of i2p's strong points comes out - my own views are irrelevent :) any sort ofnaming srevice can be used by client apps, as all of that functionality is outside of the core scope
15:08 < jrandom> i know nano is working on something too - there's some entries @ nano.i2p, though i dont know how thats progressing
15:08 < deer> <polecat> Agreed; you could write clients to use a ddns server as much as you could write them to parse the local hosts.txt
15:08 < deer> <gott> jrandom: I dread the day when hosts.txt or equivalent naming system begins to show << enlarge.your.penis.i2p >>
15:09 < deer> <polecat> Just might be easier; at the current standing only I2PTunnel has the ability to understand hosts.txt. Plus if we're going to compete with ipv4 and ipv6 we can't compromise limited functionality when they don't.
15:10 < jrandom> a while back mihi factored out the naming hooks in i2ptunnel - anything that implements http://dev.i2p.net/javadoc/net/i2p/client/naming/NamingService.html can be used transparently
15:10 < jrandom> (and that includes I2PTunnel and SAM)
15:10 < deer> <polecat> Really? I'll have to look at that too...
15:11 < jrandom> well, they trade off functionality for security and identity
15:11 < deer> <polecat> And also since i2p has such long hashes, for cryptographic security, having a name server is even more important since most people cannot remember the full i2p hash address.
15:11 < jrandom> e.g. the jackboots can kick down $domainOwner's door
15:11 < jrandom> (and someone can spoof dns without much trouble)
15:12 < jrandom> but having some sort of name --> location resolution functionality is definitely important
15:13 < deer> <polecat> Without a centralized server, you can't have a unique human readable name anyway. Even if they're cryptographically signed, they still can be duplicated on the part that is comprehensible to us.
15:14 < lucky> ugh.
15:14 < lucky> Why don't you have deer block gott out?
15:14 < jrandom> there are many tradeoffs
15:14 < jrandom> i've outlined my preference at http://dev.i2p.net/pipermail/i2p/2004-February/000135.html
15:15 < jrandom> but i'm not goingto write a naming service anytime soon, so whatever an implementer wants to do, they're free to :)
15:15 < lucky> heh. I thought that was in response to the Gott question.
15:15 < jrandom> heh
15:15 < jrandom> naw, gott has been contributing positively as of late
15:16 < jrandom> ok, in any case polecat, you should put up an eepsite with your ideas
15:16 < lucky> god, what is the world coming to?
15:16 < deer> <polecat> I'm thinking of writing a naming service myself. I'd like to know what everyone else prefers, and get as much guidance as possible how to implement it in a way that works really really well.
15:16 < lucky> Oh, how can i contribute?
15:16 < lucky> I know some java know. Like variable assigning.
15:16 < lucky> And what ++j means
15:17 < deer> <polecat> Ugh... an eepsite...
15:17 < deer> <polecat> ++j is the post-increment operator on variable j?
15:18 < jrandom> polecat: you can post to the mailing list or forum, as well. perhaps make a poll in the forum if you want to see what sort of preferences people have?
15:18 < deer> <polecat> Trouble is this computer I'm on gets reset into Windoze frequently, and so unless I put my eepsite on a vfat partition, I can't share its info between operating systems.
15:19 < jrandom> 'k, then its prolly best to have the naming stuff on the forum instead of an eepsite :)
15:20 < deer> <polecat> Where's the forum again...?
15:20 < jrandom> http://forum.i2p/
15:20 < jrandom> and http://forum.i2p.net/
15:20 < jrandom> (isnt naming wonderful? :)
15:21 < deer> <gott> I have always contributed positively.
15:21 < deer> <polecat> Yes, except we all still wget the hosts.txt file from a centralized sources. ;3
15:22 * jrandom uses cp, not wget ;)
15:22 < jrandom> ok, anyone have anything else to bring up?
15:23 * jrandom doesnt mean to shut down the naming discussion, its just that we can discuss that for weeks on end
15:23 < deer> <DrWoo> dinoman is working on a cvs server in i2p?
15:23 < jrandom> well, there already *is* a cvs server in i2p (cvs.i2p)
15:24 < jrandom> but thats right - dinoman was working on a full blown gforge in i2p iirc
15:24 < deer> <DrWoo> jrandom: sorryt,I mean a fully anonymous cvs ;)
15:25 < jrandom> hey, cvs.i2p is fully anonymous cvs :) i2p is completely self hosting, but without all the goodies for adding on lots of other projects
15:25 < jrandom> (and having a gforge on i2p would Kick Ass)
15:26 < deer> <DrWoo> jrandom: doesn't cvs.i2p run on the public server?
15:26 < deer> <polecat> gforge... dunno that...
15:27 < jrandom> DrWoo: maaaybe ;)
15:27 < jrandom> DrWoo: but the key is that developers can be anonymous and develop for i2p through i2p
15:27 < jrandom> if the machine that cvs.i2p is physically located on is under attack, we can just move the destination somewhere else
15:28 < deer> <polecat> Yes, so while the i2p source itself is vulnerable to being confiscated by the Long Arm of the Law, its developers are immune to a certain extent through anonymity.
15:28 < jrandom> let 'em have the source, its free! :)
15:29 < deer> <DrWoo> jrandom: ya, i see what you're saying, but it still is at the risk of something like the indymedia thing
15:30 < jrandom> if the jackboots kicked down the door of the colo where cvs.i2p is, i'd simply install cvs somewhere else, deploy a backup of the cvs there, and run an i2prouter with the cvs.i2p private key
15:30 < jrandom> (and *not* tell peole that cvs.i2p == cvs.i2p.net ;)
15:32 < jrandom> ok, anyone else have soemthing to bring up for the meeting?
15:32 < deer> <polecat> Hee, that's pretty cool.
15:33 < jrandom> if not
15:33 * jrandom winds up
15:34 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/113.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, October 26, 2004
=================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,404 +1,398 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 114{% endblock %}
{% block content %}<h3>I2P dev meeting, November 2, 2004</h3>
<div class="irclog">
13:37 < jrandom> 0) hi</p>
13:37 < jrandom> 1) Net status</p>
13:37 < jrandom> 2) Core updates</p>
13:37 < jrandom> 3) Streaming lib</p>
13:37 < jrandom> 4) mail.i2p progress</p>
13:38 < jrandom> 5) BT progress</p>
13:38 < jrandom> 6) ???</p>
13:38 < jrandom> 0) hi</p>
13:38 < jrandom> sorry for the delay, weekly status notes posted @ http://dev.i2p.net/pipermail/i2p/2004-November/000477.html</p>
13:38 < dm> meeting in 24 or 84?</p>
13:38 < jrandom> 0</p>
13:38 < dm> oh.. -36?</p>
13:39 < jrandom> yup, 9p GMT</p>
13:39 < jrandom> but i forgot that, so we're starting... now ;)</p>
13:39 < jrandom> 1) net status</p>
13:39 < dm> good timing</p>
13:39 < jrandom> well, no real change in the net status from my end - does anyone have anything they'd like to bring up about it?</p>
13:41 < jrandom> if not, might as well move on to 2) core updates</p>
13:41 < jrandom> i dont really have anything to add beyond whats in the email, so i'll give people a min to digest</p>
13:42 < deer> &lt;postman&gt; arg</p>
13:42 < jrandom> there've been 8 patches since the release, with another one or two pending. we'll probably just tag those all up into a 0.4.1.4, as the streaming lib itself isn't ready</p>
13:43 < deer> &lt;jrandom&gt; wb, its looking a bit bumpy over here</p>
13:43 < deer> &lt;postman&gt; np, i am back :)</p>
13:43 < protok0l> any word on aum's disappearance? i want stasher!</p>
13:44 * dm likes knowing that stuff is being done under the hood to optimize I2P</p>
13:44 < jrandom> as gott quoted, diy, do or die</p>
13:45 < jrandom> yeah, the memory churn was getting to be a substantial portion of the CPU time</p>
13:45 < jrandom> so it was finally worth the effort to optimize</p>
13:45 < deer> &lt;baffled&gt; Sorry, have to catch a bus I'll read the logs later night.</p>
13:45 < deer> &lt;peer&gt; hi just a bug report</p>
13:45 < jrandom> (as its cut down streaming lib test time by a factor of 5)</p>
13:45 < jrandom> cool baffled, ttyl</p>
13:46 < deer> &lt;peer&gt; when your net connection goes down, i2p dies</p>
13:46 < dm> These are the kind of things that creep up on you, good to get them out of the way while the project is still lean.</p>
13:46 < deer> * postman noticed this too a few days ago</p>
13:46 < deer> &lt;postman&gt; one of my servers lost its link</p>
13:46 < deer> &lt;postman&gt; for a few mins - after that i2p was good for a complete restart</p>
13:46 < jrandom> dies, as in, the JVM stops, or the router stops talking to peers?</p>
13:47 < jrandom> (it obviously stops talking to peers, i mean, after the net is back up, does it recover?)</p>
13:47 < deer> &lt;postman&gt; jrandom: in my case jvm was still running - but no connection lead to success for about 15 minutes</p>
13:47 < deer> &lt;postman&gt; jrandom: after that i restarted</p>
13:47 < jrandom> hmm, ok, cool</p>
13:48 < jrandom> thanks peer, postman. i'll do some debugging down there</p>
13:48 < jrandom> what OSes, btw?</p>
13:48 < deer> &lt;postman&gt; jrandom: np - wanted to write you a mail but forgeot</p>
13:49 < deer> &lt;postman&gt; jrandom: Linux 2.4.recent - glibc2.3.recent jvm 1.4.05</p>
13:49 * jrandom suspects that this week will be the week of "break shit and make i2p handle it better"</p>
13:49 < jrandom> word</p>
13:50 < deer> &lt;peer&gt; jrandom: in my case the jvm went completely</p>
13:50 < jrandom> did it say OutOfMemory or have any CRIT messages? or did it create a hs_* file inyour i2p install dir?</p>
13:52 < jrandom> perhaps we could dig through the details later, after the meeting</p>
13:52 < jrandom> does anyone have anything else on 2) core updates?</p>
13:52 < jrandom> if not, on to 3) streaming lib</p>
13:53 < dm> yeah</p>
13:53 < dm> this increased latency</p>
13:53 < dm> do you have an estimated % increase per hop?</p>
13:53 < dm> we talking a couple % points or 30-40%?</p>
13:53 < jrandom> none, its just some situations it didn't send through an outbound tunnel</p>
13:54 < dm> so negligeable... 'kay</p>
13:54 < dm> (on average)</p>
13:54 < dm> 3)</p>
13:54 < jrandom> 0% per hop, but its as if the peer you talk to has tunnels 1 hop longer than before (on average)</p>
13:55 < jrandom> not many real visible updates for the streaming lib so far</p>
13:55 < jrandom> things work pretty well, and i've been doing a bunch of benchmarks to track the progress during the recent memory updating</p>
13:55 < dm> oh throughput numbers!!!</p>
13:57 < dm> ping</p>
13:57 < deer> &lt;Natalia&gt; .</p>
13:57 < jrandom> well, it varied on the message size and per-hop latency injected, but preliminary throughput has been 2-5x faster</p>
13:57 < jrandom> it has been CPU bound though</p>
13:57 < dm> hmmm, not bad.</p>
13:58 < dm> cpu at which end?</p>
13:58 < jrandom> the big benefit is in the reduction of data retransmission and the virtual elimination of failure ;)</p>
13:59 < jrandom> dm: these tests were done with the sim, injecting random delays per hop</p>
13:59 < jrandom> (e.g. 400ms each time, or 1000ms, or 2000ms)</p>
13:59 < dm> Is there some kind of priority scheme so that forwarding of messages of tunnels won't be too affected by people trying to download at 30k/s and maxing out their CPU?</p>
13:59 < jrandom> (well, the *big* benefit is the sliding window and reordering, but reduction of retransmit is good)</p>
14:00 < jrandom> not sure i understand</p>
14:00 < dm> Like if I'm downloading porn, will I inject a 3s lag to anyone who's going through me in their tunnels.</p>
14:00 < jrandom> (and the transfer rates were much higher than 30KBps, but again, this was local-only with random injected delays)</p>
14:01 < dm> I'm just wondering what happens in general if someone is maxing out their CPU, as far as their contribution to the network is concerned.</p>
14:01 < dm> I guess it's not specific to abusing the streaming lib.</p>
14:02 < jrandom> you're not going to be maxing your CPU doing streaming, the CPU load was something i run into when using the local sim running a ton of routers on a single box</p>
14:02 < dm> ah alright, I thought the cpu was maxed with one router trying to encrypt all the bits going down the pipe.</p>
14:02 < jrandom> nah, encryption is ReallyReallyFast</p>
14:03 < dm> coo'</p>
14:03 < jrandom> ok, anyone else have any questions wrt the streaming lib progress?</p>
14:03 < jrandom> if not, 4) mail.i2p progress</p>
14:04 < deer> &lt;jrandom&gt; postman, you 'round?</p>
14:04 < deer> &lt;postman&gt; yo :)</p>
14:04 < deer> &lt;postman&gt; ok</p>
14:04 < deer> * postman waves</p>
14:05 < deer> &lt;postman&gt; well, gentlemen. Some of you may have noticed that we have finally implemented in/out services</p>
14:05 < jrandom> [w00t!]</p>
14:05 < deer> &lt;postman&gt; please reas www.postman.i2p/inout.html</p>
14:05 < deer> &lt;postman&gt; please test the system out</p>
14:06 < deer> &lt;postman&gt; baffled will deliver the 2nd official mx</p>
14:06 < jrandom> word</p>
14:06 < deer> &lt;postman&gt; right now i am working on IMAP implementation</p>
14:07 < deer> &lt;postman&gt; this means a switch to maildir format soon</p>
14:07 < jrandom> we'll need to recheck various clients for that though, right?</p>
14:07 < deer> &lt;postman&gt; right now i am evaluating/testing</p>
14:07 < jrandom> cool</p>
14:07 < deer> &lt;Natalia&gt; why IMAP and not pop3 ?</p>
14:07 < deer> &lt;postman&gt; yeah, and the serverside as well</p>
14:08 < deer> &lt;postman&gt; Natalia: we have pop3 already</p>
14:08 < deer> &lt;postman&gt; pop3 can be used of course </p>
14:08 < deer> &lt;postman&gt; IMAP4 will make us more flexible for webmail systems (hopefully)</p>
14:10 < deer> &lt;postman&gt; this is still open issue</p>
14:10 < deer> &lt;Natalia&gt; okay.</p>
14:10 < deer> &lt;Natalia&gt; you sounded like you were going to switch from pop3 to IMAP</p>
14:11 < deer> &lt;postman&gt; no, of course not</p>
14:11 < deer> &lt;postman&gt; jrandom: are there any news concerning locally run webmail?</p>
14:12 < jrandom> not to my knowledge. i havent had time to look into it at all</p>
14:12 < deer> * postman neither</p>
14:12 < jrandom> there were those discussions of atmail, but they're closed source</p>
14:12 < deer> &lt;postman&gt; mmh, yes</p>
14:13 < deer> &lt;postman&gt; but something jspish ?</p>
14:13 < jrandom> 'twould be a really great way for a volunteer to jump in and do some legword :)</p>
14:13 < deer> &lt;Natalia&gt; well, I've added this description to gott.i2p/sites.html</p>
14:13 < deer> * postman is completely unable to do research on that matter</p>
14:13 < deer> &lt;Natalia&gt; for www.postman.i2p</p>
14:13 < deer> &lt;Natalia&gt; postman runs i2p's first mail-service, providing free and anonymous pop3 and SMTP </p>
14:13 < deer> &lt;Natalia&gt; accounts over i2p. Recently implemented is the ability to send and receive e-mails to and </p>
14:13 < deer> &lt;Natalia&gt; from outside of the i2p network, marking the services of www.postman.i2p as a nifty </p>
14:13 < deer> &lt;Natalia&gt; destination for any concerned e-mailer and soon a must-have, as mail.i2p e-mail accounts </p>
14:13 < deer> &lt;Natalia&gt; become the norm for eepsite-authors.</p>
14:14 < deer> &lt;Natalia&gt; sound good ?</p>
14:14 < deer> &lt;postman&gt; thanks Natalia :)</p>
14:14 < deer> &lt;postman&gt; jrandom: i think it's not a urgent issue</p>
14:14 < deer> * Natalia curtsies :)</p>
14:15 < deer> &lt;postman&gt; jrandom: maybe we pick up the webmail issue later again :)</p>
14:15 < jrandom> agreed postman</p>
14:15 < deer> &lt;postman&gt; that's all from my side , thanks :)</p>
14:15 < jrandom> word, thanks postman</p>
14:15 < deer> * postman curtsie too and sits down again</p>
14:15 < jrandom> ok, anything else on that, or shall we move on to 5) BT progress?</p>
14:16 < deer> &lt;jrandom&gt; dinoman: you 'round?</p>
14:16 < dm> Yeah, I'm still waiting for BT to reactivate my ADSL</p>
14:16 < jrandom> !thwap</p>
14:17 < deer> &lt;duck&gt; dino has done some good work</p>
14:17 < deer> &lt;duck&gt; with Ragnarok to fix some ends</p>
14:17 < deer> &lt;duck&gt; so far it looks like the current problems are:</p>
14:17 < deer> &lt;duck&gt; - SAM unreliability</p>
14:17 < deer> &lt;duck&gt; - Python SAM library issues</p>
14:17 < deer> &lt;duck&gt; - Incorrect usage of the Python SAM lib</p>
14:18 < deer> &lt;duck&gt; - Correct handleing of destination instead of host/ip/port</p>
14:18 < deer> &lt;duck&gt; once those are fixed it should work</p>
14:18 < jrandom> cool</p>
14:19 < deer> &lt;duck&gt; I think it is needed to take a little step back though</p>
14:19 < deer> &lt;duck&gt; and agree on how to modify the protocol to properly handle destinations</p>
14:19 < deer> &lt;duck&gt; it will be incompatible anyway, so better break it good</p>
14:19 < jrandom> i concur</p>
14:20 < jrandom> perhaps someone can mock up an overall plan of what needs to be done to various apps/components to get it working</p>
14:20 < deer> &lt;duck&gt; each peer has an unique peer_id of 20 bytes</p>
14:20 < deer> &lt;duck&gt; it is normally derived from the host/ip</p>
14:21 < deer> &lt;duck&gt; I think that using the full destination is a bit much</p>
14:21 < deer> &lt;duck&gt; what globally unique thing should we use?</p>
14:21 < jrandom> SHA1(destination)[0:19]</p>
14:21 < jrandom> perhaps?</p>
14:21 < deer> &lt;Ragnarok&gt; first twenty bytes of the dest? :)</p>
14:22 < deer> &lt;duck&gt; a sha1 hash is 20 bytes</p>
14:22 < jrandom> first 20 bytes of the dest should be pretty random too, enough to deal with random clashes, but not to deal with hostile colisions</p>
14:22 < jrandom> even better </p>
14:22 < deer> &lt;dinoman&gt; if you lose the key how do peers find one another</p>
14:22 < jrandom> a peer *is* a key</p>
14:23 < jrandom> oh</p>
14:23 * jrandom misinterpreted</p>
14:23 < jrandom> the tracker must give peers the full destination, not the SHA1(destination)</p>
14:24 < jrandom> is that the same peer_id in question?</p>
14:24 < deer> &lt;dinoman&gt; i have fixed the php tracker to send the full key as the ip</p>
14:24 < deer> &lt;duck&gt; actually the client generates the peer_id</p>
14:24 < deer> &lt;duck&gt; (what do you mean with 'key'?)</p>
14:25 < deer> &lt;dinoman&gt; destination</p>
14:25 < dm> Sounds like a who's on first skit.</p>
14:25 < dm> Use full sentences people!</p>
14:26 < deer> &lt;dinoman&gt; ok fine :/ the tracker sends the Full destination as the ip</p>
14:27 < jrandom> heh dont mind dm. sounds great</p>
14:27 < deer> &lt;dinoman&gt; peer id is just for the trackers</p>
14:27 < deer> &lt;duck&gt; maybe we could use #i2p-bt</p>
14:28 < jrandom> what i think would be useful though is if you (or someone else) could perhaps draft up a list of modifications that'll need to be made</p>
14:28 < deer> &lt;duck&gt; so no religious wars start each time the name of the snake is dropped</p>
14:29 < deer> &lt;dinoman&gt; works for me</p>
14:29 < deer> &lt;dinoman&gt; i don't war if it works it works</p>
14:29 < jrandom> (e.g. "tracker sends e full destination as the IP", "client interprets the IP as the full destination", "torrent contains the tracker's destination in the field 'trackerDest'", etc)</p>
14:29 < deer> &lt;duck&gt; definitly</p>
14:30 < deer> &lt;dinoman&gt; jrandom you got it</p>
14:31 < deer> &lt;dinoman&gt; this is the sample output of the tracker 8:intervali300e12:min intervali30e5:peersld2:ip50:klkjlkfsdjfkljkfdhjkddfsjkldsfjlkjfdlkjsfdl;kj;sdf7:peer</p>
14:31 < dm> copy/pastes jrandom's sentence into notepad and saves as "draft.txt"</p>
14:31 < cat-a-puss> will bt over i2p be intercompatible with other clients that are not over i2p?</p>
14:31 < jrandom> cool dinoman</p>
14:31 < deer> &lt;dinoman&gt; at ip50 you will see a junk key</p>
14:32 < jrandom> cat-a-puss: yes</p>
14:32 < deer> &lt;dinoman&gt; yes</p>
14:32 < cat-a-puss> then we should talk</p>
14:32 < jrandom> welcome to the weekly meeting! :)</p>
14:32 < deer> &lt;dinoman&gt; it will need to be something like .i2ptorrent to make it live togeter</p>
14:32 < deer> &lt;dinoman&gt; for filenames and links and what not</p>
14:33 < jrandom> are you working on something similar cat-a-puss, or have some ideas for improvements?</p>
14:33 < cat-a-puss> working on something similar</p>
14:33 < cat-a-puss> in java</p>
14:33 < jrandom> cool</p>
14:34 < jrandom> is it necessarily java specific, or can some peers be in other langs?</p>
14:34 < cat-a-puss> good question, I don't know how to work that sort of thing in java, I'll have to look into it</p>
14:35 < deer> &lt;duck&gt; right</p>
14:35 < deer> &lt;duck&gt; lets use ugha.i2p to write up some specs</p>
14:35 < deer> &lt;duck&gt; .</p>
14:35 < jrandom> or perhaps we need a "swarming data transfer" section in the forum so we can all discuss this stuff at our own pace?</p>
14:35 < jrandom> or ugha.i2p, of course</p>
14:36 < jrandom> (while we work through some bugs in the sam impl and libs :)</p>
14:36 < deer> &lt;duck&gt; makes it all a challenge</p>
14:37 < deer> &lt;dinoman&gt; hehe ok</p>
14:38 < deer> &lt;duck&gt; ...</p>
14:38 < deer> &lt;duck&gt; mo bt?</p>
14:38 < deer> * dinoman gets back to work on Savane</p>
14:39 < jrandom> http://ugha.i2p/SwarmingTransfer / http://ugha.ath.cx/SwarmingTransfer</p>
14:39 < jrandom> word</p>
14:39 < jrandom> ok, anything else on 5) BT progress?</p>
14:39 < jrandom> or shall we hit 6) ???</p>
14:39 < jrandom> and ask dinoman how the Savane progress is coming? :)</p>
14:40 < deer> * jrandom cracks whip</p>
14:40 < deer> &lt;dinoman&gt; mail i am stuck on using the i2p mail system</p>
14:40 < deer> &lt;dinoman&gt; i think i should just take the mail out</p>
14:40 < jrandom> is there any way to tell it to use the SMTP server at a different port?</p>
14:40 < jrandom> or is the problem authenticated SMTP?</p>
14:41 < deer> &lt;dinoman&gt; auth</p>
14:41 < protok0l> Uptime: 5d</p>
14:41 < protok0l> ii own</p>
14:41 < deer> &lt;dinoman&gt; it is not in the class Savane uses</p>
14:42 < deer> &lt;dinoman&gt; i can put it in </p>
14:42 < protok0l> i'm "Ident: pxEI" can someone tell me my rating</p>
14:42 < jrandom> ok, i bet we can just get postman to set you up with a custom SMTP destination that doesnt require authentication</p>
14:42 < dm> I give you a 6/10</p>
14:42 < dm> You could work on your ass a bit</p>
14:42 < janonymous1> Whats savana</p>
14:43 < jrandom> janonymous1: its like sourceforge</p>
14:43 < deer> &lt;dinoman&gt; because i am looking at the I2P Public Domain Software Homepage in my browser now</p>
14:43 < jrandom> w00t</p>
14:45 < deer> &lt;dinoman&gt; that would be cool be what is being done on the server i don't want someone hacking me and the getting the info about the mail server</p>
14:45 < deer> &lt;dinoman&gt; that is what bugs me</p>
14:45 < jrandom> well, they wouldn't get any info on the mail server, they'd just be able to (at worst) spoof @mail.i2p</p>
14:45 < janonymous1> Cool</p>
14:46 < jrandom> but yeah, it'd be great to have authenticated SMTP support to prevent that</p>
14:46 < jrandom> i dont know how much work that'd be though</p>
14:46 < protok0l> well im glad i left my mailserver idea to postman</p>
14:46 < protok0l> it seem more difficult than i imagined</p>
14:47 < deer> &lt;Ch0Hag&gt; I wouldn't mind helping with that</p>
14:47 < dm> protocol</p>
14:47 < deer> &lt;Ch0Hag&gt; Got to do something. :-)</p>
14:47 < deer> &lt;dinoman&gt; i will do auth :( it will take a little time but i will do it</p>
14:47 < deer> &lt;protokol&gt; yes dm</p>
14:48 < jrandom> see, you've got a volunteer already dinoman! :)</p>
14:48 < deer> &lt;protokol&gt; maybe i could host a nessus server</p>
14:48 < deer> &lt;protokol&gt; and tunnel it through TOR on my side</p>
14:49 < deer> &lt;Ch0Hag&gt; Plus I need a good excuse to work on the rest of my network.</p>
14:49 < deer> &lt;protokol&gt; and i shall dedicate myself to learning python</p>
14:49 < janonymous1> 'the i2p software foundation'. I can see it now</p>
14:49 < deer> &lt;protokol&gt; and how to correctly type</p>
14:49 < dm> I shall dedicate myself to the pursuit of more money for myself and for those directly related to myself, who may be inclined to give me money in the near future.</p>
14:50 < jrandom> ok, anyone else have anything to bring up for 6) ??? </p>
14:50 < dm> 7) $$$</p>
14:51 < duck> Roger Dingledine (arma @ freenode) published a draft for a chapter of an upcoming O'Reilly book</p>
14:51 < duck> http://freehaven.net/doc/wupss04/usability.pdf</p>
14:51 < jrandom> ah, yeah, its pretty good</p>
14:51 < duck> it is about anonymity and usability</p>
14:51 < dm> chapter on usability?</p>
14:51 < deer> &lt;protokol&gt; i can run the i2p software foundation</p>
14:51 < deer> &lt;protokol&gt; lol</p>
14:51 < duck> some interesting parts about negative imago</p>
14:52 < deer> &lt;protokol&gt; give me the keys the the treasury</p>
14:52 < duck> having good default</p>
14:52 < deer> &lt;protokol&gt; NOW!</p>
14:52 < duck> etc</p>
14:52 < duck> .</p>
14:52 < jrandom> and the importance of usability, even over security at times</p>
14:52 < dm> protok0l: you're the user advocate aren't you? You should read that document.</p>
14:52 < jrandom> 'k, anything else for the meeting?</p>
14:52 < deer> &lt;protokol&gt; wow, im seeing 83 peers</p>
14:52 < duck> now we know why there are so few known hidden sides on tor</p>
14:53 < deer> &lt;protokol&gt; dm: i shall</p>
14:53 < duck> arma is affraid for negative imago</p>
14:53 < duck> .</p>
14:53 < dm> "imago" ?</p>
14:53 < duck> image</p>
14:53 < deer> &lt;duck&gt; (psychoanalysis) an idealized image of someone</p>
14:53 < dm> No mention of I2P in there :(</p>
14:53 < duck> jrandom: aint we?</p>
14:54 < jrandom> hm?</p>
14:54 < dm> he means aren't we. He's dutch.</p>
14:54 < duck> if some specific group now moves to i2p,</p>
14:54 < duck> they could keep away much needed other users</p>
14:55 < jrandom> oh, thats in there? i didnt see that</p>
14:55 < duck> no, I am saying that</p>
14:55 < duck> but it is in there too, more or less</p>
14:55 < duck> ofcourse andy anarchist doesnt give a fuck</p>
14:56 < jrandom> well, i do think there is room for both i2p and tor</p>
14:56 < duck> yes</p>
14:56 < duck> but what about early negative image on I2P</p>
14:56 < deer> &lt;Natalia&gt; this is the reason I am forced to be a somewhat mundane female on this IRC channel</p>
14:56 < protok0l> haha, when i get the word every major anarchist listserv and forum will hear about i2p within a day or 2</p>
14:56 < jrandom> oh, i dont give a flying fuck about that duck ;)</p>
14:56 < deer> &lt;Natalia&gt; jrandom doesn't approve of got</p>
14:56 < deer> &lt;Natalia&gt; *gott</p>
14:57 < duck> jrandom: yeah, but well</p>
14:57 * duck counts the amount of anarchy friendly regions on the globe</p>
14:57 < deer> &lt;Natalia&gt; so I have to be Natalia, the loved female of the channel</p>
14:57 < deer> &lt;Natalia&gt; ( lame )</p>
14:57 < duck> somalia?</p>
14:57 < duck> I bet they have flying fucks there</p>
14:57 < protok0l> Chiapas, mexica</p>
14:57 < duck> but not friendly ones</p>
14:57 < protok0l> mexiico</p>
14:58 < deer> &lt;Ragnarok&gt; bah, you want to be feminized</p>
14:58 < jrandom> duck: when it comes time to be more public, i'm certain we can put on a reasonable joe sixpack friendly face</p>
14:58 < duck> k</p>
14:58 < jrandom> will people do "bad" things with i2p? yeah</p>
14:58 < dm> I think we should target joe beergut</p>
14:58 < protok0l> good luck, i know gott is planning something</p>
14:58 < protok0l> gott will destroy us</p>
14:58 < duck> ok</p>
14:58 < duck> .</p>
14:58 < jrandom> the only way any worthwhile anonymity or security system can survive is to be content neutral</p>
14:59 < deer> &lt;Ragnarok&gt; anonymous communication systems can only protect communication. They don't interfere with good old police work if someone actually *does* something.</p>
14:59 < duck> just saying that some links placed on http://127.0.0.1:7657/index.jsp could be bad</p>
14:59 < dm> I2P is about technology.</p>
14:59 < deer> &lt;Natalia&gt; yes</p>
14:59 < jrandom> true enough duck</p>
15:00 < duck> and yes, the sitelist.html will turn into a TFE discussion thing all over</p>
15:00 < jrandom> well, mmhmm</p>
15:00 < deer> &lt;Natalia&gt; content neutrality is something I write about in the latest eeplog entry</p>
15:00 < deer> &lt;Natalia&gt; http://gott.i2p/eeplog.html</p>
15:01 < jrandom> this is, however, the power of interactive eepsites, like wikis</p>
15:01 < jrandom> (e.g. having people register their site with a sitelist.py or whatever)</p>
15:01 < deer> &lt;Natalia&gt; jrandom: do you support not support the idea of eepsite crawlers linking to illegal material, being linked from the frontpage ?</p>
15:01 < deer> &lt;Natalia&gt; +or</p>
15:01 < deer> &lt;Natalia&gt; if you were going to link to the sitelist</p>
15:02 < duck> from a moral point I dont give a flying fuck either</p>
15:02 < deer> &lt;Natalia&gt; jrandom: none of these are registered</p>
15:02 < duck> but from an usability point I might</p>
15:02 < deer> &lt;Natalia&gt; the script checks host.txt</p>
15:02 < deer> &lt;Natalia&gt; *hosts.txt</p>
15:02 < jrandom> from a nontechnical perspective, i support whatever the user community requires</p>
15:02 < deer> &lt;Natalia&gt; so everyone gets added to the list if they have a domain</p>
15:03 < deer> &lt;Natalia&gt; ugh, bras are so uncomfortable.</p>
15:03 < protok0l> yup, creepy</p>
15:03 < deer> &lt;cervantes&gt; have you _seen_ the user community?</p>
15:03 < cat-a-puss> The simplist solution would be to simply link to search pages, Everyone knows how to use them, they provide fast access, and nobody sees for anything they did not ask for.</p>
15:04 < deer> &lt;cervantes&gt; :)</p>
15:04 < protok0l> gott is a serial killer, i know it. he will be the first to offer live murders via webcam on i2p</p>
15:04 < deer> &lt;Natalia&gt; the user community consists of rather strange people.</p>
15:04 < jrandom> good point cat-a-puss, we could just link to files.i2p </p>
15:04 < deer> &lt;Natalia&gt; at the moment, I am forced to be a woman because the lead developer disapproves of the immoral behaviour of my other.</p>
15:04 < duck> cat-a-puss++</p>
15:04 < deer> &lt;Natalia&gt; we are united through common adventure.</p>
15:06 < BS314159> I'm not convinced this is a good idea, but the I2P license is certainly broad enough for people to spin off their own versions, differing only in the local link pages</p>
15:06 < deer> &lt;Natalia&gt; well.</p>
15:06 < deer> &lt;cervantes&gt; lets hope DrWoo can keep his indices free of corruption</p>
15:06 < jrandom> certainly BS314159 </p>
15:06 < BS314159> not versions. distributions.</p>
15:06 < deer> &lt;Natalia&gt; files.i2p should be one link</p>
15:06 < jrandom> BS314159: people can even edit their own local link page</p>
15:06 < deer> &lt;Natalia&gt; and then there should be a yahoo-style internet directory link</p>
15:06 < protok0l> most people will be wise enuf to use the official version</p>
15:06 < jrandom> (in docs/readme.html)</p>
15:07 < deer> &lt;Natalia&gt; search engines and internet directories serve different roles</p>
15:07 < deer> &lt;Natalia&gt; this is why the directory is there in the first place</p>
15:07 < deer> &lt;Natalia&gt; it has been requested as independent of a search engine</p>
15:07 < BS314159> so if you want e.g. to target an anti-pornography demographic, find an anti-pornography maintainer who maintains a filtered default start page set</p>
15:07 < protok0l> unless they are willing to search for backdoors in third-party versions</p>
15:07 < deer> &lt;Natalia&gt; by people</p>
15:07 < deer> &lt;Natalia&gt; so I think the search-engine is good</p>
15:07 < jrandom> right BS314159 </p>
15:07 < deer> &lt;Natalia&gt; but should not be the limit</p>
15:07 < deer> &lt;Natalia&gt; search engine, internet directory, wiki, help page</p>
15:07 < deer> &lt;Natalia&gt; perhaps.</p>
15:08 < jrandom> we already link to fproxy.i2p, and we know what scary evil content they have on that site ;)</p>
15:08 < BS314159> I'm not sure I'm on topic, but that seems possible. Is there an open-source content filter that any search-engine maintainers would be willing to implement support for?</p>
15:08 < BS314159> I have a feeling I'm not on topic</p>
15:08 < protok0l> is the meeting still on?</p>
15:08 < jrandom> yes protok0l </p>
15:08 < BS314159> sorry. (silences self)</p>
15:08 < deer> &lt;Natalia&gt; jrandom: perhaps you shouldn't link to fproxy.i2p</p>
15:08 < deer> &lt;Natalia&gt; it is almost always down</p>
15:08 < jrandom> BS314159: i think a cntent filter in the search engine is excessive</p>
15:08 < deer> &lt;Natalia&gt; it is down right now, it seems</p>
15:09 < protok0l> it is</p>
15:09 < deer> &lt;Natalia&gt; according to the recent run of the site-checking script</p>
15:09 < jrandom> 'k</p>
15:09 < jrandom> well, this has been a good discussion, lots of good ideas</p>
15:09 < BS314159> not _the_ search engine. _someone_'s search engine</p>
15:10 < deer> * Natalia smiles.</p>
15:10 < deer> &lt;cervantes&gt; BS3: aol.i2p ;-)</p>
15:10 < jrandom> ok, is there anything else for the meeting?</p>
15:10 < deer> &lt;cervantes&gt; whoa...still in the meeting...</p>
15:11 < deer> &lt;cervantes&gt; thought I'd missed that by an hour</p>
15:11 < jrandom> nope, i was late</p>
15:11 < jrandom> ok, if not..</p>
15:11 * jrandom winds up</p>
15:11 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:37 < jrandom> 0) hi
13:37 < jrandom> 1) Net status
13:37 < jrandom> 2) Core updates
13:37 < jrandom> 3) Streaming lib
13:37 < jrandom> 4) mail.i2p progress
13:38 < jrandom> 5) BT progress
13:38 < jrandom> 6) ???
13:38 < jrandom> 0) hi
13:38 < jrandom> sorry for the delay, weekly status notes posted @ http://dev.i2p.net/pipermail/i2p/2004-November/000477.html
13:38 < dm> meeting in 24 or 84?
13:38 < jrandom> 0
13:38 < dm> oh.. -36?
13:39 < jrandom> yup, 9p GMT
13:39 < jrandom> but i forgot that, so we're starting... now ;)
13:39 < jrandom> 1) net status
13:39 < dm> good timing
13:39 < jrandom> well, no real change in the net status from my end - does anyone have anything they'd like to bring up about it?
13:41 < jrandom> if not, might as well move on to 2) core updates
13:41 < jrandom> i dont really have anything to add beyond whats in the email, so i'll give people a min to digest
13:42 < deer> <postman> arg
13:42 < jrandom> there've been 8 patches since the release, with another one or two pending. we'll probably just tag those all up into a 0.4.1.4, as the streaming lib itself isn't ready
13:43 < deer> <jrandom> wb, its looking a bit bumpy over here
13:43 < deer> <postman> np, i am back :)
13:43 < protok0l> any word on aum's disappearance? i want stasher!
13:44 * dm likes knowing that stuff is being done under the hood to optimize I2P
13:44 < jrandom> as gott quoted, diy, do or die
13:45 < jrandom> yeah, the memory churn was getting to be a substantial portion of the CPU time
13:45 < jrandom> so it was finally worth the effort to optimize
13:45 < deer> <baffled> Sorry, have to catch a bus I'll read the logs later night.
13:45 < deer> <peer> hi just a bug report
13:45 < jrandom> (as its cut down streaming lib test time by a factor of 5)
13:45 < jrandom> cool baffled, ttyl
13:46 < deer> <peer> when your net connection goes down, i2p dies
13:46 < dm> These are the kind of things that creep up on you, good to get them out of the way while the project is still lean.
13:46 < deer> * postman noticed this too a few days ago
13:46 < deer> <postman> one of my servers lost its link
13:46 < deer> <postman> for a few mins - after that i2p was good for a complete restart
13:46 < jrandom> dies, as in, the JVM stops, or the router stops talking to peers?
13:47 < jrandom> (it obviously stops talking to peers, i mean, after the net is back up, does it recover?)
13:47 < deer> <postman> jrandom: in my case jvm was still running - but no connection lead to success for about 15 minutes
13:47 < deer> <postman> jrandom: after that i restarted
13:47 < jrandom> hmm, ok, cool
13:48 < jrandom> thanks peer, postman. i'll do some debugging down there
13:48 < jrandom> what OSes, btw?
13:48 < deer> <postman> jrandom: np - wanted to write you a mail but forgeot
13:49 < deer> <postman> jrandom: Linux 2.4.recent - glibc2.3.recent jvm 1.4.05
13:49 * jrandom suspects that this week will be the week of "break shit and make i2p handle it better"
13:49 < jrandom> word
13:50 < deer> <peer> jrandom: in my case the jvm went completely
13:50 < jrandom> did it say OutOfMemory or have any CRIT messages? or did it create a hs_* file inyour i2p install dir?
13:52 < jrandom> perhaps we could dig through the details later, after the meeting
13:52 < jrandom> does anyone have anything else on 2) core updates?
13:52 < jrandom> if not, on to 3) streaming lib
13:53 < dm> yeah
13:53 < dm> this increased latency
13:53 < dm> do you have an estimated % increase per hop?
13:53 < dm> we talking a couple % points or 30-40%?
13:53 < jrandom> none, its just some situations it didn't send through an outbound tunnel
13:54 < dm> so negligeable... 'kay
13:54 < dm> (on average)
13:54 < dm> 3)
13:54 < jrandom> 0% per hop, but its as if the peer you talk to has tunnels 1 hop longer than before (on average)
13:55 < jrandom> not many real visible updates for the streaming lib so far
13:55 < jrandom> things work pretty well, and i've been doing a bunch of benchmarks to track the progress during the recent memory updating
13:55 < dm> oh throughput numbers!!!
13:57 < dm> ping
13:57 < deer> <Natalia> .
13:57 < jrandom> well, it varied on the message size and per-hop latency injected, but preliminary throughput has been 2-5x faster
13:57 < jrandom> it has been CPU bound though
13:57 < dm> hmmm, not bad.
13:58 < dm> cpu at which end?
13:58 < jrandom> the big benefit is in the reduction of data retransmission and the virtual elimination of failure ;)
13:59 < jrandom> dm: these tests were done with the sim, injecting random delays per hop
13:59 < jrandom> (e.g. 400ms each time, or 1000ms, or 2000ms)
13:59 < dm> Is there some kind of priority scheme so that forwarding of messages of tunnels won't be too affected by people trying to download at 30k/s and maxing out their CPU?
13:59 < jrandom> (well, the *big* benefit is the sliding window and reordering, but reduction of retransmit is good)
14:00 < jrandom> not sure i understand
14:00 < dm> Like if I'm downloading porn, will I inject a 3s lag to anyone who's going through me in their tunnels.
14:00 < jrandom> (and the transfer rates were much higher than 30KBps, but again, this was local-only with random injected delays)
14:01 < dm> I'm just wondering what happens in general if someone is maxing out their CPU, as far as their contribution to the network is concerned.
14:01 < dm> I guess it's not specific to abusing the streaming lib.
14:02 < jrandom> you're not going to be maxing your CPU doing streaming, the CPU load was something i run into when using the local sim running a ton of routers on a single box
14:02 < dm> ah alright, I thought the cpu was maxed with one router trying to encrypt all the bits going down the pipe.
14:02 < jrandom> nah, encryption is ReallyReallyFast
14:03 < dm> coo'
14:03 < jrandom> ok, anyone else have any questions wrt the streaming lib progress?
14:03 < jrandom> if not, 4) mail.i2p progress
14:04 < deer> <jrandom> postman, you 'round?
14:04 < deer> <postman> yo :)
14:04 < deer> <postman> ok
14:04 < deer> * postman waves
14:05 < deer> <postman> well, gentlemen. Some of you may have noticed that we have finally implemented in/out services
14:05 < jrandom> [w00t!]
14:05 < deer> <postman> please reas www.postman.i2p/inout.html
14:05 < deer> <postman> please test the system out
14:06 < deer> <postman> baffled will deliver the 2nd official mx
14:06 < jrandom> word
14:06 < deer> <postman> right now i am working on IMAP implementation
14:07 < deer> <postman> this means a switch to maildir format soon
14:07 < jrandom> we'll need to recheck various clients for that though, right?
14:07 < deer> <postman> right now i am evaluating/testing
14:07 < jrandom> cool
14:07 < deer> <Natalia> why IMAP and not pop3 ?
14:07 < deer> <postman> yeah, and the serverside as well
14:08 < deer> <postman> Natalia: we have pop3 already
14:08 < deer> <postman> pop3 can be used of course
14:08 < deer> <postman> IMAP4 will make us more flexible for webmail systems (hopefully)
14:10 < deer> <postman> this is still open issue
14:10 < deer> <Natalia> okay.
14:10 < deer> <Natalia> you sounded like you were going to switch from pop3 to IMAP
14:11 < deer> <postman> no, of course not
14:11 < deer> <postman> jrandom: are there any news concerning locally run webmail?
14:12 < jrandom> not to my knowledge. i havent had time to look into it at all
14:12 < deer> * postman neither
14:12 < jrandom> there were those discussions of atmail, but they're closed source
14:12 < deer> <postman> mmh, yes
14:13 < deer> <postman> but something jspish ?
14:13 < jrandom> 'twould be a really great way for a volunteer to jump in and do some legword :)
14:13 < deer> <Natalia> well, I've added this description to gott.i2p/sites.html
14:13 < deer> * postman is completely unable to do research on that matter
14:13 < deer> <Natalia> for www.postman.i2p
14:13 < deer> <Natalia> postman runs i2p's first mail-service, providing free and anonymous pop3 and SMTP
14:13 < deer> <Natalia> accounts over i2p. Recently implemented is the ability to send and receive e-mails to and
14:13 < deer> <Natalia> from outside of the i2p network, marking the services of www.postman.i2p as a nifty
14:13 < deer> <Natalia> destination for any concerned e-mailer and soon a must-have, as mail.i2p e-mail accounts
14:13 < deer> <Natalia> become the norm for eepsite-authors.
14:14 < deer> <Natalia> sound good ?
14:14 < deer> <postman> thanks Natalia :)
14:14 < deer> <postman> jrandom: i think it's not a urgent issue
14:14 < deer> * Natalia curtsies :)
14:15 < deer> <postman> jrandom: maybe we pick up the webmail issue later again :)
14:15 < jrandom> agreed postman
14:15 < deer> <postman> that's all from my side , thanks :)
14:15 < jrandom> word, thanks postman
14:15 < deer> * postman curtsie too and sits down again
14:15 < jrandom> ok, anything else on that, or shall we move on to 5) BT progress?
14:16 < deer> <jrandom> dinoman: you 'round?
14:16 < dm> Yeah, I'm still waiting for BT to reactivate my ADSL
14:16 < jrandom> !thwap
14:17 < deer> <duck> dino has done some good work
14:17 < deer> <duck> with Ragnarok to fix some ends
14:17 < deer> <duck> so far it looks like the current problems are:
14:17 < deer> <duck> - SAM unreliability
14:17 < deer> <duck> - Python SAM library issues
14:17 < deer> <duck> - Incorrect usage of the Python SAM lib
14:18 < deer> <duck> - Correct handleing of destination instead of host/ip/port
14:18 < deer> <duck> once those are fixed it should work
14:18 < jrandom> cool
14:19 < deer> <duck> I think it is needed to take a little step back though
14:19 < deer> <duck> and agree on how to modify the protocol to properly handle destinations
14:19 < deer> <duck> it will be incompatible anyway, so better break it good
14:19 < jrandom> i concur
14:20 < jrandom> perhaps someone can mock up an overall plan of what needs to be done to various apps/components to get it working
14:20 < deer> <duck> each peer has an unique peer_id of 20 bytes
14:20 < deer> <duck> it is normally derived from the host/ip
14:21 < deer> <duck> I think that using the full destination is a bit much
14:21 < deer> <duck> what globally unique thing should we use?
14:21 < jrandom> SHA1(destination)[0:19]
14:21 < jrandom> perhaps?
14:21 < deer> <Ragnarok> first twenty bytes of the dest? :)
14:22 < deer> <duck> a sha1 hash is 20 bytes
14:22 < jrandom> first 20 bytes of the dest should be pretty random too, enough to deal with random clashes, but not to deal with hostile colisions
14:22 < jrandom> even better
14:22 < deer> <dinoman> if you lose the key how do peers find one another
14:22 < jrandom> a peer *is* a key
14:23 < jrandom> oh
14:23 * jrandom misinterpreted
14:23 < jrandom> the tracker must give peers the full destination, not the SHA1(destination)
14:24 < jrandom> is that the same peer_id in question?
14:24 < deer> <dinoman> i have fixed the php tracker to send the full key as the ip
14:24 < deer> <duck> actually the client generates the peer_id
14:24 < deer> <duck> (what do you mean with 'key'?)
14:25 < deer> <dinoman> destination
14:25 < dm> Sounds like a who's on first skit.
14:25 < dm> Use full sentences people!
14:26 < deer> <dinoman> ok fine :/ the tracker sends the Full destination as the ip
14:27 < jrandom> heh dont mind dm. sounds great
14:27 < deer> <dinoman> peer id is just for the trackers
14:27 < deer> <duck> maybe we could use #i2p-bt
14:28 < jrandom> what i think would be useful though is if you (or someone else) could perhaps draft up a list of modifications that'll need to be made
14:28 < deer> <duck> so no religious wars start each time the name of the snake is dropped
14:29 < deer> <dinoman> works for me
14:29 < deer> <dinoman> i don't war if it works it works
14:29 < jrandom> (e.g. "tracker sends e full destination as the IP", "client interprets the IP as the full destination", "torrent contains the tracker's destination in the field 'trackerDest'", etc)
14:29 < deer> <duck> definitly
14:30 < deer> <dinoman> jrandom you got it
14:31 < deer> <dinoman> this is the sample output of the tracker 8:intervali300e12:min intervali30e5:peersld2:ip50:klkjlkfsdjfkljkfdhjkddfsjkldsfjlkjfdlkjsfdl;kj;sdf7:peer
14:31 < dm> copy/pastes jrandom's sentence into notepad and saves as "draft.txt"
14:31 < cat-a-puss> will bt over i2p be intercompatible with other clients that are not over i2p?
14:31 < jrandom> cool dinoman
14:31 < deer> <dinoman> at ip50 you will see a junk key
14:32 < jrandom> cat-a-puss: yes
14:32 < deer> <dinoman> yes
14:32 < cat-a-puss> then we should talk
14:32 < jrandom> welcome to the weekly meeting! :)
14:32 < deer> <dinoman> it will need to be something like .i2ptorrent to make it live togeter
14:32 < deer> <dinoman> for filenames and links and what not
14:33 < jrandom> are you working on something similar cat-a-puss, or have some ideas for improvements?
14:33 < cat-a-puss> working on something similar
14:33 < cat-a-puss> in java
14:33 < jrandom> cool
14:34 < jrandom> is it necessarily java specific, or can some peers be in other langs?
14:34 < cat-a-puss> good question, I don't know how to work that sort of thing in java, I'll have to look into it
14:35 < deer> <duck> right
14:35 < deer> <duck> lets use ugha.i2p to write up some specs
14:35 < deer> <duck> .
14:35 < jrandom> or perhaps we need a "swarming data transfer" section in the forum so we can all discuss this stuff at our own pace?
14:35 < jrandom> or ugha.i2p, of course
14:36 < jrandom> (while we work through some bugs in the sam impl and libs :)
14:36 < deer> <duck> makes it all a challenge
14:37 < deer> <dinoman> hehe ok
14:38 < deer> <duck> ...
14:38 < deer> <duck> mo bt?
14:38 < deer> * dinoman gets back to work on Savane
14:39 < jrandom> http://ugha.i2p/SwarmingTransfer / http://ugha.ath.cx/SwarmingTransfer
14:39 < jrandom> word
14:39 < jrandom> ok, anything else on 5) BT progress?
14:39 < jrandom> or shall we hit 6) ???
14:39 < jrandom> and ask dinoman how the Savane progress is coming? :)
14:40 < deer> * jrandom cracks whip
14:40 < deer> <dinoman> mail i am stuck on using the i2p mail system
14:40 < deer> <dinoman> i think i should just take the mail out
14:40 < jrandom> is there any way to tell it to use the SMTP server at a different port?
14:40 < jrandom> or is the problem authenticated SMTP?
14:41 < deer> <dinoman> auth
14:41 < protok0l> Uptime: 5d
14:41 < protok0l> ii own
14:41 < deer> <dinoman> it is not in the class Savane uses
14:42 < deer> <dinoman> i can put it in
14:42 < protok0l> i'm "Ident: pxEI" can someone tell me my rating
14:42 < jrandom> ok, i bet we can just get postman to set you up with a custom SMTP destination that doesnt require authentication
14:42 < dm> I give you a 6/10
14:42 < dm> You could work on your ass a bit
14:42 < janonymous1> Whats savana
14:43 < jrandom> janonymous1: its like sourceforge
14:43 < deer> <dinoman> because i am looking at the I2P Public Domain Software Homepage in my browser now
14:43 < jrandom> w00t
14:45 < deer> <dinoman> that would be cool be what is being done on the server i don't want someone hacking me and the getting the info about the mail server
14:45 < deer> <dinoman> that is what bugs me
14:45 < jrandom> well, they wouldn't get any info on the mail server, they'd just be able to (at worst) spoof @mail.i2p
14:45 < janonymous1> Cool
14:46 < jrandom> but yeah, it'd be great to have authenticated SMTP support to prevent that
14:46 < jrandom> i dont know how much work that'd be though
14:46 < protok0l> well im glad i left my mailserver idea to postman
14:46 < protok0l> it seem more difficult than i imagined
14:47 < deer> <Ch0Hag> I wouldn't mind helping with that
14:47 < dm> protocol
14:47 < deer> <Ch0Hag> Got to do something. :-)
14:47 < deer> <dinoman> i will do auth :( it will take a little time but i will do it
14:47 < deer> <protokol> yes dm
14:48 < jrandom> see, you've got a volunteer already dinoman! :)
14:48 < deer> <protokol> maybe i could host a nessus server
14:48 < deer> <protokol> and tunnel it through TOR on my side
14:49 < deer> <Ch0Hag> Plus I need a good excuse to work on the rest of my network.
14:49 < deer> <protokol> and i shall dedicate myself to learning python
14:49 < janonymous1> 'the i2p software foundation'. I can see it now
14:49 < deer> <protokol> and how to correctly type
14:49 < dm> I shall dedicate myself to the pursuit of more money for myself and for those directly related to myself, who may be inclined to give me money in the near future.
14:50 < jrandom> ok, anyone else have anything to bring up for 6) ???
14:50 < dm> 7) $$$
14:51 < duck> Roger Dingledine (arma @ freenode) published a draft for a chapter of an upcoming O'Reilly book
14:51 < duck> http://freehaven.net/doc/wupss04/usability.pdf
14:51 < jrandom> ah, yeah, its pretty good
14:51 < duck> it is about anonymity and usability
14:51 < dm> chapter on usability?
14:51 < deer> <protokol> i can run the i2p software foundation
14:51 < deer> <protokol> lol
14:51 < duck> some interesting parts about negative imago
14:52 < deer> <protokol> give me the keys the the treasury
14:52 < duck> having good default
14:52 < deer> <protokol> NOW!
14:52 < duck> etc
14:52 < duck> .
14:52 < jrandom> and the importance of usability, even over security at times
14:52 < dm> protok0l: you're the user advocate aren't you? You should read that document.
14:52 < jrandom> 'k, anything else for the meeting?
14:52 < deer> <protokol> wow, im seeing 83 peers
14:52 < duck> now we know why there are so few known hidden sides on tor
14:53 < deer> <protokol> dm: i shall
14:53 < duck> arma is affraid for negative imago
14:53 < duck> .
14:53 < dm> "imago" ?
14:53 < duck> image
14:53 < deer> <duck> (psychoanalysis) an idealized image of someone
14:53 < dm> No mention of I2P in there :(
14:53 < duck> jrandom: aint we?
14:54 < jrandom> hm?
14:54 < dm> he means aren't we. He's dutch.
14:54 < duck> if some specific group now moves to i2p,
14:54 < duck> they could keep away much needed other users
14:55 < jrandom> oh, thats in there? i didnt see that
14:55 < duck> no, I am saying that
14:55 < duck> but it is in there too, more or less
14:55 < duck> ofcourse andy anarchist doesnt give a fuck
14:56 < jrandom> well, i do think there is room for both i2p and tor
14:56 < duck> yes
14:56 < duck> but what about early negative image on I2P
14:56 < deer> <Natalia> this is the reason I am forced to be a somewhat mundane female on this IRC channel
14:56 < protok0l> haha, when i get the word every major anarchist listserv and forum will hear about i2p within a day or 2
14:56 < jrandom> oh, i dont give a flying fuck about that duck ;)
14:56 < deer> <Natalia> jrandom doesn't approve of got
14:56 < deer> <Natalia> *gott
14:57 < duck> jrandom: yeah, but well
14:57 * duck counts the amount of anarchy friendly regions on the globe
14:57 < deer> <Natalia> so I have to be Natalia, the loved female of the channel
14:57 < deer> <Natalia> ( lame )
14:57 < duck> somalia?
14:57 < duck> I bet they have flying fucks there
14:57 < protok0l> Chiapas, mexica
14:57 < duck> but not friendly ones
14:57 < protok0l> mexiico
14:58 < deer> <Ragnarok> bah, you want to be feminized
14:58 < jrandom> duck: when it comes time to be more public, i'm certain we can put on a reasonable joe sixpack friendly face
14:58 < duck> k
14:58 < jrandom> will people do "bad" things with i2p? yeah
14:58 < dm> I think we should target joe beergut
14:58 < protok0l> good luck, i know gott is planning something
14:58 < protok0l> gott will destroy us
14:58 < duck> ok
14:58 < duck> .
14:58 < jrandom> the only way any worthwhile anonymity or security system can survive is to be content neutral
14:59 < deer> <Ragnarok> anonymous communication systems can only protect communication. They don't interfere with good old police work if someone actually *does* something.
14:59 < duck> just saying that some links placed on http://127.0.0.1:7657/index.jsp could be bad
14:59 < dm> I2P is about technology.
14:59 < deer> <Natalia> yes
14:59 < jrandom> true enough duck
15:00 < duck> and yes, the sitelist.html will turn into a TFE discussion thing all over
15:00 < jrandom> well, mmhmm
15:00 < deer> <Natalia> content neutrality is something I write about in the latest eeplog entry
15:00 < deer> <Natalia> http://gott.i2p/eeplog.html
15:01 < jrandom> this is, however, the power of interactive eepsites, like wikis
15:01 < jrandom> (e.g. having people register their site with a sitelist.py or whatever)
15:01 < deer> <Natalia> jrandom: do you support not support the idea of eepsite crawlers linking to illegal material, being linked from the frontpage ?
15:01 < deer> <Natalia> +or
15:01 < deer> <Natalia> if you were going to link to the sitelist
15:02 < duck> from a moral point I dont give a flying fuck either
15:02 < deer> <Natalia> jrandom: none of these are registered
15:02 < duck> but from an usability point I might
15:02 < deer> <Natalia> the script checks host.txt
15:02 < deer> <Natalia> *hosts.txt
15:02 < jrandom> from a nontechnical perspective, i support whatever the user community requires
15:02 < deer> <Natalia> so everyone gets added to the list if they have a domain
15:03 < deer> <Natalia> ugh, bras are so uncomfortable.
15:03 < protok0l> yup, creepy
15:03 < deer> <cervantes> have you _seen_ the user community?
15:03 < cat-a-puss> The simplist solution would be to simply link to search pages, Everyone knows how to use them, they provide fast access, and nobody sees for anything they did not ask for.
15:04 < deer> <cervantes> :)
15:04 < protok0l> gott is a serial killer, i know it. he will be the first to offer live murders via webcam on i2p
15:04 < deer> <Natalia> the user community consists of rather strange people.
15:04 < jrandom> good point cat-a-puss, we could just link to files.i2p
15:04 < deer> <Natalia> at the moment, I am forced to be a woman because the lead developer disapproves of the immoral behaviour of my other.
15:04 < duck> cat-a-puss++
15:04 < deer> <Natalia> we are united through common adventure.
15:06 < BS314159> I'm not convinced this is a good idea, but the I2P license is certainly broad enough for people to spin off their own versions, differing only in the local link pages
15:06 < deer> <Natalia> well.
15:06 < deer> <cervantes> lets hope DrWoo can keep his indices free of corruption
15:06 < jrandom> certainly BS314159
15:06 < BS314159> not versions. distributions.
15:06 < deer> <Natalia> files.i2p should be one link
15:06 < jrandom> BS314159: people can even edit their own local link page
15:06 < deer> <Natalia> and then there should be a yahoo-style internet directory link
15:06 < protok0l> most people will be wise enuf to use the official version
15:06 < jrandom> (in docs/readme.html)
15:07 < deer> <Natalia> search engines and internet directories serve different roles
15:07 < deer> <Natalia> this is why the directory is there in the first place
15:07 < deer> <Natalia> it has been requested as independent of a search engine
15:07 < BS314159> so if you want e.g. to target an anti-pornography demographic, find an anti-pornography maintainer who maintains a filtered default start page set
15:07 < protok0l> unless they are willing to search for backdoors in third-party versions
15:07 < deer> <Natalia> by people
15:07 < deer> <Natalia> so I think the search-engine is good
15:07 < jrandom> right BS314159
15:07 < deer> <Natalia> but should not be the limit
15:07 < deer> <Natalia> search engine, internet directory, wiki, help page
15:07 < deer> <Natalia> perhaps.
15:08 < jrandom> we already link to fproxy.i2p, and we know what scary evil content they have on that site ;)
15:08 < BS314159> I'm not sure I'm on topic, but that seems possible. Is there an open-source content filter that any search-engine maintainers would be willing to implement support for?
15:08 < BS314159> I have a feeling I'm not on topic
15:08 < protok0l> is the meeting still on?
15:08 < jrandom> yes protok0l
15:08 < BS314159> sorry. (silences self)
15:08 < deer> <Natalia> jrandom: perhaps you shouldn't link to fproxy.i2p
15:08 < deer> <Natalia> it is almost always down
15:08 < jrandom> BS314159: i think a cntent filter in the search engine is excessive
15:08 < deer> <Natalia> it is down right now, it seems
15:09 < protok0l> it is
15:09 < deer> <Natalia> according to the recent run of the site-checking script
15:09 < jrandom> 'k
15:09 < jrandom> well, this has been a good discussion, lots of good ideas
15:09 < BS314159> not _the_ search engine. _someone_'s search engine
15:10 < deer> * Natalia smiles.
15:10 < deer> <cervantes> BS3: aol.i2p ;-)
15:10 < jrandom> ok, is there anything else for the meeting?
15:10 < deer> <cervantes> whoa...still in the meeting...
15:11 < deer> <cervantes> thought I'd missed that by an hour
15:11 < jrandom> nope, i was late
15:11 < jrandom> ok, if not..
15:11 * jrandom winds up
15:11 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/114.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, November 2, 2004
=================================
Quick recap
-----------
TODO
Full IRC Log
------------

File diff suppressed because it is too large Load Diff

10
i2p2www/meetings/115.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, November 9, 2004
=================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,183 +1,177 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 116{% endblock %}
{% block content %}<h3>I2P dev meeting, November 16, 2004</h3>
<div class="irclog">
13:05 < jrandom> 0) hi</p>
13:05 < jrandom> 1) Congestion</p>
13:05 < jrandom> 2) Streaming</p>
13:05 <+dinoman> pgforge's key has changed :/ sorry</p>
13:05 < jrandom> 3) BT</p>
13:05 < jrandom> 4) ???</p>
13:05 < jrandom> ah cool, we can do some magic for that</p>
13:05 < jrandom> 0) hi</p>
13:05 * jrandom waves</p>
13:05 < ant> &lt;lucky&gt; hi</p>
13:05 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2004-November/000489.html</p>
13:05 < wiht> Hello.</p>
13:06 < jrandom> (and we got the notes posted *before* the meeting. w00t)</p>
13:06 < jrandom> might as well jump on in to 1) Congestion</p>
13:07 < jrandom> for people who have been hanging around the channel the last few days, you've heard lots of discussions about wtf has been going on, and both this email and duck's post earlier should cover it generally</p>
13:07 < jrandom> that said, does anyone have any questions / comments / concerns that they'd like to raise/discuss?</p>
13:09 < wiht> What do you mean by "wild peer selection"?</p>
13:10 < jrandom> the way our current tunnel building works unfortunately lets things stabalize around the fast peers</p>
13:10 < jrandom> if those fast peers don't fail occationally, we simply use them, period, rather than explore beyond them in our tunnel building</p>
13:11 < jrandom> that means that when they *do* fail later on, we have pretty much no idea how much capacity the rest of the network has, and as such, choose peers fairly arbitrarily</p>
13:11 <+DrWoo> jrandom: what is in the pipeline to use the capacity better?</p>
13:12 < jrandom> DrWoo: the 0.4.3 release will include a new way of pooling tunnels so that we can have more 'experimental' backup tunnels (allowing us to learn more about the network without sacrificing performance)</p>
13:13 < jrandom> more aggressive load balancing through ATM-style reservations are also in the pipeline, but aren't plotted at a particular release yet (aka we'll do it when we need it)</p>
13:14 < ant> &lt;Connelly&gt; bleh</p>
13:14 < ant> &lt;Connelly&gt; no meeting yet?</p>
13:14 < jrandom> (ATM-style reservations, as in, keep track of how much bandwidth tunnels use, on average, multiply that by the number of tunnels we participate in, and compare that to our bandwidth limits / capacity, using that comparison to accept / reject further tunnel requests)</p>
13:15 < jrandom> Connelly: started 10m ago, status notes posted on the list ;)</p>
13:15 <+DrWoo> jrandom: what impact will that have on performance?</p>
13:15 <+DrWoo> local pc performance</p>
13:15 * wiht wonders how many different protocols are being used on the I2P network besides HTTP, IRC, and BT.</p>
13:16 < jrandom> DrWoo: the 0.4.3 pooling will give us greater resiliance (less failures), and the reservations will allow for more capacity-based load sharing (aka reduce contention)</p>
13:16 < jrandom> neither of those are particularly latency based though</p>
13:17 < jrandom> wiht: those three are the main ones used to my knowledge, though some ugly stuff is done over HTTP</p>
13:17 < jrandom> thats actually an interesting issue, wrt irc and congestion</p>
13:18 < jrandom> what was really killing irc.duck.i2p the other day was the fact that during congestion, duck's irc server still had to pump out 20x the number of messages it received</p>
13:19 < jrandom> add on the automatic message resending every.10.seconds.with.no.backoff, and that grows to 120 messages for every line of text ;)</p>
13:19 < jrandom> basically what i'm saying is, a decentralized chat protocol would be Good ;)</p>
13:19 <+DrWoo> is there such a beast?</p>
13:20 < jrandom> (though the new streaming lib will get rid of that 6x overhead)</p>
13:20 <+dinoman> is there a good one</p>
13:20 < jrandom> i dont know if anyone has evaluated something ala SILC for i2p within the last year</p>
13:20 < susi23> pop3 and smtp are _awfully_ slow on i2p</p>
13:21 < ant> &lt;duck&gt; silc == irc+somecrypto</p>
13:21 < susi23> (as answer on the question, which protocols are used too)</p>
13:21 < jrandom> ah, i thought silc got away from the ircd concept</p>
13:21 < jrandom> oh, shit, right, i forgot about those two :)</p>
13:21 < wiht> susi23: Yes, I forgot that we have mail on I2P now.</p>
13:21 < ant> &lt;duck&gt; not far atleast</p>
13:21 < jrandom> 'k</p>
13:21 < ant> &lt;protok0l&gt; meeting?</p>
13:22 < ant> &lt;lucky&gt; rite now protok0l </p>
13:22 < ant> &lt;protok0l&gt; k</p>
13:22 < jrandom> ok, do we have anything else for 1) congestion?</p>
13:23 < jrandom> if not, moving on to 2) streaming</p>
13:23 < jrandom> [see the email]</p>
13:24 < jrandom> i've kept all the streaming lib updates out of the history.txt, but you can watch whats going on via the cvs list</p>
13:24 < jrandom> (if you're crazy)</p>
13:24 < jrandom> i dont really have anythign else to add though. so, any questions/comments/concerns? </p>
13:25 <+postman> just one</p>
13:25 <+postman> thanks :)</p>
13:25 < ant> &lt;protok0l&gt; what speed increase will there be</p>
13:25 < jrandom> hehe you're supposed to wait until you *get* the software postman ;)</p>
13:25 < jrandom> protokol: some. varies. </p>
13:25 <+postman> jrandom: i would bet on you blindfold</p>
13:26 <+DrWoo> jrandom: I'm going to ask you what you hate, is there an ETA on the new streaming lib, the current situation obviously is a point of vulnerability?</p>
13:27 < jrandom> if tests this week go well, we can pencil in next week</p>
13:27 < jrandom> there'll be services up and running on the new streaming lib before then though, so that we can test it under load conditions</p>
13:28 < wiht> As I recall, you are using a simulated network for the tests. Is that still true?</p>
13:29 < jrandom> for some of them, yeah</p>
13:29 < jrandom> when i dont use the sim, i just run it on the live net</p>
13:30 < jrandom> (because i like to abuse your bandwdith ;)</p>
13:30 < susi23> you're welcome ;)</p>
13:30 <+dinoman> hehe turn it on a see if it blows up?</p>
13:31 -!- x is now known as fidd</p>
13:31 < jrandom> pretty much - i've got some logging code that essentially dumps the streaming packet headers, allowing me to make sure everything is sent properly and various situations are handled as they should be</p>
13:32 < jrandom> the sim'ed tests are more involved though, with perhaps a half dozen unit tests w/ various runtime params</p>
13:33 < wiht> How well do the simulation tests reflect observed network usage?</p>
13:33 < jrandom> pretty well, as the simulation code is the same as the live network code</p>
13:34 < jrandom> i dont have the lag and drop injection perfect in the sim though, but its in the ballpark</p>
13:35 < ant> &lt;cat-a-puss&gt; will the new streaming lib use the same interface? Or will Java apps have to do something new?</p>
13:35 < wiht> Thanks for clarifying that.</p>
13:36 < jrandom> cat-a-puss: same interface. there are a few additional config options that you might want to tack on when building an I2PSocketManager, but thats a good ol' properties map</p>
13:36 < ant> &lt;cat-a-puss&gt; k</p>
13:37 < jrandom> k, anything else, or shall we jump to 3) BT?</p>
13:38 < jrandom> duck: ping</p>
13:38 <@duck> *quack</p>
13:38 <@duck> Last week I reported that we had BitTorrent on I2P working. There has been some </p>
13:38 <@duck> confusion but it is anonymous both for trackers and for clients (seeders and leechers).</p>
13:38 <@duck> Updates since last week:</p>
13:38 <@duck> GUI work (wxPython), included tracker, bugfixes.</p>
13:39 <@duck> full list at http://dev.i2p/cgi-bin/cvsweb.cgi/~checkout~/i2p-bt/CHANGES.txt?rev=HEAD</p>
13:39 <@duck> also the code is at the CVS on cvs.i2p</p>
13:39 <@duck> and got a dedicated eepsite: http://duck.i2p/i2p-bt/</p>
13:39 <@duck> The included tracker is very spartanic and you still have to provide the</p>
13:39 <@duck> torrents themself somewhere; so DrWoo, thetower and me have been looking at </p>
13:39 <@duck> several alternatives which offer features like suprnova, until I got nuts.</p>
13:39 <@duck> *flierp*</p>
13:40 < jrandom> w00t</p>
13:40 <@duck> Finally bytemonsoon is selected, the original is ugly, but DrWoo has been fixing that,</p>
13:40 <@duck> The idea is to improve it some more and release it as an I2P ready tracker solution,</p>
13:40 <@duck> see: http://brittanyworld.i2p/bittorrent/</p>
13:40 <@duck> meeting the requirements at: http://duck.i2p/i2p-bt/txt/bytemonsoon.txt</p>
13:40 <@duck> .</p>
13:40 < jrandom> kickass</p>
13:40 <+DrWoo> you can check out a couple of small test files on a the nice tracker duck fixed up</p>
13:41 <+DrWoo> there's nothing big to gum up the net heh</p>
13:41 < jrandom> what, you dont want us to download more episodes of Lost? :)</p>
13:41 <@duck> if thetower's is up..</p>
13:42 < jrandom> the bytemonsoon port is looking really nice.</p>
13:42 <+DrWoo> I can't get thetower right now here</p>
13:42 <+DrWoo> jrandom: it really seems to provide most anything you'd need</p>
13:42 <+dinoman> what kind of speed r ppl seeing?</p>
13:43 <@duck> ~5kb/s per peer</p>
13:43 <+DrWoo> dino: from this side it looks like 4-10K per peer</p>
13:43 <@duck> (optimistically, ofcourse there are those shitty adsl folks)</p>
13:44 <+dinoman> wow better then i thought</p>
13:44 <@duck> til i2p crashes; see 1)</p>
13:44 < jrandom> heh</p>
13:44 <+DrWoo> dinoman: in other works, it should look pretty impressive with a swarm</p>
13:44 <@duck> there have been various calls for improving the GUI</p>
13:45 <+DrWoo> dinoman: and some 0 hop peers ;)</p>
13:45 <@duck> not many takers on it though</p>
13:45 < jrandom> duck (& gang): what can we do to help?</p>
13:45 <@duck> you: get the new streaming lib ready</p>
13:46 <@duck> gang: look at the todo: http://duck.i2p/i2p-bt/txt/todo.txt</p>
13:46 <@duck> lucky is working on a howto</p>
13:47 <@duck> DrWoo: anything else?</p>
13:47 < jrandom> nice</p>
13:47 <+DrWoo> jrandom: can you talk a bit about where you stand regarding the importance (or not) of file sharing(and other popular services currently run over the internet) and what it's means to to I2P's anonymity prospects.</p>
13:47 < ant> &lt;lucky&gt; i am?</p>
13:48 < ant> &lt;lucky&gt; oh</p>
13:48 < ant> &lt;lucky&gt; i am</p>
13:48 < ant> &lt;lucky&gt; :)</p>
13:48 <+DrWoo> duck: there's always something else heh</p>
13:48 < jrandom> file sharing is critical to I2P's success, as its realistically the largest potential pool of users to blend into our anonymity set</p>
13:49 < ant> &lt;lucky&gt; uh oh.</p>
13:49 < ant> &lt;lucky&gt; So that means i should really, really, work on that howto then.</p>
13:49 < jrandom> without a viable large-file-transfer system, we've got to do some wonders for engaging user apps</p>
13:50 < jrandom> which we are doing - susi's and postman's work is quite promising</p>
13:50 < jrandom> but the market for anonymous email is much less than the market for safe file transfer</p>
13:51 < jrandom> while I2P itself scales to whatever size (if things are as we hope ;), we need a large anonymity set to support anything wortwhile </p>
13:51 < jrandom> &lt;/my $0.02&gt;</p>
13:52 <@duck> what do you think about default settings for those filesharing apps?</p>
13:52 < jrandom> that i dont know</p>
13:53 <@duck> or isn't that really relevant yet giving todays possibilities</p>
13:54 <+DrWoo> duck: there may be some 'thinking outside the box' needed to get over some bumps along the way?</p>
13:54 < jrandom> 1 hop tunnels may be relevent for the BT-ers, prior to 0.4.3</p>
13:57 < jrandom> ok, do we have anything else for 3) BT?</p>
13:57 <@duck> notme</p>
13:57 <+DrWoo> thanks to duck and the dudes</p>
13:58 <+DrWoo> that was pretty awesome work</p>
13:58 < jrandom> aye, y'all are doing a kickass job</p>
13:58 <+dinoman> i did not do it</p>
13:58 < jrandom> (i love watching the --spew 1 on the btdownloadheadless :)</p>
13:58 <@duck> dinoman: you started it</p>
13:58 <+Ragnarok> headless spew... sounds dirty</p>
13:59 <+DrWoo> dino: pushing the effort along is a real contribution</p>
13:59 * Ragnarok will put together a patch for the command line option stuff on the todo list</p>
13:59 < jrandom> w00t</p>
14:00 < ant> &lt;dm&gt; Don't forget anonymous WWW, that's a big one as well.</p>
14:00 < jrandom> dm: yeah, perhaps thousands or tens of thousands, but not the draw of millions</p>
14:01 < jrandom> (for outproxy stuff, imho)</p>
14:01 < jrandom> ok, if there's nothing else, moving on to good ol' fashioned 4) ???</p>
14:01 < jrandom> anything not yet raised that should be?</p>
14:02 < wiht> postman: What is the status of the mail system? How well is it working, especially with respect to communications outside the I2P network?</p>
14:02 <+DrWoo> dm: it's all part of life's rich pageant :)</p>
14:03 < ant> &lt;dm&gt; a lotta people use da web</p>
14:03 < ant> &lt;dm&gt; (they just installed surfcontrol at my workplace) ;)</p>
14:03 < jrandom> aye, anonymous www hosting will be critical for those who really need i2p, though they probably won't be the anonymity set necessary </p>
14:03 < jrandom> ah, lame</p>
14:04 < jrandom> wiht: if he's not around, i can say that in and outproxy has worked pretty well for me - none lost yet</p>
14:04 < jrandom> (and checking my mail takes a few seconds, but biff tells me when i need to anyway)</p>
14:05 < jrandom> ok, is there anything else?</p>
14:06 < ant> &lt;dm&gt; are you baffing the meeting?</p>
14:07 < jrandom> seems like it</p>
14:07 * jrandom winds up</p>
14:07 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:05 < jrandom> 0) hi
13:05 < jrandom> 1) Congestion
13:05 < jrandom> 2) Streaming
13:05 <+dinoman> pgforge's key has changed :/ sorry
13:05 < jrandom> 3) BT
13:05 < jrandom> 4) ???
13:05 < jrandom> ah cool, we can do some magic for that
13:05 < jrandom> 0) hi
13:05 * jrandom waves
13:05 < ant> <lucky> hi
13:05 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2004-November/000489.html
13:05 < wiht> Hello.
13:06 < jrandom> (and we got the notes posted *before* the meeting. w00t)
13:06 < jrandom> might as well jump on in to 1) Congestion
13:07 < jrandom> for people who have been hanging around the channel the last few days, you've heard lots of discussions about wtf has been going on, and both this email and duck's post earlier should cover it generally
13:07 < jrandom> that said, does anyone have any questions / comments / concerns that they'd like to raise/discuss?
13:09 < wiht> What do you mean by "wild peer selection"?
13:10 < jrandom> the way our current tunnel building works unfortunately lets things stabalize around the fast peers
13:10 < jrandom> if those fast peers don't fail occationally, we simply use them, period, rather than explore beyond them in our tunnel building
13:11 < jrandom> that means that when they *do* fail later on, we have pretty much no idea how much capacity the rest of the network has, and as such, choose peers fairly arbitrarily
13:11 <+DrWoo> jrandom: what is in the pipeline to use the capacity better?
13:12 < jrandom> DrWoo: the 0.4.3 release will include a new way of pooling tunnels so that we can have more 'experimental' backup tunnels (allowing us to learn more about the network without sacrificing performance)
13:13 < jrandom> more aggressive load balancing through ATM-style reservations are also in the pipeline, but aren't plotted at a particular release yet (aka we'll do it when we need it)
13:14 < ant> <Connelly> bleh
13:14 < ant> <Connelly> no meeting yet?
13:14 < jrandom> (ATM-style reservations, as in, keep track of how much bandwidth tunnels use, on average, multiply that by the number of tunnels we participate in, and compare that to our bandwidth limits / capacity, using that comparison to accept / reject further tunnel requests)
13:15 < jrandom> Connelly: started 10m ago, status notes posted on the list ;)
13:15 <+DrWoo> jrandom: what impact will that have on performance?
13:15 <+DrWoo> local pc performance
13:15 * wiht wonders how many different protocols are being used on the I2P network besides HTTP, IRC, and BT.
13:16 < jrandom> DrWoo: the 0.4.3 pooling will give us greater resiliance (less failures), and the reservations will allow for more capacity-based load sharing (aka reduce contention)
13:16 < jrandom> neither of those are particularly latency based though
13:17 < jrandom> wiht: those three are the main ones used to my knowledge, though some ugly stuff is done over HTTP
13:17 < jrandom> thats actually an interesting issue, wrt irc and congestion
13:18 < jrandom> what was really killing irc.duck.i2p the other day was the fact that during congestion, duck's irc server still had to pump out 20x the number of messages it received
13:19 < jrandom> add on the automatic message resending every.10.seconds.with.no.backoff, and that grows to 120 messages for every line of text ;)
13:19 < jrandom> basically what i'm saying is, a decentralized chat protocol would be Good ;)
13:19 <+DrWoo> is there such a beast?
13:20 < jrandom> (though the new streaming lib will get rid of that 6x overhead)
13:20 <+dinoman> is there a good one
13:20 < jrandom> i dont know if anyone has evaluated something ala SILC for i2p within the last year
13:20 < susi23> pop3 and smtp are _awfully_ slow on i2p
13:21 < ant> <duck> silc == irc+somecrypto
13:21 < susi23> (as answer on the question, which protocols are used too)
13:21 < jrandom> ah, i thought silc got away from the ircd concept
13:21 < jrandom> oh, shit, right, i forgot about those two :)
13:21 < wiht> susi23: Yes, I forgot that we have mail on I2P now.
13:21 < ant> <duck> not far atleast
13:21 < jrandom> 'k
13:21 < ant> <protok0l> meeting?
13:22 < ant> <lucky> rite now protok0l
13:22 < ant> <protok0l> k
13:22 < jrandom> ok, do we have anything else for 1) congestion?
13:23 < jrandom> if not, moving on to 2) streaming
13:23 < jrandom> [see the email]
13:24 < jrandom> i've kept all the streaming lib updates out of the history.txt, but you can watch whats going on via the cvs list
13:24 < jrandom> (if you're crazy)
13:24 < jrandom> i dont really have anythign else to add though. so, any questions/comments/concerns?
13:25 <+postman> just one
13:25 <+postman> thanks :)
13:25 < ant> <protok0l> what speed increase will there be
13:25 < jrandom> hehe you're supposed to wait until you *get* the software postman ;)
13:25 < jrandom> protokol: some. varies.
13:25 <+postman> jrandom: i would bet on you blindfold
13:26 <+DrWoo> jrandom: I'm going to ask you what you hate, is there an ETA on the new streaming lib, the current situation obviously is a point of vulnerability?
13:27 < jrandom> if tests this week go well, we can pencil in next week
13:27 < jrandom> there'll be services up and running on the new streaming lib before then though, so that we can test it under load conditions
13:28 < wiht> As I recall, you are using a simulated network for the tests. Is that still true?
13:29 < jrandom> for some of them, yeah
13:29 < jrandom> when i dont use the sim, i just run it on the live net
13:30 < jrandom> (because i like to abuse your bandwdith ;)
13:30 < susi23> you're welcome ;)
13:30 <+dinoman> hehe turn it on a see if it blows up?
13:31 -!- x is now known as fidd
13:31 < jrandom> pretty much - i've got some logging code that essentially dumps the streaming packet headers, allowing me to make sure everything is sent properly and various situations are handled as they should be
13:32 < jrandom> the sim'ed tests are more involved though, with perhaps a half dozen unit tests w/ various runtime params
13:33 < wiht> How well do the simulation tests reflect observed network usage?
13:33 < jrandom> pretty well, as the simulation code is the same as the live network code
13:34 < jrandom> i dont have the lag and drop injection perfect in the sim though, but its in the ballpark
13:35 < ant> <cat-a-puss> will the new streaming lib use the same interface? Or will Java apps have to do something new?
13:35 < wiht> Thanks for clarifying that.
13:36 < jrandom> cat-a-puss: same interface. there are a few additional config options that you might want to tack on when building an I2PSocketManager, but thats a good ol' properties map
13:36 < ant> <cat-a-puss> k
13:37 < jrandom> k, anything else, or shall we jump to 3) BT?
13:38 < jrandom> duck: ping
13:38 <@duck> *quack
13:38 <@duck> Last week I reported that we had BitTorrent on I2P working. There has been some
13:38 <@duck> confusion but it is anonymous both for trackers and for clients (seeders and leechers).
13:38 <@duck> Updates since last week:
13:38 <@duck> GUI work (wxPython), included tracker, bugfixes.
13:39 <@duck> full list at http://dev.i2p/cgi-bin/cvsweb.cgi/~checkout~/i2p-bt/CHANGES.txt?rev=HEAD
13:39 <@duck> also the code is at the CVS on cvs.i2p
13:39 <@duck> and got a dedicated eepsite: http://duck.i2p/i2p-bt/
13:39 <@duck> The included tracker is very spartanic and you still have to provide the
13:39 <@duck> torrents themself somewhere; so DrWoo, thetower and me have been looking at
13:39 <@duck> several alternatives which offer features like suprnova, until I got nuts.
13:39 <@duck> *flierp*
13:40 < jrandom> w00t
13:40 <@duck> Finally bytemonsoon is selected, the original is ugly, but DrWoo has been fixing that,
13:40 <@duck> The idea is to improve it some more and release it as an I2P ready tracker solution,
13:40 <@duck> see: http://brittanyworld.i2p/bittorrent/
13:40 <@duck> meeting the requirements at: http://duck.i2p/i2p-bt/txt/bytemonsoon.txt
13:40 <@duck> .
13:40 < jrandom> kickass
13:40 <+DrWoo> you can check out a couple of small test files on a the nice tracker duck fixed up
13:41 <+DrWoo> there's nothing big to gum up the net heh
13:41 < jrandom> what, you dont want us to download more episodes of Lost? :)
13:41 <@duck> if thetower's is up..
13:42 < jrandom> the bytemonsoon port is looking really nice.
13:42 <+DrWoo> I can't get thetower right now here
13:42 <+DrWoo> jrandom: it really seems to provide most anything you'd need
13:42 <+dinoman> what kind of speed r ppl seeing?
13:43 <@duck> ~5kb/s per peer
13:43 <+DrWoo> dino: from this side it looks like 4-10K per peer
13:43 <@duck> (optimistically, ofcourse there are those shitty adsl folks)
13:44 <+dinoman> wow better then i thought
13:44 <@duck> til i2p crashes; see 1)
13:44 < jrandom> heh
13:44 <+DrWoo> dinoman: in other works, it should look pretty impressive with a swarm
13:44 <@duck> there have been various calls for improving the GUI
13:45 <+DrWoo> dinoman: and some 0 hop peers ;)
13:45 <@duck> not many takers on it though
13:45 < jrandom> duck (& gang): what can we do to help?
13:45 <@duck> you: get the new streaming lib ready
13:46 <@duck> gang: look at the todo: http://duck.i2p/i2p-bt/txt/todo.txt
13:46 <@duck> lucky is working on a howto
13:47 <@duck> DrWoo: anything else?
13:47 < jrandom> nice
13:47 <+DrWoo> jrandom: can you talk a bit about where you stand regarding the importance (or not) of file sharing(and other popular services currently run over the internet) and what it's means to to I2P's anonymity prospects.
13:47 < ant> <lucky> i am?
13:48 < ant> <lucky> oh
13:48 < ant> <lucky> i am
13:48 < ant> <lucky> :)
13:48 <+DrWoo> duck: there's always something else heh
13:48 < jrandom> file sharing is critical to I2P's success, as its realistically the largest potential pool of users to blend into our anonymity set
13:49 < ant> <lucky> uh oh.
13:49 < ant> <lucky> So that means i should really, really, work on that howto then.
13:49 < jrandom> without a viable large-file-transfer system, we've got to do some wonders for engaging user apps
13:50 < jrandom> which we are doing - susi's and postman's work is quite promising
13:50 < jrandom> but the market for anonymous email is much less than the market for safe file transfer
13:51 < jrandom> while I2P itself scales to whatever size (if things are as we hope ;), we need a large anonymity set to support anything wortwhile
13:51 < jrandom> </my $0.02>
13:52 <@duck> what do you think about default settings for those filesharing apps?
13:52 < jrandom> that i dont know
13:53 <@duck> or isn't that really relevant yet giving todays possibilities
13:54 <+DrWoo> duck: there may be some 'thinking outside the box' needed to get over some bumps along the way?
13:54 < jrandom> 1 hop tunnels may be relevent for the BT-ers, prior to 0.4.3
13:57 < jrandom> ok, do we have anything else for 3) BT?
13:57 <@duck> notme
13:57 <+DrWoo> thanks to duck and the dudes
13:58 <+DrWoo> that was pretty awesome work
13:58 < jrandom> aye, y'all are doing a kickass job
13:58 <+dinoman> i did not do it
13:58 < jrandom> (i love watching the --spew 1 on the btdownloadheadless :)
13:58 <@duck> dinoman: you started it
13:58 <+Ragnarok> headless spew... sounds dirty
13:59 <+DrWoo> dino: pushing the effort along is a real contribution
13:59 * Ragnarok will put together a patch for the command line option stuff on the todo list
13:59 < jrandom> w00t
14:00 < ant> <dm> Don't forget anonymous WWW, that's a big one as well.
14:00 < jrandom> dm: yeah, perhaps thousands or tens of thousands, but not the draw of millions
14:01 < jrandom> (for outproxy stuff, imho)
14:01 < jrandom> ok, if there's nothing else, moving on to good ol' fashioned 4) ???
14:01 < jrandom> anything not yet raised that should be?
14:02 < wiht> postman: What is the status of the mail system? How well is it working, especially with respect to communications outside the I2P network?
14:02 <+DrWoo> dm: it's all part of life's rich pageant :)
14:03 < ant> <dm> a lotta people use da web
14:03 < ant> <dm> (they just installed surfcontrol at my workplace) ;)
14:03 < jrandom> aye, anonymous www hosting will be critical for those who really need i2p, though they probably won't be the anonymity set necessary
14:03 < jrandom> ah, lame
14:04 < jrandom> wiht: if he's not around, i can say that in and outproxy has worked pretty well for me - none lost yet
14:04 < jrandom> (and checking my mail takes a few seconds, but biff tells me when i need to anyway)
14:05 < jrandom> ok, is there anything else?
14:06 < ant> <dm> are you baffing the meeting?
14:07 < jrandom> seems like it
14:07 * jrandom winds up
14:07 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/116.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, November 16, 2004
==================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,70 +1,64 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 117{% endblock %}
{% block content %}<h3>I2P dev meeting, November 23, 2004</h3>
<div class="irclog">
13:03 < jrandom> 0) hi</p>
13:03 < jrandom> 1) Net status</p>
13:03 < jrandom> 2) Streaming lib</p>
13:04 < jrandom> 3) 0.4.2</p>
13:04 < jrandom> 4) Addressbook.py 0.3.1</p>
13:04 < jrandom> 5) ??? </p>
13:04 < jrandom> 0) hi</p>
13:04 * jrandom waves</p>
13:04 <+postman> hi :)</p>
13:04 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2004-November/000490.html</p>
13:05 < jrandom> well, might as well jump on in to 1) net status</p>
13:05 < jrandom> i dont have much to add to this that wasn't in the email</p>
13:05 < jrandom> anyone have anything they want to bring up wrt the network status over the last week?</p>
13:06 < jrandom> if not, we can jump on down to 2) streaming lib</p>
13:06 < jrandom> there's lots of info in the mail about this, so i'll let y'all digest a bit</p>
13:07 < jrandom> while the new lib will improve lots of things, the most important (imho) is its resiliance and handling of congestion</p>
13:08 < jrandom> especially the latter, as we've seen how things get funky with the old lib under heavy congestion</p>
13:08 < jrandom> there's also a lot of things left out of the lib though, places for people to experiment and optimize further</p>
13:09 < jrandom> anyone have any questions wrt this, or have we been beating a dead horse by discussing it each week for the last month? ;)</p>
13:10 <+Ragnarok> we'll call that a yes</p>
13:10 < jrandom> heh</p>
13:10 < jrandom> ok, moving on to 3) 0.4.2</p>
13:10 < jrandom> out real soon, just doing some minor updates to the install process at the moment</p>
13:11 <+postman> yesss</p>
13:11 <+postman> :)</p>
13:11 < jrandom> the updated install proc will be a bit nicer for people, addressing the most common user errors</p>
13:12 < jrandom> (since no one ever reads the text on the router console ;)</p>
13:12 < jrandom> but that should be ready in the next day or two, so with some testing we should have a release out by friday</p>
13:12 < jrandom> (if not sooner)</p>
13:13 < jrandom> as i mentioned in the mail though, its both backwards compatbile and /not/ backwards compatible</p>
13:13 <+Ragnarok> awesome</p>
13:13 < jrandom> does anyone have any strong preferences as to how we should do that tap dance?</p>
13:13 < jrandom> should we just push out 0.4.2 and let people upgrade when they notice they cant reach any eepsites?</p>
13:14 < jrandom> (or will they uninstall it and say "dood i2p sux0rz")</p>
13:14 * jrandom neither</p>
13:15 <+Ragnarok> I'd say mark it as not compatible. It's always better to be explicit.</p>
13:15 < jrandom> well, the docs and announcement will say not compatible, mandatory upgrade in big bold letters</p>
13:16 <+Ragnarok> no reason to send mixed messages, then</p>
13:16 < jrandom> aye</p>
13:16 < jrandom> though we would be able to tunnel route through those old peers</p>
13:16 < jrandom> i dunno, we've got a few days to finalize the decision anyway</p>
13:17 < jrandom> just something to think about, and a WARNING to people that they'll NEED TO UPGRADE TO 0.4.2 </p>
13:17 < jrandom> :)</p>
13:18 < jrandom> ok, anyone have any questions/comments/concerns wrt 0.4.2, or shall we move on to 4) addressbook.py?</p>
13:18 < jrandom> consider us moved</p>
13:18 < jrandom> Ragnarok: wanna give us an update?</p>
13:20 <+Ragnarok> sure. Minor update released yesterday. Fixes some bugs on windows, and doesn't violently die if the proxy isn't there. Only really notable thing is that this will probably be the last release for this version, barring a giant bug.</p>
13:20 < jrandom> ok cool</p>
13:21 < jrandom> avoiding violent death is always a nice feature to have</p>
13:21 < lba> hi folks</p>
13:21 <+Ragnarok> I'm planning on redesigning (just designing, really) it from the ground up based on jrandom's thoughts from the mailing list. Possibly in java too, if I can figure out the xml parsing and http stuff I'll have to do.</p>
13:21 < jrandom> wikked :)</p>
13:21 < jrandom> 'lo lba</p>
13:22 <+Ragnarok> well, that's all. Carry on.</p>
13:22 < jrandom> cool, thanks for the update</p>
13:22 < jrandom> ok if there's nothing else on that, we can move on at a blazing pace to 5) ???</p>
13:22 < jrandom> anyone else have something they want to bring up?</p>
13:23 <+Ragnarok> anyone else here?</p>
13:23 < jrandom> heh, yeah, we dont have our usual malcontents ;)</p>
13:24 < jrandom> then again, they'll show up to read the logs on the site later [yeah, i mean *YOU*]</p>
13:24 < jrandom> ok, i think thats probably the shortest meeting we've had in over a year</p>
13:25 < jrandom> might as well wraper 'er up</p>
13:25 * jrandom winds up</p>
13:25 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:03 < jrandom> 0) hi
13:03 < jrandom> 1) Net status
13:03 < jrandom> 2) Streaming lib
13:04 < jrandom> 3) 0.4.2
13:04 < jrandom> 4) Addressbook.py 0.3.1
13:04 < jrandom> 5) ???
13:04 < jrandom> 0) hi
13:04 * jrandom waves
13:04 <+postman> hi :)
13:04 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2004-November/000490.html
13:05 < jrandom> well, might as well jump on in to 1) net status
13:05 < jrandom> i dont have much to add to this that wasn't in the email
13:05 < jrandom> anyone have anything they want to bring up wrt the network status over the last week?
13:06 < jrandom> if not, we can jump on down to 2) streaming lib
13:06 < jrandom> there's lots of info in the mail about this, so i'll let y'all digest a bit
13:07 < jrandom> while the new lib will improve lots of things, the most important (imho) is its resiliance and handling of congestion
13:08 < jrandom> especially the latter, as we've seen how things get funky with the old lib under heavy congestion
13:08 < jrandom> there's also a lot of things left out of the lib though, places for people to experiment and optimize further
13:09 < jrandom> anyone have any questions wrt this, or have we been beating a dead horse by discussing it each week for the last month? ;)
13:10 <+Ragnarok> we'll call that a yes
13:10 < jrandom> heh
13:10 < jrandom> ok, moving on to 3) 0.4.2
13:10 < jrandom> out real soon, just doing some minor updates to the install process at the moment
13:11 <+postman> yesss
13:11 <+postman> :)
13:11 < jrandom> the updated install proc will be a bit nicer for people, addressing the most common user errors
13:12 < jrandom> (since no one ever reads the text on the router console ;)
13:12 < jrandom> but that should be ready in the next day or two, so with some testing we should have a release out by friday
13:12 < jrandom> (if not sooner)
13:13 < jrandom> as i mentioned in the mail though, its both backwards compatbile and /not/ backwards compatible
13:13 <+Ragnarok> awesome
13:13 < jrandom> does anyone have any strong preferences as to how we should do that tap dance?
13:13 < jrandom> should we just push out 0.4.2 and let people upgrade when they notice they cant reach any eepsites?
13:14 < jrandom> (or will they uninstall it and say "dood i2p sux0rz")
13:14 * jrandom neither
13:15 <+Ragnarok> I'd say mark it as not compatible. It's always better to be explicit.
13:15 < jrandom> well, the docs and announcement will say not compatible, mandatory upgrade in big bold letters
13:16 <+Ragnarok> no reason to send mixed messages, then
13:16 < jrandom> aye
13:16 < jrandom> though we would be able to tunnel route through those old peers
13:16 < jrandom> i dunno, we've got a few days to finalize the decision anyway
13:17 < jrandom> just something to think about, and a WARNING to people that they'll NEED TO UPGRADE TO 0.4.2
13:17 < jrandom> :)
13:18 < jrandom> ok, anyone have any questions/comments/concerns wrt 0.4.2, or shall we move on to 4) addressbook.py?
13:18 < jrandom> consider us moved
13:18 < jrandom> Ragnarok: wanna give us an update?
13:20 <+Ragnarok> sure. Minor update released yesterday. Fixes some bugs on windows, and doesn't violently die if the proxy isn't there. Only really notable thing is that this will probably be the last release for this version, barring a giant bug.
13:20 < jrandom> ok cool
13:21 < jrandom> avoiding violent death is always a nice feature to have
13:21 < lba> hi folks
13:21 <+Ragnarok> I'm planning on redesigning (just designing, really) it from the ground up based on jrandom's thoughts from the mailing list. Possibly in java too, if I can figure out the xml parsing and http stuff I'll have to do.
13:21 < jrandom> wikked :)
13:21 < jrandom> 'lo lba
13:22 <+Ragnarok> well, that's all. Carry on.
13:22 < jrandom> cool, thanks for the update
13:22 < jrandom> ok if there's nothing else on that, we can move on at a blazing pace to 5) ???
13:22 < jrandom> anyone else have something they want to bring up?
13:23 <+Ragnarok> anyone else here?
13:23 < jrandom> heh, yeah, we dont have our usual malcontents ;)
13:24 < jrandom> then again, they'll show up to read the logs on the site later [yeah, i mean *YOU*]
13:24 < jrandom> ok, i think thats probably the shortest meeting we've had in over a year
13:25 < jrandom> might as well wraper 'er up
13:25 * jrandom winds up
13:25 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/117.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, November 23, 2004
==================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,324 +1,318 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 118{% endblock %}
{% block content %}<h3>I2P dev meeting, November 30, 2004</h3>
<div class="irclog">
13:08 < jrandom> 0) hi</p>
13:08 < jrandom> 1) 0.4.2 and 0.4.2.1</p>
13:08 < jrandom> 2) mail.i2p</p>
13:08 < jrandom> 3) i2p-bt</p>
13:08 < jrandom> 4) eepsites</p>
13:08 < jrandom> 5) ???</p>
13:09 < jrandom> 0) hi</p>
13:09 < jrandom> sorry to interrupt dm's agenda</p>
13:09 < jrandom> status notes up @ http://dev.i2p.net/pipermail/i2p/2004-November/000492.html</p>
13:09 < jrandom> [hi]</p>
13:10 <+postman> ((hi))</p>
13:10 <+postman> :)</p>
13:10 < jrandom> so, as y'all read through that overwhelmingly interesting email, we might as well get the meeting underway</p>
13:10 < jrandom> 1) 0.4.2 and 0.4.2.1</p>
13:11 < jrandom> 0.4.2 is out, as you know, and the results are mixed, but when its not failing bad, it seems to be doing much better ;)</p>
13:12 < jrandom> there will be a release with a whole slew of bugfixes soon - i've been holding off to try to get as many things improved as possible</p>
13:12 < jrandom> as things stand now though, it looks like the 0.4.2.1 release will not yet get the i2p-bt port into tip top shape quite yet</p>
13:12 <+postman> jrandom: what do the bugfixes address - all errors in the new streaminglib or other stuff as well?</p>
13:13 < jrandom> a fast busy loop in the streaming lib that came up from a poorly tested scenario, some SAM issues, IP address detection problems, among other things</p>
13:14 < jrandom> dev.i2p.net/cgi-bin/cvsweb.cgi/~checkout~/i2p/history.txt?rev=HEAD has the full list</p>
13:14 <+postman> k</p>
13:14 <+postman> thx</p>
13:15 < jrandom> oh, one thing to note about 0.4.2.1 is that it, like 0.4.2, will need to modify your wrapper.config again, so please pay attention to the update instructions when they're out :)</p>
13:15 < jrandom> does anyone have any questions/comments/concerns about 0.4.2?</p>
13:15 < jrandom> (/0.4.2.1)</p>
13:16 < clayboy> been working great here, have been tracking cvs too, always smooth</p>
13:16 < jrandom> wikked</p>
13:17 < bla> It's table (0.4.2): up for days already</p>
13:17 < bla> s/table/stable/</p>
13:17 < jrandom> ah nice, yeah, the bugs havent been hitting everyone</p>
13:17 < jrandom> ok, if there's nothing else on that, lets jump on to 2) mail.i2p</p>
13:18 < jrandom> i hear postman has some things to discuss</p>
13:18 <+postman> hello</p>
13:18 < jrandom> hi postman, you're up :)</p>
13:18 <+postman> weeks ago i conducted a poll regarding IMAP</p>
13:19 <+postman> since a few weeks passed now i decided to close the polls and to count the vote</p>
13:19 <+postman> result is: not needed - won't be done. period</p>
13:19 <+postman> after talking to susi - she was quite fine wioth pop3 on her webmail interface</p>
13:19 < clayboy> reason wins! :)</p>
13:19 < jrandom> w3wt</p>
13:20 <+postman> so let's just stick to the pop3 end bury any silly imap ideas</p>
13:20 <+postman> :)</p>
13:20 * jrandom gets the shovel</p>
13:20 <+postman> 2.) we're close to 100 registered users</p>
13:21 < clayboy> wow</p>
13:21 <+postman> not all of them public of course, but it still sounds like a quite reasonable number regarding the size of the network </p>
13:21 <+Ragnarok> so... how about that LDAP address book? :)</p>
13:21 < jrandom> nice</p>
13:21 <+postman> 3. a feature to upload/share you public pgp key is active since weekend</p>
13:21 <+postman> please use it </p>
13:21 <+postman> www.postman.i2p/user/acc.html</p>
13:22 < clayboy> i'm not taking any credit for that idea :&gt;</p>
13:22 <+postman> the public keys can easily be downloaded with the help of the addressbook</p>
13:22 <+postman> or direct as www.postman.i2p/public/accountname.pub</p>
13:22 < jrandom> ooh cool</p>
13:22 <+postman> the system works quite fine</p>
13:22 <+postman> thanks to duck for pointing at a few bugs</p>
13:23 <+postman> 4.) i think about offering accountbased routing</p>
13:23 <+postman> like ppl say</p>
13:23 < jrandom> account based routing?</p>
13:23 <+postman> all mail for foo@mail.i2p gets transported to the following destination </p>
13:23 <+postman> and user presents a valid destination key for it</p>
13:24 <+postman> postman.i2p will then manually route mail to those accounts to mailsystems</p>
13:24 <+postman> just an idea(tm)</p>
13:24 < jrandom> ah nice</p>
13:24 <+postman> i am looking forward to develop and discuss the whole matter</p>
13:25 <+postman> that's it for now</p>
13:25 <+postman> more follows next week</p>
13:25 <+postman> thanks</p>
13:25 < nmi> postman: sorry, transported to a particular i2p destination you mean?</p>
13:25 * postman hands the mike back to jrandom </p>
13:25 <+postman> nmi: yes</p>
13:25 < ant> &lt;Nightblade&gt; am SMTP i2p destination?</p>
13:25 < ant> &lt;Nightblade&gt; an</p>
13:25 <+postman> nmi: provided the destination accepts smtp and mail for that account</p>
13:25 < jrandom> that sounds very cool, gets rid of the trust aspect of the mail fiiltering</p>
13:26 < nmi> ah, ok. clever. i had thought of doing something similar using mixminion single-use-reply-blocks but your idea is better...</p>
13:26 < jrandom> its probably a lot of work to set up on the client side, but perhaps someone could do some hacking</p>
13:26 <+postman> jrandom: i am working on it</p>
13:26 < jrandom> w00t</p>
13:26 <+postman> jrandom: the user will have the usual webinterface ( acc.html...)</p>
13:27 <+postman> jrandom: and inserts the destinationkey</p>
13:27 < jrandom> well, right, but then there's the MTA configuration</p>
13:27 <+postman> the rest will be done automatigally</p>
13:27 <+postman> yes, on the postman.i2p AND the receiving sinde</p>
13:28 < nmi> jrandom: yeah, it would be cool to have a really stripped down smtp proxy for people not wanting to run a full MTA</p>
13:28 < jrandom> right right</p>
13:28 <+postman> jrandom: i will provide a simple setup config for ppl interested</p>
13:28 <+postman> jrandom: for postfix, exim and sendmail</p>
13:28 <+postman> jrandom: those can be stripped down to BARE necessities</p>
13:28 <@duck> seriously, do you think that there are many users for that?</p>
13:28 < jrandom> postman: this all sounds pretty kickass. i look forward to hearing more when you're ready</p>
13:29 <+postman> jrandom: no idea about windows smtp servers tho</p>
13:29 <+postman> duck: well</p>
13:29 <+postman> duck: 8 weeks ago there was no need for a mailsystem and no users either</p>
13:29 <+postman> duck: it's investment</p>
13:29 <@duck> true</p>
13:29 <+postman> duck: in 6 months we'll be happy to have it</p>
13:29 < jrandom> duck: the potential comes with moving away from a trusted SMTP filter</p>
13:29 <+postman> :)</p>
13:30 < jrandom> er, perhaps i should say, moving /to/ a trusted smtp filter (no offense postman ;)</p>
13:30 <+postman> and there will be a few ones</p>
13:30 <+postman> AND</p>
13:30 <+postman> (now the punchline)</p>
13:30 <+postman> we could easily create maildomains :)</p>
13:30 <+postman> like duck@duck.i2p and other stuff</p>
13:30 <+postman> :)</p>
13:30 <@duck> ah</p>
13:31 <+postman> the only problem would be the official/private mapping</p>
13:31 < jrandom> hosts.txt!</p>
13:31 * jrandom ducks</p>
13:31 <+postman> but this is another thing for the webmanagement console :)</p>
13:31 <+postman> LOL</p>
13:31 <+postman> jrandom: i rely on shaky sql databases :)</p>
13:31 <@duck> ok; I see it fitting in</p>
13:32 <+postman> ok</p>
13:32 <+postman> then i will work it out and present an concept soon</p>
13:32 <+postman> yess, yet more work</p>
13:32 * postman leans back relaxed</p>
13:32 <+postman> :)</p>
13:32 < jrandom> kickass, thanks postman </p>
13:33 < jrandom> ok, unless other people have further mail.i2p related questions, shall we move on to 3) i2p-bt?</p>
13:33 < jrandom> consider us moved</p>
13:34 < jrandom> ok, as the email mentioned, i broke the i2p-bt port</p>
13:34 * jrandom hangs head in shame</p>
13:34 < jrandom> in other news, duck, do you have anything wrt i2p-bt you want to discuss?</p>
13:34 <@duck> as a result of jrandom's work not much has been done :)</p>
13:35 <+Ragnarok> booo, hissss</p>
13:35 <@duck> oh Ragnarok had some patches</p>
13:35 * jrandom2p pelts jrandom with tomatoes</p>
13:35 <@duck> I think, see the history file :)</p>
13:35 < jrandom> oh cool</p>
13:35 <@duck> we got some things in the queue too</p>
13:35 <+Ragnarok> well, I was hissing at jr, but ok :)</p>
13:36 <@duck> but I dont want to change (too) much on the unstable ground</p>
13:36 <@duck> (like breaking bt while i2p is getting fixed)</p>
13:36 < jrandom> aye, good plan</p>
13:36 <@duck> .</p>
13:37 < jrandom> ok cool, anyone else have anything on i2p-bt?</p>
13:37 < jrandom> if not, moving us along to 4) eepsites</p>
13:38 < jrandom> well, i know the issues have been discussed a few times since we first got the eepproxy, but there have been some recent queries warranting their mention again</p>
13:39 < bla> yes...</p>
13:39 < jrandom> what we have now for browsing eepsites and normal websites anonymously just plain isn't safe</p>
13:39 < clayboy> disabling java, javascript, cookies and flash helps, though</p>
13:39 < jrandom> DrWoo has done a great job with his page describing the dangers and how you can protect yourself</p>
13:40 < jrandom> right clayboy, definitely</p>
13:40 < clayboy> url?</p>
13:40 < bla> clayboy: Yes, on the HTML side, but not on the HTTP side</p>
13:40 < jrandom> but if there's one thing i've learned with the router console, its that no one follows more than two steps into the instructions ;)</p>
13:40 < clayboy> bla: good point</p>
13:40 < jrandom> clayboy: http://brittanyworld.i2p/browsing/</p>
13:41 < bla> I've done some experiments here: http://forum.i2p/viewtopic.php?t=182</p>
13:41 < bla> Doesn't look good as it is</p>
13:42 <@duck> who has the evil applets?</p>
13:42 < ant> &lt;Nightblade&gt; there was a security exploit found in java</p>
13:43 < ant> &lt;Nightblade&gt; for some older 1.4.x vers</p>
13:43 < ant> &lt;Nightblade&gt; not 1.5</p>
13:44 < jrandom> nightblade: the 'attack' used in this person's case was really trivial, and, according to the person, worked from 1.1.6-1.5</p>
13:44 < ant> &lt;Nightblade&gt; hmm</p>
13:44 < jrandom> (download a .exe, run the .exe)</p>
13:45 < jrandom> i was suprised to see some java security permissions fire up on instantiation of new File(filename) but no security permissions fire up on instantiation of new FileOutputStream(filename)</p>
13:45 * jrandom stops handing out hand grenades</p>
13:46 < jrandom> (i havent verified their code, but did see much of it)</p>
13:46 < jrandom> but anyway, eepsites</p>
13:47 < jrandom> well, i dont think it would be prudent to remove the eepproxy altogether</p>
13:47 < jrandom> but i dont really have time right now to implement any of the solutions listed</p>
13:48 < bla> jrandom: Stripping out all Accept* headers would be a good thing, for now</p>
13:48 < jrandom> what do y'all think? any volunteers? shall we wing it until we do get time?</p>
13:48 < ant> &lt;Nightblade&gt; bla: I don't think it is a big deal that people can see some browser headers</p>
13:49 < ant> &lt;Nightblade&gt; millions of people use those browsers</p>
13:49 < bla> And always adding a User-Agent: header, even if the client didn't send one. I makes requests homogeneous</p>
13:50 < bla> Nighblade: Yes, but if your browser says Accept-Language: xx (just made up on the spot), and there happens to be only 1 I2P node in a country that speaks language xx, almonimity is gone, completely</p>
13:50 < bla> The Accept-Language: header is there though, in some browsers. And we can't rely on it always being "en"</p>
13:50 < ant> &lt;Nightblade&gt; ok but what if removing some of those headers violates the HTTP spec?</p>
13:50 < jrandom> adding those two cases are easy enough, and i'll get them into 0.4.2.1, but it really isn't safe to explicitly filter headers like this</p>
13:50 < jrandom> nightblade: we break so many aspects of the HTTP spec it hurts</p>
13:51 < bla> Nightblade: Only one of the threee browsers I listed did send the header, so it shouldn't be much of a problem</p>
13:51 < ant> &lt;Connelly&gt; HTTP was not designed for anonymity</p>
13:51 < jrandom> the eepproxy is duct tape and shoe polish</p>
13:51 < bla> jrandom: Why isn't that filttering safe?</p>
13:52 < bla> jrandom: We could even consider stripping _all_ headeers, except for the Host: header and the GET header</p>
13:52 < jrandom> bla: stripping all headers except the host would be safer, yes</p>
13:52 < bla> jrandom: After all, what do we need more for an anonymous HTTP?</p>
13:52 < jrandom> but thats beyond the amount of time i can put into it</p>
13:52 < jrandom> i can add the Accept and user-agent filters in ~ 30s</p>
13:53 < jrandom> much beyond that and i throw my hands in the air and rewrite the http proxy ;)</p>
13:53 < bla> jrandom: How come stripping all of them is more difficult?</p>
13:53 < jrandom> read the code. </p>
13:54 < jrandom> (patches welcome)</p>
13:54 < jrandom> but what we're looking at here is still just a short term solution</p>
13:54 < bla> jrandom: Point well taken ;) But seriously: I think the Accept* and User-Agent fixes would do really fine for now</p>
13:54 < jrandom> we need someone to work on something that will last us long term</p>
13:55 < ant> * dm just ate 20 slices of cheese... drool.</p>
13:55 < jrandom> bla: i heard that last time someone asked us to filter the User-agent and referrer headers ;)</p>
13:55 < jrandom> (but yeah, i'll get those two into the next rev)</p>
13:56 < ant> &lt;dm&gt; those headers are usefl</p>
13:56 < ant> &lt;dm&gt; useful</p>
13:56 < ant> &lt;dm&gt; For service providers.</p>
13:56 < jrandom> yes, they are</p>
13:57 < jrandom> we've already had some apps break because we filter referrer too</p>
13:57 < bla> dmm: Yes, indeed. However, they also provide a browser or OS fingerprint</p>
13:57 < ant> &lt;dm&gt; I have an idea!</p>
13:57 * jrandom takes cover</p>
13:58 < ant> &lt;dm&gt; Hard code the User-Agent to: Nokia6230/2.0 (03.15) Profile/MIDP-2.0 Configuration/CLDC-1.1 149.254.201.133 </p>
13:58 < ant> &lt;dm&gt; eh? eh?</p>
13:58 < jrandom> we already hard code the user agent header</p>
13:59 < ant> &lt;Nightblade&gt; I2P-enabled cell phones</p>
13:59 * jrandom mounts a DoS on that phone</p>
13:59 < ant> &lt;dm&gt; To what?</p>
13:59 < ant> &lt;dm&gt; My poor phone!!!</p>
13:59 < jrandom> ok, anyone else have any thoughts on the eepproxy/eepsite stuff?</p>
14:00 < bla> MYOB/6.ss (AN/ON)</p>
14:00 < bla> no\</p>
14:00 <+Ragnarok> we should reinvent html using s-expressions!</p>
14:01 < jrandom> (i really do think using a bbcode style macro language is the way to go, at least for some things ;)</p>
14:01 < jrandom> ((or xml for you geeks))</p>
14:02 < ant> &lt;dm&gt; Microsoft endorses use of XML</p>
14:02 < ant> &lt;dm&gt; So I'm all for it.</p>
14:02 <+Ragnarok> xml is just excessively wordy s-expressions :)</p>
14:03 < ant> &lt;dm&gt; Is this a good time for me to aplaud jrandom for his work on this project?</p>
14:03 * jrandom volunteers Ragnarok to work on it, after getting the next gen address book ;)</p>
14:03 <@duck> I dont think that 'invent your own markup language' will work for general browsers</p>
14:04 <@duck> maybe for the blog thing inside myi2p</p>
14:04 <+Ragnarok> it's always a good time :)</p>
14:04 < ant> &lt;dm&gt; applaud even</p>
14:04 < jrandom> duck: the proxy will need to filter content anyway, it would be simple enough (heh) to inject the results of macro expansions into the resulting filtered content</p>
14:05 < ant> * dm tips his hat to jr.</p>
14:05 < jrandom> gracias dm et al</p>
14:05 < ant> &lt;Nightblade&gt; something like PDF would be safer than HTML</p>
14:05 < jrandom> lol</p>
14:05 <@duck> .txt files!</p>
14:06 < ant> &lt;Nightblade&gt; i've seem PDF files with clickable links, but the files themselves are huge</p>
14:06 < ant> &lt;Nightblade&gt; seen</p>
14:06 < ant> &lt;dm&gt; Uncompressed Bitmaps?</p>
14:06 < jrandom> yes, lets all write in pdf</p>
14:07 <+Ragnarok> erg, postscript is fugly</p>
14:07 < ant> &lt;cat-a-puss&gt; how is html insecure?</p>
14:07 <@duck> anyway</p>
14:07 < ant> &lt;Nightblade&gt; cat: with javascript, activex, applets,...</p>
14:07 < jrandom> cat-a-puss: all the different ways to encode dangerous data</p>
14:08 < ant> &lt;dm&gt; languages aren't secure or insecure, clients are.</p>
14:08 <+Ragnarok> the realy problem is how to do anon dhtml...</p>
14:08 < jrandom> (and we'll never, /never/ be ahead of the game as long as we explicitly filter)</p>
14:08 < ant> &lt;cat-a-puss&gt; Java/javascript are enclosed in tags. So strip those out, plain html is not harmful right?</p>
14:08 < ant> &lt;dm&gt; We need to use a data format that is parsed by a client made by a company that we trust.</p>
14:08 < jrandom> Ragnarok: macros, and/or reference known safe and locally installed javascript</p>
14:08 < ant> &lt;dm&gt; I trust Microsoft, therefore I suggest Internet Explorer, Microsoft Word, or Notepad</p>
14:09 < ant> &lt;dm&gt; Flight Simulator 2002 is acceptable as well.</p>
14:09 < ant> &lt;cat-a-puss&gt; Freenet already has an "anonymity filter" strips out all Java / Javascript / ActiveX etc. Borrow that and the only thing I can think could get through would be Image exploits... unless there is something I am missing.</p>
14:10 < jrandom> freenet's anon filter is a good start for one or two of the different camps, but would likely require some work to get forms working as we want them</p>
14:10 < ant> &lt;Nightblade&gt; the eepproxy would have to run as a separate process, because of licensing</p>
14:11 < jrandom> that still leaves us a heavily crippled html</p>
14:11 < jrandom> (with no css)</p>
14:11 < ant> &lt;dm&gt; Okay, how about Flash?</p>
14:11 < jrandom> nightblade: we can work around that (same way we work around i2ptunnel being GPL)</p>
14:11 < ant> &lt;dm&gt; Imagine a world wide web with only flash.</p>
14:11 < ant> &lt;dm&gt; What a rich and wonderful world that would be.</p>
14:12 < ant> &lt;Nightblade&gt; well Just create a warning: "Eepsite browsing is hazardous to your anonymity. Please use Gopher."</p>
14:12 < ant> &lt;Nightblade&gt; actually gopher is not a bad idea</p>
14:12 * jrandom ports archie</p>
14:12 <+Ragnarok> gopher!</p>
14:12 < ant> &lt;dm&gt; There was Betty as well, wasn't there...</p>
14:12 <+Ragnarok> I remember gopher :)</p>
14:13 <+Ragnarok> man, those were the good old days. I think I had a screaming 14.4 baud at the time... &lt;sigh&gt;</p>
14:13 < ant> &lt;Nightblade&gt; I only browsed gopher in text mode, and I don't know if it supported graphics</p>
14:13 < jrandom> they didnt have gui browsers last time i used gopher ;)</p>
14:14 < jrandom> anyway, there are lots of options</p>
14:14 < ant> &lt;Nightblade&gt; what was that browser called back then? the one before Netscape...</p>
14:14 < ant> &lt;Nightblade&gt; i forget</p>
14:14 < jrandom> mosaic</p>
14:15 < ant> &lt;Nightblade&gt; yeah</p>
14:15 < ant> &lt;dm&gt; Mosaic 2.0</p>
14:15 < ant> &lt;Nightblade&gt; "Welcome to I2P, please wait while we install Gopher and Mosaic."</p>
14:15 < jrandom> heh</p>
14:15 < jrandom> yeah, probably no javascript exploits in those</p>
14:16 < jrandom> ok, anyway, thats that, i suppose</p>
14:16 < jrandom> moving on to 5) ???</p>
14:16 <+Ragnarok> there's still a gopher package in debian</p>
14:16 < jrandom> anyone have anything else (not gopher related)?</p>
14:17 < ant> &lt;dm&gt; What will happen to I2P when you need to start working again?</p>
14:18 < jrandom> i'll be on i2p fulltime through the spring, at least. we can discuss things beyond then as that time approaches</p>
14:19 < ant> &lt;dm&gt; o k</p>
14:19 < jrandom> in any case, if i got hit by a bus tomorrow, everything is in cvs and all code is free</p>
14:19 <+Ragnarok> I assume you're planning to have a 1.0 before then. What do you think the odds are?</p>
14:19 <+Ragnarok> before spring, not your untimely demise...</p>
14:20 < jrandom> certainty.</p>
14:20 < ant> &lt;dm&gt; ahaha.. yes, what are the odds of 1.0 before tomorrow when you get hit by that bus?</p>
14:20 < jrandom> (assuming no buses ;)</p>
14:20 < ant> &lt;dm&gt; I just had a very sad thought.</p>
14:20 < ant> &lt;dm&gt; Depressing really, but... If you were to get hit by a bus, no one here would know of it.</p>
14:20 < ant> &lt;cat-a-puss&gt; On filtering: What if we created a better proxy, such that all the applications on the computer's traffic could go through it, then we would not need to filter Javascript et alt because they can't find out who we are anyway.</p>
14:21 < ant> &lt;dm&gt; You would just die, and we wouldn't know what happened :(</p>
14:21 < ant> &lt;dm&gt; God why did he have to die?!?!? why?!?!</p>
14:22 < ant> &lt;dm&gt; Can you put a clause in your will to email the mailing list if you die?</p>
14:22 < jrandom> cat-a-puss: javascript can send the contennts of your bookmarks, your IP address, and all sorts of things to a remote site</p>
14:22 < jrandom> dm: people who know me irl know i'm involved in i2p. enough of this morbid shit</p>
14:23 < ant> &lt;dm&gt; ah cool.</p>
14:24 < ant> &lt;cat-a-puss&gt; jrandom: yeah, but that sort of thing requres an exploit right, not just say forwarding them to some page that uses a different protocall that is not proxied. We probably be reasonable safe from those with a scanner on incomming content and automatic updates.</p>
14:25 < jrandom> cat-a-puss: erm, perhaps i misunderstood - are you suggesting that it may be safe to have javascript enabled in the browser, as long as the connections that that javascript code makes are proxied also?</p>
14:26 < ant> &lt;cat-a-puss&gt; jrandom: yeah, as long as there is no buffer overflows etc.</p>
14:26 < jrandom> if so, thats still vulnerable to plain old javascript that reads the javascrip environment and sends it "anonymously" to http://cia.i2p/data. </p>
14:27 < jrandom> the data available to javascript includes your IP address, as well as your bookmarks and all sorts of other things</p>
14:27 < jrandom> so even though the connection to cia.i2p was anonymous, the content exposes you</p>
14:31 < jrandom> ok, anyone else have something to bring up for the meeting?</p>
14:31 <@duck> yes:</p>
14:31 <@duck> what does the new 'active peers' counter mean</p>
14:31 < jrandom> ah</p>
14:31 < jrandom> yeah, that changed</p>
14:32 < jrandom> in 0.4.2.1, the new Active: x/y will have x=# of peers you've sent or received a message from successfully in the last minute, y=# peers seen in the last hour or so</p>
14:32 < jrandom> this is part of the code to deal with some peers giving out bad info in the IP autodetection phase</p>
14:33 * duck will try to remember it</p>
14:33 < jrandom> so it'll vary much more than before</p>
14:33 < jrandom> heh so dont worry when the value is lower than you're used to ;)</p>
14:34 < jrandom> ok, if thats it, then y'all should check back onto the mailing list and website over the next day for the 0.4.2.1 release</p>
14:34 < jrandom> it'll be backwards compatible, blah blah blah</p>
14:34 < jrandom> in any case</p>
14:34 * jrandom winds up</p>
14:35 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:08 < jrandom> 0) hi
13:08 < jrandom> 1) 0.4.2 and 0.4.2.1
13:08 < jrandom> 2) mail.i2p
13:08 < jrandom> 3) i2p-bt
13:08 < jrandom> 4) eepsites
13:08 < jrandom> 5) ???
13:09 < jrandom> 0) hi
13:09 < jrandom> sorry to interrupt dm's agenda
13:09 < jrandom> status notes up @ http://dev.i2p.net/pipermail/i2p/2004-November/000492.html
13:09 < jrandom> [hi]
13:10 <+postman> ((hi))
13:10 <+postman> :)
13:10 < jrandom> so, as y'all read through that overwhelmingly interesting email, we might as well get the meeting underway
13:10 < jrandom> 1) 0.4.2 and 0.4.2.1
13:11 < jrandom> 0.4.2 is out, as you know, and the results are mixed, but when its not failing bad, it seems to be doing much better ;)
13:12 < jrandom> there will be a release with a whole slew of bugfixes soon - i've been holding off to try to get as many things improved as possible
13:12 < jrandom> as things stand now though, it looks like the 0.4.2.1 release will not yet get the i2p-bt port into tip top shape quite yet
13:12 <+postman> jrandom: what do the bugfixes address - all errors in the new streaminglib or other stuff as well?
13:13 < jrandom> a fast busy loop in the streaming lib that came up from a poorly tested scenario, some SAM issues, IP address detection problems, among other things
13:14 < jrandom> dev.i2p.net/cgi-bin/cvsweb.cgi/~checkout~/i2p/history.txt?rev=HEAD has the full list
13:14 <+postman> k
13:14 <+postman> thx
13:15 < jrandom> oh, one thing to note about 0.4.2.1 is that it, like 0.4.2, will need to modify your wrapper.config again, so please pay attention to the update instructions when they're out :)
13:15 < jrandom> does anyone have any questions/comments/concerns about 0.4.2?
13:15 < jrandom> (/0.4.2.1)
13:16 < clayboy> been working great here, have been tracking cvs too, always smooth
13:16 < jrandom> wikked
13:17 < bla> It's table (0.4.2): up for days already
13:17 < bla> s/table/stable/
13:17 < jrandom> ah nice, yeah, the bugs havent been hitting everyone
13:17 < jrandom> ok, if there's nothing else on that, lets jump on to 2) mail.i2p
13:18 < jrandom> i hear postman has some things to discuss
13:18 <+postman> hello
13:18 < jrandom> hi postman, you're up :)
13:18 <+postman> weeks ago i conducted a poll regarding IMAP
13:19 <+postman> since a few weeks passed now i decided to close the polls and to count the vote
13:19 <+postman> result is: not needed - won't be done. period
13:19 <+postman> after talking to susi - she was quite fine wioth pop3 on her webmail interface
13:19 < clayboy> reason wins! :)
13:19 < jrandom> w3wt
13:20 <+postman> so let's just stick to the pop3 end bury any silly imap ideas
13:20 <+postman> :)
13:20 * jrandom gets the shovel
13:20 <+postman> 2.) we're close to 100 registered users
13:21 < clayboy> wow
13:21 <+postman> not all of them public of course, but it still sounds like a quite reasonable number regarding the size of the network
13:21 <+Ragnarok> so... how about that LDAP address book? :)
13:21 < jrandom> nice
13:21 <+postman> 3. a feature to upload/share you public pgp key is active since weekend
13:21 <+postman> please use it
13:21 <+postman> www.postman.i2p/user/acc.html
13:22 < clayboy> i'm not taking any credit for that idea :>
13:22 <+postman> the public keys can easily be downloaded with the help of the addressbook
13:22 <+postman> or direct as www.postman.i2p/public/accountname.pub
13:22 < jrandom> ooh cool
13:22 <+postman> the system works quite fine
13:22 <+postman> thanks to duck for pointing at a few bugs
13:23 <+postman> 4.) i think about offering accountbased routing
13:23 <+postman> like ppl say
13:23 < jrandom> account based routing?
13:23 <+postman> all mail for foo@mail.i2p gets transported to the following destination
13:23 <+postman> and user presents a valid destination key for it
13:24 <+postman> postman.i2p will then manually route mail to those accounts to mailsystems
13:24 <+postman> just an idea(tm)
13:24 < jrandom> ah nice
13:24 <+postman> i am looking forward to develop and discuss the whole matter
13:25 <+postman> that's it for now
13:25 <+postman> more follows next week
13:25 <+postman> thanks
13:25 < nmi> postman: sorry, transported to a particular i2p destination you mean?
13:25 * postman hands the mike back to jrandom
13:25 <+postman> nmi: yes
13:25 < ant> <Nightblade> am SMTP i2p destination?
13:25 < ant> <Nightblade> an
13:25 <+postman> nmi: provided the destination accepts smtp and mail for that account
13:25 < jrandom> that sounds very cool, gets rid of the trust aspect of the mail fiiltering
13:26 < nmi> ah, ok. clever. i had thought of doing something similar using mixminion single-use-reply-blocks but your idea is better...
13:26 < jrandom> its probably a lot of work to set up on the client side, but perhaps someone could do some hacking
13:26 <+postman> jrandom: i am working on it
13:26 < jrandom> w00t
13:26 <+postman> jrandom: the user will have the usual webinterface ( acc.html...)
13:27 <+postman> jrandom: and inserts the destinationkey
13:27 < jrandom> well, right, but then there's the MTA configuration
13:27 <+postman> the rest will be done automatigally
13:27 <+postman> yes, on the postman.i2p AND the receiving sinde
13:28 < nmi> jrandom: yeah, it would be cool to have a really stripped down smtp proxy for people not wanting to run a full MTA
13:28 < jrandom> right right
13:28 <+postman> jrandom: i will provide a simple setup config for ppl interested
13:28 <+postman> jrandom: for postfix, exim and sendmail
13:28 <+postman> jrandom: those can be stripped down to BARE necessities
13:28 <@duck> seriously, do you think that there are many users for that?
13:28 < jrandom> postman: this all sounds pretty kickass. i look forward to hearing more when you're ready
13:29 <+postman> jrandom: no idea about windows smtp servers tho
13:29 <+postman> duck: well
13:29 <+postman> duck: 8 weeks ago there was no need for a mailsystem and no users either
13:29 <+postman> duck: it's investment
13:29 <@duck> true
13:29 <+postman> duck: in 6 months we'll be happy to have it
13:29 < jrandom> duck: the potential comes with moving away from a trusted SMTP filter
13:29 <+postman> :)
13:30 < jrandom> er, perhaps i should say, moving /to/ a trusted smtp filter (no offense postman ;)
13:30 <+postman> and there will be a few ones
13:30 <+postman> AND
13:30 <+postman> (now the punchline)
13:30 <+postman> we could easily create maildomains :)
13:30 <+postman> like duck@duck.i2p and other stuff
13:30 <+postman> :)
13:30 <@duck> ah
13:31 <+postman> the only problem would be the official/private mapping
13:31 < jrandom> hosts.txt!
13:31 * jrandom ducks
13:31 <+postman> but this is another thing for the webmanagement console :)
13:31 <+postman> LOL
13:31 <+postman> jrandom: i rely on shaky sql databases :)
13:31 <@duck> ok; I see it fitting in
13:32 <+postman> ok
13:32 <+postman> then i will work it out and present an concept soon
13:32 <+postman> yess, yet more work
13:32 * postman leans back relaxed
13:32 <+postman> :)
13:32 < jrandom> kickass, thanks postman
13:33 < jrandom> ok, unless other people have further mail.i2p related questions, shall we move on to 3) i2p-bt?
13:33 < jrandom> consider us moved
13:34 < jrandom> ok, as the email mentioned, i broke the i2p-bt port
13:34 * jrandom hangs head in shame
13:34 < jrandom> in other news, duck, do you have anything wrt i2p-bt you want to discuss?
13:34 <@duck> as a result of jrandom's work not much has been done :)
13:35 <+Ragnarok> booo, hissss
13:35 <@duck> oh Ragnarok had some patches
13:35 * jrandom2p pelts jrandom with tomatoes
13:35 <@duck> I think, see the history file :)
13:35 < jrandom> oh cool
13:35 <@duck> we got some things in the queue too
13:35 <+Ragnarok> well, I was hissing at jr, but ok :)
13:36 <@duck> but I dont want to change (too) much on the unstable ground
13:36 <@duck> (like breaking bt while i2p is getting fixed)
13:36 < jrandom> aye, good plan
13:36 <@duck> .
13:37 < jrandom> ok cool, anyone else have anything on i2p-bt?
13:37 < jrandom> if not, moving us along to 4) eepsites
13:38 < jrandom> well, i know the issues have been discussed a few times since we first got the eepproxy, but there have been some recent queries warranting their mention again
13:39 < bla> yes...
13:39 < jrandom> what we have now for browsing eepsites and normal websites anonymously just plain isn't safe
13:39 < clayboy> disabling java, javascript, cookies and flash helps, though
13:39 < jrandom> DrWoo has done a great job with his page describing the dangers and how you can protect yourself
13:40 < jrandom> right clayboy, definitely
13:40 < clayboy> url?
13:40 < bla> clayboy: Yes, on the HTML side, but not on the HTTP side
13:40 < jrandom> but if there's one thing i've learned with the router console, its that no one follows more than two steps into the instructions ;)
13:40 < clayboy> bla: good point
13:40 < jrandom> clayboy: http://brittanyworld.i2p/browsing/
13:41 < bla> I've done some experiments here: http://forum.i2p/viewtopic.php?t=182
13:41 < bla> Doesn't look good as it is
13:42 <@duck> who has the evil applets?
13:42 < ant> <Nightblade> there was a security exploit found in java
13:43 < ant> <Nightblade> for some older 1.4.x vers
13:43 < ant> <Nightblade> not 1.5
13:44 < jrandom> nightblade: the 'attack' used in this person's case was really trivial, and, according to the person, worked from 1.1.6-1.5
13:44 < ant> <Nightblade> hmm
13:44 < jrandom> (download a .exe, run the .exe)
13:45 < jrandom> i was suprised to see some java security permissions fire up on instantiation of new File(filename) but no security permissions fire up on instantiation of new FileOutputStream(filename)
13:45 * jrandom stops handing out hand grenades
13:46 < jrandom> (i havent verified their code, but did see much of it)
13:46 < jrandom> but anyway, eepsites
13:47 < jrandom> well, i dont think it would be prudent to remove the eepproxy altogether
13:47 < jrandom> but i dont really have time right now to implement any of the solutions listed
13:48 < bla> jrandom: Stripping out all Accept* headers would be a good thing, for now
13:48 < jrandom> what do y'all think? any volunteers? shall we wing it until we do get time?
13:48 < ant> <Nightblade> bla: I don't think it is a big deal that people can see some browser headers
13:49 < ant> <Nightblade> millions of people use those browsers
13:49 < bla> And always adding a User-Agent: header, even if the client didn't send one. I makes requests homogeneous
13:50 < bla> Nighblade: Yes, but if your browser says Accept-Language: xx (just made up on the spot), and there happens to be only 1 I2P node in a country that speaks language xx, almonimity is gone, completely
13:50 < bla> The Accept-Language: header is there though, in some browsers. And we can't rely on it always being "en"
13:50 < ant> <Nightblade> ok but what if removing some of those headers violates the HTTP spec?
13:50 < jrandom> adding those two cases are easy enough, and i'll get them into 0.4.2.1, but it really isn't safe to explicitly filter headers like this
13:50 < jrandom> nightblade: we break so many aspects of the HTTP spec it hurts
13:51 < bla> Nightblade: Only one of the threee browsers I listed did send the header, so it shouldn't be much of a problem
13:51 < ant> <Connelly> HTTP was not designed for anonymity
13:51 < jrandom> the eepproxy is duct tape and shoe polish
13:51 < bla> jrandom: Why isn't that filttering safe?
13:52 < bla> jrandom: We could even consider stripping _all_ headeers, except for the Host: header and the GET header
13:52 < jrandom> bla: stripping all headers except the host would be safer, yes
13:52 < bla> jrandom: After all, what do we need more for an anonymous HTTP?
13:52 < jrandom> but thats beyond the amount of time i can put into it
13:52 < jrandom> i can add the Accept and user-agent filters in ~ 30s
13:53 < jrandom> much beyond that and i throw my hands in the air and rewrite the http proxy ;)
13:53 < bla> jrandom: How come stripping all of them is more difficult?
13:53 < jrandom> read the code.
13:54 < jrandom> (patches welcome)
13:54 < jrandom> but what we're looking at here is still just a short term solution
13:54 < bla> jrandom: Point well taken ;) But seriously: I think the Accept* and User-Agent fixes would do really fine for now
13:54 < jrandom> we need someone to work on something that will last us long term
13:55 < ant> * dm just ate 20 slices of cheese... drool.
13:55 < jrandom> bla: i heard that last time someone asked us to filter the User-agent and referrer headers ;)
13:55 < jrandom> (but yeah, i'll get those two into the next rev)
13:56 < ant> <dm> those headers are usefl
13:56 < ant> <dm> useful
13:56 < ant> <dm> For service providers.
13:56 < jrandom> yes, they are
13:57 < jrandom> we've already had some apps break because we filter referrer too
13:57 < bla> dmm: Yes, indeed. However, they also provide a browser or OS fingerprint
13:57 < ant> <dm> I have an idea!
13:57 * jrandom takes cover
13:58 < ant> <dm> Hard code the User-Agent to: Nokia6230/2.0 (03.15) Profile/MIDP-2.0 Configuration/CLDC-1.1 149.254.201.133
13:58 < ant> <dm> eh? eh?
13:58 < jrandom> we already hard code the user agent header
13:59 < ant> <Nightblade> I2P-enabled cell phones
13:59 * jrandom mounts a DoS on that phone
13:59 < ant> <dm> To what?
13:59 < ant> <dm> My poor phone!!!
13:59 < jrandom> ok, anyone else have any thoughts on the eepproxy/eepsite stuff?
14:00 < bla> MYOB/6.ss (AN/ON)
14:00 < bla> no\
14:00 <+Ragnarok> we should reinvent html using s-expressions!
14:01 < jrandom> (i really do think using a bbcode style macro language is the way to go, at least for some things ;)
14:01 < jrandom> ((or xml for you geeks))
14:02 < ant> <dm> Microsoft endorses use of XML
14:02 < ant> <dm> So I'm all for it.
14:02 <+Ragnarok> xml is just excessively wordy s-expressions :)
14:03 < ant> <dm> Is this a good time for me to aplaud jrandom for his work on this project?
14:03 * jrandom volunteers Ragnarok to work on it, after getting the next gen address book ;)
14:03 <@duck> I dont think that 'invent your own markup language' will work for general browsers
14:04 <@duck> maybe for the blog thing inside myi2p
14:04 <+Ragnarok> it's always a good time :)
14:04 < ant> <dm> applaud even
14:04 < jrandom> duck: the proxy will need to filter content anyway, it would be simple enough (heh) to inject the results of macro expansions into the resulting filtered content
14:05 < ant> * dm tips his hat to jr.
14:05 < jrandom> gracias dm et al
14:05 < ant> <Nightblade> something like PDF would be safer than HTML
14:05 < jrandom> lol
14:05 <@duck> .txt files!
14:06 < ant> <Nightblade> i've seem PDF files with clickable links, but the files themselves are huge
14:06 < ant> <Nightblade> seen
14:06 < ant> <dm> Uncompressed Bitmaps?
14:06 < jrandom> yes, lets all write in pdf
14:07 <+Ragnarok> erg, postscript is fugly
14:07 < ant> <cat-a-puss> how is html insecure?
14:07 <@duck> anyway
14:07 < ant> <Nightblade> cat: with javascript, activex, applets,...
14:07 < jrandom> cat-a-puss: all the different ways to encode dangerous data
14:08 < ant> <dm> languages aren't secure or insecure, clients are.
14:08 <+Ragnarok> the realy problem is how to do anon dhtml...
14:08 < jrandom> (and we'll never, /never/ be ahead of the game as long as we explicitly filter)
14:08 < ant> <cat-a-puss> Java/javascript are enclosed in tags. So strip those out, plain html is not harmful right?
14:08 < ant> <dm> We need to use a data format that is parsed by a client made by a company that we trust.
14:08 < jrandom> Ragnarok: macros, and/or reference known safe and locally installed javascript
14:08 < ant> <dm> I trust Microsoft, therefore I suggest Internet Explorer, Microsoft Word, or Notepad
14:09 < ant> <dm> Flight Simulator 2002 is acceptable as well.
14:09 < ant> <cat-a-puss> Freenet already has an "anonymity filter" strips out all Java / Javascript / ActiveX etc. Borrow that and the only thing I can think could get through would be Image exploits... unless there is something I am missing.
14:10 < jrandom> freenet's anon filter is a good start for one or two of the different camps, but would likely require some work to get forms working as we want them
14:10 < ant> <Nightblade> the eepproxy would have to run as a separate process, because of licensing
14:11 < jrandom> that still leaves us a heavily crippled html
14:11 < jrandom> (with no css)
14:11 < ant> <dm> Okay, how about Flash?
14:11 < jrandom> nightblade: we can work around that (same way we work around i2ptunnel being GPL)
14:11 < ant> <dm> Imagine a world wide web with only flash.
14:11 < ant> <dm> What a rich and wonderful world that would be.
14:12 < ant> <Nightblade> well Just create a warning: "Eepsite browsing is hazardous to your anonymity. Please use Gopher."
14:12 < ant> <Nightblade> actually gopher is not a bad idea
14:12 * jrandom ports archie
14:12 <+Ragnarok> gopher!
14:12 < ant> <dm> There was Betty as well, wasn't there...
14:12 <+Ragnarok> I remember gopher :)
14:13 <+Ragnarok> man, those were the good old days. I think I had a screaming 14.4 baud at the time... <sigh>
14:13 < ant> <Nightblade> I only browsed gopher in text mode, and I don't know if it supported graphics
14:13 < jrandom> they didnt have gui browsers last time i used gopher ;)
14:14 < jrandom> anyway, there are lots of options
14:14 < ant> <Nightblade> what was that browser called back then? the one before Netscape...
14:14 < ant> <Nightblade> i forget
14:14 < jrandom> mosaic
14:15 < ant> <Nightblade> yeah
14:15 < ant> <dm> Mosaic 2.0
14:15 < ant> <Nightblade> "Welcome to I2P, please wait while we install Gopher and Mosaic."
14:15 < jrandom> heh
14:15 < jrandom> yeah, probably no javascript exploits in those
14:16 < jrandom> ok, anyway, thats that, i suppose
14:16 < jrandom> moving on to 5) ???
14:16 <+Ragnarok> there's still a gopher package in debian
14:16 < jrandom> anyone have anything else (not gopher related)?
14:17 < ant> <dm> What will happen to I2P when you need to start working again?
14:18 < jrandom> i'll be on i2p fulltime through the spring, at least. we can discuss things beyond then as that time approaches
14:19 < ant> <dm> o k
14:19 < jrandom> in any case, if i got hit by a bus tomorrow, everything is in cvs and all code is free
14:19 <+Ragnarok> I assume you're planning to have a 1.0 before then. What do you think the odds are?
14:19 <+Ragnarok> before spring, not your untimely demise...
14:20 < jrandom> certainty.
14:20 < ant> <dm> ahaha.. yes, what are the odds of 1.0 before tomorrow when you get hit by that bus?
14:20 < jrandom> (assuming no buses ;)
14:20 < ant> <dm> I just had a very sad thought.
14:20 < ant> <dm> Depressing really, but... If you were to get hit by a bus, no one here would know of it.
14:20 < ant> <cat-a-puss> On filtering: What if we created a better proxy, such that all the applications on the computer's traffic could go through it, then we would not need to filter Javascript et alt because they can't find out who we are anyway.
14:21 < ant> <dm> You would just die, and we wouldn't know what happened :(
14:21 < ant> <dm> God why did he have to die?!?!? why?!?!
14:22 < ant> <dm> Can you put a clause in your will to email the mailing list if you die?
14:22 < jrandom> cat-a-puss: javascript can send the contennts of your bookmarks, your IP address, and all sorts of things to a remote site
14:22 < jrandom> dm: people who know me irl know i'm involved in i2p. enough of this morbid shit
14:23 < ant> <dm> ah cool.
14:24 < ant> <cat-a-puss> jrandom: yeah, but that sort of thing requres an exploit right, not just say forwarding them to some page that uses a different protocall that is not proxied. We probably be reasonable safe from those with a scanner on incomming content and automatic updates.
14:25 < jrandom> cat-a-puss: erm, perhaps i misunderstood - are you suggesting that it may be safe to have javascript enabled in the browser, as long as the connections that that javascript code makes are proxied also?
14:26 < ant> <cat-a-puss> jrandom: yeah, as long as there is no buffer overflows etc.
14:26 < jrandom> if so, thats still vulnerable to plain old javascript that reads the javascrip environment and sends it "anonymously" to http://cia.i2p/data.
14:27 < jrandom> the data available to javascript includes your IP address, as well as your bookmarks and all sorts of other things
14:27 < jrandom> so even though the connection to cia.i2p was anonymous, the content exposes you
14:31 < jrandom> ok, anyone else have something to bring up for the meeting?
14:31 <@duck> yes:
14:31 <@duck> what does the new 'active peers' counter mean
14:31 < jrandom> ah
14:31 < jrandom> yeah, that changed
14:32 < jrandom> in 0.4.2.1, the new Active: x/y will have x=# of peers you've sent or received a message from successfully in the last minute, y=# peers seen in the last hour or so
14:32 < jrandom> this is part of the code to deal with some peers giving out bad info in the IP autodetection phase
14:33 * duck will try to remember it
14:33 < jrandom> so it'll vary much more than before
14:33 < jrandom> heh so dont worry when the value is lower than you're used to ;)
14:34 < jrandom> ok, if thats it, then y'all should check back onto the mailing list and website over the next day for the 0.4.2.1 release
14:34 < jrandom> it'll be backwards compatible, blah blah blah
14:34 < jrandom> in any case
14:34 * jrandom winds up
14:35 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/118.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, November 30, 2004
==================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,174 +1,168 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 119{% endblock %}
{% block content %}<h3>I2P dev meeting, December 7, 2004</h3>
<div class="irclog">
22:00:00 <@duck> Tue Dec 7 21:00:00 UTC 2004</p>
22:00:04 <@duck> I2P meeting time</p>
22:00:05 < Frooze> i just made Frooze up for i2p. i don't even know what a 'frooze' is.</p>
22:00:21 <@duck> as announced on http://dev.i2p.net/pipermail/i2p/2004-December/000509.html</p>
22:00:29 <@duck> Agenda:</p>
22:00:29 <@duck> 0) hi</p>
22:00:29 <@duck> 1) 0.4.2.3</p>
22:00:29 <@duck> 2) i2p-bt</p>
22:00:29 <@duck> 3) #idlerpg</p>
22:00:29 <@duck> 4) ???</p>
22:00:32 <@duck> .</p>
22:01:09 <@duck> 0) hi</p>
22:01:15 < clayboy> hi</p>
22:01:16 <@duck> jrandom called in sick</p>
22:01:20 <+ugha2p> Hi.</p>
22:01:30 <@duck> plus msged me that he'd probably not make it</p>
22:01:39 <+protokol> http://www.google.com/search?q=frooze</p>
22:01:41 <@duck> so we'll see and just start</p>
22:01:46 < clayboy> hope he gets better quick</p>
22:02:06 <@duck> 1) 0.4.2.3</p>
22:02:16 <@duck> new release will be out Real Soon</p>
22:02:31 <@duck> so tomorrow or thursday.</p>
22:02:41 <@duck> there has been quite a few bugfixes</p>
22:03:24 <+ugha2p> Do newer CVS revisions also fix the memory/CPU issues?</p>
22:03:29 < clayboy> a few of us have been following the cvs builds, it's working very nicely</p>
22:03:33 <@duck> most streaming lib, sam bridge, etc</p>
22:04:17 <+ugha2p> I've been experiencing some uncommon loads from I2P.</p>
22:04:23 < clayboy> i think those were fixed many revisions ago, ugha2p</p>
22:04:41 <+ugha2p> (Running -7)</p>
22:04:51 < clayboy> oh, hm</p>
22:04:52 <@duck> ugha2p: dont see anything about that in the history</p>
22:05:48 <+protokol> you know what would be nice (if not feasable/worth it) is an RSS feed of the changelog</p>
22:05:48 <@duck> ok</p>
22:05:49 <+ugha2p> That's strange.</p>
22:06:01 <+protokol> ;-)</p>
22:06:17 <@duck> maybe file a bugzilla item</p>
22:06:25 <@duck> or dunno</p>
22:06:34 <+ugha2p> The Java process consumes 100% of CPU for about half of the time.</p>
22:07:18 <+ugha2p> So, you don't know anything about the issue? Do your routers behave OK?</p>
22:07:24 < dinoman> yea it is high for me to -6</p>
22:08:24 <@duck> top/uptime info is behaving weird for me since my nptl upgrade, so cant say</p>
22:09:03 <+ugha2p> Ok, maybe we should move on?</p>
22:09:07 <@duck> ok</p>
22:09:14 <@duck> 2) i2p-bt</p>
22:09:24 <+ugha2p> And ask jrandom when he is about to release 0.4.2.3</p>
22:09:40 <+ugha2p> It has worked fine for me with NPTL.</p>
22:09:45 <@duck> ugha2p: he said tomorrow or thursday</p>
22:09:58 <+ugha2p> Right.</p>
22:09:59 <@duck> yesterday I released a new i2p-bt</p>
22:10:23 <@duck> I gained some new understanding of the whole 'buffer' concept</p>
22:10:42 <@duck> plus there were some previous pending patches from Ragnarok</p>
22:11:13 < mule> duck: congratulations, good work!</p>
22:11:15 <@duck> also the slice size is increased, which means that instead of sending 32KB each time, it sends 128KB</p>
22:11:29 <@duck> which should keep the queue filled</p>
22:11:47 <+ugha2p> Yeah, thanks, duck. :)</p>
22:11:56 <@duck> DrWoo and others filed some GUI feature requests</p>
22:12:23 <@duck> but I never use the GUI myself, wouldnt know wxpython and probably dont care too much :)</p>
22:12:31 <+Ragnarok> fitting each slice into a single message didn't work as well as expected?</p>
22:12:57 < clayboy> many seeded torrents on http://brittanyworld.i2p/bittorrent/ if anyone want to try (with i2p 0.4.2.2-7 and i2p-bt 0.1.3)</p>
22:13:10 <@duck> Ragnarok: it is a bit of a guess</p>
22:13:27 <@duck> it gives much higher throughput values on local transfers</p>
22:13:51 <+ugha2p> Maybe we should wait for someone to port a full-featured client instead?</p>
22:14:10 <+Ragnarok> hm, ok</p>
22:14:13 <@duck> we can all wait :)</p>
22:14:37 < clayboy> BitTorrent _is_ "full featured", it's the only client i use for bt (also off i2p) :)</p>
22:15:15 <+ugha2p> clayboy: Not really. :)</p>
22:16:02 <@duck> personally I prefer things with sound defaults</p>
22:16:17 <@duck> take mldonkey, you can change 1 million things and most users have no idea what they do</p>
22:16:50 <@duck> this leads to user-myths, like i2p users hitting 'Reseed' all the time, or reinstalling if it doesnt work</p>
22:17:01 <+ugha2p> If you aren't willing to find out, then you shouldn't be using Linux anyway. :)</p>
22:17:04 <@duck> which kills kittens</p>
22:17:28 < slart> what about bittornado?</p>
22:17:43 <+Ragnarok> I suppose I could be tempted to write a pygtk gui, but I've got a lot of other stuff to do, and I'm not sure what people want</p>
22:17:45 <+protokol> azureus?</p>
22:17:57 <@duck> part of me is ofcourse making up excuses not to do things</p>
22:18:03 <+protokol> azureus supports plugins</p>
22:18:10 <@duck> protokol: well, write a plugin</p>
22:18:32 <+protokol> heh</p>
22:18:40 < slart> bittornado is based off the offical bt isnt it?</p>
22:18:50 <+protokol> easier said than done</p>
22:18:52 <@duck> slart: I have looked at it and wept</p>
22:19:07 <@duck> it has some improvements, which might be useful</p>
22:19:17 <@duck> but on the other hand it made the whole thing way more complex</p>
22:19:22 <@duck> without cleaning up the original code</p>
22:19:36 <+Ragnarok> gah</p>
22:19:56 <@duck> the GUI feature that you can specify a torrent if no arguments are given is taken from it and added to i2p-bt</p>
22:20:11 < clayboy> let's get the basic bittorrent working excellently before worrying about these fluffy gui things :)</p>
22:20:46 <@duck> slart: probably some other things can be used too; someone just has to do it (properly)</p>
22:21:23 <+ugha2p> clayboy: Well, I think it already does work excellently. :)</p>
22:21:53 < slart> the abc client uses tornado (i think)</p>
22:22:15 < clayboy> i feel like we have still to do some really heavy-duty testing to see how much data can really be pushed through i2p-bt</p>
22:22:21 < bushka> yes it does slart.</p>
22:23:49 <@duck> depending on how those work, you might be able to port the i2p-bt changes to them quite easily</p>
22:24:41 <@duck> please give it a try and report back</p>
22:25:47 <@duck> .</p>
22:25:55 <@duck> any other i2p-bt / bittorrent comments?</p>
22:26:08 < slart> python :S</p>
22:26:41 <+ugha2p> .</p>
22:26:51 <@duck> slart: if you dont like python, you can give porting azureus a try</p>
22:27:00 <+ugha2p> slart: What about it?</p>
22:27:06 < slart> how many people could we get seeding somthing like a linux is for speed testing?</p>
22:27:15 < slart> *iso</p>
22:27:34 <@duck> lets try that after the new i2p release</p>
22:27:57 <@duck> (since pulling an i2p router build from cvs is quite a challenge for most)</p>
22:28:17 <+protokol> eh</p>
22:28:54 <@duck> pl</p>
22:28:57 <@duck> err, ok</p>
22:29:10 <@duck> 3) #idlerpg</p>
22:29:22 <@duck> found this funny irc rpg game</p>
22:29:36 <@duck> you dont have to do anything for it, just idle </p>
22:29:56 <+ugha2p> Well, you do have to LOGIN. ;)</p>
22:30:04 <@duck> ah ;)</p>
22:30:18 < mule> cvs update -dP :)</p>
22:30:18 < mule> ant dist updater :)</p>
22:30:20 <+postman> it's the most hilarious thing i've ever seen, but i LIKE it :)</p>
22:30:30 <+protokol> there should be prizes</p>
22:30:45 <@duck> on ircnet it has 779 online players </p>
22:30:46 <+ugha2p> duck: I was thinking, that it could potentially be a reason not to upgrade.</p>
22:30:52 <+protokol> give yodels for winning stuff or reaching levels</p>
22:31:03 <+ugha2p> Although I'm not sure if people on I2P could be that childish. :)</p>
22:31:14 <+protokol> i know duck has like $10000 in yodels</p>
22:31:18 <@duck> protokol: yeah, I have to see how those quests work</p>
22:31:39 <@duck> maybe we can do some fun stuff with it</p>
22:31:42 <@duck> ugha2p: what do you mean?</p>
22:31:49 < ant> * cervantes is not going to do another 40 days without restarting his router</p>
22:32:08 <@duck> ugha2p: oh, not update because of the game :)</p>
22:32:18 <+protokol> Linux: If you can't fix it without restarting, you can't fix it.</p>
22:32:20 <@duck> well, I'll put it on pause while my router restarts</p>
22:32:24 <+ugha2p> :)</p>
22:32:33 <@duck> so if you sync it well, you wont lose</p>
22:32:35 <@duck> hehe</p>
22:32:55 < ant> &lt;cervantes&gt; thats good... since your router restarts all the time :P</p>
22:33:16 <@duck> thats called dedicated testing :)</p>
22:33:20 < ant> &lt;cervantes&gt; I guess that throws roulette into the equation too</p>
22:33:23 <@duck> ok</p>
22:33:38 <@duck> .</p>
22:33:49 <+ugha2p> .</p>
22:34:05 <@duck> 5) ???</p>
22:34:08 <@duck> s/5/4/</p>
22:34:12 <@duck> open mike!</p>
22:34:23 <+postman> .</p>
22:34:53 < mule> with a bit of tweaking you can two routers. one for the game only, which you upgrade only every year</p>
22:34:53 <@duck> questions? comments? suggestions?</p>
22:35:38 < ant> &lt;mahes&gt; Hi, i have a general non-dev question</p>
22:36:08 <@duck> shoot</p>
22:36:08 <+ugha2p> Thanks for holding the meeting, duck.</p>
22:36:50 < ant> &lt;mahes&gt; if i set up an eepsite , how can be reached with an address like i.e mahes.i2p</p>
22:36:59 <+protokol> i have a consern</p>
22:37:44 <+protokol> (start the battle) i think .i2p is a shitty TLD for many reasons</p>
22:38:19 <+ugha2p> mahes: What do you mean 'how'? People will configure their browsers to use the eepproxy, and just enter http://mahes.i2p/ onto their address bar.</p>
22:38:19 <+protokol> i think we should use one that is a) one syllable b) can be pronounced like a word c) does not include a number'</p>
22:38:46 <+ugha2p> protokol: Like .eep?</p>
22:39:07 <@duck> mahes:: to get a 'nice name' to point to your eepsite, it has to be present in your hosts.txt file</p>
22:39:37 <+protokol> ugha2p: sure</p>
22:40:01 <+ugha2p> protokol: You can make a proposal on the mailing list.</p>
22:40:03 <@duck> you can post it on the eepsite announcement forum so others can get it too</p>
22:40:09 <+ugha2p> It'll probably be considered once we have MyI2P.</p>
22:40:35 <+protokol> heh, ill try but jr shot it down for some reason already</p>
22:41:06 < ant> &lt;mahes&gt; well. i am just a user... ok, so i just publish mahes.i2p=hhfbwer8328... and it will just spread</p>
22:41:32 <@duck> it doesnt spread automatically, ppl need to get it into their hosts.txt somehow</p>
22:41:39 < ant> &lt;mahes&gt; ok</p>
22:41:52 <@duck> but announce it on the forum and it is more likely to :)</p>
22:42:34 <@duck> .</p>
22:43:18 <@duck> lets give it a *baf*</p>
22:43:20 <+ugha2p> .</p>
22:43:30 * ugha2p is waiting for the baffer.</p>
22:43:38 * duck winds up</p>
22:43:45 * duck *baf*s the meeting closed</p>
</div>
{% endblock %}
22:00:00 <@duck> Tue Dec 7 21:00:00 UTC 2004
22:00:04 <@duck> I2P meeting time
22:00:05 < Frooze> i just made Frooze up for i2p. i don't even know what a 'frooze' is.
22:00:21 <@duck> as announced on http://dev.i2p.net/pipermail/i2p/2004-December/000509.html
22:00:29 <@duck> Agenda:
22:00:29 <@duck> 0) hi
22:00:29 <@duck> 1) 0.4.2.3
22:00:29 <@duck> 2) i2p-bt
22:00:29 <@duck> 3) #idlerpg
22:00:29 <@duck> 4) ???
22:00:32 <@duck> .
22:01:09 <@duck> 0) hi
22:01:15 < clayboy> hi
22:01:16 <@duck> jrandom called in sick
22:01:20 <+ugha2p> Hi.
22:01:30 <@duck> plus msged me that he'd probably not make it
22:01:39 <+protokol> http://www.google.com/search?q=frooze
22:01:41 <@duck> so we'll see and just start
22:01:46 < clayboy> hope he gets better quick
22:02:06 <@duck> 1) 0.4.2.3
22:02:16 <@duck> new release will be out Real Soon
22:02:31 <@duck> so tomorrow or thursday.
22:02:41 <@duck> there has been quite a few bugfixes
22:03:24 <+ugha2p> Do newer CVS revisions also fix the memory/CPU issues?
22:03:29 < clayboy> a few of us have been following the cvs builds, it's working very nicely
22:03:33 <@duck> most streaming lib, sam bridge, etc
22:04:17 <+ugha2p> I've been experiencing some uncommon loads from I2P.
22:04:23 < clayboy> i think those were fixed many revisions ago, ugha2p
22:04:41 <+ugha2p> (Running -7)
22:04:51 < clayboy> oh, hm
22:04:52 <@duck> ugha2p: dont see anything about that in the history
22:05:48 <+protokol> you know what would be nice (if not feasable/worth it) is an RSS feed of the changelog
22:05:48 <@duck> ok
22:05:49 <+ugha2p> That's strange.
22:06:01 <+protokol> ;-)
22:06:17 <@duck> maybe file a bugzilla item
22:06:25 <@duck> or dunno
22:06:34 <+ugha2p> The Java process consumes 100% of CPU for about half of the time.
22:07:18 <+ugha2p> So, you don't know anything about the issue? Do your routers behave OK?
22:07:24 < dinoman> yea it is high for me to -6
22:08:24 <@duck> top/uptime info is behaving weird for me since my nptl upgrade, so cant say
22:09:03 <+ugha2p> Ok, maybe we should move on?
22:09:07 <@duck> ok
22:09:14 <@duck> 2) i2p-bt
22:09:24 <+ugha2p> And ask jrandom when he is about to release 0.4.2.3
22:09:40 <+ugha2p> It has worked fine for me with NPTL.
22:09:45 <@duck> ugha2p: he said tomorrow or thursday
22:09:58 <+ugha2p> Right.
22:09:59 <@duck> yesterday I released a new i2p-bt
22:10:23 <@duck> I gained some new understanding of the whole 'buffer' concept
22:10:42 <@duck> plus there were some previous pending patches from Ragnarok
22:11:13 < mule> duck: congratulations, good work!
22:11:15 <@duck> also the slice size is increased, which means that instead of sending 32KB each time, it sends 128KB
22:11:29 <@duck> which should keep the queue filled
22:11:47 <+ugha2p> Yeah, thanks, duck. :)
22:11:56 <@duck> DrWoo and others filed some GUI feature requests
22:12:23 <@duck> but I never use the GUI myself, wouldnt know wxpython and probably dont care too much :)
22:12:31 <+Ragnarok> fitting each slice into a single message didn't work as well as expected?
22:12:57 < clayboy> many seeded torrents on http://brittanyworld.i2p/bittorrent/ if anyone want to try (with i2p 0.4.2.2-7 and i2p-bt 0.1.3)
22:13:10 <@duck> Ragnarok: it is a bit of a guess
22:13:27 <@duck> it gives much higher throughput values on local transfers
22:13:51 <+ugha2p> Maybe we should wait for someone to port a full-featured client instead?
22:14:10 <+Ragnarok> hm, ok
22:14:13 <@duck> we can all wait :)
22:14:37 < clayboy> BitTorrent _is_ "full featured", it's the only client i use for bt (also off i2p) :)
22:15:15 <+ugha2p> clayboy: Not really. :)
22:16:02 <@duck> personally I prefer things with sound defaults
22:16:17 <@duck> take mldonkey, you can change 1 million things and most users have no idea what they do
22:16:50 <@duck> this leads to user-myths, like i2p users hitting 'Reseed' all the time, or reinstalling if it doesnt work
22:17:01 <+ugha2p> If you aren't willing to find out, then you shouldn't be using Linux anyway. :)
22:17:04 <@duck> which kills kittens
22:17:28 < slart> what about bittornado?
22:17:43 <+Ragnarok> I suppose I could be tempted to write a pygtk gui, but I've got a lot of other stuff to do, and I'm not sure what people want
22:17:45 <+protokol> azureus?
22:17:57 <@duck> part of me is ofcourse making up excuses not to do things
22:18:03 <+protokol> azureus supports plugins
22:18:10 <@duck> protokol: well, write a plugin
22:18:32 <+protokol> heh
22:18:40 < slart> bittornado is based off the offical bt isnt it?
22:18:50 <+protokol> easier said than done
22:18:52 <@duck> slart: I have looked at it and wept
22:19:07 <@duck> it has some improvements, which might be useful
22:19:17 <@duck> but on the other hand it made the whole thing way more complex
22:19:22 <@duck> without cleaning up the original code
22:19:36 <+Ragnarok> gah
22:19:56 <@duck> the GUI feature that you can specify a torrent if no arguments are given is taken from it and added to i2p-bt
22:20:11 < clayboy> let's get the basic bittorrent working excellently before worrying about these fluffy gui things :)
22:20:46 <@duck> slart: probably some other things can be used too; someone just has to do it (properly)
22:21:23 <+ugha2p> clayboy: Well, I think it already does work excellently. :)
22:21:53 < slart> the abc client uses tornado (i think)
22:22:15 < clayboy> i feel like we have still to do some really heavy-duty testing to see how much data can really be pushed through i2p-bt
22:22:21 < bushka> yes it does slart.
22:23:49 <@duck> depending on how those work, you might be able to port the i2p-bt changes to them quite easily
22:24:41 <@duck> please give it a try and report back
22:25:47 <@duck> .
22:25:55 <@duck> any other i2p-bt / bittorrent comments?
22:26:08 < slart> python :S
22:26:41 <+ugha2p> .
22:26:51 <@duck> slart: if you dont like python, you can give porting azureus a try
22:27:00 <+ugha2p> slart: What about it?
22:27:06 < slart> how many people could we get seeding somthing like a linux is for speed testing?
22:27:15 < slart> *iso
22:27:34 <@duck> lets try that after the new i2p release
22:27:57 <@duck> (since pulling an i2p router build from cvs is quite a challenge for most)
22:28:17 <+protokol> eh
22:28:54 <@duck> pl
22:28:57 <@duck> err, ok
22:29:10 <@duck> 3) #idlerpg
22:29:22 <@duck> found this funny irc rpg game
22:29:36 <@duck> you dont have to do anything for it, just idle
22:29:56 <+ugha2p> Well, you do have to LOGIN. ;)
22:30:04 <@duck> ah ;)
22:30:18 < mule> cvs update -dP :)
22:30:18 < mule> ant dist updater :)
22:30:20 <+postman> it's the most hilarious thing i've ever seen, but i LIKE it :)
22:30:30 <+protokol> there should be prizes
22:30:45 <@duck> on ircnet it has 779 online players
22:30:46 <+ugha2p> duck: I was thinking, that it could potentially be a reason not to upgrade.
22:30:52 <+protokol> give yodels for winning stuff or reaching levels
22:31:03 <+ugha2p> Although I'm not sure if people on I2P could be that childish. :)
22:31:14 <+protokol> i know duck has like $10000 in yodels
22:31:18 <@duck> protokol: yeah, I have to see how those quests work
22:31:39 <@duck> maybe we can do some fun stuff with it
22:31:42 <@duck> ugha2p: what do you mean?
22:31:49 < ant> * cervantes is not going to do another 40 days without restarting his router
22:32:08 <@duck> ugha2p: oh, not update because of the game :)
22:32:18 <+protokol> Linux: If you can't fix it without restarting, you can't fix it.
22:32:20 <@duck> well, I'll put it on pause while my router restarts
22:32:24 <+ugha2p> :)
22:32:33 <@duck> so if you sync it well, you wont lose
22:32:35 <@duck> hehe
22:32:55 < ant> <cervantes> thats good... since your router restarts all the time :P
22:33:16 <@duck> thats called dedicated testing :)
22:33:20 < ant> <cervantes> I guess that throws roulette into the equation too
22:33:23 <@duck> ok
22:33:38 <@duck> .
22:33:49 <+ugha2p> .
22:34:05 <@duck> 5) ???
22:34:08 <@duck> s/5/4/
22:34:12 <@duck> open mike!
22:34:23 <+postman> .
22:34:53 < mule> with a bit of tweaking you can two routers. one for the game only, which you upgrade only every year
22:34:53 <@duck> questions? comments? suggestions?
22:35:38 < ant> <mahes> Hi, i have a general non-dev question
22:36:08 <@duck> shoot
22:36:08 <+ugha2p> Thanks for holding the meeting, duck.
22:36:50 < ant> <mahes> if i set up an eepsite , how can be reached with an address like i.e mahes.i2p
22:36:59 <+protokol> i have a consern
22:37:44 <+protokol> (start the battle) i think .i2p is a shitty TLD for many reasons
22:38:19 <+ugha2p> mahes: What do you mean 'how'? People will configure their browsers to use the eepproxy, and just enter http://mahes.i2p/ onto their address bar.
22:38:19 <+protokol> i think we should use one that is a) one syllable b) can be pronounced like a word c) does not include a number'
22:38:46 <+ugha2p> protokol: Like .eep?
22:39:07 <@duck> mahes:: to get a 'nice name' to point to your eepsite, it has to be present in your hosts.txt file
22:39:37 <+protokol> ugha2p: sure
22:40:01 <+ugha2p> protokol: You can make a proposal on the mailing list.
22:40:03 <@duck> you can post it on the eepsite announcement forum so others can get it too
22:40:09 <+ugha2p> It'll probably be considered once we have MyI2P.
22:40:35 <+protokol> heh, ill try but jr shot it down for some reason already
22:41:06 < ant> <mahes> well. i am just a user... ok, so i just publish mahes.i2p=hhfbwer8328... and it will just spread
22:41:32 <@duck> it doesnt spread automatically, ppl need to get it into their hosts.txt somehow
22:41:39 < ant> <mahes> ok
22:41:52 <@duck> but announce it on the forum and it is more likely to :)
22:42:34 <@duck> .
22:43:18 <@duck> lets give it a *baf*
22:43:20 <+ugha2p> .
22:43:30 * ugha2p is waiting for the baffer.
22:43:38 * duck winds up
22:43:45 * duck *baf*s the meeting closed

10
i2p2www/meetings/119.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, December 7, 2004
=================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,10 +1,3 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 12{% endblock %}
{% block content %}
<h3>I2P (invisiblenet) Development Meeting 12</h3>
<div class="irclog">
Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
--- Log opened Wed Sep 25 00:57:27 2002
00:57 -!- Topic for #iip-dev: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/
00:57 [Users #iip-dev]
@@ -89,7 +82,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
01:11 <@nop> oh and DC people have been whispering in my ear to thank the Lord
01:11 <@nop> ;)
01:12 < Neo> lol
01:12 <@nop> well, on a side note, thank life for it is a neat thing ;) &lt;-- no comments
01:12 <@nop> well, on a side note, thank life for it is a neat thing ;) <-- no comments
01:12 <@nop> .
01:13 <@nop> any questions
01:13 <@nop> suggestions
@@ -313,7 +306,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
01:41 < Dag> one thing is certain in this day and age
01:41 < ellison> there's no reason you couldn't submit freenet files to the service
01:42 < ellison> dag: there would be concern if there was any evidence that they are funded by the RIAA, but it doesn't look like it to me
01:42 < Dag> ellison a md5-&gt;file content database
01:42 < Dag> ellison a md5->file content database
01:42 < Dag> would maybe work
01:42 < Dag> but can be abused as well
01:42 < Dag> its all about who controlls the data
@@ -533,7 +526,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
02:33 < aum> default freenet datastore is 1GB these days
02:34 < Dag> yikes
02:34 <@nop> what?
02:34 < aum> on another subject, i uninstalled gentoo last night and went back to debian =&gt; bliss
02:34 < aum> on another subject, i uninstalled gentoo last night and went back to debian => bliss
02:34 <@nop> really?
02:34 < aum> the source-based distros are too flaky just now
02:34 < Dag> go back to freebsd
@@ -545,7 +538,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
02:35 < aum> debian stuff works wight out of the box - no need to read megs of manuals and grope through scripts
02:36 < Dag> I always compile my servers
02:36 < aum> i've had debian woody on my server for over a year - switched desktop from windows back in feb
02:37 < aum> my desktop went windoes -&gt; mandrake -&gt; debian -&gt; sourcemage -&gt; gentoo -&gt; debian
02:37 < aum> my desktop went windoes -> mandrake -> debian -> sourcemage -> gentoo -> debian
02:37 < Dag> you ever try knoppix?
02:37 < aum> what's that?
02:37 < aum> a distro?
@@ -615,5 +608,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
08:05 < nop> sheesh
08:05 < nop> still here
--- Log closed Wed Sep 25 10:20:49 2002
</div>
{% endblock %}

10
i2p2www/meetings/12.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, September 24, 2002 @ 23:00 UTC
===============================================
Quick recap
-----------
TODO
Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
------------

View File

@@ -1,490 +1,484 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 120{% endblock %}
{% block content %}<h3>I2P dev meeting, December 14, 2004</h3>
<div class="irclog">
13:08 < jrandom> 0) hi</p>
13:08 < jrandom> 1) Net status</p>
13:08 < jrandom> 2) mail.i2p</p>
13:08 < jrandom> 3) roadmap</p>
13:08 <+polecat> It's almost as if the nodes are using the time they got 5 min ago, and setting it to the current time instead of the real time.</p>
13:09 < jrandom> 4) i2pcontent</p>
13:09 < jrandom> 5) i2p-bt</p>
13:09 < jrandom> 6) ???</p>
13:09 < jrandom> 0) hi</p>
13:09 < jrandom> weekly status notes posted a few minutes back to http://dev.i2p.net/pipermail/i2p/2004-December/000522.html</p>
13:09 * Pseudonym waves</p>
13:10 < cervantes> thanks for waiting.... just got back from work ;-)</p>
13:10 < jrandom> polecat: it isnt exactly 5m (but we can discuss further after the meeting or in it)</p>
13:10 * polecat nod</p>
13:10 < jrandom> w3rd, well, i'll give you a moment to jump into the status notes then :)</p>
13:11 < jrandom> in the meantime, 1) Net status</p>
13:11 * postman waves</p>
13:11 < jrandom> the other day, as mentioned on the list, it was pretty turbulent on irc</p>
13:12 < jrandom> we've made some adjustments though and the bugfixes have gone pretty well</p>
13:12 * dm waves</p>
13:12 < jrandom> in addition to the time sync issue mentioned in the mail, there's also a "leases expiring" problem that some have been reporting</p>
13:13 < Pseudonym> are they related?</p>
13:13 <+protokol> (for months)</p>
13:13 < Pseudonym> (the issues, not the people)</p>
13:13 < jrandom> thats due in part to a variety of issues, some of which may be addressed by the patches in CVS, some of which may be time sync related, but most of which are due to issues we're working on for the 0.5 release</p>
13:14 < jrandom> the essence of the problem is that the peer is sometimes unable to build tunnels for the client, which means it won't ask the client for a new lease</p>
13:14 < jrandom> the solution is to make sure we can build new tunnels that meet the client's needs</p>
13:15 < Pseudonym> and if we can't?</p>
13:15 < jrandom> if we can't, the leases will stay expired until we can</p>
13:16 < Pseudonym> so, how is that different?</p>
13:16 < jrandom> it isn't :) </p>
13:16 < jrandom> we need to be able to build tunnels, period.</p>
13:16 < jrandom> to assure that we can, we must both improve our profiling (see: cvs fixes for a long standing profiling bug) and improve our pooling strategy (see: 0.5)</p>
13:17 < jrandom> the only legitimate cause for not being able to build tunnels is if the entire net is completely saturated</p>
13:17 <+polecat> or you're cut off from it</p>
13:17 < jrandom> right</p>
13:17 < bla> jrandom: Can this be because the net has grown to ~110 peers?</p>
13:18 < dm> or its cut off from you</p>
13:18 < jrandom> nah, we've seen this before too bla</p>
13:18 < Pseudonym> are the "cvs fixes for a long standing profiling bug" in 0.4.2.3 or just CVS?</p>
13:18 < jrandom> though in a way, i suppose it is, since we now have a lot more peers that we have no profiling data on</p>
13:18 < jrandom> Pseudonym: CVS</p>
13:19 <+polecat> By profiling you mean ranking peers according to how helpful they are?</p>
13:19 < jrandom> yeah</p>
13:19 * Pseudonym wants 0.4.2.4 ;-)</p>
13:19 <+polecat> Phew.</p>
13:19 <+polecat> Thought it was some weird kinda function tracing like gprof or something.</p>
13:20 * orion wants 2.0 :)</p>
13:20 < jrandom> hehe naw, the profiling bug was in part due to some stupid code that was ignoring daily stats</p>
13:20 * jrandom too</p>
13:20 * polecat wants the larval form of a large dog.</p>
13:20 < jrandom> ok, well, thats about all i've got to bring up for 1) net status - anyone else have anything to add?</p>
13:21 < jrandom> if not, moving on to 2) mail.i2p</p>
13:21 < jrandom> postman: you've got the floor</p>
13:22 <+postman> ok</p>
13:22 <+postman> sorry</p>
13:22 <+postman> :)</p>
13:23 <+postman> there's a description for a complete handling of virtual maildomains on www.postman.i2p/user/virtual</p>
13:23 <+postman> there's a description for a complete handling of virtual maildomains on www.postman.i2p/user/virtual.html</p>
13:23 <+postman> (too much red wine)</p>
13:23 < dm> this is a very unprofessional presentation!</p>
13:23 <+postman> it tries to explain a system how to handle maildomains other than @mail.i2p addresses</p>
13:23 < frosk> :D</p>
13:24 * orion smacks dm in the head with the chalkboard eraser.</p>
13:24 < frosk> does that i can have frosk@frosk.i2p?</p>
13:24 <+postman> frosk: indeed</p>
13:24 < jrandom> v.cool</p>
13:24 <+polecat> The question is, why? :3</p>
13:24 <+postman> it's quite complex, still i ask for comments and ideas for this one</p>
13:24 < cervantes> s/eraser/</p>
13:24 < frosk> froody cool</p>
13:25 <+postman> it might not be a needed feature for a few ppl but the future is bright and shiny</p>
13:25 < jrandom> there are lots of reasons why - e.g. giving each user @ forum.i2p a mail address, etc</p>
13:25 < susi23> its a central system bound to postman.i2p</p>
13:25 <+polecat> Yes, that much seems clear.</p>
13:25 < susi23> if that machine fails, we're all upset :)</p>
13:25 <+polecat> jrandom: But if it all has to go through mail.i2p in the first place...</p>
13:25 * postman is VERY aware of this problem </p>
13:26 <+postman> :/</p>
13:26 < jrandom> polecat: perhaps, but perhaps not</p>
13:26 <+polecat> susi23: exactly!</p>
13:26 <+postman> the recent implementation is indeed quite single point of failure </p>
13:26 <+postman> but this applys to the internet bridge as well</p>
13:27 < jrandom> oh, the second gateway isn't in place yet?</p>
13:27 <+polecat> One solution is to put multiple destinations in the client SMTP/POP3 tunnels, and have all these destinations relay only with each other.</p>
13:27 <+postman> jrandom: no baffled has not setup yet</p>
13:27 < jrandom> ah ok</p>
13:27 <+postman> polecat: and on WHAT pop3 server should YOUR mailbox reside</p>
13:27 < orion> shiny is good, but how tould that virtual address relate to an internet address? I like the fact that orion@mail.i2p and orion@i2pmail.org are both usable.</p>
13:27 < orion> s/usable/identical/</p>
13:28 <+postman> polecat: who wants to transfer 100MBs of mailbox data every day in 1 year for all 10000 users?</p>
13:28 <+postman> orion: they will be usable</p>
13:28 <+polecat> instead of going mail.i2p -&gt; polecat.i2p -&gt; frosk@baffled.i2p, it could go to either of the 3, and from there straight to baffled.</p>
13:29 <+postman> i ask all ppl interested to contribute some ideas</p>
13:29 <+postman> still the virtual domains is a feature that appears useful and can be implemented regardless of the state of the network</p>
13:29 <+polecat> So if mail.i2p ever dies, the other two will have their server tunnels available as alternatives into the mail relay system.</p>
13:30 <+postman> polecat: still there is the question of your mailbox </p>
13:30 <+postman> polecat: your mailbox data must be moved as well and kept synchronized between ALL possible location</p>
13:30 <+polecat> Ugh... yeah that's true...</p>
13:30 <+postman> polecat: just consider this for 1000 users in the future</p>
13:30 < susi23> everybody could set up a destination on their nodes where mails are delivered to... now we have to problem to connect destinations to mail addresses</p>
13:30 <+postman> it's not THAT easy</p>
13:30 <+polecat> Oh! But this would work though...</p>
13:30 <+postman> indeed</p>
13:31 <+postman> otoh the problem of relaying from and to the internet is still there</p>
13:31 < dm> jrandom: you're enjoying this, aren't you?</p>
13:31 <+polecat> Yes! A user chooses which server to have their POP3 mailbox on, and that is the server they choose as destination for the POP3 tunnel.</p>
13:31 <+postman> polecat: what if THIS server fails?</p>
13:32 <+polecat> So mail.i2p and polecat.i2p never even have to see baffled's POP3 mailbox, since all of baffled's POP3 users download straight from baffled.</p>
13:32 <+postman> a real redundant system will require a mailbox sync</p>
13:32 < susi23> yeah, but with such a system everybody could deliver mails within i2p, even if postman.i2p would not be there</p>
13:32 <+polecat> postman: Then they have to change servers. -.-</p>
13:32 < dm> Students having an intelligent conversation between each other. A professor's dream :)</p>
13:32 <+postman> well, the meeting is hardly the place to DISCUSS all those things</p>
13:33 <+postman> i am just here to trigger the discussion</p>
13:33 <+postman> read the document first please and AFTER THAT i am ready to hear your comments</p>
13:33 <+postman> 2.</p>
13:33 <+polecat> Alright, so mail.i2p is in the works, and attempting to become less centralized and single point failurey.</p>
13:33 <+postman> we officially crossed the 100 users with 110 registered accounts</p>
13:33 <+postman> just FYI</p>
13:33 < jrandom> w00t</p>
13:34 <+postman> thats all for today :)</p>
13:34 <+postman> thanks </p>
13:34 * dm applauds</p>
13:34 < jrandom> kickass, thanks postman. it all looks promising</p>
13:34 <+postman> :)</p>
13:35 < mule2> i'd like to bring up a topic on mail, but after the meeting</p>
13:35 < jrandom> perhaps some mail-decentralization discussions could go on over the list or on the forum? but for now what you've got set up more than meets our needs</p>
13:35 <+postman> there's even a channel for it</p>
13:35 <+postman> :)</p>
13:35 < jrandom> heh good point </p>
13:35 < frosk> which one?</p>
13:36 < jrandom> #mail.i2p</p>
13:36 <+postman> frosk: #mail.i2p</p>
13:36 <+polecat> Oh, one quick note I just surprised myself by getting a little perl caching SMTP server going, so emacs doesn't hang waiting for postman's SMTP server to respond over i2p.</p>
13:36 < frosk> ok</p>
13:36 <+polecat> I might post some code later, if it works like, really well.</p>
13:36 < jrandom> oh, kickass polecat </p>
13:36 < cervantes> postman: you're welcome to have a dedicated section on the forum</p>
13:37 <+postman> cervantes: ohh thanks</p>
13:37 * postman feels honoured :)</p>
13:37 < dm> You deserve it</p>
13:38 * postman hands the mike back to hr</p>
13:38 * postman hands the mike back to jr</p>
13:38 <+postman> damn</p>
13:38 <+postman> :)</p>
13:38 < jrandom> ok, if there's nothing else on 2) mail.i2p, lets jump on over to 3) roadmap</p>
13:38 <+polecat> vroom vroom!</p>
13:38 < jrandom> the old roadmap was looking a little... out of date</p>
13:39 < jrandom> the new one reflects the current view of things</p>
13:39 < jrandom> hopefully the schedule listed has enough padding, though if more people jump on board perhaps we can beat those estimates :)</p>
13:40 < jrandom> once we've hit 0.6, we'll be able to scale to large numbers of nodes, as we wont have the thread-imposed ceiling</p>
13:41 < frosk> what do you think is a realistic node limit for &lt; 0.6?</p>
13:41 < jrandom> prior to 0.6 though, we'll probably need to stay under 200 active nodes, though we can probably stop being so lazy and actively kill some connections</p>
13:41 < jrandom> with some care, i think we'll be able to get up to 3-500</p>
13:42 < mule2> so no slashdotting please</p>
13:42 < jrandom> we'd have connection churn at that point, but our low-cost tcp transport shouldn't hurt too much</p>
13:42 < Pseudonym> the roadmap for 0.6 doesn't mention that. just udp and content dist</p>
13:42 < Pseudonym> or is it the udp that fixes it?</p>
13:42 * orion votes for no slashdotting ever</p>
13:43 < jrandom> Pseudonym: udp fixes it (http://www.i2p.net/todo#transport )</p>
13:43 < cervantes> postman: http://forum.i2p/viewforum.php?f=22</p>
13:44 < Pseudonym> orion: I disagree. to get real anonymity we're going to need LOTS of nodes eventually</p>
13:44 < Pseudonym> at some point we have to tell people about it</p>
13:44 < jrandom> agreed. when we need 'em, we'll definitely want to do all sorts of PR</p>
13:44 < jrandom> the geek crowd will likely be a large part of the userbase</p>
13:44 < Pseudonym> when do we announce to the geek community? not as a finished product but as a beta for tire-kicking</p>
13:44 < Frooze> Ask JRandom</p>
13:45 <+polecat> I think we should be very careful about making this network too popular.</p>
13:45 < jrandom> Pseudonym: when we've done the best tire kicking we can without them</p>
13:45 <+polecat> Because one of these days someone is going to use it to do something horrible and illegal.</p>
13:45 <+polecat> And if we can be tracked down at that point, we will be persecuted right along with the criminal.</p>
13:46 < jrandom> basically, once the network works great consistently and we're not able to do tihngs to b0rk it up, /then/ we'll need to get more users to help break/test it</p>
13:47 < mule2> you have to kick me off before :9</p>
13:47 < Pseudonym> just don't fall into the same trend as Toad with freenet</p>
13:47 <+polecat> Because we gave them the freedom to post the source code for Windows XPQXR, and Halo 7, so we'd better as all heck have good anonymity protection.</p>
13:47 < orion> speaking of b0rking... was that time-skew bug ever identified?</p>
13:47 < jrandom> Pseudonym: i believe our roadmap is realistic</p>
13:48 < jrandom> polecat: agreed, people shouldn't use i2p for things that are 'dangerous' yet</p>
13:48 < jrandom> orion: no</p>
13:48 < Pseudonym> jr: I'm not complaining about the roadmap. but it doesn't address announcements</p>
13:48 < jrandom> true</p>
13:49 < dm> well, with 2 years of development/testing under its belt, it should be one of the most polished offerings of this type when it launches :)</p>
13:49 < Pseudonym> perhaps add slashdotting to 0.6? :-)</p>
13:49 <+polecat> jrandom: More importantly, people who would use i2p for things that dangerous would do us a lot of good if they didn't know about i2p just yet.</p>
13:49 < jrandom> i was thinking about that the other day. perhaps some announcements for other activities (e.g. I2PContent) would make sense, to draw more people in to work on them</p>
13:49 < dm> as opposed the usual level of maturity when things go big</p>
13:50 < ant> &lt;jnymo&gt; i think jrandom should write the slashdot article.. he's best at describing i2p, i think</p>
13:50 * Pseudonym agrees</p>
13:51 < dm> I'm sure something will go on there before jrandom is comfortable to do it himself ;)</p>
13:51 < Pseudonym> I'm just trying to nudge him a bit</p>
13:51 < jrandom> heh</p>
13:51 < jrandom> well, with 0.6 we'll want to attract a larger user base in any case</p>
13:51 < Pseudonym> I figure if I can't code, I can at least pester the people who can</p>
13:51 * jrandom flings mud</p>
13:52 <+polecat> dm: I'm sure the Second Coming will pass before jrandom is comfortable enough to /. i2p ;3</p>
13:52 * Pseudonym ducks. quack</p>
13:52 < jrandom> ok, in any case, anyone have anything else to discuss wrt the roadmap?</p>
13:52 < jrandom> or shall we move on to 4) I2PContent ?</p>
13:53 -!- Irssi: #i2p: Total of 36 nicks [1 ops, 0 halfops, 3 voices, 32 normal]</p>
13:53 < jrandom> frosk: ping</p>
13:53 * frosk grabs the wireless mic</p>
13:54 < cervantes> *zzzzzZzzzzttt*</p>
13:54 * orion plugs in his RF jammer. ;)</p>
13:54 <+polecat> I have been trying to get ahold of frosk, without luck as such yet. Frankly I think I might never see em on IRC, and eir email is a sightless void.</p>
13:54 < frosk> well, jrandom put this "distributed content infrastructure" on the new roadmap for 0.6, and after hearing some thoughts about it here, it sounded really interesting, and i figure i should do whatever my skills allow to beat the schedule ;)</p>
13:54 * dm looks at polecat</p>
13:54 <+polecat> *shakes head* Just no luck whatsoever. No where to be FOUND. Maybe frosk is invisible!</p>
13:55 < frosk> "i2pcontent" is so far a document at frosk.i2p</p>
13:55 < Pseudonym> how is I2PContent different from i2p-bt?</p>
13:55 * polecat is on 4.4 atm.</p>
13:55 < frosk> it merges the ideas i've heard with my own, and it has gone through some revisions with helpful comments and suggestsions from jrandom and others, and i think it's starting to look very cool :)</p>
13:55 < ant> * jnymo tries to find a postscript viewer to see these ideas.. :/</p>
13:56 < dm> what is it, I can't get to frosk.i2p. Executive summary?</p>
13:56 <+polecat> Pseudonym: i2p-bt only applies to 1 file at a time, and is a swarming download.</p>
13:56 < frosk> Pseudonym: i2pcontent is a lot like Usenet</p>
13:56 < frosk> it merges concepts from usenet and freenet. i shall refrain from calling it "frusenet".</p>
13:56 < jrandom> lol</p>
13:56 <+polecat> Did you get my suggestion on i2pcontent?</p>
13:56 < jrandom> frusenet has a ring to it...</p>
13:56 < frosk> i2pcontent lets you post messages to your blog or to public forums, and publish your address book for others to import</p>
13:56 * dm did not refrain from calling it frazaa</p>
13:56 <+polecat> It merges usenet, freenet and livejournal. So.... Fusejournal?</p>
13:56 < jrandom> rofl</p>
13:57 < frosk> hm, yeah, LJ too ;)</p>
13:57 <+polecat> Lj is the closest parallel I've found.</p>
13:57 <+polecat> But here's one thing I didn't read in your i2pcontent document.</p>
13:57 < frosk> anyway, at this point i really want it well designed, so i urge anyone who's interested to read the document and make suggestions</p>
13:57 < orion> LiveFuseNet.</p>
13:58 <+polecat> What about making it so only a few people can /read/ a group? Not so much encrypting it, but preventing its existence from even being known.</p>
13:58 < dm> How about: Contnet? ContNet</p>
13:58 < dm> Content, Contnet... get it? eh???</p>
13:58 < susi23> jnymo: regarding postscript, I kindly asked frosk to supply us with pdf *blush*</p>
13:58 < frosk> polecat: that may be interesting, yeah. it's hard to fit into the current design, though</p>
13:58 < jrandom> i'm not sure, it sounds pretty doable</p>
13:59 <+polecat> I want HTML or plain text myself. -.- Don't like bitmap ps readers. -.-</p>
13:59 < jrandom> rather than offering a group for syndication, only trusted/known users can get the group</p>
13:59 < jrandom> (off trusted/known syndication nodes)</p>
13:59 < frosk> polecat: http://frosk.i2p/i2pcontent-3.pdf if you can handle pdf's :)</p>
13:59 < jrandom> kind of like usenet's "Distribution:" header</p>
13:59 < susi23> polecat: ps is not bitmap :P</p>
13:59 <+polecat> frosk: It's important though, if you want to have things like private mailboxes, or secret groups, or livejournal's ability to block text to all but certain friends. Also moderated forums will probably be important to have that.</p>
13:59 < frosk> hm, yeah</p>
14:00 < frosk> polecat: blocking to all but friends can be handled with encryption</p>
14:00 <+polecat> frosk: My PDF reader is this: $ pdf2ps file.pdf &gt; file.ps; gs file.ps</p>
14:00 < jrandom> polecat: you had a good suggestion for moderated forums the other day - an unmoderated submission queue, with moderators posting to the "real" group</p>
14:01 <+polecat> frosk: Encryption is good, and hopefully somewhat transparent. Otherwise users will have to type text in an xterm running gpg, copy it and paste it to the journal window. &gt;.&lt;</p>
14:01 <+polecat> jrandom: Yes, but ideally the submission queue should be invisible to all but the moderators.</p>
14:01 < frosk> polecat: oh, transparency is an important keyword in the whole thing :)</p>
14:01 < jrandom> polecat: you'd lose 99% of the target audience if you say "xterm"</p>
14:02 <+polecat> jrandom: Heathens! A grep on them!</p>
14:02 < ant> &lt;jnymo&gt; mmmmm.. what's usenet?</p>
14:02 < ant> &lt;jnymo&gt; I mean i've heard of it.. but</p>
14:02 < susi23> jnymo: news, nntp, google -&gt; groups</p>
14:02 < frosk> http://en.wikipedia.org/Usenet :)</p>
14:03 <+polecat> jnymo: newsgroups, eh?</p>
14:03 < dm> It's good for random porn downloads.</p>
14:03 < frosk> it's basically the world's oldest and most proven p2p net, as jrandom wrote today</p>
14:03 < ant> &lt;jnymo&gt; so you can post files up? or links to files?</p>
14:03 < jrandom> and its bloody resiliant</p>
14:03 < susi23> dm: its 'use'ful for random porn downloads :P</p>
14:03 <+polecat> dm: I suppose, if you can find the porn around all the spam.</p>
14:04 < frosk> it's first and foremost for discussion groups, but it's widely used for files too</p>
14:04 <+polecat> There's another issue actually. Spam and all..</p>
14:04 * dm used to run a 'porn downloader'. It worked well.</p>
14:04 < ant> &lt;jnymo&gt; so its like the forum format of irc?</p>
14:04 < frosk> i have thought about spam on i2pcontent, and i don't look forward to it ;)</p>
14:04 * susi23 points back to topic *blush*</p>
14:04 <+polecat> We can't have open forums, or at least we can't only have forums with 1 author, and forums without restriction. We need some kind of happy medium where multiple people can post, but not unauthorized people.</p>
14:04 <+dinoman> i have just 1 thing to ask would i have to run this ie is it going to be part of i2p?</p>
14:05 < frosk> polecat: i2pcontent has that (groups of users editing one blog)</p>
14:05 < dm> It's amazing usenet is so big considering how few people actually use it.</p>
14:05 < dm> Average Joe doesn't know what usenet is.</p>
14:05 < jrandom> dinoman: its an application, definitely not required</p>
14:06 <+dinoman> :)</p>
14:06 < ant> &lt;jnymo&gt; yea.. i'm average joe</p>
14:06 < frosk> but hopefully distributed with i2p ;)</p>
14:06 <+polecat> So pretty much you have a list of sha4 in meta.group.*, one list for approved syndicators/readers, one for writers, one for owners, etc...</p>
14:06 < jrandom> (but i can see no reason why not use it, as 1) installing it doesn't add *any* overhead to your machine 2) lots of good features :)</p>
14:07 < jrandom> frosk: definitely </p>
14:07 < dm> Google seems to be giving it some exposure. It should be presented as "the biggest message board in the world", and have a similar UI to the usual forums.</p>
14:07 <+polecat> jrandom: Why would you say *no* overhead? c.c</p>
14:07 <+polecat> Just because you have to select syndicates and blogs to read, before you will download them?</p>
14:07 < jrandom> jnymo: a usenet-like itnerface to the i2p mailing list: http://news.gmane.org/gmane.network.i2p</p>
14:08 < jrandom> polecat: no, 0 overhead if you don't use it</p>
14:08 < frosk> polecat: groups have one owner who can add users. as for "secret" message namespaces, i haven't thought about that till now :)</p>
14:08 < jrandom> (as in, just having it installed doesnt make your machine a public data store, etc)</p>
14:08 -!- ]Replica[ is now known as ]Replica|zZz[</p>
14:08 < jrandom> and there will probably be i2p announcements done over secure blogs in i2p, worth reading, etc</p>
14:08 <+polecat> frosk: No reason it can't have multiple owners, though only one could go in the sha for the name. :3 Just allow multiple people to modify the meta.* stuff for that group.</p>
14:09 < frosk> so in closing, if you're interested in helping out, read the document at frosk.i2p and let's talk :) anything else on i2pcontent?</p>
14:09 <+dinoman> oh so it is not freenet over i2p!</p>
14:09 < frosk> (i have quite a lag here right now)</p>
14:09 < jrandom> right dinoman, definitely not</p>
14:09 < susi23> data organized in "newsgroups" would be great...simply delete/unsubscribe i2p.childporn.* ...</p>
14:09 <+polecat> dinoman: En. Oh.</p>
14:10 < ant> &lt;jnymo&gt; jrandom: ah.. that's cool</p>
14:10 < jrandom> word frosk. this is definitely some cool shit, and people should throw tons of email at you, and read your blog :)</p>
14:10 < ant> &lt;jnymo&gt; useful ;)</p>
14:10 <+polecat> susi23: Right, and if nobody wants to syndicate it, then nobody has to help move it around.</p>
14:10 < frosk> polecat: yeah, though it adds a bit of complexity, and i'm a simplicity freak ;)</p>
14:10 < jrandom> jnymo: aye. but we can do some really cool shit beyond that, making things look like http://www.livejournal.com/ or blogger or whatever</p>
14:11 < jrandom> yeah, its best not to aim too high at the start (&lt;/lesson learned&gt;). go for the simplest thing that could possible work, with hooks for later improvement</p>
14:11 < frosk> the rendering is of course 100% up to the user client (web interface that looks like LJ? ok. slashdot-like? fine! etc :)</p>
14:12 <+polecat> frosk: I just think permissions should be generalized, and not "only one" for owner, "just a few" for writer, "everybody and their mother" for reader, unless the forum itself specifies those permissions. Otherwise you're hardcoding many types of authorization.</p>
14:12 < frosk> jrandom: yes, extensionability is king</p>
14:12 < frosk> which is why a sound design from the start is important</p>
14:13 <+dinoman> so let me see if i get this to me (end user) this is going to work like newsgroups.</p>
14:13 < frosk> polecat: agree</p>
14:13 <+polecat> dinoman: More like Livejournal, but yes.</p>
14:14 <+dinoman> well i could learn to like this idea!</p>
14:14 < frosk> technically it's like newsgroups (on speed), but on the surface it can be like livejournal</p>
14:14 <+polecat> frosk: Also not like LIvejournal, in that it's decentralized Usenet style. So the user has to pick syndicates, instead of the one syndicate LJ.</p>
14:15 < frosk> polecat: yes. the user software does the syndicate picking in most cases though, so most users won't have to know about many technicalities</p>
14:16 <+polecat> Hmm... perhaps. You'd have to have a way for the software to find the syndicates though. Aside from the user copying the hash from IRC into the i2pcontent add syndicate box.</p>
14:17 < jrandom> polecat: syndicate(s) used are included in the meta.* post</p>
14:17 < frosk> polecat: yes, i2pcontent comes with a few "seed syndicates", and the user asks them for more</p>
14:17 < ant> &lt;Asciiwhite&gt; frost, livejournal?, sounds brillient...</p>
14:17 <+polecat> jrandom: You need a syndicate to get a meta.* post. 8) frosk: yeah something like that, cool.</p>
14:17 < frosk> ah yes, frost people will love i2pcontent ;)</p>
14:18 < jrandom> heh true</p>
14:18 < frosk> jrandom: that wasn't my plan, but it sounds very smart, actually :)</p>
14:18 < frosk> the current syndicate database is a sore point in some ways</p>
14:18 < jrandom> i thought i saw it in one of your .ps files, perhaps it was just in a conversation though</p>
14:19 <+polecat> Make it a kademelia DHT! X3</p>
14:19 * jrandom groans</p>
14:19 < jrandom> but yeah, there are lots of optimizations on the syndicate database that can be done</p>
14:19 < frosk> perhaps you're just thinking smart thoughts and exchange what you read with that ;)</p>
14:19 < jrandom> lol</p>
14:19 < ant> &lt;jnymo&gt; so can you embed html?</p>
14:19 <+polecat> *chants* DHT DHT DHT USA US--</p>
14:19 < jrandom> jnym: any content</p>
14:20 <+polecat> jnymo: Either that or some sort of bbcode type thing.</p>
14:20 < jrandom> yeah, rendering would be safest with a bbcode-like syntax</p>
14:20 < dm> frosk: would you like a dedicated section on cervantes' forum?</p>
14:20 < frosk> blogs and forums will expect text with some markup like bbcode</p>
14:20 < frosk> dm: i think it's kind of early yet :)</p>
14:21 < dm> frosk: consider it done!</p>
14:21 < cervantes> dm: would you like a private sound proof section on my forum?</p>
14:21 < dm> cervantes: make it so.</p>
14:21 < frosk> while i'm still on, please not that "i2pcontent" is just a dummy name since i didn't want to insult jrandom by calling it MyI2P ;) we need a more catchy name</p>
14:21 < dm> how about... contnet?</p>
14:22 < jrandom> frusejournalrent</p>
14:22 < frosk> i like!</p>
14:22 * dm rubs his hands in excitement</p>
14:22 < jrandom> &lt;/fark&gt;</p>
14:22 < dm> &lt;/stupid jrandom tag&gt;</p>
14:22 <+polecat> usejournalforrent?</p>
14:22 < ant> &lt;jnymo&gt; fusenet sounded pretty cool</p>
14:22 <+protokol> eepnet</p>
14:22 <+postman> uupnet :)</p>
14:22 < lurk> froops</p>
14:23 <+postman> LOL</p>
14:23 < dm> nnnnnnnnnnnntp</p>
14:23 <+postman> silly persons</p>
14:23 <+polecat> "frosk's catchy name for a content distribution syndicate network." We could say "Fcnfacdsn was inspired by Usenet..."</p>
14:23 < ant> &lt;Asciiwhite&gt; yeah i thought frusenet was good.</p>
14:23 < frosk> :D</p>
14:23 < jrandom> ok, please direct all silly names to frosk@mail.i2p :)</p>
14:23 <+polecat> frootloops!</p>
14:23 < frosk> i tried frusenet on a friend, he said "... or not."</p>
14:23 < jrandom> (along with any comments/concerns/etc)</p>
14:24 < frosk> although fusenet has a cool ring to it :)</p>
14:24 < dm> How about just 'Content' ?</p>
14:24 <+polecat> I like fusenet, it sounds... volatile.</p>
14:24 <+polecat> So yes. Quieting down now.</p>
14:24 < Pseudonym> nn2p</p>
14:24 < dm> Nice and dinstinguished</p>
14:24 < jrandom> ooOOo</p>
14:24 < frosk> anyway, i'm not last on the agenda, we might want to move on ;)</p>
14:24 <+postman> NN2P is COOL</p>
14:24 < ant> &lt;jnymo&gt; if you had html.. you could have what looks like the net... inside froozlednet</p>
14:24 < jrandom> ok, moving on to 5) i2p-bt</p>
14:24 < jrandom> duck: you 'round?</p>
14:24 <@duck> meep</p>
14:24 < frosk> dm: "Content" is probably trademarked by Apple or whatever ;)</p>
14:25 < ant> &lt;Asciiwhite&gt; owww, is this a minutes ?</p>
14:25 <@duck> i2p-bt events this week:</p>
14:25 < dm> speeddating!@</p>
14:26 <@duck> - rss available on the trackers</p>
14:26 <@duck> - silly attempts to make a metatracker in #eeprnova</p>
14:26 < ant> &lt;jnymo&gt; noice</p>
14:26 < ant> &lt;Asciiwhite&gt; yeah, great idea.</p>
14:26 <+polecat> I still wish we could find a better codebase than that blasted bittorrent python source...</p>
14:26 < ant> &lt;Asciiwhite&gt; What about support for say samplers(i.e video/pics)</p>
14:26 <@duck> - some detailed code review leading to not finding bugs</p>
14:26 <@duck> most of the scary looking errors are pretty harmless</p>
14:27 <@duck> - I forgot</p>
14:27 <@duck> .</p>
14:27 < jrandom> word</p>
14:27 < jrandom> i've been watching the streaming lib activity while swarming, and there have been some improvements in cvs</p>
14:28 <+polecat> A metatracker lets you find trackers for files...?</p>
14:28 < ant> &lt;Asciiwhite&gt; so people can upload a small sample of video quality, or a thumbnail etc.</p>
14:28 < jrandom> (to keep up with the bt setup)</p>
14:28 <+polecat> jrandom: Improvements as of what date, this morning? :3</p>
14:28 <@duck> polecat: yeah, well this one just announces new files into a channel; but it could be enhanced</p>
14:28 < jrandom> a day or two ago</p>
14:29 <+polecat> Just checking, because last time I got CVS Head, you updated to 0.4.3 a few hours later.</p>
14:29 < ant> &lt;jnymo&gt; yea.. is there some idea for i2ptorrent search some where down the eschelons?</p>
14:29 < jrandom> one of the neat things though is that i believe the main remaining i2p-bt bumps we're seeing are actually just i2p/streaming lib/sam problems</p>
14:30 <+polecat> Someone'd have to write a searching server, maybe by keyword and such.</p>
14:30 <@duck> or an irc bot</p>
14:30 < jrandom> jnymo: http://brittneyworld.i2p/bittorrent/</p>
14:30 < jrandom> polecat: files.i2p/</p>
14:30 < ant> &lt;jnymo&gt; hmm</p>
14:30 < ant> &lt;jnymo&gt; mmhmm.. yea. mk</p>
14:30 <+polecat> duck: Well a server to search, whether a bot or a eepsite like files.i2p...</p>
14:31 <@duck> if someone needs rss etc enhancements on the tracker for their bots etc, let me know</p>
14:31 < ant> &lt;jnymo&gt; hmm.. seems brittanyworld.i2p is down at the moment</p>
14:32 < jrandom> since it seems the remaining problems are i2p related, not i2p-bt related, we've marked the swarming file transfer bounty as completed</p>
14:32 < jrandom> (yay!)</p>
14:32 < ant> &lt;jnymo&gt; anyhoo</p>
14:32 < ant> * jnymo tips his hat</p>
14:32 < frosk> congrats to all involved, you rock</p>
14:33 < jrandom> aye, thanks to all the hard work of duck, ragnarok, dinoman, connelly, and drwoo</p>
14:33 <+polecat> ragnaroks! dinoman's da man! Um...</p>
14:33 < ant> &lt;Asciiwhite&gt; nice work duck.</p>
14:33 <+polecat> I still want to get ctorrent ported to i2p. It's a wicked efficient bittorrent thingy, if a little flaky on the UI.</p>
14:34 < dm> good work</p>
14:35 <+polecat> Anyone know where the info about SAM proxies is?</p>
14:36 < jrandom> about half of our general fund went towards that bounty, so our current balance is around $400USD [after some new donations today [yay!]]</p>
14:36 < jrandom> polecat: http://www.i2p.net/sam</p>
14:37 <+polecat> jrandom: Doing a swarming file transfer cost like, money? o.O</p>
14:37 <+polecat> Ohh right the reward.</p>
14:37 < Pseudonym> it'd be kinda cool to have the general fund balance on the website</p>
14:37 < jrandom> right polecat :)</p>
14:37 < jrandom> thats a good idea Pseudonym </p>
14:38 < Pseudonym> doesn't have to be updated daily, just occasionally</p>
14:38 < jrandom> i'll add it on to /bounties (sound good?)</p>
14:38 < Pseudonym> sure</p>
14:38 <+protokol> dont tell me they are keeping the hello chat room</p>
14:38 < cervantes> if he did that we'd all see how much it goes down whenever jrandom goes out for a pie and a pint lunch </p>
14:39 < jrandom> heh cervantes </p>
14:39 < Pseudonym> didn't somebody donate money for jrandom's beer?</p>
14:40 < cervantes> enough for half a pint at todays rates :)</p>
14:40 < jrandom> yeah we've had a few beer donations :)</p>
14:40 < jrandom> (list of donations up @ http://www.i2p.net/halloffame )</p>
14:40 < Pseudonym> are you spending them?</p>
14:41 < cervantes> nice...someone has money to burn I see ;-)</p>
14:41 < ant> &lt;Asciiwhite&gt; anonymous</p>
14:41 < ant> &lt;Asciiwhite&gt; $5.00 USD</p>
14:41 < ant> &lt;Asciiwhite&gt; buy jrandom a beer fund</p>
14:41 < ant> &lt;Asciiwhite&gt; lol</p>
14:42 < jrandom> it would be nice if we can grow the bounties on the CDN, as thats a truckload of work</p>
14:42 < jrandom> but we'll see how it goes over time</p>
14:42 < jrandom> ok, i think we're pretty off track for 5) i2p-bt</p>
14:42 < jrandom> so i suppose we should move to 6) ???</p>
14:42 <@duck> nothing to add here.</p>
14:43 < jrandom> is there anything else people would like to bring up?</p>
14:43 <@duck> - why do so many ppl have problems when they specify a hostname?</p>
14:43 < jrandom> not sure</p>
14:43 < jrandom> both of my routers use an explicit hostname</p>
14:43 <@duck> mine too, np</p>
14:44 <@duck> maybe the warning text should be more negative</p>
14:44 < jdot_> do we have a way to change keys on hostnames in hosts.txt?</p>
14:44 < jrandom> sounds good duck </p>
14:44 <+polecat> Regarding addressbook...</p>
14:44 < jrandom> jdot_: no, not really, especially in light of the addressbook</p>
14:44 < jdot_> like, if I lost my previous eepsite key. :(</p>
14:44 < mule2> same here - but i have problems :)</p>
14:44 <+polecat> Addressbook is going to be fused with i2pcontent, right?</p>
14:45 < mule2> but don't think these result from the hostname</p>
14:45 < Pseudonym> do we have a working addressbook?</p>
14:45 <+polecat> You subscribe to an addressbook just like you subscribe to a blog... except it overwrites userhosts.txt and such.</p>
14:45 < jrandom> polecat: distributing addressbooks through i2pcontent makes sense, yeah</p>
14:45 < jrandom> Pseudonym: http://ragnarok.i2p/</p>
14:45 <+polecat> Pseudonym: http://polecat.i2p/addressbook.pl.zip</p>
14:45 < jrandom> and http://pole...er, what he said</p>
14:45 < Pseudonym> thanks</p>
14:46 < jrandom> i think there's also another one at http://orion.i2p too</p>
14:46 < frosk> polecat: "overwrite" sounds dramatic. it "merges" ;)</p>
14:47 <+polecat> Yeah... I saw orion's too.</p>
14:47 < jdot_> dang</p>
14:47 < jrandom> jdot_: so it looks like you're outa luck :/</p>
14:47 < jrandom> ok, anyone else have anything for the meeting?</p>
14:48 < dm> merry xmas</p>
14:48 <+polecat> jdot: Thankfully when we've got fusenet working, you can update your i2p key with that eventually.</p>
14:49 < ant> &lt;Asciiwhite&gt; dm, 15th of december here :)</p>
14:49 < jrandom> and a happy Chanukah</p>
14:49 <+polecat> Christ was born in September, what's everyone all celebrating about?</p>
14:49 <+polecat> I'll stick with Yule thanks muchly.</p>
14:49 < jrandom> ok if thats it...</p>
14:49 * jrandom winds up</p>
14:50 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:08 < jrandom> 0) hi
13:08 < jrandom> 1) Net status
13:08 < jrandom> 2) mail.i2p
13:08 < jrandom> 3) roadmap
13:08 <+polecat> It's almost as if the nodes are using the time they got 5 min ago, and setting it to the current time instead of the real time.
13:09 < jrandom> 4) i2pcontent
13:09 < jrandom> 5) i2p-bt
13:09 < jrandom> 6) ???
13:09 < jrandom> 0) hi
13:09 < jrandom> weekly status notes posted a few minutes back to http://dev.i2p.net/pipermail/i2p/2004-December/000522.html
13:09 * Pseudonym waves
13:10 < cervantes> thanks for waiting.... just got back from work ;-)
13:10 < jrandom> polecat: it isnt exactly 5m (but we can discuss further after the meeting or in it)
13:10 * polecat nod
13:10 < jrandom> w3rd, well, i'll give you a moment to jump into the status notes then :)
13:11 < jrandom> in the meantime, 1) Net status
13:11 * postman waves
13:11 < jrandom> the other day, as mentioned on the list, it was pretty turbulent on irc
13:12 < jrandom> we've made some adjustments though and the bugfixes have gone pretty well
13:12 * dm waves
13:12 < jrandom> in addition to the time sync issue mentioned in the mail, there's also a "leases expiring" problem that some have been reporting
13:13 < Pseudonym> are they related?
13:13 <+protokol> (for months)
13:13 < Pseudonym> (the issues, not the people)
13:13 < jrandom> thats due in part to a variety of issues, some of which may be addressed by the patches in CVS, some of which may be time sync related, but most of which are due to issues we're working on for the 0.5 release
13:14 < jrandom> the essence of the problem is that the peer is sometimes unable to build tunnels for the client, which means it won't ask the client for a new lease
13:14 < jrandom> the solution is to make sure we can build new tunnels that meet the client's needs
13:15 < Pseudonym> and if we can't?
13:15 < jrandom> if we can't, the leases will stay expired until we can
13:16 < Pseudonym> so, how is that different?
13:16 < jrandom> it isn't :)
13:16 < jrandom> we need to be able to build tunnels, period.
13:16 < jrandom> to assure that we can, we must both improve our profiling (see: cvs fixes for a long standing profiling bug) and improve our pooling strategy (see: 0.5)
13:17 < jrandom> the only legitimate cause for not being able to build tunnels is if the entire net is completely saturated
13:17 <+polecat> or you're cut off from it
13:17 < jrandom> right
13:17 < bla> jrandom: Can this be because the net has grown to ~110 peers?
13:18 < dm> or its cut off from you
13:18 < jrandom> nah, we've seen this before too bla
13:18 < Pseudonym> are the "cvs fixes for a long standing profiling bug" in 0.4.2.3 or just CVS?
13:18 < jrandom> though in a way, i suppose it is, since we now have a lot more peers that we have no profiling data on
13:18 < jrandom> Pseudonym: CVS
13:19 <+polecat> By profiling you mean ranking peers according to how helpful they are?
13:19 < jrandom> yeah
13:19 * Pseudonym wants 0.4.2.4 ;-)
13:19 <+polecat> Phew.
13:19 <+polecat> Thought it was some weird kinda function tracing like gprof or something.
13:20 * orion wants 2.0 :)
13:20 < jrandom> hehe naw, the profiling bug was in part due to some stupid code that was ignoring daily stats
13:20 * jrandom too
13:20 * polecat wants the larval form of a large dog.
13:20 < jrandom> ok, well, thats about all i've got to bring up for 1) net status - anyone else have anything to add?
13:21 < jrandom> if not, moving on to 2) mail.i2p
13:21 < jrandom> postman: you've got the floor
13:22 <+postman> ok
13:22 <+postman> sorry
13:22 <+postman> :)
13:23 <+postman> there's a description for a complete handling of virtual maildomains on www.postman.i2p/user/virtual
13:23 <+postman> there's a description for a complete handling of virtual maildomains on www.postman.i2p/user/virtual.html
13:23 <+postman> (too much red wine)
13:23 < dm> this is a very unprofessional presentation!
13:23 <+postman> it tries to explain a system how to handle maildomains other than @mail.i2p addresses
13:23 < frosk> :D
13:24 * orion smacks dm in the head with the chalkboard eraser.
13:24 < frosk> does that i can have frosk@frosk.i2p?
13:24 <+postman> frosk: indeed
13:24 < jrandom> v.cool
13:24 <+polecat> The question is, why? :3
13:24 <+postman> it's quite complex, still i ask for comments and ideas for this one
13:24 < cervantes> s/eraser/
13:24 < frosk> froody cool
13:25 <+postman> it might not be a needed feature for a few ppl but the future is bright and shiny
13:25 < jrandom> there are lots of reasons why - e.g. giving each user @ forum.i2p a mail address, etc
13:25 < susi23> its a central system bound to postman.i2p
13:25 <+polecat> Yes, that much seems clear.
13:25 < susi23> if that machine fails, we're all upset :)
13:25 <+polecat> jrandom: But if it all has to go through mail.i2p in the first place...
13:25 * postman is VERY aware of this problem
13:26 <+postman> :/
13:26 < jrandom> polecat: perhaps, but perhaps not
13:26 <+polecat> susi23: exactly!
13:26 <+postman> the recent implementation is indeed quite single point of failure
13:26 <+postman> but this applys to the internet bridge as well
13:27 < jrandom> oh, the second gateway isn't in place yet?
13:27 <+polecat> One solution is to put multiple destinations in the client SMTP/POP3 tunnels, and have all these destinations relay only with each other.
13:27 <+postman> jrandom: no baffled has not setup yet
13:27 < jrandom> ah ok
13:27 <+postman> polecat: and on WHAT pop3 server should YOUR mailbox reside
13:27 < orion> shiny is good, but how tould that virtual address relate to an internet address? I like the fact that orion@mail.i2p and orion@i2pmail.org are both usable.
13:27 < orion> s/usable/identical/
13:28 <+postman> polecat: who wants to transfer 100MBs of mailbox data every day in 1 year for all 10000 users?
13:28 <+postman> orion: they will be usable
13:28 <+polecat> instead of going mail.i2p -> polecat.i2p -> frosk@baffled.i2p, it could go to either of the 3, and from there straight to baffled.
13:29 <+postman> i ask all ppl interested to contribute some ideas
13:29 <+postman> still the virtual domains is a feature that appears useful and can be implemented regardless of the state of the network
13:29 <+polecat> So if mail.i2p ever dies, the other two will have their server tunnels available as alternatives into the mail relay system.
13:30 <+postman> polecat: still there is the question of your mailbox
13:30 <+postman> polecat: your mailbox data must be moved as well and kept synchronized between ALL possible location
13:30 <+polecat> Ugh... yeah that's true...
13:30 <+postman> polecat: just consider this for 1000 users in the future
13:30 < susi23> everybody could set up a destination on their nodes where mails are delivered to... now we have to problem to connect destinations to mail addresses
13:30 <+postman> it's not THAT easy
13:30 <+polecat> Oh! But this would work though...
13:30 <+postman> indeed
13:31 <+postman> otoh the problem of relaying from and to the internet is still there
13:31 < dm> jrandom: you're enjoying this, aren't you?
13:31 <+polecat> Yes! A user chooses which server to have their POP3 mailbox on, and that is the server they choose as destination for the POP3 tunnel.
13:31 <+postman> polecat: what if THIS server fails?
13:32 <+polecat> So mail.i2p and polecat.i2p never even have to see baffled's POP3 mailbox, since all of baffled's POP3 users download straight from baffled.
13:32 <+postman> a real redundant system will require a mailbox sync
13:32 < susi23> yeah, but with such a system everybody could deliver mails within i2p, even if postman.i2p would not be there
13:32 <+polecat> postman: Then they have to change servers. -.-
13:32 < dm> Students having an intelligent conversation between each other. A professor's dream :)
13:32 <+postman> well, the meeting is hardly the place to DISCUSS all those things
13:33 <+postman> i am just here to trigger the discussion
13:33 <+postman> read the document first please and AFTER THAT i am ready to hear your comments
13:33 <+postman> 2.
13:33 <+polecat> Alright, so mail.i2p is in the works, and attempting to become less centralized and single point failurey.
13:33 <+postman> we officially crossed the 100 users with 110 registered accounts
13:33 <+postman> just FYI
13:33 < jrandom> w00t
13:34 <+postman> thats all for today :)
13:34 <+postman> thanks
13:34 * dm applauds
13:34 < jrandom> kickass, thanks postman. it all looks promising
13:34 <+postman> :)
13:35 < mule2> i'd like to bring up a topic on mail, but after the meeting
13:35 < jrandom> perhaps some mail-decentralization discussions could go on over the list or on the forum? but for now what you've got set up more than meets our needs
13:35 <+postman> there's even a channel for it
13:35 <+postman> :)
13:35 < jrandom> heh good point
13:35 < frosk> which one?
13:36 < jrandom> #mail.i2p
13:36 <+postman> frosk: #mail.i2p
13:36 <+polecat> Oh, one quick note I just surprised myself by getting a little perl caching SMTP server going, so emacs doesn't hang waiting for postman's SMTP server to respond over i2p.
13:36 < frosk> ok
13:36 <+polecat> I might post some code later, if it works like, really well.
13:36 < jrandom> oh, kickass polecat
13:36 < cervantes> postman: you're welcome to have a dedicated section on the forum
13:37 <+postman> cervantes: ohh thanks
13:37 * postman feels honoured :)
13:37 < dm> You deserve it
13:38 * postman hands the mike back to hr
13:38 * postman hands the mike back to jr
13:38 <+postman> damn
13:38 <+postman> :)
13:38 < jrandom> ok, if there's nothing else on 2) mail.i2p, lets jump on over to 3) roadmap
13:38 <+polecat> vroom vroom!
13:38 < jrandom> the old roadmap was looking a little... out of date
13:39 < jrandom> the new one reflects the current view of things
13:39 < jrandom> hopefully the schedule listed has enough padding, though if more people jump on board perhaps we can beat those estimates :)
13:40 < jrandom> once we've hit 0.6, we'll be able to scale to large numbers of nodes, as we wont have the thread-imposed ceiling
13:41 < frosk> what do you think is a realistic node limit for < 0.6?
13:41 < jrandom> prior to 0.6 though, we'll probably need to stay under 200 active nodes, though we can probably stop being so lazy and actively kill some connections
13:41 < jrandom> with some care, i think we'll be able to get up to 3-500
13:42 < mule2> so no slashdotting please
13:42 < jrandom> we'd have connection churn at that point, but our low-cost tcp transport shouldn't hurt too much
13:42 < Pseudonym> the roadmap for 0.6 doesn't mention that. just udp and content dist
13:42 < Pseudonym> or is it the udp that fixes it?
13:42 * orion votes for no slashdotting ever
13:43 < jrandom> Pseudonym: udp fixes it (http://www.i2p.net/todo#transport )
13:43 < cervantes> postman: http://forum.i2p/viewforum.php?f=22
13:44 < Pseudonym> orion: I disagree. to get real anonymity we're going to need LOTS of nodes eventually
13:44 < Pseudonym> at some point we have to tell people about it
13:44 < jrandom> agreed. when we need 'em, we'll definitely want to do all sorts of PR
13:44 < jrandom> the geek crowd will likely be a large part of the userbase
13:44 < Pseudonym> when do we announce to the geek community? not as a finished product but as a beta for tire-kicking
13:44 < Frooze> Ask JRandom
13:45 <+polecat> I think we should be very careful about making this network too popular.
13:45 < jrandom> Pseudonym: when we've done the best tire kicking we can without them
13:45 <+polecat> Because one of these days someone is going to use it to do something horrible and illegal.
13:45 <+polecat> And if we can be tracked down at that point, we will be persecuted right along with the criminal.
13:46 < jrandom> basically, once the network works great consistently and we're not able to do tihngs to b0rk it up, /then/ we'll need to get more users to help break/test it
13:47 < mule2> you have to kick me off before :9
13:47 < Pseudonym> just don't fall into the same trend as Toad with freenet
13:47 <+polecat> Because we gave them the freedom to post the source code for Windows XPQXR, and Halo 7, so we'd better as all heck have good anonymity protection.
13:47 < orion> speaking of b0rking... was that time-skew bug ever identified?
13:47 < jrandom> Pseudonym: i believe our roadmap is realistic
13:48 < jrandom> polecat: agreed, people shouldn't use i2p for things that are 'dangerous' yet
13:48 < jrandom> orion: no
13:48 < Pseudonym> jr: I'm not complaining about the roadmap. but it doesn't address announcements
13:48 < jrandom> true
13:49 < dm> well, with 2 years of development/testing under its belt, it should be one of the most polished offerings of this type when it launches :)
13:49 < Pseudonym> perhaps add slashdotting to 0.6? :-)
13:49 <+polecat> jrandom: More importantly, people who would use i2p for things that dangerous would do us a lot of good if they didn't know about i2p just yet.
13:49 < jrandom> i was thinking about that the other day. perhaps some announcements for other activities (e.g. I2PContent) would make sense, to draw more people in to work on them
13:49 < dm> as opposed the usual level of maturity when things go big
13:50 < ant> <jnymo> i think jrandom should write the slashdot article.. he's best at describing i2p, i think
13:50 * Pseudonym agrees
13:51 < dm> I'm sure something will go on there before jrandom is comfortable to do it himself ;)
13:51 < Pseudonym> I'm just trying to nudge him a bit
13:51 < jrandom> heh
13:51 < jrandom> well, with 0.6 we'll want to attract a larger user base in any case
13:51 < Pseudonym> I figure if I can't code, I can at least pester the people who can
13:51 * jrandom flings mud
13:52 <+polecat> dm: I'm sure the Second Coming will pass before jrandom is comfortable enough to /. i2p ;3
13:52 * Pseudonym ducks. quack
13:52 < jrandom> ok, in any case, anyone have anything else to discuss wrt the roadmap?
13:52 < jrandom> or shall we move on to 4) I2PContent ?
13:53 -!- Irssi: #i2p: Total of 36 nicks [1 ops, 0 halfops, 3 voices, 32 normal]
13:53 < jrandom> frosk: ping
13:53 * frosk grabs the wireless mic
13:54 < cervantes> *zzzzzZzzzzttt*
13:54 * orion plugs in his RF jammer. ;)
13:54 <+polecat> I have been trying to get ahold of frosk, without luck as such yet. Frankly I think I might never see em on IRC, and eir email is a sightless void.
13:54 < frosk> well, jrandom put this "distributed content infrastructure" on the new roadmap for 0.6, and after hearing some thoughts about it here, it sounded really interesting, and i figure i should do whatever my skills allow to beat the schedule ;)
13:54 * dm looks at polecat
13:54 <+polecat> *shakes head* Just no luck whatsoever. No where to be FOUND. Maybe frosk is invisible!
13:55 < frosk> "i2pcontent" is so far a document at frosk.i2p
13:55 < Pseudonym> how is I2PContent different from i2p-bt?
13:55 * polecat is on 4.4 atm.
13:55 < frosk> it merges the ideas i've heard with my own, and it has gone through some revisions with helpful comments and suggestsions from jrandom and others, and i think it's starting to look very cool :)
13:55 < ant> * jnymo tries to find a postscript viewer to see these ideas.. :/
13:56 < dm> what is it, I can't get to frosk.i2p. Executive summary?
13:56 <+polecat> Pseudonym: i2p-bt only applies to 1 file at a time, and is a swarming download.
13:56 < frosk> Pseudonym: i2pcontent is a lot like Usenet
13:56 < frosk> it merges concepts from usenet and freenet. i shall refrain from calling it "frusenet".
13:56 < jrandom> lol
13:56 <+polecat> Did you get my suggestion on i2pcontent?
13:56 < jrandom> frusenet has a ring to it...
13:56 < frosk> i2pcontent lets you post messages to your blog or to public forums, and publish your address book for others to import
13:56 * dm did not refrain from calling it frazaa
13:56 <+polecat> It merges usenet, freenet and livejournal. So.... Fusejournal?
13:56 < jrandom> rofl
13:57 < frosk> hm, yeah, LJ too ;)
13:57 <+polecat> Lj is the closest parallel I've found.
13:57 <+polecat> But here's one thing I didn't read in your i2pcontent document.
13:57 < frosk> anyway, at this point i really want it well designed, so i urge anyone who's interested to read the document and make suggestions
13:57 < orion> LiveFuseNet.
13:58 <+polecat> What about making it so only a few people can /read/ a group? Not so much encrypting it, but preventing its existence from even being known.
13:58 < dm> How about: Contnet? ContNet
13:58 < dm> Content, Contnet... get it? eh???
13:58 < susi23> jnymo: regarding postscript, I kindly asked frosk to supply us with pdf *blush*
13:58 < frosk> polecat: that may be interesting, yeah. it's hard to fit into the current design, though
13:58 < jrandom> i'm not sure, it sounds pretty doable
13:59 <+polecat> I want HTML or plain text myself. -.- Don't like bitmap ps readers. -.-
13:59 < jrandom> rather than offering a group for syndication, only trusted/known users can get the group
13:59 < jrandom> (off trusted/known syndication nodes)
13:59 < frosk> polecat: http://frosk.i2p/i2pcontent-3.pdf if you can handle pdf's :)
13:59 < jrandom> kind of like usenet's "Distribution:" header
13:59 < susi23> polecat: ps is not bitmap :P
13:59 <+polecat> frosk: It's important though, if you want to have things like private mailboxes, or secret groups, or livejournal's ability to block text to all but certain friends. Also moderated forums will probably be important to have that.
13:59 < frosk> hm, yeah
14:00 < frosk> polecat: blocking to all but friends can be handled with encryption
14:00 <+polecat> frosk: My PDF reader is this: $ pdf2ps file.pdf > file.ps; gs file.ps
14:00 < jrandom> polecat: you had a good suggestion for moderated forums the other day - an unmoderated submission queue, with moderators posting to the "real" group
14:01 <+polecat> frosk: Encryption is good, and hopefully somewhat transparent. Otherwise users will have to type text in an xterm running gpg, copy it and paste it to the journal window. >.<
14:01 <+polecat> jrandom: Yes, but ideally the submission queue should be invisible to all but the moderators.
14:01 < frosk> polecat: oh, transparency is an important keyword in the whole thing :)
14:01 < jrandom> polecat: you'd lose 99% of the target audience if you say "xterm"
14:02 <+polecat> jrandom: Heathens! A grep on them!
14:02 < ant> <jnymo> mmmmm.. what's usenet?
14:02 < ant> <jnymo> I mean i've heard of it.. but
14:02 < susi23> jnymo: news, nntp, google -> groups
14:02 < frosk> http://en.wikipedia.org/Usenet :)
14:03 <+polecat> jnymo: newsgroups, eh?
14:03 < dm> It's good for random porn downloads.
14:03 < frosk> it's basically the world's oldest and most proven p2p net, as jrandom wrote today
14:03 < ant> <jnymo> so you can post files up? or links to files?
14:03 < jrandom> and its bloody resiliant
14:03 < susi23> dm: its 'use'ful for random porn downloads :P
14:03 <+polecat> dm: I suppose, if you can find the porn around all the spam.
14:04 < frosk> it's first and foremost for discussion groups, but it's widely used for files too
14:04 <+polecat> There's another issue actually. Spam and all..
14:04 * dm used to run a 'porn downloader'. It worked well.
14:04 < ant> <jnymo> so its like the forum format of irc?
14:04 < frosk> i have thought about spam on i2pcontent, and i don't look forward to it ;)
14:04 * susi23 points back to topic *blush*
14:04 <+polecat> We can't have open forums, or at least we can't only have forums with 1 author, and forums without restriction. We need some kind of happy medium where multiple people can post, but not unauthorized people.
14:04 <+dinoman> i have just 1 thing to ask would i have to run this ie is it going to be part of i2p?
14:05 < frosk> polecat: i2pcontent has that (groups of users editing one blog)
14:05 < dm> It's amazing usenet is so big considering how few people actually use it.
14:05 < dm> Average Joe doesn't know what usenet is.
14:05 < jrandom> dinoman: its an application, definitely not required
14:06 <+dinoman> :)
14:06 < ant> <jnymo> yea.. i'm average joe
14:06 < frosk> but hopefully distributed with i2p ;)
14:06 <+polecat> So pretty much you have a list of sha4 in meta.group.*, one list for approved syndicators/readers, one for writers, one for owners, etc...
14:06 < jrandom> (but i can see no reason why not use it, as 1) installing it doesn't add *any* overhead to your machine 2) lots of good features :)
14:07 < jrandom> frosk: definitely
14:07 < dm> Google seems to be giving it some exposure. It should be presented as "the biggest message board in the world", and have a similar UI to the usual forums.
14:07 <+polecat> jrandom: Why would you say *no* overhead? c.c
14:07 <+polecat> Just because you have to select syndicates and blogs to read, before you will download them?
14:07 < jrandom> jnymo: a usenet-like itnerface to the i2p mailing list: http://news.gmane.org/gmane.network.i2p
14:08 < jrandom> polecat: no, 0 overhead if you don't use it
14:08 < frosk> polecat: groups have one owner who can add users. as for "secret" message namespaces, i haven't thought about that till now :)
14:08 < jrandom> (as in, just having it installed doesnt make your machine a public data store, etc)
14:08 -!- ]Replica[ is now known as ]Replica|zZz[
14:08 < jrandom> and there will probably be i2p announcements done over secure blogs in i2p, worth reading, etc
14:08 <+polecat> frosk: No reason it can't have multiple owners, though only one could go in the sha for the name. :3 Just allow multiple people to modify the meta.* stuff for that group.
14:09 < frosk> so in closing, if you're interested in helping out, read the document at frosk.i2p and let's talk :) anything else on i2pcontent?
14:09 <+dinoman> oh so it is not freenet over i2p!
14:09 < frosk> (i have quite a lag here right now)
14:09 < jrandom> right dinoman, definitely not
14:09 < susi23> data organized in "newsgroups" would be great...simply delete/unsubscribe i2p.childporn.* ...
14:09 <+polecat> dinoman: En. Oh.
14:10 < ant> <jnymo> jrandom: ah.. that's cool
14:10 < jrandom> word frosk. this is definitely some cool shit, and people should throw tons of email at you, and read your blog :)
14:10 < ant> <jnymo> useful ;)
14:10 <+polecat> susi23: Right, and if nobody wants to syndicate it, then nobody has to help move it around.
14:10 < frosk> polecat: yeah, though it adds a bit of complexity, and i'm a simplicity freak ;)
14:10 < jrandom> jnymo: aye. but we can do some really cool shit beyond that, making things look like http://www.livejournal.com/ or blogger or whatever
14:11 < jrandom> yeah, its best not to aim too high at the start (</lesson learned>). go for the simplest thing that could possible work, with hooks for later improvement
14:11 < frosk> the rendering is of course 100% up to the user client (web interface that looks like LJ? ok. slashdot-like? fine! etc :)
14:12 <+polecat> frosk: I just think permissions should be generalized, and not "only one" for owner, "just a few" for writer, "everybody and their mother" for reader, unless the forum itself specifies those permissions. Otherwise you're hardcoding many types of authorization.
14:12 < frosk> jrandom: yes, extensionability is king
14:12 < frosk> which is why a sound design from the start is important
14:13 <+dinoman> so let me see if i get this to me (end user) this is going to work like newsgroups.
14:13 < frosk> polecat: agree
14:13 <+polecat> dinoman: More like Livejournal, but yes.
14:14 <+dinoman> well i could learn to like this idea!
14:14 < frosk> technically it's like newsgroups (on speed), but on the surface it can be like livejournal
14:14 <+polecat> frosk: Also not like LIvejournal, in that it's decentralized Usenet style. So the user has to pick syndicates, instead of the one syndicate LJ.
14:15 < frosk> polecat: yes. the user software does the syndicate picking in most cases though, so most users won't have to know about many technicalities
14:16 <+polecat> Hmm... perhaps. You'd have to have a way for the software to find the syndicates though. Aside from the user copying the hash from IRC into the i2pcontent add syndicate box.
14:17 < jrandom> polecat: syndicate(s) used are included in the meta.* post
14:17 < frosk> polecat: yes, i2pcontent comes with a few "seed syndicates", and the user asks them for more
14:17 < ant> <Asciiwhite> frost, livejournal?, sounds brillient...
14:17 <+polecat> jrandom: You need a syndicate to get a meta.* post. 8) frosk: yeah something like that, cool.
14:17 < frosk> ah yes, frost people will love i2pcontent ;)
14:18 < jrandom> heh true
14:18 < frosk> jrandom: that wasn't my plan, but it sounds very smart, actually :)
14:18 < frosk> the current syndicate database is a sore point in some ways
14:18 < jrandom> i thought i saw it in one of your .ps files, perhaps it was just in a conversation though
14:19 <+polecat> Make it a kademelia DHT! X3
14:19 * jrandom groans
14:19 < jrandom> but yeah, there are lots of optimizations on the syndicate database that can be done
14:19 < frosk> perhaps you're just thinking smart thoughts and exchange what you read with that ;)
14:19 < jrandom> lol
14:19 < ant> <jnymo> so can you embed html?
14:19 <+polecat> *chants* DHT DHT DHT USA US--
14:19 < jrandom> jnym: any content
14:20 <+polecat> jnymo: Either that or some sort of bbcode type thing.
14:20 < jrandom> yeah, rendering would be safest with a bbcode-like syntax
14:20 < dm> frosk: would you like a dedicated section on cervantes' forum?
14:20 < frosk> blogs and forums will expect text with some markup like bbcode
14:20 < frosk> dm: i think it's kind of early yet :)
14:21 < dm> frosk: consider it done!
14:21 < cervantes> dm: would you like a private sound proof section on my forum?
14:21 < dm> cervantes: make it so.
14:21 < frosk> while i'm still on, please not that "i2pcontent" is just a dummy name since i didn't want to insult jrandom by calling it MyI2P ;) we need a more catchy name
14:21 < dm> how about... contnet?
14:22 < jrandom> frusejournalrent
14:22 < frosk> i like!
14:22 * dm rubs his hands in excitement
14:22 < jrandom> </fark>
14:22 < dm> </stupid jrandom tag>
14:22 <+polecat> usejournalforrent?
14:22 < ant> <jnymo> fusenet sounded pretty cool
14:22 <+protokol> eepnet
14:22 <+postman> uupnet :)
14:22 < lurk> froops
14:23 <+postman> LOL
14:23 < dm> nnnnnnnnnnnntp
14:23 <+postman> silly persons
14:23 <+polecat> "frosk's catchy name for a content distribution syndicate network." We could say "Fcnfacdsn was inspired by Usenet..."
14:23 < ant> <Asciiwhite> yeah i thought frusenet was good.
14:23 < frosk> :D
14:23 < jrandom> ok, please direct all silly names to frosk@mail.i2p :)
14:23 <+polecat> frootloops!
14:23 < frosk> i tried frusenet on a friend, he said "... or not."
14:23 < jrandom> (along with any comments/concerns/etc)
14:24 < frosk> although fusenet has a cool ring to it :)
14:24 < dm> How about just 'Content' ?
14:24 <+polecat> I like fusenet, it sounds... volatile.
14:24 <+polecat> So yes. Quieting down now.
14:24 < Pseudonym> nn2p
14:24 < dm> Nice and dinstinguished
14:24 < jrandom> ooOOo
14:24 < frosk> anyway, i'm not last on the agenda, we might want to move on ;)
14:24 <+postman> NN2P is COOL
14:24 < ant> <jnymo> if you had html.. you could have what looks like the net... inside froozlednet
14:24 < jrandom> ok, moving on to 5) i2p-bt
14:24 < jrandom> duck: you 'round?
14:24 <@duck> meep
14:24 < frosk> dm: "Content" is probably trademarked by Apple or whatever ;)
14:25 < ant> <Asciiwhite> owww, is this a minutes ?
14:25 <@duck> i2p-bt events this week:
14:25 < dm> speeddating!@
14:26 <@duck> - rss available on the trackers
14:26 <@duck> - silly attempts to make a metatracker in #eeprnova
14:26 < ant> <jnymo> noice
14:26 < ant> <Asciiwhite> yeah, great idea.
14:26 <+polecat> I still wish we could find a better codebase than that blasted bittorrent python source...
14:26 < ant> <Asciiwhite> What about support for say samplers(i.e video/pics)
14:26 <@duck> - some detailed code review leading to not finding bugs
14:26 <@duck> most of the scary looking errors are pretty harmless
14:27 <@duck> - I forgot
14:27 <@duck> .
14:27 < jrandom> word
14:27 < jrandom> i've been watching the streaming lib activity while swarming, and there have been some improvements in cvs
14:28 <+polecat> A metatracker lets you find trackers for files...?
14:28 < ant> <Asciiwhite> so people can upload a small sample of video quality, or a thumbnail etc.
14:28 < jrandom> (to keep up with the bt setup)
14:28 <+polecat> jrandom: Improvements as of what date, this morning? :3
14:28 <@duck> polecat: yeah, well this one just announces new files into a channel; but it could be enhanced
14:28 < jrandom> a day or two ago
14:29 <+polecat> Just checking, because last time I got CVS Head, you updated to 0.4.3 a few hours later.
14:29 < ant> <jnymo> yea.. is there some idea for i2ptorrent search some where down the eschelons?
14:29 < jrandom> one of the neat things though is that i believe the main remaining i2p-bt bumps we're seeing are actually just i2p/streaming lib/sam problems
14:30 <+polecat> Someone'd have to write a searching server, maybe by keyword and such.
14:30 <@duck> or an irc bot
14:30 < jrandom> jnymo: http://brittneyworld.i2p/bittorrent/
14:30 < jrandom> polecat: files.i2p/
14:30 < ant> <jnymo> hmm
14:30 < ant> <jnymo> mmhmm.. yea. mk
14:30 <+polecat> duck: Well a server to search, whether a bot or a eepsite like files.i2p...
14:31 <@duck> if someone needs rss etc enhancements on the tracker for their bots etc, let me know
14:31 < ant> <jnymo> hmm.. seems brittanyworld.i2p is down at the moment
14:32 < jrandom> since it seems the remaining problems are i2p related, not i2p-bt related, we've marked the swarming file transfer bounty as completed
14:32 < jrandom> (yay!)
14:32 < ant> <jnymo> anyhoo
14:32 < ant> * jnymo tips his hat
14:32 < frosk> congrats to all involved, you rock
14:33 < jrandom> aye, thanks to all the hard work of duck, ragnarok, dinoman, connelly, and drwoo
14:33 <+polecat> ragnaroks! dinoman's da man! Um...
14:33 < ant> <Asciiwhite> nice work duck.
14:33 <+polecat> I still want to get ctorrent ported to i2p. It's a wicked efficient bittorrent thingy, if a little flaky on the UI.
14:34 < dm> good work
14:35 <+polecat> Anyone know where the info about SAM proxies is?
14:36 < jrandom> about half of our general fund went towards that bounty, so our current balance is around $400USD [after some new donations today [yay!]]
14:36 < jrandom> polecat: http://www.i2p.net/sam
14:37 <+polecat> jrandom: Doing a swarming file transfer cost like, money? o.O
14:37 <+polecat> Ohh right the reward.
14:37 < Pseudonym> it'd be kinda cool to have the general fund balance on the website
14:37 < jrandom> right polecat :)
14:37 < jrandom> thats a good idea Pseudonym
14:38 < Pseudonym> doesn't have to be updated daily, just occasionally
14:38 < jrandom> i'll add it on to /bounties (sound good?)
14:38 < Pseudonym> sure
14:38 <+protokol> dont tell me they are keeping the hello chat room
14:38 < cervantes> if he did that we'd all see how much it goes down whenever jrandom goes out for a pie and a pint lunch
14:39 < jrandom> heh cervantes
14:39 < Pseudonym> didn't somebody donate money for jrandom's beer?
14:40 < cervantes> enough for half a pint at todays rates :)
14:40 < jrandom> yeah we've had a few beer donations :)
14:40 < jrandom> (list of donations up @ http://www.i2p.net/halloffame )
14:40 < Pseudonym> are you spending them?
14:41 < cervantes> nice...someone has money to burn I see ;-)
14:41 < ant> <Asciiwhite> anonymous
14:41 < ant> <Asciiwhite> $5.00 USD
14:41 < ant> <Asciiwhite> buy jrandom a beer fund
14:41 < ant> <Asciiwhite> lol
14:42 < jrandom> it would be nice if we can grow the bounties on the CDN, as thats a truckload of work
14:42 < jrandom> but we'll see how it goes over time
14:42 < jrandom> ok, i think we're pretty off track for 5) i2p-bt
14:42 < jrandom> so i suppose we should move to 6) ???
14:42 <@duck> nothing to add here.
14:43 < jrandom> is there anything else people would like to bring up?
14:43 <@duck> - why do so many ppl have problems when they specify a hostname?
14:43 < jrandom> not sure
14:43 < jrandom> both of my routers use an explicit hostname
14:43 <@duck> mine too, np
14:44 <@duck> maybe the warning text should be more negative
14:44 < jdot_> do we have a way to change keys on hostnames in hosts.txt?
14:44 < jrandom> sounds good duck
14:44 <+polecat> Regarding addressbook...
14:44 < jrandom> jdot_: no, not really, especially in light of the addressbook
14:44 < jdot_> like, if I lost my previous eepsite key. :(
14:44 < mule2> same here - but i have problems :)
14:44 <+polecat> Addressbook is going to be fused with i2pcontent, right?
14:45 < mule2> but don't think these result from the hostname
14:45 < Pseudonym> do we have a working addressbook?
14:45 <+polecat> You subscribe to an addressbook just like you subscribe to a blog... except it overwrites userhosts.txt and such.
14:45 < jrandom> polecat: distributing addressbooks through i2pcontent makes sense, yeah
14:45 < jrandom> Pseudonym: http://ragnarok.i2p/
14:45 <+polecat> Pseudonym: http://polecat.i2p/addressbook.pl.zip
14:45 < jrandom> and http://pole...er, what he said
14:45 < Pseudonym> thanks
14:46 < jrandom> i think there's also another one at http://orion.i2p too
14:46 < frosk> polecat: "overwrite" sounds dramatic. it "merges" ;)
14:47 <+polecat> Yeah... I saw orion's too.
14:47 < jdot_> dang
14:47 < jrandom> jdot_: so it looks like you're outa luck :/
14:47 < jrandom> ok, anyone else have anything for the meeting?
14:48 < dm> merry xmas
14:48 <+polecat> jdot: Thankfully when we've got fusenet working, you can update your i2p key with that eventually.
14:49 < ant> <Asciiwhite> dm, 15th of december here :)
14:49 < jrandom> and a happy Chanukah
14:49 <+polecat> Christ was born in September, what's everyone all celebrating about?
14:49 <+polecat> I'll stick with Yule thanks muchly.
14:49 < jrandom> ok if thats it...
14:49 * jrandom winds up
14:50 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/120.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, December 14, 2004
==================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,329 +1,323 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 121{% endblock %}
{% block content %}<h3>I2P dev meeting, December 21, 2004</h3>
<div class="irclog">
13:05 <@jrandom> 0) hi</p>
13:05 <@jrandom> 1) 0.4.2.4 & 0.4.2.5</p>
13:05 <@jrandom> 2) 0.5 strategy</p>
13:05 <@jrandom> 3) naming</p>
13:05 <@jrandom> 4) eepsite roundup</p>
13:05 <@jrandom> 5) ???</p>
13:06 <@jrandom> 0) hi</p>
13:06 * jrandom waves</p>
13:06 <@jrandom> weekly status notes posted a lil while ago @ http://dev.i2p.net/pipermail/i2p/2004-December/000528.html</p>
13:07 <@jrandom> lets jump on in to 1) 0.4.2.4 & 0.4.2.5</p>
13:08 <@jrandom> for those of you who have already upgraded to 0.4.2.5 - a good 1/3 of the network so far - thanks!</p>
13:09 <@jrandom> i do try to keep a more calm pacing to the releases, but there were some things in 0.4.2.5 that really needed wider deployment</p>
13:10 < Madman2003> 0.4.2.5 is working well for me when it comes to disconnects, but i don't run i2p 24/7(i had quite a few irc disconnects lately) and it's only been a few hours after the release</p>
13:10 <@jrandom> as mentioned later on in the email, i dont have a planned date for when the next bugfix release will be, but we shall see</p>
13:10 <@jrandom> ah great Madman2003 </p>
13:10 <@jrandom> yeah, its definitely too early to tell about 0.4.2.5</p>
13:11 < frosk> i used to see periods of high lag on .4, so far none of those with .5, but again, a bit early</p>
13:11 < frosk> (i'm talking about irc lag, of course)</p>
13:11 <@jrandom> the dns bug fixed could manifest itself in large numbers of peers running older releases failing at once, so the sooner people upgrade, the better</p>
13:12 <@duck> is that related with the failures on those manually entering a hostname?</p>
13:12 <@jrandom> yep</p>
13:12 < dm> how useless is the windows system tray I2P icon!?!?</p>
13:12 <@duck> ah, so that is why config.jsp is still friendly</p>
13:13 < Madman2003> anyone have a clue why some still run pre 0.4.2.4 routers?(it's been out a while)</p>
13:13 <@jrandom> dm: its more of a placeholder right now, plus a status icon saying "i2p is running"</p>
13:13 < dm> They have a life? :)</p>
13:13 * jrandom should resent that...</p>
13:14 < redzog> is there a way to do soft-restarts from the command line?</p>
13:14 <@jrandom> redzog: unfortunately not</p>
13:14 < redzog> hmm, pity</p>
13:14 <@jrandom> other than with wget, perhaps</p>
13:14 < redzog> would make it easier to do automatic updates</p>
13:14 <+detonate> i2prouter stop && i2prouter start :)</p>
13:14 <@jrandom> no, nm, wget wouldnt work either</p>
13:14 <@jrandom> (as the form requires interaction)</p>
13:14 < Madman2003> i generally update trough cvs several times in between releases(at best once a day), only takes a few minutes</p>
13:15 < redzog> lwp::simple could manage it</p>
13:15 < redzog> just a POST</p>
13:15 <@jrandom> redzog: support for that would be pretty cool</p>
13:15 < redzog> I'll try to whip something up</p>
13:15 <@jrandom> well, its more than just a post, you need to read the form presented to you then post those fields back</p>
13:16 <+detonate> eventually releases will be further spaced though.. right?</p>
13:16 <@jrandom> (there's a hidden flag to prevent people from doing things like &lt;img src="/configservice.jsp?action=restart"&gt;</p>
13:16 < redzog> heh, right</p>
13:16 <@jrandom> right detonate, t'wasn't planned to be this rapid, once a week at most</p>
13:16 < redzog> does the nonce value change?</p>
13:17 <@jrandom> if it didn't, it wouldnt be a nonce ;)</p>
13:17 < redzog> hmm, seems so</p>
13:17 < redzog> well, between sessions, between pageloads... ;)</p>
13:17 < redzog> pageloads it is</p>
13:17 <@jrandom> right</p>
13:17 <@jrandom> ok, anyone have anything else wrt 0.4.2.4/0.4.2.5?</p>
13:18 <@jrandom> i'm sur there'll be more discussion later after we've burnt in the new release more</p>
13:18 < dm> oh, is this a meeting?</p>
13:18 <+detonate> starting up seems to be a lot less smooth</p>
13:18 <+detonate> than 2.3</p>
13:18 <@jrandom> oh? in what way detonate - cpu, lag, memory, time?</p>
13:19 <+detonate> the list of peers takes forever to populate</p>
13:19 <+detonate> and i get a huge number of shitlisted peers</p>
13:19 <+detonate> also the i2ptunnel stuff sometimes hangs, but generally seems to take at least 2x as long to actually start up</p>
13:19 <+detonate> once it's started things smooth out</p>
13:19 <+detonate> it's odd</p>
13:19 <@jrandom> hmm, what does it list for the cause on /logs.jsp#connectionlogs ?</p>
13:20 < ant> &lt;BS314159&gt; I just did a graceful restart into 0.4.2.5. It took 120s to have Local Destinations</p>
13:20 < ant> &lt;BS314159&gt; seems good</p>
13:20 <@jrandom> cool BS314159 - thats pretty much the bare minimum, as we don't start i2ptunnel until 2 minutes after startup :)</p>
13:20 <+detonate> there's nothing out of the ordinary</p>
13:20 <+detonate> a shutdown exception</p>
13:21 <+detonate> but i think i caused that</p>
13:21 < mule> i have pulled over 300M through fcp for a movie with the last release. never been that good before. top rates beyond 40k. great work.</p>
13:21 <@jrandom> wow, nice mule!</p>
13:21 < mule> however i still have serious trouble with recovering from an IP change</p>
13:21 <@jrandom> detonate: hmm, ok, i'd love to debug this further after the meeting or another time you have available</p>
13:22 <+detonate> yeah</p>
13:22 <+detonate> ok</p>
13:22 < dm> tunnel lag: 364ms. What the fuck is going on , the tunnel lag is dropping 100-200ms on each release!</p>
13:22 <@jrandom> ah mule, ok</p>
13:22 <@jrandom> i've got an idea for how we could deal with those hung tcp connections - just toss on a 5m keepalive</p>
13:23 <@jrandom> heh dm, dont worry, it'll get back up again ;)</p>
13:23 < frosk> wow, i only have 261ms here :)</p>
13:24 <@jrandom> ok, if there's nothing else, lets jump on to 2) 0.5 strategy</p>
13:24 < dm> That can't be right...</p>
13:25 <+ugha2p> Looks like I'm late for the meeting again.</p>
13:26 <@jrandom> there's still a lot of work to be done with 0.5, but a broad outline of the process was included in that email</p>
13:26 * jrandom sends ugha2p to the principal's office</p>
13:27 <@jrandom> there are still some details left to be worked out on the tunnel pooling and creation, but i think we've got a few different offerings that will meet the needs of various user bases</p>
13:28 <@jrandom> there'll be some good ol' fashioned documentation posted once most of the kinks in the design are hammered out for y'all's review</p>
13:28 <@jrandom> (currently its taking up ~8 pages in the notebook, should compress well though)</p>
13:29 < kaji> has the meeting started yet?</p>
13:29 <@jrandom> but another one of the tasks listed for 0.5 is "deal with the bandwidth needs of the network", and i have no idea how to plan for that, so we'll play that by ear</p>
13:29 <@jrandom> yes kaji, we're on 2) 0.5 strategy</p>
13:30 <@jrandom> well, thats all i have to say about that at the moment, unless anyone has any questions/comments/concerns?</p>
13:31 <+ugha2p> Wow, most of the routers have already upgraded.</p>
13:31 <+detonate> is filtering http traffic to strip out javascript/etc in the roadmap?</p>
13:31 <+detonate> for 0.5</p>
13:31 <+ugha2p> detonate: No.</p>
13:31 <@jrandom> detonate: 0.6</p>
13:31 < ant> &lt;cat-a-puss&gt; WRT bandwidth, should we enable probabilistic tunnel length, and/or local biased tunnels, for bittorrent as in general BT users have a weaker threat modle?</p>
13:32 <@jrandom> cat-a-puss: yes, definitely. thats one of the big parts of the 0.5 release</p>
13:32 <+ugha2p> detonate: Unless you implement it first. ;)</p>
13:32 <+detonate> i was thinking about it</p>
13:33 < ant> &lt;cat-a-puss&gt; will html filtering be conducted in a seperate process?</p>
13:33 <@jrandom> i think michelle is looking at that too, so if you two wanted to work together (michelle is learning java) that'd rule</p>
13:33 <+detonate> ok</p>
13:33 <@jrandom> cat-a-puss: i know not. </p>
13:34 <+ugha2p> cat-a-puss: Why should it?</p>
13:35 < ant> &lt;cat-a-puss&gt; (I ask because I was thinking of making a proxy that ran all incomming brouser traffic through clamav) That is GPLed so if we could include that in the filter, it would probably be good.</p>
13:35 <@jrandom> cool cat-a-puss!</p>
13:35 <+ugha2p> Some people already use Privoxy for I2P.</p>
13:36 < bens> in general, I'm anti-including-stuff</p>
13:36 < susi23> I would rather see people configuring their browsers right than promising to protect them from malicious code.</p>
13:36 <@jrandom> susi23: no one configures their browser properly</p>
13:36 <@jrandom> especially not joe sixpack</p>
13:37 < frosk> one can wonder if Joe is even able to set a proxy for his browser</p>
13:37 <@jrandom> my personal view is that something cgi-proxy like would be ideal</p>
13:37 <@jrandom> exactly frosk</p>
13:37 <@jrandom> with a cgi-proxy like interface (filtering according to their preferences, safe by default), even a drooling moron could use it</p>
13:38 < bens> I suppose I2P needs multiple versions for multiple markets even more than MS Office</p>
13:38 <@jrandom> 'tis why we have small components and push this stuff out of the router bens ;) </p>
13:38 < Ragnarok> a proxy auto config file would help</p>
13:39 <@jrandom> Ragnarok: we have one, but there are still dangerous things that can be done with it</p>
13:39 < frosk> maybe a specialized i2p browser even (if someone is drowning in free time ;)</p>
13:39 < susi23> ragnarok: that one? http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/apps/proxyscript/i2pProxy.pac</p>
13:39 <@jrandom> frosk: on the specialized i2p OS and hardware too, i suppose</p>
13:40 < frosk> hehe, perfect</p>
13:40 < Ragnarok> that's not in the install, though</p>
13:40 * jrandom implements those in the specialized i2p universe</p>
13:40 < susi23> . o O ( perhaps we should try to find a dedicated i2p planet too )</p>
13:40 < susi23> . o O ( damn, too slow )</p>
13:40 < mule> ok, we'll sell the hardware :)</p>
13:40 < frosk> you know what they say, to create something from scratch, first create the universe</p>
13:41 <@jrandom> w00t, now all we need are some investors..</p>
13:41 < bens> seriously, a firefox autoconfigurator might be reasonable</p>
13:41 <@jrandom> bens: the .pac susi linked to above should do the trick</p>
13:41 < bens> not just for proxy; also for the security settings, homepage, etc.</p>
13:41 <@jrandom> we can ship that with the install too, but its insufficient for people who need anonymity (and are not ubergeeks already)</p>
13:42 <@jrandom> hmm, perhaps that sort of thing could go into cervantes' i2p xul app</p>
13:43 <@jrandom> but thats getting further off topic from the 2) 0.5 strategy</p>
13:43 <@jrandom> anyone else have anything for that, or shall we move on to 3) naming?</p>
13:44 -!- Irssi: #i2p: Total of 40 nicks [2 ops, 0 halfops, 6 voices, 32 normal]</p>
13:44 <@jrandom> consider us moved</p>
13:44 <@jrandom> ok, aparently i kind of jumped the gun w/ the 2.0.1 ref of addressbook - Ragnarok, want to give us an update?</p>
13:44 <+ugha2p> jrandom: Can we expect the dates on the roadmap to be correct?</p>
13:45 <@jrandom> ugha2p: they currently reflect my best estimate</p>
13:45 <+ugha2p> jrandom: Ok, right.</p>
13:45 < Ragnarok> it's released now</p>
13:45 <@jrandom> w00t</p>
13:45 < Ragnarok> check ragnarok.i2p</p>
13:45 < Ragnarok> I wasn't planning on releasing it yet, but jrandom forced my hand :)</p>
13:46 <@jrandom> hehe</p>
13:46 <+ugha2p> Ragnarok: Btw, you're missing a link from the homepage. :)</p>
13:46 < Ragnarok> it's just a few bug fixes, nothing major, but it should deal better with some corner cases</p>
13:46 <@jrandom> its on the top right ugha2p </p>
13:47 < Ragnarok> ugha2p: it's on the sidebar</p>
13:47 < Ragnarok> I'll add links to the post as well, though :)</p>
13:47 < mule2> "that'll be the day when i die". daily IP change to set the clock after.</p>
13:48 < Ragnarok> anyway, if everyone could try it out, that'd be nice. Bug reports are always appreciated</p>
13:48 <+ugha2p> Ragnarok: Oh, that sidebar is seriously fucked in Opera.</p>
13:48 < mule2> Lease expired 12773d ago</p>
13:49 <+ugha2p> Ragnarok: Well, not really fucked, but just located at the end of the page.</p>
13:49 <@jrandom> cool Ragnarok, thanks</p>
13:49 < Ragnarok> your window's probably not wide enough</p>
13:49 <+ugha2p> Ragnarok: Right, but it should work with any window size.</p>
13:50 <+ugha2p> So you might want to fix it in the future. :)</p>
13:50 < Ragnarok> ugha2p: should is an interesting choice of words :)</p>
13:50 < Frooze> ah, wrong in mozilla 1.7 too. my window is small though.</p>
13:50 <+ugha2p> Why's that?</p>
13:50 < Frooze> thanks ragnarok. cool stuff.</p>
13:51 < Ragnarok> I may fix it in the future, but it's really low on my priorities</p>
13:51 * jrandom prefers addressbook updates to html fixes</p>
13:52 < Ragnarok> anyhoo, any questions?</p>
13:53 < frosk> thanks for addressbook, Ragnarok, sounds very useful</p>
13:54 <+ugha2p> Is the documented way of loading addressbook the only way, or are there any less intrusive ones?</p>
13:54 < kaji> i just installed it, it rocks</p>
13:54 < Ragnarok> you can start it by hand using "java -jar addresbook.jar &lt;path to i2p/addressbook&gt;"</p>
13:54 < Ragnarok> thank you :)</p>
13:55 < kaji> oh, and i dled version 2.0.0 is there an update someware?</p>
13:55 < Ragnarok> ok, I fixed the column, it was just a stupid mix of absolute and realitive sizes</p>
13:56 < Ragnarok> yep, there's 2.0.1 up now on ragnarok.i2p</p>
13:57 <+ugha2p> I'm getting "Failed to load Main-Class manifest attribute from" now, but never mind, I'll do a restart later.</p>
13:57 < Ragnarok> whoops</p>
13:58 < Ragnarok> that's my bad</p>
13:58 < Ragnarok> I'll try to fix that soon</p>
13:58 <+ugha2p> Ah, okay. :)</p>
13:58 < Ragnarok> there will also be an easy to install .war version soon</p>
13:59 < dm> jrandom: you are a machine</p>
14:00 <@jrandom> wikked, thanks Ragnarok </p>
14:00 <@jrandom> susi23: ping?</p>
14:00 < susi23> 1200ms</p>
14:01 <@jrandom> !thwap</p>
14:01 <@jrandom> anyway, wanna give us a rundown on whats up w/ susidns?</p>
14:01 <@jrandom> or should that wait for later?</p>
14:01 < susi23> do we have time for a more general discussion about naming stuff?</p>
14:02 < susi23> what features we want in the future?</p>
14:03 <@jrandom> some of my thoughts are posted up on http://dev.i2p.net/pipermail/i2p/2004-February/000135.html</p>
14:03 <@jrandom> (for what general features)</p>
14:04 <@jrandom> i think the hardest thing will be weaning people off globally unique human readable names, but with some good interfaces it should be doable</p>
14:04 < Ragnarok> implementing the data structures you outlined in xml is one of my next goals</p>
14:04 < susi23> ok, there is a small writing about attributes at http://susi.i2p/removablekeys.html</p>
14:05 < ant> &lt;Jnymo&gt; wow.. pretty crowded in here tonight</p>
14:05 < bens> ragnarok: have you checked out YAML? Might be easier</p>
14:05 <+ugha2p> Jnymo: Yeah, we're trying to hold a meeting here.</p>
14:05 < Ragnarok> YAML's name is far too apt</p>
14:05 <@jrandom> cool susi23, though i think we'll definitely want to migrate away from the plain hosts.txt format</p>
14:05 < ant> &lt;Quadn-werk&gt; addition of a command line graceful restart?</p>
14:06 < ant> &lt;Jnymo&gt; ugha2p: ah</p>
14:06 < susi23> are there any ideas how to keep names unique in the long run?</p>
14:06 <@jrandom> one of the important parts of the data to be managed in the naming service is for an entry to be signed, requiring some hard structure (or careful xml)</p>
14:07 <@jrandom> i dont believe in globally unique human, human readable, and secure names.</p>
14:07 <@jrandom> (i bundle centralized & secure together)</p>
14:07 <@jrandom> susi23: have you seen http://zooko.com/distnames.html ?</p>
14:07 < Ragnarok> I think using an addressbook like system, the names will end up being mostly unique, since it's in the interest of the person claiming a name not to choose one that's already in use</p>
14:08 <@jrandom> Ragnarok: we'll see. perhaps</p>
14:08 < susi23> i'll check this out</p>
14:08 < bens> I suspect trusted authorities will emerge</p>
14:08 < Ragnarok> well, there already is one</p>
14:08 < frosk> hosts.txt? :)</p>
14:09 < Ragnarok> jrandom's, yeah</p>
14:09 <@jrandom> or if not trusted authorities, names that include the path to uniquely identify it</p>
14:09 <@jrandom> (e.g. "the site orion.i2p calls 'frosk.i2p'")</p>
14:10 <@jrandom> Derek Eddington had some posts along those lines in september - http://dev.i2p.net/pipermail/i2p/2004-September/000432.html</p>
14:10 < bens> frosk.orion.i2p</p>
14:10 <@jrandom> smtp.frosk.ns.orion.i2p</p>
14:11 * jrandom starts building uucp bang paths</p>
14:11 < frosk> hah</p>
14:12 < susi23> ok, what now... how about a "naming roadmap"? :)</p>
14:12 < ant> &lt;Jnymo&gt; you guys have swayed me away from an absolute distributed dns for i2p.. somewhat.. but ducks ideas started me thinking that a trust system might work.. like, a lookup could bring back a list of sites/files, and each could be listed with the amount of trust that the network gives it</p>
14:12 < susi23> once we agreed what to do</p>
14:12 <@jrandom> thats a good idea susi23, wanna write one up?</p>
14:13 <@jrandom> trusting other people's trust has potential, but needs to be done very carefully</p>
14:13 < susi23> I could do this, but I still have no idea WHAT we want to do. There are some decisions to make.</p>
14:14 <@jrandom> (aka only according to the terms that you trust the peers along the chain to the trust author)</p>
14:14 < modulus> there is or there should not be a "network trust" of a site, trust has to be user-centric always</p>
14:14 <@jrandom> susi23: roadmap step 1: decide among $featureset</p>
14:14 < susi23> Or at least we have to develop all ideas into a more precise concept.</p>
14:14 < ant> &lt;Jnymo&gt; well, if it was explicitly simple.. like, if files i2p listed how many sites linked to siteinquestion.i2p</p>
14:15 < Ragnarok> ok, the I've updated the addressbook package with an executable jar.</p>
14:15 < ant> &lt;Jnymo&gt; er, files.i2p</p>
14:15 <@jrandom> jnymo: that turns into a centralized authority - files.i2p</p>
14:15 < modulus> not to say that you could poison the pool of links by establishing a shitload of sites.</p>
14:16 < modulus> googlebombing on i2p</p>
14:16 < ant> &lt;Jnymo&gt; true.. but files i2p could be decentralized</p>
14:16 < susi23> ok, how about collection ideas/information/concepts until, lets say january</p>
14:16 < orion> 'lo all. I see naming is on the table.. *again* :)</p>
14:16 < susi23> then comes the decision phase, ok?</p>
14:16 <@jrandom> sounds good - will you be the point of contact to gather that together?</p>
14:16 < Ragnarok> sure</p>
14:16 < modulus> doesn't matter if the trust aggregate is descentralized, trust has to emanate from the user. anything else can be poisoned imo.</p>
14:17 < susi23> can't we take the mailinglist for this?</p>
14:17 < bob> or perhaps ugha's wiki?</p>
14:17 < ant> &lt;Jnymo&gt; agreed.. but what how to do that? put a little trust meter bar at the top of the web browser?</p>
14:18 <@jrandom> the wiki would be good, we can gather links to all the previous discussions there</p>
14:18 < modulus> jnyo: probably the most feasible solution is to bind to the first name encountered or something.</p>
14:18 < dm> let's all give a hand of applause to jrandom for his wonderful project management</p>
14:18 < susi23> fine</p>
14:18 < modulus> but there are more ways than sausages.</p>
14:19 < susi23> url to the wiki? (for the records)</p>
14:19 < ant> * Jnymo claps</p>
14:19 <@jrandom> ugha.i2p</p>
14:19 * dm claps</p>
14:19 < susi23> ok</p>
14:19 < susi23> then I'm done and ping jrandom back ;)</p>
14:20 < ant> &lt;Jnymo&gt; modulus: so, if i refer a link to someone else, i'm refering them to the site i first binded to.. that might work.. </p>
14:20 <+ugha2p> Looks like jrandom has ping timeouted.</p>
14:20 <@jrandom> ok cool, anything else on nami^W nm, no more on naming. on to the wiki</p>
14:20 < modulus> anyway, if you're linking you'll probably want to put an absolute path in the link, not just a name</p>
14:21 <@jrandom> moving forward to 4) eepsite roundup</p>
14:21 < dm> dm.i2p is up and running</p>
14:21 <@jrandom> cool</p>
14:22 <@jrandom> ok, i dont really have much to add beyond whats mentioned in the mail</p>
14:22 < bob> nice to see an influx of sites! all speedy to access as well!</p>
14:22 <@jrandom> aye, agreed bob</p>
14:22 < bob> orion, thanks for your work.. I use your site daily.</p>
14:22 * jrandom too, the 'last updated' is especially helpful</p>
14:23 < bob> dm: :-)</p>
14:24 <@jrandom> ok, if there's nothing more on that, we can jump to 5) ???</p>
14:24 <@jrandom> is there anything else people want to bring up for the meeting?</p>
14:24 < ant> &lt;Jnymo&gt; hows the net status?</p>
14:24 < ant> &lt;Jnymo&gt; wrt 4.2.5?</p>
14:25 <@jrandom> its looking good, but the release is only a few hours old, so too soon to tell</p>
14:25 < ant> &lt;Jnymo&gt; oh, heh</p>
14:25 < ant> &lt;Jnymo&gt; any fusenet news?</p>
14:26 <@jrandom> (http://piespy.i2p/i2p/i2p-current.png heh)</p>
14:26 < frosk> my work on i2pcontent has been largely put aside for some weeks, but the latest version of the document can be read at http://frosk.i2p/i2pcontent.html . if anyone is interested, do read, and do comment harshly if needs be (om irc when i'm not /away or mail to frosk@mail.i2p)</p>
14:26 < frosk> i2pcontent/fusenet/anything ;)</p>
14:26 < ant> &lt;Jnymo&gt; wordicus</p>
14:28 <@jrandom> ok, if there's nothing else...</p>
14:28 < mule2> tons of applause for all the excellent contributions</p>
14:29 <@jrandom> aye, y'all are doing some kickass shit</p>
14:29 < frosk> you too, jrandom :)</p>
14:29 < orion> word.</p>
14:29 < orion> yes, very much so, you too jrandom.</p>
14:29 < scintilla> hear hear!</p>
14:29 < ant> &lt;Jnymo&gt; yea, i noticed on the site, theres less info on how to help out</p>
14:29 <@jrandom> sometimes kickass, sometimes ass kicked ;)</p>
14:29 < orion> HIP HIP</p>
14:30 < ant> &lt;Jnymo&gt; HORRAY</p>
14:30 * orion smiles</p>
14:30 < Frooze> downloaded eclipse today, to learn java over holiday, because y'all are so impressive.</p>
14:30 <@jrandom> jnymo: many of the small easy-to-accomplish tasks have been done</p>
14:30 <@jrandom> ooh wikked Frooze </p>
14:31 < Frooze> so, trouble on horizon. heh</p>
14:31 <@jrandom> jnymo: i really should collect some more of them though and post 'em</p>
14:31 < ant> &lt;Jnymo&gt; jrandom: You still looking for someone to help out on alexandria.i2p?</p>
14:31 <@jrandom> (take cover arizona!)</p>
14:31 * jrandom is not involved in alexandria, but yes, i believe they are still looking for a librarian</p>
14:31 < ant> &lt;Jnymo&gt; learn to swim, folks ;)</p>
14:31 * orion loves pump up the volume references. Vague though they may be.</p>
14:31 <@duck> yes we do</p>
14:31 <@jrandom> :)</p>
14:31 < Ragnarok> jrandom: where is the war actually supposed to go?</p>
14:31 <@jrandom> (orion++)</p>
14:32 <@jrandom> Ragnarok: i2p/webapps/addressbook.war</p>
14:32 <@jrandom> (then restart the router)</p>
14:32 < ant> &lt;Jnymo&gt; duck, you talkint to me?</p>
14:32 < Ragnarok> cool. I shall commence testing</p>
14:32 <@jrandom> r0x0r</p>
14:32 < ant> &lt;Jnymo&gt; duck: is alexandria on your site?</p>
14:33 <@duck> duck.i2p/alexandria/</p>
14:33 < ant> &lt;Jnymo&gt; word</p>
14:34 <@jrandom> ok, if thats all, we can slide out of here @ the 90m mark..</p>
14:34 * jrandom winds up</p>
14:34 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:05 <@jrandom> 0) hi
13:05 <@jrandom> 1) 0.4.2.4 & 0.4.2.5
13:05 <@jrandom> 2) 0.5 strategy
13:05 <@jrandom> 3) naming
13:05 <@jrandom> 4) eepsite roundup
13:05 <@jrandom> 5) ???
13:06 <@jrandom> 0) hi
13:06 * jrandom waves
13:06 <@jrandom> weekly status notes posted a lil while ago @ http://dev.i2p.net/pipermail/i2p/2004-December/000528.html
13:07 <@jrandom> lets jump on in to 1) 0.4.2.4 & 0.4.2.5
13:08 <@jrandom> for those of you who have already upgraded to 0.4.2.5 - a good 1/3 of the network so far - thanks!
13:09 <@jrandom> i do try to keep a more calm pacing to the releases, but there were some things in 0.4.2.5 that really needed wider deployment
13:10 < Madman2003> 0.4.2.5 is working well for me when it comes to disconnects, but i don't run i2p 24/7(i had quite a few irc disconnects lately) and it's only been a few hours after the release
13:10 <@jrandom> as mentioned later on in the email, i dont have a planned date for when the next bugfix release will be, but we shall see
13:10 <@jrandom> ah great Madman2003
13:10 <@jrandom> yeah, its definitely too early to tell about 0.4.2.5
13:11 < frosk> i used to see periods of high lag on .4, so far none of those with .5, but again, a bit early
13:11 < frosk> (i'm talking about irc lag, of course)
13:11 <@jrandom> the dns bug fixed could manifest itself in large numbers of peers running older releases failing at once, so the sooner people upgrade, the better
13:12 <@duck> is that related with the failures on those manually entering a hostname?
13:12 <@jrandom> yep
13:12 < dm> how useless is the windows system tray I2P icon!?!?
13:12 <@duck> ah, so that is why config.jsp is still friendly
13:13 < Madman2003> anyone have a clue why some still run pre 0.4.2.4 routers?(it's been out a while)
13:13 <@jrandom> dm: its more of a placeholder right now, plus a status icon saying "i2p is running"
13:13 < dm> They have a life? :)
13:13 * jrandom should resent that...
13:14 < redzog> is there a way to do soft-restarts from the command line?
13:14 <@jrandom> redzog: unfortunately not
13:14 < redzog> hmm, pity
13:14 <@jrandom> other than with wget, perhaps
13:14 < redzog> would make it easier to do automatic updates
13:14 <+detonate> i2prouter stop && i2prouter start :)
13:14 <@jrandom> no, nm, wget wouldnt work either
13:14 <@jrandom> (as the form requires interaction)
13:14 < Madman2003> i generally update trough cvs several times in between releases(at best once a day), only takes a few minutes
13:15 < redzog> lwp::simple could manage it
13:15 < redzog> just a POST
13:15 <@jrandom> redzog: support for that would be pretty cool
13:15 < redzog> I'll try to whip something up
13:15 <@jrandom> well, its more than just a post, you need to read the form presented to you then post those fields back
13:16 <+detonate> eventually releases will be further spaced though.. right?
13:16 <@jrandom> (there's a hidden flag to prevent people from doing things like <img src="/configservice.jsp?action=restart">
13:16 < redzog> heh, right
13:16 <@jrandom> right detonate, t'wasn't planned to be this rapid, once a week at most
13:16 < redzog> does the nonce value change?
13:17 <@jrandom> if it didn't, it wouldnt be a nonce ;)
13:17 < redzog> hmm, seems so
13:17 < redzog> well, between sessions, between pageloads... ;)
13:17 < redzog> pageloads it is
13:17 <@jrandom> right
13:17 <@jrandom> ok, anyone have anything else wrt 0.4.2.4/0.4.2.5?
13:18 <@jrandom> i'm sur there'll be more discussion later after we've burnt in the new release more
13:18 < dm> oh, is this a meeting?
13:18 <+detonate> starting up seems to be a lot less smooth
13:18 <+detonate> than 2.3
13:18 <@jrandom> oh? in what way detonate - cpu, lag, memory, time?
13:19 <+detonate> the list of peers takes forever to populate
13:19 <+detonate> and i get a huge number of shitlisted peers
13:19 <+detonate> also the i2ptunnel stuff sometimes hangs, but generally seems to take at least 2x as long to actually start up
13:19 <+detonate> once it's started things smooth out
13:19 <+detonate> it's odd
13:19 <@jrandom> hmm, what does it list for the cause on /logs.jsp#connectionlogs ?
13:20 < ant> <BS314159> I just did a graceful restart into 0.4.2.5. It took 120s to have Local Destinations
13:20 < ant> <BS314159> seems good
13:20 <@jrandom> cool BS314159 - thats pretty much the bare minimum, as we don't start i2ptunnel until 2 minutes after startup :)
13:20 <+detonate> there's nothing out of the ordinary
13:20 <+detonate> a shutdown exception
13:21 <+detonate> but i think i caused that
13:21 < mule> i have pulled over 300M through fcp for a movie with the last release. never been that good before. top rates beyond 40k. great work.
13:21 <@jrandom> wow, nice mule!
13:21 < mule> however i still have serious trouble with recovering from an IP change
13:21 <@jrandom> detonate: hmm, ok, i'd love to debug this further after the meeting or another time you have available
13:22 <+detonate> yeah
13:22 <+detonate> ok
13:22 < dm> tunnel lag: 364ms. What the fuck is going on , the tunnel lag is dropping 100-200ms on each release!
13:22 <@jrandom> ah mule, ok
13:22 <@jrandom> i've got an idea for how we could deal with those hung tcp connections - just toss on a 5m keepalive
13:23 <@jrandom> heh dm, dont worry, it'll get back up again ;)
13:23 < frosk> wow, i only have 261ms here :)
13:24 <@jrandom> ok, if there's nothing else, lets jump on to 2) 0.5 strategy
13:24 < dm> That can't be right...
13:25 <+ugha2p> Looks like I'm late for the meeting again.
13:26 <@jrandom> there's still a lot of work to be done with 0.5, but a broad outline of the process was included in that email
13:26 * jrandom sends ugha2p to the principal's office
13:27 <@jrandom> there are still some details left to be worked out on the tunnel pooling and creation, but i think we've got a few different offerings that will meet the needs of various user bases
13:28 <@jrandom> there'll be some good ol' fashioned documentation posted once most of the kinks in the design are hammered out for y'all's review
13:28 <@jrandom> (currently its taking up ~8 pages in the notebook, should compress well though)
13:29 < kaji> has the meeting started yet?
13:29 <@jrandom> but another one of the tasks listed for 0.5 is "deal with the bandwidth needs of the network", and i have no idea how to plan for that, so we'll play that by ear
13:29 <@jrandom> yes kaji, we're on 2) 0.5 strategy
13:30 <@jrandom> well, thats all i have to say about that at the moment, unless anyone has any questions/comments/concerns?
13:31 <+ugha2p> Wow, most of the routers have already upgraded.
13:31 <+detonate> is filtering http traffic to strip out javascript/etc in the roadmap?
13:31 <+detonate> for 0.5
13:31 <+ugha2p> detonate: No.
13:31 <@jrandom> detonate: 0.6
13:31 < ant> <cat-a-puss> WRT bandwidth, should we enable probabilistic tunnel length, and/or local biased tunnels, for bittorrent as in general BT users have a weaker threat modle?
13:32 <@jrandom> cat-a-puss: yes, definitely. thats one of the big parts of the 0.5 release
13:32 <+ugha2p> detonate: Unless you implement it first. ;)
13:32 <+detonate> i was thinking about it
13:33 < ant> <cat-a-puss> will html filtering be conducted in a seperate process?
13:33 <@jrandom> i think michelle is looking at that too, so if you two wanted to work together (michelle is learning java) that'd rule
13:33 <+detonate> ok
13:33 <@jrandom> cat-a-puss: i know not.
13:34 <+ugha2p> cat-a-puss: Why should it?
13:35 < ant> <cat-a-puss> (I ask because I was thinking of making a proxy that ran all incomming brouser traffic through clamav) That is GPLed so if we could include that in the filter, it would probably be good.
13:35 <@jrandom> cool cat-a-puss!
13:35 <+ugha2p> Some people already use Privoxy for I2P.
13:36 < bens> in general, I'm anti-including-stuff
13:36 < susi23> I would rather see people configuring their browsers right than promising to protect them from malicious code.
13:36 <@jrandom> susi23: no one configures their browser properly
13:36 <@jrandom> especially not joe sixpack
13:37 < frosk> one can wonder if Joe is even able to set a proxy for his browser
13:37 <@jrandom> my personal view is that something cgi-proxy like would be ideal
13:37 <@jrandom> exactly frosk
13:37 <@jrandom> with a cgi-proxy like interface (filtering according to their preferences, safe by default), even a drooling moron could use it
13:38 < bens> I suppose I2P needs multiple versions for multiple markets even more than MS Office
13:38 <@jrandom> 'tis why we have small components and push this stuff out of the router bens ;)
13:38 < Ragnarok> a proxy auto config file would help
13:39 <@jrandom> Ragnarok: we have one, but there are still dangerous things that can be done with it
13:39 < frosk> maybe a specialized i2p browser even (if someone is drowning in free time ;)
13:39 < susi23> ragnarok: that one? http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/apps/proxyscript/i2pProxy.pac
13:39 <@jrandom> frosk: on the specialized i2p OS and hardware too, i suppose
13:40 < frosk> hehe, perfect
13:40 < Ragnarok> that's not in the install, though
13:40 * jrandom implements those in the specialized i2p universe
13:40 < susi23> . o O ( perhaps we should try to find a dedicated i2p planet too )
13:40 < susi23> . o O ( damn, too slow )
13:40 < mule> ok, we'll sell the hardware :)
13:40 < frosk> you know what they say, to create something from scratch, first create the universe
13:41 <@jrandom> w00t, now all we need are some investors..
13:41 < bens> seriously, a firefox autoconfigurator might be reasonable
13:41 <@jrandom> bens: the .pac susi linked to above should do the trick
13:41 < bens> not just for proxy; also for the security settings, homepage, etc.
13:41 <@jrandom> we can ship that with the install too, but its insufficient for people who need anonymity (and are not ubergeeks already)
13:42 <@jrandom> hmm, perhaps that sort of thing could go into cervantes' i2p xul app
13:43 <@jrandom> but thats getting further off topic from the 2) 0.5 strategy
13:43 <@jrandom> anyone else have anything for that, or shall we move on to 3) naming?
13:44 -!- Irssi: #i2p: Total of 40 nicks [2 ops, 0 halfops, 6 voices, 32 normal]
13:44 <@jrandom> consider us moved
13:44 <@jrandom> ok, aparently i kind of jumped the gun w/ the 2.0.1 ref of addressbook - Ragnarok, want to give us an update?
13:44 <+ugha2p> jrandom: Can we expect the dates on the roadmap to be correct?
13:45 <@jrandom> ugha2p: they currently reflect my best estimate
13:45 <+ugha2p> jrandom: Ok, right.
13:45 < Ragnarok> it's released now
13:45 <@jrandom> w00t
13:45 < Ragnarok> check ragnarok.i2p
13:45 < Ragnarok> I wasn't planning on releasing it yet, but jrandom forced my hand :)
13:46 <@jrandom> hehe
13:46 <+ugha2p> Ragnarok: Btw, you're missing a link from the homepage. :)
13:46 < Ragnarok> it's just a few bug fixes, nothing major, but it should deal better with some corner cases
13:46 <@jrandom> its on the top right ugha2p
13:47 < Ragnarok> ugha2p: it's on the sidebar
13:47 < Ragnarok> I'll add links to the post as well, though :)
13:47 < mule2> "that'll be the day when i die". daily IP change to set the clock after.
13:48 < Ragnarok> anyway, if everyone could try it out, that'd be nice. Bug reports are always appreciated
13:48 <+ugha2p> Ragnarok: Oh, that sidebar is seriously fucked in Opera.
13:48 < mule2> Lease expired 12773d ago
13:49 <+ugha2p> Ragnarok: Well, not really fucked, but just located at the end of the page.
13:49 <@jrandom> cool Ragnarok, thanks
13:49 < Ragnarok> your window's probably not wide enough
13:49 <+ugha2p> Ragnarok: Right, but it should work with any window size.
13:50 <+ugha2p> So you might want to fix it in the future. :)
13:50 < Ragnarok> ugha2p: should is an interesting choice of words :)
13:50 < Frooze> ah, wrong in mozilla 1.7 too. my window is small though.
13:50 <+ugha2p> Why's that?
13:50 < Frooze> thanks ragnarok. cool stuff.
13:51 < Ragnarok> I may fix it in the future, but it's really low on my priorities
13:51 * jrandom prefers addressbook updates to html fixes
13:52 < Ragnarok> anyhoo, any questions?
13:53 < frosk> thanks for addressbook, Ragnarok, sounds very useful
13:54 <+ugha2p> Is the documented way of loading addressbook the only way, or are there any less intrusive ones?
13:54 < kaji> i just installed it, it rocks
13:54 < Ragnarok> you can start it by hand using "java -jar addresbook.jar <path to i2p/addressbook>"
13:54 < Ragnarok> thank you :)
13:55 < kaji> oh, and i dled version 2.0.0 is there an update someware?
13:55 < Ragnarok> ok, I fixed the column, it was just a stupid mix of absolute and realitive sizes
13:56 < Ragnarok> yep, there's 2.0.1 up now on ragnarok.i2p
13:57 <+ugha2p> I'm getting "Failed to load Main-Class manifest attribute from" now, but never mind, I'll do a restart later.
13:57 < Ragnarok> whoops
13:58 < Ragnarok> that's my bad
13:58 < Ragnarok> I'll try to fix that soon
13:58 <+ugha2p> Ah, okay. :)
13:58 < Ragnarok> there will also be an easy to install .war version soon
13:59 < dm> jrandom: you are a machine
14:00 <@jrandom> wikked, thanks Ragnarok
14:00 <@jrandom> susi23: ping?
14:00 < susi23> 1200ms
14:01 <@jrandom> !thwap
14:01 <@jrandom> anyway, wanna give us a rundown on whats up w/ susidns?
14:01 <@jrandom> or should that wait for later?
14:01 < susi23> do we have time for a more general discussion about naming stuff?
14:02 < susi23> what features we want in the future?
14:03 <@jrandom> some of my thoughts are posted up on http://dev.i2p.net/pipermail/i2p/2004-February/000135.html
14:03 <@jrandom> (for what general features)
14:04 <@jrandom> i think the hardest thing will be weaning people off globally unique human readable names, but with some good interfaces it should be doable
14:04 < Ragnarok> implementing the data structures you outlined in xml is one of my next goals
14:04 < susi23> ok, there is a small writing about attributes at http://susi.i2p/removablekeys.html
14:05 < ant> <Jnymo> wow.. pretty crowded in here tonight
14:05 < bens> ragnarok: have you checked out YAML? Might be easier
14:05 <+ugha2p> Jnymo: Yeah, we're trying to hold a meeting here.
14:05 < Ragnarok> YAML's name is far too apt
14:05 <@jrandom> cool susi23, though i think we'll definitely want to migrate away from the plain hosts.txt format
14:05 < ant> <Quadn-werk> addition of a command line graceful restart?
14:06 < ant> <Jnymo> ugha2p: ah
14:06 < susi23> are there any ideas how to keep names unique in the long run?
14:06 <@jrandom> one of the important parts of the data to be managed in the naming service is for an entry to be signed, requiring some hard structure (or careful xml)
14:07 <@jrandom> i dont believe in globally unique human, human readable, and secure names.
14:07 <@jrandom> (i bundle centralized & secure together)
14:07 <@jrandom> susi23: have you seen http://zooko.com/distnames.html ?
14:07 < Ragnarok> I think using an addressbook like system, the names will end up being mostly unique, since it's in the interest of the person claiming a name not to choose one that's already in use
14:08 <@jrandom> Ragnarok: we'll see. perhaps
14:08 < susi23> i'll check this out
14:08 < bens> I suspect trusted authorities will emerge
14:08 < Ragnarok> well, there already is one
14:08 < frosk> hosts.txt? :)
14:09 < Ragnarok> jrandom's, yeah
14:09 <@jrandom> or if not trusted authorities, names that include the path to uniquely identify it
14:09 <@jrandom> (e.g. "the site orion.i2p calls 'frosk.i2p'")
14:10 <@jrandom> Derek Eddington had some posts along those lines in september - http://dev.i2p.net/pipermail/i2p/2004-September/000432.html
14:10 < bens> frosk.orion.i2p
14:10 <@jrandom> smtp.frosk.ns.orion.i2p
14:11 * jrandom starts building uucp bang paths
14:11 < frosk> hah
14:12 < susi23> ok, what now... how about a "naming roadmap"? :)
14:12 < ant> <Jnymo> you guys have swayed me away from an absolute distributed dns for i2p.. somewhat.. but ducks ideas started me thinking that a trust system might work.. like, a lookup could bring back a list of sites/files, and each could be listed with the amount of trust that the network gives it
14:12 < susi23> once we agreed what to do
14:12 <@jrandom> thats a good idea susi23, wanna write one up?
14:13 <@jrandom> trusting other people's trust has potential, but needs to be done very carefully
14:13 < susi23> I could do this, but I still have no idea WHAT we want to do. There are some decisions to make.
14:14 <@jrandom> (aka only according to the terms that you trust the peers along the chain to the trust author)
14:14 < modulus> there is or there should not be a "network trust" of a site, trust has to be user-centric always
14:14 <@jrandom> susi23: roadmap step 1: decide among $featureset
14:14 < susi23> Or at least we have to develop all ideas into a more precise concept.
14:14 < ant> <Jnymo> well, if it was explicitly simple.. like, if files i2p listed how many sites linked to siteinquestion.i2p
14:15 < Ragnarok> ok, the I've updated the addressbook package with an executable jar.
14:15 < ant> <Jnymo> er, files.i2p
14:15 <@jrandom> jnymo: that turns into a centralized authority - files.i2p
14:15 < modulus> not to say that you could poison the pool of links by establishing a shitload of sites.
14:16 < modulus> googlebombing on i2p
14:16 < ant> <Jnymo> true.. but files i2p could be decentralized
14:16 < susi23> ok, how about collection ideas/information/concepts until, lets say january
14:16 < orion> 'lo all. I see naming is on the table.. *again* :)
14:16 < susi23> then comes the decision phase, ok?
14:16 <@jrandom> sounds good - will you be the point of contact to gather that together?
14:16 < Ragnarok> sure
14:16 < modulus> doesn't matter if the trust aggregate is descentralized, trust has to emanate from the user. anything else can be poisoned imo.
14:17 < susi23> can't we take the mailinglist for this?
14:17 < bob> or perhaps ugha's wiki?
14:17 < ant> <Jnymo> agreed.. but what how to do that? put a little trust meter bar at the top of the web browser?
14:18 <@jrandom> the wiki would be good, we can gather links to all the previous discussions there
14:18 < modulus> jnyo: probably the most feasible solution is to bind to the first name encountered or something.
14:18 < dm> let's all give a hand of applause to jrandom for his wonderful project management
14:18 < susi23> fine
14:18 < modulus> but there are more ways than sausages.
14:19 < susi23> url to the wiki? (for the records)
14:19 < ant> * Jnymo claps
14:19 <@jrandom> ugha.i2p
14:19 * dm claps
14:19 < susi23> ok
14:19 < susi23> then I'm done and ping jrandom back ;)
14:20 < ant> <Jnymo> modulus: so, if i refer a link to someone else, i'm refering them to the site i first binded to.. that might work..
14:20 <+ugha2p> Looks like jrandom has ping timeouted.
14:20 <@jrandom> ok cool, anything else on nami^W nm, no more on naming. on to the wiki
14:20 < modulus> anyway, if you're linking you'll probably want to put an absolute path in the link, not just a name
14:21 <@jrandom> moving forward to 4) eepsite roundup
14:21 < dm> dm.i2p is up and running
14:21 <@jrandom> cool
14:22 <@jrandom> ok, i dont really have much to add beyond whats mentioned in the mail
14:22 < bob> nice to see an influx of sites! all speedy to access as well!
14:22 <@jrandom> aye, agreed bob
14:22 < bob> orion, thanks for your work.. I use your site daily.
14:22 * jrandom too, the 'last updated' is especially helpful
14:23 < bob> dm: :-)
14:24 <@jrandom> ok, if there's nothing more on that, we can jump to 5) ???
14:24 <@jrandom> is there anything else people want to bring up for the meeting?
14:24 < ant> <Jnymo> hows the net status?
14:24 < ant> <Jnymo> wrt 4.2.5?
14:25 <@jrandom> its looking good, but the release is only a few hours old, so too soon to tell
14:25 < ant> <Jnymo> oh, heh
14:25 < ant> <Jnymo> any fusenet news?
14:26 <@jrandom> (http://piespy.i2p/i2p/i2p-current.png heh)
14:26 < frosk> my work on i2pcontent has been largely put aside for some weeks, but the latest version of the document can be read at http://frosk.i2p/i2pcontent.html . if anyone is interested, do read, and do comment harshly if needs be (om irc when i'm not /away or mail to frosk@mail.i2p)
14:26 < frosk> i2pcontent/fusenet/anything ;)
14:26 < ant> <Jnymo> wordicus
14:28 <@jrandom> ok, if there's nothing else...
14:28 < mule2> tons of applause for all the excellent contributions
14:29 <@jrandom> aye, y'all are doing some kickass shit
14:29 < frosk> you too, jrandom :)
14:29 < orion> word.
14:29 < orion> yes, very much so, you too jrandom.
14:29 < scintilla> hear hear!
14:29 < ant> <Jnymo> yea, i noticed on the site, theres less info on how to help out
14:29 <@jrandom> sometimes kickass, sometimes ass kicked ;)
14:29 < orion> HIP HIP
14:30 < ant> <Jnymo> HORRAY
14:30 * orion smiles
14:30 < Frooze> downloaded eclipse today, to learn java over holiday, because y'all are so impressive.
14:30 <@jrandom> jnymo: many of the small easy-to-accomplish tasks have been done
14:30 <@jrandom> ooh wikked Frooze
14:31 < Frooze> so, trouble on horizon. heh
14:31 <@jrandom> jnymo: i really should collect some more of them though and post 'em
14:31 < ant> <Jnymo> jrandom: You still looking for someone to help out on alexandria.i2p?
14:31 <@jrandom> (take cover arizona!)
14:31 * jrandom is not involved in alexandria, but yes, i believe they are still looking for a librarian
14:31 < ant> <Jnymo> learn to swim, folks ;)
14:31 * orion loves pump up the volume references. Vague though they may be.
14:31 <@duck> yes we do
14:31 <@jrandom> :)
14:31 < Ragnarok> jrandom: where is the war actually supposed to go?
14:31 <@jrandom> (orion++)
14:32 <@jrandom> Ragnarok: i2p/webapps/addressbook.war
14:32 <@jrandom> (then restart the router)
14:32 < ant> <Jnymo> duck, you talkint to me?
14:32 < Ragnarok> cool. I shall commence testing
14:32 <@jrandom> r0x0r
14:32 < ant> <Jnymo> duck: is alexandria on your site?
14:33 <@duck> duck.i2p/alexandria/
14:33 < ant> <Jnymo> word
14:34 <@jrandom> ok, if thats all, we can slide out of here @ the 90m mark..
14:34 * jrandom winds up
14:34 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/121.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, December 21, 2004
==================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,201 +1,195 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 122{% endblock %}
{% block content %}<h3>I2P dev meeting, December 28, 2004</h3>
<div class="irclog">
13:06 <@jrandom> 0) hi</p>
13:06 <@jrandom> 1) 0.4.2.5</p>
13:06 <@jrandom> 2) 0.5</p>
13:06 <@jrandom> 3) ???</p>
13:06 <@jrandom> 0) hi</p>
13:06 * jrandom waves</p>
13:06 <+postman> *wave*</p>
13:06 < ant> &lt;jnymo&gt; hello</p>
13:06 <@jrandom> brief status notes posted up @ http://dev.i2p.net/pipermail/i2p/2004-December/000535.html</p>
13:07 <@jrandom> jumping in to 1) 0.4.2.5</p>
13:07 <@jrandom> as mentioned, things are pretty much working</p>
13:08 <+postman> yeah, quite impressive</p>
13:08 <+postman> no more lease timouts on my systems at all</p>
13:08 <@jrandom> a lot of people have seen what you've seen jnymo, with 0 participating tunnels, largely in part to the increased efficiency & peer selection (where we now know to leech off postman's machine ;)</p>
13:08 < ant> &lt;jnymo&gt; me too</p>
13:08 <@jrandom> nice</p>
13:08 < ant> &lt;jnymo&gt; and eepsites are snappy</p>
13:09 <+postman> :)</p>
13:09 < ant> &lt;jnymo&gt; thanks postman :)</p>
13:09 <+postman> totsl bw is 29kb / 30.1kb/s</p>
13:09 < frosk> everybody feels less loved, but in reality the love is just being put more efficiently to work</p>
13:10 < ant> &lt;jnymo&gt; wow</p>
13:10 <@jrandom> b1tchin postman </p>
13:10 < mule2> i don't think that is the preferred ideal. we'd better have some traffic through all nodes</p>
13:10 < ant> &lt;jnymo&gt; i could handle that if people just loved me :(</p>
13:10 <+postman> yep</p>
13:10 < mule2> as kind of cover traffic</p>
13:10 <@jrandom> mule2: its a matter of our load being much less than our network capacity</p>
13:11 <@jrandom> i dont think we'll be able to keep the capacity greater than the load for long</p>
13:11 < ant> &lt;jnymo&gt; mule2, postman is also act as i mixer.. so its hard to tell where you packets are going after they go in</p>
13:11 <@jrandom> so i'm not too worried about not pushing any data through slower peers</p>
13:12 < mule2> probably less perfect optimization would be good for anonymity</p>
13:12 <@jrandom> otoh, it also gives incentive for more people to (implement &) use i2pcontent, so they can mirror as well as gain cover traffic ;)</p>
13:12 < jdot__> i it a security issue that one router handles all(ish) tunnels?</p>
13:13 <@jrandom> mule2: lets first get it as good as we can get it, then we can discuss proactively making it worse</p>
13:13 <@jrandom> jdot__: we don't have one router handling all of the traffic, but we are seeing the grouping of routers who are on very fast connections (colo, etc) handling more than dialup/dsl/cable users</p>
13:14 <@jrandom> plus the reduced tunnel failures means we're shifting & exploring less</p>
13:14 < mule2> perhaps some traffic distribution would be possible, as long as we are far from the routers limits</p>
13:14 <@jrandom> right, probabalistic tunnel rejection is in the router and can be enabled based on the router's bandwidth limits</p>
13:15 < ant> &lt;jnymo&gt; yea, but such high throughput on postman's node makes it harder to analyze his node.. so it might be safer to send through him than for all nodes to do one KBs..</p>
13:15 <@jrandom> (but if postman doesnt set any limits, we can't reject based on a % of that ;)</p>
13:15 < ant> &lt;jnymo&gt; groupings of faster nodes cause something of a mix cascade structure, no?</p>
13:15 <@jrandom> aye, that is one way to look at it</p>
13:15 < lektriK> can I close the Start I2P window?</p>
13:15 * postman is very sorry NOT to restrict his bandwidth</p>
13:16 <@jrandom> lektriK: unfortunately, not really, unless you start i2p as a service (See http://localhost:7657/configservice.jsp)</p>
13:16 <@jrandom> heh postman dont worry, we'll back off your router if/when we reach your router's capacity</p>
13:17 < lektriK> Ok, it sais service started</p>
13:17 < lektriK> can I close it now?</p>
13:17 <@jrandom> lektriK: no/yes - you can shut down your router then start it again via start-&gt;run-&gt;"net start i2p"</p>
13:18 < mule2> as it is, a few very big routers could handle all the tunnels, removing all cover traffic from all other routers. but lets continue with that after the meeting.</p>
13:18 < mule2> don't want to complain about the network behaving to good :)</p>
13:18 <@jrandom> hehe</p>
13:20 <@jrandom> some further exploration will occur with 0.5, though there are anonymity related issues with spreading too far. there'll be further details to be worked through on that for 0.5 though (and in the doc which might be ready next week as a first draft)</p>
13:21 <@jrandom> anyway, anyone else have something to bring up for 0.4.2.5? </p>
13:21 <@jrandom> or shall we move on briefly to 2) 0.5?</p>
13:21 <+postman> move</p>
13:21 < ant> &lt;jnymo&gt; very stable... move</p>
13:21 <@jrandom> consider us moved</p>
13:22 <@jrandom> 2) 0.5</p>
13:22 <@jrandom> yeah. still work in progress. more info when its ready.</p>
13:22 < ant> &lt;Quadn-werk&gt; Sir Arthur C. Clarke is alive :P</p>
13:22 < ant> &lt;Quadn-werk&gt; http://slashdot.org/articles/04/12/28/0120240.shtml?tid=99&tid=1</p>
13:22 < ant> &lt;jnymo&gt; .5 is exciting</p>
13:22 <@jrandom> ok, thats all i have to say on that - anyone have any questions / things to discuss about it?</p>
13:23 <@jrandom> aye, there are definitely some important revamping going on, based on what we've learned over the last 16 months</p>
13:23 <@jrandom> (or shit, 18)</p>
13:23 <+postman> jrandom: so 0.5 will emnploy a new tunnel management system mostly?</p>
13:23 < ant> &lt;Quadn-werk&gt; arg, i hope i didnt interrupt the meeting :/</p>
13:23 <+postman> wow</p>
13:23 < ant> &lt;Quadn-werk&gt; sorry heh</p>
13:23 < ant> &lt;jnymo&gt; heh. i had a suggestion</p>
13:24 <@jrandom> yeah postman, new management, pooling, and building</p>
13:24 <+postman> quadn: look what you've done - your paste caused a netsplit :)</p>
13:24 <@jrandom> you bastard!</p>
13:24 < ant> &lt;Quadn-werk&gt; !</p>
13:24 <@jrandom> sup jnymo?</p>
13:24 <+postman> jrandom: will every tunnel be a separate local destination still?</p>
13:25 <@jrandom> huzzawuzzah?</p>
13:25 <@jrandom> there won't be any change to i2ptunnel in 0.5</p>
13:25 <+postman> jrandom: ok</p>
13:25 <@jrandom> (at least, i dont plan on any)</p>
13:26 < mule> postman mounting an intersection attack?</p>
13:26 < ant> &lt;jnymo&gt; for those who aren't getting /any/ bandwidth usage.. how bout letting routers build tunnels with them in it.. like ABCABCA</p>
13:26 <+postman> mule: no, it was quadn's fault :)</p>
13:26 < ant> &lt;jnymo&gt; and that would be a dummy tunnel</p>
13:27 <@jrandom> jnymo: advertising a router as saying "hey i have excess bandwidth, use me" is a dangerous game</p>
13:27 <+postman> jrandom: what issues will then be addressed by the redesign ( in a nutshell )</p>
13:27 < ant> &lt;jnymo&gt; not sure i meant that, jrandom</p>
13:27 <@jrandom> but what it looks like now is that we'll have two sets of tunnels - the normal ones, and then exploratory ones, where the later are built from randomly selected non-failing peers</p>
13:28 < ant> &lt;jnymo&gt; jrandom: i meant creating a dummy tunnel, and putting my self in the middle of that tunnel just to simulate some traffic</p>
13:29 <@jrandom> postman: making it much harder to correllate peers in a tunnel, allowing clients to effectively choose their outbound tunnel length, and providing the options necessary for addressing the predecessor attack (with various tradeoffs)</p>
13:29 <@jrandom> (oh, and improving performance by getting rid of a lot of modPow calls)</p>
13:29 <+postman> ok thanks</p>
13:29 < ant> &lt;jnymo&gt; postman: and per hop tunnel ids is a big one</p>
13:30 <+postman> modpow?</p>
13:30 <@jrandom> ah jnymo. yeah, there's a lot of potential for various chaff traffic generation</p>
13:30 < ant> &lt;jnymo&gt; that way, no two non-neighboring nodes can know there on the same tunnel, postman</p>
13:30 <@jrandom> postman: modular exponentiation, heavy cpu usage & memory waste</p>
13:31 < ant> &lt;jnymo&gt; jrandom: k cool</p>
13:31 <+postman> k</p>
13:31 < scintilla> jrandom, wrt to letting clients choose tunnel length: will there be anything in place to keep ppl from cranking it up to 99 (or whatever)?</p>
13:31 < ant> &lt;jnymo&gt; cpu power</p>
13:32 <@jrandom> when necessary we can add hashcash, but excessively long tunnels will just end up failing anyway</p>
13:32 < scintilla> ah good point</p>
13:32 <@jrandom> we could even add in some trickery - requiring that a tunnel have a valid tunnel message pumped through it within 60s of creation for it to be 'valid'</p>
13:33 <@jrandom> (so if the tunnel was 20 hops long, it'd take them too long to build all those hops)</p>
13:33 < scintilla> that's a great idea - that'll keep any such ridiculousness from lingering for very long</p>
13:33 <@jrandom> but thats all vs the hackers. normal users will just use the exposed interface</p>
13:34 < ant> &lt;jnymo&gt; right, which you'll cap off somewhere right?</p>
13:34 < ant> &lt;jnymo&gt; we'll get higher than the maximum 2 as it is now, right?</p>
13:34 <@jrandom> right, like the # hops drop down on /configclients.jsp or /i2ptunnel/edit.jsp</p>
13:35 <@jrandom> oh i thought the max was 3 now? ok, but yeah, higher than 2 will be available</p>
13:35 < ant> &lt;jnymo&gt; 3 tunnels, 2 hops</p>
13:35 <@jrandom> ah 'k</p>
13:35 <@jrandom> yeah, 0.5 will add in some important new tweaks, such as whether to randomize those lengths, as well as how much to randomize, etc</p>
13:36 < frosk> the max is indeed 3</p>
13:36 < ant> &lt;jnymo&gt; hmm</p>
13:37 <@jrandom> ah its 3 on /configclients 2 on i2ptunnel</p>
13:37 < frosk> is 0.5 still on track for january?</p>
13:37 < ant> &lt;jnymo&gt; ah</p>
13:37 <@jrandom> yeah frosk</p>
13:37 < frosk> goodie</p>
13:37 <@jrandom> i wont dawdle too much longer on the streaming lib, i promise ;)</p>
13:37 < frosk> it just sounds like a lot of work :)</p>
13:38 <@jrandom> its actually not so bad, the hard part is getting the algorithms right</p>
13:38 <@jrandom> (details schmetails ;)</p>
13:39 <+postman> frosk: and it's all on paper already</p>
13:39 <+postman> :)</p>
13:39 < ant> &lt;jnymo&gt; heh</p>
13:39 < frosk> true :)</p>
13:39 <@jrandom> mostly yeah ;)</p>
13:39 <@jrandom> ok, anyone have anything else for 2) 0.5?</p>
13:39 < ant> &lt;jnymo&gt; nada</p>
13:39 < frosk> el zilcho</p>
13:40 <@jrandom> 'k, swingin on to good old fashioned 3) ???</p>
13:40 <@jrandom> hi</p>
13:40 <@jrandom> anyone have anything else they want to bring up?</p>
13:41 < ant> &lt;jnymo&gt; postman: there arent smtp/pop3 inproxies on i2pmail.org are there?</p>
13:41 < cat-a-puss> I am still seeing weird delays on the client end...</p>
13:41 <+postman> hrm no</p>
13:41 < frosk> this is where i'd hand over the congratulatory bottle of wine for a fine year of development ;)</p>
13:41 <+postman> jnymo: POP3 is only available for i2p users</p>
13:41 <@jrandom> cat-a-puss: ah i missed those messages when you were around earlier</p>
13:41 <+postman> jnymo: there IS a SMTP inproxy as MX for the domain i2pmail.org</p>
13:42 <@jrandom> frosk: cheers</p>
13:42 < ant> &lt;jnymo&gt; right right.. that's coo'..</p>
13:42 < cat-a-puss> Like I can have two local Destinations and when one trys to connect to another there is a delay and it is not CPU bound</p>
13:42 < mule> cat-a-puss: do you also hand over the bonus cheque ?</p>
13:42 * postman donates a good whiskey </p>
13:42 <@jrandom> cat-a-puss: right, you saw a .5-1.0s delay right?</p>
13:42 < cat-a-puss> mule: what?</p>
13:42 < cat-a-puss> jrandom: yeah</p>
13:43 <@jrandom> cat-a-puss: perfectly normal, part of the deferred syn</p>
13:43 < mule> sorry, the comment was from frosk</p>
13:43 < ant> * jnymo pulles out that crappy box wine</p>
13:43 < mule> frosk: do you also hand over the bonus cheque ?</p>
13:43 <@jrandom> (it waits a bit to send the SYN and the related ACK in case there is more data to bundle)</p>
13:43 < scintilla> oh fyi, i should be receiving the book with the fortuna algorithm spec in it soon... in the meantime i've been experimenting with trying to gather entropy in java without destroying a machine</p>
13:44 <@jrandom> ah kickass</p>
13:44 < ant> &lt;jnymo&gt; mmm, someone was wanting to mount some attacks on i2p</p>
13:44 < ant> &lt;jnymo&gt; who was that?</p>
13:44 <@jrandom> connelly</p>
13:44 < cat-a-puss> Is there a way to prevent that, or do I just have to try to avoid short lived connections where I can?</p>
13:45 < ant> &lt;jnymo&gt; any word on that, jr?</p>
13:45 <@jrandom> cat-a-puss: yeah there are some options you can pass when creating the I2PSocketManager, lemmie pull 'em up</p>
13:46 <@jrandom> jnymo: its a long term intersection attack, so after a while he'll have data to help identify what routers particular eepsites are on. i'm sure he's going to write up some summary data for us once he's got it</p>
13:46 < ant> &lt;jnymo&gt; scintalla: what's the fortuna algorithm?</p>
13:46 < ant> &lt;jnymo&gt; jrandom: aight</p>
13:48 <@jrandom> cat-a-puss: i2p.streaming.initialResendDelay=50 i2p.streaming.connectDelay=100</p>
13:48 < scintilla> it's a cryptographically secure pseudo-random number generator... something which is absolutely essential for trustworthy encryption</p>
13:48 < jdot__> anyone volunteer for that attack yet?</p>
13:48 <@jrandom> cat-a-puss: then be sure to flush() after write()ing to the I2PSocket</p>
13:48 <@jrandom> jdot__: yeah, he has 7 volutneered sites</p>
13:48 < cat-a-puss> jrandom: ok</p>
13:49 < ant> &lt;jnymo&gt; wrt the great naming debate.. </p>
13:49 < ant> * jnymo snickers</p>
13:49 <@jrandom> oh and i2p.streaming.initialAckDelay=1000</p>
13:49 <@jrandom> or even =100</p>
13:49 * jrandom flings mud at jnymo</p>
13:50 < ant> &lt;jnymo&gt; i actually do work with x500 and my job lets me have free winSevers</p>
13:50 < ant> &lt;jnymo&gt; so, perhaps i'll just set up a central DNS for testing purposes in a month or two</p>
13:51 <@jrandom> heh, having a centralized naming server hosted on a .mil would be bloody hilarious </p>
13:51 < ant> &lt;jnymo&gt; though hacking i2p addresses into winserver may be non-trivial.. dunno</p>
13:51 < ant> &lt;jnymo&gt; heh.. dnsalias is the ticket</p>
13:52 <@jrandom> nano has done some really cool work, integrating dnsjava with i2p</p>
13:52 < ant> &lt;jnymo&gt; ooooh</p>
13:53 <@jrandom> check out nano.i2p for more details</p>
13:53 < ant> &lt;jnymo&gt; and no one was going to tell me.. ah, thanks</p>
13:53 <@jrandom> but, as mentioned last time, people should post up their thoughts and ideas about naming to the wiki</p>
13:54 <@jrandom> ok, anyone else have something to bring up for the meeting?</p>
13:55 < ant> &lt;jnymo&gt; nope</p>
13:57 <@jrandom> ok in that case</p>
13:57 * jrandom winds up</p>
13:57 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:06 <@jrandom> 0) hi
13:06 <@jrandom> 1) 0.4.2.5
13:06 <@jrandom> 2) 0.5
13:06 <@jrandom> 3) ???
13:06 <@jrandom> 0) hi
13:06 * jrandom waves
13:06 <+postman> *wave*
13:06 < ant> <jnymo> hello
13:06 <@jrandom> brief status notes posted up @ http://dev.i2p.net/pipermail/i2p/2004-December/000535.html
13:07 <@jrandom> jumping in to 1) 0.4.2.5
13:07 <@jrandom> as mentioned, things are pretty much working
13:08 <+postman> yeah, quite impressive
13:08 <+postman> no more lease timouts on my systems at all
13:08 <@jrandom> a lot of people have seen what you've seen jnymo, with 0 participating tunnels, largely in part to the increased efficiency & peer selection (where we now know to leech off postman's machine ;)
13:08 < ant> <jnymo> me too
13:08 <@jrandom> nice
13:08 < ant> <jnymo> and eepsites are snappy
13:09 <+postman> :)
13:09 < ant> <jnymo> thanks postman :)
13:09 <+postman> totsl bw is 29kb / 30.1kb/s
13:09 < frosk> everybody feels less loved, but in reality the love is just being put more efficiently to work
13:10 < ant> <jnymo> wow
13:10 <@jrandom> b1tchin postman
13:10 < mule2> i don't think that is the preferred ideal. we'd better have some traffic through all nodes
13:10 < ant> <jnymo> i could handle that if people just loved me :(
13:10 <+postman> yep
13:10 < mule2> as kind of cover traffic
13:10 <@jrandom> mule2: its a matter of our load being much less than our network capacity
13:11 <@jrandom> i dont think we'll be able to keep the capacity greater than the load for long
13:11 < ant> <jnymo> mule2, postman is also act as i mixer.. so its hard to tell where you packets are going after they go in
13:11 <@jrandom> so i'm not too worried about not pushing any data through slower peers
13:12 < mule2> probably less perfect optimization would be good for anonymity
13:12 <@jrandom> otoh, it also gives incentive for more people to (implement &) use i2pcontent, so they can mirror as well as gain cover traffic ;)
13:12 < jdot__> i it a security issue that one router handles all(ish) tunnels?
13:13 <@jrandom> mule2: lets first get it as good as we can get it, then we can discuss proactively making it worse
13:13 <@jrandom> jdot__: we don't have one router handling all of the traffic, but we are seeing the grouping of routers who are on very fast connections (colo, etc) handling more than dialup/dsl/cable users
13:14 <@jrandom> plus the reduced tunnel failures means we're shifting & exploring less
13:14 < mule2> perhaps some traffic distribution would be possible, as long as we are far from the routers limits
13:14 <@jrandom> right, probabalistic tunnel rejection is in the router and can be enabled based on the router's bandwidth limits
13:15 < ant> <jnymo> yea, but such high throughput on postman's node makes it harder to analyze his node.. so it might be safer to send through him than for all nodes to do one KBs..
13:15 <@jrandom> (but if postman doesnt set any limits, we can't reject based on a % of that ;)
13:15 < ant> <jnymo> groupings of faster nodes cause something of a mix cascade structure, no?
13:15 <@jrandom> aye, that is one way to look at it
13:15 < lektriK> can I close the Start I2P window?
13:15 * postman is very sorry NOT to restrict his bandwidth
13:16 <@jrandom> lektriK: unfortunately, not really, unless you start i2p as a service (See http://localhost:7657/configservice.jsp)
13:16 <@jrandom> heh postman dont worry, we'll back off your router if/when we reach your router's capacity
13:17 < lektriK> Ok, it sais service started
13:17 < lektriK> can I close it now?
13:17 <@jrandom> lektriK: no/yes - you can shut down your router then start it again via start->run->"net start i2p"
13:18 < mule2> as it is, a few very big routers could handle all the tunnels, removing all cover traffic from all other routers. but lets continue with that after the meeting.
13:18 < mule2> don't want to complain about the network behaving to good :)
13:18 <@jrandom> hehe
13:20 <@jrandom> some further exploration will occur with 0.5, though there are anonymity related issues with spreading too far. there'll be further details to be worked through on that for 0.5 though (and in the doc which might be ready next week as a first draft)
13:21 <@jrandom> anyway, anyone else have something to bring up for 0.4.2.5?
13:21 <@jrandom> or shall we move on briefly to 2) 0.5?
13:21 <+postman> move
13:21 < ant> <jnymo> very stable... move
13:21 <@jrandom> consider us moved
13:22 <@jrandom> 2) 0.5
13:22 <@jrandom> yeah. still work in progress. more info when its ready.
13:22 < ant> <Quadn-werk> Sir Arthur C. Clarke is alive :P
13:22 < ant> <Quadn-werk> http://slashdot.org/articles/04/12/28/0120240.shtml?tid=99&tid=1
13:22 < ant> <jnymo> .5 is exciting
13:22 <@jrandom> ok, thats all i have to say on that - anyone have any questions / things to discuss about it?
13:23 <@jrandom> aye, there are definitely some important revamping going on, based on what we've learned over the last 16 months
13:23 <@jrandom> (or shit, 18)
13:23 <+postman> jrandom: so 0.5 will emnploy a new tunnel management system mostly?
13:23 < ant> <Quadn-werk> arg, i hope i didnt interrupt the meeting :/
13:23 <+postman> wow
13:23 < ant> <Quadn-werk> sorry heh
13:23 < ant> <jnymo> heh. i had a suggestion
13:24 <@jrandom> yeah postman, new management, pooling, and building
13:24 <+postman> quadn: look what you've done - your paste caused a netsplit :)
13:24 <@jrandom> you bastard!
13:24 < ant> <Quadn-werk> !
13:24 <@jrandom> sup jnymo?
13:24 <+postman> jrandom: will every tunnel be a separate local destination still?
13:25 <@jrandom> huzzawuzzah?
13:25 <@jrandom> there won't be any change to i2ptunnel in 0.5
13:25 <+postman> jrandom: ok
13:25 <@jrandom> (at least, i dont plan on any)
13:26 < mule> postman mounting an intersection attack?
13:26 < ant> <jnymo> for those who aren't getting /any/ bandwidth usage.. how bout letting routers build tunnels with them in it.. like ABCABCA
13:26 <+postman> mule: no, it was quadn's fault :)
13:26 < ant> <jnymo> and that would be a dummy tunnel
13:27 <@jrandom> jnymo: advertising a router as saying "hey i have excess bandwidth, use me" is a dangerous game
13:27 <+postman> jrandom: what issues will then be addressed by the redesign ( in a nutshell )
13:27 < ant> <jnymo> not sure i meant that, jrandom
13:27 <@jrandom> but what it looks like now is that we'll have two sets of tunnels - the normal ones, and then exploratory ones, where the later are built from randomly selected non-failing peers
13:28 < ant> <jnymo> jrandom: i meant creating a dummy tunnel, and putting my self in the middle of that tunnel just to simulate some traffic
13:29 <@jrandom> postman: making it much harder to correllate peers in a tunnel, allowing clients to effectively choose their outbound tunnel length, and providing the options necessary for addressing the predecessor attack (with various tradeoffs)
13:29 <@jrandom> (oh, and improving performance by getting rid of a lot of modPow calls)
13:29 <+postman> ok thanks
13:29 < ant> <jnymo> postman: and per hop tunnel ids is a big one
13:30 <+postman> modpow?
13:30 <@jrandom> ah jnymo. yeah, there's a lot of potential for various chaff traffic generation
13:30 < ant> <jnymo> that way, no two non-neighboring nodes can know there on the same tunnel, postman
13:30 <@jrandom> postman: modular exponentiation, heavy cpu usage & memory waste
13:31 < ant> <jnymo> jrandom: k cool
13:31 <+postman> k
13:31 < scintilla> jrandom, wrt to letting clients choose tunnel length: will there be anything in place to keep ppl from cranking it up to 99 (or whatever)?
13:31 < ant> <jnymo> cpu power
13:32 <@jrandom> when necessary we can add hashcash, but excessively long tunnels will just end up failing anyway
13:32 < scintilla> ah good point
13:32 <@jrandom> we could even add in some trickery - requiring that a tunnel have a valid tunnel message pumped through it within 60s of creation for it to be 'valid'
13:33 <@jrandom> (so if the tunnel was 20 hops long, it'd take them too long to build all those hops)
13:33 < scintilla> that's a great idea - that'll keep any such ridiculousness from lingering for very long
13:33 <@jrandom> but thats all vs the hackers. normal users will just use the exposed interface
13:34 < ant> <jnymo> right, which you'll cap off somewhere right?
13:34 < ant> <jnymo> we'll get higher than the maximum 2 as it is now, right?
13:34 <@jrandom> right, like the # hops drop down on /configclients.jsp or /i2ptunnel/edit.jsp
13:35 <@jrandom> oh i thought the max was 3 now? ok, but yeah, higher than 2 will be available
13:35 < ant> <jnymo> 3 tunnels, 2 hops
13:35 <@jrandom> ah 'k
13:35 <@jrandom> yeah, 0.5 will add in some important new tweaks, such as whether to randomize those lengths, as well as how much to randomize, etc
13:36 < frosk> the max is indeed 3
13:36 < ant> <jnymo> hmm
13:37 <@jrandom> ah its 3 on /configclients 2 on i2ptunnel
13:37 < frosk> is 0.5 still on track for january?
13:37 < ant> <jnymo> ah
13:37 <@jrandom> yeah frosk
13:37 < frosk> goodie
13:37 <@jrandom> i wont dawdle too much longer on the streaming lib, i promise ;)
13:37 < frosk> it just sounds like a lot of work :)
13:38 <@jrandom> its actually not so bad, the hard part is getting the algorithms right
13:38 <@jrandom> (details schmetails ;)
13:39 <+postman> frosk: and it's all on paper already
13:39 <+postman> :)
13:39 < ant> <jnymo> heh
13:39 < frosk> true :)
13:39 <@jrandom> mostly yeah ;)
13:39 <@jrandom> ok, anyone have anything else for 2) 0.5?
13:39 < ant> <jnymo> nada
13:39 < frosk> el zilcho
13:40 <@jrandom> 'k, swingin on to good old fashioned 3) ???
13:40 <@jrandom> hi
13:40 <@jrandom> anyone have anything else they want to bring up?
13:41 < ant> <jnymo> postman: there arent smtp/pop3 inproxies on i2pmail.org are there?
13:41 < cat-a-puss> I am still seeing weird delays on the client end...
13:41 <+postman> hrm no
13:41 < frosk> this is where i'd hand over the congratulatory bottle of wine for a fine year of development ;)
13:41 <+postman> jnymo: POP3 is only available for i2p users
13:41 <@jrandom> cat-a-puss: ah i missed those messages when you were around earlier
13:41 <+postman> jnymo: there IS a SMTP inproxy as MX for the domain i2pmail.org
13:42 <@jrandom> frosk: cheers
13:42 < ant> <jnymo> right right.. that's coo'..
13:42 < cat-a-puss> Like I can have two local Destinations and when one trys to connect to another there is a delay and it is not CPU bound
13:42 < mule> cat-a-puss: do you also hand over the bonus cheque ?
13:42 * postman donates a good whiskey
13:42 <@jrandom> cat-a-puss: right, you saw a .5-1.0s delay right?
13:42 < cat-a-puss> mule: what?
13:42 < cat-a-puss> jrandom: yeah
13:43 <@jrandom> cat-a-puss: perfectly normal, part of the deferred syn
13:43 < mule> sorry, the comment was from frosk
13:43 < ant> * jnymo pulles out that crappy box wine
13:43 < mule> frosk: do you also hand over the bonus cheque ?
13:43 <@jrandom> (it waits a bit to send the SYN and the related ACK in case there is more data to bundle)
13:43 < scintilla> oh fyi, i should be receiving the book with the fortuna algorithm spec in it soon... in the meantime i've been experimenting with trying to gather entropy in java without destroying a machine
13:44 <@jrandom> ah kickass
13:44 < ant> <jnymo> mmm, someone was wanting to mount some attacks on i2p
13:44 < ant> <jnymo> who was that?
13:44 <@jrandom> connelly
13:44 < cat-a-puss> Is there a way to prevent that, or do I just have to try to avoid short lived connections where I can?
13:45 < ant> <jnymo> any word on that, jr?
13:45 <@jrandom> cat-a-puss: yeah there are some options you can pass when creating the I2PSocketManager, lemmie pull 'em up
13:46 <@jrandom> jnymo: its a long term intersection attack, so after a while he'll have data to help identify what routers particular eepsites are on. i'm sure he's going to write up some summary data for us once he's got it
13:46 < ant> <jnymo> scintalla: what's the fortuna algorithm?
13:46 < ant> <jnymo> jrandom: aight
13:48 <@jrandom> cat-a-puss: i2p.streaming.initialResendDelay=50 i2p.streaming.connectDelay=100
13:48 < scintilla> it's a cryptographically secure pseudo-random number generator... something which is absolutely essential for trustworthy encryption
13:48 < jdot__> anyone volunteer for that attack yet?
13:48 <@jrandom> cat-a-puss: then be sure to flush() after write()ing to the I2PSocket
13:48 <@jrandom> jdot__: yeah, he has 7 volutneered sites
13:48 < cat-a-puss> jrandom: ok
13:49 < ant> <jnymo> wrt the great naming debate..
13:49 < ant> * jnymo snickers
13:49 <@jrandom> oh and i2p.streaming.initialAckDelay=1000
13:49 <@jrandom> or even =100
13:49 * jrandom flings mud at jnymo
13:50 < ant> <jnymo> i actually do work with x500 and my job lets me have free winSevers
13:50 < ant> <jnymo> so, perhaps i'll just set up a central DNS for testing purposes in a month or two
13:51 <@jrandom> heh, having a centralized naming server hosted on a .mil would be bloody hilarious
13:51 < ant> <jnymo> though hacking i2p addresses into winserver may be non-trivial.. dunno
13:51 < ant> <jnymo> heh.. dnsalias is the ticket
13:52 <@jrandom> nano has done some really cool work, integrating dnsjava with i2p
13:52 < ant> <jnymo> ooooh
13:53 <@jrandom> check out nano.i2p for more details
13:53 < ant> <jnymo> and no one was going to tell me.. ah, thanks
13:53 <@jrandom> but, as mentioned last time, people should post up their thoughts and ideas about naming to the wiki
13:54 <@jrandom> ok, anyone else have something to bring up for the meeting?
13:55 < ant> <jnymo> nope
13:57 <@jrandom> ok in that case
13:57 * jrandom winds up
13:57 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/122.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, December 28, 2004
==================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,160 +1,154 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 123{% endblock %}
{% block content %}<h3>I2P dev meeting, January 4, 2005</h3>
<div class="irclog">
13:09 <@jrandom> 0) hi</p>
13:09 <@jrandom> 1) Net status</p>
13:09 <@jrandom> 2) 0.4.2.6</p>
13:09 < ant> &lt;DrVince&gt; It says that it can't find tools.jar but doesn't stop</p>
13:10 <@jrandom> 3) 0.5</p>
13:10 <@jrandom> 4) jabber @ chat.i2p</p>
13:10 <@jrandom> 5) ???</p>
13:10 <@jrandom> 0) hi</p>
13:10 * jrandom waves</p>
13:10 < eco> hi</p>
13:10 <@jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-January/000541.html</p>
13:10 <@jrandom> DrVince: if you can hang around, we can hack through that after the meeting</p>
13:10 < ant> &lt;DrVince&gt; Cool</p>
13:11 <@jrandom> jumping on into 1) Net status</p>
13:11 <@jrandom> (as i'm sure y'all have read the weekly status notes already *cough*)</p>
13:11 <@jrandom> basically, the net seems to be working well</p>
13:11 <@jrandom> we still do have more irc disconnects than usual though, but not a horrid amount</p>
13:12 <@jrandom> hopefully the next release (with the streaming lib improvements) will help out, as will further load balancing off duck's server</p>
13:12 <@jrandom> (since remember, every message we send to any irc channel is sent to the irc server and echoed out again several times)</p>
13:13 <+protokol> yeah</p>
13:13 <@jrandom> a fully distributed chat system would be neat, but i'm not holding my breath. plus, irc works good enough</p>
13:14 <@jrandom> ok, thats all i have wrt 1) net status</p>
13:14 <@jrandom> does anyone have anything to add, comment, etc?</p>
13:14 * eco has been away for a while (what's new)</p>
13:15 < eco> and was happily surprised by the state of things. very good progress</p>
13:15 < Myo9> Wasn't the meeting at 10?</p>
13:15 < eco> both performance and usability wise</p>
13:15 < eco> Myo9 10GMT (general meeting time)</p>
13:16 <@jrandom> 9p GMT</p>
13:16 <@jrandom> the last year has definitely brought a lot of progress</p>
13:17 * eco hands out cookies to all devs and then shuts up</p>
13:17 <@jrandom> *munch*</p>
13:17 <@jrandom> ok, jumping on to 2) 0.4.2.6</p>
13:18 <@jrandom> new release coming with bugfixes, improvements, and the addressbook bundled in</p>
13:18 <@jrandom> i dont know exactly when it'll be out, maybe end of the week</p>
13:18 <@jrandom> it'll be announced on the list and in the channels, of course</p>
13:19 <@jrandom> thats all i have to say on that - anyone have any questions/comments/concerns wrt 0.4.2.6?</p>
13:19 * eco recalls someone mentioning Debian packages</p>
13:20 <@jrandom> os/distro-specific packaging is probably premature at the moment</p>
13:20 < eco> Burton is willing to give that a try, but that won't be this week i guess</p>
13:20 <@jrandom> ah cool, i hadn't heard that</p>
13:21 < eco> agree, though it would be handy</p>
13:21 <+protokol> hold on, im pretty high</p>
13:21 <+protokol> oops</p>
13:21 <+protokol> that was supposed to be a PM</p>
13:21 <@jrandom> distro-specific packaging will be nice, but we probably need to have the auto-updater in place for that to be viable</p>
13:21 <+protokol> i can look into making an ebuild</p>
13:21 <@jrandom> protokol: if you're nice, i'll cut that out of the logs ;)</p>
13:21 <+protokol> no guarentees</p>
13:21 <+protokol> lol</p>
13:22 <@jrandom> yeah, i wouldn't worry about packages until 0.5, if not 1.0</p>
13:22 <@jrandom> (i hope to have the auto-updater in 0.5)</p>
13:22 <+protokol> awesomecore</p>
13:23 <@jrandom> actually, if someone wants to work on the updater, that'd be a pretty kick-ass low-hanging-fruit. just write a servlet to download and verify from dev.i2p/i2p/i2pupdate.zip, then call the router's restart method</p>
13:23 < Myo9> Auto-updater, sounds like a threat.</p>
13:23 <+protokol> modulus: welsome</p>
13:23 <+protokol> $200 bounty for it</p>
13:24 <@jrandom> heh true myo9, the update would want to allow both manual controls (one click update) and would want to verify a signature on the update</p>
13:24 < ant> * DrVince had a problem with i2pupdate.zip</p>
13:24 < ant> &lt;cervantes&gt; something that can be enabled or disabled would be nice ;)</p>
13:24 * protokol makes it offical</p>
13:24 < Myo9> So, all of a sudden, the router restarts and one notices Jr. has teamed with the IP ppl and DRM is enabled.</p>
13:24 <@jrandom> protokol: oh cool, send in the $200 and i'll add that to the bounty page </p>
13:24 < Myo9> ;)</p>
13:24 < Myo9> I want auto-update turned off by default.</p>
13:24 <@jrandom> agreed myo9</p>
13:25 < ant> &lt;cervantes&gt; perhaps the routerconsole can be ammended to notify if a new version is available</p>
13:25 <@jrandom> right cervantes</p>
13:25 < Myo9> Great!</p>
13:25 <@jrandom> it would want to display whether there is a new release, and give the user a one click option to upgrade</p>
13:25 <@jrandom> (it'd be easy enough to add a web page @ www.i2p/ that contains the current version, so the router could check that periodically)</p>
13:26 <@jrandom> ((or on demand))</p>
13:26 < Hybrid> yes jrandom. that would be cool. also on the button a link to 'whats new' html page</p>
13:26 <@jrandom> Hybrid: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD</p>
13:26 < ant> &lt;cervantes&gt; yeah...I've got a page on the forum that lets my firefox toolbar know of latest "events"/news</p>
13:27 <@jrandom> but yeah, a link there too would be nice</p>
13:27 <@jrandom> ah cool cervantes</p>
13:27 < Hybrid> don't forget to put the version the user is currently running and the new version number available. (I like the way dvd decrypter does this)</p>
13:27 < ant> &lt;cervantes&gt; don't count on me releasing anything yet though....</p>
13:28 <@jrandom> right right Hybrid, the current version the user is running is visible on the top left corner of the router console, so it shouldnt be a problem</p>
13:28 < ant> &lt;cervantes&gt; wanted to spend the holidays working on it and have so far done absolutely nothing...</p>
13:28 <@jrandom> but this won't be bundled into the 0.4.2.6 release, because i havent written any of this code :)</p>
13:28 <@jrandom> heh cervantes, i hear you. i do look forward to the xul though!</p>
13:29 <@jrandom> ok, anyone have anything else wrt 2) 0.4.2.6, or shall we move on to 3) 0.5?</p>
13:29 < Hybrid> is it a problem for i2p to shutdown, new version install, and restart... would other applications irc need restarting??.. any other complications in a 'click n update' feature</p>
13:30 < Hybrid> (sorry interrupting dev meeting lol)</p>
13:30 <@jrandom> Hybrid: not a problem at all - thats what the "graceful restart" button on http://localhost:7657/configservice.jsp does</p>
13:30 < Hybrid> k</p>
13:31 < ant> &lt;cervantes&gt; jrandom: does the wrapper re-read the wrapper.config on a restart?</p>
13:31 <@jrandom> cervantes: no :(</p>
13:31 <@jrandom> i wish it did</p>
13:31 < ant> &lt;cervantes&gt; guess we need a wrapper service wrapper</p>
13:32 <@jrandom> perhaps someone could get a patch in to the java service wrapper folks</p>
13:32 <@jrandom> heh</p>
13:32 <@jrandom> ok, jumping to 3) 0.5</p>
13:32 <@jrandom> well, i dont really have much to say about this beyond whats in the email</p>
13:33 <@jrandom> lots of progress, many sheets of paper, and some code. nothing committed or ready for show yet though</p>
13:33 <@jrandom> thats 'bout all i have to say on that front, unless someone has any questions</p>
13:34 <@jrandom> if not, we can mosey on over to 4) jabber @ chat.i2p</p>
13:35 <@jrandom> new jabber server (w00t!). see the email & the forum for details</p>
13:35 <@jrandom> aparently it was dirt easy to set up the server too, so hopefully we can get some docs out there so that other people can run their own</p>
13:35 < frosk> i think it's the third i2p has had. i hope this one sticks around :)</p>
13:36 < jdot> docs are coming. its easy a heck w/ Jive Messenger. Just tunnel the ports properly.</p>
13:36 <@jrandom> personally, i'm fine with irc for one on one and group chat, but having the option for jabber is cool</p>
13:36 <@jrandom> ah word jdot</p>
13:36 <@jrandom> no rush, whenever is great</p>
13:37 <@jrandom> it'd just be great to be able to tell people that if they dont like how things are on one particular irc srever, they can go run their own :)</p>
13:37 < jdot> also will be looking to changate it with the irc channels .. in the future</p>
13:37 <@jrandom> nice</p>
13:38 <@jrandom> ok, thats all i have to say on that. you have anything you want to add jdot?</p>
13:39 <+protokol> how does one get on chat.i2p</p>
13:39 <+protokol> tis not resolve for me</p>
13:39 <@jrandom> http://forum.i2p.net/viewtopic.php?t=229</p>
13:40 < jdot> nothing to add. </p>
13:40 * eco has peeked at java service wrapper in the mean time</p>
13:40 < eco> re-reading the config file has been implemented for the upcoming 3.20 release</p>
13:40 < eco> see http://sourceforge.net/tracker/index.php?func=detail&aid=981060&group_id=39428&atid=425190</p>
13:41 <@jrandom> ah wikked</p>
13:41 * eco doesn't know when that's due though</p>
13:41 <@jrandom> perhaps with 0.5 we'll do a big external-app-upgrade, replacing our aging jetty and java service wrapper code</p>
13:42 <@jrandom> oh, before i go on, i suppose we should officially move to 5) ???</p>
13:42 <@jrandom> protokol: i think i remember you saying you got jetty working with CGI? any docs / info on that?</p>
13:43 <@jrandom> someone else out there was able to get jetty to do symlinks too, though i dont know who</p>
13:43 <@jrandom> (you out there, whoever you are? how'd you do it? :)</p>
13:44 <@jrandom> or, i suppose, anyone else have anything they want to bring up?</p>
13:45 * eco has a public service announcement</p>
13:45 < eco> there's a bounty for succesfully pulling i2p through gcj</p>
13:45 < eco> according to jr this will be dead simple, so go get it! :-)</p>
13:45 <@jrandom> heh, not dead simple, that was just wishful thinking ;)</p>
13:46 <@jrandom> but it might be</p>
13:46 <@jrandom> (so go get it :)</p>
13:46 < cervantes> think I posted links concering jetty symlinks somewhere either in chat or on the forum...can't remember which</p>
13:46 < cervantes> was a while back now</p>
13:46 <+protokol> jrandom: it was for the more recent version, i just crashed my jetty</p>
13:46 < slart> any news on the azureus plugin?</p>
13:46 <+protokol> i think jetty should be borught up-to-date so the docs on their website are useful</p>
13:46 < Hybrid> gcj?</p>
13:46 <+protokol> makes java into a binary</p>
13:46 <@jrandom> ah cool cervantes, i'll dig around for it</p>
13:47 < cervantes> I've looked at jetty with php...but it's a very hit an miss affair... php comes with a servlet .jar executable for use with tomcat..., I've seen reports that it can be made to work with jetty...but I have no idea how</p>
13:47 <@jrandom> protokol: ah</p>
13:47 <+protokol> and it needs cgi and symling support as well</p>
13:47 <@jrandom> slart: the azureus devs are hacking away and making progress, but its not ready yet</p>
13:47 <+protokol> cervantes: DO IT!</p>
13:48 <+protokol> it would be like apache built into i2p</p>
13:48 < frosk> Hybrid: The GNU Compiler for Java, or sumthing</p>
13:48 <@jrandom> cervantes: yeah, .jar support would be neat, but if its flakey, not worth it. having cgi support in jetty would be best, sicne we could then use normal php</p>
13:48 < slaw> excellent</p>
13:48 < frosk> mod_i2p :)</p>
13:49 <@jrandom> heh</p>
13:50 <@jrandom> ok, anyone else have anything they want to bring up for the meeting?</p>
13:51 <@jrandom> if not...</p>
13:51 * jrandom winds up</p>
13:51 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:09 <@jrandom> 0) hi
13:09 <@jrandom> 1) Net status
13:09 <@jrandom> 2) 0.4.2.6
13:09 < ant> <DrVince> It says that it can't find tools.jar but doesn't stop
13:10 <@jrandom> 3) 0.5
13:10 <@jrandom> 4) jabber @ chat.i2p
13:10 <@jrandom> 5) ???
13:10 <@jrandom> 0) hi
13:10 * jrandom waves
13:10 < eco> hi
13:10 <@jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-January/000541.html
13:10 <@jrandom> DrVince: if you can hang around, we can hack through that after the meeting
13:10 < ant> <DrVince> Cool
13:11 <@jrandom> jumping on into 1) Net status
13:11 <@jrandom> (as i'm sure y'all have read the weekly status notes already *cough*)
13:11 <@jrandom> basically, the net seems to be working well
13:11 <@jrandom> we still do have more irc disconnects than usual though, but not a horrid amount
13:12 <@jrandom> hopefully the next release (with the streaming lib improvements) will help out, as will further load balancing off duck's server
13:12 <@jrandom> (since remember, every message we send to any irc channel is sent to the irc server and echoed out again several times)
13:13 <+protokol> yeah
13:13 <@jrandom> a fully distributed chat system would be neat, but i'm not holding my breath. plus, irc works good enough
13:14 <@jrandom> ok, thats all i have wrt 1) net status
13:14 <@jrandom> does anyone have anything to add, comment, etc?
13:14 * eco has been away for a while (what's new)
13:15 < eco> and was happily surprised by the state of things. very good progress
13:15 < Myo9> Wasn't the meeting at 10?
13:15 < eco> both performance and usability wise
13:15 < eco> Myo9 10GMT (general meeting time)
13:16 <@jrandom> 9p GMT
13:16 <@jrandom> the last year has definitely brought a lot of progress
13:17 * eco hands out cookies to all devs and then shuts up
13:17 <@jrandom> *munch*
13:17 <@jrandom> ok, jumping on to 2) 0.4.2.6
13:18 <@jrandom> new release coming with bugfixes, improvements, and the addressbook bundled in
13:18 <@jrandom> i dont know exactly when it'll be out, maybe end of the week
13:18 <@jrandom> it'll be announced on the list and in the channels, of course
13:19 <@jrandom> thats all i have to say on that - anyone have any questions/comments/concerns wrt 0.4.2.6?
13:19 * eco recalls someone mentioning Debian packages
13:20 <@jrandom> os/distro-specific packaging is probably premature at the moment
13:20 < eco> Burton is willing to give that a try, but that won't be this week i guess
13:20 <@jrandom> ah cool, i hadn't heard that
13:21 < eco> agree, though it would be handy
13:21 <+protokol> hold on, im pretty high
13:21 <+protokol> oops
13:21 <+protokol> that was supposed to be a PM
13:21 <@jrandom> distro-specific packaging will be nice, but we probably need to have the auto-updater in place for that to be viable
13:21 <+protokol> i can look into making an ebuild
13:21 <@jrandom> protokol: if you're nice, i'll cut that out of the logs ;)
13:21 <+protokol> no guarentees
13:21 <+protokol> lol
13:22 <@jrandom> yeah, i wouldn't worry about packages until 0.5, if not 1.0
13:22 <@jrandom> (i hope to have the auto-updater in 0.5)
13:22 <+protokol> awesomecore
13:23 <@jrandom> actually, if someone wants to work on the updater, that'd be a pretty kick-ass low-hanging-fruit. just write a servlet to download and verify from dev.i2p/i2p/i2pupdate.zip, then call the router's restart method
13:23 < Myo9> Auto-updater, sounds like a threat.
13:23 <+protokol> modulus: welsome
13:23 <+protokol> $200 bounty for it
13:24 <@jrandom> heh true myo9, the update would want to allow both manual controls (one click update) and would want to verify a signature on the update
13:24 < ant> * DrVince had a problem with i2pupdate.zip
13:24 < ant> <cervantes> something that can be enabled or disabled would be nice ;)
13:24 * protokol makes it offical
13:24 < Myo9> So, all of a sudden, the router restarts and one notices Jr. has teamed with the IP ppl and DRM is enabled.
13:24 <@jrandom> protokol: oh cool, send in the $200 and i'll add that to the bounty page
13:24 < Myo9> ;)
13:24 < Myo9> I want auto-update turned off by default.
13:24 <@jrandom> agreed myo9
13:25 < ant> <cervantes> perhaps the routerconsole can be ammended to notify if a new version is available
13:25 <@jrandom> right cervantes
13:25 < Myo9> Great!
13:25 <@jrandom> it would want to display whether there is a new release, and give the user a one click option to upgrade
13:25 <@jrandom> (it'd be easy enough to add a web page @ www.i2p/ that contains the current version, so the router could check that periodically)
13:26 <@jrandom> ((or on demand))
13:26 < Hybrid> yes jrandom. that would be cool. also on the button a link to 'whats new' html page
13:26 <@jrandom> Hybrid: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD
13:26 < ant> <cervantes> yeah...I've got a page on the forum that lets my firefox toolbar know of latest "events"/news
13:27 <@jrandom> but yeah, a link there too would be nice
13:27 <@jrandom> ah cool cervantes
13:27 < Hybrid> don't forget to put the version the user is currently running and the new version number available. (I like the way dvd decrypter does this)
13:27 < ant> <cervantes> don't count on me releasing anything yet though....
13:28 <@jrandom> right right Hybrid, the current version the user is running is visible on the top left corner of the router console, so it shouldnt be a problem
13:28 < ant> <cervantes> wanted to spend the holidays working on it and have so far done absolutely nothing...
13:28 <@jrandom> but this won't be bundled into the 0.4.2.6 release, because i havent written any of this code :)
13:28 <@jrandom> heh cervantes, i hear you. i do look forward to the xul though!
13:29 <@jrandom> ok, anyone have anything else wrt 2) 0.4.2.6, or shall we move on to 3) 0.5?
13:29 < Hybrid> is it a problem for i2p to shutdown, new version install, and restart... would other applications irc need restarting??.. any other complications in a 'click n update' feature
13:30 < Hybrid> (sorry interrupting dev meeting lol)
13:30 <@jrandom> Hybrid: not a problem at all - thats what the "graceful restart" button on http://localhost:7657/configservice.jsp does
13:30 < Hybrid> k
13:31 < ant> <cervantes> jrandom: does the wrapper re-read the wrapper.config on a restart?
13:31 <@jrandom> cervantes: no :(
13:31 <@jrandom> i wish it did
13:31 < ant> <cervantes> guess we need a wrapper service wrapper
13:32 <@jrandom> perhaps someone could get a patch in to the java service wrapper folks
13:32 <@jrandom> heh
13:32 <@jrandom> ok, jumping to 3) 0.5
13:32 <@jrandom> well, i dont really have much to say about this beyond whats in the email
13:33 <@jrandom> lots of progress, many sheets of paper, and some code. nothing committed or ready for show yet though
13:33 <@jrandom> thats 'bout all i have to say on that front, unless someone has any questions
13:34 <@jrandom> if not, we can mosey on over to 4) jabber @ chat.i2p
13:35 <@jrandom> new jabber server (w00t!). see the email & the forum for details
13:35 <@jrandom> aparently it was dirt easy to set up the server too, so hopefully we can get some docs out there so that other people can run their own
13:35 < frosk> i think it's the third i2p has had. i hope this one sticks around :)
13:36 < jdot> docs are coming. its easy a heck w/ Jive Messenger. Just tunnel the ports properly.
13:36 <@jrandom> personally, i'm fine with irc for one on one and group chat, but having the option for jabber is cool
13:36 <@jrandom> ah word jdot
13:36 <@jrandom> no rush, whenever is great
13:37 <@jrandom> it'd just be great to be able to tell people that if they dont like how things are on one particular irc srever, they can go run their own :)
13:37 < jdot> also will be looking to changate it with the irc channels .. in the future
13:37 <@jrandom> nice
13:38 <@jrandom> ok, thats all i have to say on that. you have anything you want to add jdot?
13:39 <+protokol> how does one get on chat.i2p
13:39 <+protokol> tis not resolve for me
13:39 <@jrandom> http://forum.i2p.net/viewtopic.php?t=229
13:40 < jdot> nothing to add.
13:40 * eco has peeked at java service wrapper in the mean time
13:40 < eco> re-reading the config file has been implemented for the upcoming 3.20 release
13:40 < eco> see http://sourceforge.net/tracker/index.php?func=detail&aid=981060&group_id=39428&atid=425190
13:41 <@jrandom> ah wikked
13:41 * eco doesn't know when that's due though
13:41 <@jrandom> perhaps with 0.5 we'll do a big external-app-upgrade, replacing our aging jetty and java service wrapper code
13:42 <@jrandom> oh, before i go on, i suppose we should officially move to 5) ???
13:42 <@jrandom> protokol: i think i remember you saying you got jetty working with CGI? any docs / info on that?
13:43 <@jrandom> someone else out there was able to get jetty to do symlinks too, though i dont know who
13:43 <@jrandom> (you out there, whoever you are? how'd you do it? :)
13:44 <@jrandom> or, i suppose, anyone else have anything they want to bring up?
13:45 * eco has a public service announcement
13:45 < eco> there's a bounty for succesfully pulling i2p through gcj
13:45 < eco> according to jr this will be dead simple, so go get it! :-)
13:45 <@jrandom> heh, not dead simple, that was just wishful thinking ;)
13:46 <@jrandom> but it might be
13:46 <@jrandom> (so go get it :)
13:46 < cervantes> think I posted links concering jetty symlinks somewhere either in chat or on the forum...can't remember which
13:46 < cervantes> was a while back now
13:46 <+protokol> jrandom: it was for the more recent version, i just crashed my jetty
13:46 < slart> any news on the azureus plugin?
13:46 <+protokol> i think jetty should be borught up-to-date so the docs on their website are useful
13:46 < Hybrid> gcj?
13:46 <+protokol> makes java into a binary
13:46 <@jrandom> ah cool cervantes, i'll dig around for it
13:47 < cervantes> I've looked at jetty with php...but it's a very hit an miss affair... php comes with a servlet .jar executable for use with tomcat..., I've seen reports that it can be made to work with jetty...but I have no idea how
13:47 <@jrandom> protokol: ah
13:47 <+protokol> and it needs cgi and symling support as well
13:47 <@jrandom> slart: the azureus devs are hacking away and making progress, but its not ready yet
13:47 <+protokol> cervantes: DO IT!
13:48 <+protokol> it would be like apache built into i2p
13:48 < frosk> Hybrid: The GNU Compiler for Java, or sumthing
13:48 <@jrandom> cervantes: yeah, .jar support would be neat, but if its flakey, not worth it. having cgi support in jetty would be best, sicne we could then use normal php
13:48 < slaw> excellent
13:48 < frosk> mod_i2p :)
13:49 <@jrandom> heh
13:50 <@jrandom> ok, anyone else have anything they want to bring up for the meeting?
13:51 <@jrandom> if not...
13:51 * jrandom winds up
13:51 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/123.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, January 4, 2005
================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,384 +1,378 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 124{% endblock %}
{% block content %}<h3>I2P dev meeting, January 11, 2005</h3>
<div class="irclog">
13:10 < jrandom> 0) hi</p>
13:10 < deer> &lt;Ragnarok&gt; you're fired</p>
13:10 < jrandom> 1) Net status</p>
13:10 < jrandom> 2) 0.5 progress</p>
13:10 < jrandom> 3) 0.6 status</p>
13:10 < deer> &lt;polecat&gt; bye!</p>
13:10 < jrandom> 4) azneti2p</p>
13:10 < jrandom> 5) fbsd</p>
13:10 < jrandom> 6) hosts.txt as WoT</p>
13:11 < jrandom> 7) ???</p>
13:11 < jrandom> 0) hi</p>
13:11 * jrandom waves</p>
13:11 < fdr> yo</p>
13:11 < deer> &lt;Ragnarok&gt; hola</p>
13:11 < toad_> you just starting? /me will just watch from time to time</p>
13:11 < deer> &lt;detonate&gt; hi</p>
13:11 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2005-January/000551.html</p>
13:11 < jrandom> cool, all are welcome</p>
13:11 < deer> &lt;polecat&gt; Oh. Not your employment. My bad. =3</p>
13:11 < jrandom> the logs of the dev meetings are posted up @ the website (after the meeting, of course)</p>
13:11 < fdr> I'm starving, so I'll be in and out..</p>
13:12 < jrandom> ok, swinging on int to 1) Net status</p>
13:12 < jrandom> things seem to be working fine. duck is back (yay!)</p>
13:12 < jrandom> I dont really have much to add beyond whats in the email - anyone else have anything?</p>
13:13 < deer> &lt;jrandom&gt; nope</p>
13:13 < jrandom> ok, if not, moving on to 2) 0.5 status</p>
13:14 < jrandom> There's been some good progress here, finally got the matrix encryption working, but after chatting with polecat the other day, theres a little tweak we need to add on</p>
13:14 < toad_> talking to yourself?</p>
13:14 < jrandom> heh yeah, until anyone replies ;)</p>
13:14 < jrandom> (you should have seen these meetings before I posted the weekly status notes beforehand)</p>
13:14 < toad_> I meant across networks. I talk to myself all the time, but not usually across networks. ;)</p>
13:15 < deer> &lt;jrandom_&gt; across three networks even [iip here]</p>
13:15 < deer> &lt;Ragnarok&gt; stop that, it's creepy :)</p>
13:15 < deer> * postman waves</p>
13:16 < jrandom> I dont really have anything else to add wrt 0.5, beyond "more info coming soon"</p>
13:16 < deer> &lt;polecat&gt; Re net performance, my i2p router went down 24h ago, but before that I managed 8 days of uptime.</p>
13:16 < jrandom> ah ok cool</p>
13:16 < jrandom> OOMed? were you running bt or just from activity?</p>
13:17 < deer> &lt;polecat&gt; Just a heuristic to brag about. =3</p>
13:17 < deer> &lt;frosk&gt; i generally get as much uptime from my router as i want, although usually no more than 8-9 due to upgrades :)</p>
13:17 < deer> &lt;frosk&gt; 8-9 days, that is</p>
13:18 * jrandom wishes my kaffe box could do that (oh well)</p>
13:18 < deer> * orion can crash a router at will by running 40+ local destinations via btlaunchmanycurses.py. ;)</p>
13:18 < jrandom> heh yes, that would do it orion</p>
13:18 < deer> &lt;polecat&gt; Oh, the logs say that the JVM appears hung, so I suppose lucky must have used me in a tunnel to download gigabytes of over endowed men.</p>
13:18 < deer> &lt;orion&gt; but, I've had uptime of 15 days before BT storms.</p>
13:18 < jrandom> oh interesting polecat. </p>
13:19 < jrandom> polecat: if you're feeling brave, it might be worth trying the latest java service wrapper</p>
13:19 < jrandom> (if it gets rid of that we should upgrade)</p>
13:19 < deer> * laberhorst had uptime 15days with 0.4.2.5 without bt</p>
13:19 < jrandom> i think cervantes is still the winner w/ 0.4.1.1 @ 41 days</p>
13:20 < deer> &lt;polecat&gt; Anyone want to PM me on how to get the latest java service wrapper?</p>
13:20 < jrandom> but anyway, anyone have any comments on 0.5 stuff?</p>
13:20 < protok0l> is i2p done yet?</p>
13:20 < jrandom> http://wrapper.tanukisoftware.org/doc/english/</p>
13:20 < deer> &lt;eco&gt; looking forward to the docs</p>
13:20 < jrandom> !thwap protok0l </p>
13:21 < jrandom> ok, moving on to 3) 0.6 status</p>
13:21 < deer> &lt;polecat&gt; I still think that there ought to be a way to checksum without the gateway knowing all the checksums, or how many.</p>
13:21 < deer> &lt;Ragnarok&gt; where are the documents going up?</p>
13:21 < jrandom> polecat: I'd love it, but I doubt it can be done. </p>
13:22 < jrandom> Ragnarok: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel.html?rev=HEAD is the current draft</p>
13:22 < jrandom> (not updated wrt the first hop issue)</p>
13:22 < deer> &lt;Ragnarok&gt; thanks</p>
13:22 < deer> &lt;polecat&gt; "They said it couldn't be done.... they called me mad... but they were fools, FOOLS!</p>
13:22 < jrandom> heh</p>
13:22 < jrandom> hey, if you can find a way, I'm all ears</p>
13:23 < jrandom> (and I have a feeling the mixmaster/mixminion folks will be too)</p>
13:23 < deer> &lt;jrandom&gt; zounds, 42 usres here</p>
13:23 < deer> &lt;jrandom&gt; mule: you 'round?</p>
13:24 < deer> &lt;polecat&gt; Heh. Will keep my nose to the ground then, but no promises as I'm just a dumb ferret not geniushes like y'all.</p>
13:24 * jrandom flings a small furry animal at polecat</p>
13:25 -!- dm [mihi@dsl-80-42-80-26.access.uk.tiscali.com] has joined #i2p</p>
13:25 < jrandom> ok, anyway, 0.6 stuff looks interesting, and mule has started on some hacking, but its still early on in the game</p>
13:26 < jrandom> zab has been pretty helpful giving us some guidance from how limewire goes about things, but, well, their congestion control is kind of scary (fixed small windows, full ack)</p>
13:26 < jrandom> (but i'm sure they'll improve in time, of course)</p>
13:26 < jrandom> also was nice of him to give us a view into how they're having the rubber hit the road, what gotchas they've had with various jvms, etc</p>
13:27 < jrandom> (yay zab)</p>
13:27 < jrandom> in any case, if you're interested in helping out with the design and implementation or integration of some other provider for 0.6, get in touch with either mule or myself (or, of course, send patches ;)</p>
13:28 < jrandom> not much else to say on that, unless anyone has anything to bring up?</p>
13:28 < deer> &lt;polecat&gt; Isn't 0.6 supposed to have preliminary fusenet support?</p>
13:28 < deer> &lt;frosk&gt; by april, hopefully :)</p>
13:29 < toad_> fusenet?</p>
13:29 < deer> &lt;frosk&gt; but with all this work on the udp transport, maybe it'll be ready before fusenet will</p>
13:29 < jrandom> yeah, the general aim is just to get the ball rolling</p>
13:29 < deer> &lt;frosk&gt; fusenet is a content-distribution system more or less like usenet on speed</p>
13:29 < toad_> cool</p>
13:30 < deer> &lt;frosk&gt; it will initially support blogs, discussion forums and addressbooks for i2p name-destination mappings</p>
13:30 < jrandom> though of course, if we get the UDP transport implemented next month, we'll probably roll that out with 0.5</p>
13:31 < deer> &lt;frosk&gt; of course, that would be cool :)</p>
13:31 < jrandom> and if i had a pony, i'd play with him aaaaalll day</p>
13:31 < jrandom> ok, thats prolly 'bout it for 0.6 stuff, moving on to 4) azneti2p</p>
13:31 < deer> &lt;frosk&gt; i'm glad you have no pony, then ;)</p>
13:31 < jrandom> heh</p>
13:32 < jrandom> azneti2p == kickass. </p>
13:32 < jrandom> parg & the rest of the azureus folks have done some great work, and the integration is really nice</p>
13:33 < jrandom> torrents work the same as before, show up with all the pretty graphs, lets you do all the queueing / etc you're used to in azureus, except anonymously</p>
13:33 < deer> &lt;postman&gt; w00t!</p>
13:33 < jrandom> there are still further optimizations and simplifications left to do, but all in all, i'm quite impressed</p>
13:33 < deer> &lt;eco&gt; hurray! enter the masses...</p>
13:33 < deer> &lt;frosk&gt; i understand you still have to do some manual labour in the router console before you can use it?</p>
13:33 * jrandom holds the gates closed for just a litttttle wile longer</p>
13:33 < deer> &lt;eco&gt; is java 1.5 indeed required?</p>
13:34 < deer> &lt;polecat&gt; Yup.. neat stuff except you can't leave it to daemon out.</p>
13:34 < deer> &lt;postman&gt; sounds like the invitated for the i2p network to get his ass kicked badly</p>
13:34 < jrandom> frosk: right - but we're working on patching it up to do the I2PTunnel calls within the plugin itself</p>
13:34 < deer> &lt;frosk&gt; cool</p>
13:34 < jrandom> eco: unsure, I only tried it with 1.5, but I believe them when they say it. </p>
13:34 < deer> &lt;polecat&gt; eco: I should hope not. o.O 1.5 is just Sun trying to strongarm the market.</p>
13:34 < jrandom> worth trying though, i'll do so later</p>
13:35 < deer> * postman does not care, i got gigabit ethernet interfaces and LOTS of traffic included :)</p>
13:35 < deer> &lt;polecat&gt; Oh dear... and azareus requires it. I _really_ have to make my C++ torrent app.</p>
13:35 < jrandom> polecat: azureus does have a headless mode of operation, and a web console</p>
13:36 < deer> * polecat blinks.</p>
13:36 < jrandom> (but its... tough to the uninitiated [like myself])</p>
13:36 < deer> &lt;polecat&gt; Well okay then... I thought it didn't, like KazAa</p>
13:36 < jrandom> but i only glanced at it (and ran back to the GUI ;)</p>
13:36 < deer> &lt;Ragnarok&gt; is duck going to be bringing i2p-bt up to 3.9/4.0?</p>
13:37 < jrandom> ragnarok: unknown, but duck is currently doing leaps and bounds to keep all the existing stuff compatible with azneti2p</p>
13:37 < jrandom> (they had to do some... odd changes due to technical requirements)</p>
13:37 < deer> &lt;polecat&gt; One of the most powerful aspects of p2p is if the app can run quietly in the background whet you're not using it.</p>
13:38 * jrandom isnt arguing with that point</p>
13:38 < jrandom> ok, i think thats all i have to say wrt azneti2p (other than w00t, again). more info in the email, and there'll be lots of activity in #i2p-bt i'm sure</p>
13:39 < jrandom> anyone else have anything to bring up wrt azneti2p?</p>
13:39 < cervantes> are you ready for it... ;-)</p>
13:40 < jrandom> heh, we're workin' on it</p>
13:40 < deer> &lt;polecat&gt; Might I note that the source of azareus is totally abysmal...</p>
13:40 < deer> &lt;polecat&gt; There are 28 main entry points, and it uses at least a namespace depth of 3.</p>
13:40 < deer> &lt;Ragnarok&gt; does any bt client have nice source?</p>
13:40 < jrandom> there are some oddities, but i suspect you'll find that in anyone else's source (NIH)</p>
13:40 < deer> &lt;polecat&gt; Mine will.</p>
13:40 < jrandom> oh c'mon, net.i2p.router.netdb.kademlia.* :)</p>
13:41 < deer> &lt;Ragnarok&gt; not if it's in C++ it won't :)</p>
13:41 < toad_> lol</p>
13:41 < deer> &lt;polecat&gt; I said at least!</p>
13:42 < jrandom> ok, anyway, moving us along to 5) fbsd</p>
13:42 < deer> &lt;polecat&gt; Ragnarok: You've never seen how I *cough*rape*cough* use C++. n.n</p>
13:42 * duck looks in</p>
13:42 < deer> &lt;polecat&gt; Who cares about FreeBSD? Show of hands?</p>
13:42 < jrandom> lioux has packaged up the 0.4.2.6 release into ports (w00t!)</p>
13:42 < deer> * detonate raises his</p>
13:42 < deer> &lt;polecat&gt; Paws, tentacles, wings, etc?</p>
13:43 * jrandom raises my hand</p>
13:43 * [dave] raises</p>
13:43 < deer> &lt;Ragnarok&gt; duck: 3.9/4.0? :)</p>
13:43 < deer> &lt;polecat&gt; Woah, i2p is integrated into a distribution?</p>
13:43 < duck> Ragnarok: the lack of comments / docs / etc on the latest bram-Bittorrent changes were a bit of a setback</p>
13:43 < fdr> FreeBSD is cool :(</p>
13:43 < deer> &lt;Ragnarok&gt; I'll bet</p>
13:43 < fdr> I may be biased though.</p>
13:44 < jrandom> aye, i was worried at first polecat, but his ports impl looked really really easy (so updates will be really really easy)</p>
13:44 < duck> It would require studying what they did, maybe it would be worth the effort</p>
13:44 < deer> &lt;polecat&gt; As far as I'm concerned, fbsd is a distro with an odd kernel and lots of data hiding. It's all POSIX in the end so... ;)</p>
13:44 < jrandom> polecat: and very, very w0nky JVMs</p>
13:45 < duck> though secretly I have been hoping on azneti2p solving all problems</p>
13:45 < deer> &lt;Ragnarok&gt; duck: it did sound like there were some nice improvements, but you're the one who'd probably be doing the work, so... :)</p>
13:45 < deer> &lt;polecat&gt; Ugh... don't remind me.</p>
13:45 < jrandom> heh, azneti2p will probably fit the needs of many users, but simple CLI tools will still make sense for the ubergeeks out there</p>
13:46 < jrandom> anyway, so it seems he's tested i2p 0.4.2.6 on fbsd5.3 without problems (w00t)</p>
13:46 < deer> &lt;Ragnarok&gt; oy, I don't like azureus, I'd much rather use the normal client</p>
13:46 * jrandom has only done so on 4.8</p>
13:46 < duck> currently I'd like to do something with kenosis; being a hit-n-run coder</p>
13:47 < deer> &lt;eco&gt; jrandom: what jvm did he use?</p>
13:47 < jrandom> kenos2p</p>
13:47 < jrandom> eco: native compiled sun 1.4</p>
13:47 < jrandom> (booo hiss)</p>
13:47 < deer> &lt;eco&gt; ah, illegal!</p>
13:47 < deer> &lt;polecat&gt; Ragnarok: If you want to critique my bittorrent client design, my current code plan is here: http://polecat.i2p/bittorrent.plan.txt</p>
13:47 < jrandom> ((but kaffe works))</p>
13:48 < jrandom> eco: is it illegal? I thought you could agree to the terms and get the source legit on fbsd</p>
13:48 < deer> &lt;eco&gt; sun withdrew the license afaik</p>
13:48 < jrandom> hmm, i think thats just the blackdown license</p>
13:48 < jrandom> (and, tbh, blackdown sucks)</p>
13:49 < jrandom> individuals can still license it under SCSL</p>
13:49 < deer> &lt;polecat&gt; ouch.</p>
13:49 < jrandom> (first born child, etc)</p>
13:49 < jrandom> heh, its interesting to hear such license gripes when so few have copyright gripes ;)</p>
13:50 < jrandom> but this discussion is best for the 7) ??</p>
13:50 < jrandom> and we're on 5) fbsd</p>
13:50 < deer> &lt;eco&gt; license stuff on http://www.freebsdfoundation.org/press/20041221-newsletter.shtml , but back to the main thread...</p>
13:50 < cervantes> first time we've crept above 5) in a long time</p>
13:51 < jrandom> cervantes: and we had to trim things ;)</p>
13:51 < jrandom> ok, i think thats it for fbsd stuff (beyond yay!)</p>
13:51 < jrandom> so jumping into a messy one... 6) hosts.txt as a WoT</p>
13:51 < deer> &lt;polecat&gt; licensing can get you at the node though, whereas copyright vio can only be tracked to the destination.</p>
13:51 < deer> &lt;polecat&gt; Which "can't" be found.</p>
13:52 < jrandom> right right polecat, but once They have physical control of your box, you're in deep shit anyway</p>
13:53 < jrandom> ok, anyway I'm not sure if there's much I have to add to what was posted in the email wrt hosts.txt</p>
13:53 < jrandom> anyone have any questions/comments/concerns?</p>
13:53 < jrandom> (was I vague enough? :)</p>
13:53 < duck> yes</p>
13:53 < deer> * eco considers handing hosts.txt management over to the UN</p>
13:54 < jrandom> heh yeah, because we know nice centralized beurocratic authorities always Do The Right Thing</p>
13:54 < toad_> lol</p>
13:55 < jrandom> i suppose the real "big win" will be when the addressbook gets both a web interface and more metadata</p>
13:55 < jrandom> (and perhaps the fusenet syndication, etc)</p>
13:55 < deer> &lt;Ragnarok&gt; metadata will be the next thing I work on, using xml name records</p>
13:56 < jrandom> kickass ragnarok!</p>
13:56 < jrandom> whats your take on the WoT side ragnarok - do you see it as an issue with the addressbook, or how you forsee naming?</p>
13:57 < deer> &lt;Ragnarok&gt; Essentially I think the way addressbook works (and how passing around name references on fusenet will work) is the only really sensible way to handle naming on i2p</p>
13:58 < deer> &lt;Ragnarok&gt; so, the WoT is a feature :)</p>
13:58 < jrandom> Wo0T</p>
13:58 < lucky> whoa</p>
13:58 < deer> &lt;eco&gt; but surely you sell premium accounts?</p>
13:58 < lucky> is that a toad i see?</p>
13:58 < lucky> a real toad?</p>
13:58 < lucky> or just a frog.</p>
13:58 < deer> &lt;frosk&gt; the important point imho, is how to handle collisions</p>
13:59 < toad_> a toad</p>
13:59 < deer> &lt;detonate&gt; first come, first serve</p>
13:59 < jrandom> right frosk, it'd be nice to have an interface to manage those, rather than just "read the log"</p>
13:59 < deer> &lt;Ragnarok&gt; frosk: I think that's more an issue of interface than anything else. Collisions will have to be resolved by the user.</p>
13:59 < toad_> call my name if it gets close to my area :)</p>
13:59 < deer> &lt;frosk&gt; Ragnarok: my thinking too</p>
13:59 < deer> &lt;Ragnarok&gt; anything else can be attacked</p>
13:59 < lucky> oh, not the freenet toad.</p>
13:59 < lucky> oh</p>
13:59 < lucky> it is.</p>
13:59 < deer> &lt;eco&gt; so the names are simply like aliases in IM?</p>
14:00 < deer> &lt;frosk&gt; collisions need to be stored so you can switch long after the fact</p>
14:00 < deer> &lt;Ragnarok&gt; and is probably not provably better in the general case</p>
14:00 < lucky> we're paying toad now?</p>
14:00 < jrandom> eco: right - the names are just private local nicknames</p>
14:00 < deer> &lt;susi23&gt; the addressbook should recognize collisions and notify the user so he can decide</p>
14:01 < deer> &lt;Ragnarok&gt; frosk: after the switch to name records, the intent is to never throw them away, but make it easy to change the address they correspond to</p>
14:01 < deer> &lt;susi23&gt; until the user made his decision any changes regarding the collision should somehow get "quarantined" :)</p>
14:01 < deer> &lt;Ragnarok&gt; susi23: that's essentially how it works now</p>
14:01 < deer> &lt;Ragnarok&gt; it just has a lousy interface</p>
14:01 < deer> &lt;frosk&gt; Ragnarok: sounds good :) do you have a web interface in the works? (or is there one already i'm not aware about?)</p>
14:02 < deer> &lt;susi23&gt; fine then</p>
14:02 < deer> &lt;Ragnarok&gt; nope. I don't do web interfaces :)</p>
14:02 < deer> &lt;Ragnarok&gt; susi was working on something, I think, but I'm not sure what's happened with that</p>
14:02 < jrandom> (volunteers? any chance of reviving susidns to manage the names?)</p>
14:03 < deer> &lt;susi23&gt; ok, give me a week, I put it on TODO</p>
14:03 < jrandom> (and after susidns, we need susitorrent and susiirc...)</p>
14:03 < jrandom> wikked!</p>
14:04 < jrandom> ok, anyone have anything else to bring up wrt that whole hosts.txt thing?</p>
14:05 < jrandom> if not, moving on to 7) ???</p>
14:05 < deer> &lt;Ragnarok&gt; one thing</p>
14:05 < jrandom> you've got the mic</p>
14:05 < deer> &lt;Ragnarok&gt; for the next release, can we agree that hosts.txt should be managed directly by addressbook, so we can stop mangiling userhosts.txt?</p>
14:06 < jrandom> sounds reasonable. i'll stop shipping hosts.txt in the i2pupdate.zip (but will include it in i2pinstall.jar)</p>
14:06 < deer> &lt;Ragnarok&gt; cool. That's all :).</p>
14:07 < jrandom> ok, now back to the opne floor</p>
14:07 < jrandom> anyone else have anything they want to bring up?</p>
14:07 < deer> &lt;postman&gt; yes</p>
14:07 < jrandom> hit it postman</p>
14:07 < deer> * postman raises his hand</p>
14:08 < deer> * postman is desperately looking for a volunteer providing the secondary MX server for i2pmail.org ( this being an inproxy to the internal mailsystem )</p>
14:09 < deer> &lt;postman&gt; if anyone got a stable, fast (dedicated) machine, i would be very happy to accept help</p>
14:09 < deer> &lt;postman&gt; configuration / howto will be delivered by me</p>
14:09 < deer> &lt;eco&gt; how fast is fast?</p>
14:10 < deer> &lt;postman&gt; eco: static IP wuld be nice - everything else is negotiable</p>
14:10 < jrandom> how much traffic are you seeing through mail.i2p postman?</p>
14:10 < jrandom> (external, that is)</p>
14:10 < deer> &lt;polecat&gt; Stable, fast, dedicated... well 1/3 isn't bad.</p>
14:10 < deer> &lt;postman&gt; the mailtraffic is VERY low</p>
14:10 < deer> &lt;postman&gt; in/out is about 500 mails / month</p>
14:11 < jrandom> ah cool</p>
14:11 < deer> &lt;Frooze&gt; i have slow (500 MHz), stable, dedicated</p>
14:11 < deer> &lt;postman&gt; BUT since the inproxy will have a I2P running</p>
14:11 < jrandom> (that'll probably pick up as more people find out about it though ;)</p>
14:11 < deer> &lt;eco&gt; the machine would be for incoming mail only?</p>
14:11 < deer> &lt;postman&gt; most traffic would be I2p i guess</p>
14:12 < deer> &lt;postman&gt; eco: at least incoming ( it's needed for this ) </p>
14:12 < deer> &lt;postman&gt; if the operator is ok with that i would like to rotate outgoing over both machines</p>
14:12 < deer> &lt;postman&gt; Frooze: it's ok, when it's able to run i2p</p>
14:13 < deer> &lt;postman&gt; just drop me a mail</p>
14:13 * toad_ wonders if his current issues are AOB business or if they are simply between him and jrandom</p>
14:13 < deer> &lt;postman&gt; if anyone is interested</p>
14:14 < deer> * postman hands back the mike</p>
14:14 < deer> &lt;Frooze&gt; will do.</p>
14:14 < deer> &lt;postman&gt; thanks jr :)</p>
14:14 < jrandom> cool, thanks postman</p>
14:14 < jrandom> toad_: i think there's much to be discussed, though largely a question for the freenet folks</p>
14:15 < toad_> jrandom: right</p>
14:15 < toad_> jrandom: talk after meet</p>
14:15 < jrandom> sounds good</p>
14:15 < duck> no public mudfight? :/</p>
14:15 < jrandom> ok, anyone else have anything to bring up for the meeting?</p>
14:15 < jrandom> heh duck</p>
14:15 < deer> * eco points at http://dodo.freenetproject.org/pipermail/tech/2005-January/001224.html</p>
14:15 < jrandom> (that was on tehc ;)</p>
14:15 < cervantes> postman: my box has too much shit running on it to be any help I'm afraid ;-)</p>
14:15 < deer> &lt;polecat&gt; Ragnarok: If we could sign the addressbook host data, that would allow for automatic updates. Otherwise not much to be done. Even if the user gets a popup, how are they to tell which key is accurate?</p>
14:15 < deer> &lt;Ragnarok&gt; what does accurate mean?</p>
14:16 < jrandom> polecat: signing entries would Kick Fucking Ass.</p>
14:16 < deer> &lt;eco&gt; fyi</p>
14:16 < deer> &lt;eco&gt; no mud involved.</p>
14:16 < deer> &lt;Ragnarok&gt; (and signing is planned for name records)</p>
14:16 < deer> &lt;postman&gt; cervantes: hi, thanks anyway :)</p>
14:16 < cervantes> you are indeed very welcome</p>
14:16 < cervantes> :P</p>
14:17 < jrandom> ok, anything else?</p>
14:17 < deer> &lt;polecat&gt; Ragnarok: accurate means centered around the correct result.</p>
14:17 < cervantes> polecat: I'm waiting for one of my clients to go bust before I sneak into one of their forgotten mailservers to install i2p</p>
14:18 < deer> &lt;Ragnarok&gt; polecat: yes, but what's the correct result?</p>
14:18 < jrandom> lol cervantes </p>
14:18 < cervantes> %s/polecat/postman</p>
14:19 < deer> &lt;polecat&gt; The addressbook file that gets sent between eepsites could do the signing in its format, keeping the other hosts.txt the same.</p>
14:19 * duck wonders if updating dot.png is useful?</p>
14:19 < duck> it got kind of full</p>
14:19 < deer> &lt;eco&gt; give us a 3d applet</p>
14:20 < jrandom> duck: its a bit hard to read yeah ;)</p>
14:20 < jrandom> duck: perhaps only list the blue lines?</p>
14:20 < jrandom> to me, the value comes from seeing how spread out green is</p>
14:20 < jrandom> (or whether there are clusters of dark green, etc)</p>
14:20 < deer> &lt;Ragnarok&gt; polecat: signing will be supported in the xml name record format.</p>
14:21 < deer> &lt;polecat&gt; Ragnarok: The correct result is that the human readable name maps to the destination you expect to see, and only changes when the owner of that destination changes keys.</p>
14:21 < deer> &lt;polecat&gt; Right. So... great. No problem then.</p>
14:21 < deer> &lt;Ragnarok&gt; polecat: that's what we've got now</p>
14:22 < deer> &lt;polecat&gt; If the signature of an update matches the original record's public key then you can update automatically, no problem.</p>
14:24 < jrandom> ok, there's still room left to be hashed out on the Great Naming Debate, of course</p>
14:24 < jrandom> anyone have anything else for the meeting?</p>
14:24 < deer> * eco has a UI poll</p>
14:24 * jrandom has a GUI</p>
14:25 < deer> &lt;Ragnarok&gt; polecat: that will be supported once we've got signing :)</p>
14:25 < deer> &lt;eco&gt; the i2ptunnel option in the web ui results in a popup - am i the only one less enthusiastic about that?</p>
14:25 < jrandom> definitely not the only one eco. </p>
14:25 < jrandom> i wrote the i2ptunnel web interface approximately as poorly as i could</p>
14:25 < jrandom> it really, really sucks</p>
14:25 * cervantes steals jrandom's "patches welcome" line</p>
14:26 < jrandom> (what cervantes said :)</p>
14:26 < jrandom> or even just plain HTML, i can integrate it with the jsp</p>
14:26 < jrandom> (but of course patches to the jsp would be nice)</p>
14:27 < cervantes> jrandom: btw I have a patch for what we discussed yesterday...just going to test it a little more first....</p>
14:27 < jrandom> ah wikked cervantes, thanks!</p>
14:27 < deer> &lt;eco&gt; why not list that in the main page, like the other pages?</p>
14:27 < deer> &lt;eco&gt; ok, so no big religious or technical reason behind it?</p>
14:28 < deer> * polecat has a FUI</p>
14:28 < jrandom> eco: from a UI perspective, it can be made to look like the other pages, but not technically</p>
14:28 < jrandom> technically, it needs to stay seperate as a client app deployed as a seperate .war file</p>
14:28 < deer> &lt;polecat&gt; Ragnarok: I thought you said that's what we've got now?</p>
14:29 * jrandom appreciates very much mihi's contribution of that code, but I can't let the i2p console depend upon GPL</p>
14:29 < deer> &lt;Ragnarok&gt; er, sorry, I meant everything but the signing, which obviously we don't do right now.</p>
14:29 < jrandom> (but we can make it look like the other pages</p>
14:30 < deer> &lt;eco&gt; ah, license issues. great</p>
14:30 < jrandom> heh isn't it grand eco?</p>
14:30 < deer> &lt;Ragnarok&gt; so currently addresses are never updated automatically, changing the destination an address points to always requires user intervention</p>
14:30 < cervantes> jrandom: iframe :P</p>
14:30 * jrandom wishes people just saw the IP farse for what it was and released into the public domain</p>
14:30 < deer> &lt;eco&gt; but in this case a socket connection for example should be okay GPL-wise i'd guess</p>
14:30 < jrandom> cervantes: not an impossible alternative</p>
14:30 < jrandom> right eco</p>
14:31 < jrandom> we've done our best to tap dance around the integration of the actual meat (using clients.config and i2ptunnel.config), but the web UI suffers a bit from it</p>
14:33 < deer> &lt;susi23&gt; any wishes, feature requests, and comments regarding the addressbook interface please add to http://susi.i2p/susidns.html</p>
14:33 * toad_ respects jrandom's extremist licensing views while disagreeing vehemently with them :)</p>
14:33 < jrandom> oh cool, shall do susi23</p>
14:34 < jrandom> heh toad_ :)</p>
14:34 < deer> * eco puts it on his when-i'm-64-to-do-list</p>
14:34 < toad_> bbiab</p>
14:34 < jrandom> l8r</p>
14:34 < toad_> when i get back we need to talk about various technical issues with i2p/freenet integration</p>
14:34 < jrandom> ok, anyone else have anything for the meeting?</p>
14:34 * cervantes wheels out the metal gong</p>
14:34 < toad_> will try to get back quickly</p>
14:34 < jrandom> cool toad_, i'll be around</p>
14:34 < jrandom> (it'll give me time to catch up on those threads ;)</p>
14:35 * jrandom winds up</p>
14:35 * jrandom *baf*s the gong, closing the meeting</p>
14:35 < deer> &lt;DrWoo&gt; jrandom: I have one issue if you're still open to 7)??? , I just want to go back to the azureus plug-in for a moment if I may, #1 - this will be *quite* appealing to the peeps, isn't this the perfect time to try to get easy tunnel length controls into the p2p side of I2P via this plug-in, to try to make the best use of bw resources on the net? #2 - having a working azureus plug-in will (very likely?) cause some publicity whether you want it or not,</p>
14:35 < dm> i2p/freenet integration!?</p>
14:35 * jrandom de-gongs</p>
14:35 * cervantes puts the gong away</p>
14:35 < jrandom> #1: yes, absolutely - I've sent parg a patch to do that</p>
14:36 < jrandom> #2: [got trimmed @ 'want it or not,']</p>
14:38 * jrandom watches the irc streaming lib logs -</p>
14:38 < jrandom> 14:37:55.701: SEND bRC43g==QRnB~Q==: #2 DELAY 1000 MS ACK 1 data: 29 sent 2 times</p>
14:38 < jrandom> 14:38:20.072: SEND juVFdg==aAUIVw==: #3465 DELAY 1000 MS ACK 5723 data: 43 sent 2 times</p>
14:40 < deer> * eco grabs a beer</p>
14:40 < deer> &lt;DrWoo&gt; jrandom: #2 - having a working azureus plug-in will (very likely?) cause some publicity whether you want it or not, are you prepared for a user influx, and if not when do you think you will be?</p>
14:40 < jrandom> it would not be good to have a large burst of users prior to the UDP transport</p>
14:41 < jrandom> there is still a lot of work to be done on azneti2p, so hopefully that'll buy us some time, but we'll do what we need to do</p>
14:41 < deer> &lt;DrWoo&gt; jrandom: cool to see your all over #1 ;)</p>
14:42 < jrandom> we also will need some docs for #1 too, explaining why 0 hops works for some threat models :)</p>
14:44 < jrandom> ok, we ready for a re-gong?</p>
14:45 * jrandom winds up</p>
14:45 * jrandom *baf*s the meeting closed^2</p>
</div>
{% endblock %}
13:10 < jrandom> 0) hi
13:10 < deer> <Ragnarok> you're fired
13:10 < jrandom> 1) Net status
13:10 < jrandom> 2) 0.5 progress
13:10 < jrandom> 3) 0.6 status
13:10 < deer> <polecat> bye!
13:10 < jrandom> 4) azneti2p
13:10 < jrandom> 5) fbsd
13:10 < jrandom> 6) hosts.txt as WoT
13:11 < jrandom> 7) ???
13:11 < jrandom> 0) hi
13:11 * jrandom waves
13:11 < fdr> yo
13:11 < deer> <Ragnarok> hola
13:11 < toad_> you just starting? /me will just watch from time to time
13:11 < deer> <detonate> hi
13:11 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2005-January/000551.html
13:11 < jrandom> cool, all are welcome
13:11 < deer> <polecat> Oh. Not your employment. My bad. =3
13:11 < jrandom> the logs of the dev meetings are posted up @ the website (after the meeting, of course)
13:11 < fdr> I'm starving, so I'll be in and out..
13:12 < jrandom> ok, swinging on int to 1) Net status
13:12 < jrandom> things seem to be working fine. duck is back (yay!)
13:12 < jrandom> I dont really have much to add beyond whats in the email - anyone else have anything?
13:13 < deer> <jrandom> nope
13:13 < jrandom> ok, if not, moving on to 2) 0.5 status
13:14 < jrandom> There's been some good progress here, finally got the matrix encryption working, but after chatting with polecat the other day, theres a little tweak we need to add on
13:14 < toad_> talking to yourself?
13:14 < jrandom> heh yeah, until anyone replies ;)
13:14 < jrandom> (you should have seen these meetings before I posted the weekly status notes beforehand)
13:14 < toad_> I meant across networks. I talk to myself all the time, but not usually across networks. ;)
13:15 < deer> <jrandom_> across three networks even [iip here]
13:15 < deer> <Ragnarok> stop that, it's creepy :)
13:15 < deer> * postman waves
13:16 < jrandom> I dont really have anything else to add wrt 0.5, beyond "more info coming soon"
13:16 < deer> <polecat> Re net performance, my i2p router went down 24h ago, but before that I managed 8 days of uptime.
13:16 < jrandom> ah ok cool
13:16 < jrandom> OOMed? were you running bt or just from activity?
13:17 < deer> <polecat> Just a heuristic to brag about. =3
13:17 < deer> <frosk> i generally get as much uptime from my router as i want, although usually no more than 8-9 due to upgrades :)
13:17 < deer> <frosk> 8-9 days, that is
13:18 * jrandom wishes my kaffe box could do that (oh well)
13:18 < deer> * orion can crash a router at will by running 40+ local destinations via btlaunchmanycurses.py. ;)
13:18 < jrandom> heh yes, that would do it orion
13:18 < deer> <polecat> Oh, the logs say that the JVM appears hung, so I suppose lucky must have used me in a tunnel to download gigabytes of over endowed men.
13:18 < deer> <orion> but, I've had uptime of 15 days before BT storms.
13:18 < jrandom> oh interesting polecat.
13:19 < jrandom> polecat: if you're feeling brave, it might be worth trying the latest java service wrapper
13:19 < jrandom> (if it gets rid of that we should upgrade)
13:19 < deer> * laberhorst had uptime 15days with 0.4.2.5 without bt
13:19 < jrandom> i think cervantes is still the winner w/ 0.4.1.1 @ 41 days
13:20 < deer> <polecat> Anyone want to PM me on how to get the latest java service wrapper?
13:20 < jrandom> but anyway, anyone have any comments on 0.5 stuff?
13:20 < protok0l> is i2p done yet?
13:20 < jrandom> http://wrapper.tanukisoftware.org/doc/english/
13:20 < deer> <eco> looking forward to the docs
13:20 < jrandom> !thwap protok0l
13:21 < jrandom> ok, moving on to 3) 0.6 status
13:21 < deer> <polecat> I still think that there ought to be a way to checksum without the gateway knowing all the checksums, or how many.
13:21 < deer> <Ragnarok> where are the documents going up?
13:21 < jrandom> polecat: I'd love it, but I doubt it can be done.
13:22 < jrandom> Ragnarok: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel.html?rev=HEAD is the current draft
13:22 < jrandom> (not updated wrt the first hop issue)
13:22 < deer> <Ragnarok> thanks
13:22 < deer> <polecat> "They said it couldn't be done.... they called me mad... but they were fools, FOOLS!
13:22 < jrandom> heh
13:22 < jrandom> hey, if you can find a way, I'm all ears
13:23 < jrandom> (and I have a feeling the mixmaster/mixminion folks will be too)
13:23 < deer> <jrandom> zounds, 42 usres here
13:23 < deer> <jrandom> mule: you 'round?
13:24 < deer> <polecat> Heh. Will keep my nose to the ground then, but no promises as I'm just a dumb ferret not geniushes like y'all.
13:24 * jrandom flings a small furry animal at polecat
13:25 -!- dm [mihi@dsl-80-42-80-26.access.uk.tiscali.com] has joined #i2p
13:25 < jrandom> ok, anyway, 0.6 stuff looks interesting, and mule has started on some hacking, but its still early on in the game
13:26 < jrandom> zab has been pretty helpful giving us some guidance from how limewire goes about things, but, well, their congestion control is kind of scary (fixed small windows, full ack)
13:26 < jrandom> (but i'm sure they'll improve in time, of course)
13:26 < jrandom> also was nice of him to give us a view into how they're having the rubber hit the road, what gotchas they've had with various jvms, etc
13:27 < jrandom> (yay zab)
13:27 < jrandom> in any case, if you're interested in helping out with the design and implementation or integration of some other provider for 0.6, get in touch with either mule or myself (or, of course, send patches ;)
13:28 < jrandom> not much else to say on that, unless anyone has anything to bring up?
13:28 < deer> <polecat> Isn't 0.6 supposed to have preliminary fusenet support?
13:28 < deer> <frosk> by april, hopefully :)
13:29 < toad_> fusenet?
13:29 < deer> <frosk> but with all this work on the udp transport, maybe it'll be ready before fusenet will
13:29 < jrandom> yeah, the general aim is just to get the ball rolling
13:29 < deer> <frosk> fusenet is a content-distribution system more or less like usenet on speed
13:29 < toad_> cool
13:30 < deer> <frosk> it will initially support blogs, discussion forums and addressbooks for i2p name-destination mappings
13:30 < jrandom> though of course, if we get the UDP transport implemented next month, we'll probably roll that out with 0.5
13:31 < deer> <frosk> of course, that would be cool :)
13:31 < jrandom> and if i had a pony, i'd play with him aaaaalll day
13:31 < jrandom> ok, thats prolly 'bout it for 0.6 stuff, moving on to 4) azneti2p
13:31 < deer> <frosk> i'm glad you have no pony, then ;)
13:31 < jrandom> heh
13:32 < jrandom> azneti2p == kickass.
13:32 < jrandom> parg & the rest of the azureus folks have done some great work, and the integration is really nice
13:33 < jrandom> torrents work the same as before, show up with all the pretty graphs, lets you do all the queueing / etc you're used to in azureus, except anonymously
13:33 < deer> <postman> w00t!
13:33 < jrandom> there are still further optimizations and simplifications left to do, but all in all, i'm quite impressed
13:33 < deer> <eco> hurray! enter the masses...
13:33 < deer> <frosk> i understand you still have to do some manual labour in the router console before you can use it?
13:33 * jrandom holds the gates closed for just a litttttle wile longer
13:33 < deer> <eco> is java 1.5 indeed required?
13:34 < deer> <polecat> Yup.. neat stuff except you can't leave it to daemon out.
13:34 < deer> <postman> sounds like the invitated for the i2p network to get his ass kicked badly
13:34 < jrandom> frosk: right - but we're working on patching it up to do the I2PTunnel calls within the plugin itself
13:34 < deer> <frosk> cool
13:34 < jrandom> eco: unsure, I only tried it with 1.5, but I believe them when they say it.
13:34 < deer> <polecat> eco: I should hope not. o.O 1.5 is just Sun trying to strongarm the market.
13:34 < jrandom> worth trying though, i'll do so later
13:35 < deer> * postman does not care, i got gigabit ethernet interfaces and LOTS of traffic included :)
13:35 < deer> <polecat> Oh dear... and azareus requires it. I _really_ have to make my C++ torrent app.
13:35 < jrandom> polecat: azureus does have a headless mode of operation, and a web console
13:36 < deer> * polecat blinks.
13:36 < jrandom> (but its... tough to the uninitiated [like myself])
13:36 < deer> <polecat> Well okay then... I thought it didn't, like KazAa
13:36 < jrandom> but i only glanced at it (and ran back to the GUI ;)
13:36 < deer> <Ragnarok> is duck going to be bringing i2p-bt up to 3.9/4.0?
13:37 < jrandom> ragnarok: unknown, but duck is currently doing leaps and bounds to keep all the existing stuff compatible with azneti2p
13:37 < jrandom> (they had to do some... odd changes due to technical requirements)
13:37 < deer> <polecat> One of the most powerful aspects of p2p is if the app can run quietly in the background whet you're not using it.
13:38 * jrandom isnt arguing with that point
13:38 < jrandom> ok, i think thats all i have to say wrt azneti2p (other than w00t, again). more info in the email, and there'll be lots of activity in #i2p-bt i'm sure
13:39 < jrandom> anyone else have anything to bring up wrt azneti2p?
13:39 < cervantes> are you ready for it... ;-)
13:40 < jrandom> heh, we're workin' on it
13:40 < deer> <polecat> Might I note that the source of azareus is totally abysmal...
13:40 < deer> <polecat> There are 28 main entry points, and it uses at least a namespace depth of 3.
13:40 < deer> <Ragnarok> does any bt client have nice source?
13:40 < jrandom> there are some oddities, but i suspect you'll find that in anyone else's source (NIH)
13:40 < deer> <polecat> Mine will.
13:40 < jrandom> oh c'mon, net.i2p.router.netdb.kademlia.* :)
13:41 < deer> <Ragnarok> not if it's in C++ it won't :)
13:41 < toad_> lol
13:41 < deer> <polecat> I said at least!
13:42 < jrandom> ok, anyway, moving us along to 5) fbsd
13:42 < deer> <polecat> Ragnarok: You've never seen how I *cough*rape*cough* use C++. n.n
13:42 * duck looks in
13:42 < deer> <polecat> Who cares about FreeBSD? Show of hands?
13:42 < jrandom> lioux has packaged up the 0.4.2.6 release into ports (w00t!)
13:42 < deer> * detonate raises his
13:42 < deer> <polecat> Paws, tentacles, wings, etc?
13:43 * jrandom raises my hand
13:43 * [dave] raises
13:43 < deer> <Ragnarok> duck: 3.9/4.0? :)
13:43 < deer> <polecat> Woah, i2p is integrated into a distribution?
13:43 < duck> Ragnarok: the lack of comments / docs / etc on the latest bram-Bittorrent changes were a bit of a setback
13:43 < fdr> FreeBSD is cool :(
13:43 < deer> <Ragnarok> I'll bet
13:43 < fdr> I may be biased though.
13:44 < jrandom> aye, i was worried at first polecat, but his ports impl looked really really easy (so updates will be really really easy)
13:44 < duck> It would require studying what they did, maybe it would be worth the effort
13:44 < deer> <polecat> As far as I'm concerned, fbsd is a distro with an odd kernel and lots of data hiding. It's all POSIX in the end so... ;)
13:44 < jrandom> polecat: and very, very w0nky JVMs
13:45 < duck> though secretly I have been hoping on azneti2p solving all problems
13:45 < deer> <Ragnarok> duck: it did sound like there were some nice improvements, but you're the one who'd probably be doing the work, so... :)
13:45 < deer> <polecat> Ugh... don't remind me.
13:45 < jrandom> heh, azneti2p will probably fit the needs of many users, but simple CLI tools will still make sense for the ubergeeks out there
13:46 < jrandom> anyway, so it seems he's tested i2p 0.4.2.6 on fbsd5.3 without problems (w00t)
13:46 < deer> <Ragnarok> oy, I don't like azureus, I'd much rather use the normal client
13:46 * jrandom has only done so on 4.8
13:46 < duck> currently I'd like to do something with kenosis; being a hit-n-run coder
13:47 < deer> <eco> jrandom: what jvm did he use?
13:47 < jrandom> kenos2p
13:47 < jrandom> eco: native compiled sun 1.4
13:47 < jrandom> (booo hiss)
13:47 < deer> <eco> ah, illegal!
13:47 < deer> <polecat> Ragnarok: If you want to critique my bittorrent client design, my current code plan is here: http://polecat.i2p/bittorrent.plan.txt
13:47 < jrandom> ((but kaffe works))
13:48 < jrandom> eco: is it illegal? I thought you could agree to the terms and get the source legit on fbsd
13:48 < deer> <eco> sun withdrew the license afaik
13:48 < jrandom> hmm, i think thats just the blackdown license
13:48 < jrandom> (and, tbh, blackdown sucks)
13:49 < jrandom> individuals can still license it under SCSL
13:49 < deer> <polecat> ouch.
13:49 < jrandom> (first born child, etc)
13:49 < jrandom> heh, its interesting to hear such license gripes when so few have copyright gripes ;)
13:50 < jrandom> but this discussion is best for the 7) ??
13:50 < jrandom> and we're on 5) fbsd
13:50 < deer> <eco> license stuff on http://www.freebsdfoundation.org/press/20041221-newsletter.shtml , but back to the main thread...
13:50 < cervantes> first time we've crept above 5) in a long time
13:51 < jrandom> cervantes: and we had to trim things ;)
13:51 < jrandom> ok, i think thats it for fbsd stuff (beyond yay!)
13:51 < jrandom> so jumping into a messy one... 6) hosts.txt as a WoT
13:51 < deer> <polecat> licensing can get you at the node though, whereas copyright vio can only be tracked to the destination.
13:51 < deer> <polecat> Which "can't" be found.
13:52 < jrandom> right right polecat, but once They have physical control of your box, you're in deep shit anyway
13:53 < jrandom> ok, anyway I'm not sure if there's much I have to add to what was posted in the email wrt hosts.txt
13:53 < jrandom> anyone have any questions/comments/concerns?
13:53 < jrandom> (was I vague enough? :)
13:53 < duck> yes
13:53 < deer> * eco considers handing hosts.txt management over to the UN
13:54 < jrandom> heh yeah, because we know nice centralized beurocratic authorities always Do The Right Thing
13:54 < toad_> lol
13:55 < jrandom> i suppose the real "big win" will be when the addressbook gets both a web interface and more metadata
13:55 < jrandom> (and perhaps the fusenet syndication, etc)
13:55 < deer> <Ragnarok> metadata will be the next thing I work on, using xml name records
13:56 < jrandom> kickass ragnarok!
13:56 < jrandom> whats your take on the WoT side ragnarok - do you see it as an issue with the addressbook, or how you forsee naming?
13:57 < deer> <Ragnarok> Essentially I think the way addressbook works (and how passing around name references on fusenet will work) is the only really sensible way to handle naming on i2p
13:58 < deer> <Ragnarok> so, the WoT is a feature :)
13:58 < jrandom> Wo0T
13:58 < lucky> whoa
13:58 < deer> <eco> but surely you sell premium accounts?
13:58 < lucky> is that a toad i see?
13:58 < lucky> a real toad?
13:58 < lucky> or just a frog.
13:58 < deer> <frosk> the important point imho, is how to handle collisions
13:59 < toad_> a toad
13:59 < deer> <detonate> first come, first serve
13:59 < jrandom> right frosk, it'd be nice to have an interface to manage those, rather than just "read the log"
13:59 < deer> <Ragnarok> frosk: I think that's more an issue of interface than anything else. Collisions will have to be resolved by the user.
13:59 < toad_> call my name if it gets close to my area :)
13:59 < deer> <frosk> Ragnarok: my thinking too
13:59 < deer> <Ragnarok> anything else can be attacked
13:59 < lucky> oh, not the freenet toad.
13:59 < lucky> oh
13:59 < lucky> it is.
13:59 < deer> <eco> so the names are simply like aliases in IM?
14:00 < deer> <frosk> collisions need to be stored so you can switch long after the fact
14:00 < deer> <Ragnarok> and is probably not provably better in the general case
14:00 < lucky> we're paying toad now?
14:00 < jrandom> eco: right - the names are just private local nicknames
14:00 < deer> <susi23> the addressbook should recognize collisions and notify the user so he can decide
14:01 < deer> <Ragnarok> frosk: after the switch to name records, the intent is to never throw them away, but make it easy to change the address they correspond to
14:01 < deer> <susi23> until the user made his decision any changes regarding the collision should somehow get "quarantined" :)
14:01 < deer> <Ragnarok> susi23: that's essentially how it works now
14:01 < deer> <Ragnarok> it just has a lousy interface
14:01 < deer> <frosk> Ragnarok: sounds good :) do you have a web interface in the works? (or is there one already i'm not aware about?)
14:02 < deer> <susi23> fine then
14:02 < deer> <Ragnarok> nope. I don't do web interfaces :)
14:02 < deer> <Ragnarok> susi was working on something, I think, but I'm not sure what's happened with that
14:02 < jrandom> (volunteers? any chance of reviving susidns to manage the names?)
14:03 < deer> <susi23> ok, give me a week, I put it on TODO
14:03 < jrandom> (and after susidns, we need susitorrent and susiirc...)
14:03 < jrandom> wikked!
14:04 < jrandom> ok, anyone have anything else to bring up wrt that whole hosts.txt thing?
14:05 < jrandom> if not, moving on to 7) ???
14:05 < deer> <Ragnarok> one thing
14:05 < jrandom> you've got the mic
14:05 < deer> <Ragnarok> for the next release, can we agree that hosts.txt should be managed directly by addressbook, so we can stop mangiling userhosts.txt?
14:06 < jrandom> sounds reasonable. i'll stop shipping hosts.txt in the i2pupdate.zip (but will include it in i2pinstall.jar)
14:06 < deer> <Ragnarok> cool. That's all :).
14:07 < jrandom> ok, now back to the opne floor
14:07 < jrandom> anyone else have anything they want to bring up?
14:07 < deer> <postman> yes
14:07 < jrandom> hit it postman
14:07 < deer> * postman raises his hand
14:08 < deer> * postman is desperately looking for a volunteer providing the secondary MX server for i2pmail.org ( this being an inproxy to the internal mailsystem )
14:09 < deer> <postman> if anyone got a stable, fast (dedicated) machine, i would be very happy to accept help
14:09 < deer> <postman> configuration / howto will be delivered by me
14:09 < deer> <eco> how fast is fast?
14:10 < deer> <postman> eco: static IP wuld be nice - everything else is negotiable
14:10 < jrandom> how much traffic are you seeing through mail.i2p postman?
14:10 < jrandom> (external, that is)
14:10 < deer> <polecat> Stable, fast, dedicated... well 1/3 isn't bad.
14:10 < deer> <postman> the mailtraffic is VERY low
14:10 < deer> <postman> in/out is about 500 mails / month
14:11 < jrandom> ah cool
14:11 < deer> <Frooze> i have slow (500 MHz), stable, dedicated
14:11 < deer> <postman> BUT since the inproxy will have a I2P running
14:11 < jrandom> (that'll probably pick up as more people find out about it though ;)
14:11 < deer> <eco> the machine would be for incoming mail only?
14:11 < deer> <postman> most traffic would be I2p i guess
14:12 < deer> <postman> eco: at least incoming ( it's needed for this )
14:12 < deer> <postman> if the operator is ok with that i would like to rotate outgoing over both machines
14:12 < deer> <postman> Frooze: it's ok, when it's able to run i2p
14:13 < deer> <postman> just drop me a mail
14:13 * toad_ wonders if his current issues are AOB business or if they are simply between him and jrandom
14:13 < deer> <postman> if anyone is interested
14:14 < deer> * postman hands back the mike
14:14 < deer> <Frooze> will do.
14:14 < deer> <postman> thanks jr :)
14:14 < jrandom> cool, thanks postman
14:14 < jrandom> toad_: i think there's much to be discussed, though largely a question for the freenet folks
14:15 < toad_> jrandom: right
14:15 < toad_> jrandom: talk after meet
14:15 < jrandom> sounds good
14:15 < duck> no public mudfight? :/
14:15 < jrandom> ok, anyone else have anything to bring up for the meeting?
14:15 < jrandom> heh duck
14:15 < deer> * eco points at http://dodo.freenetproject.org/pipermail/tech/2005-January/001224.html
14:15 < jrandom> (that was on tehc ;)
14:15 < cervantes> postman: my box has too much shit running on it to be any help I'm afraid ;-)
14:15 < deer> <polecat> Ragnarok: If we could sign the addressbook host data, that would allow for automatic updates. Otherwise not much to be done. Even if the user gets a popup, how are they to tell which key is accurate?
14:15 < deer> <Ragnarok> what does accurate mean?
14:16 < jrandom> polecat: signing entries would Kick Fucking Ass.
14:16 < deer> <eco> fyi
14:16 < deer> <eco> no mud involved.
14:16 < deer> <Ragnarok> (and signing is planned for name records)
14:16 < deer> <postman> cervantes: hi, thanks anyway :)
14:16 < cervantes> you are indeed very welcome
14:16 < cervantes> :P
14:17 < jrandom> ok, anything else?
14:17 < deer> <polecat> Ragnarok: accurate means centered around the correct result.
14:17 < cervantes> polecat: I'm waiting for one of my clients to go bust before I sneak into one of their forgotten mailservers to install i2p
14:18 < deer> <Ragnarok> polecat: yes, but what's the correct result?
14:18 < jrandom> lol cervantes
14:18 < cervantes> %s/polecat/postman
14:19 < deer> <polecat> The addressbook file that gets sent between eepsites could do the signing in its format, keeping the other hosts.txt the same.
14:19 * duck wonders if updating dot.png is useful?
14:19 < duck> it got kind of full
14:19 < deer> <eco> give us a 3d applet
14:20 < jrandom> duck: its a bit hard to read yeah ;)
14:20 < jrandom> duck: perhaps only list the blue lines?
14:20 < jrandom> to me, the value comes from seeing how spread out green is
14:20 < jrandom> (or whether there are clusters of dark green, etc)
14:20 < deer> <Ragnarok> polecat: signing will be supported in the xml name record format.
14:21 < deer> <polecat> Ragnarok: The correct result is that the human readable name maps to the destination you expect to see, and only changes when the owner of that destination changes keys.
14:21 < deer> <polecat> Right. So... great. No problem then.
14:21 < deer> <Ragnarok> polecat: that's what we've got now
14:22 < deer> <polecat> If the signature of an update matches the original record's public key then you can update automatically, no problem.
14:24 < jrandom> ok, there's still room left to be hashed out on the Great Naming Debate, of course
14:24 < jrandom> anyone have anything else for the meeting?
14:24 < deer> * eco has a UI poll
14:24 * jrandom has a GUI
14:25 < deer> <Ragnarok> polecat: that will be supported once we've got signing :)
14:25 < deer> <eco> the i2ptunnel option in the web ui results in a popup - am i the only one less enthusiastic about that?
14:25 < jrandom> definitely not the only one eco.
14:25 < jrandom> i wrote the i2ptunnel web interface approximately as poorly as i could
14:25 < jrandom> it really, really sucks
14:25 * cervantes steals jrandom's "patches welcome" line
14:26 < jrandom> (what cervantes said :)
14:26 < jrandom> or even just plain HTML, i can integrate it with the jsp
14:26 < jrandom> (but of course patches to the jsp would be nice)
14:27 < cervantes> jrandom: btw I have a patch for what we discussed yesterday...just going to test it a little more first....
14:27 < jrandom> ah wikked cervantes, thanks!
14:27 < deer> <eco> why not list that in the main page, like the other pages?
14:27 < deer> <eco> ok, so no big religious or technical reason behind it?
14:28 < deer> * polecat has a FUI
14:28 < jrandom> eco: from a UI perspective, it can be made to look like the other pages, but not technically
14:28 < jrandom> technically, it needs to stay seperate as a client app deployed as a seperate .war file
14:28 < deer> <polecat> Ragnarok: I thought you said that's what we've got now?
14:29 * jrandom appreciates very much mihi's contribution of that code, but I can't let the i2p console depend upon GPL
14:29 < deer> <Ragnarok> er, sorry, I meant everything but the signing, which obviously we don't do right now.
14:29 < jrandom> (but we can make it look like the other pages
14:30 < deer> <eco> ah, license issues. great
14:30 < jrandom> heh isn't it grand eco?
14:30 < deer> <Ragnarok> so currently addresses are never updated automatically, changing the destination an address points to always requires user intervention
14:30 < cervantes> jrandom: iframe :P
14:30 * jrandom wishes people just saw the IP farse for what it was and released into the public domain
14:30 < deer> <eco> but in this case a socket connection for example should be okay GPL-wise i'd guess
14:30 < jrandom> cervantes: not an impossible alternative
14:30 < jrandom> right eco
14:31 < jrandom> we've done our best to tap dance around the integration of the actual meat (using clients.config and i2ptunnel.config), but the web UI suffers a bit from it
14:33 < deer> <susi23> any wishes, feature requests, and comments regarding the addressbook interface please add to http://susi.i2p/susidns.html
14:33 * toad_ respects jrandom's extremist licensing views while disagreeing vehemently with them :)
14:33 < jrandom> oh cool, shall do susi23
14:34 < jrandom> heh toad_ :)
14:34 < deer> * eco puts it on his when-i'm-64-to-do-list
14:34 < toad_> bbiab
14:34 < jrandom> l8r
14:34 < toad_> when i get back we need to talk about various technical issues with i2p/freenet integration
14:34 < jrandom> ok, anyone else have anything for the meeting?
14:34 * cervantes wheels out the metal gong
14:34 < toad_> will try to get back quickly
14:34 < jrandom> cool toad_, i'll be around
14:34 < jrandom> (it'll give me time to catch up on those threads ;)
14:35 * jrandom winds up
14:35 * jrandom *baf*s the gong, closing the meeting
14:35 < deer> <DrWoo> jrandom: I have one issue if you're still open to 7)??? , I just want to go back to the azureus plug-in for a moment if I may, #1 - this will be *quite* appealing to the peeps, isn't this the perfect time to try to get easy tunnel length controls into the p2p side of I2P via this plug-in, to try to make the best use of bw resources on the net? #2 - having a working azureus plug-in will (very likely?) cause some publicity whether you want it or not,
14:35 < dm> i2p/freenet integration!?
14:35 * jrandom de-gongs
14:35 * cervantes puts the gong away
14:35 < jrandom> #1: yes, absolutely - I've sent parg a patch to do that
14:36 < jrandom> #2: [got trimmed @ 'want it or not,']
14:38 * jrandom watches the irc streaming lib logs -
14:38 < jrandom> 14:37:55.701: SEND bRC43g==QRnB~Q==: #2 DELAY 1000 MS ACK 1 data: 29 sent 2 times
14:38 < jrandom> 14:38:20.072: SEND juVFdg==aAUIVw==: #3465 DELAY 1000 MS ACK 5723 data: 43 sent 2 times
14:40 < deer> * eco grabs a beer
14:40 < deer> <DrWoo> jrandom: #2 - having a working azureus plug-in will (very likely?) cause some publicity whether you want it or not, are you prepared for a user influx, and if not when do you think you will be?
14:40 < jrandom> it would not be good to have a large burst of users prior to the UDP transport
14:41 < jrandom> there is still a lot of work to be done on azneti2p, so hopefully that'll buy us some time, but we'll do what we need to do
14:41 < deer> <DrWoo> jrandom: cool to see your all over #1 ;)
14:42 < jrandom> we also will need some docs for #1 too, explaining why 0 hops works for some threat models :)
14:44 < jrandom> ok, we ready for a re-gong?
14:45 * jrandom winds up
14:45 * jrandom *baf*s the meeting closed^2

10
i2p2www/meetings/124.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, January 11, 2005
=================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,284 +1,278 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 125{% endblock %}
{% block content %}<h3>I2P dev meeting, January 18, 2005</h3>
<div class="irclog">
13:04 < jrandom> 0) hi</p>
13:04 < jrandom> 1) Net status</p>
13:04 < jrandom> 2) 0.5</p>
13:04 < jrandom> 3) i2pmail.v2</p>
13:04 < jrandom> 4) azneti2p_0.2</p>
13:04 < jrandom> 5) ???</p>
13:04 < ant> &lt;duck&gt; (the sound of the crypto talk flying past my ears)</p>
13:04 < jrandom> :)</p>
13:04 * jrandom waves</p>
13:04 < cervantes> 'lo</p>
13:04 < jrandom> you too can listen to the sound of crypto talk flying past your ears! weekly status note posted @ http://dev.i2p.net/pipermail/i2p/2005-January/000559.html</p>
13:05 < bla> hi</p>
13:05 < jrandom> jumping on in, since we're cutting into an interesting discussion anyway... 1) net status</p>
13:05 < jrandom> i dont really have anything to add beyond whats in the mail - anyone have anything they want to bring up wrt the net status?</p>
13:06 < bla> Other that we have, for the first time, seen nodes on *all* continents except Antarctica, no.</p>
13:06 < jrandom> w00t!</p>
13:07 < jrandom> ok, moving on to 2) 0.5 stuff</p>
13:07 < mule> hey, my father is just on his way to antarctica, should have given him a node</p>
13:07 < ant> &lt;duck&gt; bloody Antarticans</p>
13:07 < Xan> no antarcticans? :(</p>
13:07 < jrandom> hah nice</p>
13:07 < jrandom> though i dont think there's much of an anonymity set up there </p>
13:07 < Frooze> blame antarctica</p>
13:08 * cervantes sets up an oil rig in antartica so he can finance a node there</p>
13:09 < jrandom> ok ok, there's a lot of 0.5 stuff, so we can take it in pieces</p>
13:09 < jrandom> first up, thanks to the folks who gathered a days worth of stats - lots of interesting data @ http://dev.i2p.net/~jrandom/messageSizes/</p>
13:09 < postman> it was a pleasure :)</p>
13:10 < cervantes> wrt net status...seen quite a few people having troubles getting I2P up and running lately (on the forums etc) - I don't know if that's just down to increase user volume or perhaps more i2p based apps for things to go wrong with</p>
13:10 <+protokol> jrandom: LIAR! you said the data was interesting!</p>
13:10 * jrandom flings mud at protokol </p>
13:11 < ant> &lt;duck&gt; cervantes: I have also seen reports of ppl able to get it up and running within a couple of minutes</p>
13:11 < ant> &lt;duck&gt; I think that NAT is causing most problems</p>
13:11 < cervantes> duck: true...</p>
13:11 < ant> &lt;dmdm&gt; who is NAT?</p>
13:11 < jrandom> cervantes: there are some ugly issues still, certainly. the NAT issue and osx has been a bit of a pain lately, but Jhor's help with the later should improve the later</p>
13:12 < cervantes> aye</p>
13:12 < cervantes> *cough* so... 0.5</p>
13:13 < Xan> dmdm: network address translation</p>
13:13 < jrandom> heh, ok. basically the drive with those message size stats is to explore the padding issues </p>
13:14 < jrandom> unfortunately, the strategy i built by cherry picking numbers sucked, giving a 25% overhead just with padding data</p>
13:14 < jrandom> if we go with one of the proposals for the 0.5 encryption (tunnels-alt.html), we won't have that issue</p>
13:15 < jrandom> (since it'll force small fixes sizes with fragmentation)</p>
13:15 < mule> what type of messages do you want to pad, those a router sees or those an external observer sees?</p>
13:15 < jrandom> mule: important question</p>
13:15 < jrandom> if we're just worried about the external observer, we can leave the messages unpadded, doing any chaff generation at the transport layer</p>
13:16 < Teal`c> http://microsoft.i2p/david_hasselhoff_05_christmas_album__silent_night.mp3</p>
13:16 < jrandom> otoh, if we're worried about tunnel participants doing flow analysis, we need to worry about padding down the tunnel</p>
13:16 <@duck> with 5-6 hops, how big is the danger of a router doing traffic analysis?</p>
13:16 < cervantes> Teal`c: meeting atm... can you use #i2p-chat for mp3 announce ;-)</p>
13:17 < Teal`c> sorry</p>
13:17 < cervantes> :) for david hasselhoff?</p>
13:18 < jrandom> depends upon what level of analysis duck. if they've somehow tracked down what tunnel they're in (e.g. they're the inbound tunnel gateway and have harvested the netDb, correlatign that with a destination), thats nontrivial data. otoh its not a direct exposure, but does give some info</p>
13:18 < jrandom> even more than the tunnel padding though is end to end padding, hiding message flow data from gateways and endpoints.</p>
13:19 < jrandom> if we're crazy/stupid, we could go all the way to a pipenet, using constant bitrate everywhere</p>
13:19 <+polecat> I got it!</p>
13:19 < jrandom> (and end up with no users running i2p)</p>
13:19 <+polecat> What we need to do is tunnel i2p over email!</p>
13:19 < cervantes> what's the likelyhood of colluding routers ending up in the same tunnel on a sufficiently large network?</p>
13:19 <+polecat> No ISP would be dumb enough to stop email!</p>
13:20 * jrandom awaits the net.i2p.router.transport.gmail implementation</p>
13:20 < postman> polecat: gee , this is silly </p>
13:20 < postman> :)</p>
13:20 < bla> cervantes: N^(-h) (N is # of fast nodes, h = # hops). It seems</p>
13:20 <+polecat> =3 I know.</p>
13:21 < cervantes> is that a lot? :)</p>
13:21 < jrandom> not the # of fast nodes, as external people won't know your profiles</p>
13:21 <+polecat> Seriously though, in shameless abuse of existing IP services, we could tunnel i2p in any number of ingenious ways.</p>
13:21 < jrandom> c^2/N^h to get two peers into the same tunnel</p>
13:21 < jrandom> agreed polecat. thats one of the reasons why we don't have bidirectional tunnels</p>
13:22 < jrandom> some transports (e.g. email) suck for bidirectional comm</p>
13:22 < bla> jrandom: c = ?</p>
13:22 < jrandom> c==# colluding peers</p>
13:23 <+polecat> Hm, interesting point.</p>
13:23 < ant> &lt;duck&gt; roadmap wise, what is the impact of i2p going a wrong direction and picking a wrong crypto solution?</p>
13:23 <+polecat> Or carrier pigeon protocol, not bidi in the slightest.</p>
13:23 <+polecat> crypto is modular already, isn't it?</p>
13:23 < jrandom> duck: its just one bullet point out of 0.5, and one subsection of the tunnels*.html doc. theres lots more to the tunnel routing than just how we wrap the data</p>
13:24 < bla> jrandom: Then again, this is the prob. for getting them in the tunnel *now*. However, over T tunnel refreshments (every so many minutes), this goes as P = 1 - (1 - c^2/N^h)^T</p>
13:24 < jrandom> otoh, the difference between "fixed 1KB blocks" and "0-40KB blocks" has substantial impact</p>
13:24 <+polecat> I'd hate to see this network go the way of Entropy, stuck in McEliece.</p>
13:24 < jrandom> polecat: read http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD</p>
13:24 < bla> jrandom: And thus tends to zero for large enough time. I.e.: for large enough time, the attackers will be in the same tunnel at last one time</p>
13:25 < jrandom> the plan is standard AES256/CBC</p>
13:25 <+protokol> i hear dns is good for tunneling stuff, most people dont block it</p>
13:25 < jrandom> certainly bla, though its not quite that direct (for exploratory tunnels it is, but not for client tunnels)</p>
13:26 <+polecat> And if somehow even AES gets cracked, some equivalent symmetric cipher.</p>
13:27 < jrandom> bla: i dont think its large enough of a practical worry for most cases in that degree, but when you mount it as part of a predecessor attack, the issue is largely moot</p>
13:28 < jrandom> (because of the way we do the rest of the tunnel routing)</p>
13:28 < bla> jrandom: k</p>
13:28 < jrandom> right polecat </p>
13:29 < jrandom> duck: if we go w/ the second option, changing to another later will likely be easy. </p>
13:29 < jrandom> otoh, the second option will require some hefty performance tuning to Not Suck</p>
13:29 < jrandom> but i'm sure we can pull it off</p>
13:31 < jrandom> anyway, I think the above covers where we are right now wrt 0.5 work</p>
13:31 < jrandom> does anyone have any more questions/comments/concerns?</p>
13:31 < bla> jrandom: One</p>
13:32 < bla> jrandom: I think we should values anon. slightly more than performance atm: so yes, the PRNG options sounds good</p>
13:33 < jrandom> agreed. performance can be tuned later, "adding in" better anonymity however, is much harder</p>
13:33 < jrandom> (but, of course, performance /is/ a security parameter. if it Sucks, no one uses it)</p>
13:33 < bla> Yes.</p>
13:33 < bla> jrandom: </p>
13:33 < bla> sorry</p>
13:33 <@duck> right, /me flips the magical Freenet-performance bit</p>
13:33 < cervantes> perhaps it'll deter all those torrent waving leechers to stay away a while longer ;-)</p>
13:34 < jrandom> heh</p>
13:34 < cervantes> &lt;-- connection reset</p>
13:34 < bla> cervantes: No, I'm not! :)</p>
13:34 < cervantes> :)</p>
13:35 < jrandom> i do think that we can pull off some really cool optimizations, and it seems a lot of our choke is not related to the peer selection, but merely (heh) bugs in the jobqueue</p>
13:36 < jrandom> but, anyway, anything else for 2) 0.5?</p>
13:36 < ant> &lt;BS314159&gt; could you post an explanation for this loop attack?</p>
13:37 < ant> &lt;BS314159&gt; it sounds more dangerous than your treatment implies it is</p>
13:37 < jrandom> loop: build a tunnel containing A--&gt;B--&gt;C--&gt;D--&gt;C, send in 10 messages.</p>
13:37 < jrandom> without the PRNGs, you can add as many messages to that C&lt;--&gt;D loop as you want</p>
13:38 < ant> &lt;BS314159&gt; ok</p>
13:38 < jrandom> effectively DoSing any routers with just a few messages</p>
13:38 < ant> &lt;BS314159&gt; but only A can do this</p>
13:38 < jrandom> with the PRNGs, it limits the number of messages that can go into the loop</p>
13:38 < ant> &lt;BS314159&gt; so there's no danger of an attacker shortening my tunnels by introducing loops</p>
13:38 < jrandom> no, no one can shorten your tunnels</p>
13:39 < jrandom> the only thing this is useful for is a DoS</p>
13:39 < jrandom> (a very cheap DoS)</p>
13:39 < jrandom> (but when you can selectively DoS peers without much cost, you can do naaaasty stuff)</p>
13:40 < ant> &lt;BS314159&gt; comprendo</p>
13:40 <+protokol> and hashcash certs will help this?</p>
13:40 < jrandom> protokol: hashcash addresses the issue of a peer building too many tunnels, and perhaps building too many hops</p>
13:41 < jrandom> protokol: it doesnt help with loops. the two ways i could find that /did/ were the PRNGs (tunnel-alt.html) or verifying at each step (tunnel.html)</p>
13:42 < jrandom> verifying at each step has dangers, so the current leaning is towards the PRNGs</p>
13:42 <+Ragnarok> how effective will the prng method be?</p>
13:42 < Xan> A--&gt;B--&gt;C--&gt;D--&gt;C - shouldnt each hop get a different id or something, so that messages leave the tunnel the second time they reach C rather than looping?</p>
13:43 < jrandom> Xan: they do, but without verifying each step, you can't tell whether its bad or not</p>
13:44 < jrandom> Ragnarok: i think it'll be very effective at minimizing the damage done</p>
13:45 < jrandom> at least, from what I can see so far</p>
13:45 < jrandom> if anyone sees any problems/issues with it, or suggestions for improvement, please get in touch :)</p>
13:46 < Xan> or maybe Im missing the point</p>
13:46 < Xan> bbl</p>
13:46 < jrandom> 'k l8r, i'll update the doc to be more clear </p>
13:47 < jrandom> ok, unless there's something else, shall we move on to 3) i2pmail.v2?</p>
13:47 < jrandom> postman: you 'round?</p>
13:48 < postman> yes</p>
13:49 < postman> :)</p>
13:49 < jrandom> anything to add from your post on the forum? it sounds pretty cool</p>
13:49 < postman> well, a few of you might have read the draft for i2pmail.v2 already</p>
13:50 < bla> wtf is happening? Massive disconnects. I've got trouble reaching sites (say orion, library) here too</p>
13:50 < postman> it aims towards a fully decentralized mail infrastructure in the future</p>
13:50 < postman> but is in need of proxysoftware on the nodes as well as a bunch of dedicated relays</p>
13:51 < postman> all are invited to contribute ideas / concepts / rants</p>
13:51 < postman> development already has started - dont expect anything before late spring :)</p>
13:51 < jrandom> w00t</p>
13:51 < kaji> hmm, the cops just showed up at my door</p>
13:52 < bla> kaji: ?</p>
13:52 < jrandom> quick, blow your hard drive</p>
13:52 < postman> jrandom: well, this is all i have to say for now :) </p>
13:52 < cervantes> hide the blackjack table!</p>
13:52 < jrandom> wikked, thanks postman </p>
13:52 < kaji> they said i dialed 911, but im quite sure neither i nor my brother did</p>
13:53 <+protokol> kaji: they're just checking up on i2p</p>
13:53 < jrandom> ok, unless there's anytihng else on 3) i2pmail, lets move over to 4) azneti2p_0.2</p>
13:53 <+protokol> &lt;creepy music&gt;</p>
13:53 < jrandom> as mentioned in the email, there's been some important progress lately</p>
13:53 < kaji> then they said cordless phones can freak out when off the hook, but all my cordless phones are on their charger -&gt; #i2p-chat</p>
13:55 < jrandom> the azureus folks have been very responsive in getting an update ready (yay!), but people should also be on the lookout for problems</p>
13:55 < jrandom> (if you don't read the i2p mailing list and use azneti2p, read the i2p mailing list)</p>
13:55 < jrandom> ((or even if yuo dont use azneti2p, read the list, as thats where we announce important things ;)</p>
13:56 < jrandom> duck and orion have also been making lots of updates to accomodate the new bt client and formatting</p>
13:56 < jrandom> (yay!)</p>
13:56 * orion smiles</p>
13:57 < orion> theres still a ways to go, but for now, it works.</p>
13:57 < jrandom> (inasmuch as i2p lets it ;)</p>
13:58 < orion> hehe, yes. ;)</p>
13:58 < jrandom> does anyone else have anything to bring up wrt azneti2p or i2p-bt?</p>
13:58 < jrandom> (or bytemonsoon2p ;)</p>
14:00 < jrandom> ok if not, moving right along to 5) ???</p>
14:00 < jrandom> open floor - anyone else have anything to bring up? </p>
14:00 < postman> jrandom: why does the addressbook publich userhosts entries ?</p>
14:01 < jrandom> postman: bug. </p>
14:01 < postman> so this was no planned behaviour and will be changed?</p>
14:01 < cervantes> just one thing...</p>
14:01 < jrandom> postman: correct, and will be changed</p>
14:02 < jrandom> (right Ragnarok? :)</p>
14:02 <+Ragnarok> depends on exactly what postman means...</p>
14:03 < jrandom> Ragnarok: new entries added by the local user to their own private hosts shouldn't be propogated to the hosts published</p>
14:03 < jrandom> (e.g. userhosts.txt is private, hosts.txt is synchronized with other people and is public)</p>
14:03 < cervantes> As part of a semi regular slot on the forum, there will be recognition and awards for those that have contributed good things to I2P either recently or over the project's lifetime</p>
14:03 < postman> Ragnarok: after updating to 0.4.2.6 i found entries from my userhosts.txt in the published addressbook in my eepsite folder</p>
14:03 < ant> &lt;BS314159&gt; hmm</p>
14:04 < postman> Ragnarok: those have been manually added keys, which haven't been supposed to be published</p>
14:04 < cervantes> this week we recognise duck for general excellence as a service provider for the community and as an all round great idler: http://forum.i2p/viewtopic.php?t=275</p>
14:04 < jrandom> w00t!</p>
14:04 < jrandom> (go duck go, go duck go)</p>
14:05 < Teal`c> what about domain name hijacking ?</p>
14:05 * brachtus applauds</p>
14:05 * orion does a duck waddle as a sign of respect.</p>
14:05 < cervantes> one important point for the future...you don't have to be a cryptographic genius to get praise!</p>
14:06 <+Ragnarok> no, that's expected behaviour. I can change it, but first I'll have to finish implementing file locking so you can change hosts.txt directly</p>
14:06 < orion> (but it helps)</p>
14:06 < cervantes> you might just have contributed a cracking eepsite or something...</p>
14:06 < cervantes> or been a helpful bod on the forum etc</p>
14:07 < ant> &lt;BS314159&gt; hmm</p>
14:07 < cervantes> (otherwise, lets face it, jrandom would win every week)</p>
14:07 < jrandom> hey, y'all are paying for my beer fund, this stuff aint free ;)</p>
14:07 < ant> &lt;BS314159&gt; could you just make a new file, "publichosts.txt"?</p>
14:07 < ant> &lt;BS314159&gt; then have addressbook ignore userhosts.txt, but allowed users to subscribe to their own publichosts.txt?</p>
14:08 < jrandom> Teal`c: there is no way to hijack a domain name, no entries are overwritten, and userhosts always overrides hosts</p>
14:09 < jrandom> Ragnarok: perhaps the web interface can address the locking issue, since users won't be adding to the files manually</p>
14:09 <+Ragnarok> once the locking is done, there's no real reason to pull in addresses from userhosts.txt anymore (it's currently the only way to dodge a race), so there's no real point in adding a third file</p>
14:10 <+Ragnarok> jrandom: well, I was planning on using the java file locking api</p>
14:10 < jrandom> if you think its necessary, you're the boss :)</p>
14:10 < ant> &lt;BS314159&gt; it would allow you to kill all the names gotten from other people while keeping the ones you made yourself</p>
14:10 < ant> &lt;BS314159&gt; simply by clearing hosts.txt and changing your subscriptiong</p>
14:11 < ant> &lt;BS314159&gt; but I guess that can wait for name-signing</p>
14:11 < orion> metadata will solve this problem. Is a spec drafted yet?</p>
14:11 < jrandom> using just two files should be fine - one managed by the addressbook, one not</p>
14:12 < jrandom> (you could even have the addressbook ignore userhosts.txt entirely - userhosts.txt overrides hosts.txt anyway)</p>
14:12 <+Ragnarok> jrandom: that would be the plan, once locking is done (which really shouldn't be too much work, I just haven't gotten around to it :)</p>
14:13 <+Ragnarok> and I'm currently working on learning enough xml schema to write one for the namerecords</p>
14:13 < ant> &lt;dr_kavra&gt; is this the channel for kenosis? another channel told me to come here :D</p>
14:13 < jrandom> lol</p>
14:13 < jrandom> nah, sorry, this is i2p</p>
14:14 < jrandom> (unless you're looking for an anonymous comm layer)</p>
14:14 < jrandom> wikked Ragnarok </p>
14:14 < ant> &lt;BS314159&gt; I still the XML is too verbose and non-human-readable for this, compared to YAML, but I'm not the one writing the code</p>
14:14 < jrandom> Ragnarok: the tough part will be doing the crypto w/ XML without reverting to ugly CDATA</p>
14:14 < orion> anybody write a working draft for the metadata spec yet?</p>
14:15 < jrandom> (i personally think xml sucks, but i'm just a naysayer)</p>
14:15 < jrandom> orion: http://dev.i2p.net/pipermail/i2p/2004-February/000135.html has a basic setup</p>
14:15 < orion> (name/key metadata)</p>
14:15 < dox> has the addressbook and its features been announced somewhere? I didn't know my hosts.txt is published</p>
14:15 < jrandom> (see NameReference and LocalEntry elements)</p>
14:16 < jrandom> dox: its written to the location specified in addressbook/config.txt</p>
14:16 < jrandom> (by default, ./eepsite/docroot/hosts.txt)</p>
14:17 < orion> is missing a public/private (i.e. distribute, don't) flag.</p>
14:17 < ant> &lt;cervantes&gt; the only good thing about XML (and this is a large + point) is that it's a widely accepted standard</p>
14:17 < jrandom> right orion, lots of good ideas have come up since that post</p>
14:17 <+Ragnarok> xml may suck, but frankly, it better than any of the alternatives for what I'm doing</p>
14:17 < jrandom> cervantes: so is EDI</p>
14:17 < orion> is there a place to condense them? i.e. forum area?</p>
14:18 < orion> or maybe a wiki page?</p>
14:18 < jrandom> orion: susi's or ugha's wiki</p>
14:18 < orion> I'm going to set up wikis for bytemonsoon and orion.i2p to help get some community consensus as to the future development goals of each.</p>
14:18 < BrockSamson> xml + crypto w/o CDATA = mime, no?</p>
14:19 < jrandom> wikked orion </p>
14:19 < jrandom> BrockSamson: smime, with different parsers ;)</p>
14:19 < orion> (also one for name metadata)</p>
14:21 < jrandom> there are lots of ways to do the metadata, the important thing is flexibility and 'correctness' so that it can grow or change over time</p>
14:21 * jrandom is sure Ragnarok et al will come up with some good stuff :)</p>
14:21 < orion> thats why I think a public draft is in order.</p>
14:22 < ant> &lt;cervantes&gt; i2p consortium :P</p>
14:22 < jrandom> well, people have been saying "someone should put up their ideas on the wiki" for the last few meetings, but the wiki pages aren't growing too much ;) which is fine, we take the pace we take</p>
14:23 * orion promises to have three wikis up within a day and email everyone their locations</p>
14:23 < BrockSamson> call me lazy, but compare an ANSI 850 Purchase order EDI to nearly any other XML based purchase order, and i'd rather decode, code, and debug for the XML version. Even if it's 5x the EDI size</p>
14:23 < jrandom> w00t</p>
14:23 < jrandom> heh BrockSamson </p>
14:24 < BrockSamson> Position 10 is ST? oh then position 310 should be name</p>
14:24 < BrockSamson> duh me</p>
14:24 < jrandom> BrockSamson: don't think the xml schemas for POs are much better ;)</p>
14:24 < jrandom> (but yeah, that stuff is just a totally bloody disaster)</p>
14:25 < BrockSamson> they are at 4:30 in the morning</p>
14:25 < BrockSamson> unless...</p>
14:25 < jrandom> heh</p>
14:25 < BrockSamson> it's written by an ex EDI programmer</p>
14:25 < BrockSamson> and the xml looks like this: &lt;p1&gt;&lt;po&gt;&lt;q&gt;1&lt;/q&gt;&lt;/po&gt;&lt;/p1&gt;</p>
14:26 < BrockSamson> i bet though, if you add up the horuse OpenSource projects spend talking about to 'XML' or not 'XML' you could code linux 10x over.</p>
14:26 < BrockSamson> every project i've ever been part of has had massive debates on it</p>
14:27 < orion> debates are good for a project, depending on who's debating. ;)</p>
14:27 < jrandom> eh, it does what it does, but its not a panacea. it may work well for the naming stuff</p>
14:28 < BrockSamson> many people are in projects just to debate though.</p>
14:28 < jrandom> not here. i'm here for the free beer</p>
14:28 < ant> &lt;cervantes&gt; that's debatable</p>
14:28 < orion> the implementation details will be clearer when the draft spec is more tangable.</p>
14:28 < orion> hence the need for a wiki/peer review.</p>
14:29 < BrockSamson> I heard this project gave away free Garlic</p>
14:29 < jrandom> lots of it</p>
14:30 < jrandom> ok, anyone else have anything to bring up for the meeting?</p>
14:30 < ant> * cervantes wheels out the ceremonial call with bell</p>
14:30 < ant> &lt;cervantes&gt; call =cow</p>
14:30 * jrandom winds up</p>
14:31 * jrandom *baf*s the cowbell, closing the meeting</p>
</div>
{% endblock %}
13:04 < jrandom> 0) hi
13:04 < jrandom> 1) Net status
13:04 < jrandom> 2) 0.5
13:04 < jrandom> 3) i2pmail.v2
13:04 < jrandom> 4) azneti2p_0.2
13:04 < jrandom> 5) ???
13:04 < ant> <duck> (the sound of the crypto talk flying past my ears)
13:04 < jrandom> :)
13:04 * jrandom waves
13:04 < cervantes> 'lo
13:04 < jrandom> you too can listen to the sound of crypto talk flying past your ears! weekly status note posted @ http://dev.i2p.net/pipermail/i2p/2005-January/000559.html
13:05 < bla> hi
13:05 < jrandom> jumping on in, since we're cutting into an interesting discussion anyway... 1) net status
13:05 < jrandom> i dont really have anything to add beyond whats in the mail - anyone have anything they want to bring up wrt the net status?
13:06 < bla> Other that we have, for the first time, seen nodes on *all* continents except Antarctica, no.
13:06 < jrandom> w00t!
13:07 < jrandom> ok, moving on to 2) 0.5 stuff
13:07 < mule> hey, my father is just on his way to antarctica, should have given him a node
13:07 < ant> <duck> bloody Antarticans
13:07 < Xan> no antarcticans? :(
13:07 < jrandom> hah nice
13:07 < jrandom> though i dont think there's much of an anonymity set up there
13:07 < Frooze> blame antarctica
13:08 * cervantes sets up an oil rig in antartica so he can finance a node there
13:09 < jrandom> ok ok, there's a lot of 0.5 stuff, so we can take it in pieces
13:09 < jrandom> first up, thanks to the folks who gathered a days worth of stats - lots of interesting data @ http://dev.i2p.net/~jrandom/messageSizes/
13:09 < postman> it was a pleasure :)
13:10 < cervantes> wrt net status...seen quite a few people having troubles getting I2P up and running lately (on the forums etc) - I don't know if that's just down to increase user volume or perhaps more i2p based apps for things to go wrong with
13:10 <+protokol> jrandom: LIAR! you said the data was interesting!
13:10 * jrandom flings mud at protokol
13:11 < ant> <duck> cervantes: I have also seen reports of ppl able to get it up and running within a couple of minutes
13:11 < ant> <duck> I think that NAT is causing most problems
13:11 < cervantes> duck: true...
13:11 < ant> <dmdm> who is NAT?
13:11 < jrandom> cervantes: there are some ugly issues still, certainly. the NAT issue and osx has been a bit of a pain lately, but Jhor's help with the later should improve the later
13:12 < cervantes> aye
13:12 < cervantes> *cough* so... 0.5
13:13 < Xan> dmdm: network address translation
13:13 < jrandom> heh, ok. basically the drive with those message size stats is to explore the padding issues
13:14 < jrandom> unfortunately, the strategy i built by cherry picking numbers sucked, giving a 25% overhead just with padding data
13:14 < jrandom> if we go with one of the proposals for the 0.5 encryption (tunnels-alt.html), we won't have that issue
13:15 < jrandom> (since it'll force small fixes sizes with fragmentation)
13:15 < mule> what type of messages do you want to pad, those a router sees or those an external observer sees?
13:15 < jrandom> mule: important question
13:15 < jrandom> if we're just worried about the external observer, we can leave the messages unpadded, doing any chaff generation at the transport layer
13:16 < Teal`c> http://microsoft.i2p/david_hasselhoff_05_christmas_album__silent_night.mp3
13:16 < jrandom> otoh, if we're worried about tunnel participants doing flow analysis, we need to worry about padding down the tunnel
13:16 <@duck> with 5-6 hops, how big is the danger of a router doing traffic analysis?
13:16 < cervantes> Teal`c: meeting atm... can you use #i2p-chat for mp3 announce ;-)
13:17 < Teal`c> sorry
13:17 < cervantes> :) for david hasselhoff?
13:18 < jrandom> depends upon what level of analysis duck. if they've somehow tracked down what tunnel they're in (e.g. they're the inbound tunnel gateway and have harvested the netDb, correlatign that with a destination), thats nontrivial data. otoh its not a direct exposure, but does give some info
13:18 < jrandom> even more than the tunnel padding though is end to end padding, hiding message flow data from gateways and endpoints.
13:19 < jrandom> if we're crazy/stupid, we could go all the way to a pipenet, using constant bitrate everywhere
13:19 <+polecat> I got it!
13:19 < jrandom> (and end up with no users running i2p)
13:19 <+polecat> What we need to do is tunnel i2p over email!
13:19 < cervantes> what's the likelyhood of colluding routers ending up in the same tunnel on a sufficiently large network?
13:19 <+polecat> No ISP would be dumb enough to stop email!
13:20 * jrandom awaits the net.i2p.router.transport.gmail implementation
13:20 < postman> polecat: gee , this is silly
13:20 < postman> :)
13:20 < bla> cervantes: N^(-h) (N is # of fast nodes, h = # hops). It seems
13:20 <+polecat> =3 I know.
13:21 < cervantes> is that a lot? :)
13:21 < jrandom> not the # of fast nodes, as external people won't know your profiles
13:21 <+polecat> Seriously though, in shameless abuse of existing IP services, we could tunnel i2p in any number of ingenious ways.
13:21 < jrandom> c^2/N^h to get two peers into the same tunnel
13:21 < jrandom> agreed polecat. thats one of the reasons why we don't have bidirectional tunnels
13:22 < jrandom> some transports (e.g. email) suck for bidirectional comm
13:22 < bla> jrandom: c = ?
13:22 < jrandom> c==# colluding peers
13:23 <+polecat> Hm, interesting point.
13:23 < ant> <duck> roadmap wise, what is the impact of i2p going a wrong direction and picking a wrong crypto solution?
13:23 <+polecat> Or carrier pigeon protocol, not bidi in the slightest.
13:23 <+polecat> crypto is modular already, isn't it?
13:23 < jrandom> duck: its just one bullet point out of 0.5, and one subsection of the tunnels*.html doc. theres lots more to the tunnel routing than just how we wrap the data
13:24 < bla> jrandom: Then again, this is the prob. for getting them in the tunnel *now*. However, over T tunnel refreshments (every so many minutes), this goes as P = 1 - (1 - c^2/N^h)^T
13:24 < jrandom> otoh, the difference between "fixed 1KB blocks" and "0-40KB blocks" has substantial impact
13:24 <+polecat> I'd hate to see this network go the way of Entropy, stuck in McEliece.
13:24 < jrandom> polecat: read http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD
13:24 < bla> jrandom: And thus tends to zero for large enough time. I.e.: for large enough time, the attackers will be in the same tunnel at last one time
13:25 < jrandom> the plan is standard AES256/CBC
13:25 <+protokol> i hear dns is good for tunneling stuff, most people dont block it
13:25 < jrandom> certainly bla, though its not quite that direct (for exploratory tunnels it is, but not for client tunnels)
13:26 <+polecat> And if somehow even AES gets cracked, some equivalent symmetric cipher.
13:27 < jrandom> bla: i dont think its large enough of a practical worry for most cases in that degree, but when you mount it as part of a predecessor attack, the issue is largely moot
13:28 < jrandom> (because of the way we do the rest of the tunnel routing)
13:28 < bla> jrandom: k
13:28 < jrandom> right polecat
13:29 < jrandom> duck: if we go w/ the second option, changing to another later will likely be easy.
13:29 < jrandom> otoh, the second option will require some hefty performance tuning to Not Suck
13:29 < jrandom> but i'm sure we can pull it off
13:31 < jrandom> anyway, I think the above covers where we are right now wrt 0.5 work
13:31 < jrandom> does anyone have any more questions/comments/concerns?
13:31 < bla> jrandom: One
13:32 < bla> jrandom: I think we should values anon. slightly more than performance atm: so yes, the PRNG options sounds good
13:33 < jrandom> agreed. performance can be tuned later, "adding in" better anonymity however, is much harder
13:33 < jrandom> (but, of course, performance /is/ a security parameter. if it Sucks, no one uses it)
13:33 < bla> Yes.
13:33 < bla> jrandom:
13:33 < bla> sorry
13:33 <@duck> right, /me flips the magical Freenet-performance bit
13:33 < cervantes> perhaps it'll deter all those torrent waving leechers to stay away a while longer ;-)
13:34 < jrandom> heh
13:34 < cervantes> <-- connection reset
13:34 < bla> cervantes: No, I'm not! :)
13:34 < cervantes> :)
13:35 < jrandom> i do think that we can pull off some really cool optimizations, and it seems a lot of our choke is not related to the peer selection, but merely (heh) bugs in the jobqueue
13:36 < jrandom> but, anyway, anything else for 2) 0.5?
13:36 < ant> <BS314159> could you post an explanation for this loop attack?
13:37 < ant> <BS314159> it sounds more dangerous than your treatment implies it is
13:37 < jrandom> loop: build a tunnel containing A-->B-->C-->D-->C, send in 10 messages.
13:37 < jrandom> without the PRNGs, you can add as many messages to that C<-->D loop as you want
13:38 < ant> <BS314159> ok
13:38 < jrandom> effectively DoSing any routers with just a few messages
13:38 < ant> <BS314159> but only A can do this
13:38 < jrandom> with the PRNGs, it limits the number of messages that can go into the loop
13:38 < ant> <BS314159> so there's no danger of an attacker shortening my tunnels by introducing loops
13:38 < jrandom> no, no one can shorten your tunnels
13:39 < jrandom> the only thing this is useful for is a DoS
13:39 < jrandom> (a very cheap DoS)
13:39 < jrandom> (but when you can selectively DoS peers without much cost, you can do naaaasty stuff)
13:40 < ant> <BS314159> comprendo
13:40 <+protokol> and hashcash certs will help this?
13:40 < jrandom> protokol: hashcash addresses the issue of a peer building too many tunnels, and perhaps building too many hops
13:41 < jrandom> protokol: it doesnt help with loops. the two ways i could find that /did/ were the PRNGs (tunnel-alt.html) or verifying at each step (tunnel.html)
13:42 < jrandom> verifying at each step has dangers, so the current leaning is towards the PRNGs
13:42 <+Ragnarok> how effective will the prng method be?
13:42 < Xan> A-->B-->C-->D-->C - shouldnt each hop get a different id or something, so that messages leave the tunnel the second time they reach C rather than looping?
13:43 < jrandom> Xan: they do, but without verifying each step, you can't tell whether its bad or not
13:44 < jrandom> Ragnarok: i think it'll be very effective at minimizing the damage done
13:45 < jrandom> at least, from what I can see so far
13:45 < jrandom> if anyone sees any problems/issues with it, or suggestions for improvement, please get in touch :)
13:46 < Xan> or maybe Im missing the point
13:46 < Xan> bbl
13:46 < jrandom> 'k l8r, i'll update the doc to be more clear
13:47 < jrandom> ok, unless there's something else, shall we move on to 3) i2pmail.v2?
13:47 < jrandom> postman: you 'round?
13:48 < postman> yes
13:49 < postman> :)
13:49 < jrandom> anything to add from your post on the forum? it sounds pretty cool
13:49 < postman> well, a few of you might have read the draft for i2pmail.v2 already
13:50 < bla> wtf is happening? Massive disconnects. I've got trouble reaching sites (say orion, library) here too
13:50 < postman> it aims towards a fully decentralized mail infrastructure in the future
13:50 < postman> but is in need of proxysoftware on the nodes as well as a bunch of dedicated relays
13:51 < postman> all are invited to contribute ideas / concepts / rants
13:51 < postman> development already has started - dont expect anything before late spring :)
13:51 < jrandom> w00t
13:51 < kaji> hmm, the cops just showed up at my door
13:52 < bla> kaji: ?
13:52 < jrandom> quick, blow your hard drive
13:52 < postman> jrandom: well, this is all i have to say for now :)
13:52 < cervantes> hide the blackjack table!
13:52 < jrandom> wikked, thanks postman
13:52 < kaji> they said i dialed 911, but im quite sure neither i nor my brother did
13:53 <+protokol> kaji: they're just checking up on i2p
13:53 < jrandom> ok, unless there's anytihng else on 3) i2pmail, lets move over to 4) azneti2p_0.2
13:53 <+protokol> <creepy music>
13:53 < jrandom> as mentioned in the email, there's been some important progress lately
13:53 < kaji> then they said cordless phones can freak out when off the hook, but all my cordless phones are on their charger -> #i2p-chat
13:55 < jrandom> the azureus folks have been very responsive in getting an update ready (yay!), but people should also be on the lookout for problems
13:55 < jrandom> (if you don't read the i2p mailing list and use azneti2p, read the i2p mailing list)
13:55 < jrandom> ((or even if yuo dont use azneti2p, read the list, as thats where we announce important things ;)
13:56 < jrandom> duck and orion have also been making lots of updates to accomodate the new bt client and formatting
13:56 < jrandom> (yay!)
13:56 * orion smiles
13:57 < orion> theres still a ways to go, but for now, it works.
13:57 < jrandom> (inasmuch as i2p lets it ;)
13:58 < orion> hehe, yes. ;)
13:58 < jrandom> does anyone else have anything to bring up wrt azneti2p or i2p-bt?
13:58 < jrandom> (or bytemonsoon2p ;)
14:00 < jrandom> ok if not, moving right along to 5) ???
14:00 < jrandom> open floor - anyone else have anything to bring up?
14:00 < postman> jrandom: why does the addressbook publich userhosts entries ?
14:01 < jrandom> postman: bug.
14:01 < postman> so this was no planned behaviour and will be changed?
14:01 < cervantes> just one thing...
14:01 < jrandom> postman: correct, and will be changed
14:02 < jrandom> (right Ragnarok? :)
14:02 <+Ragnarok> depends on exactly what postman means...
14:03 < jrandom> Ragnarok: new entries added by the local user to their own private hosts shouldn't be propogated to the hosts published
14:03 < jrandom> (e.g. userhosts.txt is private, hosts.txt is synchronized with other people and is public)
14:03 < cervantes> As part of a semi regular slot on the forum, there will be recognition and awards for those that have contributed good things to I2P either recently or over the project's lifetime
14:03 < postman> Ragnarok: after updating to 0.4.2.6 i found entries from my userhosts.txt in the published addressbook in my eepsite folder
14:03 < ant> <BS314159> hmm
14:04 < postman> Ragnarok: those have been manually added keys, which haven't been supposed to be published
14:04 < cervantes> this week we recognise duck for general excellence as a service provider for the community and as an all round great idler: http://forum.i2p/viewtopic.php?t=275
14:04 < jrandom> w00t!
14:04 < jrandom> (go duck go, go duck go)
14:05 < Teal`c> what about domain name hijacking ?
14:05 * brachtus applauds
14:05 * orion does a duck waddle as a sign of respect.
14:05 < cervantes> one important point for the future...you don't have to be a cryptographic genius to get praise!
14:06 <+Ragnarok> no, that's expected behaviour. I can change it, but first I'll have to finish implementing file locking so you can change hosts.txt directly
14:06 < orion> (but it helps)
14:06 < cervantes> you might just have contributed a cracking eepsite or something...
14:06 < cervantes> or been a helpful bod on the forum etc
14:07 < ant> <BS314159> hmm
14:07 < cervantes> (otherwise, lets face it, jrandom would win every week)
14:07 < jrandom> hey, y'all are paying for my beer fund, this stuff aint free ;)
14:07 < ant> <BS314159> could you just make a new file, "publichosts.txt"?
14:07 < ant> <BS314159> then have addressbook ignore userhosts.txt, but allowed users to subscribe to their own publichosts.txt?
14:08 < jrandom> Teal`c: there is no way to hijack a domain name, no entries are overwritten, and userhosts always overrides hosts
14:09 < jrandom> Ragnarok: perhaps the web interface can address the locking issue, since users won't be adding to the files manually
14:09 <+Ragnarok> once the locking is done, there's no real reason to pull in addresses from userhosts.txt anymore (it's currently the only way to dodge a race), so there's no real point in adding a third file
14:10 <+Ragnarok> jrandom: well, I was planning on using the java file locking api
14:10 < jrandom> if you think its necessary, you're the boss :)
14:10 < ant> <BS314159> it would allow you to kill all the names gotten from other people while keeping the ones you made yourself
14:10 < ant> <BS314159> simply by clearing hosts.txt and changing your subscriptiong
14:11 < ant> <BS314159> but I guess that can wait for name-signing
14:11 < orion> metadata will solve this problem. Is a spec drafted yet?
14:11 < jrandom> using just two files should be fine - one managed by the addressbook, one not
14:12 < jrandom> (you could even have the addressbook ignore userhosts.txt entirely - userhosts.txt overrides hosts.txt anyway)
14:12 <+Ragnarok> jrandom: that would be the plan, once locking is done (which really shouldn't be too much work, I just haven't gotten around to it :)
14:13 <+Ragnarok> and I'm currently working on learning enough xml schema to write one for the namerecords
14:13 < ant> <dr_kavra> is this the channel for kenosis? another channel told me to come here :D
14:13 < jrandom> lol
14:13 < jrandom> nah, sorry, this is i2p
14:14 < jrandom> (unless you're looking for an anonymous comm layer)
14:14 < jrandom> wikked Ragnarok
14:14 < ant> <BS314159> I still the XML is too verbose and non-human-readable for this, compared to YAML, but I'm not the one writing the code
14:14 < jrandom> Ragnarok: the tough part will be doing the crypto w/ XML without reverting to ugly CDATA
14:14 < orion> anybody write a working draft for the metadata spec yet?
14:15 < jrandom> (i personally think xml sucks, but i'm just a naysayer)
14:15 < jrandom> orion: http://dev.i2p.net/pipermail/i2p/2004-February/000135.html has a basic setup
14:15 < orion> (name/key metadata)
14:15 < dox> has the addressbook and its features been announced somewhere? I didn't know my hosts.txt is published
14:15 < jrandom> (see NameReference and LocalEntry elements)
14:16 < jrandom> dox: its written to the location specified in addressbook/config.txt
14:16 < jrandom> (by default, ./eepsite/docroot/hosts.txt)
14:17 < orion> is missing a public/private (i.e. distribute, don't) flag.
14:17 < ant> <cervantes> the only good thing about XML (and this is a large + point) is that it's a widely accepted standard
14:17 < jrandom> right orion, lots of good ideas have come up since that post
14:17 <+Ragnarok> xml may suck, but frankly, it better than any of the alternatives for what I'm doing
14:17 < jrandom> cervantes: so is EDI
14:17 < orion> is there a place to condense them? i.e. forum area?
14:18 < orion> or maybe a wiki page?
14:18 < jrandom> orion: susi's or ugha's wiki
14:18 < orion> I'm going to set up wikis for bytemonsoon and orion.i2p to help get some community consensus as to the future development goals of each.
14:18 < BrockSamson> xml + crypto w/o CDATA = mime, no?
14:19 < jrandom> wikked orion
14:19 < jrandom> BrockSamson: smime, with different parsers ;)
14:19 < orion> (also one for name metadata)
14:21 < jrandom> there are lots of ways to do the metadata, the important thing is flexibility and 'correctness' so that it can grow or change over time
14:21 * jrandom is sure Ragnarok et al will come up with some good stuff :)
14:21 < orion> thats why I think a public draft is in order.
14:22 < ant> <cervantes> i2p consortium :P
14:22 < jrandom> well, people have been saying "someone should put up their ideas on the wiki" for the last few meetings, but the wiki pages aren't growing too much ;) which is fine, we take the pace we take
14:23 * orion promises to have three wikis up within a day and email everyone their locations
14:23 < BrockSamson> call me lazy, but compare an ANSI 850 Purchase order EDI to nearly any other XML based purchase order, and i'd rather decode, code, and debug for the XML version. Even if it's 5x the EDI size
14:23 < jrandom> w00t
14:23 < jrandom> heh BrockSamson
14:24 < BrockSamson> Position 10 is ST? oh then position 310 should be name
14:24 < BrockSamson> duh me
14:24 < jrandom> BrockSamson: don't think the xml schemas for POs are much better ;)
14:24 < jrandom> (but yeah, that stuff is just a totally bloody disaster)
14:25 < BrockSamson> they are at 4:30 in the morning
14:25 < BrockSamson> unless...
14:25 < jrandom> heh
14:25 < BrockSamson> it's written by an ex EDI programmer
14:25 < BrockSamson> and the xml looks like this: <p1><po><q>1</q></po></p1>
14:26 < BrockSamson> i bet though, if you add up the horuse OpenSource projects spend talking about to 'XML' or not 'XML' you could code linux 10x over.
14:26 < BrockSamson> every project i've ever been part of has had massive debates on it
14:27 < orion> debates are good for a project, depending on who's debating. ;)
14:27 < jrandom> eh, it does what it does, but its not a panacea. it may work well for the naming stuff
14:28 < BrockSamson> many people are in projects just to debate though.
14:28 < jrandom> not here. i'm here for the free beer
14:28 < ant> <cervantes> that's debatable
14:28 < orion> the implementation details will be clearer when the draft spec is more tangable.
14:28 < orion> hence the need for a wiki/peer review.
14:29 < BrockSamson> I heard this project gave away free Garlic
14:29 < jrandom> lots of it
14:30 < jrandom> ok, anyone else have anything to bring up for the meeting?
14:30 < ant> * cervantes wheels out the ceremonial call with bell
14:30 < ant> <cervantes> call =cow
14:30 * jrandom winds up
14:31 * jrandom *baf*s the cowbell, closing the meeting

10
i2p2www/meetings/125.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, January 18, 2005
=================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,178 +1,172 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 126{% endblock %}
{% block content %}<h3>I2P dev meeting, January 25, 2005</h3>
<div class="irclog">
13:50 < jrandom> 0) hi</p>
13:50 < jrandom> 1) 0.5 status</p>
13:50 < jrandom> 2) sam.net</p>
13:50 < jrandom> 3) gcj progress</p>
13:50 < jrandom> 4) udp</p>
13:50 < jrandom> 5) ???</p>
13:50 < jrandom> 0) hi</p>
13:50 * jrandom waves belatedly</p>
13:51 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2005-January/000560.html</p>
13:51 <+postman> hi</p>
13:51 * brachtus waves back</p>
13:52 * cervantes waves a detention slip for tardiness</p>
13:52 < jrandom> yeah yeah, blame the code for sucking me in</p>
13:52 < jrandom> ok, jumping into 1) 0.5 status</p>
13:53 < jrandom> lots of progress since last week - all the messy problems we had with the new crypto are resolved without much trouble</p>
13:54 < jrandom> the latest http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD is very likely to be what we deploy in 0.5 and beyond, unless/until people find any problems with it</p>
13:55 < jrandom> not sure if i have anything else to add beyond whats in the email</p>
13:55 < jrandom> anyone have any questions/concerns?</p>
13:56 < Ragnarok> what's performance going to be like?</p>
13:56 < jrandom2p> (not me)</p>
13:56 < jrandom> Ragnarok: tunnel performance should be much better</p>
13:56 < frosk> any significant overhead compared to what we have today?</p>
13:57 < jrandom> frosk: sometimes</p>
13:57 < jrandom> frosk: when we can coallesce messages in a tunnel, the overhead will be minimal</p>
13:58 < jrandom> however, when we cannot coallesce or when its not effective, there can be nontrivial waste</p>
13:58 < frosk> i see</p>
13:59 < jrandom> otoh, we're trimming some of the absurdities of our current i2np (where we currently prepend a 32 byte SHA256 before each I2NP message, even ones within garlic messages, etc)</p>
13:59 < jrandom> the fragmentation and fixed size will be an issue we need to tune with, but there is lots of room to do so</p>
14:01 < jrandom> ok, anytihng else on 0.5?</p>
14:02 < jrandom> if not, moving on to 2) sam.net</p>
14:02 < jrandom> smeghead has ported the java sam client lib to .net (yay!)</p>
14:02 < jrandom> smeghead: wanna give us the rundown?</p>
14:03 < smeghead> sure</p>
14:03 < smeghead> i'm writing tests for it, should have those in cvs in the next couple of days</p>
14:04 < smeghead> should work with .net/mono/portable.net</p>
14:04 < smeghead> and c# and vb.net</p>
14:05 < frosk> (and all of the other languages that works with .net i suppose)</p>
14:05 < cervantes> (urgh)</p>
14:05 < smeghead> the interface is dirt simple</p>
14:05 < smeghead> just register listener methods with SamReader, or subclass SamBaseEventHandler and override methods as necessary</p>
14:05 < smeghead> yes, i aim to make it fully CLR compatible</p>
14:06 < jrandom> wikked</p>
14:06 < cervantes> cool... smeg.net ;-)</p>
14:06 < frosk> goodie</p>
14:06 < smeghead> really not much else to it</p>
14:06 <+protokol> CLR?</p>
14:06 < smeghead> common language runtime</p>
14:06 < smeghead> the .net equivalent of the JRE</p>
14:07 <+protokol> JRE?</p>
14:07 <+protokol> just kidding</p>
14:07 < jrandom> !thwap protokol </p>
14:07 < Ragnarok> jrandom: how's the sam bridge holding up these days? were all the bt related issues resolved?</p>
14:08 < Tracker> I doubt it, i2p-bt can even drive my amd64 3000 mad, cpu-wise...</p>
14:08 < jrandom> Ragnarok: i havent touched it lately. there's still the outstanding choke issue that polecat came up with, but where the i2p-bt&lt;--&gt;sam bridge is getting off, i'm not sure</p>
14:09 < jrandom> hmm, failed connections will force full ElGamal instead of AES</p>
14:10 < Ragnarok> ok</p>
14:10 < jrandom> we should be able to reduce some of that after 0.5, but only partially</p>
14:12 < Tracker> Ok, the I2P will be good for anonymus trackers but not for anonymus clients. Just try to think what happens on a really popular torrent with some 1000 seeds and leechs.</p>
14:12 < jrandom> ok, the sam.net stuff sounds cool, thanks again smeghead. i'm looking forward to the unit tests and perhaps a demo app :)</p>
14:12 < ant> &lt;Evil-Brotten&gt; hello everbody</p>
14:12 < smeghead> a demo app, yes i'll do that too</p>
14:13 < smeghead> i've ported yours in fact</p>
14:13 < jrandom> Tracker: i2p can handle anonymous clients just fine, we just need to figure out whats wrong with the i2p-bt&lt;--&gt;sam bridge to reduce the full ElG's</p>
14:13 < smeghead> they're just bug-ridden atm</p>
14:13 < ant> &lt;Evil-Brotten&gt; deer?</p>
14:13 < jrandom> hi Evil-Brotten</p>
14:13 < ant> &lt;Evil-Brotten&gt; hello</p>
14:14 < jrandom> weekly dev meeting going on, feel free to stick around. deer is a gateway to i2p/iip</p>
14:14 < ant> &lt;Evil-Brotten&gt; are you an i2p expert?</p>
14:14 < ant> &lt;Evil-Brotten&gt; :P</p>
14:14 < ant> &lt;Evil-Brotten&gt; ow, ok</p>
14:14 < ant> &lt;cervantes&gt; Evil-Brotten: you can talk in #i2p-chat if you like while the meeting is ongoing</p>
14:14 < jrandom> Tracker: we've got a lot to do before handling 1k-wide torrents</p>
14:14 < ant> &lt;Evil-Brotten&gt; i was just trying to install your program, but i am having some problems</p>
14:14 < ant> &lt;Evil-Brotten&gt; cool, i will ask there</p>
14:15 < jrandom> wikked smeghead </p>
14:15 < Tracker> jrandom: I hope so, non-anonymus bt won't survive much longer...</p>
14:15 < frosk> nonsense</p>
14:15 < jrandom> "but exeem is anonymous!@#" &lt;/snark&gt;</p>
14:15 < Tracker> jrandom: But that's a different story</p>
14:15 < ant> &lt;MikeW&gt; what?</p>
14:15 < ant> &lt;MikeW&gt; who said exeem is anonymous?</p>
14:16 < jrandom> mikew: just the occational fanboy</p>
14:16 < jrandom> Tracker: after 0.5 we're going to have a lot of work to do getting performance where we need it to be</p>
14:16 * DrWoo notes that 'people' are fucking morons (sometimes)</p>
14:16 < Tracker> jrandom: Yeah, installing spy-/adware isn't really what I would do ;)</p>
14:16 < jrandom> heh</p>
14:17 < smeghead> i happen to like people</p>
14:17 < smeghead> they're good on toast</p>
14:17 < jrandom> *chomp*</p>
14:17 < smeghead> some need a little more butter than others</p>
14:18 < jrandom> ok, i think thats 'bout it for 2) sam.net (unless anyone has something else to add?)</p>
14:18 < jrandom> if not, moving on to 3) gcj progress</p>
14:19 < ant> &lt;dm&gt; sam.net??</p>
14:19 < ant> &lt;dm&gt; is it working?/</p>
14:19 < jrandom> i've read in my backlog that smeghead has been making some good headway - wanna give us an update on how its going?</p>
14:19 < smeghead> yes</p>
14:20 < ant> &lt;dm&gt; cooooooool</p>
14:20 < smeghead> i modified a few classes so the router compiles with gcj 3.4.3</p>
14:20 < smeghead> i will submit the patch after the meeting</p>
14:20 < smeghead> after that i and anyone who would like to help can get to work on making it run</p>
14:21 < jrandom> nice</p>
14:21 * frosk decorates smeghead with the Employee of the Week medal for sam.net _and_ gcj work</p>
14:21 < jrandom> aye, v.cool</p>
14:21 < smeghead> :)</p>
14:22 < Tracker> frosk: better forum user of the week ;)</p>
14:22 < frosk> i haven't read the forum this week, sorry :)</p>
14:22 < cervantes> duck's glory has not yet expired ;-)</p>
14:23 * jrandom is very much looking forward to seeing i2p gcj compatible</p>
14:24 < jrandom> (and there's still that bounty on it, so people should get in touch with smeghead and get involved ;)</p>
14:24 < smeghead> yes it would expand i2p's portability significantly</p>
14:24 < cervantes> maybe we'll be able to squeeze something that resembles performance from the router :P</p>
14:24 < ant> &lt;dm&gt; my 32-week run as hardest I2P worker ends at last...</p>
14:25 < jrandom> i dont expect gcj to actually improve performance or reduce the memory footprint, but it'll work on OSes that sun doesn't release JVMs for and kaffe is b0rked on</p>
14:25 < jrandom> (but if i'm wrong, cool!)</p>
14:25 < frosk> anything that can make i2p run better without proprietary software is Good</p>
14:26 < jrandom> agreed. supporting both kaffe and gcj would be a Good Thing</p>
14:27 < jrandom> ok, anything else on 3) gcj progress, or shall we move on?</p>
14:27 < smeghead> installation would be easier too</p>
14:27 < Teal`c> has gcj worked for anything besides 'hello world' examples ?</p>
14:27 < Ragnarok> someone built eclipse with it</p>
14:27 < smeghead> Teal`c: yes, i've used it for .exe's under mingw before in fact</p>
14:27 < smeghead> yes, eclipse was running under gcj with red hat not to long ago</p>
14:28 < jrandom> having the option of distributing gcj'ed executables, plain .jar installers, and bundled .jar+jvm will definitely be Good</p>
14:29 < jrandom> ok, moving on to 4) udp</p>
14:30 < jrandom> there was a recent post to the forum that i just wanted to draw people's attention to, asking (and answering) why udp is important</p>
14:30 < Tracker> Yuck</p>
14:30 < jrandom> (see http://forum.i2p.net/viewtopic.php?t=280 and comment if you have any suggestions/questions/concenrs)</p>
14:31 < jrandom> yuck Tracker?</p>
14:32 < jrandom> anyway, both mule and detonate are making some headway on the udp side. detonate/mule: y'all have any updates to share?</p>
14:32 < Tracker> UPD is evil here, while it works well within the country borders it really get's ugly when trying to use it on destinations outside our countrys.</p>
14:32 < jrandom> hmm</p>
14:32 < Tracker> Just my experience from 5 years online gaming...</p>
14:33 < jrandom> we'll certainly need to take into account the congestion and mtu issues as they go out on the net</p>
14:33 < Tracker> Somehow the two big backbones here don't like to router UPD very well and if only with very low priority.</p>
14:34 < Tracker> Meaning pings between 5 and 20 seconds.</p>
14:34 < jrandom> i'd be pretty suprised if there was an isp that didn't allow UDP at all (since we all use DNS)</p>
14:34 < Tracker> And high packet loss</p>
14:34 < jrandom> congestion control is certainly important</p>
14:35 < Tracker> Why do you think I'm running my own caching dns with a very big cache for years ;)</p>
14:35 < jrandom> heh</p>
14:35 < jrandom> well, we will have the fallback of tcp for people who cannot use udp for some reason</p>
14:36 < jrandom> but udp will be overwhelmingly preferred </p>
14:36 < Tracker> That's nice.</p>
14:36 < jrandom> (meaning i hope there will only be perhaps 10 people using tcp out of 1m+ nodes ;)</p>
14:37 < jrandom> but, again, that forum link explains why we need to do what we're doing, though if anyone can find a better way, i'm all ears</p>
14:37 < Tracker> I guess I will be one of them.</p>
14:37 < jrandom> perhaps. </p>
14:38 < jrandom> we'll see as 0.6 is deployed whether thats the case, or whether we'll be able to work around the issues your isp has</p>
14:38 < jrandom> ok, anything else on udp? or shall we move on to 5) ???</p>
14:39 < jrandom> consider us moved</p>
14:39 < jrandom> 5) ??</p>
14:39 < jrandom> anyone have anything else to bring up?</p>
14:40 < Teal`c> is the pizza here yet ?</p>
14:40 < Jhor> anybody know where i should look to find/debug problems in bittorrent?</p>
14:41 < jrandom> Jhor: in i2p-bt, a good place to start would likely be adding in some logging to tell you what BT messages are sent/received, so we know where its blocking/timing out/etc</p>
14:41 < jrandom> (assuming you mean i2p-bt and not azneti2p?)</p>
14:42 < Jhor> yeah, i2p-bt. what are the different spew levels?</p>
14:42 < jrandom> no idea, all i know is --spew 1</p>
14:42 < Jhor> Ok, I'll try that</p>
14:43 * Jhor prepares for a crash course in python</p>
14:43 < jrandom> :)</p>
14:44 < jrandom> ok, anybody else have something to discuss?</p>
14:44 * cervantes wheels out the Strand Gong</p>
14:44 < jrandom> we're around the 60m mark, so a pretty good rate</p>
14:44 < Teal`c> when is udp due for general consumption ?</p>
14:44 < jrandom> Teal`c: april</p>
14:44 < jrandom> thats 0.6, we're still working on 0.5</p>
14:45 < Teal`c> nice work.</p>
14:46 < jrandom> progress, ever onwards</p>
14:46 * jrandom winds up</p>
14:46 * jrandom *baf*s the gong, closing the meeting</p>
</div>
{% endblock %}
13:50 < jrandom> 0) hi
13:50 < jrandom> 1) 0.5 status
13:50 < jrandom> 2) sam.net
13:50 < jrandom> 3) gcj progress
13:50 < jrandom> 4) udp
13:50 < jrandom> 5) ???
13:50 < jrandom> 0) hi
13:50 * jrandom waves belatedly
13:51 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2005-January/000560.html
13:51 <+postman> hi
13:51 * brachtus waves back
13:52 * cervantes waves a detention slip for tardiness
13:52 < jrandom> yeah yeah, blame the code for sucking me in
13:52 < jrandom> ok, jumping into 1) 0.5 status
13:53 < jrandom> lots of progress since last week - all the messy problems we had with the new crypto are resolved without much trouble
13:54 < jrandom> the latest http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD is very likely to be what we deploy in 0.5 and beyond, unless/until people find any problems with it
13:55 < jrandom> not sure if i have anything else to add beyond whats in the email
13:55 < jrandom> anyone have any questions/concerns?
13:56 < Ragnarok> what's performance going to be like?
13:56 < jrandom2p> (not me)
13:56 < jrandom> Ragnarok: tunnel performance should be much better
13:56 < frosk> any significant overhead compared to what we have today?
13:57 < jrandom> frosk: sometimes
13:57 < jrandom> frosk: when we can coallesce messages in a tunnel, the overhead will be minimal
13:58 < jrandom> however, when we cannot coallesce or when its not effective, there can be nontrivial waste
13:58 < frosk> i see
13:59 < jrandom> otoh, we're trimming some of the absurdities of our current i2np (where we currently prepend a 32 byte SHA256 before each I2NP message, even ones within garlic messages, etc)
13:59 < jrandom> the fragmentation and fixed size will be an issue we need to tune with, but there is lots of room to do so
14:01 < jrandom> ok, anytihng else on 0.5?
14:02 < jrandom> if not, moving on to 2) sam.net
14:02 < jrandom> smeghead has ported the java sam client lib to .net (yay!)
14:02 < jrandom> smeghead: wanna give us the rundown?
14:03 < smeghead> sure
14:03 < smeghead> i'm writing tests for it, should have those in cvs in the next couple of days
14:04 < smeghead> should work with .net/mono/portable.net
14:04 < smeghead> and c# and vb.net
14:05 < frosk> (and all of the other languages that works with .net i suppose)
14:05 < cervantes> (urgh)
14:05 < smeghead> the interface is dirt simple
14:05 < smeghead> just register listener methods with SamReader, or subclass SamBaseEventHandler and override methods as necessary
14:05 < smeghead> yes, i aim to make it fully CLR compatible
14:06 < jrandom> wikked
14:06 < cervantes> cool... smeg.net ;-)
14:06 < frosk> goodie
14:06 < smeghead> really not much else to it
14:06 <+protokol> CLR?
14:06 < smeghead> common language runtime
14:06 < smeghead> the .net equivalent of the JRE
14:07 <+protokol> JRE?
14:07 <+protokol> just kidding
14:07 < jrandom> !thwap protokol
14:07 < Ragnarok> jrandom: how's the sam bridge holding up these days? were all the bt related issues resolved?
14:08 < Tracker> I doubt it, i2p-bt can even drive my amd64 3000 mad, cpu-wise...
14:08 < jrandom> Ragnarok: i havent touched it lately. there's still the outstanding choke issue that polecat came up with, but where the i2p-bt<-->sam bridge is getting off, i'm not sure
14:09 < jrandom> hmm, failed connections will force full ElGamal instead of AES
14:10 < Ragnarok> ok
14:10 < jrandom> we should be able to reduce some of that after 0.5, but only partially
14:12 < Tracker> Ok, the I2P will be good for anonymus trackers but not for anonymus clients. Just try to think what happens on a really popular torrent with some 1000 seeds and leechs.
14:12 < jrandom> ok, the sam.net stuff sounds cool, thanks again smeghead. i'm looking forward to the unit tests and perhaps a demo app :)
14:12 < ant> <Evil-Brotten> hello everbody
14:12 < smeghead> a demo app, yes i'll do that too
14:13 < smeghead> i've ported yours in fact
14:13 < jrandom> Tracker: i2p can handle anonymous clients just fine, we just need to figure out whats wrong with the i2p-bt<-->sam bridge to reduce the full ElG's
14:13 < smeghead> they're just bug-ridden atm
14:13 < ant> <Evil-Brotten> deer?
14:13 < jrandom> hi Evil-Brotten
14:13 < ant> <Evil-Brotten> hello
14:14 < jrandom> weekly dev meeting going on, feel free to stick around. deer is a gateway to i2p/iip
14:14 < ant> <Evil-Brotten> are you an i2p expert?
14:14 < ant> <Evil-Brotten> :P
14:14 < ant> <Evil-Brotten> ow, ok
14:14 < ant> <cervantes> Evil-Brotten: you can talk in #i2p-chat if you like while the meeting is ongoing
14:14 < jrandom> Tracker: we've got a lot to do before handling 1k-wide torrents
14:14 < ant> <Evil-Brotten> i was just trying to install your program, but i am having some problems
14:14 < ant> <Evil-Brotten> cool, i will ask there
14:15 < jrandom> wikked smeghead
14:15 < Tracker> jrandom: I hope so, non-anonymus bt won't survive much longer...
14:15 < frosk> nonsense
14:15 < jrandom> "but exeem is anonymous!@#" </snark>
14:15 < Tracker> jrandom: But that's a different story
14:15 < ant> <MikeW> what?
14:15 < ant> <MikeW> who said exeem is anonymous?
14:16 < jrandom> mikew: just the occational fanboy
14:16 < jrandom> Tracker: after 0.5 we're going to have a lot of work to do getting performance where we need it to be
14:16 * DrWoo notes that 'people' are fucking morons (sometimes)
14:16 < Tracker> jrandom: Yeah, installing spy-/adware isn't really what I would do ;)
14:16 < jrandom> heh
14:17 < smeghead> i happen to like people
14:17 < smeghead> they're good on toast
14:17 < jrandom> *chomp*
14:17 < smeghead> some need a little more butter than others
14:18 < jrandom> ok, i think thats 'bout it for 2) sam.net (unless anyone has something else to add?)
14:18 < jrandom> if not, moving on to 3) gcj progress
14:19 < ant> <dm> sam.net??
14:19 < ant> <dm> is it working?/
14:19 < jrandom> i've read in my backlog that smeghead has been making some good headway - wanna give us an update on how its going?
14:19 < smeghead> yes
14:20 < ant> <dm> cooooooool
14:20 < smeghead> i modified a few classes so the router compiles with gcj 3.4.3
14:20 < smeghead> i will submit the patch after the meeting
14:20 < smeghead> after that i and anyone who would like to help can get to work on making it run
14:21 < jrandom> nice
14:21 * frosk decorates smeghead with the Employee of the Week medal for sam.net _and_ gcj work
14:21 < jrandom> aye, v.cool
14:21 < smeghead> :)
14:22 < Tracker> frosk: better forum user of the week ;)
14:22 < frosk> i haven't read the forum this week, sorry :)
14:22 < cervantes> duck's glory has not yet expired ;-)
14:23 * jrandom is very much looking forward to seeing i2p gcj compatible
14:24 < jrandom> (and there's still that bounty on it, so people should get in touch with smeghead and get involved ;)
14:24 < smeghead> yes it would expand i2p's portability significantly
14:24 < cervantes> maybe we'll be able to squeeze something that resembles performance from the router :P
14:24 < ant> <dm> my 32-week run as hardest I2P worker ends at last...
14:25 < jrandom> i dont expect gcj to actually improve performance or reduce the memory footprint, but it'll work on OSes that sun doesn't release JVMs for and kaffe is b0rked on
14:25 < jrandom> (but if i'm wrong, cool!)
14:25 < frosk> anything that can make i2p run better without proprietary software is Good
14:26 < jrandom> agreed. supporting both kaffe and gcj would be a Good Thing
14:27 < jrandom> ok, anything else on 3) gcj progress, or shall we move on?
14:27 < smeghead> installation would be easier too
14:27 < Teal`c> has gcj worked for anything besides 'hello world' examples ?
14:27 < Ragnarok> someone built eclipse with it
14:27 < smeghead> Teal`c: yes, i've used it for .exe's under mingw before in fact
14:27 < smeghead> yes, eclipse was running under gcj with red hat not to long ago
14:28 < jrandom> having the option of distributing gcj'ed executables, plain .jar installers, and bundled .jar+jvm will definitely be Good
14:29 < jrandom> ok, moving on to 4) udp
14:30 < jrandom> there was a recent post to the forum that i just wanted to draw people's attention to, asking (and answering) why udp is important
14:30 < Tracker> Yuck
14:30 < jrandom> (see http://forum.i2p.net/viewtopic.php?t=280 and comment if you have any suggestions/questions/concenrs)
14:31 < jrandom> yuck Tracker?
14:32 < jrandom> anyway, both mule and detonate are making some headway on the udp side. detonate/mule: y'all have any updates to share?
14:32 < Tracker> UPD is evil here, while it works well within the country borders it really get's ugly when trying to use it on destinations outside our countrys.
14:32 < jrandom> hmm
14:32 < Tracker> Just my experience from 5 years online gaming...
14:33 < jrandom> we'll certainly need to take into account the congestion and mtu issues as they go out on the net
14:33 < Tracker> Somehow the two big backbones here don't like to router UPD very well and if only with very low priority.
14:34 < Tracker> Meaning pings between 5 and 20 seconds.
14:34 < jrandom> i'd be pretty suprised if there was an isp that didn't allow UDP at all (since we all use DNS)
14:34 < Tracker> And high packet loss
14:34 < jrandom> congestion control is certainly important
14:35 < Tracker> Why do you think I'm running my own caching dns with a very big cache for years ;)
14:35 < jrandom> heh
14:35 < jrandom> well, we will have the fallback of tcp for people who cannot use udp for some reason
14:36 < jrandom> but udp will be overwhelmingly preferred
14:36 < Tracker> That's nice.
14:36 < jrandom> (meaning i hope there will only be perhaps 10 people using tcp out of 1m+ nodes ;)
14:37 < jrandom> but, again, that forum link explains why we need to do what we're doing, though if anyone can find a better way, i'm all ears
14:37 < Tracker> I guess I will be one of them.
14:37 < jrandom> perhaps.
14:38 < jrandom> we'll see as 0.6 is deployed whether thats the case, or whether we'll be able to work around the issues your isp has
14:38 < jrandom> ok, anything else on udp? or shall we move on to 5) ???
14:39 < jrandom> consider us moved
14:39 < jrandom> 5) ??
14:39 < jrandom> anyone have anything else to bring up?
14:40 < Teal`c> is the pizza here yet ?
14:40 < Jhor> anybody know where i should look to find/debug problems in bittorrent?
14:41 < jrandom> Jhor: in i2p-bt, a good place to start would likely be adding in some logging to tell you what BT messages are sent/received, so we know where its blocking/timing out/etc
14:41 < jrandom> (assuming you mean i2p-bt and not azneti2p?)
14:42 < Jhor> yeah, i2p-bt. what are the different spew levels?
14:42 < jrandom> no idea, all i know is --spew 1
14:42 < Jhor> Ok, I'll try that
14:43 * Jhor prepares for a crash course in python
14:43 < jrandom> :)
14:44 < jrandom> ok, anybody else have something to discuss?
14:44 * cervantes wheels out the Strand Gong
14:44 < jrandom> we're around the 60m mark, so a pretty good rate
14:44 < Teal`c> when is udp due for general consumption ?
14:44 < jrandom> Teal`c: april
14:44 < jrandom> thats 0.6, we're still working on 0.5
14:45 < Teal`c> nice work.
14:46 < jrandom> progress, ever onwards
14:46 * jrandom winds up
14:46 * jrandom *baf*s the gong, closing the meeting

10
i2p2www/meetings/126.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, January 25, 2005
=================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,159 +1,153 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 127{% endblock %}
{% block content %}<h3>I2P dev meeting, February 1, 2005</h3>
<div class="irclog">
13:06 < jrandom> 0) hi</p>
13:06 < jrandom> 1) 0.5 status</p>
13:06 < jrandom> 2) nntp</p>
13:06 < jrandom> 3) tech proposals</p>
13:06 < jrandom> 4) ???</p>
13:06 < jrandom> 0) hi</p>
13:06 * jrandom waves</p>
13:06 <+postman> hi jr</p>
13:07 * postman waves</p>
13:07 < jrandom> w3wt there is life out there :)</p>
13:07 < jrandom> weekly status notes posted up @ http://i2p.net/pipermail/i2p/2005-February/000561.html</p>
13:07 < ant> * dm waves</p>
13:08 < jrandom> while y'all read that email, we can jump into 1) 0.5 status</p>
13:08 < MANCOM> hi</p>
13:09 < jrandom> lots of progress over the last week, all the new crypto is in and tested, and now all of the router's tunnel operation is done through the new tunnel pools</p>
13:10 < jrandom> there are still some parts of the router i chopped out while doing the update, such as the tie in to request leases from clients or periodically test the tunnels, but those shouldn't be too difficult</p>
13:11 < jrandom> the code is not compatible with the live net, and is on a separate branch in cvs, so people can still pull cvs HEAD and work with the latest </p>
13:12 <+polecat> Dook I finally looked at that page, and I still don't understand how we can avoid mixmaster style redundancy to protect from tunnel detection attacks.</p>
13:12 <+protokol> yey</p>
13:12 <+polecat> I imagine it works very well though. :)</p>
13:12 <+protokol> are you throwing in any other cool compatibility-breaking stuff?</p>
13:13 <+protokol> the tunnel pool has to do with treads, right?</p>
13:13 < jrandom> polecat: we don't verify at every hop, but we have a fixed message size to prevent useful tagging (and everything is encrypted at each hop)</p>
13:14 < jrandom> protokol: i'm considering http://www.i2p/todo#sessionTag</p>
13:14 <+polecat> So how to prevent multiple hops passing around bogus messages, and causing a DoS?</p>
13:15 < jrandom> but no, the pools aren't the threading issue, the pools just let us safely manage the tunnels so that we don't get those "Lease expired" messages and can configure the length on a per-client basis</p>
13:15 < jrandom> polecat: they'll fail at the endpoint, and the creator will detect the failure and move off it</p>
13:16 <+protokol> jrandom: aside from any difficulty, i think any anon-improving features should go in ASAP</p>
13:16 <+polecat> w00t! Synchronized PRNG! First application I've ever seen of that idea!</p>
13:17 < ant> &lt;dm&gt; what does PRNG stand for?</p>
13:17 < ant> &lt;dm&gt; if I may ask :)</p>
13:18 < jrandom> protokol: agreed, thats what 0.5 is for :) there aren't any other i2p-layer low hanging fruit, but there's always improvements that can be made at the app and lib layers (e.g. i2ptunnel filtering, etc)</p>
13:18 < jrandom> dm: PseudoRandom Number Generator</p>
13:18 < ant> &lt;dm&gt; cool, thanks</p>
13:20 <+protokol> so youre saying that after this, its mostly speed and reliability tweaking?</p>
13:21 <+protokol> and why has IRC been sucking lately</p>
13:21 < jrandom> protokol: prior to 2.0 for the core and router, yes</p>
13:21 <+protokol> i cant seem to connect to ducks server</p>
13:21 <+protokol> yey</p>
13:21 * jrandom doesnt know, we've seen perhaps 5 bulk disconnects in the last day or so, perhaps something on the server side</p>
13:22 < jrandom> there's lots to be tweaked though, especially in the streaming lib after 0.5 is deployed</p>
13:23 <+polecat> That whole UDP thing.</p>
13:24 < jrandom> ah, the streaming lib shouldn't need changes for the 0.6 release, beyond the ones we do for the 0.5 rev</p>
13:25 < jrandom> ok, thats all i have to bring up wrt 0.5 status - anyone have anything else on it?</p>
13:27 < jrandom> if not, moving on to 2) nntp</p>
13:27 < jrandom> nntp.fr.i2p is up, check it out :)</p>
13:28 < jrandom> it doesnt seem like LonelyGuy is around, but he can be reached at http://fr.i2p/. there are also configuration instructions for slrn on my blog, and jdot found that thunderbird can be fairly safe (though i dont know what config jdot used)</p>
13:30 < smeghead> LonelyGuy? :)</p>
13:30 < cervantes> did someone also test Pan?</p>
13:30 < jrandom> hes been on here occationally</p>
13:30 <+polecat> I wouldn't waste too much time on nntp, but as long as it has user managed access control it's fine.</p>
13:30 < jrandom> (lonelyguy, not pan ;)</p>
13:30 < smeghead> i thought his name was LazyGuy</p>
13:31 < jrandom> is it LazyGuy?</p>
13:31 < jrandom> i know we've had both...</p>
13:31 < jrandom> you're right, lazyguy</p>
13:31 * jrandom !stabs self</p>
13:31 < jrandom> cervantes: i think LazyGuy tried it out, i dont know the config or result though</p>
13:32 < cervantes> I thought it was LimeyGuy?</p>
13:33 * jrandom awaits SnarkeyGuy's comments</p>
13:33 < smeghead> he's French</p>
13:35 < jrandom> ok, i dont have anything more to add beyond that, so unless anyone has any questions, moving on to 3) tech proposals</p>
13:35 < cervantes> smeghead: you're thinking of ParesseuxGuy</p>
13:36 < jrandom> orion has put together some good descriptions and ideas for a few of the messier issues up at 1) 0.5 status</p>
13:36 < jrandom> 2) nntp</p>
13:36 < jrandom> 3) tech proposals</p>
13:36 < jrandom> erg</p>
13:36 < jrandom> damn ^C^V</p>
13:36 < jrandom> up at http://ugha.i2p/I2pRfc that is</p>
13:37 < jrandom> so next time you want to discuss how you've got a killer naming idea, go to http://ugha.i2p/I2pRfc/I2pRfc0001ResourceNameMetadata</p>
13:39 < jrandom> i dont really have much more to add beyond that. its a wiki, get wikiing :)</p>
13:39 <+polecat> Yay.</p>
13:39 <+postman> jrandom: ohh, cool i think i need to add a few ...</p>
13:40 < jrandom> cool postman, thought you would :) there's a template up there for new ones</p>
13:41 <+postman> jrandom: gimme a lil time (first things first) but i will contribute :)</p>
13:41 < jrandom> w3rd</p>
13:41 <+polecat> ResourceNameMetadata, forming it is relatively trivial. The trick is figuring out how to /get/ it from other people.</p>
13:42 < jrandom> polecat: as postman said, first things first.</p>
13:42 <+polecat> But if I had a solution, I'd be wikiing now wouldn't I. :)</p>
13:42 < jrandom> heh</p>
13:42 < jrandom> discussion of the tradeoffs of /how/ to distribute prior to deciding /what/ to distribute is premature</p>
13:43 < jrandom> there's room for lots of 'em though, so anyone should feel free to post up ideas that aren't fully worked through yet even (though fully functional ones with implementations would be cool too ;)</p>
13:44 < jrandom> ok, unless there's something else on that, perhaps we can swing on to good ol' 4) ???</p>
13:44 < jrandom> anyone have anything else to bring up?</p>
13:45 < jrandom> smeghead: is there anything people can do to help out work through the gcj issues, or is it stalled on their prng?</p>
13:46 <+polecat> What to distribute is just a signed dict. Simple as that.</p>
13:46 <+polecat> Yeah probably a good idea.</p>
13:46 <+polecat> I'm STILL working on the skeleton for my i2p bt client, though would very much appreciate advice at any stage.</p>
13:46 < smeghead> i think i've found a solution</p>
13:46 < smeghead> in gnu crypto, there's a fortuna impl. since last summer</p>
13:46 < jrandom> nice polecat </p>
13:46 < jrandom> oh cool smeghead </p>
13:46 <+polecat> smeghead: Hee, the $150 is as good as yours.</p>
13:47 < smeghead> i can whip up a gnu-crypto.jar that contains only the classes needed for Fortuna</p>
13:47 <+polecat> My working notes so far are at http://polecat.i2p/bittorrent.plan.doc</p>
13:47 < smeghead> if we shipped the whole gnu-crypto.jar it's about 500 KB, too big really</p>
13:47 <+polecat> Don't let the .doc scare you, it's in text/plain.</p>
13:48 <+polecat> Fortuna doesn't use SecureRandom to do random things?</p>
13:48 < jrandom> yowza, yeah 500KB is a bit excessive, but glancing at http://www.gnu.org/software/gnu-crypto/, it looks like something we could integrate safely (as we'd only be linking to it, not modifying)</p>
13:48 < smeghead> SecureRandom was never the problem</p>
13:48 < jrandom> polecat: fortuna /feeds/ secureRandom :)</p>
13:49 < smeghead> jrandom: it would be easy to make a custom .jar, probably around 50KB</p>
13:49 < smeghead> (rough estimate mind you)</p>
13:49 < smeghead> i could make an ant build to custom package it on demand even</p>
13:50 < jrandom> smeghead: wanna dig 'er into i2p/apps/fortuna/ ?</p>
13:50 < smeghead> will do</p>
13:50 < jrandom> kickass!</p>
13:51 < smeghead> after that, assuming gcj will finally be spitting out random numbers, there will probably be more testing of various i2p functionality</p>
13:51 <+polecat> What's the license?</p>
13:51 < jrandom> we can then work some voodo in net.i2p.util.RandomSource to either use SecureRandom or fortuna (if its found, etc)</p>
13:51 < smeghead> lgpl</p>
13:51 <+polecat> Cool.</p>
13:51 < smeghead> true, SecureRandom would be unnecessary</p>
13:52 < jrandom> yeah, there's still lots to do to get it gcjing, but its a great start</p>
13:52 < jrandom> in the profiles i've done on the live net, reseeding the PRNG takes a good portion of the cpu load</p>
13:52 < smeghead> if anyone is into writing tests</p>
13:52 < smeghead> but i probably don't have to finish that sentence</p>
13:52 < jrandom> hehe</p>
13:53 < smeghead> i will ask the gnu crypto maintainer about this impl., because i googled for info on it and searched their mailing list archives and there's not a peep on it</p>
13:54 < smeghead> and their cvs commit logs aren't too enlightening either</p>
13:54 < jrandom> 'k good idea</p>
13:54 < smeghead> i hope it works</p>
13:54 < smeghead> it's in kaffe cvs btw</p>
13:54 < smeghead> your version should have it even</p>
13:55 < jrandom> hmm, ah, yeah from the gnu-crypto import</p>
13:55 < smeghead> gnu.security.prng.Fortuna</p>
13:55 < jrandom> the 'kaffe' provider still uses their old sha1prng iirc</p>
13:55 < jrandom> cool</p>
13:56 < MANCOM> what is the status of the .net sam stuff? should one start getting into it or are major changes to be expected?</p>
13:56 < smeghead> MANCOM: it needs testing, i'll be writing some unit tests for it soon</p>
13:56 < smeghead> this gcj thing has kinda put that on hold</p>
13:57 < smeghead> MANCOM: i don't expect there'll be any changes to the API at all, so it should be safe to code against</p>
13:58 < smeghead> changes behind the API are likely, but you as a client don't need to know that :)</p>
13:59 < MANCOM> :)</p>
13:59 < jrandom> there may be some later updates that are relevent if you build apps that do large bulk transfer</p>
14:00 < jrandom> but if you're just transferring a 10s of KB at a time, it should be fine</p>
14:00 < smeghead> ok if the Java client's API changes, then the sam-sharp's will too :)</p>
14:01 < MANCOM> i can't argue against that</p>
14:02 < jrandom> ok, does anyone have anytihng else to bring up for the meeting?</p>
14:02 * cervantes lowers big ben into the channel</p>
14:03 <+DrWoo> note: nice work jrandom</p>
14:03 < smeghead> nice pun cervantes</p>
14:03 * jrandom groans</p>
14:04 < MANCOM> i read that you don't want to advertise i2p too much before v0.5, is that true?</p>
14:04 < jrandom> MANCOM: before 0.6. yes</p>
14:04 < jrandom> MANCOM: 0.5 will improve anonymity and help users control their performance better. 0.6 will let thousands+ concurrent users operate safely</p>
14:04 < MANCOM> ah. 0.6. ok.</p>
14:05 < jrandom> gracias doc, lots of progress :)</p>
14:05 <+polecat> Whee, here's looking forward to 0.6...</p>
14:05 <+DrWoo> :)</p>
14:06 < jrandom> agreed polecat, agreed :)</p>
14:06 * jrandom winds up</p>
14:06 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:06 < jrandom> 0) hi
13:06 < jrandom> 1) 0.5 status
13:06 < jrandom> 2) nntp
13:06 < jrandom> 3) tech proposals
13:06 < jrandom> 4) ???
13:06 < jrandom> 0) hi
13:06 * jrandom waves
13:06 <+postman> hi jr
13:07 * postman waves
13:07 < jrandom> w3wt there is life out there :)
13:07 < jrandom> weekly status notes posted up @ http://i2p.net/pipermail/i2p/2005-February/000561.html
13:07 < ant> * dm waves
13:08 < jrandom> while y'all read that email, we can jump into 1) 0.5 status
13:08 < MANCOM> hi
13:09 < jrandom> lots of progress over the last week, all the new crypto is in and tested, and now all of the router's tunnel operation is done through the new tunnel pools
13:10 < jrandom> there are still some parts of the router i chopped out while doing the update, such as the tie in to request leases from clients or periodically test the tunnels, but those shouldn't be too difficult
13:11 < jrandom> the code is not compatible with the live net, and is on a separate branch in cvs, so people can still pull cvs HEAD and work with the latest
13:12 <+polecat> Dook I finally looked at that page, and I still don't understand how we can avoid mixmaster style redundancy to protect from tunnel detection attacks.
13:12 <+protokol> yey
13:12 <+polecat> I imagine it works very well though. :)
13:12 <+protokol> are you throwing in any other cool compatibility-breaking stuff?
13:13 <+protokol> the tunnel pool has to do with treads, right?
13:13 < jrandom> polecat: we don't verify at every hop, but we have a fixed message size to prevent useful tagging (and everything is encrypted at each hop)
13:14 < jrandom> protokol: i'm considering http://www.i2p/todo#sessionTag
13:14 <+polecat> So how to prevent multiple hops passing around bogus messages, and causing a DoS?
13:15 < jrandom> but no, the pools aren't the threading issue, the pools just let us safely manage the tunnels so that we don't get those "Lease expired" messages and can configure the length on a per-client basis
13:15 < jrandom> polecat: they'll fail at the endpoint, and the creator will detect the failure and move off it
13:16 <+protokol> jrandom: aside from any difficulty, i think any anon-improving features should go in ASAP
13:16 <+polecat> w00t! Synchronized PRNG! First application I've ever seen of that idea!
13:17 < ant> <dm> what does PRNG stand for?
13:17 < ant> <dm> if I may ask :)
13:18 < jrandom> protokol: agreed, thats what 0.5 is for :) there aren't any other i2p-layer low hanging fruit, but there's always improvements that can be made at the app and lib layers (e.g. i2ptunnel filtering, etc)
13:18 < jrandom> dm: PseudoRandom Number Generator
13:18 < ant> <dm> cool, thanks
13:20 <+protokol> so youre saying that after this, its mostly speed and reliability tweaking?
13:21 <+protokol> and why has IRC been sucking lately
13:21 < jrandom> protokol: prior to 2.0 for the core and router, yes
13:21 <+protokol> i cant seem to connect to ducks server
13:21 <+protokol> yey
13:21 * jrandom doesnt know, we've seen perhaps 5 bulk disconnects in the last day or so, perhaps something on the server side
13:22 < jrandom> there's lots to be tweaked though, especially in the streaming lib after 0.5 is deployed
13:23 <+polecat> That whole UDP thing.
13:24 < jrandom> ah, the streaming lib shouldn't need changes for the 0.6 release, beyond the ones we do for the 0.5 rev
13:25 < jrandom> ok, thats all i have to bring up wrt 0.5 status - anyone have anything else on it?
13:27 < jrandom> if not, moving on to 2) nntp
13:27 < jrandom> nntp.fr.i2p is up, check it out :)
13:28 < jrandom> it doesnt seem like LonelyGuy is around, but he can be reached at http://fr.i2p/. there are also configuration instructions for slrn on my blog, and jdot found that thunderbird can be fairly safe (though i dont know what config jdot used)
13:30 < smeghead> LonelyGuy? :)
13:30 < cervantes> did someone also test Pan?
13:30 < jrandom> hes been on here occationally
13:30 <+polecat> I wouldn't waste too much time on nntp, but as long as it has user managed access control it's fine.
13:30 < jrandom> (lonelyguy, not pan ;)
13:30 < smeghead> i thought his name was LazyGuy
13:31 < jrandom> is it LazyGuy?
13:31 < jrandom> i know we've had both...
13:31 < jrandom> you're right, lazyguy
13:31 * jrandom !stabs self
13:31 < jrandom> cervantes: i think LazyGuy tried it out, i dont know the config or result though
13:32 < cervantes> I thought it was LimeyGuy?
13:33 * jrandom awaits SnarkeyGuy's comments
13:33 < smeghead> he's French
13:35 < jrandom> ok, i dont have anything more to add beyond that, so unless anyone has any questions, moving on to 3) tech proposals
13:35 < cervantes> smeghead: you're thinking of ParesseuxGuy
13:36 < jrandom> orion has put together some good descriptions and ideas for a few of the messier issues up at 1) 0.5 status
13:36 < jrandom> 2) nntp
13:36 < jrandom> 3) tech proposals
13:36 < jrandom> erg
13:36 < jrandom> damn ^C^V
13:36 < jrandom> up at http://ugha.i2p/I2pRfc that is
13:37 < jrandom> so next time you want to discuss how you've got a killer naming idea, go to http://ugha.i2p/I2pRfc/I2pRfc0001ResourceNameMetadata
13:39 < jrandom> i dont really have much more to add beyond that. its a wiki, get wikiing :)
13:39 <+polecat> Yay.
13:39 <+postman> jrandom: ohh, cool i think i need to add a few ...
13:40 < jrandom> cool postman, thought you would :) there's a template up there for new ones
13:41 <+postman> jrandom: gimme a lil time (first things first) but i will contribute :)
13:41 < jrandom> w3rd
13:41 <+polecat> ResourceNameMetadata, forming it is relatively trivial. The trick is figuring out how to /get/ it from other people.
13:42 < jrandom> polecat: as postman said, first things first.
13:42 <+polecat> But if I had a solution, I'd be wikiing now wouldn't I. :)
13:42 < jrandom> heh
13:42 < jrandom> discussion of the tradeoffs of /how/ to distribute prior to deciding /what/ to distribute is premature
13:43 < jrandom> there's room for lots of 'em though, so anyone should feel free to post up ideas that aren't fully worked through yet even (though fully functional ones with implementations would be cool too ;)
13:44 < jrandom> ok, unless there's something else on that, perhaps we can swing on to good ol' 4) ???
13:44 < jrandom> anyone have anything else to bring up?
13:45 < jrandom> smeghead: is there anything people can do to help out work through the gcj issues, or is it stalled on their prng?
13:46 <+polecat> What to distribute is just a signed dict. Simple as that.
13:46 <+polecat> Yeah probably a good idea.
13:46 <+polecat> I'm STILL working on the skeleton for my i2p bt client, though would very much appreciate advice at any stage.
13:46 < smeghead> i think i've found a solution
13:46 < smeghead> in gnu crypto, there's a fortuna impl. since last summer
13:46 < jrandom> nice polecat
13:46 < jrandom> oh cool smeghead
13:46 <+polecat> smeghead: Hee, the $150 is as good as yours.
13:47 < smeghead> i can whip up a gnu-crypto.jar that contains only the classes needed for Fortuna
13:47 <+polecat> My working notes so far are at http://polecat.i2p/bittorrent.plan.doc
13:47 < smeghead> if we shipped the whole gnu-crypto.jar it's about 500 KB, too big really
13:47 <+polecat> Don't let the .doc scare you, it's in text/plain.
13:48 <+polecat> Fortuna doesn't use SecureRandom to do random things?
13:48 < jrandom> yowza, yeah 500KB is a bit excessive, but glancing at http://www.gnu.org/software/gnu-crypto/, it looks like something we could integrate safely (as we'd only be linking to it, not modifying)
13:48 < smeghead> SecureRandom was never the problem
13:48 < jrandom> polecat: fortuna /feeds/ secureRandom :)
13:49 < smeghead> jrandom: it would be easy to make a custom .jar, probably around 50KB
13:49 < smeghead> (rough estimate mind you)
13:49 < smeghead> i could make an ant build to custom package it on demand even
13:50 < jrandom> smeghead: wanna dig 'er into i2p/apps/fortuna/ ?
13:50 < smeghead> will do
13:50 < jrandom> kickass!
13:51 < smeghead> after that, assuming gcj will finally be spitting out random numbers, there will probably be more testing of various i2p functionality
13:51 <+polecat> What's the license?
13:51 < jrandom> we can then work some voodo in net.i2p.util.RandomSource to either use SecureRandom or fortuna (if its found, etc)
13:51 < smeghead> lgpl
13:51 <+polecat> Cool.
13:51 < smeghead> true, SecureRandom would be unnecessary
13:52 < jrandom> yeah, there's still lots to do to get it gcjing, but its a great start
13:52 < jrandom> in the profiles i've done on the live net, reseeding the PRNG takes a good portion of the cpu load
13:52 < smeghead> if anyone is into writing tests
13:52 < smeghead> but i probably don't have to finish that sentence
13:52 < jrandom> hehe
13:53 < smeghead> i will ask the gnu crypto maintainer about this impl., because i googled for info on it and searched their mailing list archives and there's not a peep on it
13:54 < smeghead> and their cvs commit logs aren't too enlightening either
13:54 < jrandom> 'k good idea
13:54 < smeghead> i hope it works
13:54 < smeghead> it's in kaffe cvs btw
13:54 < smeghead> your version should have it even
13:55 < jrandom> hmm, ah, yeah from the gnu-crypto import
13:55 < smeghead> gnu.security.prng.Fortuna
13:55 < jrandom> the 'kaffe' provider still uses their old sha1prng iirc
13:55 < jrandom> cool
13:56 < MANCOM> what is the status of the .net sam stuff? should one start getting into it or are major changes to be expected?
13:56 < smeghead> MANCOM: it needs testing, i'll be writing some unit tests for it soon
13:56 < smeghead> this gcj thing has kinda put that on hold
13:57 < smeghead> MANCOM: i don't expect there'll be any changes to the API at all, so it should be safe to code against
13:58 < smeghead> changes behind the API are likely, but you as a client don't need to know that :)
13:59 < MANCOM> :)
13:59 < jrandom> there may be some later updates that are relevent if you build apps that do large bulk transfer
14:00 < jrandom> but if you're just transferring a 10s of KB at a time, it should be fine
14:00 < smeghead> ok if the Java client's API changes, then the sam-sharp's will too :)
14:01 < MANCOM> i can't argue against that
14:02 < jrandom> ok, does anyone have anytihng else to bring up for the meeting?
14:02 * cervantes lowers big ben into the channel
14:03 <+DrWoo> note: nice work jrandom
14:03 < smeghead> nice pun cervantes
14:03 * jrandom groans
14:04 < MANCOM> i read that you don't want to advertise i2p too much before v0.5, is that true?
14:04 < jrandom> MANCOM: before 0.6. yes
14:04 < jrandom> MANCOM: 0.5 will improve anonymity and help users control their performance better. 0.6 will let thousands+ concurrent users operate safely
14:04 < MANCOM> ah. 0.6. ok.
14:05 < jrandom> gracias doc, lots of progress :)
14:05 <+polecat> Whee, here's looking forward to 0.6...
14:05 <+DrWoo> :)
14:06 < jrandom> agreed polecat, agreed :)
14:06 * jrandom winds up
14:06 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/127.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, February 1, 2005
=================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,291 +1,285 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 128{% endblock %}
{% block content %}<h3>I2P dev meeting, February 8, 2005</h3>
<div class="irclog">
13:05 < jrandom> 0) hi</p>
13:05 < jrandom> 1) 0.4.2.6-*</p>
13:05 < jrandom> 2) 0.5</p>
13:05 < jrandom> 3) i2p-bt 0.1.6</p>
13:05 < jrandom> 4) fortuna</p>
13:05 < jrandom> 5) ???</p>
13:06 < jrandom> 0) hi</p>
13:06 * jrandom waves</p>
13:06 <@duck> y0</p>
13:06 < smeghead> hi</p>
13:06 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-February/000564.html</p>
13:07 < cervantes> sorry I'm late...I was busy reading the status notes that were posted at the last minute...</p>
13:07 < jrandom> hey, this week they were /before/ the meeting at least (by 30s or so ;)</p>
13:08 < jrandom> anyway, while you dig through that oh so exciting email, lets jump on into 1) 0.4.2.6-*</p>
13:09 < jrandom> with the latest patches from anon et al, i'm torn between pushing out a new 0.4.2.7 so close to the 0.5 rev. </p>
13:10 < jrandom> for the moment though, if you're feeling brave, feel free to give cvs a whirl - its stable (i'm breaking things off on another branch), and has some good stuff</p>
13:11 < jrandom> the deciding factor for not pushing a rev out was when i did a checklist for 0.5 and found that the only things left were really web interface updates</p>
13:11 <+Ragnarok> about the patches from sugadude, they do represent a policy change, as we discussed filtering out non .i2p addresses before, and you decided against it</p>
13:11 < jrandom> oh, hrm? i disagree with my old self then - eepproxy doesn't accept non-.i2p address in any case, even if they were in hosts.txt</p>
13:12 < jrandom> did i have a convincing argument before?</p>
13:13 <+Ragnarok> ok, then can we revert the patch, and I can implement it the way it originally worked, which is a 0 line change?</p>
13:13 <+Ragnarok> not really, I just didn't care either way :)</p>
13:13 < jrandom> oh, cool you're the boss</p>
13:13 < cervantes> well you convinced me to drop all my work on a multi-tld management system and fire all my employees</p>
13:13 <+Ragnarok> filtering is already happening, so it's just adding a condition to an if statement</p>
13:14 < jrandom> cervantes: there's also this beautiful bridge i've got for sale...</p>
13:14 < cervantes> :)</p>
13:14 < jrandom> ok word Ragnarok, if you want to send me a .java/.tar/.diff/.whatever, that'd be great</p>
13:15 <+Ragnarok> I can do cvs now :)</p>
13:15 < jrandom> :) even better</p>
13:15 * cervantes backs up cvs head</p>
13:15 < jrandom> heh</p>
13:16 <+Ragnarok> *BOOM*</p>
13:16 <+Ragnarok> ... just kidding :)</p>
13:17 < jrandom> ok, other than that, anyone have anything else to bring up wrt 0.4.*?</p>
13:17 < ant> &lt;dm>gt; 0.4.* sucks, give us 0.5</p>
13:17 < ant> &lt;dm>gt; It's like a gazillion years old!!</p>
13:18 < ant> &lt;fvw>gt; 0.4.* doesn't suck, give us 0.5 anyway.</p>
13:18 < jrandom> 2) 0.5 it is then :)</p>
13:19 < ant> &lt;dm>gt; you guys owe me big time, I brought 0.5</p>
13:19 < jrandom> we couldn't'a done it without ya dm </p>
13:19 < ant> &lt;dm>gt; amen</p>
13:20 < jrandom> as mentioned in the notes, pretty much all the heavy lifting for 0.5 is done and tested, but there are still the odds and ends left to fix up</p>
13:21 < jrandom> (e.g. the next task on my list is a tunnel config page to manage the pools and settings)</p>
13:22 <@duck> I hope we will have a test-0.5 network before releasing?</p>
13:22 < jrandom> there have been updates to lots of different components though, so 0.5 might be a bit bumpy</p>
13:22 < ant> &lt;dm>gt; jrandom HAS a test network already.. duh</p>
13:23 < jrandom> aye, i've been doing one locally here with a dozen routers, but in the next day or two i'll try to snag some people to help with some wide area tests</p>
13:24 * postman can offer a dedicated machine</p>
13:24 < jrandom> wikked. perhaps we can try something out tomorrow, try to break some things. </p>
13:26 < cervantes> as can I</p>
13:27 < jrandom> word</p>
13:27 < jrandom> thats about all i have to say about the upcoming 0.5 at the moment - the cvs commit logs have been pretty verbose, so if you want the nitty gritty, hit 'em up</p>
13:28 < jrandom> anyone else have any comments/questions/concerns/frisbees wrt 0.5?</p>
13:29 <+postman> no</p>
13:29 * postman is looking forward to get the new V8 running :)</p>
13:30 < jrandom2p> well, 0.5 is more of a new tank - designed to improve security and anonymity, not as a performance tweak ;)</p>
13:30 < jrandom2p> but i agree, its been too long</p>
13:30 <@duck> dont forget to add a 0.5 target to bugzilla</p>
13:30 <@duck> in case there are bugs</p>
13:30 < jrandom2p> (heh, did i even add a 0.4?)</p>
13:31 < jrandom2p> but good call</p>
13:31 <@duck> or would you like bugs elsewhere</p>
13:31 <@duck> err bugreports :)</p>
13:31 <@duck> I know that I have been lazy and abuse irc messages for them</p>
13:31 < jrandom2p> no, bugzilla is great, much better than my notebook</p>
13:32 < jrandom2p> i don't blame you, as bugzilla is a bit of a pain</p>
13:32 < jrandom2p> but as bugs pile up, its for the best</p>
13:32 <@duck> nah</p>
13:33 * jrandom just noticed i'm switching schitzophrenically between screens</p>
13:34 < jrandom> ok, anyway, moving on to 3) i2p-bt 0.1.6</p>
13:34 < jrandom> duck: you've got the mic </p>
13:34 <@duck> ok</p>
13:34 <@duck> i2p-bt 0.1.5 had some issues, the two biggest ones:</p>
13:35 <@duck> - resource temporarily unavailable</p>
13:35 <@duck> - invalid argument error on windows</p>
13:35 <@duck> both have been fixed</p>
13:35 < jrandom> (yay!)</p>
13:35 <@duck> while I tried to blame the sam protocol, the sam bridge and winsock</p>
13:35 <@duck> the problem turned out to be related to non-blocking socket code</p>
13:36 <@duck> I yet have to see 0.1.6 crash</p>
13:36 <@duck> some other issues are not addressed:</p>
13:36 <@duck> the GUI users have been complaining about the popups</p>
13:36 <@duck> you can comment them out, but I didnt like that</p>
13:37 <@duck> still waiting for someone to implement a better solution</p>
13:37 <@duck> like showing a status line on the transfer window itself</p>
13:37 * smeghead hides</p>
13:37 < smeghead> i looked at that last night actually</p>
13:37 < smeghead> but it's not at the top of my priority list</p>
13:37 <@duck> or maybe one day I will look into how wxPython works and do it myself</p>
13:37 <@duck> but it's not at the top of my priority list</p>
13:38 <@duck> and I dont use the GUI, so I dont really care :P</p>
13:38 <+Ragnarok> there's always the new gui from 3.9 :)</p>
13:38 <@duck> is it any better?</p>
13:38 < smeghead> yes why did you base i2p bt on such a crusty version in the first place? :)</p>
13:38 <@duck> because it was the stable release at that moment</p>
13:39 <@duck> and not as mutilated as clients like bittornado</p>
13:40 <@duck> Ragnarok: ignoring licensing issues, I think that porting our i2p things to 3.9 might be good</p>
13:40 <+Ragnarok> the new gui is pretty awsome, imho, and it's written using pygtk, so I can actually hack on it</p>
13:40 < jrandom> what's 3.9's license? i thought it was mit-esque?</p>
13:40 <+protokol> i would love a more recent jetty version</p>
13:40 < smeghead> protokol: that's coming sooner than you think</p>
13:41 <@duck> "BitTorrent Open Source License"</p>
13:41 < smeghead> flavor of the month license</p>
13:41 <+Ragnarok> I haven't read all of it.. it seems odd</p>
13:41 <+protokol> licencing does not exist on i2p</p>
13:41 <@duck> derived from the Jabber Open Source License 1.0</p>
13:41 <+protokol> if there is source, its PD</p>
13:41 <@duck> protokol: that is why I said 'ignoring'</p>
13:42 < smeghead> and the jabber license is based on?</p>
13:42 < jrandom> (out of date copyright laws?)</p>
13:42 < smeghead> besides that :)</p>
13:43 < modulus> Sun's wish to fuck about.</p>
13:43 <@duck> http://www.opensource.org/licenses/jabberpl.php</p>
13:43 < smeghead> i move we schedule the licensing issue for the next meeting of the I2P Public Domain Security Council</p>
13:43 < modulus> ah, that one</p>
13:43 < modulus> misheard.</p>
13:45 <@duck> 3.9.0 looks hot</p>
13:45 <@duck> it is still beta though</p>
13:47 <@duck> ok, those willing to help, please let me know</p>
13:47 <@duck> so we can look into using 3.9.x</p>
13:47 <@duck> .</p>
13:47 < jrandom> w3rd</p>
13:47 < smeghead> i'm willing to help out</p>
13:47 < jrandom> i'm willing to help test</p>
13:48 <+Ragnarok> I'm willing, but there are likely to be time constraints, as I am currently having the semester from hell.</p>
13:48 < jrandom> d'oh</p>
13:48 <@duck> drop out</p>
13:48 < jrandom> damn, duck beat me</p>
13:48 < smeghead> yes, everyone does it</p>
13:49 <+Ragnarok> boo</p>
13:49 < ant> &lt;jnymo>gt; just join the military ;)</p>
13:50 < jrandom> yeah, as that'll give you lots of time to code, 'eh? ;)</p>
13:50 <+Ragnarok> I've already given up on being a math major, that's as much as you're getting from me :)</p>
13:50 < jrandom> heh</p>
13:50 < jrandom> ok, anyone else have anything on 3) i2p-bt? </p>
13:51 < ant> &lt;jnymo>gt; just don't sign up for six years</p>
13:51 <@duck> quite a bit of forum posts on it</p>
13:51 <@duck> thanks to those who aid the newbies</p>
13:51 <@duck> s/thanks/my thanks/</p>
13:51 <@duck> if you have stuff for a FAQ, lemme kno</p>
13:52 < jrandom> (if we still had drupal, we could just add a new node...)</p>
13:53 < jrandom> ok, anyway, moving on to 4) fortuna</p>
13:54 < jrandom> smeghead: wanna give us an update on things?</p>
13:54 < smeghead> yes, i'm working on pants and fortuna in tandem</p>
13:55 < smeghead> since i needed to modify fortuna's build to turn it into a pbuild</p>
13:55 < smeghead> eta on a patch that will let you test fortuna is a day or two, maybe tonight depending on what drugs are involved</p>
13:56 < jrandom> heh</p>
13:56 <@duck> so you'll get your pants down?</p>
13:56 < jrandom> ok, cool, whenever is fine - if we get it in for 0.5 in the next week or so, thats great, if not, thats great too</p>
13:56 < smeghead> well even if i finish it tonight, i would take a conservative stance on deployment</p>
13:57 < jrandom> reasonable enough</p>
13:57 < smeghead> until we get some decent testing in</p>
13:57 < smeghead> since this will be at the heart of most of i2p's crypto</p>
13:57 < jrandom> aye</p>
13:57 < ant> &lt;jnymo>gt; will jbigi stay?</p>
13:57 < smeghead> your new entropy class is cool</p>
13:58 < jrandom> yeah jnymo, this is just a random # generator</p>
13:58 < ant> &lt;jnymo>gt; ah</p>
13:59 < jrandom> we'll still need to do some research into the quality of various entropy sources in the router, but I think we'll be able to feed it some data.</p>
14:00 < smeghead> btw if anyone wants to read what this pants thing is about: http://smeghead.i2p/README_pants</p>
14:00 < jrandom> oh wikked</p>
14:01 < smeghead> pants is almost done too</p>
14:01 < brachtus> i know jbigi is kinda hard to get working with OS X/Darwin... will this have the same build problems?</p>
14:01 < smeghead> what is the issue on osx?</p>
14:01 < modulus> it's just you have to build the lib</p>
14:02 < modulus> not a big deal imo, but somewhat troublesome.</p>
14:02 < jrandom> brachtus: fortuna is in pure java, doesnt use anything native</p>
14:02 < smeghead> i can put jbigi into pants and that should make building a cinch if we ship pants with i2p</p>
14:02 < brachtus> nothign terribly difficult, it's like building a shared lib on linux, but harder than just double-click-install</p>
14:02 < smeghead> you'd need ant of course</p>
14:02 < brachtus> ok jrandom, that's great :)</p>
14:03 < jrandom> smeghead: thats actually a good point - jbigi has a pants dependency upon GMP</p>
14:03 < ant> &lt;jnymo>gt; what is pants?</p>
14:03 < smeghead> no manual mucking would be necessary</p>
14:03 < ant> * jnymo doesn't have a router up</p>
14:03 < smeghead> jnymo: read that link i just posted</p>
14:04 < jrandom> http://bolas.mine.nu:8080/cgi-bin/nph-proxy/000000A/http/smeghead.i2p/README_pants</p>
14:04 < smeghead> pants can build gmp too</p>
14:04 < jrandom> (public inproxy)</p>
14:04 < smeghead> ah nice</p>
14:04 < jrandom> yuck, that totally b0rked the text</p>
14:04 < ant> &lt;jnymo>gt; thanks jr</p>
14:04 < ant> &lt;fvw>gt; aren't you afraid of legal trouble?</p>
14:04 < smeghead> jrandom doesn't run the inproxy</p>
14:04 < jrandom> oh, the inproy is run by someone else, its been posted to the forum</p>
14:05 < jrandom> (see http://bolas.mine.nu:8080/)</p>
14:05 < cervantes> jrandom: it shouldn't be viewed as an html file...check the source</p>
14:05 < ant> &lt;fvw>gt; still, I'm amazed anyone would. But as long as it's being run by someone not vital to the project, fine :)</p>
14:05 < jrandom> hehe</p>
14:05 < jrandom> we're /all/ vital to the project :)</p>
14:06 < smeghead> fvw: i don't see inproxies as legally precarious as outrpoxies</p>
14:06 < smeghead> outproxies even</p>
14:06 < ant> &lt;fvw>gt; Perhaps not, but they can still serve up child porn and such</p>
14:06 < jrandom> only if there were such things on i2p, which, to my knowledge, there isnt </p>
14:06 < legion> outproxies could route through tor, just to be a little safer, since they would just be used for webrowsing I don't see it as a problem.</p>
14:07 < jrandom> (but yeah)</p>
14:07 < modulus> yet</p>
14:07 < ant> &lt;fvw>gt; yeah, but anyone can put it on at any point.</p>
14:07 < ant> &lt;fvw>gt; yeah, I wouldn't run a tor outproxy either. Anyway, sorry for drifting offtopic like that</p>
14:07 < jrandom> legion: yeah, though i tossed up squid.i2p before tor was out</p>
14:07 < ant> &lt;duck_>gt; to get back on topic; looking forward to pants</p>
14:08 < jrandom> aye, pants++</p>
14:08 < smeghead> i'll let you know before i drop pants on CVS</p>
14:08 < smeghead> it's kinda big</p>
14:08 < ant> &lt;duck_>gt; folks outside of i2p might be interested in it too</p>
14:09 < cervantes> yes let us all know before you drop your pants</p>
14:09 < smeghead> yes, i intend to publicise it outside of i2p also</p>
14:09 < jrandom> agreed, perhaps we should put it in another module (or on the new fast/large server)?</p>
14:09 <+Ragnarok> especially if you're a big pants kind of guy</p>
14:10 < smeghead> yes the pants module really should be kept separate from the pants repo in the source tree, currently i have them located in the same apps/pants root</p>
14:10 < smeghead> :/</p>
14:10 < smeghead> which i don't have to tell you is total pants</p>
14:11 < smeghead> so what were we talking about originally?</p>
14:11 < jrandom> hmm, we can discuss deployment options offline</p>
14:11 < jrandom> fortuna ;)</p>
14:11 < smeghead> right</p>
14:12 < jrandom> smeghead: have you looked at the AES/SHA256 needs of the impl?</p>
14:12 < jrandom> (as i2p's SHA256 doesn't do partial digests)</p>
14:13 < smeghead> hm</p>
14:13 < jrandom> AES we've got perfectly suitable block impl though</p>
14:13 < smeghead> i guess i'll find out when it blows up</p>
14:13 < jrandom> anyway, we can work those through too</p>
14:13 < jrandom> heh</p>
14:15 < jrandom> ok, anyone have any questions/thoughts/concerns on fortuna?</p>
14:15 < jrandom> if not, hopping on over to 5) ???</p>
14:15 < jrandom> cervantes: p1ng</p>
14:16 < cervantes> http://forum.i2p/viewtopic.php?t=305</p>
14:16 < cervantes> we have a new forum member of the week</p>
14:16 < cervantes> I present [drumroll] Sugadude!</p>
14:16 * brachtus applauds Sugadude</p>
14:17 < jrandom> yay</p>
14:17 < cervantes> for generally being a helpful sod to all those i2p n00bs</p>
14:17 <@duck> nice avatar too</p>
14:17 < cervantes> avatar(s)</p>
14:18 < legion> avatars? didn't know that we could have avatars on the i2p forums?</p>
14:18 < smeghead> only users who are really really bad get them</p>
14:18 < cervantes> you can't...unless you're a forum person of the week ;-)</p>
14:18 <@duck> only for the elite</p>
14:18 < legion> oh, i see...</p>
14:19 < ant> &lt;jnymo>gt; i know someone was interested in secure financial systems over i2p</p>
14:19 < legion> makes sense :)</p>
14:19 < ant> &lt;jnymo>gt; don't know if they're here, but...</p>
14:19 <@duck> I am a smelly anarcho capitalist</p>
14:19 <@duck> so try me</p>
14:20 < ant> &lt;jnymo>gt; i was reading more on threashold cryptography and theres talk about using it for that</p>
14:20 < ant> &lt;jnymo>gt; as well as securing other functions</p>
14:21 < ant> &lt;jnymo>gt; everyone familiar with threshold cryptography?</p>
14:21 < legion> IMO that cryptography and network security should be variable, how much should depend on the feature/task.</p>
14:21 < ant> &lt;duck_>gt; jnymo: a bit</p>
14:22 < ant> &lt;jnymo>gt; well, for trustable financial transactions in i2p, we want strong decentralized trust</p>
14:22 < modulus> is that about the shared keys and shit like that?</p>
14:23 < ant> &lt;jnymo>gt; yea, keys are shared in pieces</p>
14:23 < ant> &lt;duck_>gt; but in an anonymous environment, how do you know that the entities doing the sharing arent controlled by the same one?</p>
14:23 < ant> &lt;jnymo>gt; and you need to circumvent more than half of all the servers in the system to obtain the priv key</p>
14:24 < modulus> afaik it's kind of complicated the issue of distributed key generations though.</p>
14:24 < legion> yeah but in a system of millions that would be hard (yeah i2p is small at the moment, but hopefully it will grow much larger soon).</p>
14:25 < ant> &lt;jnymo>gt; atomic communications, or something.. but yea, theres issues with taking on new nodes on the system, which i thing are being worked out</p>
14:25 < ant> &lt;jnymo>gt; think</p>
14:25 < ant> &lt;jnymo>gt; so maybe its not developed enough, but i'd bet some usage of threshold crypto will end up over i2p at some point</p>
14:26 < jrandom> neat</p>
14:26 < legion> dunno, maybe</p>
14:26 < ant> &lt;jnymo>gt; someone has already built a DNSSEC addon with threshold crypto</p>
14:27 < ant> &lt;jnymo>gt; and a wrapper around bind</p>
14:27 < jrandom> thresholds work fine when identity is scarce</p>
14:27 < jrandom> in anonymous networks, however, identity is free</p>
14:27 < legion> I'd figure at the moment the highest priority is to get it more user friendly and debugged.</p>
14:27 < jrandom> (want a new destination? want 100,000?)</p>
14:28 < legion> granted it's cool whenever a new service/feature is developed.</p>
14:28 < jrandom> aye, commerce and finance on top of i2p will be nice</p>
14:28 < ant> &lt;jnymo>gt; yea, and i wouldn't know if atomic commo would work over a 10000 node threshold crypto sys</p>
14:29 < ant> &lt;jnymo>gt; well, that's all i had to say :)</p>
14:30 < jrandom> heh cool, definitely feel free to post up neat stuff to the forum or whatnot whenever</p>
14:30 < jrandom> ok, anyone else have anything for the meeting?</p>
14:32 <+ugha2p> I suck.</p>
14:33 < jrandom> whats up ugha2p?</p>
14:33 < ant> &lt;jnymo>gt; glad you got that off your' chest, ugha ;)</p>
14:33 <+ugha2p> I never remember the meetings. :)</p>
14:33 < jrandom> heh</p>
14:33 < jrandom> well, the logs will be posted soon, 90 minutes of action packed fun</p>
14:34 < jrandom> well, on that note</p>
14:34 * jrandom winds up</p>
14:34 * Curiosity waves to jrandom and stays thank-you! :D</p>
14:34 < ant> * jnymo pitches the meeting ball</p>
14:34 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:05 < jrandom> 0) hi
13:05 < jrandom> 1) 0.4.2.6-*
13:05 < jrandom> 2) 0.5
13:05 < jrandom> 3) i2p-bt 0.1.6
13:05 < jrandom> 4) fortuna
13:05 < jrandom> 5) ???
13:06 < jrandom> 0) hi
13:06 * jrandom waves
13:06 <@duck> y0
13:06 < smeghead> hi
13:06 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-February/000564.html
13:07 < cervantes> sorry I'm late...I was busy reading the status notes that were posted at the last minute...
13:07 < jrandom> hey, this week they were /before/ the meeting at least (by 30s or so ;)
13:08 < jrandom> anyway, while you dig through that oh so exciting email, lets jump on into 1) 0.4.2.6-*
13:09 < jrandom> with the latest patches from anon et al, i'm torn between pushing out a new 0.4.2.7 so close to the 0.5 rev.
13:10 < jrandom> for the moment though, if you're feeling brave, feel free to give cvs a whirl - its stable (i'm breaking things off on another branch), and has some good stuff
13:11 < jrandom> the deciding factor for not pushing a rev out was when i did a checklist for 0.5 and found that the only things left were really web interface updates
13:11 <+Ragnarok> about the patches from sugadude, they do represent a policy change, as we discussed filtering out non .i2p addresses before, and you decided against it
13:11 < jrandom> oh, hrm? i disagree with my old self then - eepproxy doesn't accept non-.i2p address in any case, even if they were in hosts.txt
13:12 < jrandom> did i have a convincing argument before?
13:13 <+Ragnarok> ok, then can we revert the patch, and I can implement it the way it originally worked, which is a 0 line change?
13:13 <+Ragnarok> not really, I just didn't care either way :)
13:13 < jrandom> oh, cool you're the boss
13:13 < cervantes> well you convinced me to drop all my work on a multi-tld management system and fire all my employees
13:13 <+Ragnarok> filtering is already happening, so it's just adding a condition to an if statement
13:14 < jrandom> cervantes: there's also this beautiful bridge i've got for sale...
13:14 < cervantes> :)
13:14 < jrandom> ok word Ragnarok, if you want to send me a .java/.tar/.diff/.whatever, that'd be great
13:15 <+Ragnarok> I can do cvs now :)
13:15 < jrandom> :) even better
13:15 * cervantes backs up cvs head
13:15 < jrandom> heh
13:16 <+Ragnarok> *BOOM*
13:16 <+Ragnarok> ... just kidding :)
13:17 < jrandom> ok, other than that, anyone have anything else to bring up wrt 0.4.*?
13:17 < ant> <dm>gt; 0.4.* sucks, give us 0.5
13:17 < ant> <dm>gt; It's like a gazillion years old!!
13:18 < ant> <fvw>gt; 0.4.* doesn't suck, give us 0.5 anyway.
13:18 < jrandom> 2) 0.5 it is then :)
13:19 < ant> <dm>gt; you guys owe me big time, I brought 0.5
13:19 < jrandom> we couldn't'a done it without ya dm
13:19 < ant> <dm>gt; amen
13:20 < jrandom> as mentioned in the notes, pretty much all the heavy lifting for 0.5 is done and tested, but there are still the odds and ends left to fix up
13:21 < jrandom> (e.g. the next task on my list is a tunnel config page to manage the pools and settings)
13:22 <@duck> I hope we will have a test-0.5 network before releasing?
13:22 < jrandom> there have been updates to lots of different components though, so 0.5 might be a bit bumpy
13:22 < ant> <dm>gt; jrandom HAS a test network already.. duh
13:23 < jrandom> aye, i've been doing one locally here with a dozen routers, but in the next day or two i'll try to snag some people to help with some wide area tests
13:24 * postman can offer a dedicated machine
13:24 < jrandom> wikked. perhaps we can try something out tomorrow, try to break some things.
13:26 < cervantes> as can I
13:27 < jrandom> word
13:27 < jrandom> thats about all i have to say about the upcoming 0.5 at the moment - the cvs commit logs have been pretty verbose, so if you want the nitty gritty, hit 'em up
13:28 < jrandom> anyone else have any comments/questions/concerns/frisbees wrt 0.5?
13:29 <+postman> no
13:29 * postman is looking forward to get the new V8 running :)
13:30 < jrandom2p> well, 0.5 is more of a new tank - designed to improve security and anonymity, not as a performance tweak ;)
13:30 < jrandom2p> but i agree, its been too long
13:30 <@duck> dont forget to add a 0.5 target to bugzilla
13:30 <@duck> in case there are bugs
13:30 < jrandom2p> (heh, did i even add a 0.4?)
13:31 < jrandom2p> but good call
13:31 <@duck> or would you like bugs elsewhere
13:31 <@duck> err bugreports :)
13:31 <@duck> I know that I have been lazy and abuse irc messages for them
13:31 < jrandom2p> no, bugzilla is great, much better than my notebook
13:32 < jrandom2p> i don't blame you, as bugzilla is a bit of a pain
13:32 < jrandom2p> but as bugs pile up, its for the best
13:32 <@duck> nah
13:33 * jrandom just noticed i'm switching schitzophrenically between screens
13:34 < jrandom> ok, anyway, moving on to 3) i2p-bt 0.1.6
13:34 < jrandom> duck: you've got the mic
13:34 <@duck> ok
13:34 <@duck> i2p-bt 0.1.5 had some issues, the two biggest ones:
13:35 <@duck> - resource temporarily unavailable
13:35 <@duck> - invalid argument error on windows
13:35 <@duck> both have been fixed
13:35 < jrandom> (yay!)
13:35 <@duck> while I tried to blame the sam protocol, the sam bridge and winsock
13:35 <@duck> the problem turned out to be related to non-blocking socket code
13:36 <@duck> I yet have to see 0.1.6 crash
13:36 <@duck> some other issues are not addressed:
13:36 <@duck> the GUI users have been complaining about the popups
13:36 <@duck> you can comment them out, but I didnt like that
13:37 <@duck> still waiting for someone to implement a better solution
13:37 <@duck> like showing a status line on the transfer window itself
13:37 * smeghead hides
13:37 < smeghead> i looked at that last night actually
13:37 < smeghead> but it's not at the top of my priority list
13:37 <@duck> or maybe one day I will look into how wxPython works and do it myself
13:37 <@duck> but it's not at the top of my priority list
13:38 <@duck> and I dont use the GUI, so I dont really care :P
13:38 <+Ragnarok> there's always the new gui from 3.9 :)
13:38 <@duck> is it any better?
13:38 < smeghead> yes why did you base i2p bt on such a crusty version in the first place? :)
13:38 <@duck> because it was the stable release at that moment
13:39 <@duck> and not as mutilated as clients like bittornado
13:40 <@duck> Ragnarok: ignoring licensing issues, I think that porting our i2p things to 3.9 might be good
13:40 <+Ragnarok> the new gui is pretty awsome, imho, and it's written using pygtk, so I can actually hack on it
13:40 < jrandom> what's 3.9's license? i thought it was mit-esque?
13:40 <+protokol> i would love a more recent jetty version
13:40 < smeghead> protokol: that's coming sooner than you think
13:41 <@duck> "BitTorrent Open Source License"
13:41 < smeghead> flavor of the month license
13:41 <+Ragnarok> I haven't read all of it.. it seems odd
13:41 <+protokol> licencing does not exist on i2p
13:41 <@duck> derived from the Jabber Open Source License 1.0
13:41 <+protokol> if there is source, its PD
13:41 <@duck> protokol: that is why I said 'ignoring'
13:42 < smeghead> and the jabber license is based on?
13:42 < jrandom> (out of date copyright laws?)
13:42 < smeghead> besides that :)
13:43 < modulus> Sun's wish to fuck about.
13:43 <@duck> http://www.opensource.org/licenses/jabberpl.php
13:43 < smeghead> i move we schedule the licensing issue for the next meeting of the I2P Public Domain Security Council
13:43 < modulus> ah, that one
13:43 < modulus> misheard.
13:45 <@duck> 3.9.0 looks hot
13:45 <@duck> it is still beta though
13:47 <@duck> ok, those willing to help, please let me know
13:47 <@duck> so we can look into using 3.9.x
13:47 <@duck> .
13:47 < jrandom> w3rd
13:47 < smeghead> i'm willing to help out
13:47 < jrandom> i'm willing to help test
13:48 <+Ragnarok> I'm willing, but there are likely to be time constraints, as I am currently having the semester from hell.
13:48 < jrandom> d'oh
13:48 <@duck> drop out
13:48 < jrandom> damn, duck beat me
13:48 < smeghead> yes, everyone does it
13:49 <+Ragnarok> boo
13:49 < ant> <jnymo>gt; just join the military ;)
13:50 < jrandom> yeah, as that'll give you lots of time to code, 'eh? ;)
13:50 <+Ragnarok> I've already given up on being a math major, that's as much as you're getting from me :)
13:50 < jrandom> heh
13:50 < jrandom> ok, anyone else have anything on 3) i2p-bt?
13:51 < ant> <jnymo>gt; just don't sign up for six years
13:51 <@duck> quite a bit of forum posts on it
13:51 <@duck> thanks to those who aid the newbies
13:51 <@duck> s/thanks/my thanks/
13:51 <@duck> if you have stuff for a FAQ, lemme kno
13:52 < jrandom> (if we still had drupal, we could just add a new node...)
13:53 < jrandom> ok, anyway, moving on to 4) fortuna
13:54 < jrandom> smeghead: wanna give us an update on things?
13:54 < smeghead> yes, i'm working on pants and fortuna in tandem
13:55 < smeghead> since i needed to modify fortuna's build to turn it into a pbuild
13:55 < smeghead> eta on a patch that will let you test fortuna is a day or two, maybe tonight depending on what drugs are involved
13:56 < jrandom> heh
13:56 <@duck> so you'll get your pants down?
13:56 < jrandom> ok, cool, whenever is fine - if we get it in for 0.5 in the next week or so, thats great, if not, thats great too
13:56 < smeghead> well even if i finish it tonight, i would take a conservative stance on deployment
13:57 < jrandom> reasonable enough
13:57 < smeghead> until we get some decent testing in
13:57 < smeghead> since this will be at the heart of most of i2p's crypto
13:57 < jrandom> aye
13:57 < ant> <jnymo>gt; will jbigi stay?
13:57 < smeghead> your new entropy class is cool
13:58 < jrandom> yeah jnymo, this is just a random # generator
13:58 < ant> <jnymo>gt; ah
13:59 < jrandom> we'll still need to do some research into the quality of various entropy sources in the router, but I think we'll be able to feed it some data.
14:00 < smeghead> btw if anyone wants to read what this pants thing is about: http://smeghead.i2p/README_pants
14:00 < jrandom> oh wikked
14:01 < smeghead> pants is almost done too
14:01 < brachtus> i know jbigi is kinda hard to get working with OS X/Darwin... will this have the same build problems?
14:01 < smeghead> what is the issue on osx?
14:01 < modulus> it's just you have to build the lib
14:02 < modulus> not a big deal imo, but somewhat troublesome.
14:02 < jrandom> brachtus: fortuna is in pure java, doesnt use anything native
14:02 < smeghead> i can put jbigi into pants and that should make building a cinch if we ship pants with i2p
14:02 < brachtus> nothign terribly difficult, it's like building a shared lib on linux, but harder than just double-click-install
14:02 < smeghead> you'd need ant of course
14:02 < brachtus> ok jrandom, that's great :)
14:03 < jrandom> smeghead: thats actually a good point - jbigi has a pants dependency upon GMP
14:03 < ant> <jnymo>gt; what is pants?
14:03 < smeghead> no manual mucking would be necessary
14:03 < ant> * jnymo doesn't have a router up
14:03 < smeghead> jnymo: read that link i just posted
14:04 < jrandom> http://bolas.mine.nu:8080/cgi-bin/nph-proxy/000000A/http/smeghead.i2p/README_pants
14:04 < smeghead> pants can build gmp too
14:04 < jrandom> (public inproxy)
14:04 < smeghead> ah nice
14:04 < jrandom> yuck, that totally b0rked the text
14:04 < ant> <jnymo>gt; thanks jr
14:04 < ant> <fvw>gt; aren't you afraid of legal trouble?
14:04 < smeghead> jrandom doesn't run the inproxy
14:04 < jrandom> oh, the inproy is run by someone else, its been posted to the forum
14:05 < jrandom> (see http://bolas.mine.nu:8080/)
14:05 < cervantes> jrandom: it shouldn't be viewed as an html file...check the source
14:05 < ant> <fvw>gt; still, I'm amazed anyone would. But as long as it's being run by someone not vital to the project, fine :)
14:05 < jrandom> hehe
14:05 < jrandom> we're /all/ vital to the project :)
14:06 < smeghead> fvw: i don't see inproxies as legally precarious as outrpoxies
14:06 < smeghead> outproxies even
14:06 < ant> <fvw>gt; Perhaps not, but they can still serve up child porn and such
14:06 < jrandom> only if there were such things on i2p, which, to my knowledge, there isnt
14:06 < legion> outproxies could route through tor, just to be a little safer, since they would just be used for webrowsing I don't see it as a problem.
14:07 < jrandom> (but yeah)
14:07 < modulus> yet
14:07 < ant> <fvw>gt; yeah, but anyone can put it on at any point.
14:07 < ant> <fvw>gt; yeah, I wouldn't run a tor outproxy either. Anyway, sorry for drifting offtopic like that
14:07 < jrandom> legion: yeah, though i tossed up squid.i2p before tor was out
14:07 < ant> <duck_>gt; to get back on topic; looking forward to pants
14:08 < jrandom> aye, pants++
14:08 < smeghead> i'll let you know before i drop pants on CVS
14:08 < smeghead> it's kinda big
14:08 < ant> <duck_>gt; folks outside of i2p might be interested in it too
14:09 < cervantes> yes let us all know before you drop your pants
14:09 < smeghead> yes, i intend to publicise it outside of i2p also
14:09 < jrandom> agreed, perhaps we should put it in another module (or on the new fast/large server)?
14:09 <+Ragnarok> especially if you're a big pants kind of guy
14:10 < smeghead> yes the pants module really should be kept separate from the pants repo in the source tree, currently i have them located in the same apps/pants root
14:10 < smeghead> :/
14:10 < smeghead> which i don't have to tell you is total pants
14:11 < smeghead> so what were we talking about originally?
14:11 < jrandom> hmm, we can discuss deployment options offline
14:11 < jrandom> fortuna ;)
14:11 < smeghead> right
14:12 < jrandom> smeghead: have you looked at the AES/SHA256 needs of the impl?
14:12 < jrandom> (as i2p's SHA256 doesn't do partial digests)
14:13 < smeghead> hm
14:13 < jrandom> AES we've got perfectly suitable block impl though
14:13 < smeghead> i guess i'll find out when it blows up
14:13 < jrandom> anyway, we can work those through too
14:13 < jrandom> heh
14:15 < jrandom> ok, anyone have any questions/thoughts/concerns on fortuna?
14:15 < jrandom> if not, hopping on over to 5) ???
14:15 < jrandom> cervantes: p1ng
14:16 < cervantes> http://forum.i2p/viewtopic.php?t=305
14:16 < cervantes> we have a new forum member of the week
14:16 < cervantes> I present [drumroll] Sugadude!
14:16 * brachtus applauds Sugadude
14:17 < jrandom> yay
14:17 < cervantes> for generally being a helpful sod to all those i2p n00bs
14:17 <@duck> nice avatar too
14:17 < cervantes> avatar(s)
14:18 < legion> avatars? didn't know that we could have avatars on the i2p forums?
14:18 < smeghead> only users who are really really bad get them
14:18 < cervantes> you can't...unless you're a forum person of the week ;-)
14:18 <@duck> only for the elite
14:18 < legion> oh, i see...
14:19 < ant> <jnymo>gt; i know someone was interested in secure financial systems over i2p
14:19 < legion> makes sense :)
14:19 < ant> <jnymo>gt; don't know if they're here, but...
14:19 <@duck> I am a smelly anarcho capitalist
14:19 <@duck> so try me
14:20 < ant> <jnymo>gt; i was reading more on threashold cryptography and theres talk about using it for that
14:20 < ant> <jnymo>gt; as well as securing other functions
14:21 < ant> <jnymo>gt; everyone familiar with threshold cryptography?
14:21 < legion> IMO that cryptography and network security should be variable, how much should depend on the feature/task.
14:21 < ant> <duck_>gt; jnymo: a bit
14:22 < ant> <jnymo>gt; well, for trustable financial transactions in i2p, we want strong decentralized trust
14:22 < modulus> is that about the shared keys and shit like that?
14:23 < ant> <jnymo>gt; yea, keys are shared in pieces
14:23 < ant> <duck_>gt; but in an anonymous environment, how do you know that the entities doing the sharing arent controlled by the same one?
14:23 < ant> <jnymo>gt; and you need to circumvent more than half of all the servers in the system to obtain the priv key
14:24 < modulus> afaik it's kind of complicated the issue of distributed key generations though.
14:24 < legion> yeah but in a system of millions that would be hard (yeah i2p is small at the moment, but hopefully it will grow much larger soon).
14:25 < ant> <jnymo>gt; atomic communications, or something.. but yea, theres issues with taking on new nodes on the system, which i thing are being worked out
14:25 < ant> <jnymo>gt; think
14:25 < ant> <jnymo>gt; so maybe its not developed enough, but i'd bet some usage of threshold crypto will end up over i2p at some point
14:26 < jrandom> neat
14:26 < legion> dunno, maybe
14:26 < ant> <jnymo>gt; someone has already built a DNSSEC addon with threshold crypto
14:27 < ant> <jnymo>gt; and a wrapper around bind
14:27 < jrandom> thresholds work fine when identity is scarce
14:27 < jrandom> in anonymous networks, however, identity is free
14:27 < legion> I'd figure at the moment the highest priority is to get it more user friendly and debugged.
14:27 < jrandom> (want a new destination? want 100,000?)
14:28 < legion> granted it's cool whenever a new service/feature is developed.
14:28 < jrandom> aye, commerce and finance on top of i2p will be nice
14:28 < ant> <jnymo>gt; yea, and i wouldn't know if atomic commo would work over a 10000 node threshold crypto sys
14:29 < ant> <jnymo>gt; well, that's all i had to say :)
14:30 < jrandom> heh cool, definitely feel free to post up neat stuff to the forum or whatnot whenever
14:30 < jrandom> ok, anyone else have anything for the meeting?
14:32 <+ugha2p> I suck.
14:33 < jrandom> whats up ugha2p?
14:33 < ant> <jnymo>gt; glad you got that off your' chest, ugha ;)
14:33 <+ugha2p> I never remember the meetings. :)
14:33 < jrandom> heh
14:33 < jrandom> well, the logs will be posted soon, 90 minutes of action packed fun
14:34 < jrandom> well, on that note
14:34 * jrandom winds up
14:34 * Curiosity waves to jrandom and stays thank-you! :D
14:34 < ant> * jnymo pitches the meeting ball
14:34 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/128.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, February 8, 2005
=================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,253 +1,247 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 129{% endblock %}
{% block content %}<h3>I2P dev meeting, February 15, 2005</h3>
<div class="irclog">
13:07 < jrandom> 0) hi</p>
13:07 < jrandom> 1) Net status</p>
13:07 < jrandom> 2) 0.5 status</p>
13:07 < jrandom> 3) i2p-bt 0.1.7</p>
13:07 < jrandom> 4) ???</p>
13:07 < jrandom> 0) hi</p>
13:07 * jrandom waves</p>
13:07 <+ugha2p> jrandom: Is irc.duck.i2p also available on the testnet and linked to this network?</p>
13:07 <+ugha2p> To this IRC network</p>
13:07 < jrandom> weekly status notes posted @ http://dev.i2p.net/pipermail/i2p/2005-February/000575.html</p>
13:07 < ant> &lt;Sonium_&gt; Bonjour, sa cette fois de la semaine encore,</p>
13:07 < jrandom> no ugha2p </p>
13:08 < ant> &lt;Sonium_&gt; are you speaking french jrandom ?</p>
13:08 < jrandom> heh, yeah, proof that babelfish has its limits ;)</p>
13:08 < jrandom> lol, yeah, people were saying babelfish was turning out ok french before, but aparently not this time ;)</p>
13:09 <+ugha2p> Hi fellow I2Pers.</p>
13:09 < ant> &lt;fedo2p&gt; hi </p>
13:09 < jrandom> anyway, lets get this underway before we netsplit again </p>
13:09 < jrandom> 1) net status</p>
13:09 < jrandom> see the email for an update</p>
13:10 < jrandom> it seems that while irc has been pretty bumpy, as has some outproxy activity, bt has been doing pretty well</p>
13:11 < jrandom> i don't really have much more to add beyond that though - anyone have any comments/questions/concerns?</p>
13:12 < ant> &lt;Sonium_&gt; will 0.5 be released this friday?</p>
13:12 < jrandom> heh good question, I suppose that can bring us on to 2) 0.5 status</p>
13:12 < jrandom> yes, 0.5 will be released this friday</p>
13:13 < jrandom> the test network is doing pretty well with the latest updates, but there's still some doc and minor cleanups left to do. i'm also going to try to get the latest jetty in there, but we'll see</p>
13:14 < ant> &lt;Sonium_&gt; a question for a native english speaker: what is the semantical difference between "it will be released" and "it is going to be released" ?</p>
13:14 < bla_> Routing seems to be a little bit of a problem sometimes; in, say 5-10% of the cases, I have to reload a page, because the tunnel isn't working well</p>
13:14 < smeghead> i'd like to request that everyone involved in bittorrent activity voluntarily cease until 0.5 is released on friday since the surge in bt traffic is ruining the rest of the network traffic, especially irc</p>
13:15 < jrandom> Sonium: the later is more definitive, but same general idea</p>
13:15 < bla_> smeghead: I'd agree, but 0.5 will not solve the load problem, will it?</p>
13:15 < smeghead> eepsites are affected too, not just irc</p>
13:16 < ant> &lt;Sonium_&gt; ok, than it missunderstood the usage till now</p>
13:16 <+ugha2p> jrandom: Will it be doing a better job with interactive traffic?</p>
13:16 < jrandom> 0.5 will change a lot of dynamics, and should be able to more cleanly handle load balancing, as we can now differentiate between the different causes of tunnel rejection</p>
13:16 < ant> &lt;Sonium_&gt; I better would have listened up at school</p>
13:16 < jrandom> ugha2p: yes, substantially</p>
13:17 <+ugha2p> Ah, cool.</p>
13:17 < jrandom> otoh, there will be an overal increase in bandwidth usage for many situations, though we will improve upon that later as things progress</p>
13:18 < smeghead> and someone please let our new french speaking users know about this and ask them to hold off the bt stuff until friday</p>
13:18 < ant> &lt;BS314159&gt; smeghead: it's three days. I'm sure you can come up with something else to do for three days</p>
13:19 * jrandom could poke open an inproxy to spaetz's 0.5 ircd :)</p>
13:20 < jrandom> perhaps a simpler solution would be to suggest bt users take advantage of the capacity to reduce network load by reducing their tunnel length</p>
13:21 < jrandom> (both on the inbound tunnels, as configured with the bt command line, and on outbound tunnels, as configured on http://localhost:7657/configclients.jsp )</p>
13:21 < polecat> Yeah, they don't need so much anonymity as obscurity. It's us illegal alien ferrets that need the 2 hop thingy.</p>
13:21 < bla_> jrandom: A possible solution, bt-0.1.8, wiith default tunnels length of 1, was mentioned before here on the channel. Duck, you here?</p>
13:22 < polecat> Does i2p-bt use SAM, or does it use an i2ptunnel session?</p>
13:23 < jrandom> hmm, otoh there are a whole set of new i2cp session options we'll want exposed in the i2p-bt, so i'll need to get in touch with duck about an updated release anyway </p>
13:23 < jrandom> polecat: SAM</p>
13:23 < smeghead> BS314159: i'm a contributor to not only i2p codebase, but also i2p-bt, this bt traffic is preventing me from communicating with the other devs and impeding our efforts to improve everyone's experience, have some consideration please</p>
13:23 < smeghead> BS314159: is it more important for you to torrent than it is for us to develop</p>
13:23 < smeghead> ?</p>
13:23 < smeghead> polecat: sam</p>
13:23 < cervantes> make 0.1.8 shop all it's users to the mpaa and we'll all stick with 0.1.7</p>
13:23 < smeghead> bla_: there probably won't be a 0.1.8, we've got 0.2.0 in cvs now, a new codebase based on bt 3.9.1</p>
13:23 < jrandom> heh cervantes </p>
13:23 < jrandom> ooOOo nice</p>
13:24 < jrandom> perhaps thats a good segue from 2) 0.5 status to 3) i2p-bt :)</p>
13:24 < jrandom> smeghead/duck, how goes? </p>
13:25 < ant> &lt;Sonium_&gt; google knows 167 links to www.i2p.org</p>
13:25 < bla_> jrandom: Maybe the upgrade timeline should be reiterated: take yer eepsite offline on Thursday evening (UTC), upgrade on Friday, and fire up the eepsite when a sufficient number of users have upgraded</p>
13:26 < ant> &lt;Sonium_&gt; erm .net</p>
13:26 < smeghead> all the bt mods in 0.1.7 have been integrated into the new 0.2.0 codebase</p>
13:26 < smeghead> but we have to write a completely new sam interface, we can't use the one from 0.1.7</p>
13:27 < jrandom> ah ok</p>
13:27 < smeghead> if there's anyone with python socket experience that would like to help *cough*connelly</p>
13:28 < polecat> All that's happening in SAM is the addition of stream level choking, right?</p>
13:28 < jrandom> polecat: no protocol changes yet (to my knowledge), just porting</p>
13:28 < smeghead> please get in touch with duck</p>
13:28 < ant> &lt;MANCOM&gt; anything new on azneti2p?</p>
13:28 < smeghead> the 0.2.0 client will handle multiple torrents all in one instance, you won't have to open multiple sessions anymore</p>
13:29 < jrandom> (yay!)</p>
13:29 < polecat> Reeeally?</p>
13:29 < smeghead> and hopefully we can get it all working over a single sam session to further reduce network clutterage</p>
13:29 < bla_> smeghead: Nice! Will you also port the text-onlu bttrackmany?</p>
13:29 < polecat> Can it run in the background?</p>
13:29 < jrandom> MANCOM: I haven't heard any news, and unfortunately haven't had time to audit the updates</p>
13:29 < polecat> How much memory does it sit on?</p>
13:29 < smeghead> bla_: yes i believe so</p>
13:30 < smeghead> polecat: using btdownloadheadless.py it's a background process</p>
13:31 < polecat> A single SAM session is possible: the peerwire and tracker protocol can be divined by both the client and server.</p>
13:31 < polecat> smeghead: Yes, but what if I want to add a torrent to that process?</p>
13:32 < smeghead> polecat: and it shouldn't use significantly more memory than the comparable number of 0.1.7 instances do</p>
13:34 < jrandom> polecat: its a port of the mainline BT, it works just like the mainline BT. someone could add new and better features, but lets start with a plain port first ;)</p>
13:36 < bla_> (Connection rollercoaster ride, again...)</p>
13:36 < jrandom> (this is why I lightly edit the meeting logs ;)</p>
13:37 < bla_> jrandom: :)</p>
13:37 < jrandom> wb</p>
13:37 < polecat> smeghead: Yes, but what if I want to add a torrent to that process?</p>
13:38 <+ugha2p> jrandom: No, it must be because you're censoring the netsplits.</p>
13:38 < jrandom> polecat: its a port of the mainline BT, it works just like the mainline BT. someone could add new and better features, but lets start with a plain port first ;)</p>
13:38 < jrandom> hey, if i censor the netsplits, they dont happen! </p>
13:38 * jrandom buries head in sand</p>
13:40 < smeghead> but i will use this opportunity to again ask bt users to hold off until friday please</p>
13:41 < bla_> Right, if there's anyone who speaks French here, you don't have to say anything now, but please add a message to the effect of what smeghead asks to the French sections of forum.i2p ...</p>
13:42 <+polecat> At any rate, I've missed the chance to say but, I was thinking of instead of a bt client in C++, I could just fix the mldonkey bittorrent plugin, and use that.</p>
13:42 < ant> &lt;dm&gt; I speak french.</p>
13:43 < ant> &lt;dm&gt; awww shit, I was supposed to not say anything.</p>
13:43 * jrandom flings mud at dm</p>
13:43 < bla_> dm: Could you add those messages?</p>
13:43 < smeghead> there's nothing wrong with torrenting, but then again such a sudden increase in the number of i2p users wasn't expected and clearly the 0.4.x network can't handle it well</p>
13:43 <+polecat> Unless someone else had an idea for something better I could waste my time on. :/</p>
13:44 < ant> &lt;dm&gt; don't have i2p on here, I'm afraid. I can translate english-&gt;french if u msg me what needs to be said.</p>
13:44 < jrandom> polecat: perhaps help out getting the upcoming i2p-bt to work as you'd like?</p>
13:44 < jrandom> dm: forum.i2p.net/</p>
13:44 <+polecat> jrandom: I think the main bt isn't very useful myself, and is doomed to be a stopping block for multiple torrent system, unless they switch to a client/server UI.</p>
13:44 <+polecat> Which I might add, mldonkey/mlnet has already done.</p>
13:44 < smeghead> polecat: mldonkey is a horrid, horrid mess, please help on the i2p-bt project or the azureus-i2p project, they could use a hand</p>
13:44 < ant> &lt;BS314159&gt; polecat: I think it's a waste of time to reimplement i2p-bt in a faster language, given the overhead in I2P</p>
13:45 <+polecat> And I was planning to do with this stupid C++ client thingy o' mine.</p>
13:45 < jrandom> polecat: so put on a gui, giving you the benefit of the underlying i2p-bt code</p>
13:45 < ant> &lt;BS314159&gt; but having the use of the MLDonkey interface might be a very good thing</p>
13:46 <+polecat> Azareus doesn't separate UI from file transfer I dun' think. :/</p>
13:46 < smeghead> polecat: you need to try bt 3.9.1, it's a multitorrent client now</p>
13:48 <+polecat> Does it allow you to quit the UI without quitting swarming your files?</p>
13:48 < jrandom> there are some features that it doesnt do well, that azureus does well, though there are also some environments where azureus isn't the right solution</p>
13:48 < ant> &lt;jnymo&gt; has azureus released a compatable binary for the plugin?</p>
13:48 < jrandom> polecat: no. but adding that is trivial compared to writing a new bt client</p>
13:48 < jrandom> jnymo: yes, they have a beta azneti2p</p>
13:49 < smeghead> polecat: it could easily be modified to do so, very easily in fact</p>
13:49 < jrandom> polecat: just modify the existing bt daemon to allow other processes (aka your new GUI) to tell it to do things</p>
13:49 <+polecat> Well, perhaps...</p>
13:49 <+polecat> You think so?</p>
13:49 <+polecat> Maybe if I wrote a UI that was just an RPC socket protocol, and then... I'd have to write a whole client to grok that protocol...</p>
13:50 < smeghead> polecat: you don't have to write a new ui, mod the existing i2p-bt 0.2.0 ui to do it, it's simple</p>
13:50 <+polecat> Maybe we could separate the UI part of bt and the daemon part, and run those pieces as separate processes without having to rewrite too much code!</p>
13:50 <+polecat> Okay.</p>
13:50 <+polecat> I have one more question though...</p>
13:51 < smeghead> polecat: don't reinvent the wheel because something lacks trivial features</p>
13:51 < smeghead> polecat: you haven't looked at the i2p-bt codebase at all have you? the ui is completely separate</p>
13:51 <+polecat> If bittorrent 3.9.1 is out, why are we using version 0.2.0 in i2p? o.o </p>
13:51 < jrandom> heh</p>
13:51 < jrandom> i2p-bt 0.2.0 == bt 3.9.1 :)</p>
13:51 <+polecat> I looked at the codebase a while ago. It was quite convoluted and obfuscated.</p>
13:51 < jrandom> (i2p-bt 0.1.* == bt 3.4.something i think)</p>
13:51 <+polecat> Oh, you have different versioning.</p>
13:52 <+polecat> Is i2p-bt on CVS?</p>
13:52 < smeghead> polecat: 0.2.0 is a new branch in cvs i created yesterday, it's i2p-bt, the official bt version it's based on is 3.9.1 which will be bittorrent 4.0 when it's out of beta</p>
13:52 < jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p-bt/</p>
13:52 < smeghead> i2p-bt 0.1.7 is bt 3.4.2 based</p>
13:52 <+polecat> Thanks.</p>
13:52 <+polecat> Wait.</p>
13:53 < cervantes> at which point we'll call it version 0.3.0 :P</p>
13:53 <+polecat> I meant CVS, not the "ooh lookit the pretty website CVS"</p>
13:53 < jrandom> cvs -d :pserver:anoncvs@cvs.i2p.net/cvsroot co i2p-bt</p>
13:53 <+polecat> CVSROOT= is noticeably absent on those cvs-cgi thingies I've noticed.</p>
13:53 < jrandom> or, if you have the CVS proxy locally, cvs -d :pserver:anoncvs@localhost/cvsroot co i2p-bt</p>
13:54 < smeghead> polecat: convoluted? btdownloadgui.py is all the gui code, how can you get more cleanly separated than that?</p>
13:54 * polecat whews, and doesn't feel a burning desire to bitch about CVS now.</p>
13:54 < ant> &lt;dm&gt; ugh, that was painful, haven't written anything in french for years! http://forum.i2p.net/viewtopic.php?p=1238#1238</p>
13:55 < jrandom> thanks dm</p>
13:56 < ant> &lt;dm&gt; np</p>
13:57 < smeghead> it probably says something obscene</p>
13:58 < ant> &lt;dm&gt; hehehhe</p>
13:58 <+polecat> Alright, so I have to write btdaemon.py, which is the gui - all gui stuff. And also btdaemongui.py, which is the gui - all daemon stuff.</p>
13:58 < ant> &lt;BS314159&gt; if it's sufficiently obscene, it may serve our purposes just fine</p>
13:58 < ant> &lt;fedo2p&gt; good job dm ;)</p>
13:58 < jrandom> heh</p>
13:58 < jrandom> r0x0r polecat</p>
13:59 <+polecat> Sigh, I hate to emerge wxwindows though, it's a big library I don't normally use. Oh well.</p>
13:59 < smeghead> polecat: 0.2.0 is gtk based, no more wxwidgets</p>
13:59 < jrandom> ok, lots of bt work to do, perhaps we can discuss further on the list/forum/wiki/#i2p-bt as necessary?</p>
13:59 <+polecat> If I'm gonna be hackin', I best get the toolz</p>
14:00 <+polecat> Oh I forgot about that channel. :)</p>
14:00 < smeghead> polecat: get bittorrent 3.9.1 beta and read the docs</p>
14:01 < smeghead> #i2p-bt, right</p>
14:01 < smeghead> there's even people there</p>
14:02 < jrandom> heh ok, lots of exciting bt stuff. anything else for 3) i2p-bt, or shall we move on to 4) ???</p>
14:03 < jrandom> ok, moving to 4) ???</p>
14:03 < jrandom> anyone else have anything else to bring up for the meeting?</p>
14:03 < ant> &lt;jnymo&gt; threshold crytography rules</p>
14:04 < cervantes> ??? = http://forum.i2p/viewtopic.php?p=1237</p>
14:04 < ant> &lt;BS314159&gt; proxies to the web are not cool. What about proxies to new versions of I2P, or other anonymnets?</p>
14:04 < ant> &lt;BS314159&gt; and by not cool I mean not safe to run</p>
14:04 < ant> &lt;jnymo&gt; they aren't run by everyone, BS</p>
14:05 < ant> &lt;BS314159&gt; I know that</p>
14:05 < cervantes> Forum member of the week is &lt;tadaa!&gt; jrandom</p>
14:05 < ant> &lt;BS314159&gt; I'm thinking about upgrades</p>
14:05 < jrandom> lol thanks cervantes </p>
14:06 < ant> &lt;BS314159&gt; Not now, but eventually, would it be possible to have a large number of routers act as inter-version proxies?</p>
14:06 < ant> &lt;BS314159&gt; and would that remove the timing attack without downtime?</p>
14:06 < ant> &lt;jnymo&gt; forced upgrades are necessary</p>
14:07 < ant> &lt;BS314159&gt; I disagree</p>
14:07 < jrandom> BS314159: I2NP over i2ptunnel over I2P would be, painful. though perhaps one of the "outproxies" could point at some inproxy </p>
14:07 < jrandom> BS314159: while forced upgrades aren't generally necessary, they are here. period. we need it, because I didn't forsee all of the changes we need for 0.5</p>
14:08 < ant> &lt;BS314159&gt; I'm not saying new versions should be backwards-compatible</p>
14:08 < cervantes> jrandom: well lets be honest...you're the one that does 98% of the work ;-)</p>
14:09 < ant> &lt;BS314159&gt; I'm just trying to come up with a way to allow non-nimble I2P users to upgrade without timing attacks or downtime</p>
14:10 < jrandom> BS314159: can't be done for the 0.5 release. later releases we can be careful. but for this one, its a drop dead cutoff. </p>
14:10 < ant> &lt;jnymo&gt; automatic update may be better in the future</p>
14:10 < ant> &lt;BS314159&gt; I'm speaking about the far future.</p>
14:10 < ant> &lt;jnymo&gt; is auto-update too insecure?</p>
14:10 < jrandom> cervantes: nah, only 95% of the infrastructure, but there's a lot more goin' on than just i2p/{core,router}/ :)</p>
14:11 < jrandom> jnymo: 0 click update == insecure. 1 click == safe.</p>
14:11 < cervantes> jrandom: yes it's begun to pickup over the last couple of months thankfully ;-)</p>
14:11 < ant> &lt;jnymo&gt; and a line that says "you need to update.. countdown in * days"</p>
14:12 < jrandom> aye, lots of people [http://www.i2p.net/team] have been doing kickass shit</p>
14:13 < jrandom> BS314159: definitely lots we can do for later updates, perhaps we can discuss concrete impls as they approach :)</p>
14:13 < jrandom> ok, anyone else have anything to bring up for the meeting?</p>
14:13 < ant> &lt;MANCOM&gt; could we have some kind of autospeed feature (like with the azureus plugin that measures ping times) in i2p that adjusts the maximum (upload-)bandwidth?</p>
14:14 < ant> &lt;MANCOM&gt; it would help keep bandwidth up and latency down</p>
14:14 < jrandom> oh, interesting</p>
14:14 * cervantes is working on a 1-2 click update feature for the i2p toolbar</p>
14:14 < cervantes> although I'm having problems with hashing atm....so it's probably a few weeks away.</p>
14:15 < ant> &lt;jnymo&gt; cervantes++</p>
14:15 < jrandom> MANCOM: if you could doc up how it'd work and look, and post that on the forum, that'd be great. if its simple enough, might even make it into 0.5</p>
14:15 < cervantes> in which time a dozen people will come up with a glut of better solutions</p>
14:16 < jrandom> heh</p>
14:16 < cneal92_> :D</p>
14:17 < ant> &lt;MANCOM&gt; well, i'll try</p>
14:17 < ant> &lt;cervantes&gt; but it already detects when there's a new release out, and can point you at the relevant download link...</p>
14:17 < ant> &lt;cervantes&gt; which I may roll with initially</p>
14:18 < jrandom> cool cervantes</p>
14:18 < jrandom> thanks MANCOM</p>
14:18 < ant> &lt;jnymo&gt; you could just put the "graceful restart" button to upgrade, after the update is already in the directory</p>
14:19 < ant> &lt;jnymo&gt; or call it "upgrade"</p>
14:19 < ant> &lt;jnymo&gt; and put the restart function in there</p>
14:19 < ant> &lt;jnymo&gt; though i'm probably stating the obvious</p>
14:19 < jrandom> right, we need perhaps a dozen lines of code to fetch http://dev.i2p/i2p/i2pupdate.zip, verify it, then restart</p>
14:20 < jrandom> ok, anyone else have anything to bring up for the meeting?</p>
14:20 < ant> &lt;cervantes&gt; well I can already get the toolbar to download an update into the i2p folder AND trigger a graceful restart...but so far I haven't been able to get it verify the download's integrity</p>
14:21 < jrandom> cervantes: ah, that part should be easy - at a later date, we'll have the update itself be self-verifying</p>
14:21 < jrandom> (aka signed, verified by the router before installation)</p>
14:21 < ant> &lt;cervantes&gt; jrandom: that would be cool.</p>
14:21 < ant> &lt;jnymo&gt; ooh</p>
14:22 < ant> &lt;cervantes&gt; perhaps it will be enough then that I trigger the download and then pop a "do you wish to restart" yes/no requester</p>
14:22 < ant> &lt;cervantes&gt; so someone can verify manually if desired</p>
14:23 < ant> &lt;cervantes&gt; (it already displays what the sha1 _should_ be)</p>
14:23 < jrandom> hehe</p>
14:23 < ant> &lt;jnymo&gt; how bout, "click here to autodownload on availability"</p>
14:25 < cervantes> I'd rather avoid auto downloads</p>
14:25 < ant> &lt;jnymo&gt; hmf.. microsoft does it ;)</p>
14:26 < cervantes> but by all means alert the user that a download exists and offer a "download now" button</p>
14:26 < jrandom> right, 1 click at the least. we can automatically /notify/ on update availability, but autoinstall is not ok</p>
14:26 < jrandom> (er, what cervantes said)</p>
14:27 < ant> &lt;jnymo&gt; now, how do 10000 people update? how bout integrating i2p-bt at one point?</p>
14:27 < jrandom> yes, and flying ponies</p>
14:28 < ant> &lt;jnymo&gt; good enough for me</p>
14:29 < jrandom> ok cool... if there's nothing else...</p>
14:29 <+postman> damn missed the meeting :/</p>
14:29 * cervantes gets back to coding his vapourware</p>
14:29 < jrandom> heh you're at the buzzer, in case there's something you want to bring up postman :)</p>
14:30 <+postman> no thanks</p>
14:30 <+polecat> Microsoft? =) I have gentoo doing it.</p>
14:30 * jrandom winds up</p>
14:30 <+postman> ooops</p>
14:30 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:07 < jrandom> 0) hi
13:07 < jrandom> 1) Net status
13:07 < jrandom> 2) 0.5 status
13:07 < jrandom> 3) i2p-bt 0.1.7
13:07 < jrandom> 4) ???
13:07 < jrandom> 0) hi
13:07 * jrandom waves
13:07 <+ugha2p> jrandom: Is irc.duck.i2p also available on the testnet and linked to this network?
13:07 <+ugha2p> To this IRC network
13:07 < jrandom> weekly status notes posted @ http://dev.i2p.net/pipermail/i2p/2005-February/000575.html
13:07 < ant> <Sonium_> Bonjour, sa cette fois de la semaine encore,
13:07 < jrandom> no ugha2p
13:08 < ant> <Sonium_> are you speaking french jrandom ?
13:08 < jrandom> heh, yeah, proof that babelfish has its limits ;)
13:08 < jrandom> lol, yeah, people were saying babelfish was turning out ok french before, but aparently not this time ;)
13:09 <+ugha2p> Hi fellow I2Pers.
13:09 < ant> <fedo2p> hi
13:09 < jrandom> anyway, lets get this underway before we netsplit again
13:09 < jrandom> 1) net status
13:09 < jrandom> see the email for an update
13:10 < jrandom> it seems that while irc has been pretty bumpy, as has some outproxy activity, bt has been doing pretty well
13:11 < jrandom> i don't really have much more to add beyond that though - anyone have any comments/questions/concerns?
13:12 < ant> <Sonium_> will 0.5 be released this friday?
13:12 < jrandom> heh good question, I suppose that can bring us on to 2) 0.5 status
13:12 < jrandom> yes, 0.5 will be released this friday
13:13 < jrandom> the test network is doing pretty well with the latest updates, but there's still some doc and minor cleanups left to do. i'm also going to try to get the latest jetty in there, but we'll see
13:14 < ant> <Sonium_> a question for a native english speaker: what is the semantical difference between "it will be released" and "it is going to be released" ?
13:14 < bla_> Routing seems to be a little bit of a problem sometimes; in, say 5-10% of the cases, I have to reload a page, because the tunnel isn't working well
13:14 < smeghead> i'd like to request that everyone involved in bittorrent activity voluntarily cease until 0.5 is released on friday since the surge in bt traffic is ruining the rest of the network traffic, especially irc
13:15 < jrandom> Sonium: the later is more definitive, but same general idea
13:15 < bla_> smeghead: I'd agree, but 0.5 will not solve the load problem, will it?
13:15 < smeghead> eepsites are affected too, not just irc
13:16 < ant> <Sonium_> ok, than it missunderstood the usage till now
13:16 <+ugha2p> jrandom: Will it be doing a better job with interactive traffic?
13:16 < jrandom> 0.5 will change a lot of dynamics, and should be able to more cleanly handle load balancing, as we can now differentiate between the different causes of tunnel rejection
13:16 < ant> <Sonium_> I better would have listened up at school
13:16 < jrandom> ugha2p: yes, substantially
13:17 <+ugha2p> Ah, cool.
13:17 < jrandom> otoh, there will be an overal increase in bandwidth usage for many situations, though we will improve upon that later as things progress
13:18 < smeghead> and someone please let our new french speaking users know about this and ask them to hold off the bt stuff until friday
13:18 < ant> <BS314159> smeghead: it's three days. I'm sure you can come up with something else to do for three days
13:19 * jrandom could poke open an inproxy to spaetz's 0.5 ircd :)
13:20 < jrandom> perhaps a simpler solution would be to suggest bt users take advantage of the capacity to reduce network load by reducing their tunnel length
13:21 < jrandom> (both on the inbound tunnels, as configured with the bt command line, and on outbound tunnels, as configured on http://localhost:7657/configclients.jsp )
13:21 < polecat> Yeah, they don't need so much anonymity as obscurity. It's us illegal alien ferrets that need the 2 hop thingy.
13:21 < bla_> jrandom: A possible solution, bt-0.1.8, wiith default tunnels length of 1, was mentioned before here on the channel. Duck, you here?
13:22 < polecat> Does i2p-bt use SAM, or does it use an i2ptunnel session?
13:23 < jrandom> hmm, otoh there are a whole set of new i2cp session options we'll want exposed in the i2p-bt, so i'll need to get in touch with duck about an updated release anyway
13:23 < jrandom> polecat: SAM
13:23 < smeghead> BS314159: i'm a contributor to not only i2p codebase, but also i2p-bt, this bt traffic is preventing me from communicating with the other devs and impeding our efforts to improve everyone's experience, have some consideration please
13:23 < smeghead> BS314159: is it more important for you to torrent than it is for us to develop
13:23 < smeghead> ?
13:23 < smeghead> polecat: sam
13:23 < cervantes> make 0.1.8 shop all it's users to the mpaa and we'll all stick with 0.1.7
13:23 < smeghead> bla_: there probably won't be a 0.1.8, we've got 0.2.0 in cvs now, a new codebase based on bt 3.9.1
13:23 < jrandom> heh cervantes
13:23 < jrandom> ooOOo nice
13:24 < jrandom> perhaps thats a good segue from 2) 0.5 status to 3) i2p-bt :)
13:24 < jrandom> smeghead/duck, how goes?
13:25 < ant> <Sonium_> google knows 167 links to www.i2p.org
13:25 < bla_> jrandom: Maybe the upgrade timeline should be reiterated: take yer eepsite offline on Thursday evening (UTC), upgrade on Friday, and fire up the eepsite when a sufficient number of users have upgraded
13:26 < ant> <Sonium_> erm .net
13:26 < smeghead> all the bt mods in 0.1.7 have been integrated into the new 0.2.0 codebase
13:26 < smeghead> but we have to write a completely new sam interface, we can't use the one from 0.1.7
13:27 < jrandom> ah ok
13:27 < smeghead> if there's anyone with python socket experience that would like to help *cough*connelly
13:28 < polecat> All that's happening in SAM is the addition of stream level choking, right?
13:28 < jrandom> polecat: no protocol changes yet (to my knowledge), just porting
13:28 < smeghead> please get in touch with duck
13:28 < ant> <MANCOM> anything new on azneti2p?
13:28 < smeghead> the 0.2.0 client will handle multiple torrents all in one instance, you won't have to open multiple sessions anymore
13:29 < jrandom> (yay!)
13:29 < polecat> Reeeally?
13:29 < smeghead> and hopefully we can get it all working over a single sam session to further reduce network clutterage
13:29 < bla_> smeghead: Nice! Will you also port the text-onlu bttrackmany?
13:29 < polecat> Can it run in the background?
13:29 < jrandom> MANCOM: I haven't heard any news, and unfortunately haven't had time to audit the updates
13:29 < polecat> How much memory does it sit on?
13:29 < smeghead> bla_: yes i believe so
13:30 < smeghead> polecat: using btdownloadheadless.py it's a background process
13:31 < polecat> A single SAM session is possible: the peerwire and tracker protocol can be divined by both the client and server.
13:31 < polecat> smeghead: Yes, but what if I want to add a torrent to that process?
13:32 < smeghead> polecat: and it shouldn't use significantly more memory than the comparable number of 0.1.7 instances do
13:34 < jrandom> polecat: its a port of the mainline BT, it works just like the mainline BT. someone could add new and better features, but lets start with a plain port first ;)
13:36 < bla_> (Connection rollercoaster ride, again...)
13:36 < jrandom> (this is why I lightly edit the meeting logs ;)
13:37 < bla_> jrandom: :)
13:37 < jrandom> wb
13:37 < polecat> smeghead: Yes, but what if I want to add a torrent to that process?
13:38 <+ugha2p> jrandom: No, it must be because you're censoring the netsplits.
13:38 < jrandom> polecat: its a port of the mainline BT, it works just like the mainline BT. someone could add new and better features, but lets start with a plain port first ;)
13:38 < jrandom> hey, if i censor the netsplits, they dont happen!
13:38 * jrandom buries head in sand
13:40 < smeghead> but i will use this opportunity to again ask bt users to hold off until friday please
13:41 < bla_> Right, if there's anyone who speaks French here, you don't have to say anything now, but please add a message to the effect of what smeghead asks to the French sections of forum.i2p ...
13:42 <+polecat> At any rate, I've missed the chance to say but, I was thinking of instead of a bt client in C++, I could just fix the mldonkey bittorrent plugin, and use that.
13:42 < ant> <dm> I speak french.
13:43 < ant> <dm> awww shit, I was supposed to not say anything.
13:43 * jrandom flings mud at dm
13:43 < bla_> dm: Could you add those messages?
13:43 < smeghead> there's nothing wrong with torrenting, but then again such a sudden increase in the number of i2p users wasn't expected and clearly the 0.4.x network can't handle it well
13:43 <+polecat> Unless someone else had an idea for something better I could waste my time on. :/
13:44 < ant> <dm> don't have i2p on here, I'm afraid. I can translate english->french if u msg me what needs to be said.
13:44 < jrandom> polecat: perhaps help out getting the upcoming i2p-bt to work as you'd like?
13:44 < jrandom> dm: forum.i2p.net/
13:44 <+polecat> jrandom: I think the main bt isn't very useful myself, and is doomed to be a stopping block for multiple torrent system, unless they switch to a client/server UI.
13:44 <+polecat> Which I might add, mldonkey/mlnet has already done.
13:44 < smeghead> polecat: mldonkey is a horrid, horrid mess, please help on the i2p-bt project or the azureus-i2p project, they could use a hand
13:44 < ant> <BS314159> polecat: I think it's a waste of time to reimplement i2p-bt in a faster language, given the overhead in I2P
13:45 <+polecat> And I was planning to do with this stupid C++ client thingy o' mine.
13:45 < jrandom> polecat: so put on a gui, giving you the benefit of the underlying i2p-bt code
13:45 < ant> <BS314159> but having the use of the MLDonkey interface might be a very good thing
13:46 <+polecat> Azareus doesn't separate UI from file transfer I dun' think. :/
13:46 < smeghead> polecat: you need to try bt 3.9.1, it's a multitorrent client now
13:48 <+polecat> Does it allow you to quit the UI without quitting swarming your files?
13:48 < jrandom> there are some features that it doesnt do well, that azureus does well, though there are also some environments where azureus isn't the right solution
13:48 < ant> <jnymo> has azureus released a compatable binary for the plugin?
13:48 < jrandom> polecat: no. but adding that is trivial compared to writing a new bt client
13:48 < jrandom> jnymo: yes, they have a beta azneti2p
13:49 < smeghead> polecat: it could easily be modified to do so, very easily in fact
13:49 < jrandom> polecat: just modify the existing bt daemon to allow other processes (aka your new GUI) to tell it to do things
13:49 <+polecat> Well, perhaps...
13:49 <+polecat> You think so?
13:49 <+polecat> Maybe if I wrote a UI that was just an RPC socket protocol, and then... I'd have to write a whole client to grok that protocol...
13:50 < smeghead> polecat: you don't have to write a new ui, mod the existing i2p-bt 0.2.0 ui to do it, it's simple
13:50 <+polecat> Maybe we could separate the UI part of bt and the daemon part, and run those pieces as separate processes without having to rewrite too much code!
13:50 <+polecat> Okay.
13:50 <+polecat> I have one more question though...
13:51 < smeghead> polecat: don't reinvent the wheel because something lacks trivial features
13:51 < smeghead> polecat: you haven't looked at the i2p-bt codebase at all have you? the ui is completely separate
13:51 <+polecat> If bittorrent 3.9.1 is out, why are we using version 0.2.0 in i2p? o.o
13:51 < jrandom> heh
13:51 < jrandom> i2p-bt 0.2.0 == bt 3.9.1 :)
13:51 <+polecat> I looked at the codebase a while ago. It was quite convoluted and obfuscated.
13:51 < jrandom> (i2p-bt 0.1.* == bt 3.4.something i think)
13:51 <+polecat> Oh, you have different versioning.
13:52 <+polecat> Is i2p-bt on CVS?
13:52 < smeghead> polecat: 0.2.0 is a new branch in cvs i created yesterday, it's i2p-bt, the official bt version it's based on is 3.9.1 which will be bittorrent 4.0 when it's out of beta
13:52 < jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p-bt/
13:52 < smeghead> i2p-bt 0.1.7 is bt 3.4.2 based
13:52 <+polecat> Thanks.
13:52 <+polecat> Wait.
13:53 < cervantes> at which point we'll call it version 0.3.0 :P
13:53 <+polecat> I meant CVS, not the "ooh lookit the pretty website CVS"
13:53 < jrandom> cvs -d :pserver:anoncvs@cvs.i2p.net/cvsroot co i2p-bt
13:53 <+polecat> CVSROOT= is noticeably absent on those cvs-cgi thingies I've noticed.
13:53 < jrandom> or, if you have the CVS proxy locally, cvs -d :pserver:anoncvs@localhost/cvsroot co i2p-bt
13:54 < smeghead> polecat: convoluted? btdownloadgui.py is all the gui code, how can you get more cleanly separated than that?
13:54 * polecat whews, and doesn't feel a burning desire to bitch about CVS now.
13:54 < ant> <dm> ugh, that was painful, haven't written anything in french for years! http://forum.i2p.net/viewtopic.php?p=1238#1238
13:55 < jrandom> thanks dm
13:56 < ant> <dm> np
13:57 < smeghead> it probably says something obscene
13:58 < ant> <dm> hehehhe
13:58 <+polecat> Alright, so I have to write btdaemon.py, which is the gui - all gui stuff. And also btdaemongui.py, which is the gui - all daemon stuff.
13:58 < ant> <BS314159> if it's sufficiently obscene, it may serve our purposes just fine
13:58 < ant> <fedo2p> good job dm ;)
13:58 < jrandom> heh
13:58 < jrandom> r0x0r polecat
13:59 <+polecat> Sigh, I hate to emerge wxwindows though, it's a big library I don't normally use. Oh well.
13:59 < smeghead> polecat: 0.2.0 is gtk based, no more wxwidgets
13:59 < jrandom> ok, lots of bt work to do, perhaps we can discuss further on the list/forum/wiki/#i2p-bt as necessary?
13:59 <+polecat> If I'm gonna be hackin', I best get the toolz
14:00 <+polecat> Oh I forgot about that channel. :)
14:00 < smeghead> polecat: get bittorrent 3.9.1 beta and read the docs
14:01 < smeghead> #i2p-bt, right
14:01 < smeghead> there's even people there
14:02 < jrandom> heh ok, lots of exciting bt stuff. anything else for 3) i2p-bt, or shall we move on to 4) ???
14:03 < jrandom> ok, moving to 4) ???
14:03 < jrandom> anyone else have anything else to bring up for the meeting?
14:03 < ant> <jnymo> threshold crytography rules
14:04 < cervantes> ??? = http://forum.i2p/viewtopic.php?p=1237
14:04 < ant> <BS314159> proxies to the web are not cool. What about proxies to new versions of I2P, or other anonymnets?
14:04 < ant> <BS314159> and by not cool I mean not safe to run
14:04 < ant> <jnymo> they aren't run by everyone, BS
14:05 < ant> <BS314159> I know that
14:05 < cervantes> Forum member of the week is <tadaa!> jrandom
14:05 < ant> <BS314159> I'm thinking about upgrades
14:05 < jrandom> lol thanks cervantes
14:06 < ant> <BS314159> Not now, but eventually, would it be possible to have a large number of routers act as inter-version proxies?
14:06 < ant> <BS314159> and would that remove the timing attack without downtime?
14:06 < ant> <jnymo> forced upgrades are necessary
14:07 < ant> <BS314159> I disagree
14:07 < jrandom> BS314159: I2NP over i2ptunnel over I2P would be, painful. though perhaps one of the "outproxies" could point at some inproxy
14:07 < jrandom> BS314159: while forced upgrades aren't generally necessary, they are here. period. we need it, because I didn't forsee all of the changes we need for 0.5
14:08 < ant> <BS314159> I'm not saying new versions should be backwards-compatible
14:08 < cervantes> jrandom: well lets be honest...you're the one that does 98% of the work ;-)
14:09 < ant> <BS314159> I'm just trying to come up with a way to allow non-nimble I2P users to upgrade without timing attacks or downtime
14:10 < jrandom> BS314159: can't be done for the 0.5 release. later releases we can be careful. but for this one, its a drop dead cutoff.
14:10 < ant> <jnymo> automatic update may be better in the future
14:10 < ant> <BS314159> I'm speaking about the far future.
14:10 < ant> <jnymo> is auto-update too insecure?
14:10 < jrandom> cervantes: nah, only 95% of the infrastructure, but there's a lot more goin' on than just i2p/{core,router}/ :)
14:11 < jrandom> jnymo: 0 click update == insecure. 1 click == safe.
14:11 < cervantes> jrandom: yes it's begun to pickup over the last couple of months thankfully ;-)
14:11 < ant> <jnymo> and a line that says "you need to update.. countdown in * days"
14:12 < jrandom> aye, lots of people [http://www.i2p.net/team] have been doing kickass shit
14:13 < jrandom> BS314159: definitely lots we can do for later updates, perhaps we can discuss concrete impls as they approach :)
14:13 < jrandom> ok, anyone else have anything to bring up for the meeting?
14:13 < ant> <MANCOM> could we have some kind of autospeed feature (like with the azureus plugin that measures ping times) in i2p that adjusts the maximum (upload-)bandwidth?
14:14 < ant> <MANCOM> it would help keep bandwidth up and latency down
14:14 < jrandom> oh, interesting
14:14 * cervantes is working on a 1-2 click update feature for the i2p toolbar
14:14 < cervantes> although I'm having problems with hashing atm....so it's probably a few weeks away.
14:15 < ant> <jnymo> cervantes++
14:15 < jrandom> MANCOM: if you could doc up how it'd work and look, and post that on the forum, that'd be great. if its simple enough, might even make it into 0.5
14:15 < cervantes> in which time a dozen people will come up with a glut of better solutions
14:16 < jrandom> heh
14:16 < cneal92_> :D
14:17 < ant> <MANCOM> well, i'll try
14:17 < ant> <cervantes> but it already detects when there's a new release out, and can point you at the relevant download link...
14:17 < ant> <cervantes> which I may roll with initially
14:18 < jrandom> cool cervantes
14:18 < jrandom> thanks MANCOM
14:18 < ant> <jnymo> you could just put the "graceful restart" button to upgrade, after the update is already in the directory
14:19 < ant> <jnymo> or call it "upgrade"
14:19 < ant> <jnymo> and put the restart function in there
14:19 < ant> <jnymo> though i'm probably stating the obvious
14:19 < jrandom> right, we need perhaps a dozen lines of code to fetch http://dev.i2p/i2p/i2pupdate.zip, verify it, then restart
14:20 < jrandom> ok, anyone else have anything to bring up for the meeting?
14:20 < ant> <cervantes> well I can already get the toolbar to download an update into the i2p folder AND trigger a graceful restart...but so far I haven't been able to get it verify the download's integrity
14:21 < jrandom> cervantes: ah, that part should be easy - at a later date, we'll have the update itself be self-verifying
14:21 < jrandom> (aka signed, verified by the router before installation)
14:21 < ant> <cervantes> jrandom: that would be cool.
14:21 < ant> <jnymo> ooh
14:22 < ant> <cervantes> perhaps it will be enough then that I trigger the download and then pop a "do you wish to restart" yes/no requester
14:22 < ant> <cervantes> so someone can verify manually if desired
14:23 < ant> <cervantes> (it already displays what the sha1 _should_ be)
14:23 < jrandom> hehe
14:23 < ant> <jnymo> how bout, "click here to autodownload on availability"
14:25 < cervantes> I'd rather avoid auto downloads
14:25 < ant> <jnymo> hmf.. microsoft does it ;)
14:26 < cervantes> but by all means alert the user that a download exists and offer a "download now" button
14:26 < jrandom> right, 1 click at the least. we can automatically /notify/ on update availability, but autoinstall is not ok
14:26 < jrandom> (er, what cervantes said)
14:27 < ant> <jnymo> now, how do 10000 people update? how bout integrating i2p-bt at one point?
14:27 < jrandom> yes, and flying ponies
14:28 < ant> <jnymo> good enough for me
14:29 < jrandom> ok cool... if there's nothing else...
14:29 <+postman> damn missed the meeting :/
14:29 * cervantes gets back to coding his vapourware
14:29 < jrandom> heh you're at the buzzer, in case there's something you want to bring up postman :)
14:30 <+postman> no thanks
14:30 <+polecat> Microsoft? =) I have gentoo doing it.
14:30 * jrandom winds up
14:30 <+postman> ooops
14:30 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/129.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, February 15, 2005
==================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,288 +1,282 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 130{% endblock %}
{% block content %}<h3>I2P dev meeting, February 22, 2005</h3>
<div class="irclog">
13:04 < jrandom> 0) hi</p>
13:04 < jrandom> 1) 0.5</p>
13:04 < jrandom> 2) Next steps</p>
13:04 < jrandom> 3) azneti2p</p>
13:04 < jrandom> 4) ???</p>
13:04 < jrandom> 0) hi</p>
13:04 * jrandom waves</p>
13:05 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-February/000595.html</p>
13:05 < jrandom> (yeah, only a minute or two before the meeting, so lets test your speed reading)</p>
13:05 <+detonate> i think i'll wait until it's a bit less buggy before i put boondock saints up, in that case</p>
13:06 < jrandom> why... thats... thats... thats a copyright violation!</p>
13:06 <+detonate> weird new additions to the azureus beta</p>
13:06 <+detonate> categories</p>
13:06 <+detonate> haha</p>
13:06 <+detonate> a dht tracker</p>
13:06 <+detonate> sweet</p>
13:07 < jrandom> aye, it looks v.cool, but lets hit items 1 and 2 before 3, 'eh? ;)</p>
13:07 <+detonate> hi</p>
13:07 <+detonate> indeed</p>
13:07 < jrandom> jumpin into 1) 0.5</p>
13:07 < jrandom> its, like, out, and stuff</p>
13:08 < cervantes> yay!</p>
13:08 < jrandom> there'll be a new rev later this evening with a bunch of updates (current CVS head is 0.5-5, with a -6 in testing on some routers)</p>
13:09 < jrandom> its gone pretty well, but we've hit a few funky bugs along the way. but c'est la vie</p>
13:09 < frosk> i can report that 0.5-5 behaves a _lot_ more friendly than -4 (which often gave me participating tunnel counts in the thousands)</p>
13:09 < bla> jrandom: Will the 0.5.0.1 version correct the problem of nor being able to find destinations?</p>
13:09 < jrandom> ah, well, thats really just a function of other people though, the -0 build actually does build hundreds of tunnels</p>
13:09 < bla> s/nor/not</p>
13:10 < jrandom> bla: yes, thats a bug in the netDb</p>
13:10 < bla> jrandom: Great!</p>
13:10 < jrandom> (in the leaseSet publishing, specifically)</p>
13:11 < jrandom> and yes, the 0.5.0.1 rev will get rid of that occational disapearing proxy bug </p>
13:12 < jrandom> there is still a funky memory leak I haven't tracked down affecting some users</p>
13:12 < bla> Then, in all, it seems that part from these bugs, the 0.5 net is doing very well. Yay!</p>
13:12 < jrandom> to my knowledge, its only really hitting two or three I2PTunnel instances though</p>
13:12 < Meomia> is it a sign of progress when you have gone from 0 to 130 participating tunnels since 0.5 ?</p>
13:13 < jrandom> w3wt</p>
13:13 < jrandom> Meomia: bah, I've had over 5000 tunnels ;)</p>
13:13 < jrandom> but dm actually has helped find a bug in the exploratory pool code, so we will be building tunnels more often on 'random' peers</p>
13:14 < jrandom> (yay)</p>
13:14 < Meomia> ok</p>
13:14 < bla> jrandom: Does that also mean that now, in contrast to 0.4, every peers can at one time become your inbound gateway?</p>
13:14 < jrandom> yes, for exploratory tunnels</p>
13:15 < jrandom> client tunnels will only use peers in the 'fast' tier</p>
13:15 < bla> bla: Ok. The fact that client tunnels use only the fast peers is good: otherwise, we get the anon issue we discussed before</p>
13:16 < jrandom> and performance would suck otherwise ;)</p>
13:17 < jrandom> actually, that brings us in to 2) Next steps</p>
13:18 < jrandom> the big thing left for the 0.5 series is a bunch of strategies for ordering and/or filtering the peers used in tunnels</p>
13:18 < godmode0> jrandom can use nntp w i2p ?</p>
13:18 < jrandom> godmode0: there are two NNTP servers on i2p, yes. see the forum</p>
13:19 < godmode0> jrandom ok i;m testing</p>
13:19 < godmode0> i can build my server too ?</p>
13:20 < jrandom> godmode0: we're in a meeting right now, but yes, you can run a server</p>
13:20 < godmode0> jrandom ok sorry</p>
13:20 < jrandom> np</p>
13:20 < jrandom> the posted strategies are basically aimed at improving anonymity, but there are a few other goals that we can balance in there</p>
13:21 < jrandom> perhaps we can find a way to integrate some of the AS paths into the selection, as bla suggested</p>
13:22 < jrandom> that can both improve (jurisdictional) anonymity, or if we try to stay within an AS (or two), that can improve performance</p>
13:22 < bla> jrandom: This basically is related to a paper by the Tor creators: http://theland.i2p/files/routing-zones.pdf</p>
13:22 < jrandom> aye</p>
13:23 < jrandom> there are a whole slew of different strategies people can use, and trying out new ones should be pretty easy</p>
13:24 < jrandom> we aren't going to spend months implementing everything we can think of, but merely provide the basics for what most people will need. anyone who wants to add new ones are very much encouraged to help plug 'em in</p>
13:25 < jrandom> anyway, once the basics are in place, we'll be moving on to focus on the UDP transport for 0.6</p>
13:26 < jrandom> thats about all I have for 2) next steps, anyone have any comments/questions/concerns?</p>
13:26 < bla> Who where the ppl that started looking into I2P, again?</p>
13:26 < bla> It seems we haven't heard much from them, lately.</p>
13:27 < bla> s/into I2P/into UDP/</p>
13:27 < bla> sorry</p>
13:27 < jrandom> ah, mule has been sick, thogh I think detonate is making progress</p>
13:28 < jrandom> detonate: any news?</p>
13:29 < jrandom> or perhaps not ;) </p>
13:30 < jrandom> ok, moving on to 3) azneti2p</p>
13:30 <+detonate> sorry</p>
13:30 <+detonate> i'm making progress</p>
13:30 <+detonate> i still need to finish the re-assembly side of things</p>
13:31 <+detonate> as far as splitting data into packets and sending it across in an orderly fashion, that works</p>
13:31 <+detonate> on to 3)</p>
13:31 < jrandom> wikked</p>
13:31 < godmode0> sorry step 2) i2p has any problem with attacks ?</p>
13:31 < bla> detonate: Cool! Can you keep all of us posted on the forum?</p>
13:32 <+detonate> bla: sure</p>
13:32 < tracker> About azneti2p, look here: http://sourceforge.net/forum/forum.php?thread_id=1233727&forum_id=377614 seems like downloading works, seeding not.</p>
13:32 < jrandom> godmode0: the different ordering strategies should let the user choose the impact of predecessor attacks</p>
13:33 < microsoft> whoever runs i2p.net should add more Enterprise Class Solutions buzzwords to the page.</p>
13:33 <+detonate> someone needs to make sure that new dht tracker isn't misbehaving as well, with respect to the azureus plugin</p>
13:33 < tracker> My local tests seem to prove this, I can download with azureus but not seed.</p>
13:34 < jrandom> hmm ok cool tracker, thanks - i know they updated a few things and pushed out b34 last night, but there may be more left to do, it seems</p>
13:34 < jrandom> detonate: good point</p>
13:35 < tracker> Good point detonate, I have DHT disabled as azureus dies after some hours whit 100% CPU usage when it's active.</p>
13:35 * jrandom would like to reiterate that the azneti2p plugin is still fairly early beta, and azureus' anonymity implications have not fully been audited</p>
13:36 < jrandom> while I'm sure they love having people test it out, those who need anonymity may want to be cautious </p>
13:36 < tracker> On the other hand, i2p-bt works really well. Except that it doesn't close the tunnels, but that's not too bad IMHO.</p>
13:37 < jrandom> oh, thats still happening with you tracker? i havent been able to reproduce that</p>
13:37 < jrandom> you're on the 0.1.7 rev, right?</p>
13:37 < tracker> Yes, I'm.</p>
13:38 < jrandom> ok cool, if it happens all the time for you I'd love to pick your brains after the meeting to help track down the cause</p>
13:39 < tracker> Maybe it's related to running it on XP instead of linux or unix. Closing the tunnel works with azureus, so I gues it is I2P-BT related.</p>
13:39 < jrandom> hmm right, i2p-bt uses SAM, while azureus uses the i2p SDK directly</p>
13:40 < tracker> Btw. I send you a bug-report on the forum. The timestamper is dies on the latest cvs-builds of I2P.</p>
13:40 < jrandom> ah cool, thanks, havent checked my PMs over there today</p>
13:41 < jrandom> on -5 or -4? or earlier?</p>
13:42 < jrandom> ah, -4. ok cool</p>
13:42 < jrandom> thanks, I'll get that fixed for 0.5.0.1</p>
13:42 < jrandom> ok, anyone have anything else for 3) azneti2p?</p>
13:43 < tracker> It's also happening on -5</p>
13:43 < jrandom> you have sntp server defined explicitly, right?</p>
13:44 < tracker> Yes. The 2 ones from our country.</p>
13:44 < jrandom> i just checked the source and the exception occurs if the # concurring servers (default = 3) is greater than the # of servers specified (new default has 3)</p>
13:44 < jrandom> ok cool, its a trivial fix to % # servers</p>
13:45 < jrandom> ok, if there's nothing else for azneti2p, moving on to good ol' fashioned 4) ???</p>
13:46 < jrandom> anyone else have something to bring up for the meeting?</p>
13:46 < tracker> Nice. I've just send you the log errors from the router when closing i2p-bt on the forum.</p>
13:47 < jrandom> 'k cool, thanks</p>
13:47 < cervantes> nothing to mention other than: nice work with the 0.5 rollout, looks like it'll kick ass once the bugs are ironed out</p>
13:48 < tracker> Yep, the latest CVS builds are really performin good over here.</p>
13:48 < jrandom> thanks, with your help as well as the rest of the 0.5-pre testers we were able to clean up a bunch of issues</p>
13:49 < jrandom> the performance has been better than i had expected, though still not as high throughput as before. lots left to optimize though</p>
13:49 < cervantes> strangely the pre version were more stable...for me, but then, I was running them on a different machine ;-)</p>
13:49 < jrandom> (and these damn bugs to get reliability where it should be)</p>
13:50 < jrandom> heh well, yeah, but the -pre network was 5-7 routers, all insanely reliable on really really fast connections</p>
13:50 < cervantes> :)</p>
13:51 < cervantes> sign me up for the 0.6 pre test then :)</p>
13:51 < jrandom> heh</p>
13:51 < tracker> Maybe I should take part in the next pre network then. Providing a very unreliable and slow connection ;).</p>
13:51 < jrandom> the 0.6 migration will probably be even easier, I hope, as we'll just be able to add new router addresses to the routerInfo (UDP addresses)</p>
13:51 < jrandom> heh word</p>
13:51 < cervantes> I can put my 1TB file share online...</p>
13:52 < jrandom> we'll definitely need lots of help with the 0.6 testing, pulling in a whole variety of network setups</p>
13:52 < hobbs> ssh '~C' command is nifty</p>
13:52 < laberhorst> will this e another non comnpatible step?</p>
13:53 < Myo9> Anyone knows what nntp servers are up?</p>
13:53 < jrandom> laberhorst: no, 0.6 will be backwards compatible</p>
13:53 < jrandom> Myo9: dunno, they might be up and just be bitten by the 0.5-0 bugs</p>
13:54 < jrandom> the 0.5.0.1 rev should fix a lot of issues, and once its out, upgrading will be highly recommended</p>
13:54 < laberhorst> so just built a test 0.6 and put it to testers</p>
13:54 < cervantes> we can make BT traffic use only outdated routers...that will encourage people to upgrade ;-)</p>
13:54 < laberhorst> so big upgrade party tomorrow</p>
13:54 < jrandom> there'll be an announcement on the forum and the list when its ready</p>
13:54 < jrandom> right laberhorst </p>
13:54 < jrandom> heh cervantes ;)</p>
13:55 < laberhorst> *being keen on testing for you*</p>
13:55 < jrandom> BT performance has been pretty good on 0.5, I've seen lots of successful large file transfers on the trackers</p>
13:55 < laberhorst> pload rate: 8.85 kB/s</p>
13:55 < jrandom> (and irc hasn't been affected as it was before, beyond the problems we've been having with duck's tunnel)</p>
13:55 < tracker> Depends on what you call large ;)</p>
13:56 < jrandom> tracker: i'm thinking of a particular 874MB file that has a bunch of successful downloads ;)</p>
13:56 < jrandom> but its true, thats small to some </p>
13:56 < laberhorst> just good old porn</p>
13:56 < laberhorst> i assume ;-)</p>
13:57 < laberhorst> lets hope from tomorrow on, my router won't participate in &gt;3000 tunnels</p>
13:57 < tracker> Ok, that's large.</p>
13:57 < laberhorst> or, if so, the network IS large</p>
13:57 < jrandom> heh laberhorst </p>
13:58 < jrandom> ok, anyone have anything else for the meeting?</p>
13:58 < laberhorst> btw, if participate in &gt;3000 a synonym for a good reliable router in i2p with fast connection?</p>
13:58 <+detonate> i'm putting boondock saints up after i grab house tonight :)</p>
13:59 <+detonate> that'll be a good 4.1gb :)</p>
13:59 * laberhorst just wants to thank the developers for fast bug squashing</p>
13:59 <+detonate> there seems to be lots of demand</p>
13:59 < laberhorst> oh, some DVD images are here, to</p>
13:59 < hobbs> detonate: ooh, right. House. :)</p>
13:59 < tracker> cervantes, did you already upgrade to phpBB 2.0.12</p>
13:59 < laberhorst> but wait till 0.5.0.1 is out</p>
13:59 <+detonate> should give 0.5.0.1 a good shakedown too</p>
14:00 <+detonate> yeah</p>
14:00 <+detonate> i intend to</p>
14:00 < jrandom> only people who already own legal copies of those files should download them, of course. thats just for testing</p>
14:00 < jrandom> *cough*</p>
14:00 < tracker> rofl</p>
14:01 * jrandom notes mpaa.i2p</p>
14:01 <+detonate> heh</p>
14:01 < laberhorst> oh, i can built iso images from debian, fedora, suse, pictures I made,...</p>
14:01 < laberhorst> so a lot of legal material</p>
14:01 < laberhorst> if you just want to test, /dev/random is VERY large</p>
14:01 < Ragnarok> not always</p>
14:02 < laberhorst> btw, for lonely weekends: cat /dev/random | grep linux :-)</p>
14:02 < jrandom> heh</p>
14:02 < frosk> /dev/random runs empty all the time, i prefer /dev/urandom :)</p>
14:02 < frosk> or the new, improved /dev/jrandom</p>
14:02 < jrandom> nah, that dumps core all the time</p>
14:03 < jrandom> and needs its nightly rest</p>
14:03 < Ragnarok> what's the best way to generate entropy for /dev/random?</p>
14:03 < laberhorst> we should really built the "get jrandom a few beers" fund</p>
14:03 < frosk> call it rest or entropy gathering :)</p>
14:03 < hobbs> Ragnarok: Depends on what you really mean. Getting a hardware RNG would be more or less the "best" way :)</p>
14:03 < jrandom> Ragnarok: depends on your OS (and whether you have hardware ;)</p>
14:04 < tracker> dd if=/dev/urandom of=/dev/hda bs=1M count=4 Allways nice ;)</p>
14:04 < jrandom> we'll actually be bundling in a fortuna implementation one of these builds, and will need to dig around for various entropy sources</p>
14:04 < Ragnarok> without hardware :P</p>
14:04 < susi23> . o O ( I thought somebody using i2p knows why he should not use /dev/urandom )</p>
14:05 < cervantes> tracker: the security exploits covered in 2.0.12 my mod_rocinante inadvertantly fixes, so I haven't bothered to upgrade yet</p>
14:05 < hobbs> susi23: when it's just for mischief, I think it's alright ;)</p>
14:05 < ant> &lt;Nolar&gt; who here does the python BT port?</p>
14:05 < jrandom> Nolar: that'd be duck</p>
14:06 * duck whistles</p>
14:06 < ant> &lt;Nolar&gt; duck: why did you guys change the request block size to 128k ?</p>
14:06 < susi23> . o O ( next one suggests: while true; do echo $RANDOM &gt;&gt; largefile; done )</p>
14:06 < ant> &lt;Nolar&gt; that's why az cant seed to you</p>
14:06 < tracker> cervantes: Ok</p>
14:06 < ant> &lt;Nolar&gt; we block requests &gt; 64k</p>
14:06 < laberhorst> hell, i need more mp3</p>
14:06 < frosk> susi23: for grepping for linux on an idle evening, /dev/urandom is just fine :)</p>
14:07 < jrandom> ah, did you always? iirc i2p-bt has used 128k for a while</p>
14:08 < ant> &lt;Nolar&gt; yup, been there since the beginning :)</p>
14:08 < ant> &lt;Nolar&gt; any reason 128 is used?</p>
14:08 < ant> * duck looks through cvs log</p>
14:08 < jrandom> keeps the pipeline filled, i2p has some lag ;)</p>
14:08 < jrandom> with 32KB, thats essentially a fixed window size of 1</p>
14:09 < jrandom> so each message blocks for an ACK, while 128KB allows 4 messages to fly in the rtt</p>
14:09 <@duck> right, maximum allowed slice size according to the BT specs</p>
14:09 < ant> &lt;Nolar&gt; well, there are two ways do deal with this: 1) we raise the limit to 128k on our side, or 2) you simply pipeline more requests</p>
14:09 < cervantes> i2pbt is a little snappier than it used to be...perhaps you can afford to reduce it...</p>
14:10 <@duck> schni, schna, schnappi</p>
14:10 < ant> &lt;Nolar&gt; so, instread of making a single 128k request, send out two 64k ones for example</p>
14:10 < hobbs> duck: haha... that thing has gotten around the world.</p>
14:10 <@duck> why do you block 128k?</p>
14:11 < cervantes> *shudder* europop</p>
14:11 < laberhorst> duck: pls. be quiet OR i shoot you down!</p>
14:11 < tracker> Sometimes I regret that I learned german some years ago...</p>
14:11 < laberhorst> no europop, really not POP</p>
14:11 * cervantes orders the UK to repel borders before a song like that enters the charts</p>
14:11 < laberhorst> tracker: don't care, its ok</p>
14:12 < ant> &lt;duck&gt; its now (2^17)-13</p>
14:12 < ant> &lt;Nolar&gt; duck: well, the limit has been there for a while, but one good reason is that 128K blocks take a while to upload.....16KB (our default) allows for finer request control</p>
14:12 < ant> &lt;duck&gt; 13 bytes being the bittorrent command length</p>
14:12 < ant> &lt;duck&gt; would have no problem to (2^16)-13</p>
14:12 < laberhorst> some music is really ridiculous, but real industrial music, boh, no</p>
14:13 < ant> &lt;duck&gt; or go back to the default?</p>
14:13 < jrandom> reducing it to 64KB seems the simplest (is that a cli param atm?)</p>
14:13 < ant> &lt;duck&gt; --download_slice_size</p>
14:14 < ant> &lt;Nolar&gt; well, my question is, do you have a compelling reason for sticking to 128K blocks, which seems a bit large to me, especially for i2p</p>
14:14 < ant> &lt;Nolar&gt; rather than just pipelining multiplpe smaller requests?</p>
14:14 < ant> &lt;duck&gt; I have no reason.</p>
14:14 < tracker> laberhorst: Sometimes I catch some of the german channels via satellite. Especially viva and that "Theater Kanal" are really gruesome...</p>
14:15 < ant> &lt;Nolar&gt; one problem with large blocks is that once i choke you, i still have to finish sending that 128k chunk</p>
14:15 < jrandom> I don't recall whether the vanilla bt knows how to pipeline, but it should be simple enough (especially since i'm not doing it ;)</p>
14:15 < ant> &lt;Nolar&gt; which can take a while</p>
14:15 < laberhorst> tracker: viva is only interesting while "hard rock" time, all other times "please ignore", and theater, i don't know</p>
14:15 < jrandom> with i2p, 128KB isn't really that large, since there's an inherent lag on the order of seconds</p>
14:15 < ant> &lt;Nolar&gt; which can mess with the chunk/unchoke </p>
14:16 <@duck> jrandom: does it still make sense to subtract the bittorrent 13 byte overhead so it fits in a sam message?</p>
14:16 < jrandom> duck: nah, since the streaming lib already reduces it further into 16KB messages, so just have it be 64KB</p>
14:17 <@duck> ok, 2**16 it is</p>
14:17 < jrandom> (and then the tunnels break those 16KB messages into 996 byte fragments..)</p>
14:17 < ant> &lt;Nolar&gt; the problem with 128k, is that if i'm uploading at say 12 k/s, then it'll take me 10+ seconds to finish that block</p>
14:18 < cervantes> wow that's almost as long as the lag on irc...</p>
14:18 < jrandom> which is 1-10 RTTs (while on the normal net, 10-500)</p>
14:18 <+detonate> i was all set to use 512K blocks</p>
14:18 < ant> &lt;Nolar&gt; you might also experiment with pipelinng 16kb blocks</p>
14:18 < jrandom> heh</p>
14:18 <+detonate> so 64 is preferred?</p>
14:19 < ant> &lt;Nolar&gt; all bt clients afiak use 16KB blocks</p>
14:19 < ant> &lt;duck&gt; fixed in CVS;</p>
14:19 < jrandom> wikked, thanks duck! (and Nolar!)</p>
14:19 < ant> &lt;duck&gt; expect it to appear in the 0.1.8 release together with some sam i2cp tuning</p>
14:19 < tracker> laberhorst: It's complete name is "ZDF Theater" or so. And well they say they send a high level cultural program. I really hope that what they send isn't the best the german culture can offer ;)</p>
14:19 < jrandom> ok, heh, I just remembered we're still in a meeting</p>
14:19 < jrandom> anyone else have anything for the meeting?</p>
14:20 < ant> &lt;Nolar&gt; so if we want a 128k chunk, we just make 8 simult requests</p>
14:20 < susi23> . o O ( and discard the 448 left bytes? )</p>
14:20 < jrandom> right right</p>
14:20 < laberhorst> tracker: oh, that is small side channel... arte or 3sat is really more interesting</p>
14:20 < laberhorst> and arte is german/french :-)</p>
14:20 < ant> &lt;Nolar&gt; if the uploader can fill such a request, all 128k should be pushed into the i2p pipe stream</p>
14:20 < jrandom> cool</p>
14:21 < cervantes> . o O ( wonders why he can hear everything susi is thinking )</p>
14:21 < ant> &lt;Nolar&gt; so, it might be worth experimenting with 16KB vs 32KB vs 64KB blocks sizes</p>
14:21 < jrandom> aye</p>
14:21 < jrandom> as long as its pipelined, i2p doesnt care</p>
14:21 < ant> &lt;Nolar&gt; great</p>
14:22 < jrandom> the speed at 16KB without pipelines is pretty bad though, or at least it used to be</p>
14:22 < tracker> laberhorst: Ok, I'll try if I can catch arte in the next days...</p>
14:22 < ant> &lt;duck&gt; I suggest leaving this tweaking for 0.2</p>
14:22 < ant> &lt;duck&gt; since it will include the bittorrent 3.9.1 improvements</p>
14:22 < jrandom> yeah, DTSTTCPW</p>
14:22 < susi23> . o O ( oh thats easy... people are so predictable... )</p>
14:23 < ant> &lt;duck&gt; which might completely restructure the network code</p>
14:23 < cervantes> http://www.gavelstore.com</p>
14:24 < jrandom> ok, I think thats it for the moment, people should check the list and the site in a few hours as the 0.5.0.1 rev will be coming out soon</p>
14:24 < ant> &lt;Nolar&gt; ya, i can see how single 16kb requests would be slow</p>
14:24 * jrandom downloads a gavel</p>
14:24 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:04 < jrandom> 0) hi
13:04 < jrandom> 1) 0.5
13:04 < jrandom> 2) Next steps
13:04 < jrandom> 3) azneti2p
13:04 < jrandom> 4) ???
13:04 < jrandom> 0) hi
13:04 * jrandom waves
13:05 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-February/000595.html
13:05 < jrandom> (yeah, only a minute or two before the meeting, so lets test your speed reading)
13:05 <+detonate> i think i'll wait until it's a bit less buggy before i put boondock saints up, in that case
13:06 < jrandom> why... thats... thats... thats a copyright violation!
13:06 <+detonate> weird new additions to the azureus beta
13:06 <+detonate> categories
13:06 <+detonate> haha
13:06 <+detonate> a dht tracker
13:06 <+detonate> sweet
13:07 < jrandom> aye, it looks v.cool, but lets hit items 1 and 2 before 3, 'eh? ;)
13:07 <+detonate> hi
13:07 <+detonate> indeed
13:07 < jrandom> jumpin into 1) 0.5
13:07 < jrandom> its, like, out, and stuff
13:08 < cervantes> yay!
13:08 < jrandom> there'll be a new rev later this evening with a bunch of updates (current CVS head is 0.5-5, with a -6 in testing on some routers)
13:09 < jrandom> its gone pretty well, but we've hit a few funky bugs along the way. but c'est la vie
13:09 < frosk> i can report that 0.5-5 behaves a _lot_ more friendly than -4 (which often gave me participating tunnel counts in the thousands)
13:09 < bla> jrandom: Will the 0.5.0.1 version correct the problem of nor being able to find destinations?
13:09 < jrandom> ah, well, thats really just a function of other people though, the -0 build actually does build hundreds of tunnels
13:09 < bla> s/nor/not
13:10 < jrandom> bla: yes, thats a bug in the netDb
13:10 < bla> jrandom: Great!
13:10 < jrandom> (in the leaseSet publishing, specifically)
13:11 < jrandom> and yes, the 0.5.0.1 rev will get rid of that occational disapearing proxy bug
13:12 < jrandom> there is still a funky memory leak I haven't tracked down affecting some users
13:12 < bla> Then, in all, it seems that part from these bugs, the 0.5 net is doing very well. Yay!
13:12 < jrandom> to my knowledge, its only really hitting two or three I2PTunnel instances though
13:12 < Meomia> is it a sign of progress when you have gone from 0 to 130 participating tunnels since 0.5 ?
13:13 < jrandom> w3wt
13:13 < jrandom> Meomia: bah, I've had over 5000 tunnels ;)
13:13 < jrandom> but dm actually has helped find a bug in the exploratory pool code, so we will be building tunnels more often on 'random' peers
13:14 < jrandom> (yay)
13:14 < Meomia> ok
13:14 < bla> jrandom: Does that also mean that now, in contrast to 0.4, every peers can at one time become your inbound gateway?
13:14 < jrandom> yes, for exploratory tunnels
13:15 < jrandom> client tunnels will only use peers in the 'fast' tier
13:15 < bla> bla: Ok. The fact that client tunnels use only the fast peers is good: otherwise, we get the anon issue we discussed before
13:16 < jrandom> and performance would suck otherwise ;)
13:17 < jrandom> actually, that brings us in to 2) Next steps
13:18 < jrandom> the big thing left for the 0.5 series is a bunch of strategies for ordering and/or filtering the peers used in tunnels
13:18 < godmode0> jrandom can use nntp w i2p ?
13:18 < jrandom> godmode0: there are two NNTP servers on i2p, yes. see the forum
13:19 < godmode0> jrandom ok i;m testing
13:19 < godmode0> i can build my server too ?
13:20 < jrandom> godmode0: we're in a meeting right now, but yes, you can run a server
13:20 < godmode0> jrandom ok sorry
13:20 < jrandom> np
13:20 < jrandom> the posted strategies are basically aimed at improving anonymity, but there are a few other goals that we can balance in there
13:21 < jrandom> perhaps we can find a way to integrate some of the AS paths into the selection, as bla suggested
13:22 < jrandom> that can both improve (jurisdictional) anonymity, or if we try to stay within an AS (or two), that can improve performance
13:22 < bla> jrandom: This basically is related to a paper by the Tor creators: http://theland.i2p/files/routing-zones.pdf
13:22 < jrandom> aye
13:23 < jrandom> there are a whole slew of different strategies people can use, and trying out new ones should be pretty easy
13:24 < jrandom> we aren't going to spend months implementing everything we can think of, but merely provide the basics for what most people will need. anyone who wants to add new ones are very much encouraged to help plug 'em in
13:25 < jrandom> anyway, once the basics are in place, we'll be moving on to focus on the UDP transport for 0.6
13:26 < jrandom> thats about all I have for 2) next steps, anyone have any comments/questions/concerns?
13:26 < bla> Who where the ppl that started looking into I2P, again?
13:26 < bla> It seems we haven't heard much from them, lately.
13:27 < bla> s/into I2P/into UDP/
13:27 < bla> sorry
13:27 < jrandom> ah, mule has been sick, thogh I think detonate is making progress
13:28 < jrandom> detonate: any news?
13:29 < jrandom> or perhaps not ;)
13:30 < jrandom> ok, moving on to 3) azneti2p
13:30 <+detonate> sorry
13:30 <+detonate> i'm making progress
13:30 <+detonate> i still need to finish the re-assembly side of things
13:31 <+detonate> as far as splitting data into packets and sending it across in an orderly fashion, that works
13:31 <+detonate> on to 3)
13:31 < jrandom> wikked
13:31 < godmode0> sorry step 2) i2p has any problem with attacks ?
13:31 < bla> detonate: Cool! Can you keep all of us posted on the forum?
13:32 <+detonate> bla: sure
13:32 < tracker> About azneti2p, look here: http://sourceforge.net/forum/forum.php?thread_id=1233727&forum_id=377614 seems like downloading works, seeding not.
13:32 < jrandom> godmode0: the different ordering strategies should let the user choose the impact of predecessor attacks
13:33 < microsoft> whoever runs i2p.net should add more Enterprise Class Solutions buzzwords to the page.
13:33 <+detonate> someone needs to make sure that new dht tracker isn't misbehaving as well, with respect to the azureus plugin
13:33 < tracker> My local tests seem to prove this, I can download with azureus but not seed.
13:34 < jrandom> hmm ok cool tracker, thanks - i know they updated a few things and pushed out b34 last night, but there may be more left to do, it seems
13:34 < jrandom> detonate: good point
13:35 < tracker> Good point detonate, I have DHT disabled as azureus dies after some hours whit 100% CPU usage when it's active.
13:35 * jrandom would like to reiterate that the azneti2p plugin is still fairly early beta, and azureus' anonymity implications have not fully been audited
13:36 < jrandom> while I'm sure they love having people test it out, those who need anonymity may want to be cautious
13:36 < tracker> On the other hand, i2p-bt works really well. Except that it doesn't close the tunnels, but that's not too bad IMHO.
13:37 < jrandom> oh, thats still happening with you tracker? i havent been able to reproduce that
13:37 < jrandom> you're on the 0.1.7 rev, right?
13:37 < tracker> Yes, I'm.
13:38 < jrandom> ok cool, if it happens all the time for you I'd love to pick your brains after the meeting to help track down the cause
13:39 < tracker> Maybe it's related to running it on XP instead of linux or unix. Closing the tunnel works with azureus, so I gues it is I2P-BT related.
13:39 < jrandom> hmm right, i2p-bt uses SAM, while azureus uses the i2p SDK directly
13:40 < tracker> Btw. I send you a bug-report on the forum. The timestamper is dies on the latest cvs-builds of I2P.
13:40 < jrandom> ah cool, thanks, havent checked my PMs over there today
13:41 < jrandom> on -5 or -4? or earlier?
13:42 < jrandom> ah, -4. ok cool
13:42 < jrandom> thanks, I'll get that fixed for 0.5.0.1
13:42 < jrandom> ok, anyone have anything else for 3) azneti2p?
13:43 < tracker> It's also happening on -5
13:43 < jrandom> you have sntp server defined explicitly, right?
13:44 < tracker> Yes. The 2 ones from our country.
13:44 < jrandom> i just checked the source and the exception occurs if the # concurring servers (default = 3) is greater than the # of servers specified (new default has 3)
13:44 < jrandom> ok cool, its a trivial fix to % # servers
13:45 < jrandom> ok, if there's nothing else for azneti2p, moving on to good ol' fashioned 4) ???
13:46 < jrandom> anyone else have something to bring up for the meeting?
13:46 < tracker> Nice. I've just send you the log errors from the router when closing i2p-bt on the forum.
13:47 < jrandom> 'k cool, thanks
13:47 < cervantes> nothing to mention other than: nice work with the 0.5 rollout, looks like it'll kick ass once the bugs are ironed out
13:48 < tracker> Yep, the latest CVS builds are really performin good over here.
13:48 < jrandom> thanks, with your help as well as the rest of the 0.5-pre testers we were able to clean up a bunch of issues
13:49 < jrandom> the performance has been better than i had expected, though still not as high throughput as before. lots left to optimize though
13:49 < cervantes> strangely the pre version were more stable...for me, but then, I was running them on a different machine ;-)
13:49 < jrandom> (and these damn bugs to get reliability where it should be)
13:50 < jrandom> heh well, yeah, but the -pre network was 5-7 routers, all insanely reliable on really really fast connections
13:50 < cervantes> :)
13:51 < cervantes> sign me up for the 0.6 pre test then :)
13:51 < jrandom> heh
13:51 < tracker> Maybe I should take part in the next pre network then. Providing a very unreliable and slow connection ;).
13:51 < jrandom> the 0.6 migration will probably be even easier, I hope, as we'll just be able to add new router addresses to the routerInfo (UDP addresses)
13:51 < jrandom> heh word
13:51 < cervantes> I can put my 1TB file share online...
13:52 < jrandom> we'll definitely need lots of help with the 0.6 testing, pulling in a whole variety of network setups
13:52 < hobbs> ssh '~C' command is nifty
13:52 < laberhorst> will this e another non comnpatible step?
13:53 < Myo9> Anyone knows what nntp servers are up?
13:53 < jrandom> laberhorst: no, 0.6 will be backwards compatible
13:53 < jrandom> Myo9: dunno, they might be up and just be bitten by the 0.5-0 bugs
13:54 < jrandom> the 0.5.0.1 rev should fix a lot of issues, and once its out, upgrading will be highly recommended
13:54 < laberhorst> so just built a test 0.6 and put it to testers
13:54 < cervantes> we can make BT traffic use only outdated routers...that will encourage people to upgrade ;-)
13:54 < laberhorst> so big upgrade party tomorrow
13:54 < jrandom> there'll be an announcement on the forum and the list when its ready
13:54 < jrandom> right laberhorst
13:54 < jrandom> heh cervantes ;)
13:55 < laberhorst> *being keen on testing for you*
13:55 < jrandom> BT performance has been pretty good on 0.5, I've seen lots of successful large file transfers on the trackers
13:55 < laberhorst> pload rate: 8.85 kB/s
13:55 < jrandom> (and irc hasn't been affected as it was before, beyond the problems we've been having with duck's tunnel)
13:55 < tracker> Depends on what you call large ;)
13:56 < jrandom> tracker: i'm thinking of a particular 874MB file that has a bunch of successful downloads ;)
13:56 < jrandom> but its true, thats small to some
13:56 < laberhorst> just good old porn
13:56 < laberhorst> i assume ;-)
13:57 < laberhorst> lets hope from tomorrow on, my router won't participate in >3000 tunnels
13:57 < tracker> Ok, that's large.
13:57 < laberhorst> or, if so, the network IS large
13:57 < jrandom> heh laberhorst
13:58 < jrandom> ok, anyone have anything else for the meeting?
13:58 < laberhorst> btw, if participate in >3000 a synonym for a good reliable router in i2p with fast connection?
13:58 <+detonate> i'm putting boondock saints up after i grab house tonight :)
13:59 <+detonate> that'll be a good 4.1gb :)
13:59 * laberhorst just wants to thank the developers for fast bug squashing
13:59 <+detonate> there seems to be lots of demand
13:59 < laberhorst> oh, some DVD images are here, to
13:59 < hobbs> detonate: ooh, right. House. :)
13:59 < tracker> cervantes, did you already upgrade to phpBB 2.0.12
13:59 < laberhorst> but wait till 0.5.0.1 is out
13:59 <+detonate> should give 0.5.0.1 a good shakedown too
14:00 <+detonate> yeah
14:00 <+detonate> i intend to
14:00 < jrandom> only people who already own legal copies of those files should download them, of course. thats just for testing
14:00 < jrandom> *cough*
14:00 < tracker> rofl
14:01 * jrandom notes mpaa.i2p
14:01 <+detonate> heh
14:01 < laberhorst> oh, i can built iso images from debian, fedora, suse, pictures I made,...
14:01 < laberhorst> so a lot of legal material
14:01 < laberhorst> if you just want to test, /dev/random is VERY large
14:01 < Ragnarok> not always
14:02 < laberhorst> btw, for lonely weekends: cat /dev/random | grep linux :-)
14:02 < jrandom> heh
14:02 < frosk> /dev/random runs empty all the time, i prefer /dev/urandom :)
14:02 < frosk> or the new, improved /dev/jrandom
14:02 < jrandom> nah, that dumps core all the time
14:03 < jrandom> and needs its nightly rest
14:03 < Ragnarok> what's the best way to generate entropy for /dev/random?
14:03 < laberhorst> we should really built the "get jrandom a few beers" fund
14:03 < frosk> call it rest or entropy gathering :)
14:03 < hobbs> Ragnarok: Depends on what you really mean. Getting a hardware RNG would be more or less the "best" way :)
14:03 < jrandom> Ragnarok: depends on your OS (and whether you have hardware ;)
14:04 < tracker> dd if=/dev/urandom of=/dev/hda bs=1M count=4 Allways nice ;)
14:04 < jrandom> we'll actually be bundling in a fortuna implementation one of these builds, and will need to dig around for various entropy sources
14:04 < Ragnarok> without hardware :P
14:04 < susi23> . o O ( I thought somebody using i2p knows why he should not use /dev/urandom )
14:05 < cervantes> tracker: the security exploits covered in 2.0.12 my mod_rocinante inadvertantly fixes, so I haven't bothered to upgrade yet
14:05 < hobbs> susi23: when it's just for mischief, I think it's alright ;)
14:05 < ant> <Nolar> who here does the python BT port?
14:05 < jrandom> Nolar: that'd be duck
14:06 * duck whistles
14:06 < ant> <Nolar> duck: why did you guys change the request block size to 128k ?
14:06 < susi23> . o O ( next one suggests: while true; do echo $RANDOM >> largefile; done )
14:06 < ant> <Nolar> that's why az cant seed to you
14:06 < tracker> cervantes: Ok
14:06 < ant> <Nolar> we block requests > 64k
14:06 < laberhorst> hell, i need more mp3
14:06 < frosk> susi23: for grepping for linux on an idle evening, /dev/urandom is just fine :)
14:07 < jrandom> ah, did you always? iirc i2p-bt has used 128k for a while
14:08 < ant> <Nolar> yup, been there since the beginning :)
14:08 < ant> <Nolar> any reason 128 is used?
14:08 < ant> * duck looks through cvs log
14:08 < jrandom> keeps the pipeline filled, i2p has some lag ;)
14:08 < jrandom> with 32KB, thats essentially a fixed window size of 1
14:09 < jrandom> so each message blocks for an ACK, while 128KB allows 4 messages to fly in the rtt
14:09 <@duck> right, maximum allowed slice size according to the BT specs
14:09 < ant> <Nolar> well, there are two ways do deal with this: 1) we raise the limit to 128k on our side, or 2) you simply pipeline more requests
14:09 < cervantes> i2pbt is a little snappier than it used to be...perhaps you can afford to reduce it...
14:10 <@duck> schni, schna, schnappi
14:10 < ant> <Nolar> so, instread of making a single 128k request, send out two 64k ones for example
14:10 < hobbs> duck: haha... that thing has gotten around the world.
14:10 <@duck> why do you block 128k?
14:11 < cervantes> *shudder* europop
14:11 < laberhorst> duck: pls. be quiet OR i shoot you down!
14:11 < tracker> Sometimes I regret that I learned german some years ago...
14:11 < laberhorst> no europop, really not POP
14:11 * cervantes orders the UK to repel borders before a song like that enters the charts
14:11 < laberhorst> tracker: don't care, its ok
14:12 < ant> <duck> its now (2^17)-13
14:12 < ant> <Nolar> duck: well, the limit has been there for a while, but one good reason is that 128K blocks take a while to upload.....16KB (our default) allows for finer request control
14:12 < ant> <duck> 13 bytes being the bittorrent command length
14:12 < ant> <duck> would have no problem to (2^16)-13
14:12 < laberhorst> some music is really ridiculous, but real industrial music, boh, no
14:13 < ant> <duck> or go back to the default?
14:13 < jrandom> reducing it to 64KB seems the simplest (is that a cli param atm?)
14:13 < ant> <duck> --download_slice_size
14:14 < ant> <Nolar> well, my question is, do you have a compelling reason for sticking to 128K blocks, which seems a bit large to me, especially for i2p
14:14 < ant> <Nolar> rather than just pipelining multiplpe smaller requests?
14:14 < ant> <duck> I have no reason.
14:14 < tracker> laberhorst: Sometimes I catch some of the german channels via satellite. Especially viva and that "Theater Kanal" are really gruesome...
14:15 < ant> <Nolar> one problem with large blocks is that once i choke you, i still have to finish sending that 128k chunk
14:15 < jrandom> I don't recall whether the vanilla bt knows how to pipeline, but it should be simple enough (especially since i'm not doing it ;)
14:15 < ant> <Nolar> which can take a while
14:15 < laberhorst> tracker: viva is only interesting while "hard rock" time, all other times "please ignore", and theater, i don't know
14:15 < jrandom> with i2p, 128KB isn't really that large, since there's an inherent lag on the order of seconds
14:15 < ant> <Nolar> which can mess with the chunk/unchoke
14:16 <@duck> jrandom: does it still make sense to subtract the bittorrent 13 byte overhead so it fits in a sam message?
14:16 < jrandom> duck: nah, since the streaming lib already reduces it further into 16KB messages, so just have it be 64KB
14:17 <@duck> ok, 2**16 it is
14:17 < jrandom> (and then the tunnels break those 16KB messages into 996 byte fragments..)
14:17 < ant> <Nolar> the problem with 128k, is that if i'm uploading at say 12 k/s, then it'll take me 10+ seconds to finish that block
14:18 < cervantes> wow that's almost as long as the lag on irc...
14:18 < jrandom> which is 1-10 RTTs (while on the normal net, 10-500)
14:18 <+detonate> i was all set to use 512K blocks
14:18 < ant> <Nolar> you might also experiment with pipelinng 16kb blocks
14:18 < jrandom> heh
14:18 <+detonate> so 64 is preferred?
14:19 < ant> <Nolar> all bt clients afiak use 16KB blocks
14:19 < ant> <duck> fixed in CVS;
14:19 < jrandom> wikked, thanks duck! (and Nolar!)
14:19 < ant> <duck> expect it to appear in the 0.1.8 release together with some sam i2cp tuning
14:19 < tracker> laberhorst: It's complete name is "ZDF Theater" or so. And well they say they send a high level cultural program. I really hope that what they send isn't the best the german culture can offer ;)
14:19 < jrandom> ok, heh, I just remembered we're still in a meeting
14:19 < jrandom> anyone else have anything for the meeting?
14:20 < ant> <Nolar> so if we want a 128k chunk, we just make 8 simult requests
14:20 < susi23> . o O ( and discard the 448 left bytes? )
14:20 < jrandom> right right
14:20 < laberhorst> tracker: oh, that is small side channel... arte or 3sat is really more interesting
14:20 < laberhorst> and arte is german/french :-)
14:20 < ant> <Nolar> if the uploader can fill such a request, all 128k should be pushed into the i2p pipe stream
14:20 < jrandom> cool
14:21 < cervantes> . o O ( wonders why he can hear everything susi is thinking )
14:21 < ant> <Nolar> so, it might be worth experimenting with 16KB vs 32KB vs 64KB blocks sizes
14:21 < jrandom> aye
14:21 < jrandom> as long as its pipelined, i2p doesnt care
14:21 < ant> <Nolar> great
14:22 < jrandom> the speed at 16KB without pipelines is pretty bad though, or at least it used to be
14:22 < tracker> laberhorst: Ok, I'll try if I can catch arte in the next days...
14:22 < ant> <duck> I suggest leaving this tweaking for 0.2
14:22 < ant> <duck> since it will include the bittorrent 3.9.1 improvements
14:22 < jrandom> yeah, DTSTTCPW
14:22 < susi23> . o O ( oh thats easy... people are so predictable... )
14:23 < ant> <duck> which might completely restructure the network code
14:23 < cervantes> http://www.gavelstore.com
14:24 < jrandom> ok, I think thats it for the moment, people should check the list and the site in a few hours as the 0.5.0.1 rev will be coming out soon
14:24 < ant> <Nolar> ya, i can see how single 16kb requests would be slow
14:24 * jrandom downloads a gavel
14:24 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/130.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, February 22, 2005
==================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,372 +1,366 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 131{% endblock %}
{% block content %}<h3>I2P dev meeting, March 1, 2005</h3>
<div class="irclog">
13:05 <@jrandom> 0) hi</p>
13:05 <@jrandom> 1) 0.5.0.1</p>
13:05 <@jrandom> 2) roadmap</p>
13:05 <@jrandom> 3) addressbook editor and config</p>
13:05 <@jrandom> 4) i2p-bt</p>
13:05 <@jrandom> 5) ???</p>
13:05 <@jrandom> 0) hi</p>
13:05 * jrandom waves</p>
13:05 <@duck> hi</p>
13:05 <@jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000616.html</p>
13:05 < null> hi</p>
13:05 <@jrandom> (yeah, i'm late this week, off with my head)</p>
13:06 <@jrandom> while y'all speedreaders dig through that, perhaps we can jump into 1) 0.5.0.1</p>
13:07 <@jrandom> 0.5.0.1 is out, and gets rid of the most ovious bugs from 0.5, but as we've seen, there's still work to be done</p>
13:07 <@jrandom> (current cvs stands at 0.5.0.1-7, I expect at least -8 or -9 before we hit 0.5.0.2)</p>
13:07 <+ugha2p> Hi.</p>
13:08 <+ugha2p> Does CVS HEAD fix that 100% CPU issue?</p>
13:08 <@jrandom> yes, -7 should get the last remnants of it</p>
13:08 <@duck> Does CVS HEAD fix that OOM issue?</p>
13:08 <+detonate> hi</p>
13:08 <@jrandom> no, the OOM is still being tracked down</p>
13:09 <@jrandom> actually... is there a Connelly in the house?</p>
13:09 < ant> &lt;jrandom&gt; nope</p>
13:09 <@jrandom> bugger</p>
13:09 <+ugha2p> jrandom must be going crazy, he is having a dialogue with himself.</p>
13:09 <@jrandom> ok, well, we can see what will be done to get rid of the OOM. its definitely a show stopper, so there won't be a release until its resolved one way or another</p>
13:10 <+detonate> just in time for the meeting</p>
13:11 <@jrandom> thats about all i have to say for the 0.5.0.1 stuff - anyone else have anything they want to mention/ask/discuss?</p>
13:12 <+ugha2p> jrandom: Err, I haven't actually seen the CPU issue with 0.5.0.1, but it happened twice when I tried 0.5.0.1-5. Am I missing something?</p>
13:12 <+ugha2p> I downgraded back to 0.5.0.1 as a result.</p>
13:13 <+detonate> i had a question, the shutdown seems to take a very long time, and the memory usage spikes by about 40mb during that time</p>
13:13 <+detonate> was wondering if you knew why</p>
13:14 <+detonate> the immediate one, obviously</p>
13:14 <@jrandom> it could happen with 0.5.0.1, you just hadn't run into it. </p>
13:14 <@jrandom> (its not a common occurrence, and it only hits some people in odd situations)</p>
13:14 <@jrandom> detonate: very long, as in, more than the usual 11-12 minutes?</p>
13:14 <+ugha2p> Well, it hit me twice during a 8-hour period.</p>
13:15 <+detonate> once all the participating tunnels are gone</p>
13:15 <+ugha2p> jrandom: Is it supposed to use up all the CPU and lose all the leases until restarted when that bug occurs?</p>
13:16 <@jrandom> ugha2p: thats a typical result from the bug, yes</p>
13:16 <+detonate> hmm</p>
13:17 <@jrandom> (it happens when the # of tunnel build requests consume sufficient CPU to exceed the time to satisfy a request, causing an additional request to be queued up, etc)</p>
13:17 <+ugha2p> Must have been an extreme coincidence that it only happened to me while on 0.5.0.1-5.</p>
13:18 <@jrandom> ugha2p: its happened to some people repeatably on 0.5.0.1-0, but is fixed in -7. you can stick with -0 if you prefer, of course</p>
13:18 < cervantes> it was a wonderous godsend</p>
13:18 <+ugha2p> jrandom: I'll try out -7.</p>
13:18 <@jrandom> cool</p>
13:19 <+ugha2p> Although I'm already feeling guilty for giving a bumpy ride to the wiki users so far. :)</p>
13:20 <+ugha2p> One more thing, have you documented the bulk/interactive tunnel types anywhere?</p>
13:20 <+ugha2p> (Except for the source ;)</p>
13:20 <@jrandom> in the changelog. the only difference is a max window size of 1 message</p>
13:20 <+ugha2p> Oh, okay.</p>
13:21 <@jrandom> ok, anything else on 0.5.0.1, or shall we move on over to 2) roadmap?</p>
13:21 <@duck> move on!</p>
13:21 <@jrandom> consider us moved</p>
13:22 <@jrandom> roadmap updated. 'n stuff. see the page for details</p>
13:22 < cervantes> eeh, duck ankle bites</p>
13:23 <@jrandom> i'm thinking of pushing some of the strategies from 0.5.1 to 0.6.1 (so we get UDP faster), but we'll see</p>
13:23 <@jrandom> anyone have any questions/comments/concerns/frisbees?</p>
13:23 <+detonate> have you heard from mule lately?</p>
13:23 <+detonate> speaking of udp</p>
13:24 <@jrandom> nope, he was fairly ill last i heard from 'im</p>
13:24 <+detonate> :/</p>
13:24 < jnymo> udp would kick ass</p>
13:25 <@jrandom> s/would/will/</p>
13:25 <@jrandom> hopefully he's off having fun instead though :)</p>
13:25 <+ugha2p> jrandom: What kind of changes would the bandwidth and performance tuning include?</p>
13:26 < jnymo> so, udp basically means connectionless.. which means.. bigger network, right</p>
13:26 <+detonate> udp introduces all sorts of difficulties along with that</p>
13:26 <@jrandom> ugha2p: batching the tunnel message fragments to fit better into the fixed 1024byte tunnel messages, adding per-pool bw throttles, etc</p>
13:27 <+detonate> but yeah</p>
13:27 <@jrandom> detonate: it won't be so bad, the token bucket scheme we have now can handle async requests without a problem</p>
13:27 <@jrandom> (we just obviously wouldn't use the BandwidthLimitedOutputStream, but would ask the FIFOBandwidthLimiter to allocate K bytes)</p>
13:27 <+ugha2p> Would the first one really make much difference? Per-pool throttling doesn't sound urgent.</p>
13:28 <+detonate> that's good then</p>
13:28 <@jrandom> ugha2p: likely, yes. you can see the exact #s involved by going to /oldstats.jsp#tunnel.smallFragments</p>
13:29 < bla> detonate: How's progress on the reassembly?</p>
13:29 <+detonate> really stalled</p>
13:30 <@jrandom> ugha2p: though its largely dependent upon the type of activity, of course. chatty comm has more to gain, but bulk comm already fills the fragments fully</p>
13:30 <+ugha2p> jrandom: Ok.</p>
13:30 <+ugha2p> Right.</p>
13:31 <+detonate> i stopped working on it completely and started working on the addressbook-editor</p>
13:31 <+detonate> there's probably a really efficient, well-researched way of doing that sort of thing, but i haven't come across it </p>
13:31 < jnymo> will upd mean people behind nats can get through now?</p>
13:31 <@jrandom> some jnymo </p>
13:31 < jnymo> and use i2p?</p>
13:32 <@jrandom> but first we need to get it to work with udp at all, then we start adding the firewall/nat punching, then the PMTU, etc</p>
13:32 < jnymo> that'll be a boon</p>
13:33 <+detonate> of course if anyone has suggestions on what to do, i'd appreciate them</p>
13:33 <+ugha2p> jrandom: How would UDP help people behind NATs?</p>
13:34 < bla> detonate: TCP (on the regular net) does reassembly. Can those concepts be carried over to the I2P UDP reassembly?</p>
13:34 <+detonate> i haven't looked into how tcp does it</p>
13:34 <@jrandom> ugha2p: there's a lot of trickery we can pull off with consistent port #s, etc. lots of code & docs out there</p>
13:35 <@jrandom> bla: we'll certainly be using some level of UDP reassembly along tcp-SACK lines</p>
13:35 <+detonate> but if you're going to handle most of what tcp does, you might as well go the NIO route and actually use it</p>
13:35 <+detonate> saving the hassle</p>
13:35 <@jrandom> no, there's substantial reason for why we do want both some reassembly/retransmission and not tcp</p>
13:36 <+detonate> well, the threads thing</p>
13:36 <@jrandom> the transport layer will not need to be fully reliable or ordered, just semireliable and unordered</p>
13:37 <+ugha2p> Can we also expect a drop in memory usage because of fewer threads?</p>
13:37 <@jrandom> yes</p>
13:37 <+ugha2p> A significant drop</p>
13:38 <+ugha2p> ?</p>
13:38 <@jrandom> substantially. (as well as a drop in memory usage, based off whatever the current OOM is coming from ;)</p>
13:38 <+ugha2p> Right.</p>
13:39 <@jrandom> ok, anything else on 2) roadmap?</p>
13:39 < bla> jrandom: Yeah.</p>
13:40 < bla> jrandom: Will detonate be doing the UDP stuff now? Or else, who will?</p>
13:40 <@jrandom> its a team effort for all who can contribute :)</p>
13:40 <+detonate> heh, i plan on working on udp stuff more, it's less boring than watching tv</p>
13:41 <@jrandom> heh w3wt</p>
13:41 < bla> jrandom: I understand. But for a moment it looked like detonate dropped the project ;)</p>
13:42 <@jrandom> its on the roadmap, it will be done</p>
13:42 <+detonate> sorry for the confusion</p>
13:43 <@jrandom> ok anyone else have anything on 2) roadmap, or shall we mosey on over to 3) addressbook stuff?</p>
13:44 <@jrandom> ok, detonate wanna give us an overview/status report on the editor?</p>
13:45 < bla> detonate: (np)</p>
13:45 <+detonate> ok</p>
13:45 <+detonate> the current state of the editor is here:</p>
13:45 <+detonate> http://detonate.i2p/addressbook-editor/current-state.html</p>
13:45 <+detonate> it still doesn't do any actual editing</p>
13:45 <+detonate> and currently i'm working on the table at the bottom</p>
13:46 <+detonate> i need to read a couple chapters of my jsp book, but after that, you should be able to use it to add/modify entries in the hosts.txt and subscriptions quite easily</p>
13:47 <+detonate> i took a break from it the last 24 hours or so, so that's why there hasn't been much progress</p>
13:47 <+detonate> that's pretty much all</p>
13:47 <@jrandom> w3wt</p>
13:48 < bla> detonate: Looks good</p>
13:49 <@jrandom> yeah, mos' def', I'm looking forward to a way to manage the entries /other/ than just hcaking the hosts file</p>
13:49 <+detonate> thanks</p>
13:49 <+detonate> that's the first time i've used jsp for anything</p>
13:50 <@jrandom> cool</p>
13:51 <@jrandom> oh, i hadn't realized there was the overlap here for subscription management - perhaps smeghead's work can fit in with this as well</p>
13:51 <@jrandom> smeghead: you 'round? you seen this yet?</p>
13:51 < jnymo> detonate: will there be collision detection and what not?</p>
13:51 <@smeghead> actually i only hashed out some skeleton code on the addressbook console, nothing useful</p>
13:51 <+detonate> yeah, i got tired of that, thank duck for suggesting the idea :)</p>
13:51 <@smeghead> i got sidetracked on the TrustedUpdate thingy</p>
13:52 <@jrandom> ah cool :)</p>
13:53 * jrandom likes sidetracking to add new features </p>
13:53 < bla> smeghead: You mean 1-click updates of I2P from _within_ I2P?</p>
13:53 <@smeghead> so luck, not laziness (at least this time :)</p>
13:53 < cervantes2p> bla: 2 click at least ;-)</p>
13:54 <@jrandom> bah, we can get it down to 1 (reject if bad sig/invalid/etc ;)</p>
13:54 <+detonate> yeah, there will be collision detection, that's currently what i'm working on</p>
13:54 <@jrandom> detonate: doesnt the addressbook itself take care of that?</p>
13:54 <@jrandom> detonate: i thought what you're doing just edited the files? </p>
13:55 <@jrandom> (the files will be uniq'ed by the addressbook)</p>
13:55 <+detonate> i mean, showing you the collisions from the logs and handling that</p>
13:55 <@jrandom> ah</p>
13:55 <@jrandom> ok cool</p>
13:55 <+detonate> i assume that's what jnymo is talking about</p>
13:55 < Ragnarok> hm, is there anything I can do to make your life easier? :)</p>
13:55 <+detonate> so you can say "replace entry" with the colliding one of your choice</p>
13:55 <@jrandom> nice!</p>
13:58 <@jrandom> Ragnarok: iirc detonate was able to parse out the logfile pretty easily. do you forsee that format changing?</p>
13:58 < jnymo> detonate: pretty much, yea</p>
13:58 < jnymo> now, is this tied into i2p tightly? How easily can i put a link+key from my browser into my address book?</p>
13:59 <+detonate> yeah, don't change the format, that'll break everything</p>
13:59 < Ragnarok> the format is highly unlikely to change</p>
14:00 < Ragnarok> though more things may get logged in the future</p>
14:00 <@jrandom> jnymo: the eepproxy doesn't have any hooks into detonate's editor atm, but we could add something down the road</p>
14:00 <+detonate> although if you modified the Conflict lines, that would make them easier to parse</p>
14:00 < cervantes2p> possibly something my firefox plugin could do</p>
14:00 <+detonate> right now there are lots of human readable words that get in the way</p>
14:00 < Ragnarok> modify how?</p>
14:00 <@jrandom> (for instance, perhaps i2paddresshelper might redirect to an editor page)</p>
14:00 < cervantes2p> "click here to add this to your addressbook"</p>
14:00 < Ragnarok> ah... I want to be nice to the humans, though</p>
14:00 <+detonate> &lt;date&gt;=&lt;host&gt;=&lt;source&gt;=&lt;new destination&gt; would be superior</p>
14:01 <@jrandom> cervantes2p: that going to work like google's page rewriter? :)</p>
14:01 <+detonate> well, that's what the addressbook-editor is for :)</p>
14:01 <+detonate> it's really not an issue, i've got it covered</p>
14:01 < cervantes2p> jrandom: nah...just have it in the link context menu</p>
14:01 <@jrandom> ooOOoo</p>
14:01 <+detonate> as long as nothing changes radically, things should keep working smoothly</p>
14:02 < cervantes2p> of course I could add a rewriter...but that's just breaks people's page layouts ;-)</p>
14:02 <+detonate> oh, one thing you could do</p>
14:02 <+detonate> because it conflicts with what i do</p>
14:02 <+detonate> make sure all the entries for the hostnames are all-lowercase</p>
14:02 <+detonate> since Legion.i2p is in there</p>
14:02 < cervantes2p> I do want to add a "non i2p link highlighter"</p>
14:02 <+detonate> and i run them all through toLowercase()</p>
14:02 <@jrandom> ah that'd be neat cervantes2p </p>
14:03 <@jrandom> (be sure to only toLowercase the names, base64 is case sensitive ;)</p>
14:03 <+detonate> yeah, only the names</p>
14:04 < jnymo> context menu would be ideal</p>
14:04 <@jrandom> (dont forget the flying ponies!)</p>
14:04 < Ragnarok> I've made address comparisons non-case sensitive in my local branch... I should commit that...</p>
14:04 <+detonate> /make all the hostnames lowercase</p>
14:04 <+detonate> pair[0] = pair[0].toLowerCase();</p>
14:05 <+detonate> there, in black and white</p>
14:05 <+detonate> it just does the hostnames</p>
14:05 <@jrandom> aye Ragnarok, give us the goods :)</p>
14:05 < jnymo> why do i always feel i'm the one riding the flying ponies :(</p>
14:06 <@jrandom> thats 'cause you're hoggin' 'em jnymo ;)</p>
14:06 < cervantes2p> jnymo: don't discuss your domestic "arrangements" in a meeting</p>
14:07 <@jrandom> ok, lots of cool stuff going on within the addressbook & editor. any eta on when we can beta things detonate? (this week, next week, etc)</p>
14:07 < jnymo> heh</p>
14:07 <+detonate> well, as soon as you can get it to work in jetty, you can put it in beta i think</p>
14:07 * jnymo pulls out his p32-space-modulator</p>
14:07 <@jrandom> it works in jetty</p>
14:07 <+detonate> i have no idea how to get netbeans to precompile them and put them in the war</p>
14:08 <+detonate> as long as people don't change the names of the files in config.txt, it should work hopefully without bugs</p>
14:08 <@jrandom> ok, we can work you through ant to take care of things</p>
14:08 <+detonate> ok</p>
14:08 <+detonate> cool</p>
14:08 < cervantes2p> detonate: do what I did, take jrandom's code....strip out everything you don't need, crowbar in your own code and run the ant build script ;-)</p>
14:08 <@jrandom> heh</p>
14:09 <@smeghead> detonate: i know a thing or two about ant, yell if ya get stuck</p>
14:09 <+detonate> feel free to add it to your release</p>
14:09 <+detonate> if you know how to do that</p>
14:09 < MichElle> s/you don't need//</p>
14:09 < Ragnarok> addressbook has a very simple build script, if you want to take a look at that</p>
14:10 <+detonate> i need the section that precompiles jsps</p>
14:10 <+detonate> that's missing from mine</p>
14:10 <+detonate> although it does compile them, it just doesn't merge them, and the entry to test compile them isn't in build.xml</p>
14:10 <@jrandom> detonate: check out the precompilejsp targets in routerconsole, that'll get you started</p>
14:10 <+detonate> and i need to figure out where to put -source 1.3 etc in</p>
14:10 <@jrandom> (and the &lt;war&gt; task)</p>
14:11 <+detonate> yeah, we can sort things out later this evening</p>
14:11 <@jrandom> aye</p>
14:11 < cervantes> yup that's how I managed it...and I don't know ANY java or jsp ;-)</p>
14:11 <@jrandom> ok, if there's nothing more on 3) addressbook stuff, moving on to 4) bt stuff</p>
14:12 <@jrandom> duck/smeghead: wanna give us an update?</p>
14:12 <@duck> k</p>
14:12 <@duck> last week we spoke with Nolar from Azureus about fixing some compatibility problems</p>
14:12 <@duck> with the release of 0.1.8 as result</p>
14:12 <@duck> this week has been mostly about communication</p>
14:12 <@duck> with fellow developers, with forum admins and with users</p>
14:13 <+detonate> does anyone know if the aznet plugin can host torrents again?</p>
14:13 <@duck> the FAQ has been updated based on input from the forum, thanks for those who contributed</p>
14:13 <@duck> also there has been some miscommunication and confusion</p>
14:13 <@jrandom> detonate: word on the street is yes</p>
14:13 <@duck> like legions spork</p>
14:13 <+detonate> excellent</p>
14:13 <@duck> I believe that changing the name of it will prevent further problems there</p>
14:13 <@duck> .</p>
14:14 <@jrandom> r0xor duck</p>
14:14 * MichElle applauds duck</p>
14:14 < MichElle> duck: you work very hard</p>
14:14 < jnymo> yea, why not i2p-bt_extractor or some shit?</p>
14:15 <@jrandom> any word on the later 0.2 stuff, or is that to be addressed after 0.5.0.2/etc?</p>
14:15 <@smeghead> don't applaud yet, you don't know what we're naming it &gt;;-}</p>
14:15 <@jrandom> heh</p>
14:15 * jnymo claps</p>
14:15 <@duck> tell us!</p>
14:15 <@jrandom> i2p-flying-pony-torrent</p>
14:16 <+detonate> heh, are we hiding it now by changing the name?</p>
14:16 < MichElle> again with the ponies</p>
14:16 <@smeghead> it's top-secret for now, we don't want to get sued</p>
14:16 < jnymo> what a debocle</p>
14:17 * bla makes sign for MPAA: "Sue me, if you can..."</p>
14:17 <@smeghead> duck and i have agreed 0.2 will be the first version with the new name</p>
14:17 <+detonate> i2p-communism</p>
14:17 <@duck> released spring 2006</p>
14:17 <@jrandom> heh</p>
14:17 <@duck> .</p>
14:18 <@smeghead> based on my current workload and the fact that i'm moving this week, i don't expect to get any hacking done on 0.2 for a few days, i don't know what duck's near-term schedule is like</p>
14:18 <@duck> been doing 8 hours of C++ pointer fixing</p>
14:19 <@duck> so not much here either :)</p>
14:19 <@jrandom> 'k but something we can perhaps look forward to along side 0.6 (or 0.5.1 if we're lucky?)</p>
14:19 <@jrandom> yikes, fun fun fun</p>
14:19 <@duck> before 2.0 atleast</p>
14:19 <@smeghead> i'd estimate a month or so, just a wild guess, what do you think duck</p>
14:19 <@duck> yeah</p>
14:19 <@jrandom> cool</p>
14:19 <@duck> ballpark</p>
14:20 <@smeghead> the thing is we'd like to wait until the release of the official BT 4.0</p>
14:20 <@jrandom> its ok, we know how schedules go ;)</p>
14:20 <@smeghead> so we can sync 0.2 up-to-date with that</p>
14:20 < MichElle> duck has many things on his plate, indeed</p>
14:20 <@smeghead> 4.0 appears imminent</p>
14:20 <@jrandom> ah, really smeghead? cool</p>
14:20 <@duck> smeghead: that is just the official excuse :)</p>
14:20 < MichElle> but he is a hard worker</p>
14:21 <@duck> I am for 5) ???</p>
14:21 <@jrandom> almost there... </p>
14:21 <@jrandom> legion: any updates on your bt client? progress, etc?</p>
14:21 <@smeghead> source code?</p>
14:22 <@smeghead> (in a zip, not an .exe)</p>
14:22 < cervantes> so the next wave of releases then</p>
14:22 <@jrandom> hmm, legion seems to be idle, ok perhaps we can get an update later</p>
14:22 < cervantes2p> damn huge lag</p>
14:23 <@jrandom> so, movin' on over to 5) ???</p>
14:23 < cervantes> *ahem* w00t</p>
14:23 <@jrandom> cervantes2p: nah, you're just slow ;)</p>
14:23 <@jrandom> ok, anyone else have anything to bring up?</p>
14:23 < cervantes2p> I said those things like 5 minutes ago</p>
14:23 <+ugha2p> jrandom: The mailing list footer still uses the i2p.dnsalias.net address. Perhaps you should update it to reflect dev.i2p.net? :)</p>
14:23 * cervantes2p feeds his router's hamster</p>
14:24 <@jrandom> ah, yeah, prolly ugha2p </p>
14:24 * jrandom has some sysadmin work i've been avoiding for a while (like, oh, moving things to the new srever...)</p>
14:24 < MichElle> I have a concern</p>
14:24 < MichElle> regarding transparency</p>
14:24 <@jrandom> sup MichElle?</p>
14:25 < MichElle> for purposes of full transparency, I will declare here that identiguy has suggested jrandom could in fact be employed by the NSA</p>
14:25 <+detonate> oh, i've noticed 190 routers, how close are we to the thread limit right now?</p>
14:25 * jnymo wonders about other help people can do</p>
14:25 < jnymo> (still looking into the php thing, duck ;)</p>
14:25 <@jrandom> heh MichElle</p>
14:25 < MichElle> his 'convenient' ability to work 24/7 on i2p is quite suspicious, indeed</p>
14:25 < MichElle> anyway</p>
14:25 < MichElle> that's all I wanted to say</p>
14:25 < MichElle> keep your eyes on jrandom</p>
14:26 < MichElle> his gentle and warm facade may be just that.</p>
14:26 <+ugha2p> detonate: There are no theoretical thread limits, it will just consume all available resources until it crashes. :)</p>
14:26 < jnymo> facade</p>
14:26 <@jrandom> detonate: some OSes/ulimits may throttle @ 256, but win98 is already past the 100 TCP connections limit anyway</p>
14:26 < cervantes2p> I can give a quick update on the firefox plugin. The I2P Mail notifier is working now, as is the news reader and basic router controls. I'm busy with tediously building configuration screens now ( http://freshcoffee.i2p/fire2pe_i2pmail_prefs.jpg )</p>
14:27 < jnymo> MichElle, if the source code is sound, then who cares?</p>
14:27 <+detonate> oh, is the firefox plugin released?</p>
14:27 < MichElle> jnymo: it ruins the mood a little</p>
14:27 < cervantes2p> and I want to implement a downloader/install service that ties into smeghead's new updater verifier before I release</p>
14:27 < ddd> hi channel</p>
14:28 <+detonate> ok</p>
14:28 <@jrandom> w0ah! kickass cervantes2p </p>
14:28 <@jrandom> it looks really nice</p>
14:28 <+detonate> hi ddd</p>
14:28 < cervantes2p> but getting close now...probably another couple of weeks...</p>
14:28 < MichElle> sort of like how running windows would still not be cool, even if microsoft open-sourced it</p>
14:28 <+detonate> that plugin looks cool</p>
14:28 < MichElle> back to the meeting, though ...</p>
14:28 <@smeghead> TrustedUpdate may be done this week hopefully, before i move</p>
14:28 <@jrandom> cool</p>
14:29 < ddd> ?</p>
14:29 < ddd> is i2p the only anonymous chat?</p>
14:29 <@jrandom> hi ddd . weekly dev meeting going on</p>
14:30 < cervantes2p> 'lo ddd, we're just finishing a meeting...stick around we'll be done in a couple of minutes</p>
14:30 < ddd> are there other projects like i2p?</p>
14:30 <@smeghead> ddd: type /list then take your pick</p>
14:30 < ddd> ok</p>
14:30 < ddd> no i mean on other networks</p>
14:30 <@jrandom> ok, anyone else have anything to bring up for 5) ???</p>
14:30 <@smeghead> ddd: ask in #i2p-chat</p>
14:30 < ddd> ok i let you guys finish</p>
14:30 <+detonate> has anyone successfully run i2p in openbsd yet?</p>
14:31 <@jrandom> ddd: http://www.i2p.net/how_networkcomparisons</p>
14:31 < ddd> ok</p>
14:31 <+detonate> i was thinking of starting that fiasco up again</p>
14:31 <@jrandom> detonate: dunno</p>
14:31 < jnymo> oh yea.. who was doing the bsd i2p distro, and which bsd was it?</p>
14:31 <@jrandom> heh cool detonate, let us know how it goes</p>
14:31 <@jrandom> jnymo: lioux packaged 'er up for fbsd</p>
14:32 <@smeghead> i2p would never ship with openbsd :)</p>
14:32 <+detonate> sure</p>
14:32 < jnymo> woord.. wasn't someone going to do a i2p oriented distro?</p>
14:32 <+detonate> yeah, there's a port in freebsd now</p>
14:32 <+detonate> it's scary</p>
14:32 <+detonate> heh, someone wanted to have a knoppix cd that ran i2p</p>
14:32 <@jrandom> jnymo: after i2p is rock solid, it'd be worthwhile to explore packaging on distros/microdistros, yeah</p>
14:32 <+detonate> who knows why</p>
14:33 <@smeghead> jnymo: i remember that, i think it was going to be a knoppix/i2p, can't recall who was talking about it</p>
14:33 <@jrandom> detonate: netcafe</p>
14:33 <+detonate> ah</p>
14:34 <@jrandom> ok, anything else for the meeting?</p>
14:34 < MichElle> what the fuck is an i2p 'oriented' distro</p>
14:34 < MichElle> tor, i2p, and freenet ?</p>
14:34 < MichElle> there is no purpose</p>
14:34 < MichElle> the bandwidth requirements cancel the programmes out</p>
14:34 < MichElle> is jrandom theo de raadt ?</p>
14:34 < cervantes> a slightly camp distribution</p>
14:34 < jnymo> a completely anonymized distro</p>
14:35 < cervantes2p> jrandom: I guess not :)</p>
14:35 < MichElle> jrandom: nothing</p>
14:35 * jrandom winds up</p>
14:35 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:05 <@jrandom> 0) hi
13:05 <@jrandom> 1) 0.5.0.1
13:05 <@jrandom> 2) roadmap
13:05 <@jrandom> 3) addressbook editor and config
13:05 <@jrandom> 4) i2p-bt
13:05 <@jrandom> 5) ???
13:05 <@jrandom> 0) hi
13:05 * jrandom waves
13:05 <@duck> hi
13:05 <@jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000616.html
13:05 < null> hi
13:05 <@jrandom> (yeah, i'm late this week, off with my head)
13:06 <@jrandom> while y'all speedreaders dig through that, perhaps we can jump into 1) 0.5.0.1
13:07 <@jrandom> 0.5.0.1 is out, and gets rid of the most ovious bugs from 0.5, but as we've seen, there's still work to be done
13:07 <@jrandom> (current cvs stands at 0.5.0.1-7, I expect at least -8 or -9 before we hit 0.5.0.2)
13:07 <+ugha2p> Hi.
13:08 <+ugha2p> Does CVS HEAD fix that 100% CPU issue?
13:08 <@jrandom> yes, -7 should get the last remnants of it
13:08 <@duck> Does CVS HEAD fix that OOM issue?
13:08 <+detonate> hi
13:08 <@jrandom> no, the OOM is still being tracked down
13:09 <@jrandom> actually... is there a Connelly in the house?
13:09 < ant> <jrandom> nope
13:09 <@jrandom> bugger
13:09 <+ugha2p> jrandom must be going crazy, he is having a dialogue with himself.
13:09 <@jrandom> ok, well, we can see what will be done to get rid of the OOM. its definitely a show stopper, so there won't be a release until its resolved one way or another
13:10 <+detonate> just in time for the meeting
13:11 <@jrandom> thats about all i have to say for the 0.5.0.1 stuff - anyone else have anything they want to mention/ask/discuss?
13:12 <+ugha2p> jrandom: Err, I haven't actually seen the CPU issue with 0.5.0.1, but it happened twice when I tried 0.5.0.1-5. Am I missing something?
13:12 <+ugha2p> I downgraded back to 0.5.0.1 as a result.
13:13 <+detonate> i had a question, the shutdown seems to take a very long time, and the memory usage spikes by about 40mb during that time
13:13 <+detonate> was wondering if you knew why
13:14 <+detonate> the immediate one, obviously
13:14 <@jrandom> it could happen with 0.5.0.1, you just hadn't run into it.
13:14 <@jrandom> (its not a common occurrence, and it only hits some people in odd situations)
13:14 <@jrandom> detonate: very long, as in, more than the usual 11-12 minutes?
13:14 <+ugha2p> Well, it hit me twice during a 8-hour period.
13:15 <+detonate> once all the participating tunnels are gone
13:15 <+ugha2p> jrandom: Is it supposed to use up all the CPU and lose all the leases until restarted when that bug occurs?
13:16 <@jrandom> ugha2p: thats a typical result from the bug, yes
13:16 <+detonate> hmm
13:17 <@jrandom> (it happens when the # of tunnel build requests consume sufficient CPU to exceed the time to satisfy a request, causing an additional request to be queued up, etc)
13:17 <+ugha2p> Must have been an extreme coincidence that it only happened to me while on 0.5.0.1-5.
13:18 <@jrandom> ugha2p: its happened to some people repeatably on 0.5.0.1-0, but is fixed in -7. you can stick with -0 if you prefer, of course
13:18 < cervantes> it was a wonderous godsend
13:18 <+ugha2p> jrandom: I'll try out -7.
13:18 <@jrandom> cool
13:19 <+ugha2p> Although I'm already feeling guilty for giving a bumpy ride to the wiki users so far. :)
13:20 <+ugha2p> One more thing, have you documented the bulk/interactive tunnel types anywhere?
13:20 <+ugha2p> (Except for the source ;)
13:20 <@jrandom> in the changelog. the only difference is a max window size of 1 message
13:20 <+ugha2p> Oh, okay.
13:21 <@jrandom> ok, anything else on 0.5.0.1, or shall we move on over to 2) roadmap?
13:21 <@duck> move on!
13:21 <@jrandom> consider us moved
13:22 <@jrandom> roadmap updated. 'n stuff. see the page for details
13:22 < cervantes> eeh, duck ankle bites
13:23 <@jrandom> i'm thinking of pushing some of the strategies from 0.5.1 to 0.6.1 (so we get UDP faster), but we'll see
13:23 <@jrandom> anyone have any questions/comments/concerns/frisbees?
13:23 <+detonate> have you heard from mule lately?
13:23 <+detonate> speaking of udp
13:24 <@jrandom> nope, he was fairly ill last i heard from 'im
13:24 <+detonate> :/
13:24 < jnymo> udp would kick ass
13:25 <@jrandom> s/would/will/
13:25 <@jrandom> hopefully he's off having fun instead though :)
13:25 <+ugha2p> jrandom: What kind of changes would the bandwidth and performance tuning include?
13:26 < jnymo> so, udp basically means connectionless.. which means.. bigger network, right
13:26 <+detonate> udp introduces all sorts of difficulties along with that
13:26 <@jrandom> ugha2p: batching the tunnel message fragments to fit better into the fixed 1024byte tunnel messages, adding per-pool bw throttles, etc
13:27 <+detonate> but yeah
13:27 <@jrandom> detonate: it won't be so bad, the token bucket scheme we have now can handle async requests without a problem
13:27 <@jrandom> (we just obviously wouldn't use the BandwidthLimitedOutputStream, but would ask the FIFOBandwidthLimiter to allocate K bytes)
13:27 <+ugha2p> Would the first one really make much difference? Per-pool throttling doesn't sound urgent.
13:28 <+detonate> that's good then
13:28 <@jrandom> ugha2p: likely, yes. you can see the exact #s involved by going to /oldstats.jsp#tunnel.smallFragments
13:29 < bla> detonate: How's progress on the reassembly?
13:29 <+detonate> really stalled
13:30 <@jrandom> ugha2p: though its largely dependent upon the type of activity, of course. chatty comm has more to gain, but bulk comm already fills the fragments fully
13:30 <+ugha2p> jrandom: Ok.
13:30 <+ugha2p> Right.
13:31 <+detonate> i stopped working on it completely and started working on the addressbook-editor
13:31 <+detonate> there's probably a really efficient, well-researched way of doing that sort of thing, but i haven't come across it
13:31 < jnymo> will upd mean people behind nats can get through now?
13:31 <@jrandom> some jnymo
13:31 < jnymo> and use i2p?
13:32 <@jrandom> but first we need to get it to work with udp at all, then we start adding the firewall/nat punching, then the PMTU, etc
13:32 < jnymo> that'll be a boon
13:33 <+detonate> of course if anyone has suggestions on what to do, i'd appreciate them
13:33 <+ugha2p> jrandom: How would UDP help people behind NATs?
13:34 < bla> detonate: TCP (on the regular net) does reassembly. Can those concepts be carried over to the I2P UDP reassembly?
13:34 <+detonate> i haven't looked into how tcp does it
13:34 <@jrandom> ugha2p: there's a lot of trickery we can pull off with consistent port #s, etc. lots of code & docs out there
13:35 <@jrandom> bla: we'll certainly be using some level of UDP reassembly along tcp-SACK lines
13:35 <+detonate> but if you're going to handle most of what tcp does, you might as well go the NIO route and actually use it
13:35 <+detonate> saving the hassle
13:35 <@jrandom> no, there's substantial reason for why we do want both some reassembly/retransmission and not tcp
13:36 <+detonate> well, the threads thing
13:36 <@jrandom> the transport layer will not need to be fully reliable or ordered, just semireliable and unordered
13:37 <+ugha2p> Can we also expect a drop in memory usage because of fewer threads?
13:37 <@jrandom> yes
13:37 <+ugha2p> A significant drop
13:38 <+ugha2p> ?
13:38 <@jrandom> substantially. (as well as a drop in memory usage, based off whatever the current OOM is coming from ;)
13:38 <+ugha2p> Right.
13:39 <@jrandom> ok, anything else on 2) roadmap?
13:39 < bla> jrandom: Yeah.
13:40 < bla> jrandom: Will detonate be doing the UDP stuff now? Or else, who will?
13:40 <@jrandom> its a team effort for all who can contribute :)
13:40 <+detonate> heh, i plan on working on udp stuff more, it's less boring than watching tv
13:41 <@jrandom> heh w3wt
13:41 < bla> jrandom: I understand. But for a moment it looked like detonate dropped the project ;)
13:42 <@jrandom> its on the roadmap, it will be done
13:42 <+detonate> sorry for the confusion
13:43 <@jrandom> ok anyone else have anything on 2) roadmap, or shall we mosey on over to 3) addressbook stuff?
13:44 <@jrandom> ok, detonate wanna give us an overview/status report on the editor?
13:45 < bla> detonate: (np)
13:45 <+detonate> ok
13:45 <+detonate> the current state of the editor is here:
13:45 <+detonate> http://detonate.i2p/addressbook-editor/current-state.html
13:45 <+detonate> it still doesn't do any actual editing
13:45 <+detonate> and currently i'm working on the table at the bottom
13:46 <+detonate> i need to read a couple chapters of my jsp book, but after that, you should be able to use it to add/modify entries in the hosts.txt and subscriptions quite easily
13:47 <+detonate> i took a break from it the last 24 hours or so, so that's why there hasn't been much progress
13:47 <+detonate> that's pretty much all
13:47 <@jrandom> w3wt
13:48 < bla> detonate: Looks good
13:49 <@jrandom> yeah, mos' def', I'm looking forward to a way to manage the entries /other/ than just hcaking the hosts file
13:49 <+detonate> thanks
13:49 <+detonate> that's the first time i've used jsp for anything
13:50 <@jrandom> cool
13:51 <@jrandom> oh, i hadn't realized there was the overlap here for subscription management - perhaps smeghead's work can fit in with this as well
13:51 <@jrandom> smeghead: you 'round? you seen this yet?
13:51 < jnymo> detonate: will there be collision detection and what not?
13:51 <@smeghead> actually i only hashed out some skeleton code on the addressbook console, nothing useful
13:51 <+detonate> yeah, i got tired of that, thank duck for suggesting the idea :)
13:51 <@smeghead> i got sidetracked on the TrustedUpdate thingy
13:52 <@jrandom> ah cool :)
13:53 * jrandom likes sidetracking to add new features
13:53 < bla> smeghead: You mean 1-click updates of I2P from _within_ I2P?
13:53 <@smeghead> so luck, not laziness (at least this time :)
13:53 < cervantes2p> bla: 2 click at least ;-)
13:54 <@jrandom> bah, we can get it down to 1 (reject if bad sig/invalid/etc ;)
13:54 <+detonate> yeah, there will be collision detection, that's currently what i'm working on
13:54 <@jrandom> detonate: doesnt the addressbook itself take care of that?
13:54 <@jrandom> detonate: i thought what you're doing just edited the files?
13:55 <@jrandom> (the files will be uniq'ed by the addressbook)
13:55 <+detonate> i mean, showing you the collisions from the logs and handling that
13:55 <@jrandom> ah
13:55 <@jrandom> ok cool
13:55 <+detonate> i assume that's what jnymo is talking about
13:55 < Ragnarok> hm, is there anything I can do to make your life easier? :)
13:55 <+detonate> so you can say "replace entry" with the colliding one of your choice
13:55 <@jrandom> nice!
13:58 <@jrandom> Ragnarok: iirc detonate was able to parse out the logfile pretty easily. do you forsee that format changing?
13:58 < jnymo> detonate: pretty much, yea
13:58 < jnymo> now, is this tied into i2p tightly? How easily can i put a link+key from my browser into my address book?
13:59 <+detonate> yeah, don't change the format, that'll break everything
13:59 < Ragnarok> the format is highly unlikely to change
14:00 < Ragnarok> though more things may get logged in the future
14:00 <@jrandom> jnymo: the eepproxy doesn't have any hooks into detonate's editor atm, but we could add something down the road
14:00 <+detonate> although if you modified the Conflict lines, that would make them easier to parse
14:00 < cervantes2p> possibly something my firefox plugin could do
14:00 <+detonate> right now there are lots of human readable words that get in the way
14:00 < Ragnarok> modify how?
14:00 <@jrandom> (for instance, perhaps i2paddresshelper might redirect to an editor page)
14:00 < cervantes2p> "click here to add this to your addressbook"
14:00 < Ragnarok> ah... I want to be nice to the humans, though
14:00 <+detonate> <date>=<host>=<source>=<new destination> would be superior
14:01 <@jrandom> cervantes2p: that going to work like google's page rewriter? :)
14:01 <+detonate> well, that's what the addressbook-editor is for :)
14:01 <+detonate> it's really not an issue, i've got it covered
14:01 < cervantes2p> jrandom: nah...just have it in the link context menu
14:01 <@jrandom> ooOOoo
14:01 <+detonate> as long as nothing changes radically, things should keep working smoothly
14:02 < cervantes2p> of course I could add a rewriter...but that's just breaks people's page layouts ;-)
14:02 <+detonate> oh, one thing you could do
14:02 <+detonate> because it conflicts with what i do
14:02 <+detonate> make sure all the entries for the hostnames are all-lowercase
14:02 <+detonate> since Legion.i2p is in there
14:02 < cervantes2p> I do want to add a "non i2p link highlighter"
14:02 <+detonate> and i run them all through toLowercase()
14:02 <@jrandom> ah that'd be neat cervantes2p
14:03 <@jrandom> (be sure to only toLowercase the names, base64 is case sensitive ;)
14:03 <+detonate> yeah, only the names
14:04 < jnymo> context menu would be ideal
14:04 <@jrandom> (dont forget the flying ponies!)
14:04 < Ragnarok> I've made address comparisons non-case sensitive in my local branch... I should commit that...
14:04 <+detonate> /make all the hostnames lowercase
14:04 <+detonate> pair[0] = pair[0].toLowerCase();
14:05 <+detonate> there, in black and white
14:05 <+detonate> it just does the hostnames
14:05 <@jrandom> aye Ragnarok, give us the goods :)
14:05 < jnymo> why do i always feel i'm the one riding the flying ponies :(
14:06 <@jrandom> thats 'cause you're hoggin' 'em jnymo ;)
14:06 < cervantes2p> jnymo: don't discuss your domestic "arrangements" in a meeting
14:07 <@jrandom> ok, lots of cool stuff going on within the addressbook & editor. any eta on when we can beta things detonate? (this week, next week, etc)
14:07 < jnymo> heh
14:07 <+detonate> well, as soon as you can get it to work in jetty, you can put it in beta i think
14:07 * jnymo pulls out his p32-space-modulator
14:07 <@jrandom> it works in jetty
14:07 <+detonate> i have no idea how to get netbeans to precompile them and put them in the war
14:08 <+detonate> as long as people don't change the names of the files in config.txt, it should work hopefully without bugs
14:08 <@jrandom> ok, we can work you through ant to take care of things
14:08 <+detonate> ok
14:08 <+detonate> cool
14:08 < cervantes2p> detonate: do what I did, take jrandom's code....strip out everything you don't need, crowbar in your own code and run the ant build script ;-)
14:08 <@jrandom> heh
14:09 <@smeghead> detonate: i know a thing or two about ant, yell if ya get stuck
14:09 <+detonate> feel free to add it to your release
14:09 <+detonate> if you know how to do that
14:09 < MichElle> s/you don't need//
14:09 < Ragnarok> addressbook has a very simple build script, if you want to take a look at that
14:10 <+detonate> i need the section that precompiles jsps
14:10 <+detonate> that's missing from mine
14:10 <+detonate> although it does compile them, it just doesn't merge them, and the entry to test compile them isn't in build.xml
14:10 <@jrandom> detonate: check out the precompilejsp targets in routerconsole, that'll get you started
14:10 <+detonate> and i need to figure out where to put -source 1.3 etc in
14:10 <@jrandom> (and the <war> task)
14:11 <+detonate> yeah, we can sort things out later this evening
14:11 <@jrandom> aye
14:11 < cervantes> yup that's how I managed it...and I don't know ANY java or jsp ;-)
14:11 <@jrandom> ok, if there's nothing more on 3) addressbook stuff, moving on to 4) bt stuff
14:12 <@jrandom> duck/smeghead: wanna give us an update?
14:12 <@duck> k
14:12 <@duck> last week we spoke with Nolar from Azureus about fixing some compatibility problems
14:12 <@duck> with the release of 0.1.8 as result
14:12 <@duck> this week has been mostly about communication
14:12 <@duck> with fellow developers, with forum admins and with users
14:13 <+detonate> does anyone know if the aznet plugin can host torrents again?
14:13 <@duck> the FAQ has been updated based on input from the forum, thanks for those who contributed
14:13 <@duck> also there has been some miscommunication and confusion
14:13 <@jrandom> detonate: word on the street is yes
14:13 <@duck> like legions spork
14:13 <+detonate> excellent
14:13 <@duck> I believe that changing the name of it will prevent further problems there
14:13 <@duck> .
14:14 <@jrandom> r0xor duck
14:14 * MichElle applauds duck
14:14 < MichElle> duck: you work very hard
14:14 < jnymo> yea, why not i2p-bt_extractor or some shit?
14:15 <@jrandom> any word on the later 0.2 stuff, or is that to be addressed after 0.5.0.2/etc?
14:15 <@smeghead> don't applaud yet, you don't know what we're naming it >;-}
14:15 <@jrandom> heh
14:15 * jnymo claps
14:15 <@duck> tell us!
14:15 <@jrandom> i2p-flying-pony-torrent
14:16 <+detonate> heh, are we hiding it now by changing the name?
14:16 < MichElle> again with the ponies
14:16 <@smeghead> it's top-secret for now, we don't want to get sued
14:16 < jnymo> what a debocle
14:17 * bla makes sign for MPAA: "Sue me, if you can..."
14:17 <@smeghead> duck and i have agreed 0.2 will be the first version with the new name
14:17 <+detonate> i2p-communism
14:17 <@duck> released spring 2006
14:17 <@jrandom> heh
14:17 <@duck> .
14:18 <@smeghead> based on my current workload and the fact that i'm moving this week, i don't expect to get any hacking done on 0.2 for a few days, i don't know what duck's near-term schedule is like
14:18 <@duck> been doing 8 hours of C++ pointer fixing
14:19 <@duck> so not much here either :)
14:19 <@jrandom> 'k but something we can perhaps look forward to along side 0.6 (or 0.5.1 if we're lucky?)
14:19 <@jrandom> yikes, fun fun fun
14:19 <@duck> before 2.0 atleast
14:19 <@smeghead> i'd estimate a month or so, just a wild guess, what do you think duck
14:19 <@duck> yeah
14:19 <@jrandom> cool
14:19 <@duck> ballpark
14:20 <@smeghead> the thing is we'd like to wait until the release of the official BT 4.0
14:20 <@jrandom> its ok, we know how schedules go ;)
14:20 <@smeghead> so we can sync 0.2 up-to-date with that
14:20 < MichElle> duck has many things on his plate, indeed
14:20 <@smeghead> 4.0 appears imminent
14:20 <@jrandom> ah, really smeghead? cool
14:20 <@duck> smeghead: that is just the official excuse :)
14:20 < MichElle> but he is a hard worker
14:21 <@duck> I am for 5) ???
14:21 <@jrandom> almost there...
14:21 <@jrandom> legion: any updates on your bt client? progress, etc?
14:21 <@smeghead> source code?
14:22 <@smeghead> (in a zip, not an .exe)
14:22 < cervantes> so the next wave of releases then
14:22 <@jrandom> hmm, legion seems to be idle, ok perhaps we can get an update later
14:22 < cervantes2p> damn huge lag
14:23 <@jrandom> so, movin' on over to 5) ???
14:23 < cervantes> *ahem* w00t
14:23 <@jrandom> cervantes2p: nah, you're just slow ;)
14:23 <@jrandom> ok, anyone else have anything to bring up?
14:23 < cervantes2p> I said those things like 5 minutes ago
14:23 <+ugha2p> jrandom: The mailing list footer still uses the i2p.dnsalias.net address. Perhaps you should update it to reflect dev.i2p.net? :)
14:23 * cervantes2p feeds his router's hamster
14:24 <@jrandom> ah, yeah, prolly ugha2p
14:24 * jrandom has some sysadmin work i've been avoiding for a while (like, oh, moving things to the new srever...)
14:24 < MichElle> I have a concern
14:24 < MichElle> regarding transparency
14:24 <@jrandom> sup MichElle?
14:25 < MichElle> for purposes of full transparency, I will declare here that identiguy has suggested jrandom could in fact be employed by the NSA
14:25 <+detonate> oh, i've noticed 190 routers, how close are we to the thread limit right now?
14:25 * jnymo wonders about other help people can do
14:25 < jnymo> (still looking into the php thing, duck ;)
14:25 <@jrandom> heh MichElle
14:25 < MichElle> his 'convenient' ability to work 24/7 on i2p is quite suspicious, indeed
14:25 < MichElle> anyway
14:25 < MichElle> that's all I wanted to say
14:25 < MichElle> keep your eyes on jrandom
14:26 < MichElle> his gentle and warm facade may be just that.
14:26 <+ugha2p> detonate: There are no theoretical thread limits, it will just consume all available resources until it crashes. :)
14:26 < jnymo> facade
14:26 <@jrandom> detonate: some OSes/ulimits may throttle @ 256, but win98 is already past the 100 TCP connections limit anyway
14:26 < cervantes2p> I can give a quick update on the firefox plugin. The I2P Mail notifier is working now, as is the news reader and basic router controls. I'm busy with tediously building configuration screens now ( http://freshcoffee.i2p/fire2pe_i2pmail_prefs.jpg )
14:27 < jnymo> MichElle, if the source code is sound, then who cares?
14:27 <+detonate> oh, is the firefox plugin released?
14:27 < MichElle> jnymo: it ruins the mood a little
14:27 < cervantes2p> and I want to implement a downloader/install service that ties into smeghead's new updater verifier before I release
14:27 < ddd> hi channel
14:28 <+detonate> ok
14:28 <@jrandom> w0ah! kickass cervantes2p
14:28 <@jrandom> it looks really nice
14:28 <+detonate> hi ddd
14:28 < cervantes2p> but getting close now...probably another couple of weeks...
14:28 < MichElle> sort of like how running windows would still not be cool, even if microsoft open-sourced it
14:28 <+detonate> that plugin looks cool
14:28 < MichElle> back to the meeting, though ...
14:28 <@smeghead> TrustedUpdate may be done this week hopefully, before i move
14:28 <@jrandom> cool
14:29 < ddd> ?
14:29 < ddd> is i2p the only anonymous chat?
14:29 <@jrandom> hi ddd . weekly dev meeting going on
14:30 < cervantes2p> 'lo ddd, we're just finishing a meeting...stick around we'll be done in a couple of minutes
14:30 < ddd> are there other projects like i2p?
14:30 <@smeghead> ddd: type /list then take your pick
14:30 < ddd> ok
14:30 < ddd> no i mean on other networks
14:30 <@jrandom> ok, anyone else have anything to bring up for 5) ???
14:30 <@smeghead> ddd: ask in #i2p-chat
14:30 < ddd> ok i let you guys finish
14:30 <+detonate> has anyone successfully run i2p in openbsd yet?
14:31 <@jrandom> ddd: http://www.i2p.net/how_networkcomparisons
14:31 < ddd> ok
14:31 <+detonate> i was thinking of starting that fiasco up again
14:31 <@jrandom> detonate: dunno
14:31 < jnymo> oh yea.. who was doing the bsd i2p distro, and which bsd was it?
14:31 <@jrandom> heh cool detonate, let us know how it goes
14:31 <@jrandom> jnymo: lioux packaged 'er up for fbsd
14:32 <@smeghead> i2p would never ship with openbsd :)
14:32 <+detonate> sure
14:32 < jnymo> woord.. wasn't someone going to do a i2p oriented distro?
14:32 <+detonate> yeah, there's a port in freebsd now
14:32 <+detonate> it's scary
14:32 <+detonate> heh, someone wanted to have a knoppix cd that ran i2p
14:32 <@jrandom> jnymo: after i2p is rock solid, it'd be worthwhile to explore packaging on distros/microdistros, yeah
14:32 <+detonate> who knows why
14:33 <@smeghead> jnymo: i remember that, i think it was going to be a knoppix/i2p, can't recall who was talking about it
14:33 <@jrandom> detonate: netcafe
14:33 <+detonate> ah
14:34 <@jrandom> ok, anything else for the meeting?
14:34 < MichElle> what the fuck is an i2p 'oriented' distro
14:34 < MichElle> tor, i2p, and freenet ?
14:34 < MichElle> there is no purpose
14:34 < MichElle> the bandwidth requirements cancel the programmes out
14:34 < MichElle> is jrandom theo de raadt ?
14:34 < cervantes> a slightly camp distribution
14:34 < jnymo> a completely anonymized distro
14:35 < cervantes2p> jrandom: I guess not :)
14:35 < MichElle> jrandom: nothing
14:35 * jrandom winds up
14:35 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/131.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, March 1, 2005
==============================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,365 +1,359 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 132{% endblock %}
{% block content %}<h3>I2P dev meeting, March 8, 2005</h3>
<div class="irclog">
13:06 <@jrandom> 0) hi</p>
13:06 <@jrandom> 1) 0.5.0.2</p>
13:06 <@jrandom> 2) mail.i2p updates</p>
13:06 <@jrandom> 3) i2p-bt updates</p>
13:06 < legion> so it's related to the irc servers?</p>
13:06 <@jrandom> 4) ???</p>
13:06 <@jrandom> 0) hi</p>
13:06 <@jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000633.html</p>
13:07 < fedo> hi</p>
13:07 <+postman> hi</p>
13:07 < frosk> goodday</p>
13:07 <@jrandom> legion: no, related to i2p bugs, being worked on</p>
13:07 < bla> hi</p>
13:07 < legion> ok</p>
13:07 <@jrandom> speaking bugs being worked on, lets jump on in to 1) 0.5.0.2 :)</p>
13:07 < cervantes> 'lo</p>
13:07 < cervantes> -- Disconnected</p>
13:08 <@jrandom> heh</p>
13:08 < ant> &lt;mihi&gt; hi all</p>
13:08 <@jrandom> 0.5.0.2 is out, and while your irc connection may lag at times, it'll recover ;)</p>
13:08 <@jrandom> woah heya mihi</p>
13:09 < cervantes> hey mihi</p>
13:09 <@jrandom> the status notes give a general overview of where things are and the most immediate priorities</p>
13:10 <@jrandom> the scary thing I'm trying to track down can be seen on http://localhost:7657/oldstats.jsp#router.invalidMessageTime</p>
13:10 < bla> As for me, I can say that 0.5.0.2 already improved realiability _vastly_ compared to 0.5.0.1: errors where destinations couldn't be contacted almost don't occur anymore </p>
13:10 <@jrandom> those numbers should be very very small, but they're not, unfortunately</p>
13:10 <@jrandom> wikked bla </p>
13:11 <@jrandom> yeah, the 0.5.0.2 is definitely an improvement, and everyone should upgrade ASAP </p>
13:11 < bla> 375,932.22 in the last 10 minutes here....</p>
13:11 <@jrandom> well, the particular value isn't really the problem, its their frequency</p>
13:11 <@jrandom> (events per period)</p>
13:12 <@jrandom> those messages can likely be attributed to 0.5 routers, and some of it to 0.5.0.1 routers, which is why I want people to upgrade ASAP</p>
13:12 <@jrandom> it may be the case that its something else though, but I'd like to rule it out</p>
13:12 < bla> jrandom: I get about 200 per hour here</p>
13:13 <@jrandom> bla: i've currently got 93 this hour, but peak count much higher (thousands)</p>
13:13 <@jrandom> anyway, this particular stat is published in the netdb</p>
13:13 < bla> jrandom: How about excluding 0.5-0 from the net in software when releasing 0.5.0.3?</p>
13:14 <@jrandom> so we can all look around and see what values other people have ;)</p>
13:14 <@duck> 309,854.24 peak 5,473,314.59</p>
13:15 <@duck> pasting the wrong one, huh</p>
13:15 <@jrandom> bla: definitely. I added some code in the 0.5.0.2 rev to do soem forward compatability that 0.5.0.1 and 0.5 don't have</p>
13:16 <@jrandom> duck: hard to have a nonintegral # of events ;)</p>
13:16 < bla> jrandom: Good. At least that allows you to test your invalid-messages-are-due-to-0.5-0 hypothesis in a controlled manner</p>
13:16 <@jrandom> bla: aye, though it'd be great if people updated before then ;)</p>
13:17 <@jrandom> (so for those reading at home: http://www.i2p.net/download is your friend ;)</p>
13:17 < maestro^> jr: those numbers for router.invalidMessageTime deviations in ms?</p>
13:17 <@jrandom> maestro^: yes</p>
13:18 <@jrandom> (aka some really insanely skewed values)</p>
13:18 < legion> Here is a little network report [version|Number of nodes][0.5|6][0.5.0.1|39][0.5.0.2|107]</p>
13:18 <@jrandom> yeah, y'all have been great about updating</p>
13:18 < legion> So there is still a few people running 0.5 and many people running 0.5.0.1</p>
13:18 < maestro^> so any idea where they might be lagging?</p>
13:18 < bla> jrandom: Freenet has a flag in each release that specifies the minimum node version it will communicate with. Is the new forward-compat. code something like that?</p>
13:19 <@jrandom> maestro^: many, many ideas for why 0.5 and 0.5.0.1 users are lagging.</p>
13:19 <@jrandom> bla: similar</p>
13:19 < maestro^> or is it clock drift on nodes?</p>
13:20 <@jrandom> maestro^: clock skew, some serialization bugs, the 100% cpu bug</p>
13:20 <@jrandom> ok, thats generally my focus atm, trying to get the message reliability back up</p>
13:21 <@jrandom> anyone have any questions/comments/concerns on 0.5.0.2?</p>
13:21 < ant> * mihi has a 0.4.2.5 router here on hd not started since dec 22th... but he thinks he'd better delete it...</p>
13:21 <@jrandom> heh</p>
13:21 <@jrandom> yeah, that wont talk to too many routers ;)</p>
13:21 * postman got a backup copy of his last 0.4 installation :)</p>
13:21 < ant> &lt;mihi&gt; question for me 'd be upgrade or delete.</p>
13:22 <@jrandom> delete</p>
13:22 <@jrandom> (backing up any destination keys)</p>
13:22 <@jrandom> there is no upgrade procedure from pre-0.5 anymore</p>
13:22 < legion> Perhaps releasing another update say 0.5.0.2-1 that only allows connections from 0.5.0.2 or newer, would be good?</p>
13:22 <@jrandom> legion: that would segment the network</p>
13:22 <@jrandom> people should juts upgrade.</p>
13:23 <@jrandom> (and we should work around those that dont)</p>
13:24 < legion> yeah until the people running outdated nodes updated ;)</p>
13:24 <@jrandom> segmenting the network hurts us all, not just them</p>
13:25 < legion> Maybe if there was a update notification in the router console or something that let them know they are running outdated versions?</p>
13:25 <@jrandom> yeah, that'd certainly be pretty cool</p>
13:25 <@jrandom> hopefully that can get tied in with the updater as well</p>
13:26 < legion> yeah, I know, segmentation is bad...</p>
13:26 <@jrandom> smeghead is working on some of the key components of that, though not sure if that includes the notification / download</p>
13:26 <@jrandom> (so if anyone wants to help work on that, get in touch!)</p>
13:27 <@jrandom> ok, movin' on to 2) mail.i2p updates</p>
13:27 <@jrandom> postman: ping</p>
13:27 <+postman> yes</p>
13:27 < bla> jrandom: smeghead was doing some signing-related stuff IIRC (so that when you get an update notice, you at least know it's real, and not a phishing/spyware/crap thing)</p>
13:28 * postman takes over the mike</p>
13:28 < legion> hmm, maybe if there was a autoupdate feature built in, where updates would be downloaded through i2p and the nodes would simply download the update, then do a graceful restart.</p>
13:28 <@jrandom> right bla</p>
13:28 < ant> &lt;Gatak&gt; Oh, btw. Would I2P work behind nat even if you cannot open a port?</p>
13:28 <@jrandom> Gatak: not yet. some people will be able to at 0.6, others at 2.0</p>
13:29 <@jrandom> legion: patches welcome</p>
13:29 < ant> &lt;Gatak&gt; 2.0 heck, that is far on the future =)</p>
13:29 <@jrandom> (http://www.i2p.net/roadmap#2.0 ;)</p>
13:29 <+postman> erm, shall i start now?</p>
13:29 < aum> morning all</p>
13:30 <@jrandom> mic is all yours postman (sorry ;)</p>
13:30 <@jrandom> 'lo aum, made it for the meeting</p>
13:30 <@jrandom> (d'oh! /me shuts up again)</p>
13:30 < cervantes> Gatek: http://www.i2p.net/roadmap</p>
13:30 <+postman> first, i wanted to say, that we reached 300 accounts registered at postman.i2p already</p>
13:30 <@jrandom> w00t</p>
13:30 <+postman> the number of mails from/to internet is growing steadily and once more proves that we need to move further</p>
13:31 < cervantes> *squeeeel*</p>
13:31 <+postman> after talking to jr some weeks ago we agreed upon the the release of v2mail together with I2P 1.0</p>
13:31 <+postman> recent status is: the java based smtp proxy designed to run on every node is finished</p>
13:31 <@jrandom> nice!</p>
13:32 <+postman> the java based POP3 proxy is at 80% with just the maildir engine missing</p>
13:32 <+postman> there will be a webmanager that needs some heavy tweaking still (15% done)</p>
13:32 <+postman> the inter node communication is at 40% - we tested some datarecord exchanging with HTTP/XML</p>
13:33 <+postman> seems to work quite well and fast even</p>
13:33 <+postman> even if a relay node fails/was powered off for a few days, it'll be synced within a few minutes after going back onlione again</p>
13:33 <@jrandom> wikked</p>
13:33 <+postman> i think we're quite n track</p>
13:34 <+postman> one thing is noteable</p>
13:34 < bla> postman: Nice work man! One question: Many nodes cannot receive or send data on port 25 (not directly, anyway). Will node-owners be able to specify this (or will this be auto-detected)?</p>
13:34 < cervantes> cool</p>
13:34 <+postman> bla: later</p>
13:34 <+postman> in v2mail there will be a locally run webapp</p>
13:34 <+postman> with this you can manager your local proxies AND apply for an "relayaccount"</p>
13:35 <+postman> this relayaccount will then be used to associate your addess/domain to the relays</p>
13:35 <+postman> the relays will sync the information automatically</p>
13:35 <@jrandom> cool</p>
13:35 <+postman> even features like the addressbook / public keys and stuff will work with the LOCAL interface</p>
13:36 <+postman> so the idea is to have one centralized manager where you can do all your mailstuff</p>
13:36 <+postman> relevant data is transferred to ONE of the relays and then being synced between the relays</p>
13:36 <+postman> and this webbased manager will run on your very node</p>
13:37 <+postman> when your node is online, the relays will deliver mails queued for your destination/domain/address</p>
13:37 <+postman> it will be delivered to your local smtp proxy</p>
13:37 <+postman> you can even trigger the whole thing with ETRN :)</p>
13:37 < aum> hi again</p>
13:37 < aum> i'd like to raise a discussion point in this meeting, if it's ok</p>
13:37 <+postman> so much for the future folks :)</p>
13:37 <+postman> .</p>
13:38 <@jrandom> sound bitchin postman </p>
13:38 * postman hands back the mike</p>
13:38 <@jrandom> aum: great, should be some time at 4) </p>
13:38 <+postman> yeah, iam ecstatic :)</p>
13:38 <@jrandom> postman: so for the normal user, the smtp proxy will have the local maildir, and the pop3 proxy will read/etc, right?</p>
13:39 <+postman> yeah, the smtp proxy got a MDA</p>
13:39 <+postman> and will deliver the mail into local maildirs</p>
13:39 <+postman> even several accounts/users can be created locally</p>
13:39 < cervantes> postman: will the relays keep track of your quotas etc and propogate such info between each other?</p>
13:39 <+postman> and mapped to accounts of your domain</p>
13:39 <+postman> cervantes: yes, they will</p>
13:39 < septu_ssh> sorry, can I ask postman about payment/anti-spam mechanisms in the new model?</p>
13:40 <+postman> septu_ssh: have you read any of the documents on the webpage?</p>
13:40 <+postman> cervantes: it's not perfect real time</p>
13:40 <+postman> cervantes: but i am fine with a few minutes update of quota information exchange</p>
13:40 < septu_ssh> postman: in the queue for reading :/</p>
13:40 < septu_ssh> but if it's doc'd, then it's fine</p>
13:40 < cervantes> postman: yeah I figured</p>
13:41 <+postman> septu_ssh: www.postman.i2p/inout.html</p>
13:41 <+postman> septu_ssh: www.postman.i2p/mailv2.html</p>
13:41 <+postman> cervantes: this is no drama really - the quota is a sane limit</p>
13:41 < cervantes> postman: even someone being able to send nrelays * quota recipients is no bad thing</p>
13:41 * septu_ssh is bungle</p>
13:41 <+postman> cervantes: yep</p>
13:42 <+postman> the goal is just to stop anybody from really abusing the service</p>
13:42 <+postman> in the tests i had 3 relays have been really fast </p>
13:42 <@jrandom> postman: i forget, will this have support for the local smtp relay talking directly to someone else's smtp relay, rather than bouncing through your nodes?</p>
13:42 <+postman> cervantes: within 10 secs they have been synced :)</p>
13:43 <@jrandom> (or perhaps thats just for later)</p>
13:43 <+postman> jrandom: the i2p mail relays will be operated by several ppl and are the preferred dests for routing mail</p>
13:43 < cervantes> postman: you could introduce an exponential delay to the send queue</p>
13:43 < cervantes> if it becomes an issue</p>
13:43 <+postman> jrandom: so sending to other destinations could be handy under certain circumstances</p>
13:44 <@jrandom> aye, though dangerous under others</p>
13:44 < cervantes> so the more mail you send the greater the time the mail gets queued for...should give the relays time to catch up</p>
13:44 <+postman> jrandom: but if a node's owner discloses his IMIO destination he could be spammed w/o control :)</p>
13:44 <@jrandom> exactly</p>
13:44 <@jrandom> otoh, same goes if the i2p mail relays are hostile</p>
13:45 <+postman> jrandom: indeed, it's a WOT like construction</p>
13:45 <@jrandom> &lt;/tinFoil&gt;</p>
13:45 <+postman> jrandom: i cannot stop a relay operator from distributing a quota of 0 for your address</p>
13:45 <@jrandom> 'k great. yeah, no need to worry about it for now</p>
13:45 <+postman> :)</p>
13:46 <+postman> ok</p>
13:46 <+postman> .</p>
13:46 <@jrandom> ok cool, thanks for the update. some really exciting stuff</p>
13:46 <@jrandom> ok, swinging on to 3) i2p-bt updates</p>
13:46 <@jrandom> duck: ping</p>
13:46 <@duck> hi</p>
13:47 <@duck> Yesterday BitTorren 4.0.0 was released</p>
13:47 < ant> &lt;dm&gt; sounds german</p>
13:47 <@duck> which we more or less waited for before starting on 0.2</p>
13:47 <@duck> wrote a tasklist / todo: http://pastebin.ca/raw/7037</p>
13:47 <@duck> (sorry my www is currently down)</p>
13:48 <@jrandom> cool</p>
13:48 < legion> what sort of timetable are we talking about for 0.2?</p>
13:48 <@duck> the goal was 4 weeks</p>
13:49 < legion> cool</p>
13:49 <@duck> as you can see RawServer (the part that communicates with i2p) is the biggest task</p>
13:50 <@duck> .</p>
13:50 <@duck> a quick poll:</p>
13:50 < legion> yeah, I'm well aware of that :)</p>
13:50 <@duck> who is planning to create an i2p-bt fork?</p>
13:50 <@jrandom> cool, is there anything people can do to help?</p>
13:50 <@jrandom> heh</p>
13:51 < ant> &lt;dm&gt; i</p>
13:51 * jrandom grabs a spoon</p>
13:51 < ant> &lt;dm&gt; m wiling to hepl</p>
13:51 < legion> i</p>
13:51 < ant> &lt;dm&gt; m gay</p>
13:51 < legion> I'm working on a fork</p>
13:52 <@duck> good, then I know who not to take serious.</p>
13:52 <@duck> really, I think it is silly; pooling resources might get you much further</p>
13:53 <@jrandom> or perhaps if there are better ways to go, you can convince duck to work that way?</p>
13:53 < named> I'm going to write a fork in qbasic, please take me seriously.</p>
13:53 <@duck> I'll try to have the process more open, so others can see what is planned etc</p>
13:53 < ant> &lt;dm&gt; your openness is not swaying us. FORK! FORK! FORK! FORK!</p>
13:53 <@duck> if you have any other suggestions</p>
13:54 < ant> * dm raises legion onto his shoulders.</p>
13:54 < legion> hmm, that may be true, though with what I'm doing I doubt you want me polluting the main i2p-bt development process ;)</p>
13:54 < ant> &lt;dm&gt; FORK! FORK! FORK! FORK!</p>
13:54 <@jrandom> legion: what are you doing that duck wouldn't want to support?</p>
13:55 <@duck> legion: congrats, if you google for 'i2p bittorrent', then an announcement of "Windows I2P Bittorrent Version 1.0" is #1</p>
13:55 <@jrandom> jesus</p>
13:56 < bla> jrandom: Yes?</p>
13:56 <+postman> jrandom: yeah, they will rip this network's ass open soon :)</p>
13:56 < bla> ;)</p>
13:56 < named> 1.0? Damn, I'm using 0.1.8!</p>
13:56 < Ragnarok> oy</p>
13:57 < legion> omfg, really?! I cannot believe it... that's insane.</p>
13:57 <@duck> anyway, I dont think that there is much new to say on this</p>
13:57 < legion> my 1.0 release is based on 0.1.8 if you're running 0.1.8 you're fine.</p>
13:58 <@jrandom> (and the 1.0 release is a .exe that no one has reviewed, ymmv)</p>
13:58 < legion> I poorly named and numbered it sorry, again about that.</p>
13:58 < ant> &lt;dm&gt; 1.0 &gt;&gt; 0.1.8</p>
13:58 < ant> &lt;dm&gt; any day of the week</p>
13:59 <@duck> slightly related:</p>
13:59 <@jrandom> ok, anything else on 3) i2p-bt, or shall we move on to 4) ???</p>
13:59 <+postman> legion: when there will be sourcecode downloadable?</p>
13:59 < frosk> "I2P-BT 0.1.8 works pretty fine and stable so far. I personally see no reason to update to I2P-BT 1.0" (seen on forum)</p>
13:59 * jrandom sighs</p>
13:59 <@duck> last month bram cohen held a talk about bittorrent on some university</p>
14:00 <@duck> quite interesting: http://netnews.nctu.edu.tw/~gslin/tmp/050216-ee380-100.wmv.torrent</p>
14:00 <@duck> (learned lessons about big p2p programs, plus some bittorrent details explained)</p>
14:00 <@duck> .</p>
14:01 <@jrandom> word</p>
14:01 <@duck> postman: legion has released some sourcecode</p>
14:01 < ant> &lt;dm&gt; is he the inventor of BT?</p>
14:01 <@duck> but according to smeghead it isnt the same as the .exe</p>
14:01 <@jrandom> dm: yes</p>
14:01 < legion> There is a developer source you can download from http://legion.i2p/archives/Itorrent_1_x_Developer_Source.zip.bz2</p>
14:02 <+postman> k, will have a look</p>
14:02 < ant> &lt;dm&gt; is the exe a direct compile of that source?</p>
14:03 < legion> though really the 1.0 source is really just 0.1.8 with a patch from smeghead, compiled and nicely packaged.</p>
14:04 * cervantes walks over to 4)??? and waits for everyone to catch up</p>
14:04 < ant> &lt;dm&gt; the question remains unanswered</p>
14:04 < ant> &lt;dm&gt; Legion, did you or did you not, order a code red???</p>
14:04 <@jrandom> *cough*</p>
14:04 < legion> Perhaps we should get back on topic, my bt client discussion moved to #itorrent</p>
14:05 <@jrandom> ok, 4) ???</p>
14:05 <@jrandom> anything else people want to bring up?</p>
14:05 <@jrandom> aum: you had something?</p>
14:06 < ant> &lt;dm&gt; stasher is back?</p>
14:06 < legion> I'm just seeing some funky behavior with 0.5.0.2 periods of heavy traffic...</p>
14:06 < aum> yes</p>
14:06 < aum> i'd like to raise the question of automated tunnel creation/management</p>
14:07 < ant> &lt;dm&gt; go on</p>
14:07 <+detonate> there's a null pointer exception in the systray thing in windows, i just noticed</p>
14:07 < aum> it's 1337 that the web console now allows for humans to manually create/delete/manage tunnels</p>
14:07 <@jrandom> detonate: could you toss 'er on the bugzilla?</p>
14:07 < aum> but I also strongly believe that there should always be a reliable and convenient way for programs to manage tunels as well</p>
14:08 <@jrandom> aum: no one disagrees. we need it, and we will have it. just not yet.</p>
14:08 < ant> &lt;dm&gt; can't you do that through SAM?</p>
14:08 < aum> i noticed on my recent return to i2p that the pysam library is no longer working</p>
14:08 < septu_ssh> I have a quick question as well after aum</p>
14:08 < aum> which was a disappointment</p>
14:08 <@jrandom> the SAM protocol works, pysam doesnt</p>
14:08 < Ragnarok> did it ever work?</p>
14:09 < aum> correct</p>
14:09 < aum> pysam used to work brilliantly</p>
14:09 < legion> During such periods there are 1000+ tunnels my node is participating in and several seconds of lag and delay.</p>
14:09 <@jrandom> legion: aye, the # of tunnels is because of older builds</p>
14:09 < cervantes> ah mymodesty</p>
14:09 < cervantes> eerm pymodesty</p>
14:09 < aum> i'm presently writing a module 'i2ptunnel.py', which defines classes allowing easy tunnel management</p>
14:10 < legion> so if older builds were not being connected to, the networking would be much smoother?</p>
14:10 <@jrandom> 'k, i don't know if thats the right long term solution, but if it bridges the gap for you now, cool</p>
14:10 <@jrandom> legion: those tunnels aren't the problem</p>
14:11 < aum> well, the class interfaces can remain even though the underlying mechanism changes</p>
14:11 <@jrandom> 'k</p>
14:11 < legion> aren't they?</p>
14:12 < legion> When there a few tunnels, there is very little lag and delay...</p>
14:12 < cervantes> legion: sorry aum is just raising some questions, if you hang fire a minute</p>
14:12 < legion> it just seems odd to me.</p>
14:13 < legion> ok</p>
14:13 <@jrandom> i just worry that we need to take into consideration whats been successful in the past - the web config works and is maintained because everyone uses it. perhaps it'd be best to get whatever app you're working on working with manual tunnel creation *first*, that'd be more efficient?</p>
14:13 <@jrandom> just so that there is always something that is using i2ptunnel.py, to stress it</p>
14:13 < aum> we seem to be deadlocking</p>
14:13 <+detonate> jrandom:sure</p>
14:14 < ant> &lt;dm&gt; let's move on then</p>
14:14 < aum> i don't want to invest time in developing my app till I've got a tunnel mgmt API I can rely on</p>
14:14 < septu_ssh> \o. - point to raise </p>
14:14 < cervantes> realistically I can't imagine the tunnel interface will be revamped in the next couple of months though...</p>
14:14 <@jrandom> but surely you see that we can add one trivially</p>
14:14 < cervantes> so a stopgap solution is viable</p>
14:15 < named_> Couldn't the web config have some kind of api that aum's program manipulates?</p>
14:15 <@jrandom> named_: yes</p>
14:16 <@jrandom> its trivial to add something in to allow safe control via URLs, but only makes sense if there's something that needs it</p>
14:16 <@jrandom> otherwise it'll just rot</p>
14:16 < aum> named_: that would be nice, and could work if there were a hardcoded password in config that client progs need to POST in along with tunnel control fields</p>
14:16 < cervantes> personally I'd like to see the whole tunnel system completely revamped, if you include a tunnel management interface from the start then you won't have to worry about the extra effort needed to maintain a seperate interface</p>
14:17 <@jrandom> aye, the proxies do need a bunch of work, which i've been hiding from as much as possible :)</p>
14:17 < aum> SAM is good for some situations, bad for others</p>
14:17 < cervantes> but that's somewhat down the line...</p>
14:17 < fedo> (</p>
14:18 <@jrandom> aum: but as a stopgap, couldn't you just use one of the three available methods?</p>
14:18 < cervantes> ie if the webinterface itself uses the api then there's no maintenance overhead</p>
14:18 <@jrandom> right. the web interface uses the TunnelControllerGroup</p>
14:19 < aum> SAM usage gets difficult when one wants to use existing libs that are extensively dependent on standard TCP sockets</p>
14:19 < aum> jrandom: the I2PTunnel CLI doesn't work for opening server tunnels, so i'm presently writing code for using TunnelControllerGroup</p>
14:19 <@jrandom> aum: exising libs need to be carefully audited. for instance, the gzip utility itself exposes sensitive data</p>
14:19 < aum> coding as we speak</p>
14:21 <@jrandom> I'm certain that the CLI works for server tunnels, but using the TunnelControllerGroup is preferred, if you need it that way</p>
14:21 <@jrandom> ok, anyone else have anything to bring up?</p>
14:22 < septu_ssh> My question pertains to a distributed version of the hosts.txt, a DHT table is used currently for routerInfo, could this not be extended to a distributed version of DNS? The DNS DHT could contain mappings from www.bla.i2p to the eepsite SHA, and the entries would be signed by an 'I2P registrar'... comments? rebuttals?</p>
14:22 < mancom> a question concerning the roadmap: is 0.6 still scheduled for april?</p>
14:22 <@jrandom> septu_ssh: non-routing data goes in the netDb over my dead body ;)</p>
14:23 < septu_ssh> jrandom: not the same db</p>
14:23 < septu_ssh> a different distributed db</p>
14:23 < aum> jrandom: did you see my bug report? the CLI 'server' command /does not work/</p>
14:23 < maestro^> septu_ssh: there isnt any i2p registrar</p>
14:23 <@jrandom> septu_ssh: there are many dangerous aspects of naming, with a few key tradeoffs. have you seen the naming discussion on ugha.i2p?</p>
14:24 <@jrandom> septu_ssh: ah, a DHT on top of I2P could certainly be used to distribute entries, though those names would not be secure, if they were treated as global entries</p>
14:26 <@jrandom> aum: i used it daily up through a few weeks ago, did you see my reply?</p>
14:26 <@jrandom> maestro^: thats the plan</p>
14:26 <@jrandom> er, mancom:</p>
14:26 < cervantes> aum: I have a reply to that i2plist mail from jr, has it not reached you yet, or does the issue remain?</p>
14:26 < septu_ssh> the only reason why I suggest a 'registrar' is because collisions can take place otherwise</p>
14:26 <@jrandom> septu_ssh: embrace collisions :)</p>
14:26 <@jrandom> globally unique, human readable, distributed, and secure naming doesnt exist</p>
14:27 < septu_ssh> it can also happen in host.txt if it is manually edited, but the problem remains the same</p>
14:27 <@jrandom> drop the first parameter, and you're golden</p>
14:27 < aum> jrandom: i did see your reply - and I /do/ have streaming.jar in my cp</p>
14:27 < septu_ssh> postman manages a central node for mail, so there is some element of trust within the network, surely someone would trust a registrar to manage namespace?</p>
14:27 <@jrandom> ok cool, and it still comes back with that stacktrace aum?</p>
14:28 < aum> yes</p>
14:28 <@jrandom> septu_ssh: postman only acts as a central element for postman's outproxies and inproxies</p>
14:28 * Ragnarok really need to get around to writing that addressbook doc...</p>
14:28 < aum> this is when i manually run the cli, do a genkeys, then do a 'server' using the privkeyfile generated by genkeys</p>
14:28 <@jrandom> septu_ssh: no one will trust anyone to manage a namespace. censorship == exert presure on that registrar.</p>
14:28 < maestro^> everyone is really their own registrar</p>
14:29 < maestro^> you trust your friends and they trust you</p>
14:29 < aum> oh shit, i picked up an old classpath</p>
14:29 * aum tests again</p>
14:30 < ant> &lt;dm&gt; ok, I'll be the registrar.</p>
14:31 < ant> &lt;dm&gt; I'll be as unbiased as I can... cool?</p>
14:31 < septu_ssh> hmmm, ok, back to the proverbial drawing board then...</p>
14:31 <@jrandom> septu_ssh: a good place to review is http://zooko.com/distnames.html :)</p>
14:32 <@jrandom> everyone wants it, but what they want just isn't secure. we have a solution that is, but we give up global uniqueness</p>
14:33 < septu_ssh> hmmm, ok</p>
14:33 <@jrandom> ok, anyone else have anything else to bring up for the meeting?</p>
14:33 < cervantes> septu_ssh: http://forum.i2p.net/viewtopic.php?t=134</p>
14:33 < aum> jrandom - ok, cli 'server' now works, but i never got a 'job number' for the tunnel</p>
14:34 <@jrandom> hmm right, it runs forever</p>
14:34 < aum> oh, i gotta do 'list' to get the job num</p>
14:36 <@jrandom> ok cool, if there's nothing else...</p>
14:36 * jrandom winds up</p>
14:36 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:06 <@jrandom> 0) hi
13:06 <@jrandom> 1) 0.5.0.2
13:06 <@jrandom> 2) mail.i2p updates
13:06 <@jrandom> 3) i2p-bt updates
13:06 < legion> so it's related to the irc servers?
13:06 <@jrandom> 4) ???
13:06 <@jrandom> 0) hi
13:06 <@jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000633.html
13:07 < fedo> hi
13:07 <+postman> hi
13:07 < frosk> goodday
13:07 <@jrandom> legion: no, related to i2p bugs, being worked on
13:07 < bla> hi
13:07 < legion> ok
13:07 <@jrandom> speaking bugs being worked on, lets jump on in to 1) 0.5.0.2 :)
13:07 < cervantes> 'lo
13:07 < cervantes> -- Disconnected
13:08 <@jrandom> heh
13:08 < ant> <mihi> hi all
13:08 <@jrandom> 0.5.0.2 is out, and while your irc connection may lag at times, it'll recover ;)
13:08 <@jrandom> woah heya mihi
13:09 < cervantes> hey mihi
13:09 <@jrandom> the status notes give a general overview of where things are and the most immediate priorities
13:10 <@jrandom> the scary thing I'm trying to track down can be seen on http://localhost:7657/oldstats.jsp#router.invalidMessageTime
13:10 < bla> As for me, I can say that 0.5.0.2 already improved realiability _vastly_ compared to 0.5.0.1: errors where destinations couldn't be contacted almost don't occur anymore
13:10 <@jrandom> those numbers should be very very small, but they're not, unfortunately
13:10 <@jrandom> wikked bla
13:11 <@jrandom> yeah, the 0.5.0.2 is definitely an improvement, and everyone should upgrade ASAP
13:11 < bla> 375,932.22 in the last 10 minutes here....
13:11 <@jrandom> well, the particular value isn't really the problem, its their frequency
13:11 <@jrandom> (events per period)
13:12 <@jrandom> those messages can likely be attributed to 0.5 routers, and some of it to 0.5.0.1 routers, which is why I want people to upgrade ASAP
13:12 <@jrandom> it may be the case that its something else though, but I'd like to rule it out
13:12 < bla> jrandom: I get about 200 per hour here
13:13 <@jrandom> bla: i've currently got 93 this hour, but peak count much higher (thousands)
13:13 <@jrandom> anyway, this particular stat is published in the netdb
13:13 < bla> jrandom: How about excluding 0.5-0 from the net in software when releasing 0.5.0.3?
13:14 <@jrandom> so we can all look around and see what values other people have ;)
13:14 <@duck> 309,854.24 peak 5,473,314.59
13:15 <@duck> pasting the wrong one, huh
13:15 <@jrandom> bla: definitely. I added some code in the 0.5.0.2 rev to do soem forward compatability that 0.5.0.1 and 0.5 don't have
13:16 <@jrandom> duck: hard to have a nonintegral # of events ;)
13:16 < bla> jrandom: Good. At least that allows you to test your invalid-messages-are-due-to-0.5-0 hypothesis in a controlled manner
13:16 <@jrandom> bla: aye, though it'd be great if people updated before then ;)
13:17 <@jrandom> (so for those reading at home: http://www.i2p.net/download is your friend ;)
13:17 < maestro^> jr: those numbers for router.invalidMessageTime deviations in ms?
13:17 <@jrandom> maestro^: yes
13:18 <@jrandom> (aka some really insanely skewed values)
13:18 < legion> Here is a little network report [version|Number of nodes][0.5|6][0.5.0.1|39][0.5.0.2|107]
13:18 <@jrandom> yeah, y'all have been great about updating
13:18 < legion> So there is still a few people running 0.5 and many people running 0.5.0.1
13:18 < maestro^> so any idea where they might be lagging?
13:18 < bla> jrandom: Freenet has a flag in each release that specifies the minimum node version it will communicate with. Is the new forward-compat. code something like that?
13:19 <@jrandom> maestro^: many, many ideas for why 0.5 and 0.5.0.1 users are lagging.
13:19 <@jrandom> bla: similar
13:19 < maestro^> or is it clock drift on nodes?
13:20 <@jrandom> maestro^: clock skew, some serialization bugs, the 100% cpu bug
13:20 <@jrandom> ok, thats generally my focus atm, trying to get the message reliability back up
13:21 <@jrandom> anyone have any questions/comments/concerns on 0.5.0.2?
13:21 < ant> * mihi has a 0.4.2.5 router here on hd not started since dec 22th... but he thinks he'd better delete it...
13:21 <@jrandom> heh
13:21 <@jrandom> yeah, that wont talk to too many routers ;)
13:21 * postman got a backup copy of his last 0.4 installation :)
13:21 < ant> <mihi> question for me 'd be upgrade or delete.
13:22 <@jrandom> delete
13:22 <@jrandom> (backing up any destination keys)
13:22 <@jrandom> there is no upgrade procedure from pre-0.5 anymore
13:22 < legion> Perhaps releasing another update say 0.5.0.2-1 that only allows connections from 0.5.0.2 or newer, would be good?
13:22 <@jrandom> legion: that would segment the network
13:22 <@jrandom> people should juts upgrade.
13:23 <@jrandom> (and we should work around those that dont)
13:24 < legion> yeah until the people running outdated nodes updated ;)
13:24 <@jrandom> segmenting the network hurts us all, not just them
13:25 < legion> Maybe if there was a update notification in the router console or something that let them know they are running outdated versions?
13:25 <@jrandom> yeah, that'd certainly be pretty cool
13:25 <@jrandom> hopefully that can get tied in with the updater as well
13:26 < legion> yeah, I know, segmentation is bad...
13:26 <@jrandom> smeghead is working on some of the key components of that, though not sure if that includes the notification / download
13:26 <@jrandom> (so if anyone wants to help work on that, get in touch!)
13:27 <@jrandom> ok, movin' on to 2) mail.i2p updates
13:27 <@jrandom> postman: ping
13:27 <+postman> yes
13:27 < bla> jrandom: smeghead was doing some signing-related stuff IIRC (so that when you get an update notice, you at least know it's real, and not a phishing/spyware/crap thing)
13:28 * postman takes over the mike
13:28 < legion> hmm, maybe if there was a autoupdate feature built in, where updates would be downloaded through i2p and the nodes would simply download the update, then do a graceful restart.
13:28 <@jrandom> right bla
13:28 < ant> <Gatak> Oh, btw. Would I2P work behind nat even if you cannot open a port?
13:28 <@jrandom> Gatak: not yet. some people will be able to at 0.6, others at 2.0
13:29 <@jrandom> legion: patches welcome
13:29 < ant> <Gatak> 2.0 heck, that is far on the future =)
13:29 <@jrandom> (http://www.i2p.net/roadmap#2.0 ;)
13:29 <+postman> erm, shall i start now?
13:29 < aum> morning all
13:30 <@jrandom> mic is all yours postman (sorry ;)
13:30 <@jrandom> 'lo aum, made it for the meeting
13:30 <@jrandom> (d'oh! /me shuts up again)
13:30 < cervantes> Gatek: http://www.i2p.net/roadmap
13:30 <+postman> first, i wanted to say, that we reached 300 accounts registered at postman.i2p already
13:30 <@jrandom> w00t
13:30 <+postman> the number of mails from/to internet is growing steadily and once more proves that we need to move further
13:31 < cervantes> *squeeeel*
13:31 <+postman> after talking to jr some weeks ago we agreed upon the the release of v2mail together with I2P 1.0
13:31 <+postman> recent status is: the java based smtp proxy designed to run on every node is finished
13:31 <@jrandom> nice!
13:32 <+postman> the java based POP3 proxy is at 80% with just the maildir engine missing
13:32 <+postman> there will be a webmanager that needs some heavy tweaking still (15% done)
13:32 <+postman> the inter node communication is at 40% - we tested some datarecord exchanging with HTTP/XML
13:33 <+postman> seems to work quite well and fast even
13:33 <+postman> even if a relay node fails/was powered off for a few days, it'll be synced within a few minutes after going back onlione again
13:33 <@jrandom> wikked
13:33 <+postman> i think we're quite n track
13:34 <+postman> one thing is noteable
13:34 < bla> postman: Nice work man! One question: Many nodes cannot receive or send data on port 25 (not directly, anyway). Will node-owners be able to specify this (or will this be auto-detected)?
13:34 < cervantes> cool
13:34 <+postman> bla: later
13:34 <+postman> in v2mail there will be a locally run webapp
13:34 <+postman> with this you can manager your local proxies AND apply for an "relayaccount"
13:35 <+postman> this relayaccount will then be used to associate your addess/domain to the relays
13:35 <+postman> the relays will sync the information automatically
13:35 <@jrandom> cool
13:35 <+postman> even features like the addressbook / public keys and stuff will work with the LOCAL interface
13:36 <+postman> so the idea is to have one centralized manager where you can do all your mailstuff
13:36 <+postman> relevant data is transferred to ONE of the relays and then being synced between the relays
13:36 <+postman> and this webbased manager will run on your very node
13:37 <+postman> when your node is online, the relays will deliver mails queued for your destination/domain/address
13:37 <+postman> it will be delivered to your local smtp proxy
13:37 <+postman> you can even trigger the whole thing with ETRN :)
13:37 < aum> hi again
13:37 < aum> i'd like to raise a discussion point in this meeting, if it's ok
13:37 <+postman> so much for the future folks :)
13:37 <+postman> .
13:38 <@jrandom> sound bitchin postman
13:38 * postman hands back the mike
13:38 <@jrandom> aum: great, should be some time at 4)
13:38 <+postman> yeah, iam ecstatic :)
13:38 <@jrandom> postman: so for the normal user, the smtp proxy will have the local maildir, and the pop3 proxy will read/etc, right?
13:39 <+postman> yeah, the smtp proxy got a MDA
13:39 <+postman> and will deliver the mail into local maildirs
13:39 <+postman> even several accounts/users can be created locally
13:39 < cervantes> postman: will the relays keep track of your quotas etc and propogate such info between each other?
13:39 <+postman> and mapped to accounts of your domain
13:39 <+postman> cervantes: yes, they will
13:39 < septu_ssh> sorry, can I ask postman about payment/anti-spam mechanisms in the new model?
13:40 <+postman> septu_ssh: have you read any of the documents on the webpage?
13:40 <+postman> cervantes: it's not perfect real time
13:40 <+postman> cervantes: but i am fine with a few minutes update of quota information exchange
13:40 < septu_ssh> postman: in the queue for reading :/
13:40 < septu_ssh> but if it's doc'd, then it's fine
13:40 < cervantes> postman: yeah I figured
13:41 <+postman> septu_ssh: www.postman.i2p/inout.html
13:41 <+postman> septu_ssh: www.postman.i2p/mailv2.html
13:41 <+postman> cervantes: this is no drama really - the quota is a sane limit
13:41 < cervantes> postman: even someone being able to send nrelays * quota recipients is no bad thing
13:41 * septu_ssh is bungle
13:41 <+postman> cervantes: yep
13:42 <+postman> the goal is just to stop anybody from really abusing the service
13:42 <+postman> in the tests i had 3 relays have been really fast
13:42 <@jrandom> postman: i forget, will this have support for the local smtp relay talking directly to someone else's smtp relay, rather than bouncing through your nodes?
13:42 <+postman> cervantes: within 10 secs they have been synced :)
13:43 <@jrandom> (or perhaps thats just for later)
13:43 <+postman> jrandom: the i2p mail relays will be operated by several ppl and are the preferred dests for routing mail
13:43 < cervantes> postman: you could introduce an exponential delay to the send queue
13:43 < cervantes> if it becomes an issue
13:43 <+postman> jrandom: so sending to other destinations could be handy under certain circumstances
13:44 <@jrandom> aye, though dangerous under others
13:44 < cervantes> so the more mail you send the greater the time the mail gets queued for...should give the relays time to catch up
13:44 <+postman> jrandom: but if a node's owner discloses his IMIO destination he could be spammed w/o control :)
13:44 <@jrandom> exactly
13:44 <@jrandom> otoh, same goes if the i2p mail relays are hostile
13:45 <+postman> jrandom: indeed, it's a WOT like construction
13:45 <@jrandom> </tinFoil>
13:45 <+postman> jrandom: i cannot stop a relay operator from distributing a quota of 0 for your address
13:45 <@jrandom> 'k great. yeah, no need to worry about it for now
13:45 <+postman> :)
13:46 <+postman> ok
13:46 <+postman> .
13:46 <@jrandom> ok cool, thanks for the update. some really exciting stuff
13:46 <@jrandom> ok, swinging on to 3) i2p-bt updates
13:46 <@jrandom> duck: ping
13:46 <@duck> hi
13:47 <@duck> Yesterday BitTorren 4.0.0 was released
13:47 < ant> <dm> sounds german
13:47 <@duck> which we more or less waited for before starting on 0.2
13:47 <@duck> wrote a tasklist / todo: http://pastebin.ca/raw/7037
13:47 <@duck> (sorry my www is currently down)
13:48 <@jrandom> cool
13:48 < legion> what sort of timetable are we talking about for 0.2?
13:48 <@duck> the goal was 4 weeks
13:49 < legion> cool
13:49 <@duck> as you can see RawServer (the part that communicates with i2p) is the biggest task
13:50 <@duck> .
13:50 <@duck> a quick poll:
13:50 < legion> yeah, I'm well aware of that :)
13:50 <@duck> who is planning to create an i2p-bt fork?
13:50 <@jrandom> cool, is there anything people can do to help?
13:50 <@jrandom> heh
13:51 < ant> <dm> i
13:51 * jrandom grabs a spoon
13:51 < ant> <dm> m wiling to hepl
13:51 < legion> i
13:51 < ant> <dm> m gay
13:51 < legion> I'm working on a fork
13:52 <@duck> good, then I know who not to take serious.
13:52 <@duck> really, I think it is silly; pooling resources might get you much further
13:53 <@jrandom> or perhaps if there are better ways to go, you can convince duck to work that way?
13:53 < named> I'm going to write a fork in qbasic, please take me seriously.
13:53 <@duck> I'll try to have the process more open, so others can see what is planned etc
13:53 < ant> <dm> your openness is not swaying us. FORK! FORK! FORK! FORK!
13:53 <@duck> if you have any other suggestions
13:54 < ant> * dm raises legion onto his shoulders.
13:54 < legion> hmm, that may be true, though with what I'm doing I doubt you want me polluting the main i2p-bt development process ;)
13:54 < ant> <dm> FORK! FORK! FORK! FORK!
13:54 <@jrandom> legion: what are you doing that duck wouldn't want to support?
13:55 <@duck> legion: congrats, if you google for 'i2p bittorrent', then an announcement of "Windows I2P Bittorrent Version 1.0" is #1
13:55 <@jrandom> jesus
13:56 < bla> jrandom: Yes?
13:56 <+postman> jrandom: yeah, they will rip this network's ass open soon :)
13:56 < bla> ;)
13:56 < named> 1.0? Damn, I'm using 0.1.8!
13:56 < Ragnarok> oy
13:57 < legion> omfg, really?! I cannot believe it... that's insane.
13:57 <@duck> anyway, I dont think that there is much new to say on this
13:57 < legion> my 1.0 release is based on 0.1.8 if you're running 0.1.8 you're fine.
13:58 <@jrandom> (and the 1.0 release is a .exe that no one has reviewed, ymmv)
13:58 < legion> I poorly named and numbered it sorry, again about that.
13:58 < ant> <dm> 1.0 >> 0.1.8
13:58 < ant> <dm> any day of the week
13:59 <@duck> slightly related:
13:59 <@jrandom> ok, anything else on 3) i2p-bt, or shall we move on to 4) ???
13:59 <+postman> legion: when there will be sourcecode downloadable?
13:59 < frosk> "I2P-BT 0.1.8 works pretty fine and stable so far. I personally see no reason to update to I2P-BT 1.0" (seen on forum)
13:59 * jrandom sighs
13:59 <@duck> last month bram cohen held a talk about bittorrent on some university
14:00 <@duck> quite interesting: http://netnews.nctu.edu.tw/~gslin/tmp/050216-ee380-100.wmv.torrent
14:00 <@duck> (learned lessons about big p2p programs, plus some bittorrent details explained)
14:00 <@duck> .
14:01 <@jrandom> word
14:01 <@duck> postman: legion has released some sourcecode
14:01 < ant> <dm> is he the inventor of BT?
14:01 <@duck> but according to smeghead it isnt the same as the .exe
14:01 <@jrandom> dm: yes
14:01 < legion> There is a developer source you can download from http://legion.i2p/archives/Itorrent_1_x_Developer_Source.zip.bz2
14:02 <+postman> k, will have a look
14:02 < ant> <dm> is the exe a direct compile of that source?
14:03 < legion> though really the 1.0 source is really just 0.1.8 with a patch from smeghead, compiled and nicely packaged.
14:04 * cervantes walks over to 4)??? and waits for everyone to catch up
14:04 < ant> <dm> the question remains unanswered
14:04 < ant> <dm> Legion, did you or did you not, order a code red???
14:04 <@jrandom> *cough*
14:04 < legion> Perhaps we should get back on topic, my bt client discussion moved to #itorrent
14:05 <@jrandom> ok, 4) ???
14:05 <@jrandom> anything else people want to bring up?
14:05 <@jrandom> aum: you had something?
14:06 < ant> <dm> stasher is back?
14:06 < legion> I'm just seeing some funky behavior with 0.5.0.2 periods of heavy traffic...
14:06 < aum> yes
14:06 < aum> i'd like to raise the question of automated tunnel creation/management
14:07 < ant> <dm> go on
14:07 <+detonate> there's a null pointer exception in the systray thing in windows, i just noticed
14:07 < aum> it's 1337 that the web console now allows for humans to manually create/delete/manage tunnels
14:07 <@jrandom> detonate: could you toss 'er on the bugzilla?
14:07 < aum> but I also strongly believe that there should always be a reliable and convenient way for programs to manage tunels as well
14:08 <@jrandom> aum: no one disagrees. we need it, and we will have it. just not yet.
14:08 < ant> <dm> can't you do that through SAM?
14:08 < aum> i noticed on my recent return to i2p that the pysam library is no longer working
14:08 < septu_ssh> I have a quick question as well after aum
14:08 < aum> which was a disappointment
14:08 <@jrandom> the SAM protocol works, pysam doesnt
14:08 < Ragnarok> did it ever work?
14:09 < aum> correct
14:09 < aum> pysam used to work brilliantly
14:09 < legion> During such periods there are 1000+ tunnels my node is participating in and several seconds of lag and delay.
14:09 <@jrandom> legion: aye, the # of tunnels is because of older builds
14:09 < cervantes> ah mymodesty
14:09 < cervantes> eerm pymodesty
14:09 < aum> i'm presently writing a module 'i2ptunnel.py', which defines classes allowing easy tunnel management
14:10 < legion> so if older builds were not being connected to, the networking would be much smoother?
14:10 <@jrandom> 'k, i don't know if thats the right long term solution, but if it bridges the gap for you now, cool
14:10 <@jrandom> legion: those tunnels aren't the problem
14:11 < aum> well, the class interfaces can remain even though the underlying mechanism changes
14:11 <@jrandom> 'k
14:11 < legion> aren't they?
14:12 < legion> When there a few tunnels, there is very little lag and delay...
14:12 < cervantes> legion: sorry aum is just raising some questions, if you hang fire a minute
14:12 < legion> it just seems odd to me.
14:13 < legion> ok
14:13 <@jrandom> i just worry that we need to take into consideration whats been successful in the past - the web config works and is maintained because everyone uses it. perhaps it'd be best to get whatever app you're working on working with manual tunnel creation *first*, that'd be more efficient?
14:13 <@jrandom> just so that there is always something that is using i2ptunnel.py, to stress it
14:13 < aum> we seem to be deadlocking
14:13 <+detonate> jrandom:sure
14:14 < ant> <dm> let's move on then
14:14 < aum> i don't want to invest time in developing my app till I've got a tunnel mgmt API I can rely on
14:14 < septu_ssh> \o. - point to raise
14:14 < cervantes> realistically I can't imagine the tunnel interface will be revamped in the next couple of months though...
14:14 <@jrandom> but surely you see that we can add one trivially
14:14 < cervantes> so a stopgap solution is viable
14:15 < named_> Couldn't the web config have some kind of api that aum's program manipulates?
14:15 <@jrandom> named_: yes
14:16 <@jrandom> its trivial to add something in to allow safe control via URLs, but only makes sense if there's something that needs it
14:16 <@jrandom> otherwise it'll just rot
14:16 < aum> named_: that would be nice, and could work if there were a hardcoded password in config that client progs need to POST in along with tunnel control fields
14:16 < cervantes> personally I'd like to see the whole tunnel system completely revamped, if you include a tunnel management interface from the start then you won't have to worry about the extra effort needed to maintain a seperate interface
14:17 <@jrandom> aye, the proxies do need a bunch of work, which i've been hiding from as much as possible :)
14:17 < aum> SAM is good for some situations, bad for others
14:17 < cervantes> but that's somewhat down the line...
14:17 < fedo> (
14:18 <@jrandom> aum: but as a stopgap, couldn't you just use one of the three available methods?
14:18 < cervantes> ie if the webinterface itself uses the api then there's no maintenance overhead
14:18 <@jrandom> right. the web interface uses the TunnelControllerGroup
14:19 < aum> SAM usage gets difficult when one wants to use existing libs that are extensively dependent on standard TCP sockets
14:19 < aum> jrandom: the I2PTunnel CLI doesn't work for opening server tunnels, so i'm presently writing code for using TunnelControllerGroup
14:19 <@jrandom> aum: exising libs need to be carefully audited. for instance, the gzip utility itself exposes sensitive data
14:19 < aum> coding as we speak
14:21 <@jrandom> I'm certain that the CLI works for server tunnels, but using the TunnelControllerGroup is preferred, if you need it that way
14:21 <@jrandom> ok, anyone else have anything to bring up?
14:22 < septu_ssh> My question pertains to a distributed version of the hosts.txt, a DHT table is used currently for routerInfo, could this not be extended to a distributed version of DNS? The DNS DHT could contain mappings from www.bla.i2p to the eepsite SHA, and the entries would be signed by an 'I2P registrar'... comments? rebuttals?
14:22 < mancom> a question concerning the roadmap: is 0.6 still scheduled for april?
14:22 <@jrandom> septu_ssh: non-routing data goes in the netDb over my dead body ;)
14:23 < septu_ssh> jrandom: not the same db
14:23 < septu_ssh> a different distributed db
14:23 < aum> jrandom: did you see my bug report? the CLI 'server' command /does not work/
14:23 < maestro^> septu_ssh: there isnt any i2p registrar
14:23 <@jrandom> septu_ssh: there are many dangerous aspects of naming, with a few key tradeoffs. have you seen the naming discussion on ugha.i2p?
14:24 <@jrandom> septu_ssh: ah, a DHT on top of I2P could certainly be used to distribute entries, though those names would not be secure, if they were treated as global entries
14:26 <@jrandom> aum: i used it daily up through a few weeks ago, did you see my reply?
14:26 <@jrandom> maestro^: thats the plan
14:26 <@jrandom> er, mancom:
14:26 < cervantes> aum: I have a reply to that i2plist mail from jr, has it not reached you yet, or does the issue remain?
14:26 < septu_ssh> the only reason why I suggest a 'registrar' is because collisions can take place otherwise
14:26 <@jrandom> septu_ssh: embrace collisions :)
14:26 <@jrandom> globally unique, human readable, distributed, and secure naming doesnt exist
14:27 < septu_ssh> it can also happen in host.txt if it is manually edited, but the problem remains the same
14:27 <@jrandom> drop the first parameter, and you're golden
14:27 < aum> jrandom: i did see your reply - and I /do/ have streaming.jar in my cp
14:27 < septu_ssh> postman manages a central node for mail, so there is some element of trust within the network, surely someone would trust a registrar to manage namespace?
14:27 <@jrandom> ok cool, and it still comes back with that stacktrace aum?
14:28 < aum> yes
14:28 <@jrandom> septu_ssh: postman only acts as a central element for postman's outproxies and inproxies
14:28 * Ragnarok really need to get around to writing that addressbook doc...
14:28 < aum> this is when i manually run the cli, do a genkeys, then do a 'server' using the privkeyfile generated by genkeys
14:28 <@jrandom> septu_ssh: no one will trust anyone to manage a namespace. censorship == exert presure on that registrar.
14:28 < maestro^> everyone is really their own registrar
14:29 < maestro^> you trust your friends and they trust you
14:29 < aum> oh shit, i picked up an old classpath
14:29 * aum tests again
14:30 < ant> <dm> ok, I'll be the registrar.
14:31 < ant> <dm> I'll be as unbiased as I can... cool?
14:31 < septu_ssh> hmmm, ok, back to the proverbial drawing board then...
14:31 <@jrandom> septu_ssh: a good place to review is http://zooko.com/distnames.html :)
14:32 <@jrandom> everyone wants it, but what they want just isn't secure. we have a solution that is, but we give up global uniqueness
14:33 < septu_ssh> hmmm, ok
14:33 <@jrandom> ok, anyone else have anything else to bring up for the meeting?
14:33 < cervantes> septu_ssh: http://forum.i2p.net/viewtopic.php?t=134
14:33 < aum> jrandom - ok, cli 'server' now works, but i never got a 'job number' for the tunnel
14:34 <@jrandom> hmm right, it runs forever
14:34 < aum> oh, i gotta do 'list' to get the job num
14:36 <@jrandom> ok cool, if there's nothing else...
14:36 * jrandom winds up
14:36 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/132.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, March 8, 2005
==============================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,323 +1,317 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 133{% endblock %}
{% block content %}<h3>I2P dev meeting, March 15, 2005</h3>
<div class="irclog">
13:07 < jrandom> 0) hi</p>
13:07 < jrandom> 1) Net status</p>
13:07 < jrandom> 2) Feedspace</p>
13:07 < jrandom> 3) ???</p>
13:07 < jrandom> 0) hi</p>
13:07 * jrandom waves</p>
13:07 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000649.html</p>
13:08 < Teal> hi</p>
13:08 < jrandom> (yeah, i was late this time, but close!)</p>
13:08 < frosk> hi</p>
13:08 < jrandom> might as well jump on in to 1) net status</p>
13:08 < jrandom> the net, its, like, up, 'n stuff</p>
13:09 < jrandom> overall throughput is still down where it was before, with a substantial number of dropped messages & fragments</p>
13:09 < bla> hi</p>
13:09 < ant> &lt;dm&gt; bad</p>
13:09 < Teal> any clues as to why ?</p>
13:10 < jrandom> Teal: sure, read the status notes? :)</p>
13:10 <+detonate> hi</p>
13:11 < jrandom> there are still ~ 25 people on older builds, and likely, they'll be staying there until we drop them off the net</p>
13:11 < jrandom> in any case, we should be able to work around them, so having them here is actually helpful, i suppose</p>
13:11 < jrandom> (though it'd be nice if they upgraded... ;)</p>
13:11 < cervantes> (hi)</p>
13:11 < frosk> those are probably sheeple who installed i2p because they read about it somewhere and wanted to try "anonymous p2p"</p>
13:12 < ant> &lt;BS314159&gt; yeah, if network quality degradation can happen due to bugs, it's possible due to malice</p>
13:12 < newkid> This is the first meeting I am in, but I read the notes, and the problem seems related to what I explained before the meeting</p>
13:12 < Pseudonym> do we know what specific probblems the old nodes are causing and why?</p>
13:12 < jrandom> bs314159: never attribute to malice what can be attributed to jrandom writing bad code ;)</p>
13:13 < jrandom> Pseudonym: yeah, see the changelog</p>
13:13 < newkid> I run two nodes, milliseconds apart, and they don't regard eacxh other "fast" more of the time</p>
13:13 < jrandom> right newkid </p>
13:13 < jrandom> the speed calculator as deployed is, well, pretty shitty</p>
13:13 < jrandom> it doesnt gather enough data to have any sort of confidence in the values</p>
13:13 < bla> Hmm.. That's bad at best ;)</p>
13:13 < jrandom> its about as meaningless as the "instantaneous rates" you can see on /oldconsole.jsp</p>
13:14 < jrandom> i'm trying out some new calculators, and there is an improvement, but there are problems in the algorithm</p>
13:14 < jrandom> namely, it won't let high capacity peers turn into fast peers without those fast peers dropping from the high capacity group</p>
13:15 < bla> jrandom: Does every node get "fastness" data for the other nodes directly ("P2P"), or via tunnels?</p>
13:15 < jrandom> (aka the first K peers placed in the fast group will stay in the fast group)</p>
13:15 < jrandom> bla: tunnels, we cannot trust direct measurement, as that'd allow trivial anonymity attacks</p>
13:15 < godmode0> "alfYl6RvHzw=" = "21538-900"</p>
13:15 < godmode0> "alV9ye/y/Us=" = "23565-200"</p>
13:15 < godmode0> its is sha1 ?</p>
13:15 < jrandom> (e.g. be really really slow to everyone except Alice)</p>
13:15 <+detonate> they'll stay there for the lifetime of the router?</p>
13:15 < jrandom> godmode0: we're in a meeting right now</p>
13:16 < godmode0> ops sorry</p>
13:16 < jrandom> detonate: until one of them failed or rejected a tunnel (aka their capacity rank drops them from the high capacity group)</p>
13:16 <+detonate> ok</p>
13:17 < bla> bla: Hmm.. This sounds like a problem that ---in order to get _really_ enough_ data--- has to be &gt;&gt;log(N) on the network. </p>
13:17 < jrandom> i've been toying with some ideas to get more data, but haven't updated it yet</p>
13:17 < bla> In terms of load, that is.</p>
13:18 < jrandom> well, one of the critical points certainly is when the network load exceeds the network capacity</p>
13:18 < jrandom> i believe our capacity calculators can handle that though</p>
13:18 < cervantes> jrandom: is -3 actually employing this fast peer selection method?</p>
13:18 <+polecat> Hopefully since data transfer between peers has fairness controls, there won't be any way to increase load too much...</p>
13:19 < bla> jrandom: Well, I mean more specifically: we need to make sure that the "finding out who is fast" algo. stays O(log(N))</p>
13:19 < jrandom> cervantes: yeah, but as i said, it doesn't allow promoting peers between fast and high capacity</p>
13:19 < jrandom> polecat: fairness controls?</p>
13:19 < cervantes> since I've just realised I've had the proxy enabled, and have been browsing the live web without realising (I did think my connection was a little sluggish) ;-)</p>
13:20 < cervantes> s/live web/outerweb</p>
13:20 < jrandom> bla: i'm not sure we should be dependent upon N. no need to find an optimal 'fastest on the net', merely 'fast enough to handle our data'</p>
13:20 <@smeghead> it would seem i2pProxy.pac is dangerous even for its creator :)</p>
13:20 < jrandom> heh nice cervantes :)</p>
13:20 < jrandom> lol</p>
13:20 < cervantes> so it certainly seems to have improved things on my home node which was really suffering before</p>
13:21 < ant> &lt;BS314159&gt; jrandom: can you randomize it?</p>
13:21 < cervantes> smeghead: hehe hell I don't use that! you think I'm mad!</p>
13:21 < ant> &lt;BS314159&gt; i.e. create a spontaneous transition rate?</p>
13:21 < jrandom> BS314159: we use the tiers, and randomize within the tiers</p>
13:22 < jrandom> BS314159: spontaneous rates are essentially what we have now, which fluctuate widely</p>
13:22 < jrandom> (we == 0.5.0.2-0)</p>
13:22 < ant> &lt;BS314159&gt; I think I don't understand the problem. nm.</p>
13:23 < jrandom> it is tough to do safely and accurately, but i think there's enough data around for us to harvest sufficient info. we shall see</p>
13:23 < bla> jrandom: In any case, finding out a couple of good nodes looks an awful lot like an ant-colony optimization thing</p>
13:24 < bla> jrandom: Because once you've got fast peers, you're likely to use _those_ to find out who else is fast.</p>
13:24 < jrandom> would you propose further active probing along those lines?</p>
13:24 < jrandom> ah, actualy, thats not true</p>
13:25 < jrandom> thats the difference between client tunnels and exploratory tunnels</p>
13:25 < bla> jrandom: And thus, it seems you'd essentially be doing a greedy optimization scheme (much like ant-colony)</p>
13:25 < jrandom> client tunnels are built with fast peers, exploratory tunnels are built with any non-failing peer</p>
13:25 < jrandom> (chosen randomly)</p>
13:26 < bla> jrandom: Hmm.. For anonimity, that's good. However, for quickly finding good tunnel-partners to use, it would be better to use fast peers in the expl. tunnels... The trade-off again</p>
13:26 < jrandom> otoh, there may be something in that vein to help optimize the peer selection</p>
13:26 < jrandom> oh, right, certainly you'd get better performance by using the fast peers, but then you wouldn't be exploring :)</p>
13:27 < jrandom> the exploratory tunnels aren't used for end to end client messages, just for netDb messages, tunnel maintenance messages, and peer test messages</p>
13:27 < bla> jrandom: I see, so effectively, you use random expl. tunnels to prevent falling into local optima?</p>
13:27 < jrandom> so the actual throughput of the exploratory tunnels doesnt matter (as long as the data gets through, eventually)</p>
13:27 < jrandom> aye</p>
13:29 < bla> jrandom: Ok, I see. OTOH: When I use my client tunnels to transfer some data (like downloading from an eepsite), I seems to me (intuitively), that the timing/throughput data on that could also serve as some kind of "passive peers assessment", couldn't it?</p>
13:29 < jrandom> definitely bla, and at the moment, we don't yet harvest that data within the speed selection</p>
13:29 < bla> jrandom: i.e. as an aux. way to get more data on peers</p>
13:30 < jrandom> some of it we can, though some of it will be harder to grab (since the streaming lib is external)</p>
13:30 < jrandom> we should definitely grab what we can though to get more confidence</p>
13:30 < ant> &lt;BS314159&gt; won't that depend on the slowest link in any tunnel?</p>
13:31 < ant> &lt;BS314159&gt; making it very difficult to use for hops&gt;0?</p>
13:31 < jrandom> BS314159: yeah, but it'll average out, as peers are selected randomly within the fast tier</p>
13:31 < jrandom> same goes for any remote measurement</p>
13:34 < jrandom> ok, so thats generally where things stand atm. hopefully we'll have some new calculators & stats up for a -4 or -5 build in the next few days, trying to see how it handles the live net</p>
13:34 < jrandom> anyone have anything else to bring up for 1) Net status?</p>
13:34 < bla> jrandom: It may seem that I'm putting a truckload of emphasis on this, but it seems to me to be a problem that['s very fundamental for a big I2P net to work...</p>
13:35 < jrandom> bla: its certainly important, but remember, we don't need optimal peer selection. merely sufficient</p>
13:35 < ant> &lt;aum&gt; morning folks</p>
13:36 < jrandom> all we care about is finding some peers who can handle a tunnel, and making sure those tunnels can handle our data</p>
13:36 < jrandom> 'mornin aum, in time for the meeting :)</p>
13:36 < bla> jrandom: I see. Thnx for the explaination!</p>
13:36 < jrandom> of course, you're right in that it'd be kickass if we /could/ find the optimal peer selection ;)</p>
13:37 < jrandom> and there is definitely lots of room for some students to work out some ideas and write up some papers</p>
13:37 < frosk> this would be a cool thesis project :)</p>
13:37 <+detonate> how workable do you think it would be to actively tweak the parameters of the peer selection until it hopefully settles on something that works, disregarding the impossibility of debugging such a system? :)</p>
13:38 < jrandom> detonate: manual peer selection is a PITA, since fast peers get congested occationally, asking you to back off, etc. </p>
13:38 <+detonate> ah</p>
13:39 < jrandom> i know we could dig into this forever, which is why i've set a milestone of successfully transferring one specific large file through standard tunnels, without disconnect</p>
13:39 <+detonate> alright</p>
13:40 < Teal> Victory at any cost!</p>
13:40 < jrandom> (otoh, there are some undocumented features of the peer selection system to let people weight individual peers manually, but i'm not recommending 'em ;)</p>
13:40 < jrandom> ok, thats 'bout it for 1), now lets swing on to 2) Feedspace</p>
13:41 * jrandom hands the mic to frosk </p>
13:41 < frosk> oh, ok, hi</p>
13:42 < Myo9> Hi Frosk.</p>
13:42 * jrandom gets out the high intensity spotlight</p>
13:42 < frosk> so, everyone should check out http://feedspace.i2p (keys at orion or jrandom's blog)</p>
13:42 < frosk> my devbuddy (which i will out now as ku) and i have started writing some code and have had many lively discussions</p>
13:42 < frosk> also, http://feedspace.i2p/wiki/CallForComments has a fresh rev of the feedspace document :)</p>
13:43 < frosk> hi Myo9</p>
13:43 < frosk> oh yeah, feedspace is our new (and final) name for what used to be known as i2pcontent or fusenet :)</p>
13:43 < jrandom> r0x0r</p>
13:43 < frosk> as the status notes notes, we are still very interested in feedback on the general design of everything</p>
13:44 < frosk> nobody should be shy about challenging it :)</p>
13:44 < frosk> and the web site also lists some "job openings", we could use some helping hands on many aspects of the system and project</p>
13:45 < frosk> we're on a pretty tight schedule and none of us are full-time developers on the project unfortunately</p>
13:45 < frosk> so that's pretty much it, i think. questions? :)</p>
13:45 < ant> * aum can't reach orion.i2p or jrandom's blog, so can't reach feedspace.i2p</p>
13:46 < frosk> hm yes, the web site also has a roadmap, but the dates there _will_ change :)</p>
13:46 < legion> feedspace.i2p=KuW5sR2iGCfnnuwdslHbFsNyNCsoZnoIwAmHeypOV-s8OQxokBpdNazksBrhoQum9nv81vprl6k15Mhcd~KWE4OajjmdU7v2fjqps7QK3KmLv4UTrX-ihSIUdhb5B9FLh2XEFEQ4-8guFTVxBRqQQE~c058AL6~uZpuFpLtEOg0HEZ6BydndOhx-FCDm8ip12pPwZ3a5O86l1UoATZBXxoctGafTjnUlx64jyQs6y0WB811l36wVrc~~dqEcanxab0yfg8dJ~1M4EUNrXcHT-PwYYrr3GgpimuF4oUtYjkeDKlq5WjfMAa8bE73HFgquxq99fuW5aI1JbLPxnTLHi00-2On0dSDwJxSP08HOhKFKMNzykI9Asg8CywzNO6kWpbX9yaML36ohCJF0iaLvvDyhS4a2B65crSJRJPVkbxIvsyyUyYMGi31EK593ijOLjOvug</p>
13:46 < legion> there you go aum</p>
13:46 * jrandom just added feedspace to http://dev.i2p.net/i2p/hosts.txt</p>
13:46 < jrandom> (and cvs)</p>
13:46 * frosk goes temporarily blind</p>
13:46 < jrandom> legion: never paste as a single line, its too large to fit</p>
13:47 < ant> &lt;aum&gt; thx</p>
13:47 < frosk> jrandom can probably commit the key into his hosts.txt maybe? :)</p>
13:47 < jrandom> aye, 'tis on there now, forgot to :)</p>
13:48 < frosk> anyway, the plan is to have something simple and functional (and 100% bug-free!) out by I2P 0.6.1, and we'll build more neat stuff in later</p>
13:49 < jrandom> heh wikked</p>
13:49 < frosk> s/out/ready for real-world testing/</p>
13:49 < frosk> i still can't say if that's realistic or not, but i hope it will be, or we'll continue to cut features ;)</p>
13:49 < ant> &lt;BS314159&gt; since I can't reach feedspace.i2p, I'll ask a basic question</p>
13:50 < ant> &lt;aum&gt; that key is not correct, only 441 chars</p>
13:50 < jrandom> right aum, irc trims it, snag http://dev.i2p.net/i2p/hosts.txt</p>
13:51 <+detonate> frosk: i have a suggestion for the meantime</p>
13:51 <+detonate> get something on the i2p router console that grabs a list of updates from the i2p webserver, so people know when to update their routers, etc :)</p>
13:51 < legion> ah sorry, about that. Anyways I've already commited it to my hosts.txt also.</p>
13:51 < ant> &lt;aum&gt; thx jrandom</p>
13:51 < ant> &lt;BS314159&gt; which of the following systems do you see feedspace supplanting: usenet, gnutella, google, livejournal, www</p>
13:52 < jrandom> , the church</p>
13:52 < jrandom> er..</p>
13:52 < cervantes> jrandom: ah you caught me mid commit of hosts</p>
13:52 < ant> &lt;BS314159&gt; i.e. is it a message forum, a filesharing system, a content indexing system, a dynamic page system, and/or a static serving system</p>
13:53 < ant> * aum turns off throttling within routerConsole, and sees if that helps</p>
13:54 < frosk> BS314159: we will support blogs, forums, and shared address books (for the first version, other applications are possible)</p>
13:54 < frosk> it doesn't replace web pages per se</p>
13:54 < frosk> but it certainly could be used for "file sharing"</p>
13:54 <+detonate> content syndication then?</p>
13:54 < jrandom> it'd probably supplant static web content though, allowing persistent web publication for people who cannot run eepsites</p>
13:54 < frosk> that's what it's about</p>
13:55 < jrandom> (two word summary: usenet+SSK)</p>
13:55 < frosk> yeah</p>
13:55 < ant> &lt;BS314159&gt; ok</p>
13:55 < Ragnarok> not that persistent</p>
13:56 < jrandom> Ragnarok: depends on syndicator policy, true</p>
13:56 <+detonate> is anything happening with stasher?</p>
13:56 < frosk> it can be as persistant as the most eager syndicator :)</p>
13:56 < jrandom> (see: dejanews ;)</p>
13:56 < ant> &lt;aum&gt; detonate: stasher is on hold, writing a whole new thing called quartermaster</p>
13:57 <+detonate> i see</p>
13:58 < jrandom> frosk: what can we do to help?</p>
13:59 < jrandom> should people register & hack on the wiki, email, post on the forum?</p>
13:59 < jrandom> oh, perhaps we can get cervantes to add a new forum category?</p>
13:59 < frosk> i think actually a forum would be very nice at this point</p>
14:00 < frosk> for more private discussion, you can email us both at ku@mail.i2p and frosk@mail.i2p</p>
14:01 < cervantes> hrrrm ... are you going to put game reviews in it?</p>
14:01 < jrandom> heh</p>
14:01 < jrandom> w3rd</p>
14:01 < cervantes> because if not...then you're welcome to have a new forum section</p>
14:01 < frosk> i was thinking top20 music reviews, cervantes</p>
14:02 < jrandom> (btw, mirror of the call for comments @ http://dev.i2p.net/~jrandom/feedspace.txt)</p>
14:02 < cervantes> :)</p>
14:04 < cervantes> frosk: feedspace or feed space or Feedspace or Feed Space or FeedSpace?</p>
14:04 < frosk> cervantes: Feedspace</p>
14:05 < frosk> looking forward to much discussion over at the forum then :) i don't have anything else for this point, anyone else?</p>
14:05 < jrandom> ok cool, thanks for the update frosk </p>
14:06 <@smeghead> or FEeDspace?</p>
14:06 < ant> &lt;cervantes&gt; frosk: when you have a moment, just pm me a one liner description for the forum section</p>
14:06 < legion> hmm speaking of new forums, lol. I'm putting a new forum site together. Though I have much hacking left to do on the phpbb code, it should be finshed sometime this week. ;)</p>
14:06 < jrandom> cool legion </p>
14:06 < jrandom> that actually brings us into 3) ??? nicely</p>
14:06 < jrandom> anyone have anything else to bring up? </p>
14:06 < jrandom> aum: any updates on Q?</p>
14:07 < frosk> i, uhm, no</p>
14:07 < ant> &lt;aum&gt; Q devlt is moving along nicely, nothing to announce atm</p>
14:07 < jrandom> w3rd</p>
14:07 < ant> * aum is 90% complete with net.i2p.i2ptunnel.I2PTunnelXMLServer</p>
14:07 < ant> &lt;BS314159&gt; I have a simple question about netDb</p>
14:07 < ant> &lt;aum&gt; everything's working now except 'i2p.tunnel.close'</p>
14:07 < legion> my forums will allow for members to have decent sized avatars, discuss shared content, just about whatever.</p>
14:08 < jrandom> wikked</p>
14:08 < ant> &lt;BS314159&gt; it says on the page that entries are stores on the peers closest to SHA256(router identity + YYYYMMdd)</p>
14:08 < jrandom> right BSpi</p>
14:08 <@smeghead> legion: will it be as much a security hazard as your bt client?</p>
14:08 < ant> &lt;BS314159&gt; does this mean there's a burst of traffic every 00:00 GMT?</p>
14:08 < ant> * aum is actually gaining some fluency in java, having attained a 'cognitive critical mass'</p>
14:09 < jrandom> BS: data points expire more frequently than they migrate</p>
14:09 < jrandom> a LeaseSet is only good for 10 minutes, for example</p>
14:09 < bla> jrandom: Is there a command-line call I can make, such that I can speed estimates of each of the peers in the net over the last, say, 60 seconds, or so?</p>
14:09 < legion> lol, forums a security hazard?</p>
14:10 <@smeghead> legion: yes, and if you don't know that much, i'm already convinced that your forums will be a security hazard</p>
14:10 < jrandom> bla: yeah, java -cp lib/i2p.jar:lib/router.jar -Djava.library.path=. net.i2p.router.peermanager.ProfileOrganizer peerProfiles/*</p>
14:10 < jrandom> (i think)</p>
14:10 < legion> oh and the next release of my bt client shouldn't cause such issues...</p>
14:10 < jrandom> you may need to add some log levels to logger.config, lemmie check</p>
14:10 <@smeghead> legion: Cervantes made a ton of modifications to phpBB to lock it down for i2p use</p>
14:10 < ant> &lt;BS314159&gt; It just seems like having it occur all-at-once at a specified time is awkward. If it were happening continuously, that would seem...smoother. It would also give an attacker less time to mount an attack, since bits of the data would be wrong in less than 24 hours</p>
14:11 < jrandom> nah, it dumps to stdout</p>
14:11 < frosk> jrandom: how do you feel about the i2p roadmap currently, if one may ask? do you think it's realistic?</p>
14:11 < legion> Hmm I wonder if I can get a copy of cervantes mods?</p>
14:11 < jrandom> frosk: i update it when i become uncomfortable with it</p>
14:12 < frosk> ok</p>
14:12 <+detonate> you know, there's a windows installer for python 2.4, one for wxpython, and there's the i2p-bt tarball, i don't really see why anyone would get/trust a third-party release</p>
14:12 < legion> Otherwise I'll just have to continue to hack on the phpbb source myself...</p>
14:12 < jrandom> BS: peers would only look in the wrong place for up to 30s, due to clock synchronization</p>
14:12 <@smeghead> legion: have fun</p>
14:12 < legion> well why would anyone get and use kazaa?</p>
14:13 < bla> jrandom: I'm asking, because...</p>
14:13 < legion> Or morpheus?</p>
14:13 < jrandom> (because they dont know better?)</p>
14:13 < legion> Both of those contain adware/etc...</p>
14:13 <+detonate> they are ignorant?</p>
14:14 < legion> yeah and there are millions of ignorant users out there. ;)</p>
14:14 < ant> &lt;BS314159&gt; legion: you sound like you want to bundle spyware with I2P. Truly, a stroke of genius.</p>
14:14 < bla> jrandom: ...I browsed SpeedCalculator.java and CapacityCalculator.java, and I'd like to experiment with the estimators</p>
14:14 < cervantes> legion: stay uptodate with official patches, and put htaccess on the admin areas</p>
14:14 < jrandom> wikked bla</p>
14:14 < legion> What? Heck no... I hate malware...</p>
14:14 < cervantes> most of my mods involve spam prevention</p>
14:14 < ant> &lt;aum&gt; can i raise a more critical issue?</p>
14:14 < legion> That's it? cervantes?</p>
14:15 < jrandom> sup aum?</p>
14:15 <@smeghead> legion: what about your users that also hate malware? why do you do nothing to alleviate any concerns they might have?</p>
14:15 < ant> &lt;dm&gt; BS314159: are you a windows hotfix?</p>
14:15 < ant> &lt;aum&gt; is it just me, or is there still some flakiness going on with in i2p? i'm having heaps of trouble with even main eepsites, irc etc</p>
14:15 < bla> jrandom: In addition, the idea of "passive fingerprinting" is now in my head (a bit ;): If I receive data through a tunnel, this tells me something about the bandwidth/capacity of all the peers in that tunnel:...</p>
14:15 < jrandom> aum: see the weekly status notes</p>
14:16 < cervantes> legion: rename all registration, login , posting and profile editing pages to something non-standard </p>
14:16 < bla> jrandom: It tells me some about the peer closest to me, somewhat less about the peers one step away, and so progressively less.</p>
14:16 < cervantes> will help keep worms at bay</p>
14:16 < jrandom> bla: aye, i read that timing paper, and yesterday's tor attack paper with much interest</p>
14:17 < Myo9> Cervantes, releasing ant of your mods?</p>
14:17 < Myo9> s/ant/any/</p>
14:17 < jrandom> there is worry along those lines in the capacity calculator with the different tiers of rejection</p>
14:18 < bla> jrandom: In a way, this gives me some degree of "belief" in a peers bandwidth/capacity (that degree of belief depends on the distance to each of the tunnel members, and on the amount of belief I have on the BW/cap. of the nodes closest to me)</p>
14:18 < legion> thanks for the advice cervantes :)</p>
14:18 < bla> jrandom: Now, I happen to know some ppl that know a lot about Bayesian Belief Networks... ;))</p>
14:18 <@smeghead> again, legion ignores the question</p>
14:18 <+thetower> I think we're all gonna have to call a truce with legion and let him write whatever he wants, its not like anyone is forced to use it.</p>
14:18 < jrandom> hmm, what do you mean by distance bla?</p>
14:18 < ant> &lt;dm&gt; what is legion up to?</p>
14:19 < bla> jrandom: I'll have a chat with them, regarding passive fingerprinting (note: I do not mean "fingerprinting" in the negative sense of the word)</p>
14:19 < jrandom> wikked</p>
14:19 < jrandom> suggestions as to how we can best select 'quality' peers are very much welcome</p>
14:19 < cervantes> Myo9: I certainly could do.</p>
14:19 < legion> Anyways there isn't many i2p windows users just yet and not that many running my i2p-bt binary distribution. Soon my next release will be done and released, it will not have such issues... As there will be a binary and source distribution.</p>
14:19 <@smeghead> why anyone would want to use software from someone who doesn't even take the most basic measures to address users' concerns about security and anonymity is beyond me</p>
14:20 < ant> &lt;aum&gt; frosk: what lang you writing feedspace in? (forgive me if i asked you before)</p>
14:20 < cervantes> it's not a clean "patch" or anything though</p>
14:20 < bla> jrandom: distance... Say I have an inbound tunnel X -&gt; Y -&gt; me, and I know a _lot_ about Y's properties, than stats on what I receive thru that tunnel tells me a good deal about X</p>
14:20 < frosk> aum: java (and i forgive you ;)</p>
14:20 < cervantes> I've just been fixing stuff andproblems as it arises</p>
14:20 < bla> jrandom: OTOH, if I have little data/belief on Y's properties, transfer stats don't tell me much about X yet; I first have more to learn about Y</p>
14:20 < cervantes> as they</p>
14:20 < jrandom> bla: its very hard to tell whether lag or congestion occurs @ X or Y (or earlier hops)</p>
14:20 < cervantes> http://forum.i2p/index.php?c=4</p>
14:21 < cervantes> new section: Feedspace</p>
14:21 < jrandom> w00t</p>
14:21 < frosk> yay</p>
14:22 < legion> anyways enough discussion about my release, any further discussion about it should be done in the #itorrent channel</p>
14:22 < bla> jrandom: That is true. However, given large amount of data (and hoping that the measurement time is not _much_ larger than the timescale on which node properties change), I'm convinced there _must_ be information in traffic/tunnel stats</p>
14:22 <@smeghead> legion: we can discuss in meeting point # 3) any business that affects i2p</p>
14:23 <@smeghead> legion: and i think your software is of serious concern and warrants a warning to users</p>
14:23 < legion> yeah, ok</p>
14:23 < jrandom> bla: certainly, we just need to rope in the RTT from the OutboundClientMessageOneShotJob</p>
14:23 < jrandom> (and then figure out how best to calculate & decay the data)</p>
14:24 < legion> So smeghead if you were to make such a release, what would you do differently?</p>
14:24 <@smeghead> legion: the way you continually dodge questions and try to defer discussion on the subject is very disconcerting</p>
14:25 <@smeghead> legion: first of all, release the source to your current binary, no matter if it's "just i2p-bt with smeghead's patch", and have a writeup on your site explaining about your fork</p>
14:25 < bla> jrandom: What does the RTT signify there?</p>
14:26 <@smeghead> legion: it would be helpful to do as i2p-bt does also, and make a changelog indicating all the modifications you've made</p>
14:27 < jrandom> bla: end to end client messages are often (by default, always) bundled in garlic wrapping, containing an additional DeliveryStatusMessage that returns to the sender (through tunnels, of course), allowing the use of AES+sessionTags instead of ElGamal</p>
14:28 < bla> jrandom: (yes)</p>
14:28 <+detonate> as i said, you could just provide a link to the download page for the three things you need for i2p-bt to work, it's straight-forward and gets you exactly the same thing, i can't actually see a use for it besides a trojan</p>
14:28 < jrandom> later on we'll update I2CP (and the SDK) to allow the streaming lib to deliver that same data without requiring the DeliveryStatusMessage</p>
14:29 <@smeghead> detonate: i agree, he should have just submitted a patch to the official i2p-bt in the first place, forking was completely unnecessary and fostered immediate suspicioun</p>
14:30 <+detonate> indeed</p>
14:30 <@smeghead> *suspicion</p>
14:31 < jrandom> ok, anyone else have anything to bring up for the meeting?</p>
14:31 < ant> &lt;drakoh&gt; hi people ! wanted to know, is there anything special with the network ?</p>
14:32 <@smeghead> because of the nature of i2p, applications developed for it require a greater measure of openness with end users and cooperation among developers</p>
14:32 < jrandom> drakoh: see the weekly status notes</p>
14:32 < bla> quit</p>
14:32 < ant> &lt;drakoh&gt; no I mean something strange ...</p>
14:32 <@smeghead> i2p users will always be naturally paranoid to some extent, and it's our duty to do what we can to dispel any concerns we possibly can</p>
14:32 < ant> &lt;drakoh&gt; like I lost all my peers</p>
14:33 < jrandom> aye, agreed smeghead. for anonymity or security software, especially software dealing with a trojan-laden field such as filesharing, its critical to be open.</p>
14:33 < jrandom> drakoh: ok, hold on, we can debug that once the meeting is over</p>
14:33 < ant> &lt;drakoh&gt; woops sorry</p>
14:33 < jrandom> ok, speaking of the meeting being over...</p>
14:34 * jrandom winds up</p>
14:34 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:07 < jrandom> 0) hi
13:07 < jrandom> 1) Net status
13:07 < jrandom> 2) Feedspace
13:07 < jrandom> 3) ???
13:07 < jrandom> 0) hi
13:07 * jrandom waves
13:07 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000649.html
13:08 < Teal> hi
13:08 < jrandom> (yeah, i was late this time, but close!)
13:08 < frosk> hi
13:08 < jrandom> might as well jump on in to 1) net status
13:08 < jrandom> the net, its, like, up, 'n stuff
13:09 < jrandom> overall throughput is still down where it was before, with a substantial number of dropped messages & fragments
13:09 < bla> hi
13:09 < ant> <dm> bad
13:09 < Teal> any clues as to why ?
13:10 < jrandom> Teal: sure, read the status notes? :)
13:10 <+detonate> hi
13:11 < jrandom> there are still ~ 25 people on older builds, and likely, they'll be staying there until we drop them off the net
13:11 < jrandom> in any case, we should be able to work around them, so having them here is actually helpful, i suppose
13:11 < jrandom> (though it'd be nice if they upgraded... ;)
13:11 < cervantes> (hi)
13:11 < frosk> those are probably sheeple who installed i2p because they read about it somewhere and wanted to try "anonymous p2p"
13:12 < ant> <BS314159> yeah, if network quality degradation can happen due to bugs, it's possible due to malice
13:12 < newkid> This is the first meeting I am in, but I read the notes, and the problem seems related to what I explained before the meeting
13:12 < Pseudonym> do we know what specific probblems the old nodes are causing and why?
13:12 < jrandom> bs314159: never attribute to malice what can be attributed to jrandom writing bad code ;)
13:13 < jrandom> Pseudonym: yeah, see the changelog
13:13 < newkid> I run two nodes, milliseconds apart, and they don't regard eacxh other "fast" more of the time
13:13 < jrandom> right newkid
13:13 < jrandom> the speed calculator as deployed is, well, pretty shitty
13:13 < jrandom> it doesnt gather enough data to have any sort of confidence in the values
13:13 < bla> Hmm.. That's bad at best ;)
13:13 < jrandom> its about as meaningless as the "instantaneous rates" you can see on /oldconsole.jsp
13:14 < jrandom> i'm trying out some new calculators, and there is an improvement, but there are problems in the algorithm
13:14 < jrandom> namely, it won't let high capacity peers turn into fast peers without those fast peers dropping from the high capacity group
13:15 < bla> jrandom: Does every node get "fastness" data for the other nodes directly ("P2P"), or via tunnels?
13:15 < jrandom> (aka the first K peers placed in the fast group will stay in the fast group)
13:15 < jrandom> bla: tunnels, we cannot trust direct measurement, as that'd allow trivial anonymity attacks
13:15 < godmode0> "alfYl6RvHzw=" = "21538-900"
13:15 < godmode0> "alV9ye/y/Us=" = "23565-200"
13:15 < godmode0> its is sha1 ?
13:15 < jrandom> (e.g. be really really slow to everyone except Alice)
13:15 <+detonate> they'll stay there for the lifetime of the router?
13:15 < jrandom> godmode0: we're in a meeting right now
13:16 < godmode0> ops sorry
13:16 < jrandom> detonate: until one of them failed or rejected a tunnel (aka their capacity rank drops them from the high capacity group)
13:16 <+detonate> ok
13:17 < bla> bla: Hmm.. This sounds like a problem that ---in order to get _really_ enough_ data--- has to be >>log(N) on the network.
13:17 < jrandom> i've been toying with some ideas to get more data, but haven't updated it yet
13:17 < bla> In terms of load, that is.
13:18 < jrandom> well, one of the critical points certainly is when the network load exceeds the network capacity
13:18 < jrandom> i believe our capacity calculators can handle that though
13:18 < cervantes> jrandom: is -3 actually employing this fast peer selection method?
13:18 <+polecat> Hopefully since data transfer between peers has fairness controls, there won't be any way to increase load too much...
13:19 < bla> jrandom: Well, I mean more specifically: we need to make sure that the "finding out who is fast" algo. stays O(log(N))
13:19 < jrandom> cervantes: yeah, but as i said, it doesn't allow promoting peers between fast and high capacity
13:19 < jrandom> polecat: fairness controls?
13:19 < cervantes> since I've just realised I've had the proxy enabled, and have been browsing the live web without realising (I did think my connection was a little sluggish) ;-)
13:20 < cervantes> s/live web/outerweb
13:20 < jrandom> bla: i'm not sure we should be dependent upon N. no need to find an optimal 'fastest on the net', merely 'fast enough to handle our data'
13:20 <@smeghead> it would seem i2pProxy.pac is dangerous even for its creator :)
13:20 < jrandom> heh nice cervantes :)
13:20 < jrandom> lol
13:20 < cervantes> so it certainly seems to have improved things on my home node which was really suffering before
13:21 < ant> <BS314159> jrandom: can you randomize it?
13:21 < cervantes> smeghead: hehe hell I don't use that! you think I'm mad!
13:21 < ant> <BS314159> i.e. create a spontaneous transition rate?
13:21 < jrandom> BS314159: we use the tiers, and randomize within the tiers
13:22 < jrandom> BS314159: spontaneous rates are essentially what we have now, which fluctuate widely
13:22 < jrandom> (we == 0.5.0.2-0)
13:22 < ant> <BS314159> I think I don't understand the problem. nm.
13:23 < jrandom> it is tough to do safely and accurately, but i think there's enough data around for us to harvest sufficient info. we shall see
13:23 < bla> jrandom: In any case, finding out a couple of good nodes looks an awful lot like an ant-colony optimization thing
13:24 < bla> jrandom: Because once you've got fast peers, you're likely to use _those_ to find out who else is fast.
13:24 < jrandom> would you propose further active probing along those lines?
13:24 < jrandom> ah, actualy, thats not true
13:25 < jrandom> thats the difference between client tunnels and exploratory tunnels
13:25 < bla> jrandom: And thus, it seems you'd essentially be doing a greedy optimization scheme (much like ant-colony)
13:25 < jrandom> client tunnels are built with fast peers, exploratory tunnels are built with any non-failing peer
13:25 < jrandom> (chosen randomly)
13:26 < bla> jrandom: Hmm.. For anonimity, that's good. However, for quickly finding good tunnel-partners to use, it would be better to use fast peers in the expl. tunnels... The trade-off again
13:26 < jrandom> otoh, there may be something in that vein to help optimize the peer selection
13:26 < jrandom> oh, right, certainly you'd get better performance by using the fast peers, but then you wouldn't be exploring :)
13:27 < jrandom> the exploratory tunnels aren't used for end to end client messages, just for netDb messages, tunnel maintenance messages, and peer test messages
13:27 < bla> jrandom: I see, so effectively, you use random expl. tunnels to prevent falling into local optima?
13:27 < jrandom> so the actual throughput of the exploratory tunnels doesnt matter (as long as the data gets through, eventually)
13:27 < jrandom> aye
13:29 < bla> jrandom: Ok, I see. OTOH: When I use my client tunnels to transfer some data (like downloading from an eepsite), I seems to me (intuitively), that the timing/throughput data on that could also serve as some kind of "passive peers assessment", couldn't it?
13:29 < jrandom> definitely bla, and at the moment, we don't yet harvest that data within the speed selection
13:29 < bla> jrandom: i.e. as an aux. way to get more data on peers
13:30 < jrandom> some of it we can, though some of it will be harder to grab (since the streaming lib is external)
13:30 < jrandom> we should definitely grab what we can though to get more confidence
13:30 < ant> <BS314159> won't that depend on the slowest link in any tunnel?
13:31 < ant> <BS314159> making it very difficult to use for hops>0?
13:31 < jrandom> BS314159: yeah, but it'll average out, as peers are selected randomly within the fast tier
13:31 < jrandom> same goes for any remote measurement
13:34 < jrandom> ok, so thats generally where things stand atm. hopefully we'll have some new calculators & stats up for a -4 or -5 build in the next few days, trying to see how it handles the live net
13:34 < jrandom> anyone have anything else to bring up for 1) Net status?
13:34 < bla> jrandom: It may seem that I'm putting a truckload of emphasis on this, but it seems to me to be a problem that['s very fundamental for a big I2P net to work...
13:35 < jrandom> bla: its certainly important, but remember, we don't need optimal peer selection. merely sufficient
13:35 < ant> <aum> morning folks
13:36 < jrandom> all we care about is finding some peers who can handle a tunnel, and making sure those tunnels can handle our data
13:36 < jrandom> 'mornin aum, in time for the meeting :)
13:36 < bla> jrandom: I see. Thnx for the explaination!
13:36 < jrandom> of course, you're right in that it'd be kickass if we /could/ find the optimal peer selection ;)
13:37 < jrandom> and there is definitely lots of room for some students to work out some ideas and write up some papers
13:37 < frosk> this would be a cool thesis project :)
13:37 <+detonate> how workable do you think it would be to actively tweak the parameters of the peer selection until it hopefully settles on something that works, disregarding the impossibility of debugging such a system? :)
13:38 < jrandom> detonate: manual peer selection is a PITA, since fast peers get congested occationally, asking you to back off, etc.
13:38 <+detonate> ah
13:39 < jrandom> i know we could dig into this forever, which is why i've set a milestone of successfully transferring one specific large file through standard tunnels, without disconnect
13:39 <+detonate> alright
13:40 < Teal> Victory at any cost!
13:40 < jrandom> (otoh, there are some undocumented features of the peer selection system to let people weight individual peers manually, but i'm not recommending 'em ;)
13:40 < jrandom> ok, thats 'bout it for 1), now lets swing on to 2) Feedspace
13:41 * jrandom hands the mic to frosk
13:41 < frosk> oh, ok, hi
13:42 < Myo9> Hi Frosk.
13:42 * jrandom gets out the high intensity spotlight
13:42 < frosk> so, everyone should check out http://feedspace.i2p (keys at orion or jrandom's blog)
13:42 < frosk> my devbuddy (which i will out now as ku) and i have started writing some code and have had many lively discussions
13:42 < frosk> also, http://feedspace.i2p/wiki/CallForComments has a fresh rev of the feedspace document :)
13:43 < frosk> hi Myo9
13:43 < frosk> oh yeah, feedspace is our new (and final) name for what used to be known as i2pcontent or fusenet :)
13:43 < jrandom> r0x0r
13:43 < frosk> as the status notes notes, we are still very interested in feedback on the general design of everything
13:44 < frosk> nobody should be shy about challenging it :)
13:44 < frosk> and the web site also lists some "job openings", we could use some helping hands on many aspects of the system and project
13:45 < frosk> we're on a pretty tight schedule and none of us are full-time developers on the project unfortunately
13:45 < frosk> so that's pretty much it, i think. questions? :)
13:45 < ant> * aum can't reach orion.i2p or jrandom's blog, so can't reach feedspace.i2p
13:46 < frosk> hm yes, the web site also has a roadmap, but the dates there _will_ change :)
13:46 < legion> feedspace.i2p=KuW5sR2iGCfnnuwdslHbFsNyNCsoZnoIwAmHeypOV-s8OQxokBpdNazksBrhoQum9nv81vprl6k15Mhcd~KWE4OajjmdU7v2fjqps7QK3KmLv4UTrX-ihSIUdhb5B9FLh2XEFEQ4-8guFTVxBRqQQE~c058AL6~uZpuFpLtEOg0HEZ6BydndOhx-FCDm8ip12pPwZ3a5O86l1UoATZBXxoctGafTjnUlx64jyQs6y0WB811l36wVrc~~dqEcanxab0yfg8dJ~1M4EUNrXcHT-PwYYrr3GgpimuF4oUtYjkeDKlq5WjfMAa8bE73HFgquxq99fuW5aI1JbLPxnTLHi00-2On0dSDwJxSP08HOhKFKMNzykI9Asg8CywzNO6kWpbX9yaML36ohCJF0iaLvvDyhS4a2B65crSJRJPVkbxIvsyyUyYMGi31EK593ijOLjOvug
13:46 < legion> there you go aum
13:46 * jrandom just added feedspace to http://dev.i2p.net/i2p/hosts.txt
13:46 < jrandom> (and cvs)
13:46 * frosk goes temporarily blind
13:46 < jrandom> legion: never paste as a single line, its too large to fit
13:47 < ant> <aum> thx
13:47 < frosk> jrandom can probably commit the key into his hosts.txt maybe? :)
13:47 < jrandom> aye, 'tis on there now, forgot to :)
13:48 < frosk> anyway, the plan is to have something simple and functional (and 100% bug-free!) out by I2P 0.6.1, and we'll build more neat stuff in later
13:49 < jrandom> heh wikked
13:49 < frosk> s/out/ready for real-world testing/
13:49 < frosk> i still can't say if that's realistic or not, but i hope it will be, or we'll continue to cut features ;)
13:49 < ant> <BS314159> since I can't reach feedspace.i2p, I'll ask a basic question
13:50 < ant> <aum> that key is not correct, only 441 chars
13:50 < jrandom> right aum, irc trims it, snag http://dev.i2p.net/i2p/hosts.txt
13:51 <+detonate> frosk: i have a suggestion for the meantime
13:51 <+detonate> get something on the i2p router console that grabs a list of updates from the i2p webserver, so people know when to update their routers, etc :)
13:51 < legion> ah sorry, about that. Anyways I've already commited it to my hosts.txt also.
13:51 < ant> <aum> thx jrandom
13:51 < ant> <BS314159> which of the following systems do you see feedspace supplanting: usenet, gnutella, google, livejournal, www
13:52 < jrandom> , the church
13:52 < jrandom> er..
13:52 < cervantes> jrandom: ah you caught me mid commit of hosts
13:52 < ant> <BS314159> i.e. is it a message forum, a filesharing system, a content indexing system, a dynamic page system, and/or a static serving system
13:53 < ant> * aum turns off throttling within routerConsole, and sees if that helps
13:54 < frosk> BS314159: we will support blogs, forums, and shared address books (for the first version, other applications are possible)
13:54 < frosk> it doesn't replace web pages per se
13:54 < frosk> but it certainly could be used for "file sharing"
13:54 <+detonate> content syndication then?
13:54 < jrandom> it'd probably supplant static web content though, allowing persistent web publication for people who cannot run eepsites
13:54 < frosk> that's what it's about
13:55 < jrandom> (two word summary: usenet+SSK)
13:55 < frosk> yeah
13:55 < ant> <BS314159> ok
13:55 < Ragnarok> not that persistent
13:56 < jrandom> Ragnarok: depends on syndicator policy, true
13:56 <+detonate> is anything happening with stasher?
13:56 < frosk> it can be as persistant as the most eager syndicator :)
13:56 < jrandom> (see: dejanews ;)
13:56 < ant> <aum> detonate: stasher is on hold, writing a whole new thing called quartermaster
13:57 <+detonate> i see
13:58 < jrandom> frosk: what can we do to help?
13:59 < jrandom> should people register & hack on the wiki, email, post on the forum?
13:59 < jrandom> oh, perhaps we can get cervantes to add a new forum category?
13:59 < frosk> i think actually a forum would be very nice at this point
14:00 < frosk> for more private discussion, you can email us both at ku@mail.i2p and frosk@mail.i2p
14:01 < cervantes> hrrrm ... are you going to put game reviews in it?
14:01 < jrandom> heh
14:01 < jrandom> w3rd
14:01 < cervantes> because if not...then you're welcome to have a new forum section
14:01 < frosk> i was thinking top20 music reviews, cervantes
14:02 < jrandom> (btw, mirror of the call for comments @ http://dev.i2p.net/~jrandom/feedspace.txt)
14:02 < cervantes> :)
14:04 < cervantes> frosk: feedspace or feed space or Feedspace or Feed Space or FeedSpace?
14:04 < frosk> cervantes: Feedspace
14:05 < frosk> looking forward to much discussion over at the forum then :) i don't have anything else for this point, anyone else?
14:05 < jrandom> ok cool, thanks for the update frosk
14:06 <@smeghead> or FEeDspace?
14:06 < ant> <cervantes> frosk: when you have a moment, just pm me a one liner description for the forum section
14:06 < legion> hmm speaking of new forums, lol. I'm putting a new forum site together. Though I have much hacking left to do on the phpbb code, it should be finshed sometime this week. ;)
14:06 < jrandom> cool legion
14:06 < jrandom> that actually brings us into 3) ??? nicely
14:06 < jrandom> anyone have anything else to bring up?
14:06 < jrandom> aum: any updates on Q?
14:07 < frosk> i, uhm, no
14:07 < ant> <aum> Q devlt is moving along nicely, nothing to announce atm
14:07 < jrandom> w3rd
14:07 < ant> * aum is 90% complete with net.i2p.i2ptunnel.I2PTunnelXMLServer
14:07 < ant> <BS314159> I have a simple question about netDb
14:07 < ant> <aum> everything's working now except 'i2p.tunnel.close'
14:07 < legion> my forums will allow for members to have decent sized avatars, discuss shared content, just about whatever.
14:08 < jrandom> wikked
14:08 < ant> <BS314159> it says on the page that entries are stores on the peers closest to SHA256(router identity + YYYYMMdd)
14:08 < jrandom> right BSpi
14:08 <@smeghead> legion: will it be as much a security hazard as your bt client?
14:08 < ant> <BS314159> does this mean there's a burst of traffic every 00:00 GMT?
14:08 < ant> * aum is actually gaining some fluency in java, having attained a 'cognitive critical mass'
14:09 < jrandom> BS: data points expire more frequently than they migrate
14:09 < jrandom> a LeaseSet is only good for 10 minutes, for example
14:09 < bla> jrandom: Is there a command-line call I can make, such that I can speed estimates of each of the peers in the net over the last, say, 60 seconds, or so?
14:09 < legion> lol, forums a security hazard?
14:10 <@smeghead> legion: yes, and if you don't know that much, i'm already convinced that your forums will be a security hazard
14:10 < jrandom> bla: yeah, java -cp lib/i2p.jar:lib/router.jar -Djava.library.path=. net.i2p.router.peermanager.ProfileOrganizer peerProfiles/*
14:10 < jrandom> (i think)
14:10 < legion> oh and the next release of my bt client shouldn't cause such issues...
14:10 < jrandom> you may need to add some log levels to logger.config, lemmie check
14:10 <@smeghead> legion: Cervantes made a ton of modifications to phpBB to lock it down for i2p use
14:10 < ant> <BS314159> It just seems like having it occur all-at-once at a specified time is awkward. If it were happening continuously, that would seem...smoother. It would also give an attacker less time to mount an attack, since bits of the data would be wrong in less than 24 hours
14:11 < jrandom> nah, it dumps to stdout
14:11 < frosk> jrandom: how do you feel about the i2p roadmap currently, if one may ask? do you think it's realistic?
14:11 < legion> Hmm I wonder if I can get a copy of cervantes mods?
14:11 < jrandom> frosk: i update it when i become uncomfortable with it
14:12 < frosk> ok
14:12 <+detonate> you know, there's a windows installer for python 2.4, one for wxpython, and there's the i2p-bt tarball, i don't really see why anyone would get/trust a third-party release
14:12 < legion> Otherwise I'll just have to continue to hack on the phpbb source myself...
14:12 < jrandom> BS: peers would only look in the wrong place for up to 30s, due to clock synchronization
14:12 <@smeghead> legion: have fun
14:12 < legion> well why would anyone get and use kazaa?
14:13 < bla> jrandom: I'm asking, because...
14:13 < legion> Or morpheus?
14:13 < jrandom> (because they dont know better?)
14:13 < legion> Both of those contain adware/etc...
14:13 <+detonate> they are ignorant?
14:14 < legion> yeah and there are millions of ignorant users out there. ;)
14:14 < ant> <BS314159> legion: you sound like you want to bundle spyware with I2P. Truly, a stroke of genius.
14:14 < bla> jrandom: ...I browsed SpeedCalculator.java and CapacityCalculator.java, and I'd like to experiment with the estimators
14:14 < cervantes> legion: stay uptodate with official patches, and put htaccess on the admin areas
14:14 < jrandom> wikked bla
14:14 < legion> What? Heck no... I hate malware...
14:14 < cervantes> most of my mods involve spam prevention
14:14 < ant> <aum> can i raise a more critical issue?
14:14 < legion> That's it? cervantes?
14:15 < jrandom> sup aum?
14:15 <@smeghead> legion: what about your users that also hate malware? why do you do nothing to alleviate any concerns they might have?
14:15 < ant> <dm> BS314159: are you a windows hotfix?
14:15 < ant> <aum> is it just me, or is there still some flakiness going on with in i2p? i'm having heaps of trouble with even main eepsites, irc etc
14:15 < bla> jrandom: In addition, the idea of "passive fingerprinting" is now in my head (a bit ;): If I receive data through a tunnel, this tells me something about the bandwidth/capacity of all the peers in that tunnel:...
14:15 < jrandom> aum: see the weekly status notes
14:16 < cervantes> legion: rename all registration, login , posting and profile editing pages to something non-standard
14:16 < bla> jrandom: It tells me some about the peer closest to me, somewhat less about the peers one step away, and so progressively less.
14:16 < cervantes> will help keep worms at bay
14:16 < jrandom> bla: aye, i read that timing paper, and yesterday's tor attack paper with much interest
14:17 < Myo9> Cervantes, releasing ant of your mods?
14:17 < Myo9> s/ant/any/
14:17 < jrandom> there is worry along those lines in the capacity calculator with the different tiers of rejection
14:18 < bla> jrandom: In a way, this gives me some degree of "belief" in a peers bandwidth/capacity (that degree of belief depends on the distance to each of the tunnel members, and on the amount of belief I have on the BW/cap. of the nodes closest to me)
14:18 < legion> thanks for the advice cervantes :)
14:18 < bla> jrandom: Now, I happen to know some ppl that know a lot about Bayesian Belief Networks... ;))
14:18 <@smeghead> again, legion ignores the question
14:18 <+thetower> I think we're all gonna have to call a truce with legion and let him write whatever he wants, its not like anyone is forced to use it.
14:18 < jrandom> hmm, what do you mean by distance bla?
14:18 < ant> <dm> what is legion up to?
14:19 < bla> jrandom: I'll have a chat with them, regarding passive fingerprinting (note: I do not mean "fingerprinting" in the negative sense of the word)
14:19 < jrandom> wikked
14:19 < jrandom> suggestions as to how we can best select 'quality' peers are very much welcome
14:19 < cervantes> Myo9: I certainly could do.
14:19 < legion> Anyways there isn't many i2p windows users just yet and not that many running my i2p-bt binary distribution. Soon my next release will be done and released, it will not have such issues... As there will be a binary and source distribution.
14:19 <@smeghead> why anyone would want to use software from someone who doesn't even take the most basic measures to address users' concerns about security and anonymity is beyond me
14:20 < ant> <aum> frosk: what lang you writing feedspace in? (forgive me if i asked you before)
14:20 < cervantes> it's not a clean "patch" or anything though
14:20 < bla> jrandom: distance... Say I have an inbound tunnel X -> Y -> me, and I know a _lot_ about Y's properties, than stats on what I receive thru that tunnel tells me a good deal about X
14:20 < frosk> aum: java (and i forgive you ;)
14:20 < cervantes> I've just been fixing stuff andproblems as it arises
14:20 < bla> jrandom: OTOH, if I have little data/belief on Y's properties, transfer stats don't tell me much about X yet; I first have more to learn about Y
14:20 < cervantes> as they
14:20 < jrandom> bla: its very hard to tell whether lag or congestion occurs @ X or Y (or earlier hops)
14:20 < cervantes> http://forum.i2p/index.php?c=4
14:21 < cervantes> new section: Feedspace
14:21 < jrandom> w00t
14:21 < frosk> yay
14:22 < legion> anyways enough discussion about my release, any further discussion about it should be done in the #itorrent channel
14:22 < bla> jrandom: That is true. However, given large amount of data (and hoping that the measurement time is not _much_ larger than the timescale on which node properties change), I'm convinced there _must_ be information in traffic/tunnel stats
14:22 <@smeghead> legion: we can discuss in meeting point # 3) any business that affects i2p
14:23 <@smeghead> legion: and i think your software is of serious concern and warrants a warning to users
14:23 < legion> yeah, ok
14:23 < jrandom> bla: certainly, we just need to rope in the RTT from the OutboundClientMessageOneShotJob
14:23 < jrandom> (and then figure out how best to calculate & decay the data)
14:24 < legion> So smeghead if you were to make such a release, what would you do differently?
14:24 <@smeghead> legion: the way you continually dodge questions and try to defer discussion on the subject is very disconcerting
14:25 <@smeghead> legion: first of all, release the source to your current binary, no matter if it's "just i2p-bt with smeghead's patch", and have a writeup on your site explaining about your fork
14:25 < bla> jrandom: What does the RTT signify there?
14:26 <@smeghead> legion: it would be helpful to do as i2p-bt does also, and make a changelog indicating all the modifications you've made
14:27 < jrandom> bla: end to end client messages are often (by default, always) bundled in garlic wrapping, containing an additional DeliveryStatusMessage that returns to the sender (through tunnels, of course), allowing the use of AES+sessionTags instead of ElGamal
14:28 < bla> jrandom: (yes)
14:28 <+detonate> as i said, you could just provide a link to the download page for the three things you need for i2p-bt to work, it's straight-forward and gets you exactly the same thing, i can't actually see a use for it besides a trojan
14:28 < jrandom> later on we'll update I2CP (and the SDK) to allow the streaming lib to deliver that same data without requiring the DeliveryStatusMessage
14:29 <@smeghead> detonate: i agree, he should have just submitted a patch to the official i2p-bt in the first place, forking was completely unnecessary and fostered immediate suspicioun
14:30 <+detonate> indeed
14:30 <@smeghead> *suspicion
14:31 < jrandom> ok, anyone else have anything to bring up for the meeting?
14:31 < ant> <drakoh> hi people ! wanted to know, is there anything special with the network ?
14:32 <@smeghead> because of the nature of i2p, applications developed for it require a greater measure of openness with end users and cooperation among developers
14:32 < jrandom> drakoh: see the weekly status notes
14:32 < bla> quit
14:32 < ant> <drakoh> no I mean something strange ...
14:32 <@smeghead> i2p users will always be naturally paranoid to some extent, and it's our duty to do what we can to dispel any concerns we possibly can
14:32 < ant> <drakoh> like I lost all my peers
14:33 < jrandom> aye, agreed smeghead. for anonymity or security software, especially software dealing with a trojan-laden field such as filesharing, its critical to be open.
14:33 < jrandom> drakoh: ok, hold on, we can debug that once the meeting is over
14:33 < ant> <drakoh> woops sorry
14:33 < jrandom> ok, speaking of the meeting being over...
14:34 * jrandom winds up
14:34 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/133.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, March 15, 2005
===============================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,177 +1,171 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 134{% endblock %}
{% block content %}<h3>I2P dev meeting, March 22, 2005</h3>
<div class="irclog">
13:01 <@jrandom> 0) hi</p>
13:01 <@jrandom> 1) 0.5.0.3</p>
13:01 <@jrandom> 2) batching</p>
13:01 <@jrandom> 3) updating</p>
13:01 <@jrandom> 4) ???</p>
13:01 <@jrandom> 0) hi</p>
13:01 * jrandom waves</p>
13:01 <@jrandom> the just-now-posted weekly status notes are up @ http://dev.i2p.net/pipermail/i2p/2005-March/000654.html</p>
13:02 <+detonate> hi</p>
13:02 <+cervantes> 'lo</p>
13:02 <@jrandom> jumpin' right in to 1) 0.5.0.3</p>
13:02 <@jrandom> the release came out a few days ago, and reports have been positive</p>
13:02 <+cervantes> jrandom: let us know when the blue dancing dwarves climb onto your monitor and we'll stop the meeting early</p>
13:03 <@jrandom> heh cervantes </p>
13:03 <@jrandom> (thank Bob for editable meeting logs ;)</p>
13:04 <@jrandom> i dont really have much to add wrt 0.5.0.3 than whats in that message</p>
13:04 <@jrandom> anyone have any comments/questions/concerns on it?</p>
13:04 < bla> jrandom: Any new measurements on the fast-peers-selection code?</p>
13:05 <@jrandom> ah, i knew there was something else in 0.5.0.3 that i had neglected ;)</p>
13:06 <@jrandom> i dont have any hard metrics yet, but anecdotally the fast peer selection has found the peers that i know explicitly to be 'fast' (e.g. routers on the same box, etc)</p>
13:07 < bla> jrandom: Sometimes, eepsites still require a number of retries to find a good tunnel to use</p>
13:07 <@jrandom> reports have come in for fairly reasonable throughput rates on occation as well (in the 10-20KBps range), but thats still not frequent (we still have the parameters tuned down)</p>
13:08 <+ant> &lt;Connelly&gt; oops there's a meeting</p>
13:09 <@jrandom> hmm, yes, i've found that reliability still isn't where it need to be. retrying more than once really isn't a solution though - if a site doesnt load after 1 retry, give it 5-10m before retrying</p>
13:09 <@jrandom> what i've seen on the net though is some not-infrequent-enough transport layer delay spikes</p>
13:10 <@jrandom> e.g. taking 5-20+ seconds just to flush a 1-2KB message through a socket</p>
13:10 <@jrandom> tie that up with a 5 hop path (2 hop tunnels) and you can run into trouble</p>
13:11 <@jrandom> thats actually part of whats driving the batching code - reducing the # of messages to be sent</p>
13:13 <@jrandom> ok, anyone else have any questions/comments/concerns on 0.5.0.3?</p>
13:13 < bla> jrandom: Looks good. I will ask more about it in the next "section"</p>
13:14 <@jrandom> w3rd, ok, perhaps we can move on there then - 2) batching</p>
13:15 <@jrandom> the email and my blog (jrandom.dev.i2p&lt;/spam&gt;) should describe the basics of whats planned</p>
13:15 <@jrandom> and, well, really its some pretty basic stuff</p>
13:15 <@jrandom> the current preprocessor we have was the simplest possible one to implement (class name: TrivialPreprocessor) ;)</p>
13:16 <@jrandom> this new one has some tunable parameters for batching frequency, as well as some outbound tunnel affinity within individual tunnel pools (where we try to select the same outbound tunnel for subsequent requests for up to e.g. 500ms, so that we can optimize the batching)</p>
13:17 <@jrandom> that's about all i have to add on that though - any questions/comments/concerns? </p>
13:18 < bla> Does this require all participating nodes to run the new preprocessor, or can a mix of Trivial/NewOne coexist?</p>
13:18 <+Ragnarok> this will add .5 s to latency, right?</p>
13:19 <@jrandom> bla: nah, this preprocessor is only used on the tunnel gateway, and its up to that gateway to decide how or whether to batch</p>
13:20 <@jrandom> Ragnarok: not usually - message 1 may be delayed for up to .5s, but messages 2-15 get transferred much faster than they would have otherwise. its also a simple threshold - as soon as a full tunnel message worth of data is available, its flushed</p>
13:20 <+Ragnarok> cool</p>
13:20 <+Ragnarok> how much overhead does it save?</p>
13:21 <@jrandom> substantial ;)</p>
13:21 <+Ragnarok> substantial is good, if vague :P</p>
13:21 <@jrandom> look on your http://localhost:7657/oldstats.jsp#tunnel.smallFragments</p>
13:21 <@jrandom> compare that to #tunnel.fullFragments</p>
13:22 < bla> jrandom: Does this concern endpoint-&gt;IB-gateway communication only? </p>
13:22 <@jrandom> with batching, the ratio of full to small will go up, and the # of pad bytes in the small will go down</p>
13:23 <@jrandom> bla: hmm, it concerns all tunnel gateways, whether inbound or outbound</p>
13:24 < mihi> full fragments: lifetime average value: 1,00 over 1.621,00 events</p>
13:24 < bla> jrandom: ok</p>
13:24 < mihi> can there be a frational number of fragments?</p>
13:24 <@jrandom> full: 1.00 over 807,077.00 events small: 746.80 over 692,682.00 events</p>
13:25 <@jrandom> heh mihi</p>
13:25 <@jrandom> (that small: 746 means that on those 692k messages, 746 out of 996 bytes were wasted pad bytes!)</p>
13:26 <@jrandom> well, not quite wasted - they served their purpose</p>
13:26 <+detonate> needless overhead anyway</p>
13:27 <@jrandom> yep, much of which we should be able to shed with the batching preprocessor</p>
13:28 <@jrandom> unfortunately, that won't be bundled in the next release</p>
13:28 <@jrandom> but it will be bundled in the 0.5.0.6 rev (or perhaps 0.5.1)</p>
13:28 <@jrandom> erm, 0.5.0.5, or 0.5.1</p>
13:28 * jrandom gets confused with #s</p>
13:29 < bla> jrandom: How come not?</p>
13:29 <+cervantes> hash and pills...damn</p>
13:30 <@jrandom> !thwap cervantes </p>
13:30 <@jrandom> bla: there's a bug in 0.5.0.3 (and before) where the fragmented message handler will cause subsequent fragments within the same tunnel message to be discarded</p>
13:31 <@jrandom> if we deployed the batching preprocessor directly, we'd have a substantial number of lost messages</p>
13:31 <@jrandom> its not a worry, we've got other neat stuff up our sleeves though, so this coming 0.5.0.4 won't be totally boring ;)</p>
13:31 < bla> jrandom: Ah, so that</p>
13:32 < bla> jrandom: Ah, so that is why we have to do that after 0.5.0.4 is mainstream.. I see. Thnx.</p>
13:33 <@jrandom> yeah, it'd be nice if the fragment handler was able to deal with it, and it does, generally, it just releases the byte buffer too soon, zeroing out subsequent fragments (oops)</p>
13:33 <@jrandom> ok, anything else on 2), or shall we move on to 3) updating?</p>
13:35 <@jrandom> ok, as mentioned in the status notes (and discussed for a while in various venues), we're going to add some functionality for simple and safe updating that doesn't require the end user to go to the website, read the mailing list, or read the topic in the channel :)</p>
13:36 <+detonate> cool</p>
13:36 <@jrandom> smeghead has put together some code to help automate and secure the process, working with cervantes to tie in with fire2pe as well as the normal routerconsole</p>
13:37 <@jrandom> the email lists the general description of whats going to be available, and while most of it is functional, there are still a few pieces not yet fully hashed out</p>
13:37 <@jrandom> unlike the batching, this /will/ be available in the next rev, though people won't be able to make much use of it until 0.5.0.5 (when it comes time to update)</p>
13:39 <+Ragnarok> so... what's the cool stuff for 5.0.4, then?</p>
13:42 <@jrandom> with the update code comes the ability to pull announcement data, displaying e.g. a snippet of news on the top of the router console. in addition to that, as part of the update code we've got a new reliable download component which works either directly or through the eepproxy, retrying and continuing along the way. perhaps there'll be some relatd features built off that, but no promises</p>
13:42 <+Ragnarok> neat</p>
13:43 <@jrandom> ok, anyone else have any questions/comments/concerns on 3) updating?</p>
13:45 <@jrandom> if not, moving on to 4) ???</p>
13:45 <@jrandom> anything else anyone wants to bring up? i'm sure i've missed soem things</p>
13:45 <+detonate> i2p's known to work with the sun jvm in OpenBSD 3.7 :)</p>
13:45 <@jrandom> nice!</p>
13:47 < bla> What is the status on the UDP transport?</p>
13:48 <+detonate> udp is going to be messy, i think it would be better to steal the pipelining code from bt and adapt it ;)</p>
13:48 <@jrandom> *cough*</p>
13:49 <@jrandom> i dont expect there to be much trouble, but there's certainly work to be done</p>
13:49 <@jrandom> how the queueing policy operates, as well as the bw throttling for admission to the queue will be interesting</p>
13:50 < bla> Who was doing that prelim work?</p>
13:50 <@jrandom> bla: detonate and mule</p>
13:50 <+detonate> yeah.. i've been slacking off the last month or so though</p>
13:50 < bla> detonate: I assume you jest, with your BT remark?</p>
13:51 <+detonate> i'm half-serious</p>
13:51 <+detonate> you could at least cut the thread count for the transport in half if you did that</p>
13:51 * jrandom flings a bucket of mud at detonate </p>
13:51 < jdot> woohoo. my router is now running on my dedicated server rather than my POS cable connection.</p>
13:51 <@jrandom> nice1 jdot </p>
13:52 <@jrandom> we'll be able to get by with 3-5 threads in the transport layer for all comm with all peers</p>
13:52 < bla> detonate: But half is not going to cut it, when the net becomes large (&gt; couple hundred nodes)</p>
13:52 < jdot> with 1000GB of b/w at its disposal</p>
13:53 < jdot> unforunately j.i2p and the chat.i2p will be down for a few more hours while i migrate things</p>
13:53 < duck> detonate: addressbook on halt too?</p>
13:53 <+detonate> yeah, it's on halt too</p>
13:54 <+detonate> the only thing that isn't on halt is the monolithic profile storage, i was meaning to get that working later today</p>
13:54 <@jrandom> w3rd</p>
13:54 <+detonate> then i2p won't fragment the drive massively</p>
13:54 < jdot> jrandom: as far as BW limits go, are they averages?</p>
13:54 <+frosk> modern filesystems don't fragment, silly</p>
13:55 <+detonate> ntfs does</p>
13:55 <@jrandom> jdot: the bandwidth limits are strict token buckets</p>
13:55 <@jrandom> jdot: if you set the burst duration out, thats how long of a period it averages out through</p>
13:56 <@jrandom> (well, 2x burst == period)</p>
13:56 <@jrandom> ((ish))</p>
13:56 < jdot> hmmm... well i have 1000GB and want i2p to be able to take up to 800GB/mo....</p>
13:56 <+ant> &lt;mihi&gt; detonate: ntfs stores really small files in mft which means nealy no fragmentation</p>
13:57 < jdot> and i dont care what it bursts to</p>
13:57 <+detonate> well, when you run the defragmenter, it spends 10 minutes moving all 6000 profiles around.. so they must fragment</p>
13:58 <@jrandom> jdot: hmm, well, 800GB is probably more than it'll want to push anyway, so you can probably go without limits ;) </p>
13:58 <@jrandom> otoh, if you could describe a policy that you'd like implemented, we might be able to handle it</p>
13:58 < jdot> jrandom: i'll do that for now and see how it works</p>
13:58 < bla> detonate: NTFS, IIRC, is a journalling FS. So even a monolotic file will get fragmented if you write small portions to it </p>
13:58 <+detonate> everything gets written at once</p>
13:59 <+detonate> and read at once</p>
13:59 < bla> detonate: Ok. I see.</p>
13:59 < jdot> jrandom: well, lets wait until we figure out if it'll even be a problem.</p>
13:59 < bla> detonate: Good work in that case!</p>
13:59 <+detonate> i'd be interested in knowing how much usage there really is if you leave it uncapped</p>
14:00 <+detonate> on a good connection</p>
14:00 < jdot> i'm interested too!</p>
14:00 <@jrandom> my colo routers run uncapped, though cpu constrained</p>
14:00 <+Ragnarok> can you use a bitbucket to average over a month?</p>
14:00 < jdot> jrandom: cpu contrianed? what kind of cpu?</p>
14:01 <@jrandom> 4d transfer 3.04GB/2.73GB</p>
14:01 <+detonate> hmm, was expecting less</p>
14:01 <@jrandom> jdot: cpu constrained because i run 3 routers on it, plus a few other jvms, sometimes profiling</p>
14:01 <+detonate> must be those bt people</p>
14:01 <+detonate> once the batching stuff is online, it would be interesting to see how that changes</p>
14:02 <@jrandom> detonate: some of that transfer is also me pushing 50MB files between itself ;)</p>
14:02 <+detonate> heh</p>
14:02 < jdot> ahh. ok. well, we'll see how this system does. its an AMD XP 2400 w/ 512MB and a 10Mbit connection</p>
14:02 <@jrandom> Ragnarok: token buckets dont really work that way</p>
14:02 <@jrandom> jdot: word, yeah, this is a p4 1.6 iirc</p>
14:03 <@jrandom> Ragnarok: in a token bucket, every (e.g.) second you add in some tokens, according to the rate. if the bucket is full (size = burst period), the tokens are discarded</p>
14:04 <@jrandom> whenever you want to transfer data, you need to get a sufficient amount of tokens</p>
14:04 <@jrandom> (1 token = 1 byte)</p>
14:04 <+Ragnarok> I know how they work... what happens if you just make the bucket really big?</p>
14:05 <+detonate> then you never stop sending data</p>
14:05 <+detonate> if it's infinite in size</p>
14:05 <+detonate> err, and it's filled with tokens</p>
14:05 <@jrandom> if its really big, it may go out and burst to unlimited rates after low usage</p>
14:06 <@jrandom> though perhaps thats desired in some cases</p>
14:07 <@jrandom> the thing is, you can't just set the token bucket to 800GB, as that wouldnt constrain the total amount transferred</p>
14:08 <+detonate> you need a field there where you can set the number of tokens per second, then you can just divide the bandwidth usage per month by the number of seconds</p>
14:08 <+detonate> :)</p>
14:10 <@jrandom> thats the same as just setting the rate averaged over the month, which would be unbalanced. but, anyway, lots of scenarios available - if anyone has any that address their needs that can't be met with whats available, please, get in touch</p>
14:10 <+Ragnarok> but if you set the rate to the average you want... I think 308 kB/s here, and then set the bitbucket to something very larger... why doesn't that work?</p>
14:11 <+Ragnarok> s/larger/large/</p>
14:12 <+detonate> well, you could set it so that it never sends more than 800GB/44000 in a 60 second burst period</p>
14:12 <+detonate> 44000 being roughly the number of minutes in a month</p>
14:13 <@jrandom> the bucket size / burst duration describes how much we'll send without constraint, and most people /do/ want constraints, so the router doesnt gobble 10mbps for 5 minutes while draining the bucket (or whatever)</p>
14:14 <@jrandom> an additional throttle of tokens coming out of the bucket is also possible (and should that throttle have its own token bucket, and that bucket have its own throttle, etc)</p>
14:16 <+Ragnarok> I thought the bucket only got paid into when there was bandwidth not being used</p>
14:16 <@jrandom> tokens are added to the bucket at a constant rate (e.g. 64k tokens per second)</p>
14:17 <@jrandom> anything that wants bandwidth always asks the bucket</p>
14:18 <+Ragnarok> ah.. ok</p>
14:19 <@jrandom> ok cool, anyone else have anything they want to bring up for the meeting?</p>
14:21 <@jrandom> ok if not</p>
14:21 * jrandom winds up</p>
14:21 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:01 <@jrandom> 0) hi
13:01 <@jrandom> 1) 0.5.0.3
13:01 <@jrandom> 2) batching
13:01 <@jrandom> 3) updating
13:01 <@jrandom> 4) ???
13:01 <@jrandom> 0) hi
13:01 * jrandom waves
13:01 <@jrandom> the just-now-posted weekly status notes are up @ http://dev.i2p.net/pipermail/i2p/2005-March/000654.html
13:02 <+detonate> hi
13:02 <+cervantes> 'lo
13:02 <@jrandom> jumpin' right in to 1) 0.5.0.3
13:02 <@jrandom> the release came out a few days ago, and reports have been positive
13:02 <+cervantes> jrandom: let us know when the blue dancing dwarves climb onto your monitor and we'll stop the meeting early
13:03 <@jrandom> heh cervantes
13:03 <@jrandom> (thank Bob for editable meeting logs ;)
13:04 <@jrandom> i dont really have much to add wrt 0.5.0.3 than whats in that message
13:04 <@jrandom> anyone have any comments/questions/concerns on it?
13:04 < bla> jrandom: Any new measurements on the fast-peers-selection code?
13:05 <@jrandom> ah, i knew there was something else in 0.5.0.3 that i had neglected ;)
13:06 <@jrandom> i dont have any hard metrics yet, but anecdotally the fast peer selection has found the peers that i know explicitly to be 'fast' (e.g. routers on the same box, etc)
13:07 < bla> jrandom: Sometimes, eepsites still require a number of retries to find a good tunnel to use
13:07 <@jrandom> reports have come in for fairly reasonable throughput rates on occation as well (in the 10-20KBps range), but thats still not frequent (we still have the parameters tuned down)
13:08 <+ant> <Connelly> oops there's a meeting
13:09 <@jrandom> hmm, yes, i've found that reliability still isn't where it need to be. retrying more than once really isn't a solution though - if a site doesnt load after 1 retry, give it 5-10m before retrying
13:09 <@jrandom> what i've seen on the net though is some not-infrequent-enough transport layer delay spikes
13:10 <@jrandom> e.g. taking 5-20+ seconds just to flush a 1-2KB message through a socket
13:10 <@jrandom> tie that up with a 5 hop path (2 hop tunnels) and you can run into trouble
13:11 <@jrandom> thats actually part of whats driving the batching code - reducing the # of messages to be sent
13:13 <@jrandom> ok, anyone else have any questions/comments/concerns on 0.5.0.3?
13:13 < bla> jrandom: Looks good. I will ask more about it in the next "section"
13:14 <@jrandom> w3rd, ok, perhaps we can move on there then - 2) batching
13:15 <@jrandom> the email and my blog (jrandom.dev.i2p</spam>) should describe the basics of whats planned
13:15 <@jrandom> and, well, really its some pretty basic stuff
13:15 <@jrandom> the current preprocessor we have was the simplest possible one to implement (class name: TrivialPreprocessor) ;)
13:16 <@jrandom> this new one has some tunable parameters for batching frequency, as well as some outbound tunnel affinity within individual tunnel pools (where we try to select the same outbound tunnel for subsequent requests for up to e.g. 500ms, so that we can optimize the batching)
13:17 <@jrandom> that's about all i have to add on that though - any questions/comments/concerns?
13:18 < bla> Does this require all participating nodes to run the new preprocessor, or can a mix of Trivial/NewOne coexist?
13:18 <+Ragnarok> this will add .5 s to latency, right?
13:19 <@jrandom> bla: nah, this preprocessor is only used on the tunnel gateway, and its up to that gateway to decide how or whether to batch
13:20 <@jrandom> Ragnarok: not usually - message 1 may be delayed for up to .5s, but messages 2-15 get transferred much faster than they would have otherwise. its also a simple threshold - as soon as a full tunnel message worth of data is available, its flushed
13:20 <+Ragnarok> cool
13:20 <+Ragnarok> how much overhead does it save?
13:21 <@jrandom> substantial ;)
13:21 <+Ragnarok> substantial is good, if vague :P
13:21 <@jrandom> look on your http://localhost:7657/oldstats.jsp#tunnel.smallFragments
13:21 <@jrandom> compare that to #tunnel.fullFragments
13:22 < bla> jrandom: Does this concern endpoint->IB-gateway communication only?
13:22 <@jrandom> with batching, the ratio of full to small will go up, and the # of pad bytes in the small will go down
13:23 <@jrandom> bla: hmm, it concerns all tunnel gateways, whether inbound or outbound
13:24 < mihi> full fragments: lifetime average value: 1,00 over 1.621,00 events
13:24 < bla> jrandom: ok
13:24 < mihi> can there be a frational number of fragments?
13:24 <@jrandom> full: 1.00 over 807,077.00 events small: 746.80 over 692,682.00 events
13:25 <@jrandom> heh mihi
13:25 <@jrandom> (that small: 746 means that on those 692k messages, 746 out of 996 bytes were wasted pad bytes!)
13:26 <@jrandom> well, not quite wasted - they served their purpose
13:26 <+detonate> needless overhead anyway
13:27 <@jrandom> yep, much of which we should be able to shed with the batching preprocessor
13:28 <@jrandom> unfortunately, that won't be bundled in the next release
13:28 <@jrandom> but it will be bundled in the 0.5.0.6 rev (or perhaps 0.5.1)
13:28 <@jrandom> erm, 0.5.0.5, or 0.5.1
13:28 * jrandom gets confused with #s
13:29 < bla> jrandom: How come not?
13:29 <+cervantes> hash and pills...damn
13:30 <@jrandom> !thwap cervantes
13:30 <@jrandom> bla: there's a bug in 0.5.0.3 (and before) where the fragmented message handler will cause subsequent fragments within the same tunnel message to be discarded
13:31 <@jrandom> if we deployed the batching preprocessor directly, we'd have a substantial number of lost messages
13:31 <@jrandom> its not a worry, we've got other neat stuff up our sleeves though, so this coming 0.5.0.4 won't be totally boring ;)
13:31 < bla> jrandom: Ah, so that
13:32 < bla> jrandom: Ah, so that is why we have to do that after 0.5.0.4 is mainstream.. I see. Thnx.
13:33 <@jrandom> yeah, it'd be nice if the fragment handler was able to deal with it, and it does, generally, it just releases the byte buffer too soon, zeroing out subsequent fragments (oops)
13:33 <@jrandom> ok, anything else on 2), or shall we move on to 3) updating?
13:35 <@jrandom> ok, as mentioned in the status notes (and discussed for a while in various venues), we're going to add some functionality for simple and safe updating that doesn't require the end user to go to the website, read the mailing list, or read the topic in the channel :)
13:36 <+detonate> cool
13:36 <@jrandom> smeghead has put together some code to help automate and secure the process, working with cervantes to tie in with fire2pe as well as the normal routerconsole
13:37 <@jrandom> the email lists the general description of whats going to be available, and while most of it is functional, there are still a few pieces not yet fully hashed out
13:37 <@jrandom> unlike the batching, this /will/ be available in the next rev, though people won't be able to make much use of it until 0.5.0.5 (when it comes time to update)
13:39 <+Ragnarok> so... what's the cool stuff for 5.0.4, then?
13:42 <@jrandom> with the update code comes the ability to pull announcement data, displaying e.g. a snippet of news on the top of the router console. in addition to that, as part of the update code we've got a new reliable download component which works either directly or through the eepproxy, retrying and continuing along the way. perhaps there'll be some relatd features built off that, but no promises
13:42 <+Ragnarok> neat
13:43 <@jrandom> ok, anyone else have any questions/comments/concerns on 3) updating?
13:45 <@jrandom> if not, moving on to 4) ???
13:45 <@jrandom> anything else anyone wants to bring up? i'm sure i've missed soem things
13:45 <+detonate> i2p's known to work with the sun jvm in OpenBSD 3.7 :)
13:45 <@jrandom> nice!
13:47 < bla> What is the status on the UDP transport?
13:48 <+detonate> udp is going to be messy, i think it would be better to steal the pipelining code from bt and adapt it ;)
13:48 <@jrandom> *cough*
13:49 <@jrandom> i dont expect there to be much trouble, but there's certainly work to be done
13:49 <@jrandom> how the queueing policy operates, as well as the bw throttling for admission to the queue will be interesting
13:50 < bla> Who was doing that prelim work?
13:50 <@jrandom> bla: detonate and mule
13:50 <+detonate> yeah.. i've been slacking off the last month or so though
13:50 < bla> detonate: I assume you jest, with your BT remark?
13:51 <+detonate> i'm half-serious
13:51 <+detonate> you could at least cut the thread count for the transport in half if you did that
13:51 * jrandom flings a bucket of mud at detonate
13:51 < jdot> woohoo. my router is now running on my dedicated server rather than my POS cable connection.
13:51 <@jrandom> nice1 jdot
13:52 <@jrandom> we'll be able to get by with 3-5 threads in the transport layer for all comm with all peers
13:52 < bla> detonate: But half is not going to cut it, when the net becomes large (> couple hundred nodes)
13:52 < jdot> with 1000GB of b/w at its disposal
13:53 < jdot> unforunately j.i2p and the chat.i2p will be down for a few more hours while i migrate things
13:53 < duck> detonate: addressbook on halt too?
13:53 <+detonate> yeah, it's on halt too
13:54 <+detonate> the only thing that isn't on halt is the monolithic profile storage, i was meaning to get that working later today
13:54 <@jrandom> w3rd
13:54 <+detonate> then i2p won't fragment the drive massively
13:54 < jdot> jrandom: as far as BW limits go, are they averages?
13:54 <+frosk> modern filesystems don't fragment, silly
13:55 <+detonate> ntfs does
13:55 <@jrandom> jdot: the bandwidth limits are strict token buckets
13:55 <@jrandom> jdot: if you set the burst duration out, thats how long of a period it averages out through
13:56 <@jrandom> (well, 2x burst == period)
13:56 <@jrandom> ((ish))
13:56 < jdot> hmmm... well i have 1000GB and want i2p to be able to take up to 800GB/mo....
13:56 <+ant> <mihi> detonate: ntfs stores really small files in mft which means nealy no fragmentation
13:57 < jdot> and i dont care what it bursts to
13:57 <+detonate> well, when you run the defragmenter, it spends 10 minutes moving all 6000 profiles around.. so they must fragment
13:58 <@jrandom> jdot: hmm, well, 800GB is probably more than it'll want to push anyway, so you can probably go without limits ;)
13:58 <@jrandom> otoh, if you could describe a policy that you'd like implemented, we might be able to handle it
13:58 < jdot> jrandom: i'll do that for now and see how it works
13:58 < bla> detonate: NTFS, IIRC, is a journalling FS. So even a monolotic file will get fragmented if you write small portions to it
13:58 <+detonate> everything gets written at once
13:59 <+detonate> and read at once
13:59 < bla> detonate: Ok. I see.
13:59 < jdot> jrandom: well, lets wait until we figure out if it'll even be a problem.
13:59 < bla> detonate: Good work in that case!
13:59 <+detonate> i'd be interested in knowing how much usage there really is if you leave it uncapped
14:00 <+detonate> on a good connection
14:00 < jdot> i'm interested too!
14:00 <@jrandom> my colo routers run uncapped, though cpu constrained
14:00 <+Ragnarok> can you use a bitbucket to average over a month?
14:00 < jdot> jrandom: cpu contrianed? what kind of cpu?
14:01 <@jrandom> 4d transfer 3.04GB/2.73GB
14:01 <+detonate> hmm, was expecting less
14:01 <@jrandom> jdot: cpu constrained because i run 3 routers on it, plus a few other jvms, sometimes profiling
14:01 <+detonate> must be those bt people
14:01 <+detonate> once the batching stuff is online, it would be interesting to see how that changes
14:02 <@jrandom> detonate: some of that transfer is also me pushing 50MB files between itself ;)
14:02 <+detonate> heh
14:02 < jdot> ahh. ok. well, we'll see how this system does. its an AMD XP 2400 w/ 512MB and a 10Mbit connection
14:02 <@jrandom> Ragnarok: token buckets dont really work that way
14:02 <@jrandom> jdot: word, yeah, this is a p4 1.6 iirc
14:03 <@jrandom> Ragnarok: in a token bucket, every (e.g.) second you add in some tokens, according to the rate. if the bucket is full (size = burst period), the tokens are discarded
14:04 <@jrandom> whenever you want to transfer data, you need to get a sufficient amount of tokens
14:04 <@jrandom> (1 token = 1 byte)
14:04 <+Ragnarok> I know how they work... what happens if you just make the bucket really big?
14:05 <+detonate> then you never stop sending data
14:05 <+detonate> if it's infinite in size
14:05 <+detonate> err, and it's filled with tokens
14:05 <@jrandom> if its really big, it may go out and burst to unlimited rates after low usage
14:06 <@jrandom> though perhaps thats desired in some cases
14:07 <@jrandom> the thing is, you can't just set the token bucket to 800GB, as that wouldnt constrain the total amount transferred
14:08 <+detonate> you need a field there where you can set the number of tokens per second, then you can just divide the bandwidth usage per month by the number of seconds
14:08 <+detonate> :)
14:10 <@jrandom> thats the same as just setting the rate averaged over the month, which would be unbalanced. but, anyway, lots of scenarios available - if anyone has any that address their needs that can't be met with whats available, please, get in touch
14:10 <+Ragnarok> but if you set the rate to the average you want... I think 308 kB/s here, and then set the bitbucket to something very larger... why doesn't that work?
14:11 <+Ragnarok> s/larger/large/
14:12 <+detonate> well, you could set it so that it never sends more than 800GB/44000 in a 60 second burst period
14:12 <+detonate> 44000 being roughly the number of minutes in a month
14:13 <@jrandom> the bucket size / burst duration describes how much we'll send without constraint, and most people /do/ want constraints, so the router doesnt gobble 10mbps for 5 minutes while draining the bucket (or whatever)
14:14 <@jrandom> an additional throttle of tokens coming out of the bucket is also possible (and should that throttle have its own token bucket, and that bucket have its own throttle, etc)
14:16 <+Ragnarok> I thought the bucket only got paid into when there was bandwidth not being used
14:16 <@jrandom> tokens are added to the bucket at a constant rate (e.g. 64k tokens per second)
14:17 <@jrandom> anything that wants bandwidth always asks the bucket
14:18 <+Ragnarok> ah.. ok
14:19 <@jrandom> ok cool, anyone else have anything they want to bring up for the meeting?
14:21 <@jrandom> ok if not
14:21 * jrandom winds up
14:21 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/134.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, March 22, 2005
===============================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,125 +1,119 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 135{% endblock %}
{% block content %}<h3>I2P dev meeting, March 29, 2005</h3>
<div class="irclog">
13:13 < jrandom> 0) hi</p>
13:13 < jrandom> 1) 0.5.0.5</p>
13:13 < jrandom> 2) UDP (SSU)</p>
13:13 < jrandom> 3) Q</p>
13:13 < jrandom> 4) ???</p>
13:13 < jrandom> 0) hi</p>
13:13 * jrandom waves</p>
13:13 * smeghead particles</p>
13:13 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000661.html</p>
13:14 < jrandom> (an hour early *mumblemumble*)</p>
13:14 < jrandom> anyway, jumping in to 1) 0.5.0.5</p>
13:15 < jrandom> as mentioned in the status notes, there'll be a new release later this evening</p>
13:15 < jrandom> everyone who is not yet on 0.5.0.4 should upgrade ASAP, as you'll be unable to talk to 0.5.0.5 users</p>
13:15 < jrandom> all 0.5.0.4 users should upgrade as soon as 0.5.0.5 is out, as well</p>
13:16 <@smeghead> will the update work through the new trusted update facility in the router console?</p>
13:17 < jrandom> yes and no</p>
13:17 < jrandom> of course, 0.5.0.4 has a bug in the NewsFetcher, where it doesn't write to a temp file, but instead resumes /over/ the existing file </p>
13:18 < jrandom> so, given the way that the NewsFetcher detects updates, it won't see the later "hey, 0.5.0.5! get it!" info</p>
13:18 < zzz> yes if you want to wait 12 hours? there's no 'update now' button, is there?</p>
13:18 < jrandom> otoh, once 0.5.0.5 is out and the news.xml is updated, 0.5.0.4 users can delete the file and it'll fetch it, detect it, and let you update</p>
13:19 <@smeghead> what's the name of this file?</p>
13:19 <@smeghead> oh ic</p>
13:19 < jrandom> zzz: if news.xml doesn't exist or if it hasn't been modified in 12 hours, a new rev is fetched</p>
13:20 < jrandom> there'll be a new i2pupdate.zip made available, as well as i2pupdate.sud</p>
13:20 < jrandom> (though for later revs, the .zip may not be provided)</p>
13:20 <@smeghead> should news.xml be in the base install dir?</p>
13:20 < jrandom> smeghead: docs/news.xml</p>
13:21 <+Myo9> Would it not good to get updates anonymous by default?</p>
13:21 <+Myo9> s/not/"not be"/</p>
13:22 < jrandom> Myo9: last week bla offered a counterpoint to that - the fact that you're running i2p is not secret, and using your eepproxy to fetch it could let dev.i2p see what destination is used</p>
13:22 <+frosk> anyone can tell you're running a router anyway</p>
13:22 <+ant> &lt;mae^&gt; lalalala</p>
13:22 < jrandom> just as it isn't a good idea to say on irc "hey, i'm restarting my router now", you dont want to associate your nyms with your router's activity</p>
13:23 <+Myo9> Ok.</p>
13:23 <+ant> * mae^ covers his ears</p>
13:23 < jrandom> but, on the other hand, if dev.i2p were truely an anonymous host (aka we didn't know it was dev.i2p.net), we'd need support for it :)</p>
13:23 <+ant> &lt;mae^&gt; dont talle me your goddamn network passwword</p>
13:24 <+ant> &lt;mae^&gt; damnit</p>
13:25 < jrandom> ok, anyone else have anything for 1) 0.5.0.5?</p>
13:25 <+ant> &lt;mae^&gt; lets all take take a minute to thank jr ight now</p>
13:25 <+ant> &lt;mae^&gt; silently and to yourself...</p>
13:25 <@smeghead> mae^: how about after the meeting</p>
13:25 < jrandom> heh, and to the donations page ;)</p>
13:25 <+ant> &lt;mae^&gt; or to him and private is ifine too</p>
13:26 <+ant> &lt;mae^&gt; or donate!</p>
13:26 < jrandom> ok, moving on to 2) UDP (SSU)</p>
13:26 < jrandom> we've got some thoughts on the new UDP protocol up on the web, and some critical feedback would be great</p>
13:27 <+ant> * cervantes notes the royal "we"</p>
13:27 <@smeghead> what is SSU</p>
13:27 < jrandom> well, i may be the one who types it in, but we've all been discussing the issues ;)</p>
13:28 < jrandom> SSU == Secure Semireliable UDP</p>
13:28 < jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html?rev=HEAD</p>
13:28 <+ant> &lt;Eol&gt; ??? got i2p up and running but can't resolve the .i2p sites .... states point browser at 4444 proxy but privoxy + tor already there ... site.i2p:4444 also fails ... ideas (w/o disabling privoxy or tor)</p>
13:28 <@smeghead> Eol: --&gt; #i2p-chat</p>
13:29 < jrandom> Eol: perhaps some people in #i2p-chat can help, we're in the weekly dev meeting right now</p>
13:30 < jrandom> the basic gist of things is that we'll be able to work around most NATs, but unfortunately not all of 'em. stats show that it'll work for a substantial % though (75-95, depending upon who you ask)</p>
13:31 < jrandom> ok, thats that, really - if anyone has any questions/comments/concerns, feel free to bounce me or the list an email anytime</p>
13:31 <+ant> * Eol apologizes</p>
13:31 <@smeghead> the remaining should rebel against their tyrannical system admins</p>
13:31 < jrandom> np eol</p>
13:32 <@smeghead> (or splurge for a real net connection)</p>
13:32 < jrandom> or get a non-symmetric NAT</p>
13:32 <+frosk> (or wait for restricted routes)</p>
13:32 < jrandom> yeah, or wait for 2.0 :)</p>
13:32 <@smeghead> because really, if you're concerned about freedom of information and anonymity, you shouldn't subject yourself to such NAT restrictions beyond your power anyhow</p>
13:32 < jrandom> smeghead: not everyone has a choice in the matter</p>
13:33 < jrandom> for instance, we had a user here the other day from the UAE, where there is ONE isp, with their own NAT</p>
13:33 <@smeghead> very true, but there are also people who expect us to bend over backwards to support them when they should be getting their power back</p>
13:33 <@smeghead> right</p>
13:34 < jrandom> aye, we'll support what we can, and what we can't, well, we can't, yet</p>
13:34 <@smeghead> the more people bend over for their ISPs, the more ISPs will restrict their users, and the harder our task becomes</p>
13:37 < jrandom> ok, anyone else have anything for 2) UDP? if not, moving on to 3) Q</p>
13:37 < jrandom> hmm, looks like aum isn't up yet :)</p>
13:37 < jrandom> but basically, lots of cool stuff up @ http://aum.i2p/q/</p>
13:38 <@smeghead> i think i speak for aum when i say, "zzzzzzzzzzzzzZZZz"</p>
13:39 < jrandom> ok, i dont know if i have anything to add beyond whats in the email, beyond "neat stuff, talk to aum" :)</p>
13:40 < jrandom> ok, moving on at a rapid rate to 4) ???</p>
13:40 < jrandom> anyone else have anything they want to bring up?</p>
13:41 < cervantes> whoa a sub half hour?</p>
13:41 < jrandom> first i get the meeting notes out an hour early, and now this!</p>
13:41 <@smeghead> time for a filibuster</p>
13:41 < jrandom> *cough*</p>
13:41 <+postman> :)</p>
13:41 < jrandom> ok, if there's nothing else, i can get back to packaging up 0.5.0.5 and y'all can download when its ready :)</p>
13:41 <+postman> ok, just wanted to announce v2mail.i2p</p>
13:42 * cervantes wheels out a ming dynasty china gong</p>
13:42 < jrandom> ooh word postman </p>
13:42 <+postman> as official portal to the v2mail deleopment</p>
13:42 <+postman> the html layout eats babys</p>
13:42 <+postman> but still i hope you find the docs/whitepapers there interesting</p>
13:43 <+postman> the documentation will be updated over the next week</p>
13:43 <@smeghead> could you say a little about what v2mail is?</p>
13:43 <@smeghead> v2 like version 2, or like the rocket?</p>
13:43 <+postman> smeghead: the new decentralized mailservice for i2p 1.0</p>
13:43 <+postman> smeghead: v2 refers to the version</p>
13:44 * postman does not plan any mailbombs or rockets :)</p>
13:44 <@smeghead> does it have specific dependencies on 1.0, or is that just a target?</p>
13:45 <+postman> there's still a few months work ahead - updates will be announced there</p>
13:45 <+frosk> nice effort, postman</p>
13:45 <+postman> smeghead: no, there're no dependencies on 1.0 - you'll still continue using susimail or your own mua</p>
13:46 <+postman> frosk: thanks </p>
13:46 <+postman> jrandom: k, /me hands back the microphone</p>
13:47 <+ant> &lt;cervantes&gt; *distant clapping*</p>
13:47 < jrandom> w3rd, it definitely looks cool</p>
13:47 <+postman> cervantes: hey, what about your firefox plugin?</p>
13:47 < jrandom> ok, anyone else have anything to add to the meeting?</p>
13:48 <+ant> &lt;cervantes&gt; postman: eerm still plugin away at it</p>
13:49 <+postman> cervantes: me want play with it :)</p>
13:50 <+ant> &lt;cervantes&gt; just getting through a tedious part of managing user preferences...then all should be ready for a test release</p>
13:50 < jrandom> wikked</p>
13:50 <+postman> c00l :)</p>
13:52 <+ant> &lt;cervantes&gt; on an aside...I seem to have persuaded a few mozilla developers to look into modifying the codebase so I can easily add URI filtering into the plugin (ie I will be able to guarantee no connections to non-i2p addresses are being made)</p>
13:52 < jrandom> oh, nice!</p>
13:52 <+ant> &lt;cervantes&gt; but that won't be in firefox for a couple of releases</p>
13:53 < jrandom> great, please keep us updated</p>
13:53 <+ant> &lt;cervantes&gt; will do</p>
13:54 < jrandom> ok, if there's nothing else...</p>
13:54 * jrandom winds up</p>
13:54 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:13 < jrandom> 0) hi
13:13 < jrandom> 1) 0.5.0.5
13:13 < jrandom> 2) UDP (SSU)
13:13 < jrandom> 3) Q
13:13 < jrandom> 4) ???
13:13 < jrandom> 0) hi
13:13 * jrandom waves
13:13 * smeghead particles
13:13 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000661.html
13:14 < jrandom> (an hour early *mumblemumble*)
13:14 < jrandom> anyway, jumping in to 1) 0.5.0.5
13:15 < jrandom> as mentioned in the status notes, there'll be a new release later this evening
13:15 < jrandom> everyone who is not yet on 0.5.0.4 should upgrade ASAP, as you'll be unable to talk to 0.5.0.5 users
13:15 < jrandom> all 0.5.0.4 users should upgrade as soon as 0.5.0.5 is out, as well
13:16 <@smeghead> will the update work through the new trusted update facility in the router console?
13:17 < jrandom> yes and no
13:17 < jrandom> of course, 0.5.0.4 has a bug in the NewsFetcher, where it doesn't write to a temp file, but instead resumes /over/ the existing file
13:18 < jrandom> so, given the way that the NewsFetcher detects updates, it won't see the later "hey, 0.5.0.5! get it!" info
13:18 < zzz> yes if you want to wait 12 hours? there's no 'update now' button, is there?
13:18 < jrandom> otoh, once 0.5.0.5 is out and the news.xml is updated, 0.5.0.4 users can delete the file and it'll fetch it, detect it, and let you update
13:19 <@smeghead> what's the name of this file?
13:19 <@smeghead> oh ic
13:19 < jrandom> zzz: if news.xml doesn't exist or if it hasn't been modified in 12 hours, a new rev is fetched
13:20 < jrandom> there'll be a new i2pupdate.zip made available, as well as i2pupdate.sud
13:20 < jrandom> (though for later revs, the .zip may not be provided)
13:20 <@smeghead> should news.xml be in the base install dir?
13:20 < jrandom> smeghead: docs/news.xml
13:21 <+Myo9> Would it not good to get updates anonymous by default?
13:21 <+Myo9> s/not/"not be"/
13:22 < jrandom> Myo9: last week bla offered a counterpoint to that - the fact that you're running i2p is not secret, and using your eepproxy to fetch it could let dev.i2p see what destination is used
13:22 <+frosk> anyone can tell you're running a router anyway
13:22 <+ant> <mae^> lalalala
13:22 < jrandom> just as it isn't a good idea to say on irc "hey, i'm restarting my router now", you dont want to associate your nyms with your router's activity
13:23 <+Myo9> Ok.
13:23 <+ant> * mae^ covers his ears
13:23 < jrandom> but, on the other hand, if dev.i2p were truely an anonymous host (aka we didn't know it was dev.i2p.net), we'd need support for it :)
13:23 <+ant> <mae^> dont talle me your goddamn network passwword
13:24 <+ant> <mae^> damnit
13:25 < jrandom> ok, anyone else have anything for 1) 0.5.0.5?
13:25 <+ant> <mae^> lets all take take a minute to thank jr ight now
13:25 <+ant> <mae^> silently and to yourself...
13:25 <@smeghead> mae^: how about after the meeting
13:25 < jrandom> heh, and to the donations page ;)
13:25 <+ant> <mae^> or to him and private is ifine too
13:26 <+ant> <mae^> or donate!
13:26 < jrandom> ok, moving on to 2) UDP (SSU)
13:26 < jrandom> we've got some thoughts on the new UDP protocol up on the web, and some critical feedback would be great
13:27 <+ant> * cervantes notes the royal "we"
13:27 <@smeghead> what is SSU
13:27 < jrandom> well, i may be the one who types it in, but we've all been discussing the issues ;)
13:28 < jrandom> SSU == Secure Semireliable UDP
13:28 < jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html?rev=HEAD
13:28 <+ant> <Eol> ??? got i2p up and running but can't resolve the .i2p sites .... states point browser at 4444 proxy but privoxy + tor already there ... site.i2p:4444 also fails ... ideas (w/o disabling privoxy or tor)
13:28 <@smeghead> Eol: --> #i2p-chat
13:29 < jrandom> Eol: perhaps some people in #i2p-chat can help, we're in the weekly dev meeting right now
13:30 < jrandom> the basic gist of things is that we'll be able to work around most NATs, but unfortunately not all of 'em. stats show that it'll work for a substantial % though (75-95, depending upon who you ask)
13:31 < jrandom> ok, thats that, really - if anyone has any questions/comments/concerns, feel free to bounce me or the list an email anytime
13:31 <+ant> * Eol apologizes
13:31 <@smeghead> the remaining should rebel against their tyrannical system admins
13:31 < jrandom> np eol
13:32 <@smeghead> (or splurge for a real net connection)
13:32 < jrandom> or get a non-symmetric NAT
13:32 <+frosk> (or wait for restricted routes)
13:32 < jrandom> yeah, or wait for 2.0 :)
13:32 <@smeghead> because really, if you're concerned about freedom of information and anonymity, you shouldn't subject yourself to such NAT restrictions beyond your power anyhow
13:32 < jrandom> smeghead: not everyone has a choice in the matter
13:33 < jrandom> for instance, we had a user here the other day from the UAE, where there is ONE isp, with their own NAT
13:33 <@smeghead> very true, but there are also people who expect us to bend over backwards to support them when they should be getting their power back
13:33 <@smeghead> right
13:34 < jrandom> aye, we'll support what we can, and what we can't, well, we can't, yet
13:34 <@smeghead> the more people bend over for their ISPs, the more ISPs will restrict their users, and the harder our task becomes
13:37 < jrandom> ok, anyone else have anything for 2) UDP? if not, moving on to 3) Q
13:37 < jrandom> hmm, looks like aum isn't up yet :)
13:37 < jrandom> but basically, lots of cool stuff up @ http://aum.i2p/q/
13:38 <@smeghead> i think i speak for aum when i say, "zzzzzzzzzzzzzZZZz"
13:39 < jrandom> ok, i dont know if i have anything to add beyond whats in the email, beyond "neat stuff, talk to aum" :)
13:40 < jrandom> ok, moving on at a rapid rate to 4) ???
13:40 < jrandom> anyone else have anything they want to bring up?
13:41 < cervantes> whoa a sub half hour?
13:41 < jrandom> first i get the meeting notes out an hour early, and now this!
13:41 <@smeghead> time for a filibuster
13:41 < jrandom> *cough*
13:41 <+postman> :)
13:41 < jrandom> ok, if there's nothing else, i can get back to packaging up 0.5.0.5 and y'all can download when its ready :)
13:41 <+postman> ok, just wanted to announce v2mail.i2p
13:42 * cervantes wheels out a ming dynasty china gong
13:42 < jrandom> ooh word postman
13:42 <+postman> as official portal to the v2mail deleopment
13:42 <+postman> the html layout eats babys
13:42 <+postman> but still i hope you find the docs/whitepapers there interesting
13:43 <+postman> the documentation will be updated over the next week
13:43 <@smeghead> could you say a little about what v2mail is?
13:43 <@smeghead> v2 like version 2, or like the rocket?
13:43 <+postman> smeghead: the new decentralized mailservice for i2p 1.0
13:43 <+postman> smeghead: v2 refers to the version
13:44 * postman does not plan any mailbombs or rockets :)
13:44 <@smeghead> does it have specific dependencies on 1.0, or is that just a target?
13:45 <+postman> there's still a few months work ahead - updates will be announced there
13:45 <+frosk> nice effort, postman
13:45 <+postman> smeghead: no, there're no dependencies on 1.0 - you'll still continue using susimail or your own mua
13:46 <+postman> frosk: thanks
13:46 <+postman> jrandom: k, /me hands back the microphone
13:47 <+ant> <cervantes> *distant clapping*
13:47 < jrandom> w3rd, it definitely looks cool
13:47 <+postman> cervantes: hey, what about your firefox plugin?
13:47 < jrandom> ok, anyone else have anything to add to the meeting?
13:48 <+ant> <cervantes> postman: eerm still plugin away at it
13:49 <+postman> cervantes: me want play with it :)
13:50 <+ant> <cervantes> just getting through a tedious part of managing user preferences...then all should be ready for a test release
13:50 < jrandom> wikked
13:50 <+postman> c00l :)
13:52 <+ant> <cervantes> on an aside...I seem to have persuaded a few mozilla developers to look into modifying the codebase so I can easily add URI filtering into the plugin (ie I will be able to guarantee no connections to non-i2p addresses are being made)
13:52 < jrandom> oh, nice!
13:52 <+ant> <cervantes> but that won't be in firefox for a couple of releases
13:53 < jrandom> great, please keep us updated
13:53 <+ant> <cervantes> will do
13:54 < jrandom> ok, if there's nothing else...
13:54 * jrandom winds up
13:54 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/135.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, March 29, 2005
===============================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,103 +1,97 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 136{% endblock %}
{% block content %}<h3>I2P dev meeting, April 5, 2005</h3>
<div class="irclog">
14:34 <@jrandom> 0) hi</p>
14:34 <@jrandom> 1) 0.5.0.5</p>
14:34 <@jrandom> 2) Bayesian peer profiling</p>
14:34 <@jrandom> 3) Q</p>
14:34 <@jrandom> 4) ???</p>
14:35 <@jrandom> 0) hi</p>
14:35 * jrandom waves</p>
14:35 * smeghead outsources his todo list to a parallel universe</p>
14:35 <@jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-April/000675.html</p>
14:36 <@jrandom> might as well jump on in to 1) 0.5.0.5</p>
14:36 <+ant> * Connelly waves</p>
14:37 <+protokol> high everyone</p>
14:37 <@jrandom> as mentioned in the status notes (and the current history.txt), we've tracked down some very long lasting netDb bugs</p>
14:37 <@jrandom> in the past, we've been able to fudge it, but 0.5.0.5 forced us to start doing things "right", which is why its been biting us now</p>
14:39 <@jrandom> i expect we'll have a new release sometime tomorrow, so keep an eye out for the update link on your router console :)</p>
14:39 <+protokol> yey</p>
14:39 <@jrandom> actually, thats about all i have on that at the moment - anyone else have anything to add wrt 0.5.0.5?</p>
14:40 <+protokol> nope</p>
14:41 <@jrandom> ok, moving on to 2) Bayesian peer profiling</p>
14:41 <@jrandom> ah, damn, bla dropped off the channel a few mins back</p>
14:42 <@jrandom> well, anyway, I just wanted to point people out at bla's work exploring some more robust profiling techniques</p>
14:42 <+protokol> postponing 2?</p>
14:43 <@jrandom> check out the forum post and the link to theland.i2p for more info, and bounce bla your thoughts :)</p>
14:44 <@jrandom> ok, movin' on to 3) Q</p>
14:44 <@jrandom> aum: you up?</p>
14:44 <@jrandom> hmm, doesnt look like it</p>
14:45 <@jrandom> ok, lots of progress on the Q front, more details for getting involved in alpha testing up @ http://aum.i2p/q/ </p>
14:45 <@jrandom> i'm sure we'll hear more on the list when there's an update available</p>
14:46 <+ant> &lt;Connelly&gt; Q works for me for retrieving content</p>
14:46 <@jrandom> yeah, its been working great for me as well, a few bumps here and there, but quite promising</p>
14:47 <+ant> &lt;Connelly&gt; my Q server stored 2 small items, then got stuck at 100% cpu usage until i killed it</p>
14:47 < zzz> for those who haven't seen it check out my q front end http://flock.i2p/cgi-bin/q</p>
14:47 <@jrandom> zzz: that is quite kickass</p>
14:48 * jrandom forgot the url to that when writing up the status notes (d'oh)</p>
14:50 <@jrandom> ok, anything else on 3) Q? or shall we move on to 4) ???</p>
14:50 * jrandom considers us moved</p>
14:51 <@jrandom> anyone have anything else they'd like to bring up for the meeting?</p>
14:51 <+ant> &lt;Connelly&gt; i've coding an http/html filter for i2p</p>
14:51 <+protokol> yes</p>
14:51 <+protokol> ian clarke is a troll on slashdot</p>
14:51 <+ant> &lt;Connelly&gt; been coding</p>
14:51 <+ant> &lt;Connelly&gt; should be more safe than freenet's html filterer</p>
14:51 <+ant> &lt;Connelly&gt; if i run out of time i'll just incorporate freenet's filterer</p>
14:51 <@jrandom> cool Connelly, how is it coming along?</p>
14:52 <@jrandom> protokol: and you're a troll in #i2p ;)</p>
14:52 <+ant> &lt;Connelly&gt; so in the end we should have an html filterer for i2p</p>
14:52 <+ant> &lt;Connelly&gt; got html filtering done, now working on css, still haven't looked at header filtering</p>
14:53 <+ant> &lt;Connelly&gt; it's very paranoid :)</p>
14:53 <@jrandom> bitchin</p>
14:53 <+protokol> whitelist?</p>
14:53 <@duck> does it let anything trough at all?</p>
14:53 <+ant> &lt;Connelly&gt; yeah</p>
14:53 <+protokol> if so, what is currently disallowed</p>
14:53 <+protokol> (of any importance)</p>
14:55 <+ant> &lt;Connelly&gt; disallowed of significance: frames and iframes, scripting, optgroup</p>
14:55 <+ant> &lt;Connelly&gt; meta</p>
14:55 <+ant> &lt;Connelly&gt; embedded objects</p>
14:56 <@jrandom> neat. i'm looking forward to seeing how things progress - any eta on when we could try rigging it up with the eepproxy?</p>
14:56 <+ant> &lt;Connelly&gt; i'll probably have an alpha in 1-2 weeks</p>
14:57 <+ant> &lt;Connelly&gt; so we can test out how it works</p>
14:57 < jrandom2p> kickass</p>
14:58 <+ant> &lt;Connelly&gt; it allows forms, cookies, content caching but those can be turned off in 'paranoid' mode</p>
14:58 <+protokol> why frames and iframes? can you just not block connections to non-i2p sites from them?</p>
14:59 <+ant> &lt;Connelly&gt; it has a cgiproxy like url navigator bar at the top</p>
14:59 <+ant> &lt;BS314159&gt; I suspect the hard thing would be blocking frames between different eepsites</p>
14:59 <+ant> &lt;Connelly&gt; i don't want that hijacked</p>
14:59 <+protokol> i mean can you just block connections</p>
14:59 <+ant> &lt;Connelly&gt; could make it like freenet's proxy where you just enter a url at the beginning</p>
14:59 <+protokol> yeah, frames can rock</p>
14:59 <+ant> &lt;Connelly&gt; and can't enter urls once you start browsing</p>
14:59 < jrandom2p> frames kill kittens</p>
15:00 <+ant> &lt;BS314159&gt; this has to be the oldest framewar ever. excuse me, flamewar</p>
15:00 < jrandom2p> heh</p>
15:00 <+protokol> i said "can" rock</p>
15:00 <+ant> &lt;BS314159&gt; what we need is our own browser</p>
15:00 <@jrandom> and flying ponies</p>
15:01 <@jrandom> *cough*</p>
15:01 <+ant> &lt;Connelly&gt; i'd prefer an F-16 to a pony</p>
15:01 < Teal`c__> can i have a girl ?</p>
15:01 <+ant> &lt;Connelly&gt; i'll make an option for enabling frames</p>
15:01 <+protokol> Teal`c__: no</p>
15:02 <+ant> &lt;BS314159&gt; Is there a functioning I2P inproxy? bolas.mine.nu appears to be dead.</p>
15:02 <+protokol> from other eepsites, right?</p>
15:02 <@jrandom> BS314159: http://i2p.mine.nu/</p>
15:02 <+protokol> i2p.mine.nu</p>
15:02 < frosk> i2p.mine.nu</p>
15:02 <+ant> &lt;BS314159&gt; thanks</p>
15:02 <+ant> &lt;BS314159&gt; frames are safe if they're inside one eepsite. frames are safe if all content is static</p>
15:03 <+ant> &lt;BS314159&gt; the only danger is if there's a form in one of the frames, since you might submit information to the wrong party</p>
15:04 <@jrandom> eh, i'm of the opinion the filter should only support what we *need* (and know is safe), and let actual end user demands expand functionality, rather than preemptively assume people will want some things</p>
15:04 <+ant> &lt;BS314159&gt; wise</p>
15:06 <@jrandom> ok, anyone else have anything for the meeting?</p>
15:06 < Teal`c__> sorry didn't know a meeting was on</p>
15:07 <@jrandom> heh no worry, you'll be immortalized in the meeting logs ;)</p>
15:07 <@jrandom> speaking of which</p>
15:07 * jrandom winds up</p>
15:07 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
14:34 <@jrandom> 0) hi
14:34 <@jrandom> 1) 0.5.0.5
14:34 <@jrandom> 2) Bayesian peer profiling
14:34 <@jrandom> 3) Q
14:34 <@jrandom> 4) ???
14:35 <@jrandom> 0) hi
14:35 * jrandom waves
14:35 * smeghead outsources his todo list to a parallel universe
14:35 <@jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-April/000675.html
14:36 <@jrandom> might as well jump on in to 1) 0.5.0.5
14:36 <+ant> * Connelly waves
14:37 <+protokol> high everyone
14:37 <@jrandom> as mentioned in the status notes (and the current history.txt), we've tracked down some very long lasting netDb bugs
14:37 <@jrandom> in the past, we've been able to fudge it, but 0.5.0.5 forced us to start doing things "right", which is why its been biting us now
14:39 <@jrandom> i expect we'll have a new release sometime tomorrow, so keep an eye out for the update link on your router console :)
14:39 <+protokol> yey
14:39 <@jrandom> actually, thats about all i have on that at the moment - anyone else have anything to add wrt 0.5.0.5?
14:40 <+protokol> nope
14:41 <@jrandom> ok, moving on to 2) Bayesian peer profiling
14:41 <@jrandom> ah, damn, bla dropped off the channel a few mins back
14:42 <@jrandom> well, anyway, I just wanted to point people out at bla's work exploring some more robust profiling techniques
14:42 <+protokol> postponing 2?
14:43 <@jrandom> check out the forum post and the link to theland.i2p for more info, and bounce bla your thoughts :)
14:44 <@jrandom> ok, movin' on to 3) Q
14:44 <@jrandom> aum: you up?
14:44 <@jrandom> hmm, doesnt look like it
14:45 <@jrandom> ok, lots of progress on the Q front, more details for getting involved in alpha testing up @ http://aum.i2p/q/
14:45 <@jrandom> i'm sure we'll hear more on the list when there's an update available
14:46 <+ant> <Connelly> Q works for me for retrieving content
14:46 <@jrandom> yeah, its been working great for me as well, a few bumps here and there, but quite promising
14:47 <+ant> <Connelly> my Q server stored 2 small items, then got stuck at 100% cpu usage until i killed it
14:47 < zzz> for those who haven't seen it check out my q front end http://flock.i2p/cgi-bin/q
14:47 <@jrandom> zzz: that is quite kickass
14:48 * jrandom forgot the url to that when writing up the status notes (d'oh)
14:50 <@jrandom> ok, anything else on 3) Q? or shall we move on to 4) ???
14:50 * jrandom considers us moved
14:51 <@jrandom> anyone have anything else they'd like to bring up for the meeting?
14:51 <+ant> <Connelly> i've coding an http/html filter for i2p
14:51 <+protokol> yes
14:51 <+protokol> ian clarke is a troll on slashdot
14:51 <+ant> <Connelly> been coding
14:51 <+ant> <Connelly> should be more safe than freenet's html filterer
14:51 <+ant> <Connelly> if i run out of time i'll just incorporate freenet's filterer
14:51 <@jrandom> cool Connelly, how is it coming along?
14:52 <@jrandom> protokol: and you're a troll in #i2p ;)
14:52 <+ant> <Connelly> so in the end we should have an html filterer for i2p
14:52 <+ant> <Connelly> got html filtering done, now working on css, still haven't looked at header filtering
14:53 <+ant> <Connelly> it's very paranoid :)
14:53 <@jrandom> bitchin
14:53 <+protokol> whitelist?
14:53 <@duck> does it let anything trough at all?
14:53 <+ant> <Connelly> yeah
14:53 <+protokol> if so, what is currently disallowed
14:53 <+protokol> (of any importance)
14:55 <+ant> <Connelly> disallowed of significance: frames and iframes, scripting, optgroup
14:55 <+ant> <Connelly> meta
14:55 <+ant> <Connelly> embedded objects
14:56 <@jrandom> neat. i'm looking forward to seeing how things progress - any eta on when we could try rigging it up with the eepproxy?
14:56 <+ant> <Connelly> i'll probably have an alpha in 1-2 weeks
14:57 <+ant> <Connelly> so we can test out how it works
14:57 < jrandom2p> kickass
14:58 <+ant> <Connelly> it allows forms, cookies, content caching but those can be turned off in 'paranoid' mode
14:58 <+protokol> why frames and iframes? can you just not block connections to non-i2p sites from them?
14:59 <+ant> <Connelly> it has a cgiproxy like url navigator bar at the top
14:59 <+ant> <BS314159> I suspect the hard thing would be blocking frames between different eepsites
14:59 <+ant> <Connelly> i don't want that hijacked
14:59 <+protokol> i mean can you just block connections
14:59 <+ant> <Connelly> could make it like freenet's proxy where you just enter a url at the beginning
14:59 <+protokol> yeah, frames can rock
14:59 <+ant> <Connelly> and can't enter urls once you start browsing
14:59 < jrandom2p> frames kill kittens
15:00 <+ant> <BS314159> this has to be the oldest framewar ever. excuse me, flamewar
15:00 < jrandom2p> heh
15:00 <+protokol> i said "can" rock
15:00 <+ant> <BS314159> what we need is our own browser
15:00 <@jrandom> and flying ponies
15:01 <@jrandom> *cough*
15:01 <+ant> <Connelly> i'd prefer an F-16 to a pony
15:01 < Teal`c__> can i have a girl ?
15:01 <+ant> <Connelly> i'll make an option for enabling frames
15:01 <+protokol> Teal`c__: no
15:02 <+ant> <BS314159> Is there a functioning I2P inproxy? bolas.mine.nu appears to be dead.
15:02 <+protokol> from other eepsites, right?
15:02 <@jrandom> BS314159: http://i2p.mine.nu/
15:02 <+protokol> i2p.mine.nu
15:02 < frosk> i2p.mine.nu
15:02 <+ant> <BS314159> thanks
15:02 <+ant> <BS314159> frames are safe if they're inside one eepsite. frames are safe if all content is static
15:03 <+ant> <BS314159> the only danger is if there's a form in one of the frames, since you might submit information to the wrong party
15:04 <@jrandom> eh, i'm of the opinion the filter should only support what we *need* (and know is safe), and let actual end user demands expand functionality, rather than preemptively assume people will want some things
15:04 <+ant> <BS314159> wise
15:06 <@jrandom> ok, anyone else have anything for the meeting?
15:06 < Teal`c__> sorry didn't know a meeting was on
15:07 <@jrandom> heh no worry, you'll be immortalized in the meeting logs ;)
15:07 <@jrandom> speaking of which
15:07 * jrandom winds up
15:07 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/136.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, April 5, 2005
==============================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,286 +1,280 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 137{% endblock %}
{% block content %}<h3>I2P dev meeting, April 12, 2005</h3>
<div class="irclog">
14:05 < jrandom> 0) hi</p>
14:05 < jrandom> 1) Net status</p>
14:05 < jrandom> 2) SSU status</p>
14:05 < jrandom> 3) Bayesian peer profiling</p>
14:05 < jrandom> 4) Q status</p>
14:05 < jrandom> 5) ???</p>
14:05 < hummingbird> 7) Profit</p>
14:06 < jrandom> damn, i messed up y'all's agenda :)</p>
14:06 < jrandom> hi</p>
14:06 < jrandom> weekly status notes posted /before/ the meeting up @ http://dev.i2p.net/pipermail/i2p/2005-April/000683.html</p>
14:06 < gott> jrandom: try it again</p>
14:06 <+cervantes> never mind, this meeting gott off onto a bad footing anyway</p>
14:06 < jrandom> *cough*</p>
14:06 < jrandom> jumping in to 1) Net status</p>
14:07 < jrandom> the big problem we were seeing with the netDb has been fixed and confirmed dead in the wild</p>
14:07 < jrandom> there are still some other issues, but it seems on the whole to be fairly reasonable</p>
14:08 < frosk> any idea what's causing the weird dnfs sometimes?</p>
14:08 < gott> confirm; I can get my illegal porn at record speeds for i2p now.</p>
14:08 <+cervantes> seems like that might be a hard one to pin down</p>
14:08 < jrandom> sneaking suspicion that its some confusion related to the throttle on the tunnel building</p>
14:09 < jrandom> pulling out those throttles will probably address it, but could be painful for users with slow CPUs</p>
14:09 < jrandom> otoh, perhaps we could make them optional, or someone could write some smarter throttling code</p>
14:10 < frosk> i see</p>
14:10 <+cervantes> the throttle seems much more pro-active than previous versions on my system</p>
14:10 < jrandom> yeah, we delay tunnel building when there are too many outstanding - before we just said "ok, we need to build X tunnels. build 'em"</p>
14:10 <+cervantes> can we not make the threshold tweakable?</p>
14:11 < jrandom> aye, that we can</p>
14:11 < gott> jrandom: optional</p>
14:11 < gott> so users with thin i2p servents can still be productive</p>
14:12 < jrandom> my attention is focused elsewhere at the moment, so if someone wants to dig into that, the key method is TunnelPoolManager.allocateBuilds</p>
14:12 < jrandom> (or if no one jumps at it, i can toss in some tweaks when the next build comes out)</p>
14:13 <+cervantes> ........@ &lt;-- tumbleweed</p>
14:13 < jrandom> :)</p>
14:13 < jrandom> anyone have anything else for 1) net status, or shall we move on to 2) SSU?</p>
14:14 * gott mutters something about too much talk and too little action when it comes to the i2p community</p>
14:14 <+cervantes> perhaps in the future we can introduce performance profiles into the console</p>
14:14 < gott> jrandom does too much on the development side.</p>
14:14 <+cervantes> so people can choose a preset batch of config options for high/med/low spec systems</p>
14:15 < jrandom> ooh good idea cervantes, there's lots of room for variants. while we want to automatically tune ourselves as best we can, it may be easier for humans to do it</p>
14:15 <+cervantes> since there are many that seem to be using low spec machines and modem connections atm</p>
14:15 < gott> cervantes: yeah, excellent idea.</p>
14:15 <+cervantes> I should publish my fire2pe todo list...it has lots of shit like that in it ;-)</p>
14:16 < gott> based on processor and network speed primarily ?</p>
14:16 < jrandom> a site with a pseudonymous todo list would be nice</p>
14:16 < gott> that is a good idea.</p>
14:16 <+cervantes> well the bandwidth limiter should ideally take care of net speed</p>
14:16 < gott> in typical google-fashion, have a bunch of 'thin i2p servents' in your LAN.</p>
14:17 <+cervantes> jrandom: ugha.i2p?</p>
14:17 < jrandom> perhaps</p>
14:19 < jrandom> ok, anything else for 1) net status?</p>
14:19 * jrandom moves us on to 2) SSU</p>
14:19 < jrandom> Lots of progress on the UDP front (SSU == Secure Semireliable UDP)</p>
14:19 < gott> someone should alias 'i2pwiki.i2p' to that</p>
14:20 <+cervantes> I guess that's up to ugha ;-)</p>
14:20 < jrandom> the general overview of whats up is in the email, and a lot more technical details (and a pretty picture ;) is up on my blog</p>
14:21 <+ant> &lt;godmode0&gt; udp is safe ?</p>
14:21 <+ant> &lt;godmode0&gt; how :)</p>
14:21 < jrandom> http://dev.i2p/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html &lt;-- how</p>
14:22 <+ant> &lt;godmode0&gt; hehe</p>
14:22 <+ant> &lt;godmode0&gt; i2p not found right ip my computer</p>
14:22 < jrandom> sorry, if you don't have i2p installed, change "dev.i2p" to "dev.i2p.net"</p>
14:22 <+ant> &lt;godmode0&gt; have installled</p>
14:23 <+ant> &lt;godmode0&gt; but not work</p>
14:23 < jrandom> ok, perhaps we can debug that after the meeting </p>
14:23 <+ant> &lt;godmode0&gt; oops in meeting again sorry</p>
14:23 < jrandom> hehe np</p>
14:25 < jrandom> anyway, as i said, the general plan of how things are going is in the email</p>
14:25 < jrandom> anyone have any questions/comments/concerns wrt SSU?</p>
14:26 <+Ragnarok> will throughput/latency be much different than the tcp transport?</p>
14:27 < jrandom> my hope is that the cause of the lag spikes will be addressed, but i'm not making any particular predictions.</p>
14:28 < jrandom> if we can keep latency in the same ballpark as it is now and get rid of the spikes, we can jack back up the throughput</p>
14:29 <+Ragnarok> cool</p>
14:29 < gott> will there be documentation on the implementation provided on i2p.net ?</p>
14:30 < jrandom> much of my time when i go offline to move will be writing up docs to be put on the website, yes</p>
14:30 < gott> awesome \m/</p>
14:30 < jrandom> we do have some pretty good implementation docs at the code level for the core and router, but no great overall router architecture docs yet</p>
14:31 < jrandom> anyway, if there's nothing else on 2) SSU, lets shimmy on over to 3) Bayesian peer profiling</p>
14:32 < jrandom> we got a brief update from bla earlier this evening, as shown in the status notes</p>
14:32 <+bla> I'm still here though... ;)</p>
14:33 < jrandom> bla may atcually still be around to give us any further thoughts or answer questions -</p>
14:33 < jrandom> ah, there you are</p>
14:33 < defnax> jrandom : what do you think about anounce i2p bittorrent Tracker, for security i think is not good or?, </p>
14:34 <+bla> The IRC discussion quoted by jrandom shows the general idea. Summarized: </p>
14:34 < jrandom> defnax: perhaps we can discuss that further in 5) </p>
14:34 < defnax> ok i can wait </p>
14:34 <+bla> The eventual idea is to use both round-trip-time information obtained from explicit tunnels tests, and implicit information from client-tunnel tests, into one node-speed estimation framework</p>
14:35 <+bla> For now, I use information obtained from explicit tunnel tests only, as for those tests, all participating peers are known.</p>
14:36 <+bla> A naive Bayesian classifier framework will be used to estimate a peer's speed, given the tunnels in which it has participated (in any position), and how fast those tunnels were</p>
14:36 <+bla> In order to compare things to a "ground truth", I've obtained "actual" peer speeds as listed in the status notes</p>
14:37 <+bla> Results are very prelim. But http://theland.i2p/estspeed.png shows the correlation between actual speeds, and speeds inferred using the Bayesian framework</p>
14:37 <+bla> Well. Any questions or comments?</p>
14:38 < jrandom> comment: looks promising. </p>
14:38 <+ant> &lt;BS314159&gt; it seems like the total tunnel speed provides a hard lower bound on the speed of every participating peer</p>
14:38 <+detonate> comment: seem to be a few outliers</p>
14:38 <+ant> &lt;BS314159&gt; is that incorporated?</p>
14:39 < jrandom> BS314159: total tunnel speed? oh, do you mean the testing node's net connection?</p>
14:40 <+bla> BS314159: That does provide a lower bound, yes. This is not addressed yet, but will be: The naive Bayesian framework enables weighting different samples (RTT measurements) to different degrees. Very fast RTTs will be weighted by a larger factor in the future</p>
14:40 <+ant> &lt;BS314159&gt; I mean the total bandwidth of a given tunnel</p>
14:40 <+bla> BS: The results show _latency_ measurements, for now</p>
14:40 <+ant> &lt;BS314159&gt; right.</p>
14:41 <+ant> &lt;BS314159&gt; nevermind, then</p>
14:41 < jrandom> ah, right, certainly. throughput measurements will require further modifications to test with different size messages</p>
14:41 < jrandom> otoh, the implicit tunnel tests are driven by larger messages (typically 4KB, since thats the streaming lib fragmentation size)</p>
14:42 <+bla> detonate: Yes, there are outliers. There will always be _some_ (that's inherent to estimation, and modeling in general). However, the separation between really slow and really fast clients (putting a threshold at around 400 ms), is ok-ish</p>
14:42 <+detonate> ok</p>
14:43 <+bla> jrandom: Indeed. Once I get that working (in not a Java buff...), I'll also test using the larger messages</p>
14:43 <+bla> detonate: Now, I'd like to make the separation between fast and really-fast peers in a better way.</p>
14:43 < jrandom> cool, i'll see if i can bounce you a modified TestJob for that</p>
14:44 <+bla> I'll report when I have new results.</p>
14:44 < jrandom> kickass</p>
14:45 < jrandom> ok cool, anyone else have anything for 3) Bayesian peer profiling?</p>
14:46 < jrandom> if not, moving on to 4) Q status</p>
14:46 < jrandom> As mentioned in the email, rumor has it Aum is making progress on a new web interface</p>
14:47 < jrandom> i don't know much about it, or the status details on the rest of the Q updates, but i'm sure we'll hear more soon</p>
14:48 < jrandom> anyone have anything on Q to bring up? or shall we make this a rapid fire agenda item and move on to 5) ???</p>
14:49 < jrandom> [consider us moved]</p>
14:49 < jrandom> ok, anyone have anything else to bring up for the meeting?</p>
14:50 < jrandom> defnax: announcing an i2p tracker to people in the i2p community would be great. to the outside world it might be a bit rough, since we aren't at 0.6 yet</p>
14:50 < gott> Yes.</p>
14:50 < jrandom> (or 1.0 ;)</p>
14:50 < gott> I have some information to bring up on userland documentation efforts.</p>
14:51 <+mancom> just for the record: on mancom.i2p there is a c# implementation of Q's client api (in its first incarnation)</p>
14:51 < jrandom> oh cool, sup gott</p>
14:51 < jrandom> ah nice1 mancom</p>
14:51 < gott> I have previously written userland documentation for 0.4 i2p.</p>
14:52 < jrandom> which i unforutnately obsoleted by changing a whole bunch of stuff :(</p>
14:52 < gott> But it is entirely out-of-date with current i2p.</p>
14:52 < gott> Accordingly, I am very interested in writing a defacto set of documentation that we can either (a) bundle with i2p or (b) have access via i2p.</p>
14:53 < jrandom> wikked. docs to bundle with i2p (localized to the user's language, etc) would be great</p>
14:53 <+cervantes> cool</p>
14:53 < gott> I don't suggest bundling, but it is still a possible option, as a user can't access eepsites to read the manual if he doesn't know how to use or configure i2p ;-)</p>
14:53 < gott> Okay.</p>
14:53 < gott> But is it overkill ?</p>
14:53 <+ant> &lt;BS314159&gt; what respectable program comes without man pages?</p>
14:53 <+cervantes> and is it worth waiting til 1.0?</p>
14:54 < gott> That is another question.</p>
14:54 < jrandom> since development is fairly fluid, it might be worth focusing on context-specific help, rather than an overall user guide</p>
14:54 < gott> BS314159: these are not manpages, as it will be platform-independent. Probably HTML.</p>
14:54 <+cervantes> how much more structural changes are we due before then</p>
14:54 < jrandom> for instance, it'd be nice to have better docs describing what the different config options *mean*, what their implications are, etc.</p>
14:55 < gott> Okay, so I shall write an english and french localisation of a manual for i2p.</p>
14:55 <+jdot> actually, we could use the inproxy to access the documentation even w/o i2p being installed.</p>
14:55 < gott> Two major questions :</p>
14:55 < jrandom> those could be kept up to date by virtue of being *in* the interface itself</p>
14:55 <+cervantes> yeah context help would rock</p>
14:55 < gott> (1) Bundled or accessible via manual.i2p ?</p>
14:55 < gott> (2) For which version ?</p>
14:55 < gott> yes</p>
14:55 < jrandom> gott: i'm not sure it'd be wise to build a user guide yet</p>
14:55 < gott> that's a great idea</p>
14:56 < gott> do you mean to use the auto-update function to update the usermanual ?</p>
14:56 < gott> jrandom: okay</p>
14:56 < gott> but then how do you suggest context-specific help ?</p>
14:56 < jrandom> oh, we can certainly deploy updates to the docs with the update process</p>
14:56 <+cervantes> if/when it's time to do a manual then perhaps a manual.war can be dropped into a user's webapps folder if they want local access to the docs</p>
14:57 < gott> I am thinking of a user-manual.</p>
14:57 < gott> or a HOWTO.</p>
14:57 < gott> I have no idea what you mean by context-specific help.</p>
14:57 < gott> it's pretty straightforward.</p>
14:57 < jrandom> gott: for instance, a set of human (non-ubergeek) readable info explaining wtf things on /config.jsp mean. that info would go *on* /config.jsp, or on an html page reachable from that config.jsp</p>
14:58 < jrandom> a user-manual or howto would be great, but not until 1.0</p>
14:59 < jrandom> there's already some work on that front in the forum @ http://forum.i2p.net/viewtopic.php?t=385</p>
14:59 < gott> jrandom: yes.</p>
14:59 < gott> well.</p>
14:59 < gott> the information on config.jsp is pretty straightfoward already </p>
15:00 < jrandom> otoh, we see questions about what bandwidth limits actually do, how the burst rates work, etc here all the time. it'd be great to have the answers on the page, rather than have people ask</p>
15:00 < gott> heh</p>
15:00 < jrandom> gott: its straightforward to you because you've been using i2p for almost two years</p>
15:00 < gott> nevermind, 'configtunnels.jsp' could use some work.</p>
15:00 < gott> okay.</p>
15:00 <+cervantes> straightforward to the initiated perhaps, a n00b would be lost</p>
15:01 < gott> this is, then, a more up-to-date selection of tasks :</p>
15:01 <+cervantes> not sure the best way to present the help from an interface perspective</p>
15:01 < gott> (1) Context-specific help on the webpages localised to user's language. A configuration variable can be set for the language interface, by default, loaded from $LANG path variable on linux</p>
15:02 < gott> I'm not sure how java figures out the default locale under windows.</p>
15:02 < gott> But this is a good start to localisation and documentation writing.</p>
15:03 < gott> (2) For version 1.0, a HOWTO _accessed_ via i2p</p>
15:03 < gott> I don't suggest bundling the HOWTO, as that is just overkill. Would be nice to keep i2p as small as possible, hmm ?</p>
15:03 < jrandom> dood, its html. its tiny. even if its huge, html compresses *really* well</p>
15:03 < jrandom> having a local manual would be very much preferred</p>
15:03 < jrandom> especially since we can push updates</p>
15:03 * gott shrugs</p>
15:04 < gott> I suppose.</p>
15:04 < gott> I just find it silly.</p>
15:04 < gott> when you can just download it via the web.</p>
15:04 < gott> but on the other hand, if the user can't figure out how to use i2p</p>
15:04 < gott> he can't.</p>
15:04 <+ant> &lt;Synonymous2&gt; Is aum around, i was looking at the specs for QuarterMaster</p>
15:04 <+ant> &lt;Synonymous2&gt; * In order to help client-side searching, all data items are accompanied</p>
15:04 <+ant> &lt;Synonymous2&gt; by a simple metadata schema - so far, just consisting of:</p>
15:04 <+ant> &lt;Synonymous2&gt; - key - text name of key</p>
15:04 <+jdot> put it on www.i2p.net so it is accessible via the intarweb and i2p.</p>
15:04 <+jdot> and always up to date</p>
15:05 < gott> yeah.</p>
15:05 < gott> well, just use the update mechanism.</p>
15:05 < gott> okay.</p>
15:05 < gott> so, finalising :</p>
15:05 < jrandom> sure, we can put it on the website too. we can spam it all over the net if it helps ;)</p>
15:05 <+ant> &lt;Synonymous2&gt; I am wondering if Aum can implement the datastore so the metadata are seperated incase he wants to upgrade the storage system. Remember when Freenet wanted to change the storage system but was stuck</p>
15:05 < gott> 1 : Localised interface and context-specific help.</p>
15:05 < gott> 2 : Localised HOWTO for version 1.0</p>
15:05 <+ant> &lt;Synonymous2&gt; oopse is this the meeting :)</p>
15:05 < gott> Any additions ?</p>
15:06 < gott> the HOWTO will cover a lot of extra i2p-network features.</p>
15:06 < gott> where to get the latest porn ( j/k )</p>
15:06 <+ant> &lt;BS314159&gt; manpage! :-)</p>
15:06 < gott> manpages aren't platform-independent</p>
15:06 < jrandom> cool, including things like Q, i2ptunnel, feedspace, i2p-bt, etc would be great for a howto</p>
15:06 <+cervantes> the installer could be localised too I guess...</p>
15:06 < gott> the i2p network has a hilariously large amount of french users</p>
15:07 <+Ragnarok> you should clearly write the addressbook documentation I've never gotten around to :)</p>
15:07 < gott> I'm sure they would appreciate a localised interface so they don't have to look at the disgusting english language</p>
15:07 <+cervantes> hey it's mostly french already</p>
15:07 < gott> true.</p>
15:07 < gott> good ideas.</p>
15:08 < gott> well, that is all I had to say.</p>
15:08 < jrandom> ok cool, thanks gott, nice initiative</p>
15:08 < gott> for now, I shall start on the context-specific stuff</p>
15:08 < jrandom> Synonymous2: I'm not sure what Aum is doing on that front</p>
15:08 < jrandom> bitchin'</p>
15:08 < gott> and then, when a localisation option is added, the localised languages </p>
15:08 <+bla> gott: Je _deteste_ Anglais! ;)</p>
15:09 < gott> moi aussi</p>
15:09 <+ant> &lt;Synonymous2&gt; Q, i2ptunnel, feedspace, i2p-bt, etc would be great for a howto, i think the wiki article should be updated for i2p to add this, i'll do that</p>
15:09 <+cervantes> ewll you have william the conquerer to blame for that</p>
15:09 < jrandom> heh</p>
15:09 < gott> a wiki is good, but also non-official.</p>
15:09 < gott> the manual has the element of certification.</p>
15:09 < gott> it is more reassuring.</p>
15:10 <+ant> &lt;Synonymous2&gt; if ppl want to come and look that would be helpful too, the freenet wikipedia article is also good describing the tools for freenet. As well, I see that the Freenet webpage is released under the GNU FDL, if i2p.net could do the same (or public domain) I could copy some stuff to wikipedia :)) if you want to do that</p>
15:10 <+cervantes> we'd still be speaking anglo-saxon otherwise</p>
15:10 < jrandom> everything i do which i 'have rights to' is released implicitly into the public domain</p>
15:11 <+ant> &lt;Synonymous2&gt; i thought it was, if you can put that as a blurb on the webpage that would be great at your convience, the ppl at wikipedia are anal bout copyright :&gt;</p>
15:11 <+ant> &lt;Synonymous2&gt; :)))</p>
15:11 < gott> jrandom: all the localisation I write will be public domain</p>
15:11 < jrandom> otoh, outright copying the text is, er, not too helpful, as your copies will be out of date - just link to it, the web is there for a reason</p>
15:11 < gott> I don't give a damn about any licenses.</p>
15:12 < gott> also, last question :</p>
15:12 <+ant> &lt;Synonymous2&gt; i was going to copy a few things like the chart and some graphics hehe</p>
15:12 < gott> where are the .jsp for the router located ?</p>
15:12 < jrandom> gott: http://dev.i2p/cgi-bin/cvsweb.cgi/apps/routerconsole/jsp/</p>
15:13 < gott> ah</p>
15:13 < gott> so, locally, they are in a .jar ?</p>
15:13 < jrandom> gott: routerconsole.war</p>
15:13 < jrandom> but you can't really edit them there, as they're precompiled into java</p>
15:13 * gott nods</p>
15:13 < gott> Sure.</p>
15:14 < gott> Though, that's an inconvenience.</p>
15:14 < gott> when localisation comes out, that might be changed ?</p>
15:14 < jrandom> yep. lots of options though. if you work out the html that the jsps should render as, we can wire it in</p>
15:14 <+cervantes> Synonymous: http://www.i2p.net/licenses</p>
15:15 < gott> so you can have language packs</p>
15:15 * gott nods</p>
15:15 < gott> for now, it is just hardcoded</p>
15:15 < jrandom> localization in java works by loading up per-language properties files with resources</p>
15:15 < gott> but later on, it should be less restricted, I suggest</p>
15:15 < jrandom> right right</p>
15:16 < gott> awesome.</p>
15:16 < gott> well, I'll use anonymous CVS then ;-)</p>
15:16 < jrandom> bitchin'</p>
15:16 <+ant> &lt;BS314159&gt; bla: is your raw data available anywhere?</p>
15:16 < jrandom> bla has recently disconnected, but we'll see about getting some data available</p>
15:17 < gott> btw, do we have anyone running i2p on openbsd ?</p>
15:17 <+ant> &lt;BS314159&gt; it's be fun to let people try their own estimators</p>
15:17 <+ant> &lt;BS314159&gt; sister:...23?</p>
15:17 < jrandom> gott: yeah, i think detonate is</p>
15:18 <+ant> &lt;BS314159&gt; ack</p>
15:18 <+ant> &lt;BS314159&gt; cross-post</p>
15:18 <+ant> &lt;BS314159&gt; curses!</p>
15:18 < gott> is it even possible ? what are the java limitations regarding openbsd and i2p ?</p>
15:18 < gott> okay.</p>
15:18 < jrandom> BS314159: yeah, there's some good info about modifying your estimators up in the forum</p>
15:18 <+cervantes> long meeting</p>
15:18 < gott> if I ever have time, I might get it running and setup a port.</p>
15:18 < gott> but that is long off and someone will probably do it before me ;-)</p>
15:18 < jrandom> cervantes: check the logs, we've broken 2h before ;)</p>
15:19 < jrandom> ok, anyone else have anything for the meeting?</p>
15:20 < jrandom> if not</p>
15:20 * jrandom winds up</p>
15:20 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
14:05 < jrandom> 0) hi
14:05 < jrandom> 1) Net status
14:05 < jrandom> 2) SSU status
14:05 < jrandom> 3) Bayesian peer profiling
14:05 < jrandom> 4) Q status
14:05 < jrandom> 5) ???
14:05 < hummingbird> 7) Profit
14:06 < jrandom> damn, i messed up y'all's agenda :)
14:06 < jrandom> hi
14:06 < jrandom> weekly status notes posted /before/ the meeting up @ http://dev.i2p.net/pipermail/i2p/2005-April/000683.html
14:06 < gott> jrandom: try it again
14:06 <+cervantes> never mind, this meeting gott off onto a bad footing anyway
14:06 < jrandom> *cough*
14:06 < jrandom> jumping in to 1) Net status
14:07 < jrandom> the big problem we were seeing with the netDb has been fixed and confirmed dead in the wild
14:07 < jrandom> there are still some other issues, but it seems on the whole to be fairly reasonable
14:08 < frosk> any idea what's causing the weird dnfs sometimes?
14:08 < gott> confirm; I can get my illegal porn at record speeds for i2p now.
14:08 <+cervantes> seems like that might be a hard one to pin down
14:08 < jrandom> sneaking suspicion that its some confusion related to the throttle on the tunnel building
14:09 < jrandom> pulling out those throttles will probably address it, but could be painful for users with slow CPUs
14:09 < jrandom> otoh, perhaps we could make them optional, or someone could write some smarter throttling code
14:10 < frosk> i see
14:10 <+cervantes> the throttle seems much more pro-active than previous versions on my system
14:10 < jrandom> yeah, we delay tunnel building when there are too many outstanding - before we just said "ok, we need to build X tunnels. build 'em"
14:10 <+cervantes> can we not make the threshold tweakable?
14:11 < jrandom> aye, that we can
14:11 < gott> jrandom: optional
14:11 < gott> so users with thin i2p servents can still be productive
14:12 < jrandom> my attention is focused elsewhere at the moment, so if someone wants to dig into that, the key method is TunnelPoolManager.allocateBuilds
14:12 < jrandom> (or if no one jumps at it, i can toss in some tweaks when the next build comes out)
14:13 <+cervantes> ........@ <-- tumbleweed
14:13 < jrandom> :)
14:13 < jrandom> anyone have anything else for 1) net status, or shall we move on to 2) SSU?
14:14 * gott mutters something about too much talk and too little action when it comes to the i2p community
14:14 <+cervantes> perhaps in the future we can introduce performance profiles into the console
14:14 < gott> jrandom does too much on the development side.
14:14 <+cervantes> so people can choose a preset batch of config options for high/med/low spec systems
14:15 < jrandom> ooh good idea cervantes, there's lots of room for variants. while we want to automatically tune ourselves as best we can, it may be easier for humans to do it
14:15 <+cervantes> since there are many that seem to be using low spec machines and modem connections atm
14:15 < gott> cervantes: yeah, excellent idea.
14:15 <+cervantes> I should publish my fire2pe todo list...it has lots of shit like that in it ;-)
14:16 < gott> based on processor and network speed primarily ?
14:16 < jrandom> a site with a pseudonymous todo list would be nice
14:16 < gott> that is a good idea.
14:16 <+cervantes> well the bandwidth limiter should ideally take care of net speed
14:16 < gott> in typical google-fashion, have a bunch of 'thin i2p servents' in your LAN.
14:17 <+cervantes> jrandom: ugha.i2p?
14:17 < jrandom> perhaps
14:19 < jrandom> ok, anything else for 1) net status?
14:19 * jrandom moves us on to 2) SSU
14:19 < jrandom> Lots of progress on the UDP front (SSU == Secure Semireliable UDP)
14:19 < gott> someone should alias 'i2pwiki.i2p' to that
14:20 <+cervantes> I guess that's up to ugha ;-)
14:20 < jrandom> the general overview of whats up is in the email, and a lot more technical details (and a pretty picture ;) is up on my blog
14:21 <+ant> <godmode0> udp is safe ?
14:21 <+ant> <godmode0> how :)
14:21 < jrandom> http://dev.i2p/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html <-- how
14:22 <+ant> <godmode0> hehe
14:22 <+ant> <godmode0> i2p not found right ip my computer
14:22 < jrandom> sorry, if you don't have i2p installed, change "dev.i2p" to "dev.i2p.net"
14:22 <+ant> <godmode0> have installled
14:23 <+ant> <godmode0> but not work
14:23 < jrandom> ok, perhaps we can debug that after the meeting
14:23 <+ant> <godmode0> oops in meeting again sorry
14:23 < jrandom> hehe np
14:25 < jrandom> anyway, as i said, the general plan of how things are going is in the email
14:25 < jrandom> anyone have any questions/comments/concerns wrt SSU?
14:26 <+Ragnarok> will throughput/latency be much different than the tcp transport?
14:27 < jrandom> my hope is that the cause of the lag spikes will be addressed, but i'm not making any particular predictions.
14:28 < jrandom> if we can keep latency in the same ballpark as it is now and get rid of the spikes, we can jack back up the throughput
14:29 <+Ragnarok> cool
14:29 < gott> will there be documentation on the implementation provided on i2p.net ?
14:30 < jrandom> much of my time when i go offline to move will be writing up docs to be put on the website, yes
14:30 < gott> awesome \m/
14:30 < jrandom> we do have some pretty good implementation docs at the code level for the core and router, but no great overall router architecture docs yet
14:31 < jrandom> anyway, if there's nothing else on 2) SSU, lets shimmy on over to 3) Bayesian peer profiling
14:32 < jrandom> we got a brief update from bla earlier this evening, as shown in the status notes
14:32 <+bla> I'm still here though... ;)
14:33 < jrandom> bla may atcually still be around to give us any further thoughts or answer questions -
14:33 < jrandom> ah, there you are
14:33 < defnax> jrandom : what do you think about anounce i2p bittorrent Tracker, for security i think is not good or?,
14:34 <+bla> The IRC discussion quoted by jrandom shows the general idea. Summarized:
14:34 < jrandom> defnax: perhaps we can discuss that further in 5)
14:34 < defnax> ok i can wait
14:34 <+bla> The eventual idea is to use both round-trip-time information obtained from explicit tunnels tests, and implicit information from client-tunnel tests, into one node-speed estimation framework
14:35 <+bla> For now, I use information obtained from explicit tunnel tests only, as for those tests, all participating peers are known.
14:36 <+bla> A naive Bayesian classifier framework will be used to estimate a peer's speed, given the tunnels in which it has participated (in any position), and how fast those tunnels were
14:36 <+bla> In order to compare things to a "ground truth", I've obtained "actual" peer speeds as listed in the status notes
14:37 <+bla> Results are very prelim. But http://theland.i2p/estspeed.png shows the correlation between actual speeds, and speeds inferred using the Bayesian framework
14:37 <+bla> Well. Any questions or comments?
14:38 < jrandom> comment: looks promising.
14:38 <+ant> <BS314159> it seems like the total tunnel speed provides a hard lower bound on the speed of every participating peer
14:38 <+detonate> comment: seem to be a few outliers
14:38 <+ant> <BS314159> is that incorporated?
14:39 < jrandom> BS314159: total tunnel speed? oh, do you mean the testing node's net connection?
14:40 <+bla> BS314159: That does provide a lower bound, yes. This is not addressed yet, but will be: The naive Bayesian framework enables weighting different samples (RTT measurements) to different degrees. Very fast RTTs will be weighted by a larger factor in the future
14:40 <+ant> <BS314159> I mean the total bandwidth of a given tunnel
14:40 <+bla> BS: The results show _latency_ measurements, for now
14:40 <+ant> <BS314159> right.
14:41 <+ant> <BS314159> nevermind, then
14:41 < jrandom> ah, right, certainly. throughput measurements will require further modifications to test with different size messages
14:41 < jrandom> otoh, the implicit tunnel tests are driven by larger messages (typically 4KB, since thats the streaming lib fragmentation size)
14:42 <+bla> detonate: Yes, there are outliers. There will always be _some_ (that's inherent to estimation, and modeling in general). However, the separation between really slow and really fast clients (putting a threshold at around 400 ms), is ok-ish
14:42 <+detonate> ok
14:43 <+bla> jrandom: Indeed. Once I get that working (in not a Java buff...), I'll also test using the larger messages
14:43 <+bla> detonate: Now, I'd like to make the separation between fast and really-fast peers in a better way.
14:43 < jrandom> cool, i'll see if i can bounce you a modified TestJob for that
14:44 <+bla> I'll report when I have new results.
14:44 < jrandom> kickass
14:45 < jrandom> ok cool, anyone else have anything for 3) Bayesian peer profiling?
14:46 < jrandom> if not, moving on to 4) Q status
14:46 < jrandom> As mentioned in the email, rumor has it Aum is making progress on a new web interface
14:47 < jrandom> i don't know much about it, or the status details on the rest of the Q updates, but i'm sure we'll hear more soon
14:48 < jrandom> anyone have anything on Q to bring up? or shall we make this a rapid fire agenda item and move on to 5) ???
14:49 < jrandom> [consider us moved]
14:49 < jrandom> ok, anyone have anything else to bring up for the meeting?
14:50 < jrandom> defnax: announcing an i2p tracker to people in the i2p community would be great. to the outside world it might be a bit rough, since we aren't at 0.6 yet
14:50 < gott> Yes.
14:50 < jrandom> (or 1.0 ;)
14:50 < gott> I have some information to bring up on userland documentation efforts.
14:51 <+mancom> just for the record: on mancom.i2p there is a c# implementation of Q's client api (in its first incarnation)
14:51 < jrandom> oh cool, sup gott
14:51 < jrandom> ah nice1 mancom
14:51 < gott> I have previously written userland documentation for 0.4 i2p.
14:52 < jrandom> which i unforutnately obsoleted by changing a whole bunch of stuff :(
14:52 < gott> But it is entirely out-of-date with current i2p.
14:52 < gott> Accordingly, I am very interested in writing a defacto set of documentation that we can either (a) bundle with i2p or (b) have access via i2p.
14:53 < jrandom> wikked. docs to bundle with i2p (localized to the user's language, etc) would be great
14:53 <+cervantes> cool
14:53 < gott> I don't suggest bundling, but it is still a possible option, as a user can't access eepsites to read the manual if he doesn't know how to use or configure i2p ;-)
14:53 < gott> Okay.
14:53 < gott> But is it overkill ?
14:53 <+ant> <BS314159> what respectable program comes without man pages?
14:53 <+cervantes> and is it worth waiting til 1.0?
14:54 < gott> That is another question.
14:54 < jrandom> since development is fairly fluid, it might be worth focusing on context-specific help, rather than an overall user guide
14:54 < gott> BS314159: these are not manpages, as it will be platform-independent. Probably HTML.
14:54 <+cervantes> how much more structural changes are we due before then
14:54 < jrandom> for instance, it'd be nice to have better docs describing what the different config options *mean*, what their implications are, etc.
14:55 < gott> Okay, so I shall write an english and french localisation of a manual for i2p.
14:55 <+jdot> actually, we could use the inproxy to access the documentation even w/o i2p being installed.
14:55 < gott> Two major questions :
14:55 < jrandom> those could be kept up to date by virtue of being *in* the interface itself
14:55 <+cervantes> yeah context help would rock
14:55 < gott> (1) Bundled or accessible via manual.i2p ?
14:55 < gott> (2) For which version ?
14:55 < gott> yes
14:55 < jrandom> gott: i'm not sure it'd be wise to build a user guide yet
14:55 < gott> that's a great idea
14:56 < gott> do you mean to use the auto-update function to update the usermanual ?
14:56 < gott> jrandom: okay
14:56 < gott> but then how do you suggest context-specific help ?
14:56 < jrandom> oh, we can certainly deploy updates to the docs with the update process
14:56 <+cervantes> if/when it's time to do a manual then perhaps a manual.war can be dropped into a user's webapps folder if they want local access to the docs
14:57 < gott> I am thinking of a user-manual.
14:57 < gott> or a HOWTO.
14:57 < gott> I have no idea what you mean by context-specific help.
14:57 < gott> it's pretty straightforward.
14:57 < jrandom> gott: for instance, a set of human (non-ubergeek) readable info explaining wtf things on /config.jsp mean. that info would go *on* /config.jsp, or on an html page reachable from that config.jsp
14:58 < jrandom> a user-manual or howto would be great, but not until 1.0
14:59 < jrandom> there's already some work on that front in the forum @ http://forum.i2p.net/viewtopic.php?t=385
14:59 < gott> jrandom: yes.
14:59 < gott> well.
14:59 < gott> the information on config.jsp is pretty straightfoward already
15:00 < jrandom> otoh, we see questions about what bandwidth limits actually do, how the burst rates work, etc here all the time. it'd be great to have the answers on the page, rather than have people ask
15:00 < gott> heh
15:00 < jrandom> gott: its straightforward to you because you've been using i2p for almost two years
15:00 < gott> nevermind, 'configtunnels.jsp' could use some work.
15:00 < gott> okay.
15:00 <+cervantes> straightforward to the initiated perhaps, a n00b would be lost
15:01 < gott> this is, then, a more up-to-date selection of tasks :
15:01 <+cervantes> not sure the best way to present the help from an interface perspective
15:01 < gott> (1) Context-specific help on the webpages localised to user's language. A configuration variable can be set for the language interface, by default, loaded from $LANG path variable on linux
15:02 < gott> I'm not sure how java figures out the default locale under windows.
15:02 < gott> But this is a good start to localisation and documentation writing.
15:03 < gott> (2) For version 1.0, a HOWTO _accessed_ via i2p
15:03 < gott> I don't suggest bundling the HOWTO, as that is just overkill. Would be nice to keep i2p as small as possible, hmm ?
15:03 < jrandom> dood, its html. its tiny. even if its huge, html compresses *really* well
15:03 < jrandom> having a local manual would be very much preferred
15:03 < jrandom> especially since we can push updates
15:03 * gott shrugs
15:04 < gott> I suppose.
15:04 < gott> I just find it silly.
15:04 < gott> when you can just download it via the web.
15:04 < gott> but on the other hand, if the user can't figure out how to use i2p
15:04 < gott> he can't.
15:04 <+ant> <Synonymous2> Is aum around, i was looking at the specs for QuarterMaster
15:04 <+ant> <Synonymous2> * In order to help client-side searching, all data items are accompanied
15:04 <+ant> <Synonymous2> by a simple metadata schema - so far, just consisting of:
15:04 <+ant> <Synonymous2> - key - text name of key
15:04 <+jdot> put it on www.i2p.net so it is accessible via the intarweb and i2p.
15:04 <+jdot> and always up to date
15:05 < gott> yeah.
15:05 < gott> well, just use the update mechanism.
15:05 < gott> okay.
15:05 < gott> so, finalising :
15:05 < jrandom> sure, we can put it on the website too. we can spam it all over the net if it helps ;)
15:05 <+ant> <Synonymous2> I am wondering if Aum can implement the datastore so the metadata are seperated incase he wants to upgrade the storage system. Remember when Freenet wanted to change the storage system but was stuck
15:05 < gott> 1 : Localised interface and context-specific help.
15:05 < gott> 2 : Localised HOWTO for version 1.0
15:05 <+ant> <Synonymous2> oopse is this the meeting :)
15:05 < gott> Any additions ?
15:06 < gott> the HOWTO will cover a lot of extra i2p-network features.
15:06 < gott> where to get the latest porn ( j/k )
15:06 <+ant> <BS314159> manpage! :-)
15:06 < gott> manpages aren't platform-independent
15:06 < jrandom> cool, including things like Q, i2ptunnel, feedspace, i2p-bt, etc would be great for a howto
15:06 <+cervantes> the installer could be localised too I guess...
15:06 < gott> the i2p network has a hilariously large amount of french users
15:07 <+Ragnarok> you should clearly write the addressbook documentation I've never gotten around to :)
15:07 < gott> I'm sure they would appreciate a localised interface so they don't have to look at the disgusting english language
15:07 <+cervantes> hey it's mostly french already
15:07 < gott> true.
15:07 < gott> good ideas.
15:08 < gott> well, that is all I had to say.
15:08 < jrandom> ok cool, thanks gott, nice initiative
15:08 < gott> for now, I shall start on the context-specific stuff
15:08 < jrandom> Synonymous2: I'm not sure what Aum is doing on that front
15:08 < jrandom> bitchin'
15:08 < gott> and then, when a localisation option is added, the localised languages
15:08 <+bla> gott: Je _deteste_ Anglais! ;)
15:09 < gott> moi aussi
15:09 <+ant> <Synonymous2> Q, i2ptunnel, feedspace, i2p-bt, etc would be great for a howto, i think the wiki article should be updated for i2p to add this, i'll do that
15:09 <+cervantes> ewll you have william the conquerer to blame for that
15:09 < jrandom> heh
15:09 < gott> a wiki is good, but also non-official.
15:09 < gott> the manual has the element of certification.
15:09 < gott> it is more reassuring.
15:10 <+ant> <Synonymous2> if ppl want to come and look that would be helpful too, the freenet wikipedia article is also good describing the tools for freenet. As well, I see that the Freenet webpage is released under the GNU FDL, if i2p.net could do the same (or public domain) I could copy some stuff to wikipedia :)) if you want to do that
15:10 <+cervantes> we'd still be speaking anglo-saxon otherwise
15:10 < jrandom> everything i do which i 'have rights to' is released implicitly into the public domain
15:11 <+ant> <Synonymous2> i thought it was, if you can put that as a blurb on the webpage that would be great at your convience, the ppl at wikipedia are anal bout copyright :>
15:11 <+ant> <Synonymous2> :)))
15:11 < gott> jrandom: all the localisation I write will be public domain
15:11 < jrandom> otoh, outright copying the text is, er, not too helpful, as your copies will be out of date - just link to it, the web is there for a reason
15:11 < gott> I don't give a damn about any licenses.
15:12 < gott> also, last question :
15:12 <+ant> <Synonymous2> i was going to copy a few things like the chart and some graphics hehe
15:12 < gott> where are the .jsp for the router located ?
15:12 < jrandom> gott: http://dev.i2p/cgi-bin/cvsweb.cgi/apps/routerconsole/jsp/
15:13 < gott> ah
15:13 < gott> so, locally, they are in a .jar ?
15:13 < jrandom> gott: routerconsole.war
15:13 < jrandom> but you can't really edit them there, as they're precompiled into java
15:13 * gott nods
15:13 < gott> Sure.
15:14 < gott> Though, that's an inconvenience.
15:14 < gott> when localisation comes out, that might be changed ?
15:14 < jrandom> yep. lots of options though. if you work out the html that the jsps should render as, we can wire it in
15:14 <+cervantes> Synonymous: http://www.i2p.net/licenses
15:15 < gott> so you can have language packs
15:15 * gott nods
15:15 < gott> for now, it is just hardcoded
15:15 < jrandom> localization in java works by loading up per-language properties files with resources
15:15 < gott> but later on, it should be less restricted, I suggest
15:15 < jrandom> right right
15:16 < gott> awesome.
15:16 < gott> well, I'll use anonymous CVS then ;-)
15:16 < jrandom> bitchin'
15:16 <+ant> <BS314159> bla: is your raw data available anywhere?
15:16 < jrandom> bla has recently disconnected, but we'll see about getting some data available
15:17 < gott> btw, do we have anyone running i2p on openbsd ?
15:17 <+ant> <BS314159> it's be fun to let people try their own estimators
15:17 <+ant> <BS314159> sister:...23?
15:17 < jrandom> gott: yeah, i think detonate is
15:18 <+ant> <BS314159> ack
15:18 <+ant> <BS314159> cross-post
15:18 <+ant> <BS314159> curses!
15:18 < gott> is it even possible ? what are the java limitations regarding openbsd and i2p ?
15:18 < gott> okay.
15:18 < jrandom> BS314159: yeah, there's some good info about modifying your estimators up in the forum
15:18 <+cervantes> long meeting
15:18 < gott> if I ever have time, I might get it running and setup a port.
15:18 < gott> but that is long off and someone will probably do it before me ;-)
15:18 < jrandom> cervantes: check the logs, we've broken 2h before ;)
15:19 < jrandom> ok, anyone else have anything for the meeting?
15:20 < jrandom> if not
15:20 * jrandom winds up
15:20 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/137.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, April 12, 2005
===============================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,106 +1,100 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 138{% endblock %}
{% block content %}<h3>I2P dev meeting, April 19, 2005</h3>
<div class="irclog">
14:05 <@jrandom> 0) hi</p>
14:05 <@jrandom> 1) Net status</p>
14:05 <@jrandom> 2) SSU status</p>
14:05 <@jrandom> 3) Roadmap update</p>
14:05 <@jrandom> 4) Q status</p>
14:05 <@jrandom> 5) ???</p>
14:05 <@jrandom> 0) hi</p>
14:05 * jrandom waves</p>
14:05 <@jrandom> weekly status notes (posted a sec ago) up @ http://dev.i2p.net/pipermail/i2p/2005-April/000708.html</p>
14:06 * maestro^ beatboxes</p>
14:06 <+cervantes> evening</p>
14:06 <+protokol> susi23: you there?</p>
14:06 <@jrandom> while y'all read those exciting notes, lets jump on in to 1) net status</p>
14:06 <+protokol> oops, meeting</p>
14:07 <@jrandom> i dont really have much to add beyond what it says though. new release tomorrow, most likely, with the fixes incorporated so far, as well as some neat new contributions</p>
14:08 <@jrandom> anyone have any comments or concerns w/ the net status &&/|| the upcoming 0.5.0.7?</p>
14:10 <@jrandom> if not, moving on to 2) SSU status</p>
14:10 <+maestro^> i've been getting some of these errors: Wanted to build 2 tunnels, but throttled down to 0, due to concurrent requests (cpu overload?)</p>
14:10 <@jrandom> ah, yeah, thats the tunnel throttling issue</p>
14:10 <+protokol> will it support ftp?</p>
14:10 <@jrandom> its a bit... overzealous</p>
14:10 <+protokol> jk jk</p>
14:10 <@jrandom> !thwap protokol </p>
14:10 <+maestro^> heh, ok</p>
14:12 <@jrandom> ok, as for SSU, there's been a bunch of updates in the last week, and still further changes locally not yet committed</p>
14:13 <@jrandom> i havent been making any history.txt entries for the updates though, since its not used by anyone yet, so only people on the i2p-cvs list get to read the exciting details ;)</p>
14:14 <@jrandom> otoh, in the last few days after things have been pretty much working, while streamlining its operation i've found some choke points in the SDK</p>
14:14 <@jrandom> (and in the jobQueue). i've pulled those out now, locally, and testing continues.</p>
14:15 <@jrandom> we may have some alphas for the SSU transport this week, more likely this weekend though</p>
14:15 <@jrandom> not much more i have to say on that - anyone have any questions?</p>
14:16 <+Ragnarok> how much impact did the choke points have?</p>
14:17 <@jrandom> well, it varies - i'm measuring the impact upon the live net now, but on my local ssu network, two minor tweaks gave more than an order of magnitude improvement</p>
14:17 <@jrandom> but i don't expect that to occur on the live net</p>
14:17 <+Ragnarok> yikes</p>
14:18 <+Ragnarok> heh, ok</p>
14:18 <@jrandom> (at least, not until we move to 0.6 ;)</p>
14:20 <@jrandom> ok, following that lead, lets move to 3) Roadmap update</p>
14:21 <@jrandom> as mentioned in the notes, the dates and revs on the roadmap have been moved around. 0.5.1 dropped, with the further tunnel modifications pushed to 0.6.1</p>
14:21 <+cervantes> 3) Roadmap Skew</p>
14:21 <@jrandom> heh</p>
14:22 <@jrandom> yeah, when you run a fast CPU, it skews the clock more frequently. similary... ;)</p>
14:22 <@jrandom> ^ry^rly</p>
14:23 <+cervantes> ooh is that a hint of an ego? I never would have thought! :)</p>
14:23 <@jrandom> but yeah, unfortunately, a 0.6 rev in april just isnt going to happen</p>
14:23 <@jrandom> hehe</p>
14:23 <@jrandom> cervantes: dont worry, its tempered by the fact that its taken 2 years to get this far ;)</p>
14:25 <@jrandom> we will probably have some -X builds for people to brea^Wtest SSU on the live net while i'm offline, but there won't be a 0.6 rev until i'm back</p>
14:25 <@jrandom> (and, like last year, i have no idea how long it'll take to get hooked up again, but hopefully less than a month)</p>
14:25 <+cervantes> heh, if anyone here is a little deserving of self-appreciation then I guess it would be you ;-)</p>
14:26 <+polecat> Where you going, jrandom ?</p>
14:27 <+cervantes> $somewhere</p>
14:27 <@jrandom> dunno</p>
14:27 <@jrandom> (thankfully, $somewhere is a runtime expression ;)</p>
14:27 <+cervantes> jrandom: do you envisage a months downtime?</p>
14:27 <+maestro^> jr: walk around the neighborhood and setup a wireless relay network from someone else's link ;]</p>
14:27 <@jrandom> depends on the internet situation where i end up cervantes.</p>
14:28 <@jrandom> i'm quite likely to hop online occationally of course, though</p>
14:28 <+protokol> polecat: lol</p>
14:28 <+cervantes> I would have though you would have got the relocation class method pretty slick by now</p>
14:28 < Teal`c> lets move to .6 now and work the bugs out as we go along</p>
14:28 <+cervantes> *thought</p>
14:28 <+cervantes> cool, Teal'c you can do Q&A</p>
14:29 <@jrandom> Teal`c: "work the bugs out" == fix the code == (have a coder who knows the code to fix it)</p>
14:29 < Teal`c> ya, I'd like that.</p>
14:29 < Teal`c> I know some perl</p>
14:29 * cervantes sets bugzilla > tealc@mail.i2p</p>
14:29 <@jrandom> word Teal`c, we can always use some help testing</p>
14:30 <@jrandom> especially in automation of tests</p>
14:31 <@jrandom> ok, anything else on 3) or shall we move to 4) Q status</p>
14:31 <+polecat> I see. Good luck getting stable Internet back.</p>
14:31 <+ant> &lt;jrandom&gt; hrm, aum seems to be sleeping still</p>
14:31 <@jrandom> thanks. i'm sure i'll find a way ;)</p>
14:32 <@jrandom> ok, I don't really have much more to add beyond whats in the status notes</p>
14:32 <@jrandom> aum's code is in cvs now though, so the hardcore can grab it and start hacking</p>
14:32 <+maestro^> shweet</p>
14:33 <@jrandom> yeah, definitely. currently things are all GPL (since one component links against I2PTunnel), but I hear aum is working on some refactoring so it'll end up LGPL</p>
14:34 <@jrandom> (but dont ask me what the implications of licensing is when it comes to xmlrpc ;)</p>
14:34 <@jrandom> ok, anyone have anything on 4) to bring up?</p>
14:36 <@jrandom> ok, if not, moving on to 5) ???</p>
14:36 <@jrandom> anyone have anything else to bring up for the meeting?</p>
14:36 <+polecat> I would like to say a few words for this occasion.</p>
14:37 <+polecat> Hinkle finkle dinkle doo.</p>
14:37 <@jrandom> mmmhmm.</p>
14:37 <@jrandom> ok, anyone have anything to bring up in a human language? :)</p>
14:38 < defnax> what moving on 5?</p>
14:39 <+maestro^> long live spacerace! long live i2p!</p>
14:39 <@jrandom> hmm defnax?</p>
14:41 < defnax> on 5 o'clock in the morning?</p>
14:41 < defnax> in 5 hours?</p>
14:41 <+cervantes> wrt xmlrpc, copyright is retained on the specification, but no restrictions placed upon implementation</p>
14:42 <@jrandom> defnax: agenda item 5: "???", where we discuss other issues</p>
14:43 <+maestro^> jr: have you committed those optimization changes?</p>
14:43 <@jrandom> cervantes: my jab related to the question of whether using a GPL'ed app's xmlrpc API is viral (but merely a rhetorical question)</p>
14:43 <@jrandom> maestro^: nope</p>
14:43 * jrandom tests before committing</p>
14:43 <+maestro^> excellent! whats your eta on that?</p>
14:44 <@jrandom> later tonight, maybe, else tomorrow for the release</p>
14:45 <@jrandom> ok, if there's nothing else</p>
14:45 * jrandom winds up</p>
14:45 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
14:05 <@jrandom> 0) hi
14:05 <@jrandom> 1) Net status
14:05 <@jrandom> 2) SSU status
14:05 <@jrandom> 3) Roadmap update
14:05 <@jrandom> 4) Q status
14:05 <@jrandom> 5) ???
14:05 <@jrandom> 0) hi
14:05 * jrandom waves
14:05 <@jrandom> weekly status notes (posted a sec ago) up @ http://dev.i2p.net/pipermail/i2p/2005-April/000708.html
14:06 * maestro^ beatboxes
14:06 <+cervantes> evening
14:06 <+protokol> susi23: you there?
14:06 <@jrandom> while y'all read those exciting notes, lets jump on in to 1) net status
14:06 <+protokol> oops, meeting
14:07 <@jrandom> i dont really have much to add beyond what it says though. new release tomorrow, most likely, with the fixes incorporated so far, as well as some neat new contributions
14:08 <@jrandom> anyone have any comments or concerns w/ the net status &&/|| the upcoming 0.5.0.7?
14:10 <@jrandom> if not, moving on to 2) SSU status
14:10 <+maestro^> i've been getting some of these errors: Wanted to build 2 tunnels, but throttled down to 0, due to concurrent requests (cpu overload?)
14:10 <@jrandom> ah, yeah, thats the tunnel throttling issue
14:10 <+protokol> will it support ftp?
14:10 <@jrandom> its a bit... overzealous
14:10 <+protokol> jk jk
14:10 <@jrandom> !thwap protokol
14:10 <+maestro^> heh, ok
14:12 <@jrandom> ok, as for SSU, there's been a bunch of updates in the last week, and still further changes locally not yet committed
14:13 <@jrandom> i havent been making any history.txt entries for the updates though, since its not used by anyone yet, so only people on the i2p-cvs list get to read the exciting details ;)
14:14 <@jrandom> otoh, in the last few days after things have been pretty much working, while streamlining its operation i've found some choke points in the SDK
14:14 <@jrandom> (and in the jobQueue). i've pulled those out now, locally, and testing continues.
14:15 <@jrandom> we may have some alphas for the SSU transport this week, more likely this weekend though
14:15 <@jrandom> not much more i have to say on that - anyone have any questions?
14:16 <+Ragnarok> how much impact did the choke points have?
14:17 <@jrandom> well, it varies - i'm measuring the impact upon the live net now, but on my local ssu network, two minor tweaks gave more than an order of magnitude improvement
14:17 <@jrandom> but i don't expect that to occur on the live net
14:17 <+Ragnarok> yikes
14:18 <+Ragnarok> heh, ok
14:18 <@jrandom> (at least, not until we move to 0.6 ;)
14:20 <@jrandom> ok, following that lead, lets move to 3) Roadmap update
14:21 <@jrandom> as mentioned in the notes, the dates and revs on the roadmap have been moved around. 0.5.1 dropped, with the further tunnel modifications pushed to 0.6.1
14:21 <+cervantes> 3) Roadmap Skew
14:21 <@jrandom> heh
14:22 <@jrandom> yeah, when you run a fast CPU, it skews the clock more frequently. similary... ;)
14:22 <@jrandom> ^ry^rly
14:23 <+cervantes> ooh is that a hint of an ego? I never would have thought! :)
14:23 <@jrandom> but yeah, unfortunately, a 0.6 rev in april just isnt going to happen
14:23 <@jrandom> hehe
14:23 <@jrandom> cervantes: dont worry, its tempered by the fact that its taken 2 years to get this far ;)
14:25 <@jrandom> we will probably have some -X builds for people to brea^Wtest SSU on the live net while i'm offline, but there won't be a 0.6 rev until i'm back
14:25 <@jrandom> (and, like last year, i have no idea how long it'll take to get hooked up again, but hopefully less than a month)
14:25 <+cervantes> heh, if anyone here is a little deserving of self-appreciation then I guess it would be you ;-)
14:26 <+polecat> Where you going, jrandom ?
14:27 <+cervantes> $somewhere
14:27 <@jrandom> dunno
14:27 <@jrandom> (thankfully, $somewhere is a runtime expression ;)
14:27 <+cervantes> jrandom: do you envisage a months downtime?
14:27 <+maestro^> jr: walk around the neighborhood and setup a wireless relay network from someone else's link ;]
14:27 <@jrandom> depends on the internet situation where i end up cervantes.
14:28 <@jrandom> i'm quite likely to hop online occationally of course, though
14:28 <+protokol> polecat: lol
14:28 <+cervantes> I would have though you would have got the relocation class method pretty slick by now
14:28 < Teal`c> lets move to .6 now and work the bugs out as we go along
14:28 <+cervantes> *thought
14:28 <+cervantes> cool, Teal'c you can do Q&A
14:29 <@jrandom> Teal`c: "work the bugs out" == fix the code == (have a coder who knows the code to fix it)
14:29 < Teal`c> ya, I'd like that.
14:29 < Teal`c> I know some perl
14:29 * cervantes sets bugzilla > tealc@mail.i2p
14:29 <@jrandom> word Teal`c, we can always use some help testing
14:30 <@jrandom> especially in automation of tests
14:31 <@jrandom> ok, anything else on 3) or shall we move to 4) Q status
14:31 <+polecat> I see. Good luck getting stable Internet back.
14:31 <+ant> <jrandom> hrm, aum seems to be sleeping still
14:31 <@jrandom> thanks. i'm sure i'll find a way ;)
14:32 <@jrandom> ok, I don't really have much more to add beyond whats in the status notes
14:32 <@jrandom> aum's code is in cvs now though, so the hardcore can grab it and start hacking
14:32 <+maestro^> shweet
14:33 <@jrandom> yeah, definitely. currently things are all GPL (since one component links against I2PTunnel), but I hear aum is working on some refactoring so it'll end up LGPL
14:34 <@jrandom> (but dont ask me what the implications of licensing is when it comes to xmlrpc ;)
14:34 <@jrandom> ok, anyone have anything on 4) to bring up?
14:36 <@jrandom> ok, if not, moving on to 5) ???
14:36 <@jrandom> anyone have anything else to bring up for the meeting?
14:36 <+polecat> I would like to say a few words for this occasion.
14:37 <+polecat> Hinkle finkle dinkle doo.
14:37 <@jrandom> mmmhmm.
14:37 <@jrandom> ok, anyone have anything to bring up in a human language? :)
14:38 < defnax> what moving on 5?
14:39 <+maestro^> long live spacerace! long live i2p!
14:39 <@jrandom> hmm defnax?
14:41 < defnax> on 5 o'clock in the morning?
14:41 < defnax> in 5 hours?
14:41 <+cervantes> wrt xmlrpc, copyright is retained on the specification, but no restrictions placed upon implementation
14:42 <@jrandom> defnax: agenda item 5: "???", where we discuss other issues
14:43 <+maestro^> jr: have you committed those optimization changes?
14:43 <@jrandom> cervantes: my jab related to the question of whether using a GPL'ed app's xmlrpc API is viral (but merely a rhetorical question)
14:43 <@jrandom> maestro^: nope
14:43 * jrandom tests before committing
14:43 <+maestro^> excellent! whats your eta on that?
14:44 <@jrandom> later tonight, maybe, else tomorrow for the release
14:45 <@jrandom> ok, if there's nothing else
14:45 * jrandom winds up
14:45 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/138.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, April 19, 2005
===============================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,64 +1,58 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 139{% endblock %}
{% block content %}<h3>I2P dev meeting, April 26, 2005</h3>
<div class="irclog">
14:10 <@jrandom> 0) hi</p>
14:10 <@jrandom> 1) Net status</p>
14:10 <@jrandom> 2) SSU status</p>
14:10 <@jrandom> 3) Unit test bounty</p>
14:10 <@jrandom> 4) ???</p>
14:10 <@jrandom> 0) hi</p>
14:10 * jrandom waves</p>
14:10 <@jrandom> (late) weekly status notes are up @ http://dev.i2p.net/pipermail/i2p/2005-April/000723.html</p>
14:10 < bla> hi</p>
14:11 <@jrandom> while y'all read that tome, lets jump on into 1) Net status</p>
14:12 <@jrandom> the previous set of problems we saw with some eepsites going offline in 0.5.0.6 seems to be resolved, though there are a few people who have been running into other problems with their sites</p>
14:13 <@jrandom> i've seen some increased torrent activity at some trackers as well, though it hasn't caused any problems on irc from what i can tell</p>
14:13 < laberhorst> net status: fairly well beside the not reachable prob :-)</p>
14:13 <@jrandom> heh</p>
14:13 <@jrandom> yeah, i'm stil not sure whats going on with your site. we can debug further after the meeting</p>
14:14 <@jrandom> other than that, anyone else have any questions/comments/concerns wrt the net status / 0.5.0.7?</p>
14:16 <@jrandom> ok, if not, moving on to 2) SSU status</p>
14:16 <@jrandom> [insert hand waving here]</p>
14:17 < Lorie> Good morning.</p>
14:17 <@jrandom> i know, i'm dragging my heels a bit by not pushing it out faster, and it does perform really well as is. still, there are some issues i'm not comfortable with yet, so y'all will have to bear with me a bit during this testing</p>
14:18 <@smeghead> i commend you for not foisting crapware on us :)</p>
14:18 <@jrandom> i'm hoping this week we'll have some further live net tests though (fingers crossed)</p>
14:19 <@jrandom> well, i've foisted enough bugs on y'all so far</p>
14:19 < Lorie> you're dragging your heels, are you ?</p>
14:19 * Lorie eyes smeghead</p>
14:19 < bla> jrandom: Just to make things clear: We could even have an intermediate period in which clients can be both UDP and TCP?</p>
14:20 <@jrandom> bla: yes. i've got a test network now with some TCP-only and some both TCP and UDP. its kind of neat running the tunnels through both :)</p>
14:20 <@jrandom> the live net will actually handle that as well, ignoring any UDP addresses (for people who don't yet support it)</p>
14:20 <@smeghead> and that's given us lots of protein, but we don't want to over-indulge</p>
14:21 < bla> jrandom: Nice! That's good for the transition</p>
14:23 <@jrandom> aye, thats the hope. still, there's lots of work to do[/obligatory]</p>
14:23 <@jrandom> while our transport is SSU - "SEMIreliable Secure UDP" - we still need to try to be kind of reliable</p>
14:24 <@jrandom> i've followed a bunch of research out there on the net, watching whats worked best, and while we could just be lazy and fire & forget, there's a lot to be gained by doing some simple tcp-esque reliability, which is what i'm hacking on now</p>
14:25 <@jrandom> otoh, since its just semireliable, if it doesn't get ACKed quickly we can just drop the message, rather than drop the connection</p>
14:26 < Lorie> yes</p>
14:26 < Lorie> do be reliable; time is a luxury one has</p>
14:27 <@jrandom> thats about all i have to bring up for 2) SSU status. anyone have any questions/comments/concerns, or shall we move on to 3) Unit test bounty?</p>
14:28 < jrandom2p> consider us moved</p>
14:29 < jrandom2p> ok, duck posted up a good summary about whats up and the importance of the unit test bounty the other day, and there's a lot of detail referenced from the site.</p>
14:30 < jrandom2p> this is a good chance for someone to dig into i2p a bit and get a little cash back in the process ;)</p>
14:30 < jrandom2p> but anyway, y'all can read all that stuff. does anyone have any questions on it?</p>
14:31 < jrandom2p> ok, if not, moving on to 4) ???</p>
14:32 <@smeghead> anyone tried that emma code coverage suite?</p>
14:32 < jrandom2p> there's been a lot of various things going on in the last week, though i'm not sure whats ready for discussion yet. anyone have anything they want to bring up?</p>
14:33 < jrandom2p> not i</p>
14:33 <@duck> *hick*</p>
14:34 <@smeghead> either duck is inebriated, or he has spotted a redneck</p>
14:34 <@duck> !former</p>
14:35 < jrandom2p> (to evaluate as a shell command or c/java... ;)</p>
14:36 < jrandom2p> anyone else have anything to bring up for the meeting?</p>
14:36 * jrandom2p likes short meetings, leaves more time for coding</p>
14:36 <@smeghead> and drinking apparently :)</p>
14:36 <@duck> & drinking</p>
14:37 <@smeghead> bah lag</p>
14:37 < jrandom2p> heh</p>
14:38 < jrandom2p> ok, time to get back to dri^Wworking</p>
14:38 * jrandom2p winds up</p>
14:38 * jrandom2p *baf*s the meeting closed</p>
</div>
{% endblock %}
14:10 <@jrandom> 0) hi
14:10 <@jrandom> 1) Net status
14:10 <@jrandom> 2) SSU status
14:10 <@jrandom> 3) Unit test bounty
14:10 <@jrandom> 4) ???
14:10 <@jrandom> 0) hi
14:10 * jrandom waves
14:10 <@jrandom> (late) weekly status notes are up @ http://dev.i2p.net/pipermail/i2p/2005-April/000723.html
14:10 < bla> hi
14:11 <@jrandom> while y'all read that tome, lets jump on into 1) Net status
14:12 <@jrandom> the previous set of problems we saw with some eepsites going offline in 0.5.0.6 seems to be resolved, though there are a few people who have been running into other problems with their sites
14:13 <@jrandom> i've seen some increased torrent activity at some trackers as well, though it hasn't caused any problems on irc from what i can tell
14:13 < laberhorst> net status: fairly well beside the not reachable prob :-)
14:13 <@jrandom> heh
14:13 <@jrandom> yeah, i'm stil not sure whats going on with your site. we can debug further after the meeting
14:14 <@jrandom> other than that, anyone else have any questions/comments/concerns wrt the net status / 0.5.0.7?
14:16 <@jrandom> ok, if not, moving on to 2) SSU status
14:16 <@jrandom> [insert hand waving here]
14:17 < Lorie> Good morning.
14:17 <@jrandom> i know, i'm dragging my heels a bit by not pushing it out faster, and it does perform really well as is. still, there are some issues i'm not comfortable with yet, so y'all will have to bear with me a bit during this testing
14:18 <@smeghead> i commend you for not foisting crapware on us :)
14:18 <@jrandom> i'm hoping this week we'll have some further live net tests though (fingers crossed)
14:19 <@jrandom> well, i've foisted enough bugs on y'all so far
14:19 < Lorie> you're dragging your heels, are you ?
14:19 * Lorie eyes smeghead
14:19 < bla> jrandom: Just to make things clear: We could even have an intermediate period in which clients can be both UDP and TCP?
14:20 <@jrandom> bla: yes. i've got a test network now with some TCP-only and some both TCP and UDP. its kind of neat running the tunnels through both :)
14:20 <@jrandom> the live net will actually handle that as well, ignoring any UDP addresses (for people who don't yet support it)
14:20 <@smeghead> and that's given us lots of protein, but we don't want to over-indulge
14:21 < bla> jrandom: Nice! That's good for the transition
14:23 <@jrandom> aye, thats the hope. still, there's lots of work to do[/obligatory]
14:23 <@jrandom> while our transport is SSU - "SEMIreliable Secure UDP" - we still need to try to be kind of reliable
14:24 <@jrandom> i've followed a bunch of research out there on the net, watching whats worked best, and while we could just be lazy and fire & forget, there's a lot to be gained by doing some simple tcp-esque reliability, which is what i'm hacking on now
14:25 <@jrandom> otoh, since its just semireliable, if it doesn't get ACKed quickly we can just drop the message, rather than drop the connection
14:26 < Lorie> yes
14:26 < Lorie> do be reliable; time is a luxury one has
14:27 <@jrandom> thats about all i have to bring up for 2) SSU status. anyone have any questions/comments/concerns, or shall we move on to 3) Unit test bounty?
14:28 < jrandom2p> consider us moved
14:29 < jrandom2p> ok, duck posted up a good summary about whats up and the importance of the unit test bounty the other day, and there's a lot of detail referenced from the site.
14:30 < jrandom2p> this is a good chance for someone to dig into i2p a bit and get a little cash back in the process ;)
14:30 < jrandom2p> but anyway, y'all can read all that stuff. does anyone have any questions on it?
14:31 < jrandom2p> ok, if not, moving on to 4) ???
14:32 <@smeghead> anyone tried that emma code coverage suite?
14:32 < jrandom2p> there's been a lot of various things going on in the last week, though i'm not sure whats ready for discussion yet. anyone have anything they want to bring up?
14:33 < jrandom2p> not i
14:33 <@duck> *hick*
14:34 <@smeghead> either duck is inebriated, or he has spotted a redneck
14:34 <@duck> !former
14:35 < jrandom2p> (to evaluate as a shell command or c/java... ;)
14:36 < jrandom2p> anyone else have anything to bring up for the meeting?
14:36 * jrandom2p likes short meetings, leaves more time for coding
14:36 <@smeghead> and drinking apparently :)
14:36 <@duck> & drinking
14:37 <@smeghead> bah lag
14:37 < jrandom2p> heh
14:38 < jrandom2p> ok, time to get back to dri^Wworking
14:38 * jrandom2p winds up
14:38 * jrandom2p *baf*s the meeting closed

10
i2p2www/meetings/139.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, April 26, 2005
===============================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,199 +1,193 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 140{% endblock %}
{% block content %}<h3>I2P dev meeting, May 3, 2005</h3>
<div class="irclog">
14:08 < jrandom> 0) hi</p>
14:08 < jrandom> 1) Net status</p>
14:08 < jrandom> 2) SSU status</p>
14:08 < jrandom> 3) i2phex</p>
14:08 < jrandom> 4) awol</p>
14:08 < jrandom> 5) ???</p>
14:08 < jrandom> 0) hi</p>
14:08 * jrandom waves</p>
14:08 < jrandom> weekly status notes posted nearly an hour early @ http://dev.i2p.net/pipermail/i2p/2005-May/000738.html</p>
14:09 * Masterboy waves back:P</p>
14:10 < jrandom> ok, jumping into 1) Net status</p>
14:10 < jrandom> i don't really have too much more to add, though it does appear that we may be up for some turbulance from the azureus influx</p>
14:11 < jrandom> hopefully it'll hold up well enough though, we'll see</p>
14:11 < Masterboy> no big probs for me and i can't remember the little ones.</p>
14:11 < jrandom> heh cool</p>
14:11 < jrandom> anyone else have any questions/comments/concerns wrt the current net status? </p>
14:11 < sirup> is azureus using out proxies?</p>
14:12 < jrandom> heh i hope not</p>
14:12 < jrandom> its probably just people trying it out after seeing the option listed</p>
14:12 <@smeghead> most will bugger off in a week or so</p>
14:13 < Masterboy> :D</p>
14:13 <+DrWoo> smeghead: that's not good</p>
14:13 < sirup> so they wrap two different networks under one hood</p>
14:13 <+cervantes> it's not mentioned in the az release notes</p>
14:13 <+cervantes> although it is listed in the plugins section</p>
14:14 < ant> &lt;cat-a-puss&gt; There is a link that mentions it on the left of their main page</p>
14:14 < jrandom> it'll be great once 0.6 is out and we can handle the increased user load</p>
14:14 <+DrWoo> jrandom: what is the current status of getting out a build to cope with more users?</p>
14:14 < jrandom> yeah, azureus is currently our largest referrer to the website, well more than even the /. references</p>
14:15 < jrandom> DrWoo: no chance. </p>
14:15 < sirup> don't let that stress you and put out 0.6 too early</p>
14:15 * eAi sets unreasonable bandwidth limit to stop people haxoring my download speed</p>
14:15 < ant> &lt;cat-a-puss&gt; how big of a network will .6 support?</p>
14:15 < jrandom> DrWoo: 0.6 is the solution, and that'll be ready when its ready :)</p>
14:15 <+cervantes> there are 445 google hits for "i2p" and "azureus"</p>
14:15 < jrandom> heh eAi </p>
14:16 <+cervantes> I must say I was impressed with the throughput of the test SSU net</p>
14:16 < Masterboy> w00t cervantes:)</p>
14:16 <+DrWoo> jrandom: you know I love ya but your shedule is slipping like a $5 hooker's panties ;)</p>
14:16 < jrandom> cat-a-puss: it removes our current bottleneck to the point that i don't see the next bottleneck clearly. i hope it'll handle into the thousands.</p>
14:16 <+cervantes> managed to max out my DSL connection with a straight http file transfer</p>
14:17 < jrandom> damn straight DrWoo ;) if it could be done faster, that'd be great, but i've got to move next week, so there really isn't any alternative</p>
14:17 < sirup> cervantes: 0 hops both ends ;)</p>
14:18 < jrandom> sirup: sure, but the point is the SSU transport was able to handle it</p>
14:18 <+DrWoo> jrandom: yikes that sux, good luck :)</p>
14:18 < Teal`c__> there is an alternative. I'm calling toad, he'll finish it up while you're in tahiti</p>
14:18 <@smeghead> movin' on up, to the east side, to a deluxe apartment in the skyyyyy</p>
14:18 < shendaras> You have a place in mind, jrandom, or is it up in the air where you end up?</p>
14:19 <+cervantes> *mute*</p>
14:19 < jrandom> heh</p>
14:19 < jrandom> i think i know what country i'll end up in. beyond that, not really</p>
14:19 < jrandom> ok, anyway, back onto the agenda</p>
14:19 < jrandom> anything else on 1) Net status, or shall we move on to 2) SSU status?</p>
14:20 < Masterboy> move</p>
14:20 < jrandom> consider us moved</p>
14:21 < jrandom> ok, as described in the status notes and as cervantes said a minute ago, things are looking promising</p>
14:22 < jrandom> this first round of live net tests caught a few bugs but also helped expose some of the tradeoffs in bandwidth, latency, and tcp-friendliness</p>
14:23 < Masterboy> how can one join a test net?:P</p>
14:23 < jrandom> thats the thing - the ssu testing is done on the live net</p>
14:24 < jrandom> if you look in the netDb, you'll see that some peers have both TCP and SSU addresses, while almost everyone else has just a TCP address. </p>
14:24 < jrandom> peers who know how to talk via SSU try that first, but fall back on TCP if the SSU port isn't reachable.</p>
14:25 < jrandom> still, and i can't emphesize this enough, ssu is not production ready. it will break, and it will cause problems, so people should not use it except as part of explicit tests</p>
14:25 < Masterboy> thanks:)</p>
14:26 < jrandom> for now, everyone should disable ssu, but in the next day or so there'll be more info made available on my blog for the second round of tests</p>
14:27 < jrandom> ok, i think that and the email covered pretty much what i have to bring up wrt ssu. anyone have any questions/comments/concerns?</p>
14:27 < Teal`c__> jrandom: can we use ssu while your gone ?</p>
14:28 < jrandom> probably, but people may want to talk to other users to see if it acts up, and if it does, just disable it</p>
14:29 < shendaras> What's your new SACK technique? =)</p>
14:29 < jrandom> i've still got almost a week of hacking time left, so there's going to be more improvement</p>
14:30 <+bla> jrandom: I was just thinking... When there is a SSU connection between two nodes, do they drop the TCP connection between them (since that's not necessary then)?</p>
14:30 < jrandom> heh shendaras, its just exploiting the small message size and fixed fragmentation to let the receiver transmit explicit ACKs/NACKs for a full message in a bitfield, rather than ACKing or NACKing each fragment separately</p>
14:31 < jrandom> bla: correct, they never establish a TCP connection if SSU is available</p>
14:31 < jrandom> the two transports 'bid' on each message being sent, and the SSU transport is configured to bid 'lower' than the TCP transport</p>
14:31 <+bla> jrandom: That's good, but it means I'll have to update my theland.i2p scripts :(... ;)</p>
14:32 < jrandom> heh well, yeah too bad ;)</p>
14:32 < jrandom> (the new peers.jsp may be what you're after though)</p>
14:33 <+bla> jrandom: I'll have a look. But I don't plan on using SSU until it is ready, though</p>
14:33 <+cervantes> perhaps we should all stay on TCP so bla doesn't have to do any coding</p>
14:34 < jrandom> heh </p>
14:34 < jrandom> cool bla, yeah, no rush</p>
14:34 <+cervantes> ;)</p>
14:34 <+bla> cervantes: ;) </p>
14:35 <+cervantes> will there be any situations where an SSU connection is not appropriate and a TCP one would be preferred?</p>
14:36 * Masterboy pokes jr</p>
14:36 < jrandom> the current default setup prefers an established TCP connection to an unestablished SSU connection</p>
14:36 < jrandom> (you can override that with a config flag, i think its documented in the history.txt)</p>
14:37 <@smeghead> there are some people who've claimed their ISPs block UDP altogether</p>
14:37 < jrandom> but in general, no i can't think of why you'd want to go TCP when SSU is available</p>
14:37 <+cervantes> yup I know about the config option...but I mean are there circumstances where it would be better to use TCP instead of UDP packets</p>
14:37 < jrandom> smeghead: there are some people who've claimed elvis was a martian</p>
14:38 <+cervantes> so it's good just as a fallback</p>
14:38 < jrandom> cervantes: none i can think of, as long as ssu is available by both peers</p>
14:39 < jrandom> perhaps as a fallback, though it does raise issues of restricted routes, as all peers must be able to contact all peers.</p>
14:40 < jrandom> if we allow TCP only nodes, that means everyone must be reachable through TCP and UDP</p>
14:41 < Teal`c__> :~(</p>
14:41 < jrandom> for this summer, we'll probably support both, but i'm inclined to lean towards udp only</p>
14:41 < entroy> Hi, can any one tell me where I can go to ask a q about setting up 12p and Azureus?</p>
14:41 < jrandom> (until 2.0)</p>
14:42 < jrandom> hi entroy, #i2p-chat may be able to help, or forum.i2p.net. we're in our weekly dev meeting at the moment, but can help you out afterwards if you're still having trouble</p>
14:42 <+cervantes> here they come, repel borders :)</p>
14:42 < jrandom> cervantes: anyone who can make it onto irc is one of us :)</p>
14:42 <@smeghead> better call the Minutemen</p>
14:43 < Teal`c__> liverpool or chelsea ?!</p>
14:43 < entroy> ok, thx</p>
14:43 < ant> &lt;cat-a-puss&gt; jrandom: WRT bitfields, if we assume most of the packets are going to be successfully received, then the bitfields would be almost all 1's. Wouldn't it be more efficent to list the number of NACKS and then encode them ECC style.</p>
14:43 <+cervantes> jrandom: are you sure about that...someone mentioned an mschat client earlier</p>
14:43 <+cervantes> ;-)</p>
14:45 < jrandom> cat-a-puss: there are a few options, but when you look at the actual message size, its pretty hard to beat- tunnel messages, which are 4x as common as every other message, will require at *most* two fragments - only two bits</p>
14:45 < Teal`c__> &lt;steve&gt; # Appears as TIKI</p>
14:45 < jrandom> streaming lib messages between the endpoint and gateway is only 4KB - up to 8 bits, or 2 bytes wiwth the bitfields</p>
14:45 < jrandom> that is, assuming the absolute smallest MTU</p>
14:46 < jrandom> with 1492 (or 1472, depending on who is counting), you can handle most anything in a single bitfield byte</p>
14:46 < ant> &lt;cat-a-puss&gt; jrandom: ah, so the bitfields are only for fragments, not for each packet then?</p>
14:47 < jrandom> right, if a message is partially received, you send back the bitfield for the received fragments of that message</p>
14:47 < ant> &lt;cat-a-puss&gt; ok</p>
14:47 < jrandom> message ids are unfortunately completely random and unordered, so we can't use tcp style sequence numbers</p>
14:48 < jrandom> (and, well, we dont want that overhead either)</p>
14:49 < jrandom> ok, if there's nothing else on 2) SSU, lets move on to 3) i2phex</p>
14:49 < jrandom> sirup: you 'round?</p>
14:49 < ant> &lt;cat-a-puss&gt; quickly:why random?</p>
14:50 * sirup is lurking</p>
14:50 < jrandom> cat-a-puss: message ids are exposed to peers - we don't want them to know that one message is related to another message (the one with an earlier sequence #)</p>
14:50 < ant> &lt;cat-a-puss&gt; ok</p>
14:51 < jrandom> heya sirup, i posted up some general info to the list, but if you could give us an update, that'd be great</p>
14:52 < sirup> well. first tests were successfull</p>
14:52 < jrandom> [w3wt]</p>
14:52 < sirup> but it also seems that we need tweaking with the time out settings. connections between peers don't hold up for some reason</p>
14:53 < sirup> so it's not run and gun right now :)</p>
14:53 < sirup> but i also expected that, cause i didn't change anything concerning timeouts and such</p>
14:54 < sirup> generally, i would be happy if some people would be ready to help me test it until a bearable state is reached</p>
14:55 < sirup> several instances on the same machine only get you so far...</p>
14:55 < sirup> oh. and any experience/input is welcome. best done wiht mail to sirup@mail.i2p</p>
14:56 < sirup> a forum would be great too (i can't have any at my destination, 'cause i'm not 24/7)</p>
14:56 < sirup> that's it :)</p>
14:56 < jrandom> wikked</p>
14:56 < jrandom> cervantes: any way we could get an i2phex section added in there?</p>
14:57 <+cervantes> sure could</p>
14:57 * sirup wonders who's downloading that crappy commons licensed music from me :)</p>
14:58 <@smeghead> hey, you can build more crap on top of that crap at least :)</p>
14:58 <+cervantes> sirup: I take it "sirup" is your moniker on the forum</p>
14:58 < sirup> that would be neat</p>
14:58 < sirup> yes</p>
14:59 < ant> &lt;BS314159&gt; status notes?</p>
15:00 < jrandom> ok great. its looking really quite promising, sirup has done some great work, so people should swing over to sirup.i2p and read up on whats goin' on :)</p>
15:00 <@smeghead> mailing list?</p>
15:00 < RevDuck> or www.i2phex.tk</p>
15:01 < sirup> mailing list would also be nice, of course</p>
15:01 < sirup> lol. i2phex.tk is fake. get your dialers there :)</p>
15:01 <+cervantes> I2Phex forum added</p>
15:01 < jrandom> !stab duck</p>
15:02 <+cervantes> sirup is moderator</p>
15:02 < Masterboy> :D</p>
15:02 <+cervantes> sirup: let me know if you want to change the description text</p>
15:02 < jrandom> sirup: if you'd like an i2phex and i2phex-cvs list, lemmie know, they're easy enough to add</p>
15:02 < jrandom> (though at the moment, it may be simpler to just use the i2p list)</p>
15:02 < sirup> cervantes, thanks a bunch </p>
15:03 < sirup> yeah. forum will do atm</p>
15:04 < jrandom> ok cool. anyone have anything else on 3) i2phex?</p>
15:05 < jrandom> if not, moving on briefly to 4) awol</p>
15:05 < jrandom> i know y'all are chomping at the bit, looking for ways to contribute code to i2p, so the status notes have a few suggestions</p>
15:05 <+bla> jrandom: You're finally being canceled by Operations?</p>
15:06 < jrandom> nah, the CIA is just reassigning me^Ula la la</p>
15:06 <@smeghead> no the black budget was increased this quarter</p>
15:07 <+cervantes> *the elephant has flown the nest* repeat *the elephant has flown the nest* over</p>
15:07 < jrandom> i dont really have much more to add to 4) than what was in the mail, though i'm sure y'all have plenty of other neat ideas </p>
15:07 * smeghead supresses elephantitis joke</p>
15:08 < jrandom> so your homework assignment while i'm gone is to pick something neat that you want to build, and build it ;)</p>
15:08 * cervantes staunches smeghead's bleeding temples</p>
15:08 < jrandom> (be it a webpage or a flying pony)</p>
15:09 < jrandom> ok, moving on to 5) ???</p>
15:09 < jrandom> anyone else have anything they want to bring up for the meeting?</p>
15:09 < shendaras> We'll miss you...</p>
15:09 <@smeghead> yeah who's chairing the meetings while you're gone?</p>
15:09 <+mancom> has aum shown up during the last week?</p>
15:09 <@smeghead> mancom: negative</p>
15:10 < Masterboy> brother duck?:P</p>
15:11 < jrandom> our beloved operations manager will hopefully fill in, or y'all can draw straws for who has to write up status notes at the last minute :)</p>
15:11 < jrandom> mancom: he was by #i2p-chat the other day briefly</p>
15:12 < RevDuck> maybe only hold meetings when there is actually something to report though</p>
15:12 <+cervantes> it's ok I'm writing a jrandom simulation script</p>
15:12 <+cervantes> * w3wt</p>
15:12 < jrandom> nothing wrong with 5 minute meeting ;)</p>
15:13 <+cervantes> * jrandom flings a mud at his flying pony</p>
15:13 * smeghead writes a cervantes simulation script that writes a jrandom simulation script</p>
15:13 * jrandom writes a smeghead simu[CRASH]</p>
15:13 <+cervantes> oop gotta work on that grammar</p>
15:14 <@smeghead> haha</p>
15:14 < jrandom> ok, anyone else have anything to bring up for the meeting?</p>
15:14 * cervantes writes an aum simula.........</p>
15:14 <@smeghead> java.util.RecursiveIdiocyException</p>
15:15 < jrandom> speaking of which.. ;)</p>
15:15 * jrandom winds up</p>
15:15 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
14:08 < jrandom> 0) hi
14:08 < jrandom> 1) Net status
14:08 < jrandom> 2) SSU status
14:08 < jrandom> 3) i2phex
14:08 < jrandom> 4) awol
14:08 < jrandom> 5) ???
14:08 < jrandom> 0) hi
14:08 * jrandom waves
14:08 < jrandom> weekly status notes posted nearly an hour early @ http://dev.i2p.net/pipermail/i2p/2005-May/000738.html
14:09 * Masterboy waves back:P
14:10 < jrandom> ok, jumping into 1) Net status
14:10 < jrandom> i don't really have too much more to add, though it does appear that we may be up for some turbulance from the azureus influx
14:11 < jrandom> hopefully it'll hold up well enough though, we'll see
14:11 < Masterboy> no big probs for me and i can't remember the little ones.
14:11 < jrandom> heh cool
14:11 < jrandom> anyone else have any questions/comments/concerns wrt the current net status?
14:11 < sirup> is azureus using out proxies?
14:12 < jrandom> heh i hope not
14:12 < jrandom> its probably just people trying it out after seeing the option listed
14:12 <@smeghead> most will bugger off in a week or so
14:13 < Masterboy> :D
14:13 <+DrWoo> smeghead: that's not good
14:13 < sirup> so they wrap two different networks under one hood
14:13 <+cervantes> it's not mentioned in the az release notes
14:13 <+cervantes> although it is listed in the plugins section
14:14 < ant> <cat-a-puss> There is a link that mentions it on the left of their main page
14:14 < jrandom> it'll be great once 0.6 is out and we can handle the increased user load
14:14 <+DrWoo> jrandom: what is the current status of getting out a build to cope with more users?
14:14 < jrandom> yeah, azureus is currently our largest referrer to the website, well more than even the /. references
14:15 < jrandom> DrWoo: no chance.
14:15 < sirup> don't let that stress you and put out 0.6 too early
14:15 * eAi sets unreasonable bandwidth limit to stop people haxoring my download speed
14:15 < ant> <cat-a-puss> how big of a network will .6 support?
14:15 < jrandom> DrWoo: 0.6 is the solution, and that'll be ready when its ready :)
14:15 <+cervantes> there are 445 google hits for "i2p" and "azureus"
14:15 < jrandom> heh eAi
14:16 <+cervantes> I must say I was impressed with the throughput of the test SSU net
14:16 < Masterboy> w00t cervantes:)
14:16 <+DrWoo> jrandom: you know I love ya but your shedule is slipping like a $5 hooker's panties ;)
14:16 < jrandom> cat-a-puss: it removes our current bottleneck to the point that i don't see the next bottleneck clearly. i hope it'll handle into the thousands.
14:16 <+cervantes> managed to max out my DSL connection with a straight http file transfer
14:17 < jrandom> damn straight DrWoo ;) if it could be done faster, that'd be great, but i've got to move next week, so there really isn't any alternative
14:17 < sirup> cervantes: 0 hops both ends ;)
14:18 < jrandom> sirup: sure, but the point is the SSU transport was able to handle it
14:18 <+DrWoo> jrandom: yikes that sux, good luck :)
14:18 < Teal`c__> there is an alternative. I'm calling toad, he'll finish it up while you're in tahiti
14:18 <@smeghead> movin' on up, to the east side, to a deluxe apartment in the skyyyyy
14:18 < shendaras> You have a place in mind, jrandom, or is it up in the air where you end up?
14:19 <+cervantes> *mute*
14:19 < jrandom> heh
14:19 < jrandom> i think i know what country i'll end up in. beyond that, not really
14:19 < jrandom> ok, anyway, back onto the agenda
14:19 < jrandom> anything else on 1) Net status, or shall we move on to 2) SSU status?
14:20 < Masterboy> move
14:20 < jrandom> consider us moved
14:21 < jrandom> ok, as described in the status notes and as cervantes said a minute ago, things are looking promising
14:22 < jrandom> this first round of live net tests caught a few bugs but also helped expose some of the tradeoffs in bandwidth, latency, and tcp-friendliness
14:23 < Masterboy> how can one join a test net?:P
14:23 < jrandom> thats the thing - the ssu testing is done on the live net
14:24 < jrandom> if you look in the netDb, you'll see that some peers have both TCP and SSU addresses, while almost everyone else has just a TCP address.
14:24 < jrandom> peers who know how to talk via SSU try that first, but fall back on TCP if the SSU port isn't reachable.
14:25 < jrandom> still, and i can't emphesize this enough, ssu is not production ready. it will break, and it will cause problems, so people should not use it except as part of explicit tests
14:25 < Masterboy> thanks:)
14:26 < jrandom> for now, everyone should disable ssu, but in the next day or so there'll be more info made available on my blog for the second round of tests
14:27 < jrandom> ok, i think that and the email covered pretty much what i have to bring up wrt ssu. anyone have any questions/comments/concerns?
14:27 < Teal`c__> jrandom: can we use ssu while your gone ?
14:28 < jrandom> probably, but people may want to talk to other users to see if it acts up, and if it does, just disable it
14:29 < shendaras> What's your new SACK technique? =)
14:29 < jrandom> i've still got almost a week of hacking time left, so there's going to be more improvement
14:30 <+bla> jrandom: I was just thinking... When there is a SSU connection between two nodes, do they drop the TCP connection between them (since that's not necessary then)?
14:30 < jrandom> heh shendaras, its just exploiting the small message size and fixed fragmentation to let the receiver transmit explicit ACKs/NACKs for a full message in a bitfield, rather than ACKing or NACKing each fragment separately
14:31 < jrandom> bla: correct, they never establish a TCP connection if SSU is available
14:31 < jrandom> the two transports 'bid' on each message being sent, and the SSU transport is configured to bid 'lower' than the TCP transport
14:31 <+bla> jrandom: That's good, but it means I'll have to update my theland.i2p scripts :(... ;)
14:32 < jrandom> heh well, yeah too bad ;)
14:32 < jrandom> (the new peers.jsp may be what you're after though)
14:33 <+bla> jrandom: I'll have a look. But I don't plan on using SSU until it is ready, though
14:33 <+cervantes> perhaps we should all stay on TCP so bla doesn't have to do any coding
14:34 < jrandom> heh
14:34 < jrandom> cool bla, yeah, no rush
14:34 <+cervantes> ;)
14:34 <+bla> cervantes: ;)
14:35 <+cervantes> will there be any situations where an SSU connection is not appropriate and a TCP one would be preferred?
14:36 * Masterboy pokes jr
14:36 < jrandom> the current default setup prefers an established TCP connection to an unestablished SSU connection
14:36 < jrandom> (you can override that with a config flag, i think its documented in the history.txt)
14:37 <@smeghead> there are some people who've claimed their ISPs block UDP altogether
14:37 < jrandom> but in general, no i can't think of why you'd want to go TCP when SSU is available
14:37 <+cervantes> yup I know about the config option...but I mean are there circumstances where it would be better to use TCP instead of UDP packets
14:37 < jrandom> smeghead: there are some people who've claimed elvis was a martian
14:38 <+cervantes> so it's good just as a fallback
14:38 < jrandom> cervantes: none i can think of, as long as ssu is available by both peers
14:39 < jrandom> perhaps as a fallback, though it does raise issues of restricted routes, as all peers must be able to contact all peers.
14:40 < jrandom> if we allow TCP only nodes, that means everyone must be reachable through TCP and UDP
14:41 < Teal`c__> :~(
14:41 < jrandom> for this summer, we'll probably support both, but i'm inclined to lean towards udp only
14:41 < entroy> Hi, can any one tell me where I can go to ask a q about setting up 12p and Azureus?
14:41 < jrandom> (until 2.0)
14:42 < jrandom> hi entroy, #i2p-chat may be able to help, or forum.i2p.net. we're in our weekly dev meeting at the moment, but can help you out afterwards if you're still having trouble
14:42 <+cervantes> here they come, repel borders :)
14:42 < jrandom> cervantes: anyone who can make it onto irc is one of us :)
14:42 <@smeghead> better call the Minutemen
14:43 < Teal`c__> liverpool or chelsea ?!
14:43 < entroy> ok, thx
14:43 < ant> <cat-a-puss> jrandom: WRT bitfields, if we assume most of the packets are going to be successfully received, then the bitfields would be almost all 1's. Wouldn't it be more efficent to list the number of NACKS and then encode them ECC style.
14:43 <+cervantes> jrandom: are you sure about that...someone mentioned an mschat client earlier
14:43 <+cervantes> ;-)
14:45 < jrandom> cat-a-puss: there are a few options, but when you look at the actual message size, its pretty hard to beat- tunnel messages, which are 4x as common as every other message, will require at *most* two fragments - only two bits
14:45 < Teal`c__> <steve> # Appears as TIKI
14:45 < jrandom> streaming lib messages between the endpoint and gateway is only 4KB - up to 8 bits, or 2 bytes wiwth the bitfields
14:45 < jrandom> that is, assuming the absolute smallest MTU
14:46 < jrandom> with 1492 (or 1472, depending on who is counting), you can handle most anything in a single bitfield byte
14:46 < ant> <cat-a-puss> jrandom: ah, so the bitfields are only for fragments, not for each packet then?
14:47 < jrandom> right, if a message is partially received, you send back the bitfield for the received fragments of that message
14:47 < ant> <cat-a-puss> ok
14:47 < jrandom> message ids are unfortunately completely random and unordered, so we can't use tcp style sequence numbers
14:48 < jrandom> (and, well, we dont want that overhead either)
14:49 < jrandom> ok, if there's nothing else on 2) SSU, lets move on to 3) i2phex
14:49 < jrandom> sirup: you 'round?
14:49 < ant> <cat-a-puss> quickly:why random?
14:50 * sirup is lurking
14:50 < jrandom> cat-a-puss: message ids are exposed to peers - we don't want them to know that one message is related to another message (the one with an earlier sequence #)
14:50 < ant> <cat-a-puss> ok
14:51 < jrandom> heya sirup, i posted up some general info to the list, but if you could give us an update, that'd be great
14:52 < sirup> well. first tests were successfull
14:52 < jrandom> [w3wt]
14:52 < sirup> but it also seems that we need tweaking with the time out settings. connections between peers don't hold up for some reason
14:53 < sirup> so it's not run and gun right now :)
14:53 < sirup> but i also expected that, cause i didn't change anything concerning timeouts and such
14:54 < sirup> generally, i would be happy if some people would be ready to help me test it until a bearable state is reached
14:55 < sirup> several instances on the same machine only get you so far...
14:55 < sirup> oh. and any experience/input is welcome. best done wiht mail to sirup@mail.i2p
14:56 < sirup> a forum would be great too (i can't have any at my destination, 'cause i'm not 24/7)
14:56 < sirup> that's it :)
14:56 < jrandom> wikked
14:56 < jrandom> cervantes: any way we could get an i2phex section added in there?
14:57 <+cervantes> sure could
14:57 * sirup wonders who's downloading that crappy commons licensed music from me :)
14:58 <@smeghead> hey, you can build more crap on top of that crap at least :)
14:58 <+cervantes> sirup: I take it "sirup" is your moniker on the forum
14:58 < sirup> that would be neat
14:58 < sirup> yes
14:59 < ant> <BS314159> status notes?
15:00 < jrandom> ok great. its looking really quite promising, sirup has done some great work, so people should swing over to sirup.i2p and read up on whats goin' on :)
15:00 <@smeghead> mailing list?
15:00 < RevDuck> or www.i2phex.tk
15:01 < sirup> mailing list would also be nice, of course
15:01 < sirup> lol. i2phex.tk is fake. get your dialers there :)
15:01 <+cervantes> I2Phex forum added
15:01 < jrandom> !stab duck
15:02 <+cervantes> sirup is moderator
15:02 < Masterboy> :D
15:02 <+cervantes> sirup: let me know if you want to change the description text
15:02 < jrandom> sirup: if you'd like an i2phex and i2phex-cvs list, lemmie know, they're easy enough to add
15:02 < jrandom> (though at the moment, it may be simpler to just use the i2p list)
15:02 < sirup> cervantes, thanks a bunch
15:03 < sirup> yeah. forum will do atm
15:04 < jrandom> ok cool. anyone have anything else on 3) i2phex?
15:05 < jrandom> if not, moving on briefly to 4) awol
15:05 < jrandom> i know y'all are chomping at the bit, looking for ways to contribute code to i2p, so the status notes have a few suggestions
15:05 <+bla> jrandom: You're finally being canceled by Operations?
15:06 < jrandom> nah, the CIA is just reassigning me^Ula la la
15:06 <@smeghead> no the black budget was increased this quarter
15:07 <+cervantes> *the elephant has flown the nest* repeat *the elephant has flown the nest* over
15:07 < jrandom> i dont really have much more to add to 4) than what was in the mail, though i'm sure y'all have plenty of other neat ideas
15:07 * smeghead supresses elephantitis joke
15:08 < jrandom> so your homework assignment while i'm gone is to pick something neat that you want to build, and build it ;)
15:08 * cervantes staunches smeghead's bleeding temples
15:08 < jrandom> (be it a webpage or a flying pony)
15:09 < jrandom> ok, moving on to 5) ???
15:09 < jrandom> anyone else have anything they want to bring up for the meeting?
15:09 < shendaras> We'll miss you...
15:09 <@smeghead> yeah who's chairing the meetings while you're gone?
15:09 <+mancom> has aum shown up during the last week?
15:09 <@smeghead> mancom: negative
15:10 < Masterboy> brother duck?:P
15:11 < jrandom> our beloved operations manager will hopefully fill in, or y'all can draw straws for who has to write up status notes at the last minute :)
15:11 < jrandom> mancom: he was by #i2p-chat the other day briefly
15:12 < RevDuck> maybe only hold meetings when there is actually something to report though
15:12 <+cervantes> it's ok I'm writing a jrandom simulation script
15:12 <+cervantes> * w3wt
15:12 < jrandom> nothing wrong with 5 minute meeting ;)
15:13 <+cervantes> * jrandom flings a mud at his flying pony
15:13 * smeghead writes a cervantes simulation script that writes a jrandom simulation script
15:13 * jrandom writes a smeghead simu[CRASH]
15:13 <+cervantes> oop gotta work on that grammar
15:14 <@smeghead> haha
15:14 < jrandom> ok, anyone else have anything to bring up for the meeting?
15:14 * cervantes writes an aum simula.........
15:14 <@smeghead> java.util.RecursiveIdiocyException
15:15 < jrandom> speaking of which.. ;)
15:15 * jrandom winds up
15:15 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/140.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, May 3, 2005
============================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,135 +1,129 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 141{% endblock %}
{% block content %}<h3>I2P dev meeting, August 2, 2005</h3>
<div class="irclog">
13:53 < jrandom2p> ok, as i'm here, is there anyone interested in having a brief meeting wrt the notes (or something else)?</p>
13:54 < jrandom2p> anything in the notes people are concerned with, thoughts not related to 'em that people want to bring up, or other issues relevent and timely?</p>
13:54 <@smeghead> sure</p>
13:54 <+protokol> is icepick here?</p>
13:55 <+protokol> i am wondering if i2p-mnet is testable yet and/or an ETA on it</p>
13:55 < jrandom2p> idle for 9 hours atm..</p>
13:56 < jrandom2p> from the channel logs, it didnt sound workable, but he did get the basic SAM integration going</p>
13:56 < jrandom2p> i'm sure we'll hear more when there's more to hear</p>
13:56 <+protokol> cooool</p>
13:57 < jrandom2p> smeghead: has -1 fixed your port migration issue?</p>
13:57 <@smeghead> i haven't noticed any funny business</p>
13:58 <@smeghead> in 3 days or so</p>
13:58 <@cervantes> glad to say I haven't had a loss of service for a day or two</p>
13:58 <@smeghead> i think i can call it fixed</p>
13:58 < jrandom2p> wr0d</p>
13:58 < jrandom2p> (^2)</p>
13:59 <@cervantes> and thetower is only reconnecting every 4 minutes now...so the network health in general must be improving</p>
13:59 < jrandom2p> heh</p>
13:59 <+thetower> A fresh install seemed to fix the problem, but it was really quite disturbing and I never could find a good reason for it.</p>
14:00 < jrandom2p> hmm</p>
14:00 < jrandom2p> was it irc only, or were you losing many peers?</p>
14:00 <@cervantes> gremlins</p>
14:01 <+thetower> Is it possible that changing the router.config file without restarting i2p would have caused the crashes?</p>
14:01 < jrandom2p> hmm, no, i change router.config often</p>
14:01 < jrandom2p> or, is there a particular change you're concerned with?</p>
14:02 <@cervantes> I remember copying over my jbigi lib once while the router was still running.... THAT caused problems ;-)</p>
14:02 <+thetower> I set up some script to alter the bandwidth limits based on current network usage and I was wondering if that was causing the problem.</p>
14:02 < jrandom2p> heh yeah cervantes, that'll always kill the router</p>
14:03 < jrandom2p> ah ok, no, that shouldnt be a problem... though... if it altered the limits to be too small for messages to get through...</p>
14:04 <+thetower> Well, it had fairly reasonable lower limits so I guess that wasn't it.</p>
14:04 < jrandom2p> ok cool, just checkin~ :)</p>
14:05 < jrandom2p> i suppose we'll have 0.6.0.1 tomorrow then, as -1 seems to be a pretty good improvement</p>
14:05 < jrandom2p> it'll be backwards compat, etc, yadda yadda.</p>
14:06 < jrandom2p> anything else y'all know that needs to get pushed out there?</p>
14:06 < jrandom2p> whats the status with i2phex?</p>
14:06 <@smeghead> maybe push the cvs hosts.txt to dev.i2p.net... the current one is months old</p>
14:06 < jrandom2p> i did the other night iirc</p>
14:07 <@smeghead> sirup hasn't been around in a couple of weeks</p>
14:07 < jrandom2p> ooh, hmmm..</p>
14:07 <@smeghead> it's summer though</p>
14:07 <@smeghead> maybe on holiday or something</p>
14:08 <@cervantes> or he's been bum-raped by the riaa</p>
14:08 < jrandom2p> ah yeah, its up there (it was just cached on squid.i2p)</p>
14:08 <@smeghead> riaaped?</p>
14:09 < jrandom2p> ($Id: meeting141.html,v 1.2 2005-08-04 16:21:39 duck Exp $)</p>
14:09 < jrandom2p> *cough*</p>
14:09 <+bar> there are some things that need to be added to bugzilla, like i2p 0.6 and java 1.5</p>
14:09 <@smeghead> ok</p>
14:09 < jrandom2p> ah right, yeah i still havent gotten my laptop online yet (grr)</p>
14:10 < jrandom2p> ((the weekly status notes needed to be burnt to cd... a 1KB cd...))</p>
14:10 < jrandom2p> woah heya mihi</p>
14:10 <@duck> hi mihi!</p>
14:10 < mihi> hi all :)</p>
14:10 <@cervantes> could be dm :)</p>
14:10 < jrandom2p> heh</p>
14:10 <@smeghead> indeed</p>
14:10 <@cervantes> 'lo mihi</p>
14:10 < mihi> seemed to require a bit of tweaking in the config file till my router believed that *only* 8887/udp is open...</p>
14:11 * jrandom2p mentioned i2ptunnel in the status notes and mihi appears ;)</p>
14:11 < jrandom2p> ah, hmm, the i2np.udp.fixedPort=true thing?</p>
14:11 < mihi> hmm? was it there?</p>
14:11 * mihi read status notes only quickly</p>
14:11 < mihi> hmm... is that better solution?</p>
14:12 * mihi just reset the port to 8887 and restarted hard until it did not change the port...</p>
14:12 < jrandom2p> whats the tweak you did to your router.config to make it believe only 8886?</p>
14:12 < jrandom2p> er, 8887</p>
14:12 < jrandom2p> hah</p>
14:12 <@cervantes> can we perhaps rename I2PTunnel as you suggested to something like I2PProxy...?</p>
14:12 < jrandom2p> ok, yeah, use i2np.udp.fixedPort=true</p>
14:12 < jrandom2p> (deployed in 0.6-1 and to be released asap as 0.6.0.1)</p>
14:12 <@cervantes> it can get very confusing talking about "the tunnel config page"</p>
14:13 <+thetower> Oh I have a question, isn't i2p supposed to automatically detect which udp port to use? And if so, is it supposed to be hard coded in the default router.config?</p>
14:13 < mihi> hmmkay...</p>
14:14 < mihi> seems that i2p changed the port once again</p>
14:14 < mihi> expect me to be away soon :)</p>
14:14 < jrandom2p> thetower: yes, it should automatically detect, but there are some funky tap dances that we~re going through at the moment </p>
14:14 <@cervantes> mihi: d'you have the latest cvs?</p>
14:14 < jrandom2p> thats what the whole PeerTest thing is about (making it so that we always automatically configure it properly)</p>
14:14 < mihi> nope.</p>
14:14 <@cervantes> mihi: that would be why then :)</p>
14:15 < mihi> only the version from i2pupdate.zip</p>
14:15 <@cervantes> mihi: 0.6 has RandomPort (tm) functionality</p>
14:15 < jrandom2p> heh</p>
14:16 <@cervantes> :)</p>
14:16 <+ant> * mihi 'd like FixedPorto functionality :)</p>
14:16 <+ant> <mihi> and disconnected...</p>
14:16 <@cervantes> then you'd need 0.6-1 FixedPort Pro</p>
14:16 < jrandom2p> heh</p>
14:16 < jrandom2p> ok, anyone else have something to bring up for the meeting?</p>
14:16 <@cervantes> or wait for 0.6.0.1</p>
14:17 < jrandom2p> how has the latency/throughput been, barring the intermittent reachability?</p>
14:17 <+ant> <mihi> hmm. here is a cvs checkout from 2004-10-06. should try to update it :)</p>
14:17 < jrandom2p> !thwap mihi</p>
14:18 <@cervantes> I got i2pinstall.jar at 110k/sec from dev.i2p yesterday on a single stream</p>
14:18 < jrandom2p> nice</p>
14:19 <@cervantes> and 320k/sec using multiple</p>
14:19 < jrandom2p> w0ah</p>
14:19 < jrandom2p> 0hop, i assume</p>
14:19 < jrandom2p> (dev.i2p is 0hop)</p>
14:19 <@cervantes> yup</p>
14:19 < jrandom2p> ((in case you couldn't tell ;)</p>
14:19 <@cervantes> ;-)</p>
14:19 <+thetower> download to: GTA San Andreas</p>
14:19 <+thetower> download rate: 28.51 kB/s</p>
14:20 <@cervantes> that was from multiple sources though...</p>
14:20 < jrandom2p> ah cool thetower </p>
14:20 <@cervantes> managed to push squid.i2p up to about 280</p>
14:21 < lucky> jrandom2p :)</p>
14:21 < lucky> would you push the new hosts.txt to the site</p>
14:21 <@cervantes> lucky: tis done</p>
14:21 < jrandom2p> yeah, once we can consistently pull that sort of rate cervantes, we'll need to add on some configurable delays to let people do 0hops safely</p>
14:22 < jrandom2p> (so it delays AVG(tunnelTestTime/2) but doesnt waste bw or lose messages)</p>
14:22 <@cervantes> to hide the fact that it's a 0 hop tunnel?</p>
14:22 < lucky> i wonder if I2P will ever have speeds decent enough tha ti could let people log into my virtu-vax</p>
14:23 < jrandom2p> yeah. otherwise, if you say "hey i~m getting 300KBps from your site", you can pretty safely guess that its 2 0hop tunnels</p>
14:23 < jrandom2p> (otoh, 1 to 2 to 3 to 4hops don't have such a dramatic cut)</p>
14:23 <@cervantes> so will i2p effectively have a bandwidth cap</p>
14:23 < jrandom2p> ((as once you force true tunnel operation, each intermediate hop isn't much))</p>
14:24 < jrandom2p> nah cervantes, large windows + delays </p>
14:24 * cervantes cancels his plans for HDTV streaming anonymous pr0n</p>
14:24 < jrandom2p> you can just have more messages in the air to get the same rate</p>
14:25 <@cervantes> ah right</p>
14:25 < jrandom2p> (but it'll take a few more rtts to get to the larger window, of course)</p>
14:25 < jrandom2p> ok, anyone have anything else to bring up?</p>
14:26 < mihi> bring up a *baf*er :)</p>
14:26 <@cervantes> it's gone rusty with missuse</p>
14:27 < jrandom2p> heh i suppose its time ;)</p>
14:27 * jrandom2p winds up</p>
14:27 * jrandom2p *baf*s the meeting closed</p>
</div>
{% endblock %}
13:53 < jrandom2p> ok, as i'm here, is there anyone interested in having a brief meeting wrt the notes (or something else)?
13:54 < jrandom2p> anything in the notes people are concerned with, thoughts not related to 'em that people want to bring up, or other issues relevent and timely?
13:54 <@smeghead> sure
13:54 <+protokol> is icepick here?
13:55 <+protokol> i am wondering if i2p-mnet is testable yet and/or an ETA on it
13:55 < jrandom2p> idle for 9 hours atm..
13:56 < jrandom2p> from the channel logs, it didnt sound workable, but he did get the basic SAM integration going
13:56 < jrandom2p> i'm sure we'll hear more when there's more to hear
13:56 <+protokol> cooool
13:57 < jrandom2p> smeghead: has -1 fixed your port migration issue?
13:57 <@smeghead> i haven't noticed any funny business
13:58 <@smeghead> in 3 days or so
13:58 <@cervantes> glad to say I haven't had a loss of service for a day or two
13:58 <@smeghead> i think i can call it fixed
13:58 < jrandom2p> wr0d
13:58 < jrandom2p> (^2)
13:59 <@cervantes> and thetower is only reconnecting every 4 minutes now...so the network health in general must be improving
13:59 < jrandom2p> heh
13:59 <+thetower> A fresh install seemed to fix the problem, but it was really quite disturbing and I never could find a good reason for it.
14:00 < jrandom2p> hmm
14:00 < jrandom2p> was it irc only, or were you losing many peers?
14:00 <@cervantes> gremlins
14:01 <+thetower> Is it possible that changing the router.config file without restarting i2p would have caused the crashes?
14:01 < jrandom2p> hmm, no, i change router.config often
14:01 < jrandom2p> or, is there a particular change you're concerned with?
14:02 <@cervantes> I remember copying over my jbigi lib once while the router was still running.... THAT caused problems ;-)
14:02 <+thetower> I set up some script to alter the bandwidth limits based on current network usage and I was wondering if that was causing the problem.
14:02 < jrandom2p> heh yeah cervantes, that'll always kill the router
14:03 < jrandom2p> ah ok, no, that shouldnt be a problem... though... if it altered the limits to be too small for messages to get through...
14:04 <+thetower> Well, it had fairly reasonable lower limits so I guess that wasn't it.
14:04 < jrandom2p> ok cool, just checkin~ :)
14:05 < jrandom2p> i suppose we'll have 0.6.0.1 tomorrow then, as -1 seems to be a pretty good improvement
14:05 < jrandom2p> it'll be backwards compat, etc, yadda yadda.
14:06 < jrandom2p> anything else y'all know that needs to get pushed out there?
14:06 < jrandom2p> whats the status with i2phex?
14:06 <@smeghead> maybe push the cvs hosts.txt to dev.i2p.net... the current one is months old
14:06 < jrandom2p> i did the other night iirc
14:07 <@smeghead> sirup hasn't been around in a couple of weeks
14:07 < jrandom2p> ooh, hmmm..
14:07 <@smeghead> it's summer though
14:07 <@smeghead> maybe on holiday or something
14:08 <@cervantes> or he's been bum-raped by the riaa
14:08 < jrandom2p> ah yeah, its up there (it was just cached on squid.i2p)
14:08 <@smeghead> riaaped?
14:09 < jrandom2p> ($Id: meeting141.html,v 1.2 2005-08-04 16:21:39 duck Exp $)
14:09 < jrandom2p> *cough*
14:09 <+bar> there are some things that need to be added to bugzilla, like i2p 0.6 and java 1.5
14:09 <@smeghead> ok
14:09 < jrandom2p> ah right, yeah i still havent gotten my laptop online yet (grr)
14:10 < jrandom2p> ((the weekly status notes needed to be burnt to cd... a 1KB cd...))
14:10 < jrandom2p> woah heya mihi
14:10 <@duck> hi mihi!
14:10 < mihi> hi all :)
14:10 <@cervantes> could be dm :)
14:10 < jrandom2p> heh
14:10 <@smeghead> indeed
14:10 <@cervantes> 'lo mihi
14:10 < mihi> seemed to require a bit of tweaking in the config file till my router believed that *only* 8887/udp is open...
14:11 * jrandom2p mentioned i2ptunnel in the status notes and mihi appears ;)
14:11 < jrandom2p> ah, hmm, the i2np.udp.fixedPort=true thing?
14:11 < mihi> hmm? was it there?
14:11 * mihi read status notes only quickly
14:11 < mihi> hmm... is that better solution?
14:12 * mihi just reset the port to 8887 and restarted hard until it did not change the port...
14:12 < jrandom2p> whats the tweak you did to your router.config to make it believe only 8886?
14:12 < jrandom2p> er, 8887
14:12 < jrandom2p> hah
14:12 <@cervantes> can we perhaps rename I2PTunnel as you suggested to something like I2PProxy...?
14:12 < jrandom2p> ok, yeah, use i2np.udp.fixedPort=true
14:12 < jrandom2p> (deployed in 0.6-1 and to be released asap as 0.6.0.1)
14:12 <@cervantes> it can get very confusing talking about "the tunnel config page"
14:13 <+thetower> Oh I have a question, isn't i2p supposed to automatically detect which udp port to use? And if so, is it supposed to be hard coded in the default router.config?
14:13 < mihi> hmmkay...
14:14 < mihi> seems that i2p changed the port once again
14:14 < mihi> expect me to be away soon :)
14:14 < jrandom2p> thetower: yes, it should automatically detect, but there are some funky tap dances that we~re going through at the moment
14:14 <@cervantes> mihi: d'you have the latest cvs?
14:14 < jrandom2p> thats what the whole PeerTest thing is about (making it so that we always automatically configure it properly)
14:14 < mihi> nope.
14:14 <@cervantes> mihi: that would be why then :)
14:15 < mihi> only the version from i2pupdate.zip
14:15 <@cervantes> mihi: 0.6 has RandomPort (tm) functionality
14:15 < jrandom2p> heh
14:16 <@cervantes> :)
14:16 <+ant> * mihi 'd like FixedPorto functionality :)
14:16 <+ant> <mihi> and disconnected...
14:16 <@cervantes> then you'd need 0.6-1 FixedPort Pro
14:16 < jrandom2p> heh
14:16 < jrandom2p> ok, anyone else have something to bring up for the meeting?
14:16 <@cervantes> or wait for 0.6.0.1
14:17 < jrandom2p> how has the latency/throughput been, barring the intermittent reachability?
14:17 <+ant> <mihi> hmm. here is a cvs checkout from 2004-10-06. should try to update it :)
14:17 < jrandom2p> !thwap mihi
14:18 <@cervantes> I got i2pinstall.jar at 110k/sec from dev.i2p yesterday on a single stream
14:18 < jrandom2p> nice
14:19 <@cervantes> and 320k/sec using multiple
14:19 < jrandom2p> w0ah
14:19 < jrandom2p> 0hop, i assume
14:19 < jrandom2p> (dev.i2p is 0hop)
14:19 <@cervantes> yup
14:19 < jrandom2p> ((in case you couldn't tell ;)
14:19 <@cervantes> ;-)
14:19 <+thetower> download to: GTA San Andreas
14:19 <+thetower> download rate: 28.51 kB/s
14:20 <@cervantes> that was from multiple sources though...
14:20 < jrandom2p> ah cool thetower
14:20 <@cervantes> managed to push squid.i2p up to about 280
14:21 < lucky> jrandom2p :)
14:21 < lucky> would you push the new hosts.txt to the site
14:21 <@cervantes> lucky: tis done
14:21 < jrandom2p> yeah, once we can consistently pull that sort of rate cervantes, we'll need to add on some configurable delays to let people do 0hops safely
14:22 < jrandom2p> (so it delays AVG(tunnelTestTime/2) but doesnt waste bw or lose messages)
14:22 <@cervantes> to hide the fact that it's a 0 hop tunnel?
14:22 < lucky> i wonder if I2P will ever have speeds decent enough tha ti could let people log into my virtu-vax
14:23 < jrandom2p> yeah. otherwise, if you say "hey i~m getting 300KBps from your site", you can pretty safely guess that its 2 0hop tunnels
14:23 < jrandom2p> (otoh, 1 to 2 to 3 to 4hops don't have such a dramatic cut)
14:23 <@cervantes> so will i2p effectively have a bandwidth cap
14:23 < jrandom2p> ((as once you force true tunnel operation, each intermediate hop isn't much))
14:24 < jrandom2p> nah cervantes, large windows + delays
14:24 * cervantes cancels his plans for HDTV streaming anonymous pr0n
14:24 < jrandom2p> you can just have more messages in the air to get the same rate
14:25 <@cervantes> ah right
14:25 < jrandom2p> (but it'll take a few more rtts to get to the larger window, of course)
14:25 < jrandom2p> ok, anyone have anything else to bring up?
14:26 < mihi> bring up a *baf*er :)
14:26 <@cervantes> it's gone rusty with missuse
14:27 < jrandom2p> heh i suppose its time ;)
14:27 * jrandom2p winds up
14:27 * jrandom2p *baf*s the meeting closed

10
i2p2www/meetings/141.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, August 2, 2005
===============================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,94 +1,88 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 142{% endblock %}
{% block content %}<h3>I2P dev meeting, August 9, 2005</h3>
<div class="irclog">
13:11 < jrandom2p> 0) hi</p>
13:11 < jrandom2p> 1) 0.6.0.2</p>
13:11 < jrandom2p> 2) roadmap update</p>
13:11 < jrandom2p> 3) ???</p>
13:11 < jrandom2p> 0) hi</p>
13:11 * jrandom2p waves</p>
13:11 <+detonate> hi</p>
13:11 < jrandom2p> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-August/000839.html</p>
13:12 < jrandom2p> ok, jumping in briefly to [1-2] before the freeforall..</p>
13:12 < jrandom2p> 1) 0.6.0.2</p>
13:12 < jrandom2p> its out. and stuff</p>
13:12 < jrandom2p> anyone have any questions/comments/concerns w/ 0.6.0.2?</p>
13:13 < jrandom2p> if not, moving on to 2) roadmap update</p>
13:13 < jrandom2p> the, er, roadmap has been updated. and stuff ;)</p>
13:14 < duck> you aussie</p>
13:14 <+bla> jrandom: There still are intermittent problems contacting a destination, even when it's normally up</p>
13:14 * postman can second this</p>
13:14 * detonate can third that</p>
13:14 <+bla> jrandom: E.g., forum.i2p works fine, then after a few minutes it doesn't, and requires a few reloads</p>
13:15 * bla firsted it ;)</p>
13:15 < jrandom2p> hmm, aye, i've heard reports of that. with 0.6.0.2 as well, right?</p>
13:16 <+postman> indeed sir</p>
13:16 <+bla> Yes, 0.6.0.2</p>
13:16 <+bla> Could be netDb trouble, or poor selection of peers to put in tunnels (or something else)</p>
13:16 < jrandom2p> 'k</p>
13:17 < jrandom2p> the tunnel peer selection has been pretty bad lately, as has netDb store flooding</p>
13:17 < jrandom2p> (see your /oldstats.jsp for tunnel request failure counts)</p>
13:18 <+bla> Now that we use UDP/SSU, peer classification seems to be better than before: a number of peers I _know_ to be fast, usually show up under the "fast" section on the profile pafe</p>
13:19 < jrandom2p> nice</p>
13:19 < jrandom2p> 0.6.0.2 added some tunnel rejection code based on the netDb that it should have been doing before (refusing to join if we can't find the next hop), so the increase in rejections is expected</p>
13:19 <+bla> Though I really should get going at the classification algorithms again... ;)</p>
13:20 < jrandom2p> i've been doing profile/stat analysis, but no solid results yet</p>
13:21 < jrandom> that would be cool bla :)</p>
13:25 < jrandom2p> ok, anything else on 2) roadmpa update? :)</p>
13:26 < jrandom2p> if not, moving on to 3) ???</p>
13:26 <+detonate> do you think it would be useful to shitlist peers with high failure/duprecv rates compared to the mode?</p>
13:27 < jrandom> hmm, i'm not sure about that - if the failure/dup rates are too high to be useful, we should just transfer slowly and carefully</p>
13:27 < jrandom> as long as messages are getting through, messages are getting through</p>
13:28 < jrandom> there's a reason why we haven't used stats on direct peer communication as part of our profiling - depending upon them would make us vulnerable to some easy and powerful attacks (acting differently to different peers and see who uses you, etc)</p>
13:29 <+detonate> hmm</p>
13:29 <+detonate> ok</p>
13:29 < jrandom> but perhaps we need to drop sessions for peers who are in such congested cons</p>
13:29 <+detonate> good point</p>
13:34 < jrandom> ok, anyone else have something to bring up for 3) ???</p>
13:34 < luckypunk> o,oh, maybe you should wait ti leveryone is back</p>
13:34 < luckypunk> before asking critical questions :P</p>
13:35 < jrandom2p> bah, they've got the mailing list ;)</p>
13:35 < luckypunk> well</p>
13:35 < luckypunk> i guess this is the right place to whine</p>
13:36 < luckypunk> I2P still uses a bit of CPU</p>
13:36 < luckypunk> but not as much as before</p>
13:36 < luckypunk> true, i haven't run it since the 5.0 days</p>
13:36 < luckypunk> but yeah</p>
13:36 < luckypunk> er</p>
13:36 < luckypunk> 0.5.0</p>
13:36 < jrandom2p> cool, which of your boxes works with it?</p>
13:36 < luckypunk> er</p>
13:36 < luckypunk> ffs</p>
13:36 < luckypunk> i haven't used it since 0.6.0.0</p>
13:36 < luckypunk> it works fine with the pentium 2</p>
13:37 < luckypunk> the default nice value mens it tends to crashif i do anything too CPU intensive for too long as I2P gets CPU starved</p>
13:38 <+detonate> hmm, i guess there could be a space in the router console network config to hardwire the introducers, once there are introducers, if the user prefers</p>
13:39 < jrandom2p> are you on 0.6.0.2 now luckypunk?</p>
13:39 <@smeghead> detonate: that's trusted route stuff... later on in the roadmap :)</p>
13:39 < luckypunk> no</p>
13:39 < luckypunk> i haven't run it since 0.6.0.0</p>
13:39 <@smeghead> *restricted route</p>
13:40 < luckypunk> but it's CPU use seemed much less.</p>
13:40 <+detonate> heh, it should be there as soon as there's introducers :)</p>
13:40 < jrandom2p> ah yeah detonate, the introducer selection could certainly be configurable, but it'll probably be a hidden advanced config option ;)</p>
13:41 < jrandom2p> luckypunk: 0.6.0.1 cut out a lot of crypto, and 0.6.0.2 should help further. give it a try sometime, it may handle it better</p>
13:41 < luckypunk> ok</p>
13:41 <@smeghead> what if an introducer doesn't want you selecting them all the time?</p>
13:41 < luckypunk> i have the feeling I2P would on a dedicated mid range pentium now.</p>
13:41 < jrandom> smeghead: then they say "fuck off, i'm not going to serve as an introducer for you"</p>
13:42 < jrandom> and peers will have multiple introducers, so it'll be balanced</p>
13:42 < jrandom> (and its only 2 packets to wire up a new peer, not all packets communicated)</p>
13:44 <+detonate> if introducers worked differently you could do a majority vote between them to decide which ones are working, but as it stands that doesn't make sense</p>
13:45 < ant> &lt;jme___&gt; q. where can i find a description of this voting system ?</p>
13:45 < jrandom> majority doesnt make any sense</p>
13:45 * jrandom doesnt trust voting any further than i can throw it</p>
13:45 < jrandom> (especially in light of sybil)</p>
13:45 < jrandom> an introducer is working if a new peer can contact you through it</p>
13:47 <+detonate> what's the status of vanguard, that's sort of related</p>
13:47 <+detonate> while smeghead is around</p>
13:51 < jrandom> ok, if there isn't anything else...</p>
13:51 * jrandom winds up </p>
13:51 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:11 < jrandom2p> 0) hi
13:11 < jrandom2p> 1) 0.6.0.2
13:11 < jrandom2p> 2) roadmap update
13:11 < jrandom2p> 3) ???
13:11 < jrandom2p> 0) hi
13:11 * jrandom2p waves
13:11 <+detonate> hi
13:11 < jrandom2p> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-August/000839.html
13:12 < jrandom2p> ok, jumping in briefly to [1-2] before the freeforall..
13:12 < jrandom2p> 1) 0.6.0.2
13:12 < jrandom2p> its out. and stuff
13:12 < jrandom2p> anyone have any questions/comments/concerns w/ 0.6.0.2?
13:13 < jrandom2p> if not, moving on to 2) roadmap update
13:13 < jrandom2p> the, er, roadmap has been updated. and stuff ;)
13:14 < duck> you aussie
13:14 <+bla> jrandom: There still are intermittent problems contacting a destination, even when it's normally up
13:14 * postman can second this
13:14 * detonate can third that
13:14 <+bla> jrandom: E.g., forum.i2p works fine, then after a few minutes it doesn't, and requires a few reloads
13:15 * bla firsted it ;)
13:15 < jrandom2p> hmm, aye, i've heard reports of that. with 0.6.0.2 as well, right?
13:16 <+postman> indeed sir
13:16 <+bla> Yes, 0.6.0.2
13:16 <+bla> Could be netDb trouble, or poor selection of peers to put in tunnels (or something else)
13:16 < jrandom2p> 'k
13:17 < jrandom2p> the tunnel peer selection has been pretty bad lately, as has netDb store flooding
13:17 < jrandom2p> (see your /oldstats.jsp for tunnel request failure counts)
13:18 <+bla> Now that we use UDP/SSU, peer classification seems to be better than before: a number of peers I _know_ to be fast, usually show up under the "fast" section on the profile pafe
13:19 < jrandom2p> nice
13:19 < jrandom2p> 0.6.0.2 added some tunnel rejection code based on the netDb that it should have been doing before (refusing to join if we can't find the next hop), so the increase in rejections is expected
13:19 <+bla> Though I really should get going at the classification algorithms again... ;)
13:20 < jrandom2p> i've been doing profile/stat analysis, but no solid results yet
13:21 < jrandom> that would be cool bla :)
13:25 < jrandom2p> ok, anything else on 2) roadmpa update? :)
13:26 < jrandom2p> if not, moving on to 3) ???
13:26 <+detonate> do you think it would be useful to shitlist peers with high failure/duprecv rates compared to the mode?
13:27 < jrandom> hmm, i'm not sure about that - if the failure/dup rates are too high to be useful, we should just transfer slowly and carefully
13:27 < jrandom> as long as messages are getting through, messages are getting through
13:28 < jrandom> there's a reason why we haven't used stats on direct peer communication as part of our profiling - depending upon them would make us vulnerable to some easy and powerful attacks (acting differently to different peers and see who uses you, etc)
13:29 <+detonate> hmm
13:29 <+detonate> ok
13:29 < jrandom> but perhaps we need to drop sessions for peers who are in such congested cons
13:29 <+detonate> good point
13:34 < jrandom> ok, anyone else have something to bring up for 3) ???
13:34 < luckypunk> o,oh, maybe you should wait ti leveryone is back
13:34 < luckypunk> before asking critical questions :P
13:35 < jrandom2p> bah, they've got the mailing list ;)
13:35 < luckypunk> well
13:35 < luckypunk> i guess this is the right place to whine
13:36 < luckypunk> I2P still uses a bit of CPU
13:36 < luckypunk> but not as much as before
13:36 < luckypunk> true, i haven't run it since the 5.0 days
13:36 < luckypunk> but yeah
13:36 < luckypunk> er
13:36 < luckypunk> 0.5.0
13:36 < jrandom2p> cool, which of your boxes works with it?
13:36 < luckypunk> er
13:36 < luckypunk> ffs
13:36 < luckypunk> i haven't used it since 0.6.0.0
13:36 < luckypunk> it works fine with the pentium 2
13:37 < luckypunk> the default nice value mens it tends to crashif i do anything too CPU intensive for too long as I2P gets CPU starved
13:38 <+detonate> hmm, i guess there could be a space in the router console network config to hardwire the introducers, once there are introducers, if the user prefers
13:39 < jrandom2p> are you on 0.6.0.2 now luckypunk?
13:39 <@smeghead> detonate: that's trusted route stuff... later on in the roadmap :)
13:39 < luckypunk> no
13:39 < luckypunk> i haven't run it since 0.6.0.0
13:39 <@smeghead> *restricted route
13:40 < luckypunk> but it's CPU use seemed much less.
13:40 <+detonate> heh, it should be there as soon as there's introducers :)
13:40 < jrandom2p> ah yeah detonate, the introducer selection could certainly be configurable, but it'll probably be a hidden advanced config option ;)
13:41 < jrandom2p> luckypunk: 0.6.0.1 cut out a lot of crypto, and 0.6.0.2 should help further. give it a try sometime, it may handle it better
13:41 < luckypunk> ok
13:41 <@smeghead> what if an introducer doesn't want you selecting them all the time?
13:41 < luckypunk> i have the feeling I2P would on a dedicated mid range pentium now.
13:41 < jrandom> smeghead: then they say "fuck off, i'm not going to serve as an introducer for you"
13:42 < jrandom> and peers will have multiple introducers, so it'll be balanced
13:42 < jrandom> (and its only 2 packets to wire up a new peer, not all packets communicated)
13:44 <+detonate> if introducers worked differently you could do a majority vote between them to decide which ones are working, but as it stands that doesn't make sense
13:45 < ant> <jme___> q. where can i find a description of this voting system ?
13:45 < jrandom> majority doesnt make any sense
13:45 * jrandom doesnt trust voting any further than i can throw it
13:45 < jrandom> (especially in light of sybil)
13:45 < jrandom> an introducer is working if a new peer can contact you through it
13:47 <+detonate> what's the status of vanguard, that's sort of related
13:47 <+detonate> while smeghead is around
13:51 < jrandom> ok, if there isn't anything else...
13:51 * jrandom winds up
13:51 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/142.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, August 9, 2005
===============================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,56 +1,50 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 143{% endblock %}
{% block content %}<h3>I2P dev meeting, August 16, 2005</h3>
<div class="irclog">
13:09 <@jrandom> 0) hi</p>
13:09 <@jrandom> 1) PeerTest status</p>
13:09 <@jrandom> 2) Irc2P</p>
13:09 <@jrandom> 3) Feedspace</p>
13:09 <@jrandom> 4) meta</p>
13:09 <@jrandom> 5) ???</p>
13:09 <@jrandom> 0) hi</p>
13:09 * jrandom waves</p>
13:09 <@jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-August/000842.html</p>
13:10 <@jrandom> (which i'm sure you've all read studiously)</p>
13:10 <@postman> hi</p>
13:10 <+cervantes> hmm changate perl scripts...will give them a go...</p>
13:10 <+cervantes> hi</p>
13:10 <@jrandom> 1) peer test status</p>
13:11 <@jrandom> not too much to add on this beyond what i posted in the notes - anyone have any questions/comments/concerns with it?</p>
13:11 <@jrandom> i'm not sure whether to verify the remote reachability of everyone who connects to us, but i'm toying with that idea</p>
13:11 <@jrandom> (we do that now with tcp)</p>
13:13 <@jrandom> well, perhaps we can try it without that on a 0.6.0.3 before moving to 0.6.1. ve zhall zee</p>
13:13 <@jrandom> ok, moving on to 2) irc2p</p>
13:13 <@jrandom> y'all are here, so you know whats up :)</p>
13:13 <@jrandom> nice work postman & smeghead</p>
13:16 <@jrandom> ok, smeghead & postman have been putting out plenty of info on that thaang, so if there's nothing else y'all want to bring up on that, we can swing over to 3) feedspace</p>
13:16 <@jrandom> frosk seems to have stepped out, and i don't really have anything to add beyond whats in the notes (and on his blog)</p>
13:17 <@postman> :)</p>
13:17 * Complication is reading frosk's blog</p>
13:18 <@jrandom> ok, perhaps frosk'll fill us in with a post there when there's more info to share</p>
13:19 <@jrandom> movin' on briefly to 4) meta</p>
13:19 <@jrandom> what are y'all's thoughts on 8p GMT meetings? too early, too late, just right?</p>
13:21 * jrandom holds back the crowds</p>
13:21 <+Complication> I'd like to say something useful, but cannot seem to find my world clock...</p>
13:21 <@jrandom> google://what+time+is+it</p>
13:22 <+Complication> :)</p>
13:22 <@jrandom> ok, movin' on to 5) ???</p>
13:22 <@jrandom> anyone have anything else they want to bring up?</p>
13:23 <+susi23> well</p>
13:23 <+susi23> not officially ;)</p>
13:24 <+Complication> It's been an unusually stable time.</p>
13:24 <+Complication> Aside from occasional "message invalid" (or was it "packet invalid"), I can't find errors to report. :o</p>
13:24 <@postman> my errors are already reported :)</p>
13:24 <@jrandom> coo', though thats unfortunately a symptom of undetected errors Complication, since there's still some stuff not going as it Should</p>
13:25 <@jrandom> but, progress, ever onwards</p>
13:25 <@jrandom> perhaps we're seeing a lot of restricted routes out there due to the udp situation</p>
13:25 <+susi23> we started a new idlerpg on #idle and you are all invited to join :)</p>
13:25 <@jrandom> (and perhaps there's a bunch of other things...)</p>
13:25 <@jrandom> w00t susi23 </p>
13:26 <+susi23> :P</p>
13:30 <@jrandom> ok, anyone else have something to bring up for the meeting?</p>
13:32 <@jrandom> ok, if there's nothin' else</p>
13:32 * jrandom winds up</p>
13:32 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:09 <@jrandom> 0) hi
13:09 <@jrandom> 1) PeerTest status
13:09 <@jrandom> 2) Irc2P
13:09 <@jrandom> 3) Feedspace
13:09 <@jrandom> 4) meta
13:09 <@jrandom> 5) ???
13:09 <@jrandom> 0) hi
13:09 * jrandom waves
13:09 <@jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-August/000842.html
13:10 <@jrandom> (which i'm sure you've all read studiously)
13:10 <@postman> hi
13:10 <+cervantes> hmm changate perl scripts...will give them a go...
13:10 <+cervantes> hi
13:10 <@jrandom> 1) peer test status
13:11 <@jrandom> not too much to add on this beyond what i posted in the notes - anyone have any questions/comments/concerns with it?
13:11 <@jrandom> i'm not sure whether to verify the remote reachability of everyone who connects to us, but i'm toying with that idea
13:11 <@jrandom> (we do that now with tcp)
13:13 <@jrandom> well, perhaps we can try it without that on a 0.6.0.3 before moving to 0.6.1. ve zhall zee
13:13 <@jrandom> ok, moving on to 2) irc2p
13:13 <@jrandom> y'all are here, so you know whats up :)
13:13 <@jrandom> nice work postman & smeghead
13:16 <@jrandom> ok, smeghead & postman have been putting out plenty of info on that thaang, so if there's nothing else y'all want to bring up on that, we can swing over to 3) feedspace
13:16 <@jrandom> frosk seems to have stepped out, and i don't really have anything to add beyond whats in the notes (and on his blog)
13:17 <@postman> :)
13:17 * Complication is reading frosk's blog
13:18 <@jrandom> ok, perhaps frosk'll fill us in with a post there when there's more info to share
13:19 <@jrandom> movin' on briefly to 4) meta
13:19 <@jrandom> what are y'all's thoughts on 8p GMT meetings? too early, too late, just right?
13:21 * jrandom holds back the crowds
13:21 <+Complication> I'd like to say something useful, but cannot seem to find my world clock...
13:21 <@jrandom> google://what+time+is+it
13:22 <+Complication> :)
13:22 <@jrandom> ok, movin' on to 5) ???
13:22 <@jrandom> anyone have anything else they want to bring up?
13:23 <+susi23> well
13:23 <+susi23> not officially ;)
13:24 <+Complication> It's been an unusually stable time.
13:24 <+Complication> Aside from occasional "message invalid" (or was it "packet invalid"), I can't find errors to report. :o
13:24 <@postman> my errors are already reported :)
13:24 <@jrandom> coo', though thats unfortunately a symptom of undetected errors Complication, since there's still some stuff not going as it Should
13:25 <@jrandom> but, progress, ever onwards
13:25 <@jrandom> perhaps we're seeing a lot of restricted routes out there due to the udp situation
13:25 <+susi23> we started a new idlerpg on #idle and you are all invited to join :)
13:25 <@jrandom> (and perhaps there's a bunch of other things...)
13:25 <@jrandom> w00t susi23
13:26 <+susi23> :P
13:30 <@jrandom> ok, anyone else have something to bring up for the meeting?
13:32 <@jrandom> ok, if there's nothin' else
13:32 * jrandom winds up
13:32 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/143.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, August 16, 2005
================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,149 +1,143 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 144{% endblock %}
{% block content %}<h3>I2P dev meeting, August 23, 2005</h2>
<div class="irclog">
12:01 < jrandom> 0) hi</p>
12:01 < jrandom> 1) 0.6.0.3 status</p>
12:01 < jrandom> 2) IRC status</p>
12:01 < jrandom> 3) susibt</p>
12:01 < jrandom> 4) Syndie</p>
12:01 < jrandom> 5) ???</p>
12:01 < jrandom> 0) hi</p>
12:01 * jrandom waves</p>
12:01 < lucky> hi</p>
12:02 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-August/000857.html</p>
12:02 < lucky> hihihihi</p>
12:02 < jrandom> hi lucky </p>
12:02 < jrandom> ok, jumping into 1) 0.6.0.3 status</p>
12:02 < jrandom> i think the biggest things worth mentioning wrt 0.6.0.3 are in the status notes, but beyond that, anyone have anything to bring up?</p>
12:04 < gott> What's the deal with 'Unknown' ?</p>
12:04 < jrandom> i'm not sure whether the ssu cwin improvements will come in 0.6.0.4 or will wait until 0.6.1 when we have better peer / configuration</p>
12:04 < jrandom> gott: there are two paragraphs in the email related to that - do you have any specific questions beyond those?</p>
12:05 < jrandom> or is there some point i could clarify?</p>
12:05 < gott> No, I just haven't read the bloody email.</p>
12:05 < jrandom> heh</p>
12:05 < jrandom> well, scroll up five lines and read the bloody email ;)</p>
12:06 < jrandom> ok, anyone else have any questions on 0.6.0.3?</p>
12:07 < jrandom> if not, moving on to 2) IRC status</p>
12:07 < modulus> sorry guys, but need to leave. later all.</p>
12:08 < jrandom> beyond whats in the mail, postman/cervantes/arcturus: y'all have anything you want to bring up?</p>
12:08 < jrandom> l8r modulus</p>
12:08 <+arcturus> on 1)?</p>
12:08 <+arcturus> oh sorry</p>
12:08 < gott> Hmm.</p>
12:08 <+arcturus> 2) it is now</p>
12:09 < gott> How much upstream bandwidth does IRC over i2p usually take at the moment ?</p>
12:09 <+arcturus> netsplits are history</p>
12:09 <+arcturus> gott: i coudln't say that without compromising my router's anonymity</p>
12:09 < gott> No, no, no.</p>
12:10 < jrandom> not sure, my router with squid.i2p/dev.i2p/cvs.i2p/www.cvs/syndiemedia.i2p plus my irc and eepproxy uses on average 10-20KBps</p>
12:10 < gott> Does it require a commercial line ?</p>
12:10 < jrandom> nice1 arcturus</p>
12:10 < gott> jrandom: I mean to say, to host.</p>
12:10 < jrandom> gott: to operate a server or a client?</p>
12:10 < jrandom> ah</p>
12:10 <+arcturus> gott: i couldn't say that without compromising my router's anonymity</p>
12:10 < gott> server.</p>
12:10 * jrandom knows not. probably less when you have just one ircd</p>
12:10 < gott> So are you running a modified unrealircd ?</p>
12:11 < jrandom> say, add a factor of 1.3 to the client usage for a single server</p>
12:11 <+arcturus> i'd like to also add that inter-server lag is steady and very very low</p>
12:11 < gott> I assume you are, since there doesn't seem to be a VERSION command</p>
12:11 <+arcturus> i disabled version</p>
12:12 < gott> Are your modifications open-source ?</p>
12:12 <+arcturus> maybe we're running unreal, maybe we aren't :)</p>
12:12 < gott> You should put them up so others can start their own private networks.</p>
12:12 <+arcturus> i can't tell you without compromising security</p>
12:12 < gott> security through obscurity, sweet.</p>
12:12 < jrandom> word arcturus. i'm seeing something like 0-2s lag on average (at the moment, less than irssi's lag detector)</p>
12:12 <+arcturus> no, it's only one layer of security</p>
12:13 <+arcturus> and it only serves as a deterrent, no substitute for technical security measures</p>
12:15 < jrandom> arcturus: how goes with vanguard?</p>
12:15 <+arcturus> i haven't coded on it lately, other projects have been occupying me, but there's a constant, steady pressure i feel to get around to finishing it :)</p>
12:16 < jrandom> heh coo'</p>
12:16 <+arcturus> vanguard will be most effective against bots, the hashcash measure is a separate deal</p>
12:16 <+arcturus> i'm concerned about hashcash now though</p>
12:17 <+arcturus> with the latest attacks against sha-1</p>
12:17 <+arcturus> it won't be long before there are tools available to the masses</p>
12:17 <+arcturus> unfortunately the standard hashcash implementation is based entirely on sha-1</p>
12:17 < susi23_> Unable to find a javac compiler; // com.sun.tools.javac.Main is not on the classpath. // Perhaps JAVA_HOME does not point to the JDK</p>
12:18 <@cervantes> ah made it</p>
12:18 < susi23_> any ideas about this? JAVA_HOME points definitely to the right dir, javac is in PATH and callable</p>
12:18 <+arcturus> susi23_: we're in a meeting atm :)</p>
12:18 < jrandom> susi23_: OOM?</p>
12:18 < susi23_> meeting? though its 8pm?</p>
12:18 < jrandom> (precompile your jsps rather than letting jetty/tomcat do it, its faster ;)</p>
12:19 < jrandom> yeah we moved it susi23_ :)</p>
12:19 < susi23_> didn't know, sorry</p>
12:19 < jrandom> hehe np, glad you made it for the meeting, your agenda item is up next ;)</p>
12:20 * susi23_ sits down and listens</p>
12:20 <+arcturus> so while i don't expect immediate problems with hashcash, i think it's feasible sha-1 could be seriously compromised soon</p>
12:21 < jrandom> arcturus: hashcash with md5 would probably be fine</p>
12:21 < jrandom> its just a PoW</p>
12:21 <+arcturus> if anyone knows of any hashcash implementations based on sha256 or higher please met me know</p>
12:21 <+arcturus> well PoW is pointless if there's little P in it :)</p>
12:21 < jrandom> the size of the hash only matters when your hashcash reaches the size of the hash</p>
12:23 < jrandom> (but, yeah, running against a truncated sha256 or 512 or whirlpool or whatever would be neat)</p>
12:23 <+arcturus> i guess we could go ahead with the current implementation, perhaps we can design it so that we can swap it out easily later when we need to</p>
12:24 < jrandom> (DTSTTCPW)</p>
12:25 <+arcturus> because we will eventually need to drop sha-1, i'm sure of it :) and if we can't be reasonably certain a token was generated properly there's no reason to even be using hashcash</p>
12:25 < jrandom> (its only for a PoW to get a nym on irc, not to get access to fort knox ;)</p>
12:26 <@cervantes> there's some talk on the hashcash mailing list about implementing sha256</p>
12:26 <+arcturus> it's not for a nym, it's for entry to the server</p>
12:26 <+arcturus> cervantes: cool i'll check that</p>
12:27 <+arcturus> jrandom: and it's not just PoW, the hashcash is what gives us a method to uniquely identify clients on the network, akin to being able to identify by IP, so that we can ban with precision</p>
12:28 < jrandom> certainly those are renewed over time though, right?</p>
12:28 < jrandom> e.g. a new PoW cert every 6 months (or 6h, or whatever)</p>
12:28 <+arcturus> if a user doen't have to do any work to get their ID, that nullifies our ability to ban them</p>
12:29 <+arcturus> i don't know of any reason to expire them automatically, only expire them manually if they violate terms of service</p>
12:29 <+arcturus> no need to make people do unnecessary work for new IDs</p>
12:29 < jrandom> eh, its just a passive PoW, they can run one cycle every 6 hours to regenerate a new one</p>
12:29 < jrandom> but perhaps DTSTTCPW</p>
12:30 <+arcturus> any hashcash genereated must be used within 24 hours or it is invalid</p>
12:32 <@cervantes> just to reiterate the new server irc.freshcoffee.i2p needs to be added into your i2ptunnel console</p>
12:32 < jrandom> coo'. ok, anything else for 2) irc2p?</p>
12:33 <@cervantes> (http://forum.i2p/viewtopic.php?t=911</p>
12:33 <@cervantes> )</p>
12:33 <@cervantes> &lt;-- done</p>
12:34 <+arcturus> i don't have anything else to bore you all with :)</p>
12:34 < jrandom> hehe</p>
12:34 < jrandom> ok, 3) susibt</p>
12:34 < ardvark> um, when I add the new server to my tunnel, do I have to restart i2p?</p>
12:34 < jrandom> susi23_: p1ng</p>
12:35 <@cervantes> ardvark: just the tunnel</p>
12:35 <@cervantes> (ircproxy tunnel)</p>
12:35 < ardvark> oh ok, I just added and saved, so that is not enuff then</p>
12:36 < jrandom> right, unfortunately you need to stop and start that proxy</p>
12:36 < susi23_> well</p>
12:36 < ardvark> but i'll miss the meeting then ;)</p>
12:37 < susi23_> susibt is a webapp (like susimail) to drop into your routers VM</p>
12:37 < susi23_> it acts as a web frontend for i2p-bt</p>
12:38 < susi23_> so you can manage your seeds, up- and download files etc.</p>
12:38 < jrandom> w00t</p>
12:39 < susi23_> the prob is, you need to start a btdownloadheadless.py for each seed... so you get lot of python processes to your many java threads :)</p>
12:39 <+arcturus> that will be addressed in ducktorrent *cough*</p>
12:39 < jrandom> heh</p>
12:39 * jrandom holds breath</p>
12:40 < susi23_> it even supports restart of seeds after router restart</p>
12:40 <@cervantes> nice</p>
12:40 < jrandom> wikked</p>
12:40 < susi23_> future plans are automatic build of torrents and ui improvement</p>
12:41 < susi23_> if you want to try it out, I recommend a separate jetty instance</p>
12:41 < susi23_> so you don't have to fiddle with your router :)</p>
12:41 < susi23_> download and installation instructions on http://susi.i2p</p>
12:42 < susi23_> thats all *ping back to jr*</p>
12:42 < jrandom> w3wt, gracias susi</p>
12:42 < jrandom> ok, anyone have any questions & comments on that, or shall we jump on over to 4) syndie?</p>
12:44 < jrandom> ok regarding syndi, i've posted a bunch to the list about it over the last day or two, and there'll be lots more activity</p>
12:45 < jrandom> the main demo site for syndie is http://syndiemedia.i2p / http://66.111.51.110:8000/, but of course people are encouraged to download it and install it locally</p>
12:45 < jrandom> i dont have too much to add at the moment on that frnt. unless anyone has any questions?</p>
12:46 < gott> Why is it called syndie ?</p>
12:46 < gott> is it a reference to 'syndicate' ?</p>
12:47 < jrandom> yeah, its a generic syndication frontend (+ security, authentication, and anonymity awareness)</p>
12:48 < jrandom> ok, if there's nothing else on 4), lets jump on over to 5) ???</p>
12:48 < jrandom> anyone have anythin i2p related to bring up for the meeting?</p>
12:51 < jrandom> ok, if there's nothing else</p>
12:51 * jrandom winds up</p>
12:52 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
12:01 < jrandom> 0) hi
12:01 < jrandom> 1) 0.6.0.3 status
12:01 < jrandom> 2) IRC status
12:01 < jrandom> 3) susibt
12:01 < jrandom> 4) Syndie
12:01 < jrandom> 5) ???
12:01 < jrandom> 0) hi
12:01 * jrandom waves
12:01 < lucky> hi
12:02 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-August/000857.html
12:02 < lucky> hihihihi
12:02 < jrandom> hi lucky
12:02 < jrandom> ok, jumping into 1) 0.6.0.3 status
12:02 < jrandom> i think the biggest things worth mentioning wrt 0.6.0.3 are in the status notes, but beyond that, anyone have anything to bring up?
12:04 < gott> What's the deal with 'Unknown' ?
12:04 < jrandom> i'm not sure whether the ssu cwin improvements will come in 0.6.0.4 or will wait until 0.6.1 when we have better peer / configuration
12:04 < jrandom> gott: there are two paragraphs in the email related to that - do you have any specific questions beyond those?
12:05 < jrandom> or is there some point i could clarify?
12:05 < gott> No, I just haven't read the bloody email.
12:05 < jrandom> heh
12:05 < jrandom> well, scroll up five lines and read the bloody email ;)
12:06 < jrandom> ok, anyone else have any questions on 0.6.0.3?
12:07 < jrandom> if not, moving on to 2) IRC status
12:07 < modulus> sorry guys, but need to leave. later all.
12:08 < jrandom> beyond whats in the mail, postman/cervantes/arcturus: y'all have anything you want to bring up?
12:08 < jrandom> l8r modulus
12:08 <+arcturus> on 1)?
12:08 <+arcturus> oh sorry
12:08 < gott> Hmm.
12:08 <+arcturus> 2) it is now
12:09 < gott> How much upstream bandwidth does IRC over i2p usually take at the moment ?
12:09 <+arcturus> netsplits are history
12:09 <+arcturus> gott: i coudln't say that without compromising my router's anonymity
12:09 < gott> No, no, no.
12:10 < jrandom> not sure, my router with squid.i2p/dev.i2p/cvs.i2p/www.cvs/syndiemedia.i2p plus my irc and eepproxy uses on average 10-20KBps
12:10 < gott> Does it require a commercial line ?
12:10 < jrandom> nice1 arcturus
12:10 < gott> jrandom: I mean to say, to host.
12:10 < jrandom> gott: to operate a server or a client?
12:10 < jrandom> ah
12:10 <+arcturus> gott: i couldn't say that without compromising my router's anonymity
12:10 < gott> server.
12:10 * jrandom knows not. probably less when you have just one ircd
12:10 < gott> So are you running a modified unrealircd ?
12:11 < jrandom> say, add a factor of 1.3 to the client usage for a single server
12:11 <+arcturus> i'd like to also add that inter-server lag is steady and very very low
12:11 < gott> I assume you are, since there doesn't seem to be a VERSION command
12:11 <+arcturus> i disabled version
12:12 < gott> Are your modifications open-source ?
12:12 <+arcturus> maybe we're running unreal, maybe we aren't :)
12:12 < gott> You should put them up so others can start their own private networks.
12:12 <+arcturus> i can't tell you without compromising security
12:12 < gott> security through obscurity, sweet.
12:12 < jrandom> word arcturus. i'm seeing something like 0-2s lag on average (at the moment, less than irssi's lag detector)
12:12 <+arcturus> no, it's only one layer of security
12:13 <+arcturus> and it only serves as a deterrent, no substitute for technical security measures
12:15 < jrandom> arcturus: how goes with vanguard?
12:15 <+arcturus> i haven't coded on it lately, other projects have been occupying me, but there's a constant, steady pressure i feel to get around to finishing it :)
12:16 < jrandom> heh coo'
12:16 <+arcturus> vanguard will be most effective against bots, the hashcash measure is a separate deal
12:16 <+arcturus> i'm concerned about hashcash now though
12:17 <+arcturus> with the latest attacks against sha-1
12:17 <+arcturus> it won't be long before there are tools available to the masses
12:17 <+arcturus> unfortunately the standard hashcash implementation is based entirely on sha-1
12:17 < susi23_> Unable to find a javac compiler; // com.sun.tools.javac.Main is not on the classpath. // Perhaps JAVA_HOME does not point to the JDK
12:18 <@cervantes> ah made it
12:18 < susi23_> any ideas about this? JAVA_HOME points definitely to the right dir, javac is in PATH and callable
12:18 <+arcturus> susi23_: we're in a meeting atm :)
12:18 < jrandom> susi23_: OOM?
12:18 < susi23_> meeting? though its 8pm?
12:18 < jrandom> (precompile your jsps rather than letting jetty/tomcat do it, its faster ;)
12:19 < jrandom> yeah we moved it susi23_ :)
12:19 < susi23_> didn't know, sorry
12:19 < jrandom> hehe np, glad you made it for the meeting, your agenda item is up next ;)
12:20 * susi23_ sits down and listens
12:20 <+arcturus> so while i don't expect immediate problems with hashcash, i think it's feasible sha-1 could be seriously compromised soon
12:21 < jrandom> arcturus: hashcash with md5 would probably be fine
12:21 < jrandom> its just a PoW
12:21 <+arcturus> if anyone knows of any hashcash implementations based on sha256 or higher please met me know
12:21 <+arcturus> well PoW is pointless if there's little P in it :)
12:21 < jrandom> the size of the hash only matters when your hashcash reaches the size of the hash
12:23 < jrandom> (but, yeah, running against a truncated sha256 or 512 or whirlpool or whatever would be neat)
12:23 <+arcturus> i guess we could go ahead with the current implementation, perhaps we can design it so that we can swap it out easily later when we need to
12:24 < jrandom> (DTSTTCPW)
12:25 <+arcturus> because we will eventually need to drop sha-1, i'm sure of it :) and if we can't be reasonably certain a token was generated properly there's no reason to even be using hashcash
12:25 < jrandom> (its only for a PoW to get a nym on irc, not to get access to fort knox ;)
12:26 <@cervantes> there's some talk on the hashcash mailing list about implementing sha256
12:26 <+arcturus> it's not for a nym, it's for entry to the server
12:26 <+arcturus> cervantes: cool i'll check that
12:27 <+arcturus> jrandom: and it's not just PoW, the hashcash is what gives us a method to uniquely identify clients on the network, akin to being able to identify by IP, so that we can ban with precision
12:28 < jrandom> certainly those are renewed over time though, right?
12:28 < jrandom> e.g. a new PoW cert every 6 months (or 6h, or whatever)
12:28 <+arcturus> if a user doen't have to do any work to get their ID, that nullifies our ability to ban them
12:29 <+arcturus> i don't know of any reason to expire them automatically, only expire them manually if they violate terms of service
12:29 <+arcturus> no need to make people do unnecessary work for new IDs
12:29 < jrandom> eh, its just a passive PoW, they can run one cycle every 6 hours to regenerate a new one
12:29 < jrandom> but perhaps DTSTTCPW
12:30 <+arcturus> any hashcash genereated must be used within 24 hours or it is invalid
12:32 <@cervantes> just to reiterate the new server irc.freshcoffee.i2p needs to be added into your i2ptunnel console
12:32 < jrandom> coo'. ok, anything else for 2) irc2p?
12:33 <@cervantes> (http://forum.i2p/viewtopic.php?t=911
12:33 <@cervantes> )
12:33 <@cervantes> <-- done
12:34 <+arcturus> i don't have anything else to bore you all with :)
12:34 < jrandom> hehe
12:34 < jrandom> ok, 3) susibt
12:34 < ardvark> um, when I add the new server to my tunnel, do I have to restart i2p?
12:34 < jrandom> susi23_: p1ng
12:35 <@cervantes> ardvark: just the tunnel
12:35 <@cervantes> (ircproxy tunnel)
12:35 < ardvark> oh ok, I just added and saved, so that is not enuff then
12:36 < jrandom> right, unfortunately you need to stop and start that proxy
12:36 < susi23_> well
12:36 < ardvark> but i'll miss the meeting then ;)
12:37 < susi23_> susibt is a webapp (like susimail) to drop into your routers VM
12:37 < susi23_> it acts as a web frontend for i2p-bt
12:38 < susi23_> so you can manage your seeds, up- and download files etc.
12:38 < jrandom> w00t
12:39 < susi23_> the prob is, you need to start a btdownloadheadless.py for each seed... so you get lot of python processes to your many java threads :)
12:39 <+arcturus> that will be addressed in ducktorrent *cough*
12:39 < jrandom> heh
12:39 * jrandom holds breath
12:40 < susi23_> it even supports restart of seeds after router restart
12:40 <@cervantes> nice
12:40 < jrandom> wikked
12:40 < susi23_> future plans are automatic build of torrents and ui improvement
12:41 < susi23_> if you want to try it out, I recommend a separate jetty instance
12:41 < susi23_> so you don't have to fiddle with your router :)
12:41 < susi23_> download and installation instructions on http://susi.i2p
12:42 < susi23_> thats all *ping back to jr*
12:42 < jrandom> w3wt, gracias susi
12:42 < jrandom> ok, anyone have any questions & comments on that, or shall we jump on over to 4) syndie?
12:44 < jrandom> ok regarding syndi, i've posted a bunch to the list about it over the last day or two, and there'll be lots more activity
12:45 < jrandom> the main demo site for syndie is http://syndiemedia.i2p / http://66.111.51.110:8000/, but of course people are encouraged to download it and install it locally
12:45 < jrandom> i dont have too much to add at the moment on that frnt. unless anyone has any questions?
12:46 < gott> Why is it called syndie ?
12:46 < gott> is it a reference to 'syndicate' ?
12:47 < jrandom> yeah, its a generic syndication frontend (+ security, authentication, and anonymity awareness)
12:48 < jrandom> ok, if there's nothing else on 4), lets jump on over to 5) ???
12:48 < jrandom> anyone have anythin i2p related to bring up for the meeting?
12:51 < jrandom> ok, if there's nothing else
12:51 * jrandom winds up
12:52 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/144.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, August 23, 2005
================================
Quick recap
-----------
TODO
Full IRC Log
------------

View File

@@ -1,134 +1,128 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 145{% endblock %}
{% block content %}<h3>I2P dev meeting, August 30, 2005</h2>
<div class="irclog">
13:03 <+bla> Is there a meeting today?</p>
13:04 < jrandom> 0) hi</p>
13:04 < jrandom> 1) Net status</p>
13:04 < jrandom> 2) floodfill netDb</p>
13:04 < jrandom> 3) Syndie</p>
13:04 < jrandom> 4) ???</p>
13:04 < jrandom> 0) hi</p>
13:04 <+bla> ;)</p>
13:04 * jrandom waves</p>
13:04 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2005-August/000871.html</p>
13:04 < jrandom> (yeah, i'm a few minutes late ;)</p>
13:05 < jrandom> anyway, jumping into 1) net status</p>
13:06 < jrandom> restricted routes suck, and we finally have some data as to how common they are (boo hiss)</p>
13:06 < jrandom> but stil, the net seems fairly healthy, if you ignore all the worried reports of "omg it says status: Unknown!" ;)</p>
13:07 < gloin> hmm.. where should be the document root for the i2p included webserver?</p>
13:07 < jrandom> $i2pInstallDir/eepsite/docroot/</p>
13:07 < gloin> i2p/eepsite/docroot ?</p>
13:07 < jrandom> anyone have any questions/comments/concerns regarding the net status outside of whats posted in the status notes?</p>
13:08 < gloin> found it. it seems that the webserver won't deliver index.html automatically.</p>
13:08 <+bla> jrandom: I have been doing some tests to check which nodes are selected in tunnels.</p>
13:09 <+bla> jrandom: Mainly, as I've now implemented node-localization in the RouterInfo struct, I can see graphically (country flags) were tunnel participants are located.</p>
13:09 <+bla> I am in Europe (no secret), and most of my tunnel participants are in Europe</p>
13:09 < jrandom> gloin: it should serve up the index.html (thats what renders "Welcome to your Eepsite")</p>
13:10 < jrandom> ooh nice1 bla!</p>
13:10 < redzara> as some people have reported some low perf with UDP, maybe we could had a little perfmeter like iperf in I2P ?</p>
13:11 < redzara> s/had/add</p>
13:11 < jrandom> bla: so thats not just on the profiles.jsp page, but also on tunnels.jsp? v.cool... screenshots, screenshots! :)</p>
13:11 < gloin> jrandom: now it works. strange.</p>
13:11 <+bla> jrandom: I'll post some screenshots, but I first have to black out my own router-ID in the screenshots ;)</p>
13:11 < jrandom> redzara: hmm, a command line utility to let people check their link quality, or a monitor for SSU performance?</p>
13:11 < jrandom> heh bla</p>
13:12 < jrandom> odd gloin </p>
13:13 < gloin> jrandom: btw, since I updated my pppoe i2p seems to be more stable.</p>
13:13 < jrandom> nice, what was the problem with your net connection? firmware update?</p>
13:14 < gloin> jrandom: I lost all peers. But the internet connection was ok, but every peer failed. </p>
13:16 < jrandom> right, but what did you update about your pppoe settings?</p>
13:17 < gloin> jrandom: I mean the linux ppppoe deamon.</p>
13:18 < jrandom> ah ok</p>
13:18 < jrandom> ok, anyone else have anything for 1) net status, or shall we move on to 2) floodfill netdb?</p>
13:18 <+bla> http://theland.i2p/parttunnels.jpg</p>
13:19 <+bla> http://theland.i2p/servertunnels.jpg</p>
13:21 <+bar> (umm.. inaccessible?)</p>
13:21 < jrandom> yeah, i'm having trouble reaching it too</p>
13:21 < fox> &lt;godmode0> i use pppoe never be at problem i2p</p>
13:22 * jrandom will try later though</p>
13:22 <+bla> jrandom: Well.. There's new network problem just there ;)</p>
13:22 < jrandom> hehe</p>
13:22 < jrandom> bla: are you on -4 or an earlier build?</p>
13:23 <+bla> jrandom: I'm on -4</p>
13:23 < jrandom> hmm, ok cool</p>
13:23 < jrandom> ok, anyway, we can dig through that later</p>
13:24 < jrandom> (if you could send me the netDb stats from /oldstats.jsp, that'd be great :)</p>
13:25 < jrandom> ok, moving on to 2) floodfill netdb</p>
13:26 < jrandom> there's lots of info posted to my blog on this topic</p>
13:26 < jrandom> we've begun deploying a first pass, though there's still some work to be done</p>
13:26 < jrandom> does anyone have any questions/comments/concerns on the plan?</p>
13:27 <+bla> jrandom: Will the floodfill scale as log(N) (N=number of peers in the net), or linearly?</p>
13:27 < jrandom> linearly with M (M= number of peers participating in the floodfill netdb)</p>
13:28 < jrandom> well, M may be small enough that N is the dominant term</p>
13:29 < jrandom> (in which case it'll be linearly with N)</p>
13:29 < jrandom> which is not great, but until we have > 10K eepsites, it doesnt matter</p>
13:30 < jrandom> once we do, then we can go into more advanced algorithms for sharing the load between the floodfill participants</p>
13:31 < jrandom> (note thats 10k eepsites, not users, since we don't really need to publish client leaseSets in the netdb)</p>
13:32 <+bla> jrandom: Is there a reason why we still do publish the client destinations in the netDb?</p>
13:32 <+bla> jrandom: Or, for that matter, why we still show off who our fast peers are in the netDb?</p>
13:33 <+bla> jrandom: Removing both would slash the netDb data by a big factor</p>
13:33 < jrandom> bla: to the former, no. to the later, for me to debug (though i havent looked at that particular field recently)</p>
13:33 < jrandom> aye, worth trying, perhaps in -5</p>
13:36 < jrandom> ok coo', well, we'll see and hopefully get -5 out in the next few days</p>
13:37 < jrandom> (maybe tomorrow)</p>
13:37 < jrandom> ok, if there's nothing else on 2) floodfill netdb, lets move on to 3) syndie</p>
13:38 < jrandom> i posted a bunch of info in the mail and on my blog, so rather than rehash them, does anyone have any questions / comments / concerns?</p>
13:40 * jrandom really digs the remote syndication functionality, though its far from what we're hoping for with feedspace integration</p>
13:41 < jrandom> (i havent been bothered to do freenet posting integration, though it would be quite easy to fire up a CLI and post all the entries in)</p>
13:42 < jrandom> ok, if there's nothing else on 3) syndie, lets open 'er up to 4) ???</p>
13:42 < jrandom> anyone have anything else i2p related to bring up?</p>
13:42 < redzara> sure, where is the doc ;)</p>
13:43 < laberhorst> just that my node under 0.6.x sonsumes up to 100% cpu load, but have to crosscheck it with linux on that line here</p>
13:43 <+nickless_head> I think the i2pProxy.pac script should be in the jetty web folder by default.</p>
13:43 < jrandom> nickless_head: i dont recommend i2pproxy.pac, as its a huge security risk</p>
13:44 < redzara> 2 - could be have the latest build of jetty included in I2P ?</p>
13:44 < jrandom> we've got 5.2.1 in i2p right now</p>
13:44 < jrandom> er, 5.1.2</p>
13:44 <+nickless_head> jrandom: it's the only thing available for separating between eepsites and websites in one browser without having to switch by hand afaik</p>
13:45 < jrandom> i use switchproxy</p>
13:45 < jrandom> (and i dont switch to non-anonymous browsing)</p>
13:45 < jrandom> ((squid.i2p is fast enough for me))</p>
13:45 <+nickless_head> Think of the slashdotters! :p</p>
13:46 < jrandom> as i've said before, i have reservations about the viability of eepsites. the security risks are tremendous</p>
13:46 < jrandom> but, for those who don't care about those risks, perhaps an i2pproxy.pac makes sense.</p>
13:47 <+bla> I strongly think that something that isn't secure by _default_, shouldn't be in I2P, as to not give new users a false sense of secutiry</p>
13:48 < jrandom> agreed (though we do push i2pproxy.pac, we just dont tell people about it until we scare 'em enough ;)</p>
13:49 <+nickless_head> I somehow can't believe that within the configuration of Mozilla there isn't a way to make sites only access resources from the same domain .. </p>
13:50 < redzara> sorry but IRC connection lost :( about jetty there is a fix about common logging and maybe this help me running my mvnforum in the same instance of I2P</p>
13:50 < redzara> Jetty-5.1.5rc1 - 23 August 2005</p>
13:52 < jrandom> ah cool, whats the problem exactly redzara?</p>
13:52 < jrandom> nickless_head: if you find a way, let us know</p>
13:52 < redzara> or maybe i could even only build my own I2P with the latest version of jetty</p>
13:52 < jrandom> redzara: that you certainly can do - just drop in the jetty jar files into your i2p lib directory</p>
13:53 < redzara> jrandom : everythime i try to start mvnforum in I2P, jetty failed to find apache common logging</p>
13:53 <+nickless_head> Oh! I just noticed that the default i2pproxy.pac uses a mode which allows sites to switch proxy'ing to i2p on and off at runtime, which is protected by the TOTALLY SECURE AND UNBREAKABLE &lt;/sarcasm> default password "passw0rd". Please, someone who knows about cvs change this.</p>
13:54 < jrandom> redzara: thats in commons-logging.jar and commons-el.jar iirc, which should be in your lib dir and in your wrapper.config's classpath</p>
13:54 < jrandom> nickless_head: yet another reason why i dont recommend anyone use it ;)</p>
13:55 < redzara> yes i know, i'm not so n00b :)) i've to dig into again with this new version of jetty</p>
13:56 < jrandom> cool, keep us updated</p>
13:56 < redzara> np</p>
13:57 < fox> * mihi guesses most i2p users will reveal their "real ip" to a java applet anyway :)</p>
13:57 < fox> &lt;mihi> try http://www.stilllistener.com/checkpoint1/Java/ (and scroll down)</p>
13:58 * jrandom sees lots of blank fields ;)</p>
13:59 <+bla> fox: All one exposes is the relation between an IP and a particular client destination, where the client destination will change at every router restart.</p>
13:59 < jrandom> bla: unless the user is on some site like e.g. http://i_have_illegal_stuff.i2p/</p>
14:00 < jrandom> (exposing the clients IP "just once" is fatal enough ;)</p>
14:00 <+bla> jrandom: Yes. </p>
14:00 <+bla> But then again, if you're serious about anonymous browsing, you'll use temporary HTTP proxies, and disable all things java, and plugins, and cookies, entirely</p>
14:01 < jrandom> or use syndie :)</p>
14:02 < ZULU> sorry for interruption,is duck.ip down ?</p>
14:02 <+bla> jrandom: Is it time yet for general questions?</p>
14:02 < jrandom> aye, we're on 4) ???</p>
14:02 < jrandom> ZULU: yeah, duck is offline for the time being</p>
14:03 <+bla> jrandom: I've edited the java-files that help profiles.jsp and tunnels.jsp generate the country-flags</p>
14:04 <+bla> jrandom: However, where do I place images that I can actually LINK to, and that will work, on my local router (_not_ my eepsite)?</p>
14:06 < jrandom> we need a "get.jsp?name" that dumps the contents of ./docs/'name' to the browser</p>
14:06 < jrandom> (aka you need to have it in the .war right now, but with a tiny .jsp file, you could dump 'em in docs)</p>
14:06 <+bla> jrandom: Ah, ok, so it wasn't my fault ;)</p>
14:06 < jrandom> heh nope, blame me :)</p>
14:09 < jrandom> ok, if there's nothing else for the meeting</p>
14:09 * jrandom winds up</p>
14:10 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}
13:03 <+bla> Is there a meeting today?
13:04 < jrandom> 0) hi
13:04 < jrandom> 1) Net status
13:04 < jrandom> 2) floodfill netDb
13:04 < jrandom> 3) Syndie
13:04 < jrandom> 4) ???
13:04 < jrandom> 0) hi
13:04 <+bla> ;)
13:04 * jrandom waves
13:04 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2005-August/000871.html
13:04 < jrandom> (yeah, i'm a few minutes late ;)
13:05 < jrandom> anyway, jumping into 1) net status
13:06 < jrandom> restricted routes suck, and we finally have some data as to how common they are (boo hiss)
13:06 < jrandom> but stil, the net seems fairly healthy, if you ignore all the worried reports of "omg it says status: Unknown!" ;)
13:07 < gloin> hmm.. where should be the document root for the i2p included webserver?
13:07 < jrandom> $i2pInstallDir/eepsite/docroot/
13:07 < gloin> i2p/eepsite/docroot ?
13:07 < jrandom> anyone have any questions/comments/concerns regarding the net status outside of whats posted in the status notes?
13:08 < gloin> found it. it seems that the webserver won't deliver index.html automatically.
13:08 <+bla> jrandom: I have been doing some tests to check which nodes are selected in tunnels.
13:09 <+bla> jrandom: Mainly, as I've now implemented node-localization in the RouterInfo struct, I can see graphically (country flags) were tunnel participants are located.
13:09 <+bla> I am in Europe (no secret), and most of my tunnel participants are in Europe
13:09 < jrandom> gloin: it should serve up the index.html (thats what renders "Welcome to your Eepsite")
13:10 < jrandom> ooh nice1 bla!
13:10 < redzara> as some people have reported some low perf with UDP, maybe we could had a little perfmeter like iperf in I2P ?
13:11 < redzara> s/had/add
13:11 < jrandom> bla: so thats not just on the profiles.jsp page, but also on tunnels.jsp? v.cool... screenshots, screenshots! :)
13:11 < gloin> jrandom: now it works. strange.
13:11 <+bla> jrandom: I'll post some screenshots, but I first have to black out my own router-ID in the screenshots ;)
13:11 < jrandom> redzara: hmm, a command line utility to let people check their link quality, or a monitor for SSU performance?
13:11 < jrandom> heh bla
13:12 < jrandom> odd gloin
13:13 < gloin> jrandom: btw, since I updated my pppoe i2p seems to be more stable.
13:13 < jrandom> nice, what was the problem with your net connection? firmware update?
13:14 < gloin> jrandom: I lost all peers. But the internet connection was ok, but every peer failed.
13:16 < jrandom> right, but what did you update about your pppoe settings?
13:17 < gloin> jrandom: I mean the linux ppppoe deamon.
13:18 < jrandom> ah ok
13:18 < jrandom> ok, anyone else have anything for 1) net status, or shall we move on to 2) floodfill netdb?
13:18 <+bla> http://theland.i2p/parttunnels.jpg
13:19 <+bla> http://theland.i2p/servertunnels.jpg
13:21 <+bar> (umm.. inaccessible?)
13:21 < jrandom> yeah, i'm having trouble reaching it too
13:21 < fox> <godmode0> i use pppoe never be at problem i2p
13:22 * jrandom will try later though
13:22 <+bla> jrandom: Well.. There's new network problem just there ;)
13:22 < jrandom> hehe
13:22 < jrandom> bla: are you on -4 or an earlier build?
13:23 <+bla> jrandom: I'm on -4
13:23 < jrandom> hmm, ok cool
13:23 < jrandom> ok, anyway, we can dig through that later
13:24 < jrandom> (if you could send me the netDb stats from /oldstats.jsp, that'd be great :)
13:25 < jrandom> ok, moving on to 2) floodfill netdb
13:26 < jrandom> there's lots of info posted to my blog on this topic
13:26 < jrandom> we've begun deploying a first pass, though there's still some work to be done
13:26 < jrandom> does anyone have any questions/comments/concerns on the plan?
13:27 <+bla> jrandom: Will the floodfill scale as log(N) (N=number of peers in the net), or linearly?
13:27 < jrandom> linearly with M (M= number of peers participating in the floodfill netdb)
13:28 < jrandom> well, M may be small enough that N is the dominant term
13:29 < jrandom> (in which case it'll be linearly with N)
13:29 < jrandom> which is not great, but until we have > 10K eepsites, it doesnt matter
13:30 < jrandom> once we do, then we can go into more advanced algorithms for sharing the load between the floodfill participants
13:31 < jrandom> (note thats 10k eepsites, not users, since we don't really need to publish client leaseSets in the netdb)
13:32 <+bla> jrandom: Is there a reason why we still do publish the client destinations in the netDb?
13:32 <+bla> jrandom: Or, for that matter, why we still show off who our fast peers are in the netDb?
13:33 <+bla> jrandom: Removing both would slash the netDb data by a big factor
13:33 < jrandom> bla: to the former, no. to the later, for me to debug (though i havent looked at that particular field recently)
13:33 < jrandom> aye, worth trying, perhaps in -5
13:36 < jrandom> ok coo', well, we'll see and hopefully get -5 out in the next few days
13:37 < jrandom> (maybe tomorrow)
13:37 < jrandom> ok, if there's nothing else on 2) floodfill netdb, lets move on to 3) syndie
13:38 < jrandom> i posted a bunch of info in the mail and on my blog, so rather than rehash them, does anyone have any questions / comments / concerns?
13:40 * jrandom really digs the remote syndication functionality, though its far from what we're hoping for with feedspace integration
13:41 < jrandom> (i havent been bothered to do freenet posting integration, though it would be quite easy to fire up a CLI and post all the entries in)
13:42 < jrandom> ok, if there's nothing else on 3) syndie, lets open 'er up to 4) ???
13:42 < jrandom> anyone have anything else i2p related to bring up?
13:42 < redzara> sure, where is the doc ;)
13:43 < laberhorst> just that my node under 0.6.x sonsumes up to 100% cpu load, but have to crosscheck it with linux on that line here
13:43 <+nickless_head> I think the i2pProxy.pac script should be in the jetty web folder by default.
13:43 < jrandom> nickless_head: i dont recommend i2pproxy.pac, as its a huge security risk
13:44 < redzara> 2 - could be have the latest build of jetty included in I2P ?
13:44 < jrandom> we've got 5.2.1 in i2p right now
13:44 < jrandom> er, 5.1.2
13:44 <+nickless_head> jrandom: it's the only thing available for separating between eepsites and websites in one browser without having to switch by hand afaik
13:45 < jrandom> i use switchproxy
13:45 < jrandom> (and i dont switch to non-anonymous browsing)
13:45 < jrandom> ((squid.i2p is fast enough for me))
13:45 <+nickless_head> Think of the slashdotters! :p
13:46 < jrandom> as i've said before, i have reservations about the viability of eepsites. the security risks are tremendous
13:46 < jrandom> but, for those who don't care about those risks, perhaps an i2pproxy.pac makes sense.
13:47 <+bla> I strongly think that something that isn't secure by _default_, shouldn't be in I2P, as to not give new users a false sense of secutiry
13:48 < jrandom> agreed (though we do push i2pproxy.pac, we just dont tell people about it until we scare 'em enough ;)
13:49 <+nickless_head> I somehow can't believe that within the configuration of Mozilla there isn't a way to make sites only access resources from the same domain ..
13:50 < redzara> sorry but IRC connection lost :( about jetty there is a fix about common logging and maybe this help me running my mvnforum in the same instance of I2P
13:50 < redzara> Jetty-5.1.5rc1 - 23 August 2005
13:52 < jrandom> ah cool, whats the problem exactly redzara?
13:52 < jrandom> nickless_head: if you find a way, let us know
13:52 < redzara> or maybe i could even only build my own I2P with the latest version of jetty
13:52 < jrandom> redzara: that you certainly can do - just drop in the jetty jar files into your i2p lib directory
13:53 < redzara> jrandom : everythime i try to start mvnforum in I2P, jetty failed to find apache common logging
13:53 <+nickless_head> Oh! I just noticed that the default i2pproxy.pac uses a mode which allows sites to switch proxy'ing to i2p on and off at runtime, which is protected by the TOTALLY SECURE AND UNBREAKABLE </sarcasm> default password "passw0rd". Please, someone who knows about cvs change this.
13:54 < jrandom> redzara: thats in commons-logging.jar and commons-el.jar iirc, which should be in your lib dir and in your wrapper.config's classpath
13:54 < jrandom> nickless_head: yet another reason why i dont recommend anyone use it ;)
13:55 < redzara> yes i know, i'm not so n00b :)) i've to dig into again with this new version of jetty
13:56 < jrandom> cool, keep us updated
13:56 < redzara> np
13:57 < fox> * mihi guesses most i2p users will reveal their "real ip" to a java applet anyway :)
13:57 < fox> <mihi> try http://www.stilllistener.com/checkpoint1/Java/ (and scroll down)
13:58 * jrandom sees lots of blank fields ;)
13:59 <+bla> fox: All one exposes is the relation between an IP and a particular client destination, where the client destination will change at every router restart.
13:59 < jrandom> bla: unless the user is on some site like e.g. http://i_have_illegal_stuff.i2p/
14:00 < jrandom> (exposing the clients IP "just once" is fatal enough ;)
14:00 <+bla> jrandom: Yes.
14:00 <+bla> But then again, if you're serious about anonymous browsing, you'll use temporary HTTP proxies, and disable all things java, and plugins, and cookies, entirely
14:01 < jrandom> or use syndie :)
14:02 < ZULU> sorry for interruption,is duck.ip down ?
14:02 <+bla> jrandom: Is it time yet for general questions?
14:02 < jrandom> aye, we're on 4) ???
14:02 < jrandom> ZULU: yeah, duck is offline for the time being
14:03 <+bla> jrandom: I've edited the java-files that help profiles.jsp and tunnels.jsp generate the country-flags
14:04 <+bla> jrandom: However, where do I place images that I can actually LINK to, and that will work, on my local router (_not_ my eepsite)?
14:06 < jrandom> we need a "get.jsp?name" that dumps the contents of ./docs/'name' to the browser
14:06 < jrandom> (aka you need to have it in the .war right now, but with a tiny .jsp file, you could dump 'em in docs)
14:06 <+bla> jrandom: Ah, ok, so it wasn't my fault ;)
14:06 < jrandom> heh nope, blame me :)
14:09 < jrandom> ok, if there's nothing else for the meeting
14:09 * jrandom winds up
14:10 * jrandom *baf*s the meeting closed

10
i2p2www/meetings/145.rst Normal file
View File

@@ -0,0 +1,10 @@
I2P dev meeting, August 30, 2005
================================
Quick recap
-----------
TODO
Full IRC Log
------------

Some files were not shown because too many files have changed in this diff Show More