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> 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> wb, its looking a bit bumpy over here 13:43 < deer> 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> Sorry, have to catch a bus I'll read the logs later night. 13:45 < deer> 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> 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> one of my servers lost its link 13:46 < deer> 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> jrandom: in my case jvm was still running - but no connection lead to success for about 15 minutes 13:47 < deer> 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> jrandom: np - wanted to write you a mail but forgeot 13:49 < deer> 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> 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> . 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> postman, you 'round? 14:04 < deer> yo :) 14:04 < deer> ok 14:04 < deer> * postman waves 14:05 < deer> well, gentlemen. Some of you may have noticed that we have finally implemented in/out services 14:05 < jrandom> [w00t!] 14:05 < deer> please reas www.postman.i2p/inout.html 14:05 < deer> please test the system out 14:06 < deer> baffled will deliver the 2nd official mx 14:06 < jrandom> word 14:06 < deer> right now i am working on IMAP implementation 14:07 < deer> 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> right now i am evaluating/testing 14:07 < jrandom> cool 14:07 < deer> why IMAP and not pop3 ? 14:07 < deer> yeah, and the serverside as well 14:08 < deer> Natalia: we have pop3 already 14:08 < deer> pop3 can be used of course 14:08 < deer> IMAP4 will make us more flexible for webmail systems (hopefully) 14:10 < deer> this is still open issue 14:10 < deer> okay. 14:10 < deer> you sounded like you were going to switch from pop3 to IMAP 14:11 < deer> no, of course not 14:11 < deer> 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> mmh, yes 14:13 < deer> 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> 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> for www.postman.i2p 14:13 < deer> postman runs i2p's first mail-service, providing free and anonymous pop3 and SMTP 14:13 < deer> accounts over i2p. Recently implemented is the ability to send and receive e-mails to and 14:13 < deer> from outside of the i2p network, marking the services of www.postman.i2p as a nifty 14:13 < deer> destination for any concerned e-mailer and soon a must-have, as mail.i2p e-mail accounts 14:13 < deer> become the norm for eepsite-authors. 14:14 < deer> sound good ? 14:14 < deer> thanks Natalia :) 14:14 < deer> jrandom: i think it's not a urgent issue 14:14 < deer> * Natalia curtsies :) 14:15 < deer> jrandom: maybe we pick up the webmail issue later again :) 14:15 < jrandom> agreed postman 14:15 < deer> 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> dinoman: you 'round? 14:16 < dm> Yeah, I'm still waiting for BT to reactivate my ADSL 14:16 < jrandom> !thwap 14:17 < deer> dino has done some good work 14:17 < deer> with Ragnarok to fix some ends 14:17 < deer> so far it looks like the current problems are: 14:17 < deer> - SAM unreliability 14:17 < deer> - Python SAM library issues 14:17 < deer> - Incorrect usage of the Python SAM lib 14:18 < deer> - Correct handleing of destination instead of host/ip/port 14:18 < deer> once those are fixed it should work 14:18 < jrandom> cool 14:19 < deer> I think it is needed to take a little step back though 14:19 < deer> and agree on how to modify the protocol to properly handle destinations 14:19 < deer> 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> each peer has an unique peer_id of 20 bytes 14:20 < deer> it is normally derived from the host/ip 14:21 < deer> I think that using the full destination is a bit much 14:21 < deer> what globally unique thing should we use? 14:21 < jrandom> SHA1(destination)[0:19] 14:21 < jrandom> perhaps? 14:21 < deer> first twenty bytes of the dest? :) 14:22 < deer> 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> 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> i have fixed the php tracker to send the full key as the ip 14:24 < deer> actually the client generates the peer_id 14:24 < deer> (what do you mean with 'key'?) 14:25 < deer> destination 14:25 < dm> Sounds like a who's on first skit. 14:25 < dm> Use full sentences people! 14:26 < deer> ok fine :/ the tracker sends the Full destination as the ip 14:27 < jrandom> heh dont mind dm. sounds great 14:27 < deer> peer id is just for the trackers 14:27 < deer> 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> so no religious wars start each time the name of the snake is dropped 14:29 < deer> works for me 14:29 < deer> 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> definitly 14:30 < deer> jrandom you got it 14:31 < deer> 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> at ip50 you will see a junk key 14:32 < jrandom> cat-a-puss: yes 14:32 < deer> yes 14:32 < cat-a-puss> then we should talk 14:32 < jrandom> welcome to the weekly meeting! :) 14:32 < deer> it will need to be something like .i2ptorrent to make it live togeter 14:32 < deer> 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> right 14:35 < deer> lets use ugha.i2p to write up some specs 14:35 < deer> . 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> makes it all a challenge 14:37 < deer> hehe ok 14:38 < deer> ... 14:38 < deer> 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> mail i am stuck on using the i2p mail system 14:40 < deer> 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> auth 14:41 < protok0l> Uptime: 5d 14:41 < protok0l> ii own 14:41 < deer> it is not in the class Savane uses 14:42 < deer> 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> because i am looking at the I2P Public Domain Software Homepage in my browser now 14:43 < jrandom> w00t 14:45 < deer> 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> 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> I wouldn't mind helping with that 14:47 < dm> protocol 14:47 < deer> Got to do something. :-) 14:47 < deer> i will do auth :( it will take a little time but i will do it 14:47 < deer> yes dm 14:48 < jrandom> see, you've got a volunteer already dinoman! :) 14:48 < deer> maybe i could host a nessus server 14:48 < deer> and tunnel it through TOR on my side 14:49 < deer> Plus I need a good excuse to work on the rest of my network. 14:49 < deer> and i shall dedicate myself to learning python 14:49 < janonymous1> 'the i2p software foundation'. I can see it now 14:49 < deer> 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> i can run the i2p software foundation 14:51 < deer> lol 14:51 < duck> some interesting parts about negative imago 14:52 < deer> give me the keys the the treasury 14:52 < duck> having good default 14:52 < deer> 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> wow, im seeing 83 peers 14:52 < duck> now we know why there are so few known hidden sides on tor 14:53 < deer> 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> (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> 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> jrandom doesn't approve of got 14:56 < deer> *gott 14:57 < duck> jrandom: yeah, but well 14:57 * duck counts the amount of anarchy friendly regions on the globe 14:57 < deer> so I have to be Natalia, the loved female of the channel 14:57 < deer> ( 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> 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> 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> 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> content neutrality is something I write about in the latest eeplog entry 15:00 < deer> 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> jrandom: do you support not support the idea of eepsite crawlers linking to illegal material, being linked from the frontpage ? 15:01 < deer> +or 15:01 < deer> 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> jrandom: none of these are registered 15:02 < duck> but from an usability point I might 15:02 < deer> the script checks host.txt 15:02 < deer> *hosts.txt 15:02 < jrandom> from a nontechnical perspective, i support whatever the user community requires 15:02 < deer> so everyone gets added to the list if they have a domain 15:03 < deer> ugh, bras are so uncomfortable. 15:03 < protok0l> yup, creepy 15:03 < deer> 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> :) 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> 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> 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> 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> well. 15:06 < deer> lets hope DrWoo can keep his indices free of corruption 15:06 < jrandom> certainly BS314159 15:06 < BS314159> not versions. distributions. 15:06 < deer> files.i2p should be one link 15:06 < jrandom> BS314159: people can even edit their own local link page 15:06 < deer> 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> search engines and internet directories serve different roles 15:07 < deer> this is why the directory is there in the first place 15:07 < deer> 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> by people 15:07 < deer> so I think the search-engine is good 15:07 < jrandom> right BS314159 15:07 < deer> but should not be the limit 15:07 < deer> search engine, internet directory, wiki, help page 15:07 < deer> 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> jrandom: perhaps you shouldn't link to fproxy.i2p 15:08 < deer> it is almost always down 15:08 < jrandom> BS314159: i think a cntent filter in the search engine is excessive 15:08 < deer> it is down right now, it seems 15:09 < protok0l> it is 15:09 < deer> 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> BS3: aol.i2p ;-) 15:10 < jrandom> ok, is there anything else for the meeting? 15:10 < deer> whoa...still in the meeting... 15:11 < deer> 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