Moved meetings/* to meetings/logs/ (ready for splitting out meetings code)

i2p2www/meetings/logs/1.log

@@ -0,0 +1,695 @@
+--- Log opened Wed May 22 02:01:22 2002
+02:01 <+logger> Logging started
+02:01 <@nop> ok
+02:01 <@nop> welcome to this humble first meeting
+02:01 <@nop> first and foremost
+02:02 <@nop> Thank you's to all of you for your efforts
+02:02 <@nop> especially as we all know that there is Real life to deal with
+02:02 <@nop> and that we've done pretty well so far
+02:02 <@nop> meeting: The reason for this meeting(s) will be plural hopefully
+02:03 <@nop> we need to gain some order for development and schedules and tasks that are being done for IIP
+02:03 <@nop> whether it's contributed tasks, ala #factory, or backend, ala inform, or core ala IIP software
+02:03 <@nop> or ircd
+02:03 <@nop> :)
+02:03 <@mids> .
+02:04 <@mids> (to indicate I am here)
+02:04 <@nop> I think we all share a common goal in supporting this project, and it has it's rewards just knowing the technology is becoming possible to help a lot of people with free speech, privacy, anonymity and security
+02:04 <@nop> this is a great project in the matter, because it challenges all of these topics, and is sparking intereests especially in these times
+02:05 <@mids> agenda:
+02:05 <@mids> - Welcome (nop)
+02:05 <@mids> - Status of developers / projects (nop)
+02:05 <@mids> - Website (nym)
+02:05 <@mids> - Release Roadmap
+02:05 <@mids> - Documentation (cohesion, codeshark, mids)
+02:05 <@mids> - Question Round
+02:05 <@nop> so welcome all, and again thank you.
+02:05 <@Chocolate> (still connected)
+02:05 <@nop> next on the agenda: Status of developers
+02:05 <@nop> hehe
+02:06 <@nop> before we get there
+02:06 <@nop> a side not, this meeting is invite only
+02:06 <@nop> but will be logged and published to the public for viewing and/or comments
+02:06 <@nop> as well as the results 
+02:06 <@mids> live logging is on http://mids.student.utwente.nl/~mids/iip-dev.txt
+02:06 <@mids> (in case you drop out)
+02:07 <@nop> ok
+02:07 <@nop> Status of developers
+02:07 <@mids> who first? :)
+02:08 <@nop> UserX and I have been focusing on IIP 1.1 to be released, but we're to the point of no return where we would like to release iip rc2 for running tests by the team and public, but would like more thorough docs, so that's the hold up there
+02:08 <@nop> let's talk about docs
+02:08 <@nop> status : mids, cs, ?
+02:08 <@codeshark> you :)
+02:08 <@mids> .
+02:08 <@mids> me
+02:09 <@mids> I joined IIP when I heared about it on Freenet
+02:09 <@mids> after some chatting etc, I made Trent
+02:09 <@mids> our big friend :)
+02:09 <@nop> yes
+02:09 <@mids> also done some ircd patches
+02:09 <@mids> helped by Chocolate, thanks!
+02:10 <@mids> I promised 0x90 to look into doing client 2 client encryption
+02:10 <@mids> I did a lot of talking and research
+02:10 <@mids> but nothing is done :(
+02:10 <@nop> tis ok
+02:10 <@mids> currently I kind of dropped it, because I lacked time and willing
+02:10 <@mids> something slightly related:
+02:11 <@mids> I coded bankbot
+02:11 <@mids> another helpfull application for IIP :)
+02:11 < nym> hey
+02:11 <@nop> welcome
+02:11 < nym> only non op ;)
+02:11 <@nop> mids
+02:11 <@nop> continue
+02:11 -!- mode/#iip-dev [+o nym] by Chocolate
+02:11 -!- mode/#iip-dev [+o nym] by mids
+02:11 <@nym> sorry, i was under the impression the meeting was tomorrow
+02:12 <@mids> last act of me was that I ported the docs to LaTeX, more about that later
+02:12 <@mids> .
+02:12 <@nop> k
+02:12 <@nop> cs
+02:12 <@codeshark> ok, like mids i heared about iip on freenet
+02:12 <@codeshark> and chatted with nop about it :)
+02:13 <@codeshark> then i made our inform relaychecker script, that keeps a list of the running nodes
+02:13 <@codeshark> now i'm doing some anonymail stuff...
+02:14 <@nop> on a note
+02:14 <@nop> cs is responsible for the "dynamic routing system" that being the inform server
+02:14 <@nym> freenet is too slow, so i came here
+02:15 <@codeshark> anything else?
+02:15 <@codeshark> hmm, the docs
+02:16 <@codeshark> i created a windows version of our docs (.chm format)
+02:16 <@nop> yes
+02:16 <@nop> which will need updating once cohesion finishes the docs
+02:17 <@codeshark> i also made a test for the docbook format
+02:17 <@codeshark> but we'll come back to this later
+02:17 <@mids> you bet I will
+02:17 <@codeshark> that's it for now
+02:18 <@codeshark> chocolate?
+02:19 <@Chocolate> I first heard of IIP on freenet from CofE
+02:19 <@Chocolate> after seeing a couple of anouncements about it on his freesite
+02:19 <@Chocolate> I decided to try it out
+02:19 <@Chocolate> since then I have helped with misc things
+02:20 <@Chocolate> running a relay (precrypto, the DH didnt work on my 486)
+02:20 <@Chocolate> helping to debug the memory leak (by killing the ircd for about 5 hours...)
+02:21 <@Chocolate> my first main codeing cotribution to IIP was helping mids with Trent
+02:21 <@nop> kewl
+02:21 <@nop> don't forget hydrabot
+02:21 <@nop> or eyek0n
+02:21 <@Chocolate> oh yea right
+02:22 <@Chocolate> hydrabot came out of a disire to be able to see waht was happening on #freenet on OPN
+02:22 <@Chocolate> unfortunetly the bot died the sad death of flexibilitise
+02:23 <@nop> and along came eyek0n
+02:23 <@nop> :)
+02:23 <@Chocolate> yes, eyek0n is a modified changate that was hacked up to serve the purpos that HydraBot was intended to fill
+02:25 <@Chocolate> I also maintain a misc group of xchat and other scripts for IIP, some donated, others my own
+02:25 <@Chocolate> my current area of work is on ThreadChat, a realtime BBS/forums type sytem over IRC
+02:25 <@Chocolate> .
+02:25 <@nop> kewlness
+02:26 <@nop> ok
+02:26 <@nop> is that all?
+02:26 <@mids> ardvark just joined, he isnt a developer, but a zeroday user... he isnt allowed to introduce himself because otherwise this will take too long
+02:26 <@mids> maybe a quicky for nym?
+02:26 <@nop> ok
+02:27 <@nop> nym : developer intro
+02:28 <@nop> ok
+02:28 <@nop> I'll say it
+02:28 <@nop> he seems to be off somewhere
+02:28 <@mids> go for it
+02:28 <@nop> he comes to us as the web developer of freenetprojects' site
+02:29 <@nop> and we're open he can give us a make over to give us a more global appeal of anonymous irc/internet projects
+02:29 <@nop> open == hoping
+02:29 <@nop> he will be focusing on a lighter design with press releases etc
+02:29 <@nop> gives us less of a hobby and more of a serious developer team look to us
+02:30 <@nop> even though you can't see us
+02:30 <@nop> :)
+02:30 <@nop> hehe
+02:30 <@mids> :)
+02:30 <@nop> ok
+02:30 <@nop> agenda list
+02:30 <@nop> please
+02:30 <@mids> - Website (nym)
+02:30 <@mids> - Release Roadmap
+02:30 <@mids> - Documentation (cohesion, codeshark, mids)
+02:30 <@mids> - Question Round
+02:31 <@Chocolate> can't do website now if nym isnt here
+02:31 <@nop> ok well let's talk about website when nym seems awake
+02:31 <@nop> so Release Roadmap
+02:31 <@mids> .
+02:31 <@nop> our first focus on this is rc2
+02:31 <@nop> This is for testing the changes and added features and to break in any network changes that may occur before 1.1
+02:32 <@nym> hi
+02:32 <@nym> i'm here
+02:32 <@nop> ok
+02:32 <@nop> website
+02:32 <@nop> please
+02:32 <@nop> then we'll go back
+02:33 <@nop> to roadmap
+02:33 <@nym> well the website is coming along, although i thought i had another day to get something to you guys
+02:33 <@nop> do you have any screen shots at all
+02:33 <@nym> not on hand
+02:33 <@nop> hmm mids
+02:34 <@mids> http://mids.student.utwente.nl/~mids/draft2.jpg
+02:34 <@nop> do you have draft2?
+02:34 <@nop> ok
+02:34 <@nop> that will give people an idea
+02:34 <@nop> this is older
+02:34 <@nop> but it's what we have
+02:34 <@nym> okay, well what i need to know is what release this is going to correspond with
+02:34 <@nop> the current release
+02:34 <@nop> and we can modify easily
+02:34 <@mids> nop: current as in rc2 ?
+02:35 <@nop> current as as soon as we can get something
+02:35 <@nym> i thought you had a big release on the horizon
+02:35 <@nop> so focus on iip 1.1 rc1
+02:35 <@mids> :)
+02:35 <@nop> yes
+02:35 <@nop> but
+02:35 <@nop> we need something going
+02:35 <@nop> other than what we have
+02:35 <@nop> something that has a easily modifiable template
+02:35 <@mids> we want to have the site betatested too, same with the rcs
+02:35 <@nop> so that it can be prepped for released
+02:35 <@mids> so we can go 'big' on 1.1
+02:35 <@nop> releases
+02:35 <@nop> ok
+02:35 <@nop> site betatested
+02:35 <@nym> yeah, but what releases do you have coming, and when?
+02:36 <@nop> rc 2
+02:36 <@nop> is coming
+02:36 <@nop> cohesion is working on docs
+02:36 <@nop> cs it's easy for you to do .chm correct?
+02:36 <@nym> no idea what those are
+02:36 <@codeshark> nop: we'll have to talk about docs later :)
+02:36 <@nop> ok
+02:36 <@Chocolate> are we on the relese roadmap now or are we still on the website?
+02:36 <@nop> website
+02:36 <@nop> we went back
+02:36 <@nop> because nym is awake ;)
+02:36 <@nym> aye
+02:37 <@nop> let's focus on getting somethign up
+02:37 <@nop> then we can be focused on release
+02:37 <@nym> hrm okay
+02:37 <@nym> well i'll get something going
+02:37 <@nop> we would like to have it modifiable
+02:37 <@nop> this is key
+02:37 <@nop> so it's template based
+02:38 <@mids> nym: can you name the changes between the draft and current?
+02:38 <@nym> umm
+02:38 <@nop> umm, current I have no clue on
+02:38 <@nop> he might
+02:38 <@nop> I saw n : and answered
+02:38 <@nop> my bad
+02:38  * nop will shut up now
+02:39 <@nym> okay..
+02:39 <@nym> well lots 
+02:39 <@nym> font changes
+02:39 <@nym> drop shadows
+02:39 <@nym> the logo looks different (invisiblenet.net/iip/)
+02:40 <@nym> better crunchbox logo
+02:40 <@mids> great
+02:40 <@nym> we don't have a mac version, so i dropped that
+02:41 <@nym> plus i dropped anything to do with invisible im because that's not happening
+02:41 <@nop> not as that title
+02:41 <@nop> no
+02:41 <@nym> that's confusing
+02:41 <@nop> IIP is simple and makes sense
+02:41 <@mids> question: what about FreeBSD & OpenBSD ? its the same release as linux
+02:41 <@nop> let's focus on the now for that
+02:42 <@nop> yes
+02:42 <@nop> mids it is
+02:42 <@mids> freebsd users will be offended if they would have to click on a Tux
+02:42 <@nop> hmm
+02:42 <@nop> good point
+02:42 <@nym> i worry about the neiche market still tho
+02:42 <@nop> can we have maybe a tux and a devil fucking ;)
+02:42 <@nop> hehe
+02:43 <@nym> well we'll offer source
+02:43 <@nym> freebsd doesn't need a logo
+02:43  * nop says bad jokes too oftne
+02:43 <@nop> often
+02:43 <@nop> ok
+02:43 <@nop> so when can we get a new draft
+02:43 <@nop> give us a solid date
+02:43 <@nop> GMT
+02:43 <@mids> :)
+02:44 <@nym> well i can promise progress by next meeting
+02:44 <@nym> but i'm in the middle of a big contract atm
+02:44 <@nop> how much progress, like something we can put up?
+02:44 <@nym> well no
+02:44 <@nop> hmm
+02:44 <@codeshark> nop: it's better to wait until it's complete anyway
+02:45 <@nym> ditto
+02:45 <@mids> codeshark: current looks is terrible
+02:45 <@nop> understood codeshark : just thinking maybe we can revamp the current look though
+02:45 <@mids> I suggest reverting to the old look
+02:45 <@nop> it needs a lighter feel
+02:45 <@mids> till the site is done
+02:46 <@nop> we could do that unless nym can maybe dish out a slightly lighter look for it possibly
+02:46 <@nop> with a donation button and just like an intro page
+02:46 <@nym> for what?
+02:46 <@nop> for the site, instead of the under construction we have now
+02:46 <@nop> maybe like something gives more an intro and download software right off the bat
+02:47 <@Chocolate> well the old site is linked
+02:47 <@nop> then take them to the site behind it
+02:47 <@codeshark> nop: just make the old page easier to find
+02:47 <@codeshark> put the link up a bit
+02:47 <@nop> ok
+02:47 <@nym> well edit that as needed
+02:47 <@nop> ok
+02:47 <@nop> we'll figure something out
+02:47 <@mids> k
+02:47 <@nym> i'm going to keep working on the big release
+02:47 <@nop> can you give us a draft by friday?
+02:48 <@nym> most likely
+02:48 <@nop> ok
+02:48 <@codeshark> but keep the intro page until the new site is complete
+02:48 <@mids> screenshot is enough
+02:48 <@nop> thnk you
+02:48 <@nop> yes
+02:48 <@nop> screenshot/draft
+02:48 <@nop> same thing to me
+02:48 <@nym> i've got everything on my laptop now.. 
+02:48 <@nym> it shouldn't be a problem
+02:48 <@nop> ok
+02:49 <@nop> next part
+02:49 <@nop> back to roadmap release
+02:49 <@mids> what are the current limits for doing RC2 ?
+02:49 <@codeshark> what's missing except the docs?
+02:49 <@nop> RC2 as stated earlier is designed to get all the bugs out and adjust to changes for 1.1 final release
+02:49 <@nop> that's it
+02:49 <@nop> docs are needed
+02:49 <@nop> and new .chm
+02:49 <@nop> and cs
+02:49 <@nop> make sure we don't include .ini or listen.ref this time
+02:49 <@nop> :)
+02:49 <@codeshark> sure :)
+02:50 <@codeshark> has been removed
+02:50 <@nop> ok
+02:50 <@nop> also
+02:50 <@nop> cs
+02:50 <@nop> in the future
+02:50 <@nop> as people move over
+02:50 <@nop> to rc2
+02:50 <@nop> we can wait a week
+02:50 <@nop> but then after that I need you to add closedelay: infront of the networkprotocol = closedelay:etc
+02:50 <@nop> this is a key feature
+02:50 <@nop> that has been wanted
+02:51 <@codeshark> ok
+02:51 <@nop> this tells the network to hold on to the user even if he dies out from 15-45 seconds
+02:51 <@mids> (closedelays makes your connection staying up for a little while if your client or node disconnects)
+02:51 <@mids> (making it harder to track you to your IP)
+02:51 <@nop> yes
+02:51 <@codeshark> will it break rc-1 clients completely?
+02:51 <@Chocolate> can you reconnect to the held connection?
+02:51 <@nop> if we wait a week
+02:52 <@nop> most people should have upgraded
+02:52 <@codeshark> i'd wait a bit longer than a week
+02:52 <@nop> ok
+02:52 <@nop> maybe 2
+02:52 <@nop> because the network side will have it
+02:52 <@nop> it will still help you
+02:52 <@nop> but by the time rc2 is everyone
+02:52 <@nop> the entire network will help support your delayed presence
+02:53 <@nop> please send a ! now if you guys are willing to pre-test before we officially release rc2
+02:53 <@nop> making sure things go smoothly
+02:53 <@mids> !
+02:53 <@codeshark> !I have to do that anyway ;)
+02:53 <@nop> hehe
+02:53 <@nop> anyone else?
+02:54 <@codeshark> tell me if you're ready for rc-2 and i'll prepare the windows installer and *nix tgz
+02:54 <@nop> irc is tough for this anyway
+02:54 <@codeshark> you have my pager e-mail?
+02:54 <@nop> ok, should be ready for friday, but I really want docs updated 
+02:54 <@nop> no I don't
+02:54 <@Chocolate> !
+02:54 <@nop> please send it privately
+02:54 <@codeshark> sure
+02:55 <@nop> this is a publicly logged channel
+02:55 <@nop> you all have mine I assume
+02:55 <@Chocolate> the one that's only outgoing?
+02:56 <@nop> hehe
+02:56 <@nop> ok, to answer cs's question
+02:57 <@nop> closedelay - we need to hold off at least 2 weeks
+02:57 <@nop> and promote it well enough
+02:57 <@nop> so that people do upgrade
+02:57 <@nop> the challenge is
+02:57 <@nop> making sure relay users can just simply upgrade
+02:57 <@nop> without redoing the relay system
+02:57 <@nop> that should be trivial
+02:57 <@nop> but it's a necessity to make sure it's done right
+02:57 <@nop> choc
+02:57 <@nop> your question of reconnecting to help connection
+02:57 <@nop> can you elaborate
+02:57 <@nop> held
+02:57 <@nop> not help
+02:58 -!- mode/#iip-dev [+o UserX] by mids
+02:58 <@nop> welcome userx
+02:58 <@UserX> hi
+02:58 <@nop> can you redisplay agenda list for userx
+02:58 <@nop> please
+02:58 <@mids> - Welcome (nop)
+02:58 <@mids> - Status of developers / projects (nop)
+02:58 <@mids> - Website (nym)
+02:58 <@mids> - Release Roadmap
+02:58 <@mids> - Documentation (cohesion, codeshark, mids)
+02:59 <@mids> - Question Round
+02:59 <@nop> we're on release roadmap
+02:59 <@Chocolate> the closedelay holds the connection open after the user drops from IP change, or (ip) network failure
+02:59 <@nop> yes
+02:59 <@Chocolate> can you reconnect to this help connection?
+02:59 <@nop> no
+02:59 <@nop> it's just for traffic analysis preventative assistance
+02:59 <@Chocolate> ok, great
+02:59 <@nop> but there is a major other feature that works
+02:59 <@Chocolate> I assume it's help for a random time?
+02:59 <@mids> s/help/held/
+03:00 <@codeshark> nop: did you include the feature that tries another relay if the first doesn't work?
+03:00 <@Chocolate> s/help/held/
+03:00 <@nop> it will retry (default 5 tries) (random time yes) when connecting to network nodes so you won't get disconnected each time a relay doesn't work
+03:00 <@codeshark> ok, cool
+03:00 <@nop> codeshark see above, yes
+03:00 <@mids> wow, cool
+03:00 <@nop> this does not help you if a relay fails and you're already conencted to it
+03:01 <@nop> that is what closedelay does though
+03:01 <@nop> is makes you stall a bit visually
+03:01 <@codeshark> btw: we should stop adding features now
+03:01 <@nop> it's already stopped
+03:01 <@nop> :)
+03:01 <@codeshark> :)
+03:01 <@nop> cvs rc2 is tagged I believe is it not userx?
+03:01 <@UserX> it's not tagged yet
+03:01 <@codeshark> nop: not only to rc-2 but also to 1.1
+03:01 <@nop> correct
+03:02 <@nop> rc2 is just testing of the already set features
+03:02 <@nop> and changes
+03:02 <@nop> also cs
+03:02 <@nop> make sure we have a decent changelog
+03:02 <@nop> I sent you that list
+03:02 <@codeshark> hmm
+03:02 <@codeshark> email?
+03:02 <@nop> the changes and features
+03:02 <@nop> yes
+03:02 <@nop> I cc'd to you and cohesion
+03:02 <@Chocolate> could there be someway to verify that a relay has been added to the check list?
+03:02 <@nop> UserX - we're covering roadmap release, is there anything you would like to add
+03:02 <@codeshark> k, got it
+03:03 <@Chocolate> like I have no idea if my relay isnt on the public list becouse it didnt inform right, or becouse it's to unreliable
+03:03 <@nop> choc it's most likely not
+03:03 <@nop> but that's ok
+03:03 <@nop> we forgive you
+03:03 <@nop> :)
+03:04 <@codeshark> hmm, i think i should add a page where you can get infos about you relays
+03:04 <@mids> Chocolate's question is often asked
+03:04 <@codeshark> "you relays" = "your relay"
+03:04 <@nop> and you don't think that would compromise anything
+03:05 <@Chocolate> make the request come from the IP that the relay in question would have?
+03:05 <@codeshark> i won't show too much info
+03:05 <@codeshark> and i need to keep the deleted relays too
+03:05 <@codeshark> just mark them as deleted
+03:05 <@nop> spoofing 
+03:05 <@nop> UserX - looks like that's a no
+03:05 <@nop> hehe
+03:06 <@codeshark> nop: tcp/ip conections can't easily be spoofed
+03:06 <@nop> easily, but they can be
+03:06 <@codeshark> except you are somewhere between the relay and me
+03:06 <@mids> it is a php thing isnt it? (not an isproxy one)
+03:06 <@codeshark> yes
+03:06 <@nop> agenda list please
+03:07 <@mids> - Welcome (nop)
+03:07 <@mids> - Status of developers / projects (nop)
+03:07 <@mids> - Website (nym)
+03:07 <@mids> - Release Roadmap
+03:07 <@mids> - Documentation (cohesion, codeshark, mids)
+03:07 <@mids> - Question Round
+03:07 <@codeshark> i'll just show a small status message ("your node is on the public list", "your node has been deleted because it was down to often..."
+03:07 <@nop> ok
+03:07 <@nop> cs that's fine
+03:07 <@nop> any more questions on roadmap release
+03:07 <@mids> .
+03:07 <@nop> ok next part
+03:07 <@nop> documentation
+03:07 <@mids> ill do intro
+03:07 <@nop> k
+03:08 <@mids> cohesion is document manager
+03:08 <@mids> but he isnt here
+03:08 <@mids> codeshark and me are both working on it
+03:08 <@mids> codeshark did .chm (windows help) and Docbook
+03:08 <@mids> and will tell about that
+03:08 <@mids> I did a LaTeX version, and will explain that
+03:08 <@mids> why 2 systems?
+03:08 <@mids> docbook was taking long, and I was getting impatient
+03:09 <@mids> I knew that a release should be soon, so docs are wanted
+03:09 <@mids> I have no hate regarding codeshark or anything :)
+03:09 <@codeshark> :)
+03:09 <@mids> codeshark, can you tell us about docbook? pro and con and status?
+03:09 <@nop> also note
+03:09 <@codeshark> ok
+03:09 <@nop> cs was in the process of moving
+03:10 <@codeshark> pro's: docbook uses xml; it can generate different output formats: pdf, html, and "CHM"
+03:10 <@codeshark> cons: it's not that easy to learn. I think i'm the only one who wrote some help pages in it yet :(
+03:10 <@mids> hey, I ported trent!
+03:11 <@codeshark> completely?
+03:11 <@codeshark> cool
+03:12 <@codeshark> another thing about the docbook stuff we use: it's taken from the phphelp
+03:12 <@codeshark> so we have all the tools/templates for the different output formats
+03:12 <@mids> http://cvs.php.net/cvs.php/phpdoc
+03:12 <@mids> they made the CHM link with M$ chm cooking facility
+03:13 <@codeshark> it has been tested. it works. i converted some chapters of the doc to docbook
+03:13 <@codeshark> about CHM: why CHM?
+03:14 <@mids> proprietary fileformats are cool? :)
+03:14 <@codeshark> nope :)
+03:14 <@codeshark> it's the default help format on windows. it supports keyword search, fulltext search and has a nice grouping of the help chapters
+03:15 <@codeshark> it allows you to add bitmap to the helps (see iip.chm)
+03:15 <@nop> also very handy for IIP help systray  option
+03:15 <@codeshark> btw: mids, there's also a *nix chm viewer
+03:15 <@mids> sure
+03:16 <@mids> done?
+03:16 <@codeshark> yes
+03:16 <@mids> okay, LaTeX is a much older system then docbook
+03:17 <@mids> pro: its well known in the academic word, it doesnt use XML, it support different outputs: ps, dvi, pdf, html, txt. and I know it
+03:17 <@mids> con: it doesnt use XML, it is not very easy to learn, no native .CHM support
+03:17 <@nop> interrupt
+03:17 <@nop> real quick
+03:17 <@mids> I converted the whole v1.1.2-pre9 doc
+03:17 <@mids> ok
+03:18 <@nop> for pdf I notice the casper logo
+03:18 <@nop> can we change that to nyms logo
+03:18 <@nop> for reasons of copyright
+03:18 <@mids> sure
+03:18 <@nop> and at the bottom
+03:18 <@nop> I will send you guys a powered by InvisibleNet
+03:18 <@nop> which is us
+03:18 <@nop> logo
+03:18 <@nop> to put at bottom of page
+03:18 <@nop> :)
+03:18 <@codeshark> nop: the existing pdf is just a test anyway
+03:18 <@nop> yes
+03:18 <@nop> I understand
+03:18 <@nop> I'm just requesting
+03:18 <@codeshark> it doesn't use either docbook nor latex
+03:19 <@nop> k
+03:19 <@nop> well, anyway
+03:19 <@nop> that's a yes I assume
+03:19 <@codeshark> yes
+03:19 <@nop> kewl
+03:20 <@mids> I converted the whole v1.1.2-pre9 doc; its on http://mids.student.utwente.nl/~mids/docdemo/
+03:20 <@mids> take a look
+03:20 <@mids> it has the *.tex sourcefiles
+03:20 <@mids> the Makefile
+03:20 <@mids> and all the outputs... pdf, ps, dvi, txt, html and bightml
+03:20 <@nop> mids
+03:20 <@nop> you also have a sourceforge account
+03:20 <@mids> about chm: why does chm suck?
+03:20 <@nop> you have rights to make directories on the website
+03:20 <@nop> so that they can be there as well
+03:20 <@mids> nop: I know
+03:20 <@nop> ok
+03:20 <@nop> kewl
+03:21 <@mids> chm sucks because it is a proprietary microsoft format
+03:21 <@mids> there are no good opensource tools for it
+03:21 <@codeshark> nop: these are just experiments right now. that's why they're not on the sf server
+03:21 <@mids> the chm viewer for *nix is just a hard to use extractor
+03:21 <@mids> nobody uses windows help files anyway
+03:21 <@nop> ok
+03:21 <@mids> :)
+03:21 <@codeshark> hehe )
+03:21 <@codeshark> :)
+03:21 <@nop> mids
+03:21 <@nop> it's helpful for win32 users
+03:22 <@nop> and I say we can use it for help systray option
+03:22 <@mids> you can also put the pdf file in the IIP dir or the html ones
+03:22 <@nop> yes
+03:22 <@mids> and start the browser in the systray option
+03:22 <@nop> umm
+03:22 <@nop> trust me .chm looks nice in windows
+03:22 <@codeshark> sure, but do you have a chapter list in html?
+03:22 <@nop> so stick with that for win32
+03:22 <@mids> I am not against CHM for IIP, I am just not going to do it
+03:22 <@nop> cs will
+03:22 <@nop> no worries
+03:22 <@codeshark> aehm
+03:23 <@codeshark> there's a small problem
+03:23 <@mids> have fun codeshark :P
+03:23 <@nop> uhh
+03:23 <@codeshark> i don't want to have 2 version of the docs like we have now
+03:23 <@nop> sup?
+03:23 <@nop> umm
+03:23 <@nop> maybe we can make chm a separate doc
+03:23 <@nop> :)
+03:23 <@codeshark> that's how it is now
+03:23 <@codeshark> chm and pdf are seperate
+03:23 <@nop> that's all I'm saying
+03:23 <@nop> welcome back userx
+03:23 <@codeshark> but that's not how it should be
+03:23 <@codeshark> right mis?
+03:23 <@codeshark> mids?
+03:23 <@mids> right
+03:24 <@codeshark> what are the possibilities?
+03:24 <@nop> chm is a nice plus
+03:24 <@codeshark> 1) use docbook,...
+03:24 <@nop> one
+03:24 <@nop> not everyone has pdf viewers
+03:24 <@nop> chm for win32 is built in
+03:24 <@codeshark> 2) use latex and try to create the chm's from the htmls
+03:24 <@codeshark> 3) manually synchronize chm and html
+03:24 <@codeshark> 4) drop chm support
+03:25 <@nop> x on 4
+03:25 <@mids> 5) make a light chm with only the menu functions explained
+03:25 <@nop> hopefully x 3
+03:25 <@nop> yes
+03:25 <@nop> that's what I was thinkign
+03:25 <@nop> 5
+03:25 <@mids> (manually)
+03:25 <@nop> like a man page
+03:25 <@nop> :)
+03:25 <@Chocolate> eavryon on win will have a web browser
+03:25 <@mids> and link it for more info to the full doc as html, pdf , dvi, ps whatever
+03:25 <@nop> sounds good
+03:25 <@Chocolate> you should be able to generate an index page from the LaTeX/docbook
+03:25 <@codeshark> ok, i'll look at it
+03:25 <@nop> ok
+03:26 <@nop> is that it for docs?
+03:26 <@mids> no
+03:26 <@nop> ok
+03:26 <@nop> sorry
+03:26 <@mids> still pieces of doc should be written on the unix part
+03:26 <@nop> continue
+03:26 <@nop> also man page
+03:26 <@nop> is that completed
+03:26 <@mids> its still missing in the current one, cohesions work didnt have it
+03:26 <@nop> and symbolicly link iip with isproxy
+03:26 <@nop> like man iip
+03:26 <@mids> man page is in CVS for weeks
+03:26 <@nop> will give man isproxy
+03:26 <@mids> nobody commented on it, so I assume it is perfect
+03:26 <@nop> ok
+03:26 <@nop> nice
+03:27 <@nop> UserX
+03:27 <@nop> will IIP as is auto-install man pages
+03:27 <@codeshark> nop: does it have "make install" yet?
+03:27 <@nop> he might be having connectivity issues
+03:27 <@nop> yes
+03:27 <@mids> hairy topic
+03:28 <@nop> the concern is upgrading relay node users
+03:28 <@mids> location of manpages is really system dependant
+03:28 <@nop> right
+03:28 < UserX> make install should install the man page
+03:28 <@codeshark> yeah, they have to manually upgrade from rc1 to rc2
+03:28 <@mids> configure in 1.2 will fix that
+03:28 <@nop> ok
+03:29 -!- mode/#iip-dev [+o UserX] by mids
+03:29 <@nop> userx hasn't identified - policy
+03:29 <@nop> no ops to unidentified users
+03:29 <@nop> ok
+03:29 <@nop> spoken late
+03:29 <@mids> The nickname userx is registered and identified
+03:29 <@nop> :)
+03:29 <@nop> I am really lagging
+03:29 <@mids> np
+03:29 <@nop> I still have it saying that it's not
+03:30 <@nop> ok
+03:30 <@nop> continue
+03:30 <@mids> I am finished with my part of docs
+03:30 <@nop> cs
+03:30 <@nop> what did you mean they have to manually upgrade
+03:30 <@codeshark> hmm
+03:30 <@codeshark> docbook vs latex? ;)
+03:30 <@mids> latex short term, docbook long term?
+03:31 <@codeshark> output of both formats is ok (except missing chm support of latex)
+03:31 <@nop> I just want to make sure installer sees already known node.ref and listen.ref in there
+03:31 <@nop> as well as isproxy.ini
+03:31 <@nop> cohesion needs to get on the unix stuff
+03:31 <@codeshark> nop: windows?
+03:31 <@mids> mind you that we also have 2 translatins
+03:31 <@nop> yes
+03:31 <@nop> obviously as long as we don't include our own isproxy.ini, node.ref or listen.ref for unix
+03:32 <@nop> we should be fine
+03:32 <@nop> we might want to have a blurb in doc about upgrading
+03:32 <@nop> to install in same directory
+03:32 <@nop> for upgraded node
+03:32 <@nop> or import your .ref and .ini files
+03:32 <@nop> etc
+03:32 <@nop> to be discussed later
+03:32 <@mids> .
+03:32 <@nop> agenda list please
+03:33 <@mids> - Welcome (nop)
+03:33 <@mids> - Status of developers / projects (nop)
+03:33 <@mids> - Website (nym)
+03:33 <@mids> - Release Roadmap
+03:33 <@mids> - Documentation (cohesion, codeshark, mids)
+03:33 <@mids> - Question Round
+03:33 <@nop> ok
+03:33 <@nop> question round
+03:33 <@nop> any questions
+03:33 <@codeshark> nop: i think i'm already handling the upgrading stuff. but i have to check
+03:33 <@nop> ok
+03:33 <@mids> why is not everybody here?
+03:33 <@nop> thnx cs
+03:33 <@codeshark> we looked at it on rc1 already
+03:33 <@nop> answer : real life
+03:33 <@nop> :)
+03:33 <@nop> ok
+03:33 <@mids> is this time correct or need a better one?
+03:34 <@nop> so far it's not conflicting
+03:34 <@mids> (it took 1:30 hours now_
+03:34 <@nop> well
+03:34 <@nop> this is a first meeting
+03:34 <@nop> so I can see why
+03:34 <@nop> we'll get better
+03:34 <@codeshark> well a bit earlier would be nice
+03:34 <@nop> and shorter
+03:34 <@nop> :)
+03:34 <@codeshark> if possible
+03:34 <@nop> the conflict with that
+03:34 <@mids> yes, please
+03:34 <@nop> hmm
+03:34 <@nop> I can't do too much earlier
+03:34 <@codeshark> it's 4 am soon :(
+03:34 <@mids> 1 hour shorter would be fine
+03:34 <@codeshark> yeah, right
+03:35 <@nop> hmm
+03:35 <@mids> more q's?
+03:36 <@codeshark> mids: what is cohesion doing right now?
+03:36 <@nop> let's try this for a bit, and see if it's workable
+03:36 <@codeshark> on the docs?
+03:36 <@nop> dunno
+03:36 <@mids> codeshark: dont ask me
+03:36 <@nop> he needs to work on contact
+03:36 <@mids> btw 1 yodel for everybody attending this meeting
+03:36 <@nop> thnx
+03:36 <@nop> :)
+03:36 <@codeshark> hehe, thanks mids :)
+03:37 <@codeshark> btw: right now we have 4 systems to create help files :(
+03:37 <@nop> closing
+03:38 <@mids> I will leave the log running for a couple of hours
+03:38 <@mids> its available on that url
+03:38 <@nop> meeting ajouned, thank you for all attending
+03:38 <@nop> see you next week
+03:38 <@codeshark> same time, same place?
+03:38 <@nop> yes
+03:39 <@nop> thnx all
+03:39  * nop will brb after these messages
+03:39  * codeshark will go to sleep soon
+03:39 <@mids> night
+03:46 <@nop> night
+03:47 <+logger> Ended logging
+--- Log closed Wed May 22 03:47:55 2002

i2p2www/meetings/logs/1.rst

@@ -0,0 +1,9 @@
+I2P dev meeting, May 22, 2002
+=============================
+
+(Courtesy of the wayback machine http://www.archive.org/)
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/10.log

@@ -0,0 +1,162 @@
+--- Log opened Tue Sep 03 23:55:46 2002
+23:56 <@mids> test
+--- Day changed Wed Sep 04 2002
+00:34 < athena> hello :)
+00:34 < athena> no specific agenda today?
+00:36 -!- mode/#iip-dev [+o nop] by mids
+00:36 -!- mode/#iip-dev [+v logger] by mids
+00:36 <@mids> not yet atleast
+00:55 < athena> OQP... cute :)
+00:56 <@mids> what is OQP?
+00:56 < athena> occupe', i'm guessing
+00:56 <@mids> ic
+00:58 < gabierOQP> OQP=occupé in french
+00:58 < gabierOQP> busy
+00:58 -!- gabierOQP is now known as legabier
+00:59 <@mids> compris
+01:00 <@mids> Tue Sep  3 23:00:00 UTC 2002
+01:00 <@mids> Welcome to the 10th IIP meeting
+01:00 <@mids> Agenda:
+01:00 <@mids> 1) Welcome
+01:00 <@mids> 2) Website status update
+01:00 <@mids> 3) ...
+01:00 <@mids> a) Questions
+01:00 <@mids> .
+01:00 <@mids> lets go to point 1
+01:00 <@mids> welcome all
+01:00 < legabier> why freenet is so slow and iip so fast?
+01:01 <@mids> legabier: can we keep that till part a ?
+01:01 < legabier> ok
+01:01 <@mids> part 2
+01:01 <@mids> nop: status update?
+01:02 <@mids> hm
+01:02 <@mids> the website is in CVS
+01:02 <@mids> nop has reviewed the files
+01:03 <@mids> but there are some parts without good text
+01:03 <@mids> and the support area needs a better layout
+01:03 <@mids> appart from that it is done
+01:03 <@mids> I wont tell you when the site is up
+01:03 <@mids> but you are free to do private bettings on the online time :)
+01:04 <@mids> .
+01:04 <@mids> nop probably has something to add
+01:04 <@mids> lets wait 3 min or something
+01:06 < athena> lol
+01:06 <@mids> I guess nop is too busy with editing the website to answer
+01:06 <@mids> okay well...
+01:06 <@mids> before we go to the question round.. any other items we should discuss?
+01:08 <@mids> guess not :-)
+01:08 <@mids> I like it when everybody agrees :)
+01:08 <@mids> .
+01:08 <@mids> question from legabier: "why freenet is so slow and iip so fast?"
+01:08 <@mids> freenet is a different program, there is no technical relationship between IIP and Freenet
+01:08 <@mids> Freenet is completely decentralized.. IIP isn't (yet)
+01:08 <@nop> haha
+01:09 <@mids> Freenet is intended for file transfer, while IRC over IIP uses short lines
+01:09 <@nop> just because freenet is decentralized
+01:09 <@nop> is not the reason why IIP is fast
+01:09 <@mids> well, enlighten us, o master yoda :)
+01:10 <@nop> differences
+01:10 <@nop> freenet == high volume, low speed, static (archived) content
+01:10 <@nop> iip == low volume, high speed, dynamic content
+01:10 <@nop> different concepts all together, centralized or decentralized, IIP will remain fast
+01:11  * mids hopes that too
+01:11  * nop knows that
+01:11 <@mids> ok
+01:11 <@mids> does that answer your question legabier ? 
+01:12 < legabier> yes merci :)
+01:13  * mids aims the spotlight in the audience.. searching for the next question and/or comment
+01:13 < athena> why are there so few public relays (besides the ones nop runs and mids', i see only 2 or 3 others usually)?  do we have no volunteers or does the uptime checker reject a lot of them?
+01:13 < Sheige> I got 8 of them.... I guess
+01:14 < Sheige> (still a few)
+01:14 < athena> how many is that if you don't count mids' and nop's?
+01:14 <@mids> 5
+01:14 <@mids> source: http://invisiblenet.net/iip/crypto/node.ref
+01:15 < athena> hmmm, ok... guess i need to pull down a new one... still, 20 or so public nodes would be nice :)
+01:15 <@mids> I _think_ that the uptime checker is a bit too strict
+01:16 <@mids> codeshark had to pause it some time ago when the net was down
+01:16 <@mids> otherwise it would kick all relays out
+01:17 <@nop> the strict checking is a good thing
+01:17 <@nop> you'd have more problems if you had a lot of relays not working
+01:17 <@nop> it's better to have lower number with solid relay connection
+01:17 <@mids> nop: well.. but the reannounces dont seem to work
+01:17 <@nop> than a bunch of crappy ones
+01:17 <@nop> yes they do
+01:17 <@mids> hm
+01:17 <@nop> it just takes time
+01:17 <@nop> plus if you're a relay you won't see your route
+01:17 <@mids> then why do we only have 7 :)
+01:17 <@nop> because the stability of the relays
+01:18 <@nop> it may take a few more days for them to show up
+01:20 <@nop> talk to codeshark about this
+01:20 <@nop> he would have more detail
+01:20 <@nop> I will test it with him
+01:20 <@mids> ok
+01:21 <@mids> I think that I have somehow too many nodes connecting to my relay
+01:21 <@mids> but maybe there are a lot more users then we know about :)
+01:21 < athena> how many connections do you have?
+01:22 <@mids> I dont know if I should tell that
+01:22  * mids does some back channel talking
+01:22 < athena> could be that you're the best reachable relay
+01:22 <@mids> heh, I wouldnt say that with the recent lack of stability
+01:22 < athena> i often find that i can't connect through half of the hosts in node.ref
+01:23 < athena> and when you start with 7 that's not a whole lot of reliable relays
+01:23 <@nop> well, most usually are that are on
+01:23 < athena> just relating my experience...
+01:24 <@nop> maybe it's recent
+01:25 <@mids> it would be interesting to measure uptime...
+01:25 <@mids> but...
+01:25 < athena> you'd have to measure it from topologically diverse sites
+01:27 <@mids> nop: would you be against that?
+01:27 <@mids> if this whole thing wasn't about anonymity, I would love to see a lot of statistics :)
+01:27 <@nop> umm, if it exposes attacking info, yes
+01:28 <@nop> maybe we'll set up a non-anonymous weary system later and take stats
+01:28 < athena> i would say any publicly available stats SHOULD be published
+01:28 <@nop> especially as it gets bigger
+01:28 < athena> rely on the security of IIP, not on keeping info secret
+01:28 <@nop> well athena, if anyone was taking stats, they should be published
+01:28 <@nop> but no one is so far
+01:28 <@nop> anyone who is please publish your findings
+01:28 <@nop> ;)
+01:29 < athena> maybe i will :p
+01:29 <@mids> well.. I'll try to collect stats in a 'fair' way
+01:29 <@mids> without abusing my public node-powers
+01:29 <@mids> what I can collect that way, everybody can
+01:29 < athena> that's exactly what i meant, great
+01:30 < ArdVark> why not abuse your public node power and show us what that entails too mids?
+01:30 <@mids> now if I disappear from the IIP chat system... it is because someone doesnt like me collecting the stats ;)
+01:30 <@mids> ArdVark: maybe that is the next step...
+01:30 < athena> ArdVark: lol, excellent point!  since anyway can become a public node...
+01:31 < athena> s/anyway/anyone/
+01:31 <@mids> athena: install a public relay and you do it :)
+01:31 < ArdVark> I wanna see the failures as well as the successes of this beast reported
+01:32 <@mids> would be cool to have 100 'agencies' all running a public relay to log connections, but in the meanwhile helping to boost the anonymity
+01:33 < ArdVark> on a different topic, not to end the current one, has there ever been any thought to adding wiki to invisiblnet?  or too much trouble?
+01:33 <@mids> wiki as in wikiwiki?
+01:33 < ArdVark> yes
+01:33 <@mids> those $#@&%@ infobots are already some wiki
+01:33 < athena> mids: how do you know i don't already run a public relay ;)
+01:34 < ArdVark> I love those infobots mids   ;)
+01:34 <@mids> ArdVark: I know you do
+01:34 <@mids> ArdVark: if you put a webserver 'behind' IIP.. then you could install a wiki on it
+01:35 < ArdVark> ok, that is reasonable I guess
+01:35 <@mids> but running a webserver over irc isnt too great
+01:35 < ArdVark> no I meant the website
+01:35 <@mids> oh
+01:35 <@mids> you mean on the normal website
+01:35 < ArdVark> yes
+01:36 <@mids> guess you could do that
+01:36 <@mids> otoh.. you could use a public wiki too....
+01:36 < ArdVark> ok
+01:37 <@mids> I think we shouldnt really install the wiki on sourceforge.... not now
+01:37 <@mids> since it is some work to install/tweak etc
+01:38 <@mids> but someone could run a wiki, and then IIP could point to it
+01:38 < ArdVark> fine
+01:39 <@mids> ArdVark: but maybe a public wiki for IIP (like freenet has now) is the way to go
+01:39 <@mids> .
+01:39 < ArdVark> yeah ok  
+01:41 <@mids> I am going to sleep. feel free to keep chatting here :)
+01:41 < athena> night mids
+01:49 <@mids> for those who want to play with a wiki: http://mids.student.utwente.nl/~mids/phpwiki/
+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

i2p2www/meetings/logs/10.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, September 4 2002
+=================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/100.log

@@ -0,0 +1,189 @@
+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)

i2p2www/meetings/logs/100.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, July 27, 2004
+==============================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/101.log

@@ -0,0 +1,215 @@
+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

i2p2www/meetings/logs/101.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, August 3, 2004 @ 21:00 GMT
+===========================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/102.log

@@ -0,0 +1,114 @@
+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

i2p2www/meetings/logs/102.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, August 10, 2004 @ 21:00 GMT
+============================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/103.log

@@ -0,0 +1,211 @@
+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

i2p2www/meetings/logs/103.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, August 17, 2004
+================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/104.log

@@ -0,0 +1,416 @@
+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

i2p2www/meetings/logs/104.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, August 24, 2004
+================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/105.log

@@ -0,0 +1,219 @@
+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

i2p2www/meetings/logs/105.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, August 31, 2004
+================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/106.log

@@ -0,0 +1,470 @@
+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

i2p2www/meetings/logs/106.rst

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

i2p2www/meetings/logs/107.log

@@ -0,0 +1,494 @@
+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

i2p2www/meetings/logs/107.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, September 14, 2004
+===================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/108.log

@@ -0,0 +1,34 @@
+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

i2p2www/meetings/logs/108.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, September 21, 2004
+===================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/109.log

@@ -0,0 +1,113 @@
+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

i2p2www/meetings/logs/109.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, September 28, 2004
+===================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/11.log

@@ -0,0 +1,152 @@
+--- Log opened Tue Sep 17 22:59:26 2002
+23:01 -!- mode/#iip-dev [+v logger] by mids
+23:54  * Roto waves
+23:54 <@mids> ssh, we arent started :)
+23:55 < Lorax> Heh, I am already logged.
+23:56  * Lorax waves to any SRHers.
+23:59 < Lorax> anyway, if IIP could pass psudonymous keys then SSL can be used, as it's the connection that is secure, not the conversation.  (Unless you have previously established socially satisfactory identification exchange.)
+--- Day changed Wed Sep 18 2002
+00:00 <@mids> hush
+00:01 <@mids> we start in 1 hour
+00:01 < Lorax> but we are here now.
+00:01 <@mids> but the others aint
+00:01 <@mids> its not fair to start :)
+00:01 -!- mode/#iip-dev [+m] by mids
+00:02 -!- Chocolate changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | Topic: not started
+00:03 <@Chocolate> starting in about 1 hour
+00:04 -!- mode/#iip-dev [-m] by Chocolate
+00:23 < Lorax> Why are the logs recording to a website already then?  hrm?  ;)
+00:23 <+logger> we are testing the live nsa wiretap
+00:24 < Lorax> ah, that is senseable.
+00:51 < nop> hi
+00:51 < Roto> hulloz
+00:53 < thecrypto> hello
+00:53 < nop> http://www.techtv.com/screensavers/supergeek/story/0,24330,3347481,00.html
+00:53 < nop> friend of mine
+00:54 -!- mode/#iip-dev [+o codeshark] by Trent
+00:54 < nop> just got back from a deposition
+01:00 <@mids> Tue Sep 17 23:00:09 UTC 2002
+01:00 <@mids> Welcome everybody
+01:00 <@mids> this is the 11th IIP meeting
+01:00 <@mids> maybe more, but then I lost count
+01:00 <@mids> :)
+01:00 <@mids> Agenda for now:
+01:00 <@mids> rc2 status update
+01:00 <@mids> website
+01:00 <@mids> open mic
+01:01 <@mids> .
+01:01 < Roto> .
+01:01 <@mids> nop is on the phone, but he might drop in
+01:01 <@mids> like you all know, rc2 has been 'almost there' for a long time
+01:01 <@mids> but it didnt work
+01:01 <@mids> now it does better :)
+01:01 <@mids> userx fixed some bugs with the end-end crypto
+01:02 <@mids> and with the 1.1 protocol
+01:02 <@mids> I tested it this weekend, and it works great
+01:02 <@mids> you can even do 2048 bit encryption etc
+01:02 <@mids> so, one step closer to the release
+01:02 <@mids> (heh we did say that often)
+01:02 <@mids> .
+01:03 < codeshark2> what is needed for the release? except the inform stuff?
+01:03 -!- codeshark is now known as nickthief53256
+01:03 -!- codeshark2 is now known as codeshark
+01:03 <@mids> only some minor things: fixup of the commandline help
+01:03 <@mids> manpage check
+01:04 <@mids> cant think about more
+01:04 -!- mode/#iip-dev [+o codeshark] by Trent
+01:04 <@codeshark> so, the source is ready
+01:04 <@mids> I'd say so
+01:05 <@codeshark> ok, i think we should create a build for internal testing then
+01:05 <@codeshark> .
+01:05 <@mids> ack (pending nops status)
+01:05 <@codeshark> and set up inform for the new protocol
+01:06 -!- Chocolate changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | Topic: RC2
+01:06 <@mids> more rc2?
+01:06 <@codeshark> another thing we should discuss is: version numbers
+01:06 <@codeshark> why call it rc2 ;)
+01:06 <@codeshark> .
+01:06 <@mids> release candidate
+01:07 <@codeshark> yeah sure, but we changed a lot of stuff between rc1 and rc3
+01:07 <@codeshark> rc2
+01:07 <@mids> yes we did
+01:07 <@mids> it aint proper naming this way
+01:07 <@mids> based on the changes we should be at 1.3 now
+01:08 <@codeshark> yes
+01:08 <@codeshark> we could call it 1.3 RC-2 (and then make a final 1.3 soon)
+01:08 <@mids> nah
+01:09 <@mids> I'd say continue with the numbering like we do now
+01:09 <@mids> and in the future, release more often
+01:10 <@codeshark> ack
+01:10 <@mids> .
+01:10 <@codeshark> .
+01:10 <@mids> next thing: website
+01:10 <@mids> nop reviewed most text, some stuff is reworded
+01:11 <@mids> ellison (the designer) is now making a layout for the support page
+01:11 -!- Chocolate changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | Topic: website
+01:11 <@mids> should be there in a week
+01:12 <@mids> the latest version of the site is on http://mids.student.utwente.nl/~mids/iip/www/
+01:12 <@mids> and in CVS ofcourse
+01:12 <@mids> .
+01:12 <@mids> site should be up soon too
+01:12 <@mids> .
+01:13  * mids hands the mic over to codeshark 
+01:13 <@codeshark> nothing to add ;)
+01:13 <@codeshark> .
+01:13 <@mids> yes you do
+01:13 <@codeshark> i do?
+01:13 <@mids> tell em about your work with the public nodes
+01:13 <@codeshark> about the website?
+01:13 <@codeshark> ok
+01:13 <@mids> how you rescued 2000
+01:13 <@codeshark> 23
+01:14 <@codeshark> our inform server does very strict checking on the relay nodes: our list has been reduced to about 6 nodes
+01:15 <@codeshark> i disabled one of these checks to allow nodes to be down more often
+01:15 <@codeshark> and most important:
+01:15 <@codeshark> i rescued all nodes ever added to inform and checked if they're still up
+01:16 <@codeshark> now, we have 23 nodes in our list
+01:16 <@codeshark> .
+01:16 < _42> how are nodes added to inform?
+01:16 < nop> awesom
+01:16 < nop> when you announce
+01:16 < nop> it sends a message to inform
+01:17 <@codeshark> just for the statist guys here: i added 1125 hosts from the log
+01:17 < nop> you know that's a lot of downloads ;)
+01:18 <@codeshark> about 300 of them were valid (dns resolves...) and unique hosts
+01:18 <@codeshark> .
+01:18 <@mids> currently we have 9 nodes on the list... in about 5 days (after the inform testing) that will be 23 (if they keep up)
+01:18 <@mids> .
+01:19 <@codeshark> right now 22/23 are up
+01:19 <@codeshark> .
+01:19 -!- mids changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | Topic: hurray for the saviour of the public nodes
+01:20 < Roto> .
+01:20 <@mids> okay, I am out of agenda items
+01:20 < nop> rc2
+01:20 <@mids> maybe nop has something to add
+01:20 < nop> rc2 will be released with website release
+01:20 < nop> we will be spending this week thoroughly testing it from a developer's standpoint
+01:20 <@codeshark> nop: we should create an internal build of rc2 asap
+01:21 < nop> agreed
+01:21 < _42> What new features will be added to rc2?
+01:21 <@codeshark> so we can set up the network and test inform
+01:21 < nop> Perfect Forward Security
+01:21 < nop> 160 bit encryption end to end
+01:21 < nop> 1536 bit network id
+01:21 < nop> 2048 bit PFS keys
+01:21 <@codeshark> .
+01:21 < nop> and all around just general bug fixes
+01:21 < nop> I will get a changelog
+01:22 < nop> .
+01:23 <@mids> I guess its open microphone time
+01:24 <@mids> you can reread the chatlogs of this and the previous meetings on http://mids.student.utwente.nl/~mids/iip/
+01:24 <@mids> questions? (I know that Lorax had some... :)
+01:25 -!- Chocolate changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | Topic: open mic
+01:25 <@Chocolate> Lorax timed out
+01:25 <@mids> I know :)
+01:26  * Roto cheerleads
+01:26 <@Chocolate> I'd like to raise the issue of saner version numbers
+01:27 <@Chocolate> the feature changes from rc1 to rc2 where realy a minor version increment, not updates to a beta release
+01:30 <@mids> the updates got out of hand
+01:30 <@mids> for the common good.. but that is no excuse :)
+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

i2p2www/meetings/logs/11.rst

@@ -0,0 +1,9 @@
+I2P dev meeting, September 18, 2002
+===================================
+
+(Courtesy of the wayback machine http://www.archive.org/)
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/110.log

@@ -0,0 +1,180 @@
+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

i2p2www/meetings/logs/110.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, October 5, 2004
+================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/111.log

@@ -0,0 +1,195 @@
+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

i2p2www/meetings/logs/111.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, October 12, 2004
+=================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/112.log

@@ -0,0 +1,268 @@
+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 %}

i2p2www/meetings/logs/112.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, October 19, 2004
+=================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/113.log

@@ -0,0 +1,267 @@
+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

i2p2www/meetings/logs/113.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, October 26, 2004
+=================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/114.log

@@ -0,0 +1,398 @@
+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

i2p2www/meetings/logs/114.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, November 2, 2004
+=================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/115.log

@@ -0,0 +1,517 @@
+13:26 < jrandom> 0) hi
+13:26 < cervantes> lets see the menu before we order :P
+13:26 < jrandom> 1) 0.4.1.4
+13:26 < jrandom> 2) Streaming lib
+13:26 < jrandom> 3) BT progress
+13:26 < jrandom> 4) addressbook.py
+13:26 < jrandom> 5) ???
+13:26 < jrandom> 0) hi
+13:27  * jrandom waves
+13:27 < Ragnarok> hi
+13:27  * cervantes waves
+13:27 < jrandom> status notes up @ http://dev.i2p.net/pipermail/i2p/2004-November/000485.html
+13:27 < keysersoze> hi
+13:27 <+polecat> 5) can be DHTs, like that bamboo thing?
+13:27 < jrandom> (yeah, i'm late)
+13:27 < jrandom> cool polecat 
+13:27  * polecat nips at fingers again!
+13:27 < jrandom> ok, jumping into 1) 0.4.1.4
+13:28 <+Ch0Hag> 0.4.1.4 seems to die more than it should
+13:28 <+Ch0Hag> like - at all
+13:28 < jrandom> die?
+13:28 <+Ch0Hag> Though there's a chance that's kaffe's fault.
+13:28 < jrandom> drop your irc connection, or restart the router?
+13:28 < jrandom> ah, you're on kaffe?
+13:29 <+Ch0Hag> the router
+13:29 <+Ch0Hag> I am.
+13:29 <+Ch0Hag> Someone has to be :)
+13:29 < jrandom> on kaffe i've had to double the defaul mem usage (give 'er a -mx128m on startup)
+13:29 <+polecat> GAH!  No wonder!  I had hawk on ignore.
+13:29 < jrandom> well, we've got at least 3 people on kaffe these days
+13:30 < jrandom> other than that, though, how is 0.4.1.4 going for y'all?
+13:30  * polecat is on kaffe... doesn't know of a better JVM at the moment.
+13:30 < jrandom> early reports were good, but i havent heard much lately
+13:30 <+Ch0Hag> I had 64, shall try 128
+13:30 < Ragnarok> seems good
+13:30 < keysersoze> jrandom: No major problems here
+13:30 <@duck> latest major irc outage was mine
+13:30 <+Ch0Hag> And yes, much of it was OOMing
+13:31 <@duck> otherwise I think it is a bit unstable (since my bw enabling), but I dont have proof
+13:31 < jrandom> the throttling on your machine is a bit of a choke point, as e.g. each message you receive is something like 20+ messages that have to be sent out
+13:32 <@duck> ah
+13:32 < jrandom> but i agree, irc has been bumpy 
+13:32 < cervantes> 0.4.1.3 has always been rock solid on my ibm jvm, so I've avoided upgrading at this stage
+13:32 < cervantes> (22 days uptime)
+13:32 < jrandom> nice cervantes 
+13:32 < jrandom> duck: [insert comment describing hopes for new streaming lib here]
+13:33 < cervantes> baffled's irc server has been a little less bumpy
+13:33 < jrandom> word, thats a good metric
+13:33 < keysersoze> cervantes:  What version does he run? (Do you know?)
+13:33 < ant> <dm> will streaming lib have an effect on IRC, or are the messages too small anyway?
+13:33 <@duck> I have been a good duck this week, so I'll up the limit a bit
+13:33 < jrandom> lemmie check keysersoze 
+13:33 < jrandom> :)
+13:33 <+polecat> I've got 11 hours uptime.  ;.;
+13:34 < jrandom> keysersoze: 0.4.1.4
+13:34 < keysersoze> jrandom: ;) But one could ask him here when he's around
+13:34 < keysersoze> ok
+13:34 < jrandom> dm: the new streaming lib will improve resiliance and address failures, but obviously won't improve irc throughput
+13:34 < jrandom> (router versions are published in the netDb, and i know which routers are his)
+13:34 < ant> <dm> that's good
+13:35 < jrandom> ok, do we have anythingelse for 0.4.1.4?
+13:35 < jrandom> if not, swinging briefly over to 2) streaming lib progress
+13:36 < keysersoze> no
+13:36 < jrandom> as mentioned in the notes, more news when its available :)
+13:36 <+polecat> What would we be able to do with the streaming lib that we would not be able to do before it exists?
+13:36 < Ragnarok> download large files quickly
+13:36 < Ragnarok> and DOS the network :)
+13:36 < jrandom> polecat: transfer arbitrarily large files, transfer at > 4KBps
+13:37 <+Ch0Hag> and/or reliably?
+13:37 < jrandom> Ragnarok: *not* dos'ing the network is what i'm working on now ;)
+13:37 <+protokol> i've noticed over time that if i lose a connection on eepIRC, the reconnects always fail, but if i stop it for a few minutes it connects just fine
+13:37 <+polecat> It would increase the transfer rate?  o.O
+13:37 < jrandom> polecat: yes.  the current streaming lib uses a fixed 1 packet window size - waiting for an ack before sending the next message
+13:37  * polecat nods to protokol, seems so.
+13:38 < ant> <dm> The streaming lib will allow a new class of TCP-based applications to be usable on I2P. 
+13:38 < Ragnarok> jrandom: ah, good.  I've been a little concerned about that :)
+13:38 < ant> <dm> That's the marketing version.
+13:38 < jrandom> let me just say that throughput looks promising with the new lib.
+13:39 < jrandom> heh dm
+13:39 < keysersoze> jrandom: Like the extension to normal TCP, where the sending machine will keep sending even if it hasn't receivved an ACK yet, up to a certain number?
+13:39 <+polecat> jrandom: Ah, I see how that could be compromising...
+13:39 < jrandom> right keysersoze, up to a (sliding) window size
+13:39 < jrandom> (doing all that congestion control / avoidance stuff) [/arm waving]
+13:40 <+polecat> I also see how it might have congestion problems.  If many packets are sent after a connection is dropped.
+13:40 < cervantes> will be interesting to see some benchmarks comparisions for i2p BT over the new streaming lib and the old not-so-streaming lib
+13:40 < jrandom> aye cervantes 
+13:41 < jrandom> polecat: thats the biggest danger, preventing a network flood, which is why we're deploying cautiously
+13:41 < ant> <dm> I have a bug to report. Someone remind me when we hit 5.
+13:41 < cervantes> jrandom: from an application point of view, how transparent will the switch over be?
+13:42 < keysersoze> polecat: Do the current plans implement a "slow-start" idea, where the window will be 1 first, and then cautiously increased to 2, and ONLY if that works well, to 3, etc. Up to a certain maximum?
+13:42 <+polecat> Does 0.4.1.4 use the streaming lib, or has it not yet been deployed?
+13:42 < jrandom> cervantes when 0.4.2 is out, no code changes.  you can even use the streaming lib now if you want, if you specify a magic flag in the environment :)
+13:42 < cervantes> polecat: that will be with us on 0.4.2
+13:42 < ant> * dm everyone rushes towards jrandom.
+13:42 < jrandom> its with you now - see streaming.jar
+13:42 < jrandom> but disabled by default
+13:42 < ant> <dm> "flag! flag! flag!"
+13:43 < keysersoze> jrandom: Ow come on, spoil us and tell which env var ;)
+13:43 < jrandom> however, the streaming lib is *NOT BACKWARDS COMPATIBLE*
+13:43 < jrandom> aka you can't use IRC with it
+13:43 < cervantes> I have an early .1.3 remember ;-)
+13:43 < jrandom> unless duck runs a seperate newStreamingLib destination
+13:43 <+polecat> Yeah... probably best to switch in sync then, not individually.
+13:43 < jrandom> yup
+13:43 <+Ch0Hag> I think this flag is one of those "if you can't find it, you don't need it" ones.
+13:43 < ant> <dm> duck: for the love of god, do as you're told!!!
+13:43 <+Ch0Hag> Like most of GCCs...
+13:43 < jrandom> right Ch0Hag :)
+13:44 < jrandom> dm: still some other things to be tested
+13:44 < jrandom> e.g. this morning mule was helping out test with FUQID
+13:44 < keysersoze> jrandom: Does that influence any of the hosts.txt keys for existing I2P destinations?
+13:44 < mule> missed the meeting. end of daylight savings :(.
+13:44 < jrandom> (and FUQID does eeevil things :)
+13:45 < jrandom> heya mule, me too :)  you're just in time
+13:45 < ant> <dm> mule: you haven't missed section 5) ?????
+13:45 <+Ch0Hag> Oh speaking of fuqid, is there news on stasher?
+13:45 < ant> <dm> for all you know, ???? might be: GOTO 1
+13:45 < jrandom> keysersoze: no, the streaming lib isn't involved in that part of things
+13:45 <+Ch0Hag> Or is  that a big enough topic to wait until 5?
+13:45 < jrandom> Ch0Hag: no one has heard anything from aum since september, and no one else is doing anything on stasher.
+13:46 < jrandom> (but there is other DHT stuff to discuss in 5)??? i hear)
+13:46 <+Ch0Hag> Oh.
+13:46 <+Ch0Hag> Bummer.
+13:46 <+Ch0Hag> The freenet devs didn't have their competition ... removed did they?
+13:46 <+Ch0Hag> :)
+13:46 < jrandom> heh
+13:47 <+polecat> The first application of assassination politics.   x3
+13:47 <+Ch0Hag> Anyway I have nothing else, so I shan't butt in again until 5
+13:47 < jrandom> ok, there's lots going on in the streaming lib, but discussion will have to wait for later
+13:47 < jrandom> unless there's somethingelse, we can move to 3) BT progress
+13:47 < cervantes> </evasion>
+13:48 < ant> <dm> Doesn't everyone wish jrandom adopted the toad deployment process?
+13:48 < ant> <dm> Build 3435: streaming lib attempt
+13:48 < jrandom> duck: ping?
+13:48 < ant> <dm> Build 3436: streaming lib attempt 2
+13:48 <@duck> pong
+13:48 < ant> <dm> Build 3436: streaming lib attempt 3
+13:48 < jrandom> be nice
+13:48  * duck takes the mike
+13:48 < Ragnarok> no, no we don't
+13:48 <@duck> dinoman, Ragnarok and me have been working on the BT client.
+13:48 <@duck> - BT protocol analysed and changes specified on http://duck.i2p/i2p-bt/txt/i2p-bt_protocol.txt
+13:48 <@duck> - dino modified phpbt, info at http://duck.i2p/i2p-bt/txt/tracker.txt
+13:48 <@duck> dino got the client to talk with the tracker, R and me have improved it a bit.
+13:48 <@duck> the whole tracker <-> client stuff worked
+13:48 <@duck> but we got stuck at the python sam library...
+13:49 <@duck> Connelly has been helping, but also busy
+13:49 <@duck> and aum is missing
+13:49 <+polecat> I'm still stunned BT can work at all on i2p...
+13:49 <@duck> so I threw out pysam, reimplemented BT's RawServer.py and now it kinda works.
+13:49 < jrandom> (w00t!)
+13:49 <@duck> hot news: channel #i2p-bt (especially topic with latest release info)
+13:49 <@duck> now I am working at adding a lot of logging support, to catch some little flaws
+13:50 < Ragnarok> it's much nicer than the original RawServer.py
+13:50 < peer> duck: so is it ready for beta testing?
+13:50 <@duck> (for example during the EndGame it has to timeout and retry to get the last bits)
+13:50 <@duck> peer: yup
+13:50 <@duck> a little point of discussion:
+13:51 <@duck> so far it is python 2.2 (and up) compatible
+13:51 <@duck> (seems to be the same for bittorrent itself)
+13:51 <@duck> the logging stuff needs 2.3 though...
+13:51 < cervantes> yus indeed
+13:51 <@duck> how bad do you think that is?
+13:51 < jrandom> my freebsd and linux boxen have 2.3
+13:51 < ant> <dm> bad?
+13:52 < jrandom> (though they were installed within the last year)
+13:52 < Ragnarok> are there any major distros still shipping 2.2?
+13:52 <@duck> debian-stable still seems to ship 2.2, last time I checked
+13:52 < jrandom> ah, i'm on debian unstable
+13:52 <@duck> but then again that is hardly a surprise
+13:52 <+Ch0Hag> Debian ships 2.3, 2.2, 2.1 and possibly 2.0
+13:52 <+Ch0Hag> Together.
+13:52 < Ragnarok> except Debian stable, I think...
+13:53 <+Ch0Hag> That's what I'm unsure about.
+13:53 < jrandom> it'd be nice to have 2.2 support - are there no good logging libs for it?
+13:53 < Ragnarok> silly debian
+13:53 <@duck> jrandom: you could bundle the 2.3 lib
+13:54 < Ragnarok> can logging simply be made optional?
+13:54 <@duck> I guess
+13:55 < jrandom> well, its really a coder-productivity-tool, so whatever works best for the people coding
+13:55 < ant> <dm> we can worry about this when I2P + BT becomes popular.
+13:55 < keysersoze> For whom is this logging necessary? Not for the end-user, I guess, so when deploying, it shouldn't matter that logging isn't possible on some platforms, no?
+13:55 < ant> <dm> by then maybe 2.3 is standard
+13:55 < jrandom> 2.2 support would be nice, but i dont think it'd be that bad if 2.3 were required
+13:55 < cervantes> duck: so the tracker's peer announce list can be made to spew out i2p destinations instead of machine ips?
+13:56 <@duck> ok, we'll try to abstract the logging lib, with 2.2 use stdout
+13:56 <@duck> cervantes: http://duck.i2p/i2p-bt/diffs/phpbt-i2p.diff
+13:56 < jrandom> keysersoze: you want logging deployed on the clients machines so that if/when bugs arise, the dev can get detailed logs
+13:56 < jrandom> word duck
+13:56 < cervantes> ta
+13:56 <+Ch0Hag> heh if anyone's still interested, Woody has python 1.5, 2.0 and 2.1
+13:56 <+Ch0Hag> :)
+13:57 <@duck> heh
+13:57 <@duck> ok, in that case I say require 2.3
+13:57 <@duck> and fuck woody
+13:57 < cervantes> think mine is tuck on 1.5 and 2.2
+13:57 < jrandom> yeah, no need to deal with 2.1
+13:57 < cervantes> (upgrade time)
+13:57 < jrandom> heh
+13:57 <+Ch0Hag> That's the opinion of most Debian users, too
+13:58 < Ragnarok> addressbook.py requires 2.3
+13:58 <@duck> there are some interesting sub projects:
+13:58 < jrandom> ah ok cool Ragnarok 
+13:58 <@duck> researching the optimal settings for i2p
+13:58 <+polecat> That little thing requires 2.3?
+13:58 < keysersoze> jrandom: I agree, but on a small net like now (~100 peers), it's not a problem to have some beta-testers upgrade to 2.2 or 2.3. And once the most blatant bugs are stamped out, the new "real" endd-users shouldn't really need logging. So what I'm saying is: The logging is no problem at this stage, so we agree ;)
+13:58 < cervantes> when I was pulling apart BT a year or so back, this machine was pushing 6mb/sec through the tracker at times...
+13:58 <+polecat> Weird... 2.2 must be practically crippled then.
+13:58 < Ragnarok> 2.3 has better urllib proxy support
+13:58 <@duck> porting the standard bt tracker too
+13:58 < cervantes> I mean the seed
+13:59 < Ragnarok> it could work on 2.2, but it'd be too much effort :)
+13:59 <+polecat> Ah that would be important, right.
+13:59 < jrandom> duck: researching the optimal settings will be tough until 0.4.2 comes out
+13:59 <@duck> right
+14:00 < jrandom> porting the tracker would be great though. do you have the tools for creating the .torrent implemented, or did you do that manually?
+14:00 <@duck> whut?
+14:00 < cervantes> the client has tons of nice tweaks for peer takeup rates, timeouts, min/max peers etc
+14:01 < cervantes> jrandom: that shouldn't need any modification I think
+14:01 < jrandom> duck: the .torrent references the i2p destination of the tracker, right?
+14:01 <@duck> right now we ship: btdownloadheadless.py + btmakemetafile.py + btshowmetainfo.py
+14:01 < jrandom> or does it reference the name?
+14:01 < cervantes> it's just a url and a bunch of sha1 hashes
+14:01 <@duck> though btmakemetafile.py and btshowmetainfo.py are not modified
+14:01 < jrandom> "a url" is the tough part :)
+14:02 <@duck> so you can use other tools
+14:02 <@duck> its http://duck.i2p/phpbt/announce.php now
+14:02 < jrandom> ok, cool
+14:02 <@duck> guess you can use http://i2p/bigbase64/announce.php
+14:02 <+protokol> are their plans for other clients to support eepTorrent? i like azureus
+14:02 <@duck> plenty
+14:02 < cervantes> jrandom: the early version I looked at did no url validation on the announce string
+14:03 < ant> <dm> what does eep stand for again?
+14:03 < cervantes> you could put anything in there
+14:03 < jrandom> hmm, worth checking to see if that works duck ( in case phpbt does stupid url rewriting, etc)
+14:03 < cervantes> dm: look in the forum glossary
+14:03 <@duck> maybe its time for an i2p-bt forum?
+14:03 < keysersoze> duck: Especially once new users, that don't have a "registration" in hosts.txt, want to host trackers, it _must_ be possible to have a base64 iin theer
+14:03 <+Ch0Hag> Eye Eye Pee?
+14:03 < jrandom> that'd be cool duck
+14:03 <@duck> (forum section on forum.i2p)
+14:04 < ant> <dm> cervantes: that was helpful!
+14:04 < cervantes> duck: yeah no probs
+14:04 <@duck> keysersoze: it will be investigated
+14:04 < jrandom> still, as is its pretty bloody cool
+14:05 < jrandom> the 4KBps per peer isn't really that much of a problem either
+14:05 < ant> <dm> what time is it? "There's a clock just two blocks down the road"
+14:05 < cervantes> moving forward oerhaps we should set up a seperate forum space so people can publish files alla suprnova
+14:05 <@duck> eeprnova
+14:05 < jrandom> cervantes: with reviews, etc :)
+14:05 < keysersoze> jrandom: Will the transition to streaminglib require large changes to the current python I2P-BT code?
+14:05 <+polecat> I sure never get more than 4KBps even on IPv4 bittorrent streams...
+14:05 < peer> would be good if there were a command line argument for setting the i2p server address, so you can run it from other machines on a network
+14:05 < jrandom> (but i think that'd be best left outside of the forum.i2p, perhaps)
+14:06 < jrandom> keysersoze: 0 changes
+14:06 <@duck> mind you that i2p-bt trackers will scale a lot worse
+14:06 <@duck> since they have to send bloaty big keys
+14:06 < Ragnarok> polecat: you must be natted
+14:06 < keysersoze> polecat: ((OT) try the firefox torrent of today ;))
+14:06 < cervantes> jrandom: yup.
+14:06 <@duck> where the normal trackers are recently modified to only send 6 bytes / peer
+14:06 < jrandom> peer: i2p server address?
+14:07 < jrandom> peer: i use the i2p-bt with my SAM bridge locally accessing a remote router
+14:07 < jrandom> oh, but it'd be nice if there were flags to set the SAM bridge location & eep proxy location in the CLI, yeah
+14:07 < peer> jrandom: yep
+14:07 < keysersoze> duck: Can we compress the host-key? (Just asking...)
+14:08 < peer> with one cli arg
+14:08 < jrandom> (rather than remodifying the code after every release :)
+14:08 <@duck> keysersoze: using binary instead of base64 will shrink it a bit
+14:08 <@duck> like 15% 
+14:08 <@duck> no worth it
+14:08 < keysersoze> duck: I agree.
+14:09 < ant> <dm> cervantes: where is this forum glossary? I don't see anything at http://forum.i2p.net/
+14:09 < Ragnarok> could hostnames be used?
+14:09 < jrandom> Ragnarok: hostnames are not globally unique
+14:09 <@duck> Ragnarok: dont want to go there
+14:09 < cervantes> dm: only shows up for reg'd users
+14:10 < ant> <dm> cervantes: oh excellent! I'll look for eep on google then!
+14:10 < Ragnarok> fair enough
+14:11 < cervantes> dm: it's a phoneme for IIP
+14:11 < cervantes> is the word on the street
+14:11 < jrandom> ok, y'all are doing tremendous work on the bt side of things, and i look forward to hearing (and using) more :)
+14:11 < ant> <dm> cervantes: not an acronym?
+14:12  * cervantes has 1/2 of a terabyte of movies and tv shows to share
+14:12 < jrandom> do we have anything else wrt i2p-bt to discuss?
+14:12 < cervantes> dm: not that I've heard
+14:12 <@duck> (dont forget #i2p-bt)
+14:12 < jrandom> yeah, #i2p-bt, finally an incentive for people to move from freenode :)
+14:12 < ant> <dm> alrighty. Thank you sir.
+14:13 <+Ch0Hag> As if this Great network wasn't incentive enough already...
+14:13 < jrandom> ok if not, shall we move on to 4) addressbook.py
+14:13 < jrandom> Ragnarok: wanna give us the run down?
+14:13 < Ragnarok> whee
+14:14 < Ragnarok> hm, ok.  addressbook.py is a first stab at a subscribable address book system.
+14:14 < Ragnarok> It's pretty ugly at the moment, but it works
+14:14 < Ragnarok> you can get it at ragnarok.i2p
+14:14 < peer> can i just make a suggestion re: naming? i think the best method would be for the links between eepsites to use base64, but let people create their own bookmark names for sites, rather than having any centralised naming system
+14:14 < Ragnarok> um...
+14:14 < Ragnarok> any questions?
+14:15 <+postman> Ragnarok: define ugly :)
+14:15 < jrandom> Ragnarok: kickass
+14:15 < ant> <dm> jrandom: not a question
+14:15 <+polecat> What were we talking about again?  @.@
+14:15 < peer> sort of like the bookmarks on the front page of the freenet web interface, but instead with urls
+14:15 < cervantes> Ragnarok: is it all command line, or is there a gui?
+14:15 < Ragnarok> read it, it's ugly :)
+14:15 < jrandom> peer: agreed, though we need author tools
+14:15 < cervantes> there weren't any screenies so I lost interest and went away ;-)
+14:15 < jrandom> peer: though the ?i2paddresshelper helps
+14:15 <+postman> Ragnarok: ok, thanks - i will check it out
+14:16 <+polecat> Bah, GUIs are for soccer moms!
+14:16 < Ragnarok> it's all command line.  It's designed to be run as a daemon.  It doesn't run as a daemon on windows yet, but that's my next project.
+14:16 < Ragnarok> aside from the cli tool, all interactions are through config files.
+14:17 < jrandom> perhaps the next step in the namign field is a web interface for managing the entries and subscriptions?
+14:17 < cervantes> are you basically syndicating your hosts file then?
+14:17 < Ragnarok> yes
+14:17 < cervantes> right...cool
+14:17 < Ragnarok> web interface would be great.  I'm not writing it, though :)
+14:17 < jrandom> with merges and conflict management
+14:18 <+polecat> What is the conflict management, besides yelping about it in the log?
+14:18 < jrandom> yeah, the engine itself is Good Stuff, maybe we can get someone else to jump on the web side of it :)
+14:19 < Ragnarok> none.  If you want to resolve a conflict, you do it by hand :).  Though, it is a bit easier now.
+14:19 < jrandom> polecat: yelp & never overwrite an existing entry afaik
+14:19 < jrandom> (er, what he said)
+14:19 < cervantes> it would be nice as a sidebar plugin for firefox...
+14:19 <+polecat> Yes, that's what I had thought.
+14:19 < cervantes> that's something I could work into my i2p toolbar
+14:20 < Ragnarok> user changes are never overwritten, so it's reasonably secure against attack
+14:20 < jrandom> and you should only subscribe to relatively trustworthy peers
+14:20 < Ragnarok> indeed
+14:20 < cervantes> maybe a feature to lock entries?
+14:20 < cervantes> (ie move them to userhosts)
+14:21 < Ragnarok> entries are are never modified
+14:21 <+polecat> I like the concept of a myhosts.txt file for entries you want to endorse yourself.
+14:21 < cervantes> Ragnarok: ah sorry, so you said
+14:22 < Ragnarok> myhosts.txt is a dirty hack to get around a race condition, but for some reason everyone likes it as an interface thing :)
+14:22 < jrandom> if people are interested, there are ways to get the i2ptunnel / sam / etc to read from more than just hosts.txt and userhosts.txt
+14:22 < jrandom> (but only if there's a good solid reason to do so)
+14:22 < cervantes> Ragnarok: you were meant to pretend that was intentional ;-)
+14:23  * duck suggest abstracting away from hosts.txt / userhosts.txt
+14:23 <+polecat> My perl version of addressbook.pl supports the myhosts.txt thing.
+14:23 < Ragnarok> yeah, that will be part of the big rewrite :)
+14:23  * polecat notes to duck, you'd have to modify i2ptunnel and sam to do that.
+14:23 < Ragnarok> first, I want to get feature parity on windows, though.
+14:24 < jrandom> right duck, as it would have been nice for 0.4.2 if we could flag different destinations as "oldLib" and "newLib" (etc)
+14:24 <@duck> polecat: you could write the final result to something called 'hosts.txt'
+14:24 < cervantes> ideally you want a hierachical mini-database of local addresses you can catagorise 
+14:24 <@duck> but use some other structure towards the user
+14:24 <+polecat> The final result goes to userhosts.txt
+14:24 <+polecat> And also a file called "hosts.txt" on the eepsite that is not the system hosts.txt.
+14:24 <@duck> which is confusing :)
+14:25 < Ragnarok> I like to be as confusing as possible :)
+14:25 < MrEcho> hope to have the dns done by the end of the month
+14:25 <@duck> ok, then let the name depend on the checksum of the content
+14:25 < cervantes> addressbook.txt? :)
+14:25 < Ragnarok> the published address book is just called hosts.txt, because that's what it is on dev.i2p
+14:25 <+polecat> It's possible to call Ragnarok's hosts.txt file something else.  People just have to subscribe to that other filename.
+14:26 < Ragnarok> true, it's a configuration option
+14:26 <+polecat> i.e. like going http://polecat.i2p/addressbook instead of http://polecat.i2p/hosts.txt
+14:26 < MrEcho> fyi, my dns doesnt touch the hosts file .. just like a real dns
+14:27 <+polecat> Oh yeah, there's that too.  >.<
+14:27 <@duck> my dns causes world peace
+14:27 < jrandom> MrEcho: it might be worthwhile to explore interoperability
+14:27 <+polecat> There's /etc/hosts, jrandom's hosts.txt that i2ptunnel and sam use, and now the hosts.txt published by Ragnarok.
+14:28 < Ragnarok> I don't think anything that doesn't resolve names locally will ever perform acceptably over i2p, but you're welcome to prove me wrong :) 
+14:28 < mule> hostile environment :)
+14:28 < MrEcho> i could make it update the hosts text, but i was hoping to add something in other code
+14:28 < jrandom> there is some code in cvs (under apps/myi2p) for loading/storing address book entries with the data posted to that feb email, if anyone is interested ;)
+14:29 <+polecat> ?
+14:29 < MrEcho> already took a look jr
+14:30 < jrandom> polecat: http://forum.i2p.net/viewtopic.php?t=141#419
+14:30 <+polecat> You mean under apps/myi2p/java/src/net/i2p/myi2p
+14:30 < jrandom> well, yeah, if you want to get specific ;)
+14:30 <+polecat> More like hideously redundant.  ;3
+14:31 < jrandom> cool MrEcho, though i'm suggesting that sort of file format for other naming systems too, if people are going to consider replacing hosts.txt
+14:31 < jrandom> polecat: with good reason (and imho there's no redundancy in that pathname ;)
+14:31 < Ragnarok> cool.  I'll have a look
+14:32 < ant> <dm> at least it doesn't say internet three times in there anymore
+14:33 < jrandom> it'd have to be implemented as a net.i2p.client.naming.NamingService as well - something to load from that local db, but that shouldn't be too hard
+14:33 <+polecat> Eek!  No, no noo MX records... no CNAME... 
+14:33 < jrandom> having multiple destinations per name is a good idea though
+14:33 < ant> <janonymous2> Im partial to an address book/ dns hybrid
+14:34 < jrandom> an address book is a domain name system :)
+14:34 <+polecat> jrandom: How many times did you have to call it myi2p?  And how necessary is it to call it i2p if it's already called myi2p?  And is there any question whether or not that mess is a thing of java?
+14:34 < jrandom> polecat: not all myi2p code will be in java.
+14:34 <@duck> go back to your cave you perl troll :)
+14:34 <+polecat> I agree that it's all necessary, not blaming you jrandom, but blaming java and ant.
+14:35 < jrandom> polecat: and i2p's codebase is unique under the net.i2p namespace, as we don't control the net.myi2p namespace :)
+14:35  * polecat grunts and crouches under the bridge.
+14:35 < ant> <dm> polecat: it's called OCD
+14:35 < jrandom> heh
+14:35 < jrandom> its called software engineering ;)
+14:36 <+polecat> Yes, but why put everything in a directory structure parroting the namespace?
+14:36 <+polecat> Just specify like... in the file "This file is namespace net.i2p"
+14:36 < jrandom> but anyway, anything else on Ragnarok's kickass naming system?  :)
+14:36 <@duck> it kicks ass
+14:36 < Ragnarok> thank you :)
+14:36 <+polecat> Asseth Kickius.
+14:36 < jrandom> polecat: there are 1340 java files in i2p
+14:37 <@duck> I was _shocked_ when I wanted to visit an eepsite and the host was already propagated
+14:37 < Ragnarok> hehe
+14:37 < jrandom> :)
+14:37 <+polecat> Well, not saying it needs to be squashed all in one place.  1340 files seems an awful lot though, isn't there any redundant code in there?  o.O
+14:38 < Ragnarok> does anyone know a command to kill a windows process by pid?
+14:38 <@duck> like TCP stack reimplementations? :)
+14:38 <+polecat> Not to mention fully functional web servers.  c.c
+14:38 < jrandom> heh
+14:38 < jrandom> oh, lemmie skip the jetty code..
+14:39 < keysersoze> (91 peers on the net now!)
+14:39 < ant> <dm> ragnarok: kill
+14:39 < jrandom> ok, 389 in router/ and core/ 
+14:39 < Ragnarok> what versions does that exist on?
+14:39 <+polecat> That's still a lot for a lousy router... but considering the all and everything not too bad.
+14:39 < ant> <dm> not sure... Running XP here.
+14:39 < cervantes> Ragnarook: only if you have the support cd files installed
+14:40 < Ragnarok> ah
+14:40  * duck refocuses
+14:40 < cervantes> Ragnarok: otherwise download sysinternals pskill
+14:40 < jrandom> ok, anything else for 4) addressbook.py, or shall we move on to 5) ???
+14:41 < cervantes> Ragnarok: http://www.sysinternals.com/ntw2k/freeware/pstools.shtml
+14:41 < jrandom> ok, 5) it is
+14:41 < Ragnarok> neat, thanks :)
+14:41 < jrandom> polecat: iirc you wanted to bring up bamboo-dht?
+14:41 < MrEcho> ? meeting right now
+14:41 <+polecat> :chants: DHT DHT USA USA~/o
+14:42 <+polecat> Yes indeed.  I'm just looking something up...
+14:42 < jrandom> yes MrEcho 
+14:43 <+Ch0Hag> 5?
+14:43 < jrandom> 5) ???
+14:43 < MrEcho> heh
+14:43 <+Ch0Hag> ooh yes, I've found an irrelevant semantic bug
+14:43 < jrandom> sup Ch0Hag?
+14:43 <+polecat> There are 79 java files in bamboo source.  There are 253 files total.
+14:44 <+polecat> The entire project takes 4.6 megabytes in source and support files, before building.
+14:44 < jrandom> yikes
+14:44 <+Ch0Hag> in /netdb.jsp, 'our' information is given port first, whereas other peers are given host first
+14:44 <+Ch0Hag> On the Addresses line
+14:44 < jrandom> have  you played around with it polecat?
+14:44 < jrandom> Ch0Hag: the ordering is arbitrary
+14:45 <+Ch0Hag> And 0.4.1.4 has been up for an hour with 128MB under Kaffe
+14:45 <+polecat> I haven't had much of a chance.  I played around with circle, and got a nifty graphical representation of a PGP public key, but not bamboo yet.
+14:45 < ant> <dm> ah yes, ch0hag's insignificant bug report reminded me!
+14:45 < ant> <dm> on the config page it says "you should either use a service like dyndns or leave the hostname blank. If you leave it blank, your router will autodetect the 'correct' IP address by asking a peer"
+14:45 <+Ch0Hag> It seems to be host/port on all of them
+14:45 < MrEcho> Uptime: 54h Memory: 23,506KB
+14:45 <+Ch0Hag> But hey
+14:45 <+Ch0Hag> It's not like it really matters.
+14:46 < ant> <dm> which is great for me, since I have a dynamic IP address and have been waiting for this feature for some time, but when I blank and hit save, it automatically fills the box again with an (incorrect) IP
+14:46 < cervantes> polecat: do you have a url?
+14:46 < ant> <dm> Cheers!
+14:47 < jrandom> hmm dm, it doesnt honor you setting it to empty?  
+14:47 < jrandom> thats definitely a substantial bug
+14:47 <+polecat> Yes, moment please.
+14:47 < Ragnarok> it would be nice if it only recommended filling in the box if you have a real, static hostname.  Or if the box wasn't there...
+14:47 < jrandom> Ch0Hag: kaffe typically keeps a steady size
+14:47 <+polecat> http://bamboo-dht.org/
+14:48 < jrandom> Ragnarok: i'm considering removing that box altogether, leaving it for the hackers to add on /configadvanced.jsp
+14:48 < ant> <dm> I only care because the instruction paragraph makes me feel like na idiot when I can't get it to blank ;)
+14:48 < cervantes> polecat: ta
+14:48 <+Ch0Hag> dm: It's clearly an intelligence test.
+14:48 <+Ch0Hag> If you can make it stay blank, you pass.
+14:48 <+polecat> I also notice bamboo seems to compile with jikes and the kaffe jar in approximately 30 seconds.
+14:48 <+polecat> Uses some weird variables though, JAVAC and JAVAHOME instead of JAVA_HOME
+14:49 < Ragnarok> jr: I think that's a great idea.  At this point, it's a bit like a newbie trap.
+14:50 < cervantes> dm: do you click the save button, or hit enter?
+14:50 < ant> <dm> click save
+14:50 < ant> <dm>     * Updated bandwidth limits
+14:50 < ant> <dm>     * Configuration saved successfully
+14:50 <@duck> polecat: do you plan to take a closer look at it?
+14:51 <+polecat> I do indeed.  bamboo seems like the best candidate for porting over i2p, and the most "together" DHT project I see out there.
+14:52 <+polecat> The important thing is whether it "works" or not of course.
+14:52 < jrandom> bah, who needs functionality, its all about buzzword compatability!
+14:53 < jrandom> please keep us updated on how it goes
+14:53 < jrandom> (as i agree, the project does look promising)
+14:53 <@duck> probably most important is what it offers for transport level modifications
+14:54 < ant> <janonymous2> Whats the shtick on bamboo?
+14:54 < jrandom> aye, whether it requires NIO channels or uses plain sockets
+14:54 < cervantes> heh... bamboo news: "5 Aug Bamboo Now 100% Pure Java...uses Berkely DB Java Edition"   "4 Nov Bamboo No Longer 100% Pure Java...BDB Java sucked..back to C""
+14:54 < jrandom> (though we /could/ write NIO channels for i2psocket, it'd take some work)
+14:54 <+polecat> jrandom: Go back to your cathedral, java gargoyle!  X3
+14:54 <+polecat> Indeed.  If it requires TCP or UDP, or worse... DNS, then we might be hosed.
+14:54 <+polecat> NIO/
+14:54 <+polecat> NIO?
+14:55 <+polecat> All I know is ni'o means change the subject in lojban.
+14:55 < jrandom> NIO is a New I/O library in java, added in 1.4
+14:55 <+polecat> I see.  Even plain sockets though, doesn't SAM have analog objects for sockets, and analog read() and write() functions?
+14:55 < jrandom> yes
+14:56 < jrandom> if they use plain sockets, its easy as shit
+14:56 < jrandom> (...whatever that means)
+14:56 < ant> <janonymous2> Whats bamboo?
+14:56 < jrandom> bamboo-dht.org
+14:57 < cervantes> what were the problems with pysam btw?
+14:57  * polecat nods.
+14:58 <@duck> cervantes: sending / receiving data
+14:58 < cervantes> duck: oh is that all? :)
+14:58 < ant> * janonymous2 /me coweres on his inadequate phone
+14:58 <@duck> and making / detecting connections
+14:58 <+Nightblade> it didn't send?
+14:59 < Ragnarok> oy
+14:59 <@duck> Nightblade: it probably did something
+14:59 <+Nightblade> does it work at all?
+15:00 < cervantes> duck: any thoughts on i2p-bt forum section naming?
+15:00 < cervantes> d'you want you're own top level, with some subs?
+15:01 < Ragnarok> hm, I've got to hit the road.  Have a good rest-of-meeting :)
+15:01 < jrandom> Nightblade: aum was using it, so i'm sure it worked
+15:01 < jrandom> l8r Ragnarok 
+15:01 < cervantes> you're = your
+15:01 < cervantes> cya ragnarok
+15:02 < ant> <janonymous2> Status on bt?
+15:02 < jrandom> janonymous: see the meeting logs (once they come out)
+15:03 < jrandom> speaking of which, is there anything else people would like to bring up in the meeting?
+15:03 < ant> <janonymous2> Oh, my bad
+15:04  * cervantes hands jr the egold plated baffer
+15:04  * jrandom winds up
+15:04 < jrandom> ...
+15:04 < jrandom> ...
+15:04  * jrandom *baf*s the meeting closed

i2p2www/meetings/logs/115.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, November 9, 2004
+=================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/116.log

@@ -0,0 +1,177 @@
+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

i2p2www/meetings/logs/116.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, November 16, 2004
+==================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/117.log

@@ -0,0 +1,64 @@
+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

i2p2www/meetings/logs/117.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, November 23, 2004
+==================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/118.log

@@ -0,0 +1,318 @@
+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

i2p2www/meetings/logs/118.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, November 30, 2004
+==================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/119.log

@@ -0,0 +1,168 @@
+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

i2p2www/meetings/logs/119.rst

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

i2p2www/meetings/logs/12.log

@@ -0,0 +1,610 @@
+--- 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]
+00:57 [@mids] [ Dag] [ logger] [ nemesis] [ nop] [ Zwolly] 
+00:57 -!- Irssi: #iip-dev: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal]
+00:57 -!- Irssi: Join to #iip-dev was synced in 1 secs
+00:58 -!- mode/#iip-dev [+v logger] by mids
+01:00 <@mids> Tue Sep 24 23:00:38 UTC 2002
+01:00 <@mids> welcome et all
+01:00 <@mids> the 12th meeting just started 
+01:01 <@mids> agenda:
+01:01 <@mids> 1) website
+01:01 <@mids> 2) nop's messages
+01:01 <@mids> 3) question round
+01:01 <@mids> website:
+01:01 <@mids> new invisibleNET site online - http://www.invisiblenet.net/ - new IIP site online - http://www.invisiblenet.net/iip/
+01:02 <@mids> for those who just joined:
+01:02 <@mids> new invisibleNET site online - http://www.invisiblenet.net/ - new IIP site online - http://www.invisiblenet.net/iip/
+01:02 <@mids> geeh
+01:02 <@mids> I keep busy
+01:02 < nop> ok
+01:02 < nop> pause a sec
+01:02 <@mids> for those who just joined:
+01:02 <@mids> hehe
+01:02 < nop> just add it to topic
+01:03 < nop> ok
+01:03 < nop> go
+01:03 < nop> ;(
+01:03 -!- mids changed the topic of #iip-dev to: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/ | new invisibleNET site online - http://www.invisiblenet.net/ - new IIP site online - http://www.invisiblenet.net/iip/
+01:03 < nop> ;)
+01:03 <@mids> .
+01:04 -!- mode/#iip-dev [+o nop] by mids
+01:05 <@mids> any questions about this topic? otherwise we'll go to #2
+01:06 <@nop> ok
+01:06 <@nop> thanks to ellison
+01:07 <@nop> and the distributedcity crew
+01:07 <@nop> for helping out
+01:07 <@nop> with the website
+01:07 <@nop> we owe them a lot now ;)
+01:07 <@nop> ok
+01:07 <@nop> rc2 is coming out tomorrow
+01:07 <@nop> we're just packaging it up
+01:07 <@nop> and getting it ready for release
+01:07 <@nop> new features
+01:07 <@nop> are Forward Security
+01:08 <@nop> Close Delay protocol for killed connections
+01:08 <@nop> some bug fixes
+01:08 <@nop> and upgrade features for future versions
+01:08 <@nop> I think that's about it
+01:08 <@nop> thank you all you users
+01:08 <@nop> that use IIP
+01:08 <@nop> without you
+01:08 <@nop> the project would be a waste
+01:08 <@nop> ;)
+01:09 <@nop> so thank all of you for your loyalty and support by using the software
+01:09 <@nop> I think that's it for my daily comments ;)
+01:09 <@nop> oh
+01:09 <@nop> wait
+01:09 <@nop> thank you mids
+01:09 <@nop> for assisting me with the website setup
+01:09 <@nop> and for being patient with me
+01:09 <@nop> thank you codeshark
+01:09 <@nop> for setting up the software
+01:09 <@mids> your welcome :)
+01:09 <@nop> and handling inform
+01:09 <@nop> thank you userx wherever you ar
+01:10 <@nop> are
+01:10 <@nop> for your hard work on core development
+01:10 <@nop> and putting up with my ranting ;)
+01:10 <@nop> thanks to chocolate
+01:10 <@nop> for the informity and scripts that are needed
+01:10 <@nop> thanks to cohesion even though long gone, for documentation in the past
+01:10 <@nop> umm, like to thank the academy ... j/k
+01:11 <@nop> everyone who has contributed thank you all
+01:11 <@nop> .
+01:11 <@mids> 3 hurrays for nop
+01:11 <@mids> hurray
+01:11 < Zwolly> hurray
+01:11 < thecrypto> huzzah
+01:11 <@nop> haha
+01:11 < athena> that's 2 hurrays and 1 huzzah
+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 ;) <-- no comments
+01:12 <@nop> .
+01:13 <@nop> any questions
+01:13 <@nop> suggestions
+01:13 <@nop> review
+01:13 <@nop> ideas
+01:13 <@nop> etc
+01:13 < Neo> congratulations on the new site, looks great.
+01:13 <@nop> ?
+01:13 <@nop> thnx
+01:13 <@mids> what is forward security?
+01:13 <@nop> encryption can only be decrypted at time of session
+01:13 <@nop> aka, you can't replay the messages
+01:13 <@nop> and decrypt them
+01:14 <@nop> as that key and signature doesn't exist anymore
+01:14 <@nop> and will not be useful
+01:14 <@nop> this is designed against log and replay attacks
+01:14 <@nop> .
+01:14 <@mids> thx
+01:14 < athena> will you require public proxies to support these new protocol additions? (methinks all proxies should be forced to upgrade)
+01:14 <@nop> athena
+01:14 <@nop> it's a mandatory upgrade
+01:14 <@nop> all relay holders
+01:14 <@nop> will need to upgrade
+01:15 <@nop> to rc2 relay
+01:15 <@nop> and re-announce
+01:15 < athena> ok, thanks
+01:16 < sferic> I guess I cam ein late and missed something, but do you mean that we can't log anymore?
+01:16 <@nop> no
+01:16 <@nop> you can log
+01:16 <@nop> what I'm saying
+01:16 <@nop> is
+01:16 <@nop> if you were a gov't agent
+01:16 <@nop> spying on a relay
+01:16 <@nop> and you were logging the encrypted traffic
+01:16 <@nop> you couldn't then come and seize the ircd end node
+01:16 <@nop> and use the network secret key
+01:16 <@nop> to replay the traffic
+01:16 <@nop> and decrypt it
+01:17 < sferic> Ahh, thanks
+01:17 <@nop> it eliminates the importance of the network secret key
+01:17 <@nop> it's useless
+01:17 <@nop> all it does is authenticate
+01:17 <@nop> nothing more
+01:17 <@nop> doesn't actually encrypt
+01:17 <@nop> this covers two things
+01:17 <@nop> man in the middle attack protection
+01:17 <@nop> and log and relay protection
+01:17 <@nop> aka forward security
+01:17 <@nop> ;)
+01:17 < Zwolly> is it now without central server.
+01:18 <@nop> not yet
+01:18 <@nop> that's 1.22
+01:18 <@nop> 1.2
+01:18 <@nop> correction
+01:18 <@nop> 1.2.0 to be exact
+01:18 <@nop> ;)
+01:18 <@nop> after 1.1 basically is finished
+01:18 <@mids> (I'd say that decentralization is 2.0)
+01:19 < Zwolly> how about system resources memory cpu and bandwith
+01:19 <@nop> well, 2.0 is a more perfect form of decentralization
+01:19 <@nop> 1.2 we will attempt decentralization
+01:20 < Tanthrix> how does true p2p work, you can't exactly scan IP blocks until you find someone? isn't some sort of a central server neccessary for initial connection?
+01:20 <@nop> bootstrap is needed
+01:20 <@nop> but once connected
+01:20 <@nop> you have your own peer routes
+01:20 <@nop> so we include a small node.ref
+01:20 <@nop> which connects you in
+01:20 <@nop> then from that point
+01:20 < athena> thanthrix: find some friends you trust and trade node.refs :)
+01:20 <@nop> you are dynamically updated from the network
+01:21 <@nop> yes
+01:21 <@nop> that's the idea
+01:21 <@nop> in a nice world
+01:21 <@nop> ;)
+01:21 < Tanthrix> hehehe
+01:21 <@mids> what if you dont have friends?
+01:21 <@nop> then try to trust the signature on our software ;)
+01:21 <@nop> haha
+01:21 <@nop> yeah right, digital trust is rarely possible
+01:22 < Dag> trust no one
+01:22 < Dag> heh
+01:22 < athena> awww...i'll be your friends, mids!
+01:22 <@mids> hurray
+01:22 < athena> huzzah
+01:22 < Tanthrix> and grey-eyed athena comes to the rescue..
+01:22 <@nop> hehe
+01:22 <@nop> this website kicks ass
+01:22 <@nop> far difference then the previous one
+01:23 <@mids> kinda :)
+01:23 <@nop> umm
+01:23 <@nop> yeah
+01:23 <@nop> that nice little under construction site sucked ass
+01:24 < Tanthrix> heh..the new invisiblenet site looks like a page for some web-based corporation
+01:25 <@mids> thanks... I guess :)
+01:25  * mids points at ellison ... he is the one to blame; he gets all fame
+01:25 < Tanthrix> hehehe
+01:25  * ellison hides under some eye candy in the corner
+01:26 < Zwolly> what is the gues about how stable it will be 
+01:26 <@mids> Zwolly: Trent is running on a rc2 relay for 2 days now
+01:26 <@mids> without trouble
+01:27 < Zwolly> ok.
+01:27 <@mids> trent is the irc client/service with the heaviest traffic
+01:27 <@mids> so... I think it is okay
+01:27 < Zwolly> we will see
+01:27 <@nop> the reason
+01:27 < Zwolly> is it tomorrow already? hehe
+01:28 <@nop> for the middle of the road
+01:28 <@nop> corporate looking site
+01:28 <@nop> is called steganography
+01:28 <@nop> ;)
+01:28 <@nop> our evil black hat activities
+01:28 <@nop> wouldn't be good
+01:28 <@nop> if it's obvious
+01:28 <@nop> we're evil
+01:28 <@nop> now would it
+01:29 <@nop> so we blend in with the other evil
+01:29 <@nop> and they won't notice us
+01:29 <@nop> ;)
+01:29 <@nop> honestly though
+01:29 <@nop> it's just for attracting all audiences
+01:29 <@mids> in 2 month there will be an invisibleNET sponsored golf tournament
+01:29 <@nop> hahaha
+01:30 <@nop> oh and the palladium efforts
+01:30 <@nop> we bought it out
+01:30 <@nop> ;)
+01:31 <@nop> if you've noticed
+01:31 <@nop> we own www.invisiblenet.net, www.invisiblenet.com, and www.invisiblenet.org
+01:31 <@nop> we're evil
+01:31 <@nop> ;)
+01:31 <@nop> we've monopolized the market
+01:31 <@nop> we're bastards
+01:31 < Dag> what about getting one of those signs on the highway for cleaning up the roadside?
+01:31 <@nop> yeah
+01:31 <@nop> that's in the works
+01:31 <@nop> as well as OEM'ing with Microsucks, and Intel
+01:32 <@nop> haha
+01:32 <@mids> euh
+01:32 <@mids> you okay nop? :)
+01:32 < Zwolly> ok other question what to do if there are warez channels and some big stupid country lets say america for example want this network doun can it run on its own from the european nodes
+01:32 <@nop> yeah
+01:32 <@nop> yes
+01:32 <@nop> it will be possible to do that
+01:33 <@nop> plus
+01:33 <@nop> I advise for all warez activity
+01:33 < Dag> I thought there was no /dcc 
+01:33 < Dag> in here
+01:33 <@nop> to use a !anonymous mode channel
+01:33 <@nop> doesn't mean you can't trade ftp sites
+01:33 < Dag> well
+01:33 <@nop> then for anyone monitoring
+01:33 <@nop> who is saying what
+01:33 < Dag> google trades warez ftp sites
+01:33 <@nop> is a bit more tricky
+01:33 <@nop> ;)
+01:33 <@nop> exactly
+01:33 < Dag> so does the newsgroups
+01:33 <@nop> I doubt that we're a threat to that
+01:33 < Dag> er do
+01:33 <@nop> our main concern is #pedophilia public channels
+01:34 < Dag> I did a /list one day
+01:34 <@nop> as they would be a concerned threat to the existance of IIP as a whole
+01:34 < Dag> and saw that channel in the list
+01:34 <@mids> nah
+01:34 < Dag> was a month or so ago
+01:34 <@mids> I wouldnt be too affraid about that
+01:34 <@nop> I like as little trouble as possible while were developing
+01:34 <@mids> this is pure text based
+01:34 <@nop> true
+01:34 < nemesis> k
+01:34 < nemesis> brb
+01:35  * nemesis  decides to go out and tar the way to the loung ()ŻŻŻŻ)ŻŻŻŻŻŻŻŻŻŻŻŻŻŻ)))~~~~
+01:35 < Dag> freenet has been overwhelmed with that crap
+01:35 < Dag> at least last time I used frost
+01:35 < Dag> it was a VERY high percentage of that crap on there
+01:35 < athena> comes with the territory
+01:35 < Dag> I think it would be good for people to spam freenet with random non porn images and media files
+01:36 <@nop> yeah
+01:36 <@nop> it's unfortunate
+01:36 < Dag> just to make the percentage of crap go down
+01:36 <@mids> I am using freenet for 3 or 4 years now and I have never seen any pedo crap...
+01:36 <@nop> I accidentally downloaded trash on my hardrive because of their shit
+01:36 <@nop> sickening
+01:36 <@nop> I found one
+01:36 <@mids> if you dont look for it, I dont think you will run into much
+01:36 <@nop> by accident
+01:36 <@nop> not true
+01:36 <@nop> stuff gets renamed stuf
+01:37 < Dag> mids I just had frost list all the files available
+01:37 < Dag> as there are not many
+01:37 < Dag> maybe a few hundred files max
+01:37 < Dag> its not like gnutella
+01:37 <@mids> well, if you view each of them.. you will probably run into stuff
+01:37 < Dag> I didnt download anything
+01:37 <@mids> but I have no reason to view a msc0001a.jpg
+01:38 < Dag> I just saw the listings
+01:38 < ellison> you guys seen www.bitzi.com?
+01:38 < Dag> no
+01:38 < Dag> isnt that some spyware
+01:38 < ellison> it is a database of tons of files on p2p networks
+01:38 < athena> no
+01:38 <@nop> mids
+01:38 < athena> the fingerprint mp3s
+01:38 <@nop> check iip-dev
+01:38 < ellison> you can enter a filename and size, and it'll tell you what it is
+01:38 <@nop> this can't be true
+01:38 <@nop> we have a few debian users
+01:38 <@mids> nop: iip-dev email?
+01:38 <@nop> yes
+01:38 < Dag> ellison who is funding it?
+01:39 < ellison> dag: dunno
+01:40 < Dag> ellison I would bet its the riaa
+01:40 < ellison> "Bitzi is a privately-held metadata publishing company based in San Francisco."
+01:40 < Dag> or some such org
+01:40 < Dag> ellision who pays the bills
+01:40 < Dag> follow the $$$$$
+01:40 < ellison> doubt it, I think you can use their service to differentiate between valid media files and the fake stuff uploaded by RIAA
+01:41 < ellison> the founder posted on a RIAA thread and mentioned this use of the system
+01:41 < Dag> find out who funds it
+01:41 < ellison> i brought up their site because it seems to be a good way of avoiding nasty re-named stuff
+01:41 < athena> bitzi is cool... their stuff is opensource
+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->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
+01:43  * athena controls the data
+01:43 < Dag> mallicous people can change the file slightly anyhow
+01:43 < ellison> if course there is an issue of trust, but if you don't trust anyone then it'll be difficult to take part in a service-based economy...
+01:43 < ellison> then the signature would change
+01:44 < Dag> yes
+01:44 < Dag> I am addressing your wanting to avoid known bad files
+01:44 < ellison> if lots of people use bitzi, then all it takes is one person downloading and reporting a bad file
+01:45 < Dag> I could write a gnutella server to on the fly randomly tag on some byte
+01:45 < Dag> to a file
+01:45 < ellison> and bitzi will be a more and more valuable service as the RIAA begins seeding P2P networks w/ crap...
+01:45 < Dag> and change the file sig each time
+01:45 < athena> bitzi is being integrated into limewire
+01:45 < ellison> people could go to bitzi and find out which files are the good ones, and only download those
+01:45 < Dag> I think that the riaa would find the service more usefull than not
+01:46 < Dag> they are doing the riaas job for them
+01:46 < ellison> it's also about finding the good ones - avoiding the bad ones is just 1/2 of the process
+01:46 < Dag> finding keys to stuff they own
+01:46 <@mids> hey aum 
+01:46 < aum> hi mids
+01:47 <@nop> aum
+01:47 <@nop> it's most likely
+01:47 <@nop> the dh key exchange
+01:47 <@nop> maybe handshaking with a bad or out of date node, or so
+01:47 < aum> the max-out doesn't happen when i run iip as root
+01:47 < aum> only when i run as user
+01:47 <@nop> interesting
+01:47 < athena> huh?
+01:47 <@nop> have you checked your file descriptors for users
+01:47 <@nop> how many are allowed and such?
+01:48 < aum> well, all the files are owned by the same user as is running the daemno
+01:48 < aum> it's a severe max-out when i run as user - a 1.5GHz box grinds to a halt - even the mouse can barely move
+01:49 < Zwolly> people i need to go now it was fun and will install the new IIP as soon as possible (working at 7.00)
+01:49 < aum> compliments on the new website nop
+01:49 <@nop> thnx, thank ellison
+01:50 <@nop> he did it
+01:50 <@nop> ;)
+01:50 < aum> it looks so professional that one could expect to go to the download page, and see a link saying 'download 30-day demo'
+01:50 < aum> free software websites are rarely designed so professionally
+01:50 <@mids> :)
+01:50 <@nop> nor are they documented so well either
+01:51 <@mids> nor do they have such cool irc channels
+01:51 <@nop> we have kind of put the profesionallism back into open source ;)
+01:51 <@nop> I spelled that badly
+01:51 <@nop> haha
+01:51 < aum> the word 'free' needs to appear on the front page IMO
+01:51 <@nop> Professionalism
+01:51 <@nop> it says open 
+01:51 <@nop> and available
+01:51 <@nop> etc
+01:51 < aum> the word 'open' is being used more and more with commercial software
+01:51 <@nop> well, if people don't read
+01:51 <@nop> they can't be educated
+01:52 <@nop> and they shouldn't be running IIP anyway
+01:52 < ellison> :-)
+01:53 < aum> i saw a freaky film the other night - 'fight club'
+01:53 <@nop> finally?
+01:53 <@nop> haha
+01:53 <@nop> read the book
+01:53 <@nop> it's worse
+01:53 < aum> wow!
+01:53 <@mids> night all
+01:53 < aum> good concept - taking down the credit card databases
+01:53 < aum> night mids
+01:53 < ellison> night mids
+01:54 <@nop> night mids
+01:54 <@nop> thnx again
+01:54 <@nop> for your help
+01:54 < nemesis> gn8 mids
+01:54  * aum wonders if iip can take advantage of palladium features
+01:55  * nop wonders what aum means by that
+01:55 < aum> palladium could be a huge boon for p2p
+01:55 <@nop> yes
+01:55 <@nop> did you get my ip stego app?
+01:55 < aum> palladium creates a private task space that not even root can access
+01:55 < aum> back in 5...
+01:55 <@nop> k
+02:02 <@nop> ok
+02:02 < aum> back
+02:02 <@nop> wb 
+02:03 < aum> palladium can help piracy
+02:03 < Dag> anyone here run vmware?
+02:03 <@nop> I'm not convinced that palladium will be secure against the security researchers of the world
+02:03 < aum> yes
+02:03 <@nop> I do
+02:03 <@nop> I run it 
+02:03 < aum> ditto
+02:03 < Dag> how good a sandbox is it?
+02:03 <@nop> great
+02:03 < aum> brilliant
+02:03 <@nop> I use it for my windows stuff
+02:03 < Dag> that is my only real interest for it
+02:03 <@nop> while running linux as the main one
+02:03 <@nop> oh yeah
+02:03 < Dag> is a sandbox potentia;
+02:04 <@nop> yes
+02:04 <@nop> it's great
+02:04 <@nop> easy to set up too
+02:04 < aum> beautiful thing about vmware is that you can choose to discard all disk changes
+02:04 < Dag> well
+02:04 < Dag> i imagine it leaks data to the swap
+02:04 < aum> so if you install some windows fuckware, it's easy to get rid of it without having to hunt through c:\windows and registry etc
+02:04 < Dag> well yes
+02:05 < Dag> just delete the install
+02:05 < Dag> I keep a good install file
+02:05 < Dag> that has nothing on it
+02:05 < aum> i like how vers 3 does usb
+02:06 < Dag> its an amazing little app
+02:06 < Dag> wish it was open sourced
+02:06 < Dag> I looked at some open source attemps
+02:06 < Dag> at the same thing
+02:07 < Dag> and seemed to be stagnating
+02:07 < Dag> bochs and the like
+02:07 < aum> bochs is a nightmare
+02:07 < nemesis> AS/400 are better than vmware ;p
+02:08 < Dag> plex86 was another one I think
+02:08 < Dag> I have run vmware and ran some tools like filemon and regmon
+02:08 < Dag> etc
+02:09 < Dag> and they seem to show that its a decent sandbox
+02:09 < Dag> its not writting or reading to anything unusual
+02:09 < Dag> from waht I saw
+02:09 < Dag> winternals software rules
+02:09 < Dag> sysinternals/winternals that is
+02:10 < Dag> tcpview pro is another of their tools I like
+02:10 < Dag> erd commander is another
+02:11 < Dag> I am hoping someday soon that linux/bsd can have better ntfs support
+02:12 < Dag> read only access (stable) is pretty limiting
+02:14 <@nop> I'm so excited
+02:14 <@nop> this toorcon speech might get me killed ;)
+02:14 < nemesis> hrhr
+02:14 < nemesis> nooo nooo
+02:15 < nemesis> i linke the read only
+02:15 <@nop> sorry
+02:15 <@nop> I'm all interrupting
+02:15 <@nop> ;)
+02:15 < nemesis> because i stored some files in a ntfs5.1 part
+02:15 < nemesis> ;)
+02:15 < aum> nop - you better have a fast car out the back, and deliver the speech in a ski mask
+02:16 <@nop> did you read what I'm talking about
+02:16 <@nop> www.toorcon.org
+02:16 < aum> actually, a ski mask would be a good gimmick - that, and a throat-mike wired up to a harmoniser box to change your voice
+02:16 <@nop> and no I don't care if people know who I am, it's a risk I have to take for starting IIP anyway
+02:17 <@nop> haha
+02:17 <@nop> I have a friend who's an expert in make-up and disguise
+02:17 <@nop> could do that too
+02:17 < Dag> nop is it tammy faye"?
+02:17 < Dag> katherine harris?
+02:17 < aum> room will be fulla spooks
+02:18 <@nop> http://www.toorcon.org/speakers/james.html
+02:20 <@nop> making gov't irrelevant is the underlying tone
+02:21 <@nop> I contradict the keynote speaker
+02:21 <@nop> who works for nasa
+02:23 < Dag> nasa is evil
+02:23 < Dag> richard hoagland says so
+02:23 < Dag> they are withholding proof aliens exist
+02:24 <@nop> hehe
+02:24 < Dag> they bombed the face on mars
+02:24 <@nop> aum is quiet
+02:24 <@nop> hehe
+02:24 < Dag> to cover up that it really looked like a face
+02:24 < Dag> even in high res scans
+02:25 < Dag> if it were not for nasa, we would each have our own starship cruisers
+02:25 < Dag> and vacation planets as we speak
+02:25 < Dag> hell they even wont let that backstreet boy
+02:25 < Dag> on their stupid space station
+02:25 <@nop> haha
+02:25 <@nop> nsync but yeah
+02:26 < Dag> they dont want him to see who their real masters are
+02:26 <@nop> haha
+02:26 < Dag> and I dont mean the american taxpayer
+02:26 <@nop> yep
+02:27 < Dag> the government is not run by the taxpayer
+02:27 <@nop> you know what I notice
+02:27 <@nop> every corporate position in a company
+02:27 < Dag> I think the fairest govt would be one were the number of votes you have is in line with the taxes you pay
+02:27 <@nop> is desired by a selfish person
+02:27 <@nop> right
+02:27 < Dag> maybe 1 vote for each 5k in taxes you pay
+02:28 < Dag> the government is run on theft
+02:28 < Dag> steal steal steal
+02:29 < Dag> rms is a commie too
+02:29 < Dag> did you know that
+02:29 <@nop> that's why they punish drug dealers
+02:29 <@nop> because the gov't is stealing the money they make
+02:29 <@nop> you notice
+02:29 <@nop> they always wait
+02:29 <@nop> till the dealer
+02:29 <@nop> is making big money
+02:29 <@nop> to get their bust
+02:29 <@nop> they don't care about the lowly pot dealer
+02:29 <@nop> they always like to let it continue
+02:29 <@nop> till they know
+02:29 < Dag> the us govt is the biggest drug dealer out there
+02:29 <@nop> there is serious money coming in
+02:30 <@nop> then bam
+02:30 <@nop> robbin' from the dealer
+02:30 < Dag> bo gritz says so
+02:30 < Dag> harry brown for president
+02:30 < Dag> enuf said
+02:30 <@nop> hehe
+02:30 <@nop> charlie brown for president
+02:31 < Dag> what about snoopy
+02:31 <@nop> he's cool
+02:31 <@nop> he doesn't say much
+02:31 <@nop> so yeah
+02:31 < Dag> he always seemed level headed
+02:31 < Dag> cept he hung out with that bird a little to much
+02:31 < Dag> charlie brown was easily duped
+02:32 < Dag> how many times he try to kick that damn football?
+02:33  * aum is back
+02:33 < Dag> how big is a freenet install?
+02:33 <@nop> not big, 200 megs
+02:33 <@nop> for datastore
+02:33 <@nop> ;)
+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 => bliss
+02:34 <@nop> really?
+02:34 < aum> the source-based distros are too flaky just now
+02:34 < Dag> go back to freebsd
+02:35 < Dag> er forward
+02:35 < Dag> heh
+02:35 < aum> debian 4 me - huge catalog of software, ready to urn
+02:35 < aum> s/urn/run/
+02:35 < Dag> well you running it as a server or desktop?
+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 -> mandrake -> debian -> sourcemage -> gentoo -> debian
+02:37 < Dag> you ever try knoppix?
+02:37 < aum> what's that?
+02:37 < aum> a distro?
+02:37 < Dag> is a livefilesystem linux distro
+02:37 < Dag> based off debian
+02:37 < aum> huh?
+02:37 < aum> what does 'livefilesystem' mean?
+02:37 < Dag> the whole thing runs in ram and cd
+02:38 < Dag> boot off the cd
+02:38 < Dag> and away you go
+02:39 < Dag> its pretty good about hw detection
+02:39 < Dag> runs kde and even has openoffice
+02:39 < Dag> heh
+02:39 < Dag> I dont run any linux servers anymore
+02:39 < Dag> but its fun to have around
+02:39 < aum> Dag: freeBSD?
+02:40 < Dag> free/openbsd
+02:40 < Dag> solaris
+02:40 < aum> what's the big advantage?
+02:40 < Dag> depending on HW
+02:40 < Dag> openbsd has a good security audit
+02:40 < Dag> of anything they release
+02:40 < Dag> no distro of linux even comes close
+02:41 < aum> but linux 'ploits get fixed within 24 hours
+02:41 <@nop> true
+02:41 < Dag> do you check for exploits and patch every day?
+02:41 <@nop> I do
+02:41 < Dag> well
+02:41 < Dag> come now
+02:41 < Dag> heh
+02:41 <@nop> I'm on bugtraq
+02:41 <@nop> and I sometimes post
+02:41 <@nop> so I keep my eye out
+02:42 < Dag> openbsd has had ONE remote exploit in 6 years
+02:42 <@nop> it's my daytime job
+02:42 <@nop> openBSD is very conscious
+02:42 <@nop> which is good
+02:42 <@nop> proves
+02:42 <@nop> that all it takes
+02:42 <@nop> is more conscious coders
+02:42 <@nop> and a conscious framework
+02:43 < Dag> if you install redhat without patches
+02:43 < Dag> its a guarantee you will be hacked
+02:43 < Dag> I use to work in a NOC
+02:43 < Dag> it would piss me off when other lazy coworkers would install rh 6.2 etc
+02:43 < Dag> for a client
+02:44 < Dag> and never put any patches on
+02:44 < Dag> one guy worked there 3 years and his idea of rebooting a box was to hit the power switch
+02:46 < aum> power switch? did he think it was windows?
+02:46 < nemesis> lol
+02:46  * aum sometimes sees the linux BSOD screensaver
+02:47 < Dag> there was a time like 4 years back that anyone could get a tech job
+02:47 < Dag> now people who have a brain and experience
+02:47 < Dag> cant find sh*t
+02:47 < aum> an open source advocate here in new zealand wrote to the Minister for Information Technology expressing concerns about windows security vulnerabilities - Minister wrote back saying "we don't have a security problem - we use firewalls"
+02:48 < Dag> you hear the latest with XP and their help center allowing you to delete files by visiting a url
+02:48 < Dag> heh
+02:48 < Dag> there is a story at the register uk about it
+02:49 < Dag> there is even a link to have the exploit remove the help center from your machine
+02:49 < Dag> and in doing so removes the ablity to be exploited
+02:50 < Dag> Win-XP Help Center request wipes your HD
+02:50 < Dag> http://www.theregister.co.uk/content/4/27074.html
+03:03 < nemesis> erm, sorry
+03:03 < nemesis> question
+03:03 < nemesis> can i ban an port with bind to an nic?
+04:14 < nemesis> cu@all für genau 50 mins ins bett legen dann duschen und in arbeit fahren *grummel*
+08:05 < nop> sheesh
+08:05 < nop> still here
+--- Log closed Wed Sep 25 10:20:49 2002

i2p2www/meetings/logs/12.rst

@@ -0,0 +1,9 @@
+I2P dev meeting, September 24, 2002 @ 23:00 UTC
+===============================================
+
+(Courtesy of the wayback machine http://www.archive.org/)
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/120.log

@@ -0,0 +1,484 @@
+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

i2p2www/meetings/logs/120.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, December 14, 2004
+==================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/121.log

@@ -0,0 +1,323 @@
+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

i2p2www/meetings/logs/121.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, December 21, 2004
+==================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/122.log

@@ -0,0 +1,195 @@
+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

i2p2www/meetings/logs/122.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, December 28, 2004
+==================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/123.log

@@ -0,0 +1,154 @@
+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

i2p2www/meetings/logs/123.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, January 4, 2005
+================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/124.log

@@ -0,0 +1,378 @@
+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

i2p2www/meetings/logs/124.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, January 11, 2005
+=================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/125.log

@@ -0,0 +1,278 @@
+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

i2p2www/meetings/logs/125.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, January 18, 2005
+=================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/126.log

@@ -0,0 +1,172 @@
+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

i2p2www/meetings/logs/126.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, January 25, 2005
+=================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/127.log

@@ -0,0 +1,153 @@
+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

i2p2www/meetings/logs/127.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, February 1, 2005
+=================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/128.log

@@ -0,0 +1,285 @@
+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

i2p2www/meetings/logs/128.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, February 8, 2005
+=================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/129.log

@@ -0,0 +1,247 @@
+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

i2p2www/meetings/logs/129.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, February 15, 2005
+==================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/130.log

@@ -0,0 +1,282 @@
+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

i2p2www/meetings/logs/130.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, February 22, 2005
+==================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/131.log

@@ -0,0 +1,366 @@
+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

i2p2www/meetings/logs/131.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, March 1, 2005
+==============================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/132.log

@@ -0,0 +1,359 @@
+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

i2p2www/meetings/logs/132.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, March 8, 2005
+==============================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/133.log

@@ -0,0 +1,317 @@
+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

i2p2www/meetings/logs/133.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, March 15, 2005
+===============================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/134.log

@@ -0,0 +1,171 @@
+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

i2p2www/meetings/logs/134.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, March 22, 2005
+===============================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/135.log

@@ -0,0 +1,119 @@
+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

i2p2www/meetings/logs/135.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, March 28, 2005
+===============================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/136.log

@@ -0,0 +1,97 @@
+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

i2p2www/meetings/logs/136.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, April 5, 2005
+==============================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/137.log

@@ -0,0 +1,280 @@
+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

i2p2www/meetings/logs/137.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, April 12, 2005
+===============================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/138.log

@@ -0,0 +1,100 @@
+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

i2p2www/meetings/logs/138.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, April 19, 2005
+===============================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/139.log

@@ -0,0 +1,58 @@
+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

i2p2www/meetings/logs/139.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, April 26, 2005
+===============================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/140.log

@@ -0,0 +1,193 @@
+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

i2p2www/meetings/logs/140.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, May 3, 2005
+============================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/141.log

@@ -0,0 +1,129 @@
+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

i2p2www/meetings/logs/141.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, August 2, 2005
+===============================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/142.log

@@ -0,0 +1,88 @@
+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

i2p2www/meetings/logs/142.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, August 9, 2005
+===============================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/143.log

@@ -0,0 +1,50 @@
+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

i2p2www/meetings/logs/143.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, August 16, 2005
+================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/144.log

@@ -0,0 +1,143 @@
+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

i2p2www/meetings/logs/144.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, August 23, 2005
+================================
+
+Quick recap
+-----------
+
+TODO

i2p2www/meetings/logs/145.log

@@ -0,0 +1,128 @@
+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

i2p2www/meetings/logs/145.rst

@@ -0,0 +1,7 @@
+I2P dev meeting, August 30, 2005
+================================
+
+Quick recap
+-----------
+
+TODO