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