kytv/I2P_Website
1
0
Fork 0
forked from I2P_Developers/i2p.www
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

merge of '815d110b12ab9f27cad1cb3511b3027c8db4d2b3'

Browse Source 
and 'be7a16368a772fa456776fb0576b5a587c6d49e7'
This commit is contained in:
str4d
2012-09-12 22:56:03 +00:00
parent 5aff8d2d9a 135ce35ac6
commit 488e647c34
516 changed files with 43829 additions and 43328 deletions
Download Patch File Download Diff File Expand all files Collapse all files

704
i2p2www/meetings/1.log Normal file
View File

@@ -0,0 +1,704 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 1{% endblock %}
{% block content %}
<h3>I2P (invisiblenet) Development Meeting 1</h3>
<div class="irclog">
Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
--- Log opened Wed May 22 02:01:22 2002
02:01 <+logger> Logging started
02:01 <@nop> ok
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
</div>
{% endblock %}

171
i2p2www/meetings/10.log Normal file
View File

@@ -0,0 +1,171 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 10{% endblock %}
{% block content %}
<h3>I2P (invisiblenet) Development Meeting 10</h3>
<div class="irclog">
Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
--- Log opened Tue Sep 03 23:55:46 2002
23:56 <@mids> test
--- Day changed Wed Sep 04 2002
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
</div>
{% endblock %}

195
i2p2www/meetings/100.log Normal file
View File

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

221
i2p2www/meetings/101.log Normal file
View File

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

120
i2p2www/meetings/102.log Normal file
View File

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

217
i2p2www/meetings/103.log Normal file
View File

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

422
i2p2www/meetings/104.log Normal file
View File

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

225
i2p2www/meetings/105.log Normal file
View File

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

476
i2p2www/meetings/106.log Normal file
View File

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

500
i2p2www/meetings/107.log Normal file
View File

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

40
i2p2www/meetings/108.log Normal file
View File

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

119
i2p2www/meetings/109.log Normal file
View File

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

161
i2p2www/meetings/11.log Normal file
View File

@@ -0,0 +1,161 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 11{% endblock %}
{% block content %}
<h3>I2P (invisiblenet) Development Meeting 11</h3>
<div class="irclog">
Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
--- Log opened Tue Sep 17 22:59:26 2002
23:01 -!- mode/#iip-dev [+v logger] by mids
23:54 * Roto waves
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
</div>
{% endblock %}

186
i2p2www/meetings/110.log Normal file
View File

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

201
i2p2www/meetings/111.log Normal file
View File

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

272
i2p2www/meetings/112.log Normal file
View File

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

273
i2p2www/meetings/113.log Normal file
View File

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

404
i2p2www/meetings/114.log Normal file
View File

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

523
i2p2www/meetings/115.log Normal file
View File

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

183
i2p2www/meetings/116.log Normal file
View File

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

70
i2p2www/meetings/117.log Normal file
View File

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

324
i2p2www/meetings/118.log Normal file
View File

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

174
i2p2www/meetings/119.log Normal file
View File

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

619
i2p2www/meetings/12.log Normal file
View File

@@ -0,0 +1,619 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 12{% endblock %}
{% block content %}
<h3>I2P (invisiblenet) Development Meeting 12</h3>
<div class="irclog">
Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
--- Log opened Wed Sep 25 00:57:27 2002
00:57 -!- Topic for #iip-dev: IIP meeting | logs: http://mids.student.utwente.nl/~mids/iip/
00:57 [Users #iip-dev]
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 ;) &lt;-- 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-&gt;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 =&gt; 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 -&gt; mandrake -&gt; debian -&gt; sourcemage -&gt; gentoo -&gt; 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
</div>
{% endblock %}

490
i2p2www/meetings/120.log Normal file
View File

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

329
i2p2www/meetings/121.log Normal file
View File

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

201
i2p2www/meetings/122.log Normal file
View File

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

160
i2p2www/meetings/123.log Normal file
View File

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

384
i2p2www/meetings/124.log Normal file
View File

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

284
i2p2www/meetings/125.log Normal file
View File

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

178
i2p2www/meetings/126.log Normal file
View File

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

159
i2p2www/meetings/127.log Normal file
View File

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

291
i2p2www/meetings/128.log Normal file
View File

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

253
i2p2www/meetings/129.log Normal file
View File

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

288
i2p2www/meetings/130.log Normal file
View File

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

372
i2p2www/meetings/131.log Normal file
View File

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

365
i2p2www/meetings/132.log Normal file
View File

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

323
i2p2www/meetings/133.log Normal file
View File

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

177
i2p2www/meetings/134.log Normal file
View File

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

125
i2p2www/meetings/135.log Normal file
View File

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

103
i2p2www/meetings/136.log Normal file
View File

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

286
i2p2www/meetings/137.log Normal file
View File

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

106
i2p2www/meetings/138.log Normal file
View File

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

64
i2p2www/meetings/139.log Normal file
View File

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

199
i2p2www/meetings/140.log Normal file
View File

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

135
i2p2www/meetings/141.log Normal file
View File

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

94
i2p2www/meetings/142.log Normal file
View File

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

56
i2p2www/meetings/143.log Normal file
View File

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

149
i2p2www/meetings/144.log Normal file
View File

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

134
i2p2www/meetings/145.log Normal file
View File

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

218
i2p2www/meetings/146.log Normal file
View File

@@ -0,0 +1,218 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 146{% endblock %}
{% block content %}<h3>I2P dev meeting, September 06, 2005</h3>
<div class="irclog">
13:04 < jrandom> 0) hi</p>
13:04 < jrandom> 1) Net status</p>
13:04 < jrandom> 2) Syndie status</p>
13:04 < jrandom> 3) susidns</p>
13:04 < jrandom> 4) ???</p>
13:04 < jrandom> 0) hi</p>
13:04 * jrandom waves</p>
13:04 <+bar> salaam aleikum</p>
13:04 < jrandom> status notes up @ http://dev.i2p.net/pipermail/i2p/2005-September/000888.html</p>
13:04 <+Ragnarok> hi</p>
13:04 * cervantes tips his hat</p>
13:04 <+fox> * adamta waves back across the Irc2p/Freenode bridge</p>
13:05 < jrandom> :) ok, movin' in to 1) net status</p>
13:05 <@cervantes> *** Disconnected</p>
13:05 < jrandom> things seem to be going reasonably well from what i can see</p>
13:05 < jrandom> heh</p>
13:06 * cervantes concurs...only one netsplit in a few days</p>
13:06 < jrandom> i know we do still have some problems when one's net con is heavily congested (causing messages to back up and fail, resulting in more elGamal and higher CPU usage)</p>
13:06 <@cervantes> and my irc connection uptime is as long as my routers'</p>
13:06 <+Ragnarok> same as usual for me. Slow, but usable, with intermittent unreliability</p>
13:07 < jrandom> nice, i have been seeing that too cervantes </p>
13:07 < jrandom> Ragnarok: unreliability with eepsites, irc, i2pbt, i2phex, mail, all of the above? with 0.6.0.5 or earlier?</p>
13:08 <+Ragnarok> mostly in the form of irc disconnects every few hours. </p>
13:08 <+Ragnarok> don't use a whole lot else, so I don't have much more information</p>
13:08 < jrandom> hmm, do you have the bw limiter set?</p>
13:08 <+Ragnarok> yeah</p>
13:08 < jrandom> (as a reminder, -1 now means 16KBps)</p>
13:09 <+Ragnarok> it's set to more than the default</p>
13:09 < jrandom> ok cool, is it hitting that limit at all, and/or is that limit appropriate for your real net capacity?</p>
13:09 <+Ragnarok> the limit is well below my real capacity, since setting it high seems to kill my wireless router</p>
13:10 < jrandom> heh ok</p>
13:10 <+Ragnarok> but my router doesn't seem to hit the limit anyway</p>
13:11 <+Ragnarok> I can try to stress test it a bit, and keep better track</p>
13:11 < jrandom> does the peak bw usage hit it though (per oldstats.jsp)? i2p is pretty bursty, and congestion on a burst might cause an irc discon</p>
13:11 < jrandom> cool, that'd be great. i can only locally test so many situations, so any reports are appreciated</p>
13:11 <+Ragnarok> which number am I looking for. oldstats is pretty dense...</p>
13:12 <+Ragnarok> s/./?/</p>
13:12 < jrandom> heh, sorry - oldstats.jsp#bw.sendBps the 60s peak (the second number on the line)</p>
13:14 <+Ragnarok> what are the units? The number seems highly improbable</p>
13:14 < jrandom> KBps, sorry</p>
13:14 < jrandom> (its improperly named)</p>
13:15 < Pseudonym> bits or bytes?</p>
13:15 < jrandom> bytes</p>
13:15 <+Ragnarok> unfortuneately, it must be wrong then</p>
13:15 <+Ragnarok> the peak number is a small fraction of the limit, and of the current usage of the router</p>
13:15 < jrandom> hmm, its pretty specific, counting sizeof(messages received)</p>
13:16 < jrandom> (though the bw limiter itself works at a lower level, counting sizeof(packets received or sent)</p>
13:16 <+Ragnarok> how bad is it if I cut & paste the line? :)</p>
13:16 < jrandom> might be safer to msg it to me </p>
13:17 <+Ragnarok> wait, I was looking at the 60 m rate. It still looks low, but at least it's higher than the current usage.</p>
13:17 <+Ragnarok> sorry</p>
13:17 <+Ragnarok> I'll /msg you more info</p>
13:17 <@cervantes> Ragnarok: we'd instantly be able to determin your name, address and credit details from the netDB</p>
13:17 < jrandom> heh</p>
13:18 < jrandom> cervantes: thats why the netDb bw publishes only the *current* rate, not the peak ;)</p>
13:18 < jrandom> (but yeah, giving out one's bw usage can be dangerous to an adversary)</p>
13:19 < jrandom> ok, anyone else have anything to bring up wrt net status?</p>
13:21 < jrandom> if not, moving on to 2) syndie status</p>
13:22 < jrandom> lots of syndie progress, as outlined in the email and on my blog. rather than repeating it here, anyone have anything to bring up on that front?</p>
13:22 <@cervantes> Officiali2pApps++</p>
13:23 <+fox> &lt;adamta&gt; I'm modifying the JSP files to use more structured/semantic markup so that it can be more flexibly styled with CSS.</p>
13:23 <+fox> &lt;adamta&gt; I don't have anything to show yet, but I'll post on the mailing list when I have something ready.</p>
13:23 <+Ragnarok> maybe a small description on what you think the common use case for syndie is might be nice. I'm still a little unsure as to what it is, aside from a blog CMS</p>
13:23 < jrandom> cool adamta - be sure to work with the latest codebase, as I went through and css'ed everything last night</p>
13:24 < jrandom> (at a rought level, that is)</p>
13:24 <+fox> &lt;adamta&gt; jrandom: Oops... I'd been working on an earlier version.</p>
13:24 <+fox> &lt;adamta&gt; I'll `cvs update` and see what's changed, then.</p>
13:24 * Ragnarok , asking for user docs. Oh the hypocrisy</p>
13:24 < jrandom> good call Ragnarok. the use case is essentially '$myI2P.getUseCases()'</p>
13:25 < jrandom> safe syndication and publication of content, rather than using eepsites</p>
13:25 < jrandom> (as eepsites don't allow safe syndication, require more skill for publication, and require high availability of the operating node)</p>
13:25 <+Ragnarok> how is it syndicated, though?</p>
13:26 < jrandom> a good intro to syndie's aims is in the post http://syndiemedia.i2p/index.jsp?blog=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=&entry=1124496000001&images=false&expand=true</p>
13:27 < jrandom> syndication, right now, is done through http with explicitly specified syndication peers (either apache archives, other syndie instances, or freesites with syndie archives)</p>
13:27 * cervantes just pulled apart the syndie css... it's sufficiently classes to do a varied amount of styling, but the markup itself isn't good for working in new themes</p>
13:27 <+Ragnarok> oh, nice. I don't think I've seen that</p>
13:27 <@cervantes> *classes=classed</p>
13:27 <@cervantes> adamta: I'd be interested in seeing what you come up with</p>
13:28 < jrandom> cervantes: i'm no css wonk, so anyone inspired to improve upon it, restructure it, or revamp how the whole css/frontend works is very much appreciated :)</p>
13:28 <@cervantes> just get rid of those damn tables :)</p>
13:28 < jrandom> heh</p>
13:30 <+fox> &lt;adamta&gt; cervantes+jrandom: Indeed. There's enough there for basic styling, like changing the colour scheme, but I'm trying to modify it to get rid of the tables and to provide enough semantic markup (nested &lt;div&gt;s for sections, header tags, and so forth, all with classes and IDs when it would be useful) so that a stylesheet can completely change the appearance to the user's liking.</p>
13:30 <@cervantes> cool</p>
13:30 < jrandom> kickass adamta!</p>
13:31 * jrandom will not touch that side of things for a bit (i've got plenty to work on in the router :)</p>
13:31 <@cervantes> on a semi related note the new routerconsole themes have been somewhat delayed by arcturus' *ahem* disappearence</p>
13:31 < jrandom> heh d'oh</p>
13:31 <@cervantes> I'm trying to pick up where he left off with some of the workflow tweaks</p>
13:32 <@cervantes> but I don't have the JSP skills to do anything radical like fix the broken tunnel config screens</p>
13:33 < jrandom> ah cool, any progress is good, and if you need help with anything in particular, i'm 'round</p>
13:33 < jrandom> adamta: one thing to keep in mind is the multiple-style thing (using the author-selected but locally hosted style) ((check my recent blog posts for more info))</p>
13:33 <@cervantes> having said that the new alternative theme is looking ok</p>
13:33 < jrandom> nice</p>
13:34 <+fox> &lt;adamta&gt; The new color scheme is definitely nicer, if that's what you're referring to (?).</p>
13:35 <@cervantes> adamta: it would be cool if the author's can select a complete style from a set of templates for their particular blog</p>
13:35 < jrandom> cervantes: do you think we should deploy those jsp/css changes arcturus bounced me before, or would you prefer to hold off until you've finished some more pieces of it?</p>
13:36 <@cervantes> jrandom: I'm not sure what he gave you</p>
13:36 <@cervantes> if you can sling them over to me I can compare...I have made additional markup changes since I last discussed things with him</p>
13:37 < jrandom> cervantes: individual blog posts can now have per-blog style applied (causing e.g. class="s_detail_addressLink ss_minimal_detail_addressLink" to be used in the html, assuming the style specified is "minimal")</p>
13:37 < jrandom> cool, i'll bounce 'em your way cervantes </p>
13:37 <@cervantes> ta</p>
13:38 < jrandom> cervantes: a per-blog theme is a bit tougher - the LJ folks had to deal with it too, and came up with the compromise saying the list containing multiple blogs uses the reader's style preferences, while the list containing just one blog's posts uses the author's style preferences</p>
13:38 < jrandom> we could publish a 'DefaultStyle: minimal' in the blog's metadata to allow the later</p>
13:39 <@cervantes> yeah that was what I was imagining</p>
13:39 <+susi23> (readers preferences should always override others)</p>
13:39 <+susi23> (but thats an opinion :)</p>
13:39 < jrandom> right, when the reader has explicit preferences</p>
13:39 <@cervantes> /ignore susi23</p>
13:39 <@cervantes> sheet it didn't work</p>
13:41 <@cervantes> if we make filter by blog more distinct form of navigation</p>
13:42 <@cervantes> such as a side list</p>
13:42 < jrandom> at the moment, the user's preferences are kind of integrated into the workflow, rather than off in a separate prefs page (e.g. a link to bookmark a blog, or ignore them, or hide/show images). perhaps when we have multiple local styles, it'd be good to have a 'view style' drop down at the top</p>
13:42 <@cervantes> then it will make style changes more pallatable</p>
13:42 < jrandom> hmm yeah ,interblog navigation is going to be interesting</p>
13:43 < jrandom> so you like how it was originally, with that list of blogs on the left hand side, rather than the drop down?</p>
13:43 < jrandom> http://syndiemedia.i2p/viewattachment.jsp?blog=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=&entry=1124769600000&attachment=0</p>
13:44 <@cervantes> &lt;bluesky&gt;well that could be a template preference perhaps?&lt;/bluesky&gt;</p>
13:44 < jrandom> hmm, i dont know if stylesheets can turn a list into a drop down, can it?</p>
13:44 <@cervantes> navigation type: dropdown|sidelist|hierarchy </p>
13:44 <@cervantes> no</p>
13:45 < jrandom> ok, yeah, that can be done in jsp & user preference though, no problem</p>
13:45 < jrandom> (hierarchy?)</p>
13:45 <+susi23> (sure, you can give the select a rows parameter)</p>
13:45 <@cervantes> but if you abstract the markup into templates then you can have multiple user preference layouts</p>
13:45 < jrandom> ah, true, as a multivalued list</p>
13:45 < jrandom> (rather than an html list of links)</p>
13:46 <@cervantes> (I was blueskying though)</p>
13:46 < jrandom> right right cervantes (though it'd be nice if we can do as much templating as possible through css, since thats easier to deploy themes for)</p>
13:46 < jrandom> ((especially with the new docs/syndie_standard.css))</p>
13:46 <@cervantes> you might want to save that until version 2 and concentrate on more important aspects</p>
13:47 <+susi23> (you could put all three variants in the html source and the users decides which divs we want to hide)</p>
13:47 <@cervantes> right, if adamta sorts out the markup then you can probably do quite dramatic variations</p>
13:47 < jrandom> aye, but i'm open for ideas for the default. if there's a better way to nav, it'd be better to deploy that</p>
13:47 < jrandom> good call susi23 </p>
13:47 <+susi23> (k, not very elegant way ;)</p>
13:47 <@cervantes> as in http://www.csszengarden.copm</p>
13:48 <@cervantes> * http://www.csszengarden.com</p>
13:48 * jrandom is glad i implemented ArchiveIndex as a separate object from Archive, so all this stuff is essentially just churning through the archive.txt textfile :)</p>
13:49 < jrandom> ok, anyone have any further questions/comments/concerns wrt syndie?</p>
13:50 < jrandom> (one thing to note is that the new petname stuff has a one-click export to the user's userhosts.txt file, dumping any i2p addresses there [but it doesn't import yet])</p>
13:50 <@cervantes> nice work</p>
13:50 < jrandom> gracias cervantes </p>
13:50 <@cervantes> you going to ever do anything on i2p core again? :)</p>
13:50 < jrandom> heh</p>
13:51 * jrandom has a pair of killer changes to the router coming up, giving us lots of capabilities</p>
13:51 < jrandom> (but more on those when they're tested and ready for deployment)</p>
13:51 <@cervantes> i2pponies.ar</p>
13:51 <@cervantes> i2ponies.war</p>
13:52 <@cervantes> hmm vnc refresh is slow tonight</p>
13:52 <+susi23> (pony wars? poor ponies...)</p>
13:52 < jrandom> heh</p>
13:52 < jrandom> ok, moving on to 3) susidns</p>
13:52 < jrandom> susi23: wanna give us a rundown?</p>
13:52 <+susi23> well</p>
13:53 <+susi23> there is not much to say... susidns is a very simple webapp giving you access to addressbook configuration and subscriptions files</p>
13:53 <+susi23> and to your "addressbooks" namely hosts.txt, userhosts.txt and (if existing) your published addressbook</p>
13:54 <+susi23> I added an introduction page and some explanations how addressbook works</p>
13:54 <+susi23> (ok, how I think addressbok works ;)</p>
13:54 < jrandom> w00t :)</p>
13:54 <+bar> userhosts.txt?</p>
13:54 <+susi23> as there've been user questions about this in the last weeks</p>
13:54 <+Ragnarok> I'll send feedback, once I try it out :)</p>
13:54 <@cervantes> cool, how ready is it?</p>
13:54 <+susi23> sure</p>
13:54 <+susi23> usable</p>
13:55 < ardvark> i use addressbook, but have no userhosts.txt, or is userhosts.txt my personal/private eepsites?</p>
13:55 < jrandom> ardvark: userhosts is for user specified custom overrides (it doesnt exist by default)</p>
13:55 <+susi23> userhosts.txt is a 2nd hosts.txt file which is read by the NamingService</p>
13:55 < ardvark> ok</p>
13:55 <+Ragnarok> userhosts.txt is the one you can edit without fear of dataloss via race conditions :)</p>
13:55 <+susi23> and yes people used this for private keys</p>
13:56 <+susi23> (which is a bit dangerous now when you activate addressbook publication)</p>
13:57 <+susi23> well, no magic here... thats all</p>
13:57 <+Ragnarok> adding a privatehosts.txt or something, which is read by the NamingService but not addressbook would be trivial</p>
13:57 <+susi23> true</p>
13:57 <@cervantes> I would like to see that ;-)</p>
13:58 * cervantes clutches his private keys ;-)</p>
13:58 < jrandom> ooh, susidns intro page is nice :)</p>
13:58 < jrandom> (cervantes/susi/ragnarok/et al: see the syndie pet name web interface too [you need to log in to see it])</p>
13:58 <+susi23> as addressbooks publication is turned off by default there is no danger for normal people</p>
13:58 < jrandom> right right</p>
13:59 <+Ragnarok> I've asked this before, but is there anything I can do to make life easier for people writing addressbook frontends?</p>
13:59 * cervantes has forgotten his login</p>
13:59 < jrandom> cervantes: you can register again ;)</p>
13:59 <+Ragnarok> so have I, probably</p>
14:00 <@cervantes> wouldn't sushidns be a better name?</p>
14:00 * cervantes ducks</p>
14:00 <+susi23> ragnarok: how about a function to interupt the sleeping thread for immediate (user triggered) subscription update?</p>
14:01 < jrandom> ooh, or a manual "fetch now" capabiliy</p>
14:01 * susi23 slaps cervantes with a large trout.</p>
14:01 <+susi23> yes, calling it dns is ridiculous here...but thats a historic name :)</p>
14:01 <@cervantes> raw trout!</p>
14:01 * cervantes grabs the soya sauce</p>
14:01 <+susi23> (pervert!)</p>
14:02 <+susi23> k, back to topic please ;)</p>
14:02 <+Ragnarok> ok, I'll look into that</p>
14:02 <+susi23> (don't drink at meetings!)</p>
14:02 * jrandom hides my drink</p>
14:03 * susi23 pings jrandom</p>
14:03 < jrandom> ok cool, thanks susi, looks v.nice</p>
14:03 < jrandom> ok, moving on to 4) ???</p>
14:03 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
14:04 <@cervantes> if anyone has been experiencing any issues with irc2p please let the admins know</p>
14:06 <@cervantes> #irc2p is the support channel</p>
14:06 <@cervantes> or post to the forum</p>
14:06 <@cervantes> jrandom: do you want a syndie forum btw? (or is that redundant)</p>
14:07 <@cervantes> susi23: you're welcome to have one too, for you plethora of i2p apps ;-)</p>
14:07 < jrandom> atm, i think we're ok without one, thanks though</p>
14:07 < jrandom> the susiworld forum</p>
14:09 < jrandom> ok, if there's nothing else</p>
14:09 * jrandom winds up</p>
14:09 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

47
i2p2www/meetings/147.log Normal file
View File

@@ -0,0 +1,47 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 147{% endblock %}
{% block content %}<h3>I2P dev meeting, September 13, 2005</h3>
<div class="irclog">
13:01 < jrandom> 0) hi</p>
13:01 < jrandom> 1) Net status</p>
13:01 < jrandom> 2) SSU introductions / NAT hole punching</p>
13:01 < jrandom> 3) Bounties</p>
13:01 < jrandom> 4) Client app directions</p>
13:01 < jrandom> 5) ???</p>
13:01 < jrandom> 0) hi</p>
13:01 * jrandom waves</p>
13:01 < jrandom> weekly status notes posted up (before the meeting!) at http://dev.i2p.net/pipermail/i2p/2005-September/000892.html</p>
13:01 < jrandom> (drop the .net if you prefer, of course)</p>
13:03 < jrandom> jumping on in to 1) Net status</p>
13:03 < jrandom> there are a few users bouncing a bit on irc, but it seems pretty good for most</p>
13:04 < jrandom> does anyone have any reports regarding other protocols to bring up, or questions/concerns regarding the net status?</p>
13:05 <@cervantes> I've found this version to be the most stable since 0.4.x</p>
13:05 <@cervantes> so top work! ;-)</p>
13:05 < jrandom> w00t</p>
13:05 < jrandom> ok, if there's nothing else on 1) net status, lets move on to 2) SSU introductions</p>
13:06 < jrandom> I don't really have much to add beyond whats in the email - anyone have any questions/comments/concerns?</p>
13:07 < jrandom> if not, i suppose we'll be hearing more when 0.6.0.6 comes out ;)</p>
13:07 < jrandom> ok, moving on to 3) bounties</p>
13:07 * cervantes battens down the hatches</p>
13:08 * cervantes wonders if people have got the hang of the new meeting time yet</p>
13:08 < jrandom> hmm, it doesn't seem like Comwiz is around at the moment. I suppose we can expect more info when its ready</p>
13:08 < jrandom> bah, bloody americans and their slow time zones</p>
13:09 <+Myo9> I though you were one, having your own bunker and all. ;)</p>
13:09 * susi23 listens to the dialog ;)</p>
13:10 < jrandom> ok, if there's nothing else on 3), we can race on through to 4) client apps directions</p>
13:11 < jrandom> lots of typing in the mail, so rather than repeat it here, anyone have any thoughts on it? </p>
13:11 < jrandom> its not just an immediate question, if/when people want to chime in on that stuff, please feel free to post to the forum or list as well</p>
13:12 <@cervantes> there's a new Application Support section in the forum, which is a good place to post about such matters</p>
13:12 < jrandom> ah good call</p>
13:13 < jrandom> also the discussion section for non-support comments, e.g. prioritization stuff</p>
13:13 < jrandom> ok, working us towards the first under-15-minute meeting in a long time...</p>
13:14 < kbi> i guess the meetings go fast when everyone is happy</p>
13:15 < jrandom> could be, and hopefully we'll get some posts on the list and the forum</p>
13:15 < jrandom> ok, moving on to 5) ???</p>
13:15 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
13:15 <@cervantes> (except their lunch)</p>
13:17 <@cervantes> there goes 15 mins</p>
13:17 * jrandom winds up</p>
13:17 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

103
i2p2www/meetings/148.log Normal file
View File

@@ -0,0 +1,103 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 148{% endblock %}
{% block content %}<h3>I2P dev meeting, September 20 @ 20:00 GMT</h3>
<div class="irclog">
16:18 < jrandom> 0) hi</p>
16:18 < jrandom> 1) 0.6.0.6</p>
16:18 < jrandom> 2) I2Phex 0.1.1.27</p>
16:18 < jrandom> 3) migration</p>
16:18 < jrandom> 4) ???</p>
16:18 < jrandom> 0) hi</p>
16:18 * jrandom waves</p>
16:18 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-September/000929.html</p>
16:18 <+postman> hello</p>
16:18 < forest> hi</p>
16:18 < jrandom> lets jump on in to 1) 0.6.0.6</p>
16:19 < jrandom> the status notes cover pretty much what i've got on my mind for 0.6.0.6. anyone have any questions/concerns/comments to bring up?</p>
16:19 <+postman> jrandom: observation:</p>
16:19 <+postman> jrandom: much higher bandwidth consumption</p>
16:20 <+postman> jrandom: all within the limits and running fine - but my routers really getting warm now</p>
16:20 * nickless_head makes similar observation</p>
16:20 < jrandom> aye, me too, i think its likely due to an increase in bt and i2phex traffic</p>
16:20 <+postman> what increase, with just 80 active torrents on the tracker? :)</p>
16:20 < jrandom> heh</p>
16:21 <+postman> but its good to see, that the network does not crumble</p>
16:21 <+postman> irc is pretty stable altho the router does 50k/s atm</p>
16:21 < jrandom> mos' def'. i'm not even logged into freenode anymore, as irc here is stable enough</p>
16:22 * postman hands the mike back</p>
16:22 < jrandom> cool, thanks. i think there's definitely still room to go for bandwidth efficiency, but it seems reasonable atm</p>
16:22 < jrandom> (hopefully the thing i'm working on will help, but more on that when its ready)</p>
16:22 < fox> &lt;mihi&gt; you should definitely distinguish between OK (Nat) and Err (Nat)...</p>
16:23 < fox> &lt;mihi&gt; or is your hole punching almighty?</p>
16:23 < jrandom> heh</p>
16:23 < jrandom> well, ERR-SymmetricNAT is and will continue to be an ERR</p>
16:23 < fox> &lt;mihi&gt; or is it impossible to check whether it was successful?</p>
16:24 < fox> &lt;mihi&gt; ok</p>
16:24 < jrandom> but ERR-Reject is due to restricted cone, while full cone nats work fine</p>
16:24 < jrandom> (since i2p uses only one source port for everyone, as long as you're on i2p you'll have a hole punched for the full cone)</p>
16:25 < jrandom> still, it is better when people forward their ports so they don't need introducers, as that lets them also become introducers themselves</p>
16:25 < fox> &lt;mihi&gt; as long as there are no nasty iptables rules (like drop UDP to 8887 from IP addresses divisable by 7 :) )</p>
16:25 < jrandom> heh</p>
16:26 < jrandom> and unfortunately, some people do have b0rked configurations like that (*cough*peerguardian*cough*)</p>
16:26 < jrandom> someone the other day was wondering why i2p didn't work, even though they had their firewall dropping packets from all .edu peers</p>
16:27 <+Ragnarok> .edu? That's pretty random</p>
16:27 < jrandom> yeah, made no sense to me, in so many ways</p>
16:27 < jrandom> but, c'est la vie</p>
16:27 * nickless_head sings: We don't need no education...</p>
16:28 < jrandom> heh</p>
16:28 < jrandom> ok, anyone else have anything on 1) 0.6.0.6?</p>
16:29 < jrandom> if not, moving on to 2) i2phex 0.1.1.27</p>
16:29 < jrandom> not much to say here beyond whats in the mail either...</p>
16:30 <+postman> jrandom: there was no positive response in the mentioned forums either :(</p>
16:31 <+postman> jrandom: i will forward your statusnotes and links - maybe the readers get the point</p>
16:31 < jrandom> postman: people are of course able to use whatever they want, but I don't recommend the binary release from legion as the source doesn't match the binary, and the launcher is entirely closed source</p>
16:32 < jrandom> now that we've got i2phex on a web accessible location, built from cvs, hopefully that will reduce people's reliance on that</p>
16:33 < jrandom> (perhaps if you want to post the irc log from #i2p-chat an hour or two ago between legion and i, that might help explain the situation to people more completely)</p>
16:34 < jrandom> ok, anyone else have anyhing on 2) i2phex, or shall we move on to 3) migration</p>
16:34 * postman has a look</p>
16:34 < jrandom> there's not much really to add for 3), its more of an fyi</p>
16:34 < jrandom> so, perhaps we can jump quickly to 4) ???</p>
16:34 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
16:35 <+Complication> Migration?</p>
16:36 < jrandom> if you didn't notice, great :)</p>
16:36 < jrandom> we moved from one colo to another</p>
16:36 < jrandom> (cvs.i2p.net, dev.i2p.net, www.i2p.net, mail.i2p.net)</p>
16:36 <+Complication> Oh, that migration. :)</p>
16:36 * Complication is simply a bit slow today</p>
16:39 <+Complication> By the way, 0.6.0.6 seems very nice... in the regard that my router didn't touch 0 participating tunnels in 54 hours.</p>
16:39 <+Complication> Not even once.</p>
16:39 < jrandom> nice</p>
16:40 < jrandom> ok, if there's nothing else people want to bring up for the meeting...</p>
16:40 * jrandom winds up</p>
16:40 <+postman> jrandom: one thing</p>
16:40 * jrandom stops winding</p>
16:40 <+postman> jrandom: you just incremented the i2phex version - what if sirup plans another release?</p>
16:40 < jrandom> postman: sirup uses the cvs</p>
16:41 <+postman> jrandom: how about giving it a an additional tag</p>
16:41 <+postman> ok, that's fine then</p>
16:41 <+postman> :)</p>
16:41 * postman is back in his cave</p>
16:41 < jrandom> (developing code outside a source control system == crazy)</p>
16:41 * Kefoo remembers how crazy it was developing inside a source control system, too</p>
16:41 <+postman> jrandom: (it did not need to be YOUR's)</p>
16:42 < jrandom> heh true enough Kefoo ;)</p>
16:42 < jrandom> heh well, yeah... his just happens to be though ;)</p>
16:43 * bar just set a new personal record of 156 concurrent udp connections (old record was 152)</p>
16:43 < jrandom> cool, yeah, i saw 173 earlier today</p>
16:44 <+bar> oh :) yeah the indtroducing is doing its thing fo' sure</p>
16:44 < Kefoo> Not to backtrack, but is i2phex supossed to try connecting on startup? I've heard both yes and no.</p>
16:44 <+bar> -d</p>
16:44 < jrandom> wikked bar</p>
16:44 < jrandom> Kefoo: afaik, no.</p>
16:44 < jrandom> but, i'm no phex dev</p>
16:45 < Kefoo> The only way I've found is to copy and paste the host keys into the program and connect to them manually</p>
16:45 < jrandom> thats what i've done Kefoo</p>
16:45 <+postman> wind ye up now, jrandom :)</p>
16:45 < Kefoo> Ok, so I'm not making it harder than it should be</p>
16:45 < Kefoo> I do that sometimes</p>
16:46 < jrandom> Kefoo: if there's something easier, i'd like to hear about it :)</p>
16:46 < jrandom> ok ok postman, you can go get your beer ;)</p>
16:46 * jrandom winds up</p>
16:46 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

258
i2p2www/meetings/149.log Normal file
View File

@@ -0,0 +1,258 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 149{% endblock %}
{% block content %}<h3>I2P dev meeting, September 27, 2005</h3>
<div class="irclog">
16:14 < jrandom> 0) hi</p>
16:14 < jrandom> 1) Net status</p>
16:14 < jrandom> 2) 0.6.1</p>
16:14 < jrandom> 3) ???</p>
16:14 < jrandom> 0) hi</p>
16:14 * jrandom waves</p>
16:14 <+Ragnarok> ok, I'll hold my further questions</p>
16:14 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2005-September/000933.html</p>
16:14 <+Ragnarok> hi :)</p>
16:15 < wiht> Hello.</p>
16:15 < jrandom> we can definitely dig into it further in 3?? if you'd prefer</p>
16:15 <+Ragnarok> cool</p>
16:15 < jrandom> ok, jumping into 1) Net status</p>
16:15 < jrandom> in general, things seem pretty solid</p>
16:16 < A123> Is the http outproxy run by just one router?</p>
16:16 < wiht> I see 307 known nodes on my router console.</p>
16:16 < A123> (I'm still a little hazy on how I2P works)</p>
16:16 < jrandom> there are two outproxies configured by default, and a few others available not configured by default</p>
16:16 < wiht> Has anyone's bandwidth been maxed out by the recent growth of the network?</p>
16:17 < jrandom> well, my bandwidth usage has grown, a steady 30-40KBps on my routers</p>
16:17 < jrandom> (to a steady 30-40, that is)</p>
16:18 < jrandom> (i'm also running a few high traffic services, like squid.i2p ;)</p>
16:19 < A123> Ever look at the logs?</p>
16:19 < jrandom> of squid? no, i have it set to not do any request logging</p>
16:20 <+Ragnarok> remember, he could be lying :)</p>
16:20 <+Ragnarok> thus, it's a stupid question to ask</p>
16:20 < jrandom> (though that could be a lie, and may work for the FBI/etc, so don't abuse it ;)</p>
16:20 < A123> I was just curious as to whether there was anything interesting in there :)</p>
16:21 <+mihi> A123: run your own outproxy :)</p>
16:21 < gloin> A123: setup a tor node.</p>
16:21 < A123> Is it easy to set up?</p>
16:21 < jrandom> not really</p>
16:21 < A123> gloin, tor is explicitly not designed for file sharing, so I have little interest in it.</p>
16:22 < jrandom> (an outproxy, that is. tor is easy to set up)</p>
16:22 < A123> Or at least, they've explicitly stated that they don't want people to use it for file sharing.</p>
16:22 < wiht> jrandom, do you still want to wait for version 1.0 before a full public announcement of the I2P project's maturity?</p>
16:23 <+mihi> A123: it is definitely harder than registering your nick with nickserv *hint* *hint*</p>
16:23 < A123> Oh yeah, I sure don't want A123 to be taken :)</p>
16:23 < wiht> If the network is doing well now, could it stand the addition of more users?</p>
16:23 < jrandom> we'll need to do some outreach before 1.0 so that we can have some testing in larger environments</p>
16:24 <+Ragnarok> maybe a preview release, or some such thing</p>
16:24 < wiht> A beta release? Sounds like a good idea.</p>
16:25 < jrandom> aye, that'll happen along side the website revamp, maybe before 0.6.2</p>
16:25 < jrandom> (or maybe @ 0.6.2)</p>
16:25 < jrandom> (website revamp being part of that critical path so we dont spend hours upon hours answering the same questions)</p>
16:25 <+Ragnarok> well, with a little more end-user polish than just another beta</p>
16:26 < A123> Is it possible for I2P-aware clients to configure tunnels themselves easily?</p>
16:26 < jrandom> yes</p>
16:26 < A123> I guess they could always do HTTP requests to the console...</p>
16:26 <+Ragnarok> the router console also need a serious revamp. It would be nice for the initial page to be more like an i2p portal, and move all the technical stuff a little farther in</p>
16:26 < jrandom> its one of the properties they send when they connect to i2p</p>
16:26 < jrandom> agreed Ragnarok</p>
16:27 < A123> Hrm. The Azureus I2P plugin could have a bit of additional friendliness, then.</p>
16:27 < A123> Or any friendliness at all.</p>
16:27 < jrandom> agreed A123 ;)</p>
16:27 < jrandom> (though they've done a great job showing the proof of work)</p>
16:28 < jrandom> there have been a lot of great suggestions on the mailing list as of late regarding usability</p>
16:28 < jrandom> many/most of which should be done prior to asking new users to try i2p out</p>
16:28 < A123> From the console: "If you can't poke a hole in your NAT or firewall to allow unsolicited UDP packets to reach the router, as detected with the Status: ERR-Reject..."</p>
16:28 < A123> Where would I see "Status: ERR-Reject"?</p>
16:29 <+Ragnarok> it's nice that we're at the point where we can worry about usability :)</p>
16:29 < jrandom> A123: on the left hand side of your router console, it says Status: OK (or Status: unknown, or something else)</p>
16:29 <+Complication> In the Status field of the router console.</p>
16:29 < jrandom> true 'nuff Ragnarok </p>
16:29 <+Complication> Hopefully you've got an OK or OK (NAT) there.</p>
16:30 < A123> Complication, ah, thanks. Is that the thing that gets updated if you click on "Check network reachability..."?</p>
16:30 < wiht> I hope that you will not have to break compatibility in future releases of I2P. Full network migration to a new version seems to have been painful in the past.</p>
16:30 <+Complication> A123: yes, it should test again when you click</p>
16:30 <+Complication> Doesn't happen instantly, though.</p>
16:30 < jrandom> eh, they're not as painful as they used to be, but yeah, it'd be good if we can avoid it wiht</p>
16:30 < A123> So I have to refresh the page?</p>
16:30 < A123> Well, no, that would do another http post...</p>
16:31 <+Complication> A123: it may take a minute to find a testing-suitable peer</p>
16:31 <+Complication> 'cause you cannot test with those whom you're already speaking to</p>
16:31 <+Complication> It could give false results.</p>
16:32 <+Complication> So, it should show up when you view the router console sometime later.</p>
16:32 <+Complication> Basically, in ideal circumstances, you shouldn not need to fire a peer test manually.</p>
16:33 <+Complication> =shouldn't need</p>
16:33 < jrandom> right, i2p now does a peer test automatically when certain events occur</p>
16:33 < jrandom> (such as when someone tells you that your IP is something other than what you think it is)</p>
16:33 < A123> I found that button completely unintuitive. I had no idea what it was updating and when, it never explicitly told me the results of the test...</p>
16:34 < A123> The page wasn't automatically refreshing (I think), I can't do a reload in the browser...</p>
16:34 < jrandom> reload should be safe</p>
16:34 < A123> Surely that fires another test?</p>
16:34 < jrandom> but yeah, the router console was designed more for technical reasons rather than usability</p>
16:34 < jrandom> A123: it has a nonce to prevent that</p>
16:34 <+Complication> That facet might benefit from a better explanation text in future</p>
16:35 < wiht> Have we skipped 2) and gone to 3) already?</p>
16:35 < jrandom> Complication: we'll probably drop it, since its unnecessary</p>
16:35 < jrandom> no, still on 1</p>
16:35 < jrandom> actually, anyone have anything else for 1) network status?</p>
16:35 < A123> Ah, indeed, after a few times it complains about the nonce.</p>
16:35 < jrandom> if not, moving on to 2) 0.6.1</p>
16:35 < A123> "nonce" to non-geeks is just going to seem like a nonsense word.</p>
16:36 < A123> :)</p>
16:36 * Complication looks at graphs</p>
16:36 <+Complication> No complaints about net status from here.</p>
16:36 < jrandom> w3wt</p>
16:37 < A123> Is there any reason that reseeding isn't automatic?</p>
16:37 < jrandom> ok, i don't really have too much to mention regarding 0.6.1 beyond whats in the mail</p>
16:37 < gloin> hmm.. shouldn't be the incoming and outoging traffic more or less symmetric?</p>
16:37 < A123> Mine seems more or less symmetric.</p>
16:37 < jrandom> A123: yes, though we may be able to do it safer</p>
16:37 <+Complication> gloin: not if one's leeching or seeding ;)</p>
16:37 <+Ragnarok> not if you're downloading stuff</p>
16:38 < A123> Total: 3.74/4.09KBps (that's in/out)</p>
16:39 < gloin> Complication: Is this a security problem? Shouldn't the 'foreign' traffic be reduced?</p>
16:39 <+Complication> gloin: depends on what the criteria are</p>
16:40 <+Complication> A person striving for utmost security clearly shouldn't be doing things which permit others to cause observable changes in their BW.</p>
16:40 < jrandom> gloin: as we move to 1.0, we will stop publishing those stats</p>
16:40 < A123> My ISP will still know them...</p>
16:40 < jrandom> but yes, defending against local traffic analysis does require you to participate in other people's tunnels</p>
16:41 <+Complication> (for a strict definition of "their BW", meaning "bandwidth use starting/ending at their node")</p>
16:41 < jrandom> (or do sufficient chaff activity. tarzan for instance has "mimics" for wasting bandwidth^W^Wdefending anonymity)</p>
16:41 < A123> Hrm.</p>
16:41 < A123> I'm on ADSL, with far more download ability than upload.</p>
16:42 <+Complication> Many are.</p>
16:42 < A123> When my download exceeds my upload, doesn't that imply that I'm downloading stuff?</p>
16:43 < wiht> No, you could also be forwarding others' traffic.</p>
16:43 <+Complication> I guess it would imply you are downloading something.</p>
16:43 < A123> Does I2P cache data?</p>
16:43 * wiht would like to be corrected if that's wrong.</p>
16:43 <+Complication> Unless you are seeding as much as you're leeching.</p>
16:43 < jrandom> i2p itself does not cache</p>
16:43 <+Complication> A123: no caching occurs to my knowledge</p>
16:43 < jrandom> though syndie, on the other hand, does. </p>
16:44 < A123> If there's no caching, then my download exceeding my upload must mean that I'm downloading something myself, right?</p>
16:44 < jrandom> if you have large amounts of inbound trafffic but no current outbound traffic, you could just be running a syndie node</p>
16:44 < jrandom> yes A123, given a small enough time frame</p>
16:45 < A123> Since I could only usefully be downloading at the speed of my upload, after network buffers fill.</p>
16:45 < jrandom> for a certain threat model, yes</p>
16:45 < A123> Hrm.</p>
16:45 < jrandom> (local passive attacker with sufficient resources, or a targetted local attacker, etc)</p>
16:46 <+Complication> You could download faster, but it would increase your risk. (For which reason I have allocated up/down similar limits.)</p>
16:46 < A123> Ah, good point, I can just limit my download speed.</p>
16:46 <@LevDavidovitch> btw, you should limit both your dl and ul speed</p>
16:47 <+Complication> But if someone targeted everyone who downloads more than uploads... they'd be targeting everyone and their granny.</p>
16:47 < wiht> We are still having disconnection issues with IRC, it seems.</p>
16:47 < jrandom> wiht: only a few people are</p>
16:47 < wiht> OK.</p>
16:47 <@LevDavidovitch> also reconnection is v FAST these days</p>
16:48 < jrandom> (and nothing as bad as it was)</p>
16:48 < wiht> I agree, reconnections are better.</p>
16:48 < jrandom> aye, its nice to have our irc servers hosted on routers with reasonable bw limits :)</p>
16:49 < jrandom> ((not that before was unreasonable, it was great, we just outgrew it))</p>
16:49 < A123> Is there any technical reason why DCC isn't supported? It can be implemented similar to the nat module, right?</p>
16:49 < jrandom> ok, anyone have anything for 2) 0.6.1?</p>
16:49 < jrandom> yes A123, there are technical reasons why dcc isnt supported</p>
16:50 <@LevDavidovitch> it'd have to be done client side, i think.</p>
16:50 < jrandom> someone could implement an irc proxy with dcc support, but no one has</p>
16:50 < A123> What are they? Or is that a long discussion?</p>
16:50 < jrandom> dcc support requires knowing and interpretting the irc protocol, and rewriting the irc messages sent as necessary</p>
16:50 <@LevDavidovitch> normal dcc uses arbitrary ports and all</p>
16:50 < jrandom> (in particular, ctcp messages for establishing dcc connections)</p>
16:50 < A123> Oh, that's what I meant to ask... Whether it was technically possible to do it as with a nat module (which does as you say).</p>
16:51 < jrandom> i dont know what a nat module is?</p>
16:51 <@LevDavidovitch> the nat uses some UDP weirdnesses.</p>
16:52 <@LevDavidovitch> the nat traversal thing i think he means</p>
16:52 < jrandom> ah, ok, yeah, its technically possible, but no one has volunteered to work on it (and i'm swamped)</p>
16:52 < A123> No... At least for Linux, there's a masq module for iptables which will rewrite IRC packets with DCC CTCP requests.</p>
16:53 <@LevDavidovitch> ah, i see</p>
16:53 <@LevDavidovitch> maybe some of that code would be usable</p>
16:53 <@LevDavidovitch> depends how intimate it is with the ipfilter thing</p>
16:54 < jrandom> probably simpler to just extend I2PTunnelClient to interpret irc perhaps</p>
16:54 < A123> http://www.koders.com/c/fidA6A89E1080590138EB211E694473DDDD098B6B75.aspx &lt;- Might be interesting, courtesy of Google.</p>
16:54 < jrandom> (in the same way I2PTunnelHTTPClient extends it to interpret HTTP)</p>
16:55 <@LevDavidovitch> not in most countries. </p>
16:55 <@LevDavidovitch> oops</p>
16:56 < jrandom> A123: an os level filter would be a bit tough to deploy, but if someone wants to work on it, that'd be a good place to start</p>
16:57 < jrandom> ok, anything else on 2) 0.6.1, or shall we move on to 3) ???</p>
16:57 < A123> jrandom, it wouldn't really need to be OS level, would it? It would be coming through the IRC tunnel anyway...</p>
16:58 < jrandom> actually, it wouldn't even work as an iptables filter. it has to be done inside i2ptunnel or some other i2p-aware proxy</p>
16:58 < jrandom> in any case, its a lot of work, and unless someone volunteers to do it, it'll never get done ;)</p>
16:59 < jrandom> (it *woudl* be cool though)</p>
16:59 < A123> Right.</p>
16:59 < A123> I meant "like the iptables filter", not "using the iptables filter" :)</p>
16:59 < A123> -the+a</p>
16:59 < A123> +n</p>
17:00 < A123> Hrm hrm.</p>
17:00 <@LevDavidovitch> go forth I think</p>
17:01 < jrandom> ok, on to 3) ??? </p>
17:01 < jrandom> (though one could probably say we've been on 3) all along ;)</p>
17:01 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
17:01 <+fox> &lt;brutus&gt; on 3) bugzilla would be nice to have in shape before 1.0</p>
17:01 < wiht> Speaking of the usability suggestions from the mailing list, have you incorporated any of them into I2P?</p>
17:02 < jrandom> brutus: we used to have bugzilla, but no one used it</p>
17:03 < wiht> I should say, are you still concentrating on the core I2P functionality and planning to focus on usability a little later?</p>
17:03 < A123> I don't want to try it here, but I think that sending someone a DCC request at the moment would reveal to them your IP.</p>
17:03 < A123> (Assuming your client knows your IP)</p>
17:03 < jrandom> wiht: the last week i've been doing a lot of improvements to the streaming lib which should substantially improve usability</p>
17:04 < jrandom> A123: the irc servers filter ctcp messages</p>
17:04 < jrandom> (they've been modified)</p>
17:04 < A123> Servers...</p>
17:04 < jrandom> but yes, that does send your ip to the server (which it may discard, or may file into some NSA database)</p>
17:04 < jrandom> so, dont send dcc requests</p>
17:04 < A123> I don't really want the server admins knowing who I am, either :)</p>
17:05 < A123> (In theory. I don't care now or with you guys)</p>
17:05 < A123> It might be worth warning users about that.</p>
17:05 < jrandom> there's a page on the wiki about a whole slew of issues iirc</p>
17:05 < jrandom> (swing by ugha.i2p)</p>
17:06 <+fox> &lt;mihi&gt; btw: are the irc2p servers connected via i2p or directly?</p>
17:06 <+Complication> I'd assume i2p</p>
17:06 <+Complication> Unless someone's gone mad meanwhile, and not notified me. :P</p>
17:06 < wiht> jrandom, that's good, but what about the UI suggestions by Isamoor?</p>
17:07 < jrandom> mihi: i believe they're done over i2p</p>
17:08 < jrandom> wiht: the list of what i've been doing is available on http://dev.i2p/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD</p>
17:09 < jrandom> there's a lot more to be done, and a lot more will be done, but i have only two hands</p>
17:09 < wiht> Thank you, I will look there.</p>
17:10 < jrandom> actually, i have something to bring up for the meeting...</p>
17:10 < A123> What's the server/channel that fox is changating? Or do I misunderstand fox's purpose?</p>
17:11 < jrandom> as mentioned on hq.postman.i2p, we've had over a full year of anonymous mail service through postman's servers! </p>
17:11 * jrandom cheers</p>
17:11 * wiht does not want to seem ungrateful.</p>
17:12 < A123> jrandom, have the spammers caught on yet?</p>
17:12 < jrandom> A123: fox is a bridge to irc.freenode.net</p>
17:12 < A123> (OK, it's a slow way to go about spamming...)</p>
17:12 < jrandom> A123: doubt it, postman has antispam measures</p>
17:12 < jrandom> inbound spam is a bit of a problem though ;)</p>
17:13 < jrandom> (but my account there has been well filtered)</p>
17:13 < mule> is it really that long. time passes ...</p>
17:13 < A123> jrandom, ah, thanks.</p>
17:13 * Complication looks if someone has finally dropped him a bear via e-mail</p>
17:14 <+fox> &lt;brutus&gt; yeah, postman & cervantes deserve a medal, they're pulling some great weights around here</p>
17:15 <+fox> &lt;brutus&gt; excellent services indeed</p>
17:16 < jrandom> mos' def'. as is mule with his outproxy and fproxy, orion with his site, and the rest of y'all with yer content :)</p>
17:16 < jrandom> ok, anyone have anything else to bring up for the meeting?</p>
17:16 < wiht> Speaking of content...</p>
17:16 < wiht> It seems that we know what sites are up or not, but no easily accessible directory of sites.</p>
17:17 < A123> My clock runs fast. Would it be possible for the "Updating clock offset to -316819ms from -304801ms" messages to be downgraded from "CRIT"? It's a little disconcerting.</p>
17:17 < wiht> I was thinking of creating one where site admins can post what their site is about.</p>
17:17 < jrandom> orion.i2p is pretty easily accessible...?</p>
17:17 < jrandom> A123: hmm, perhaps</p>
17:18 < wiht> It has a short description of sites' purposes?</p>
17:18 <+postman> A123: spam is only a problem for incoming mail ( mail FROM the internet )</p>
17:18 < jrandom> wiht: yeah, it does, though i dont know where they come from</p>
17:18 <+Complication> wiht: no, orion doesn't seem to have that feature</p>
17:18 < wiht> I will look again.</p>
17:18 < jrandom> iirc jnymo used to maintain them</p>
17:18 <+postman> A123: i2p mail users can rarely spam themselves as well as they cannot spam internet targets</p>
17:19 <+Complication> Sorry, meant to say it doesn't seem user-accessible.</p>
17:19 < wiht> I was thinking of a directory that categorizes sites, something similar to dmoz.org.</p>
17:19 < A123> wiht, as a brand new user, that sounds great.</p>
17:19 <+fox> &lt;Sugadude&gt; wiht: Do we have enough sites to need to classify them?</p>
17:19 < A123> wiht, but check Freenet for an excellent example of how not to do it.</p>
17:20 < jrandom> a reliable categorized site would be neat. or perhaps we can integrate it into syndie to let people tag and categorize their peer references (and share them)</p>
17:20 < jrandom> (syndie already has a set of category tags for each bookmark, laying it out visually dmoz style wouldnt be hard)</p>
17:20 < jrandom> and it'd be local &lt;--- fast</p>
17:20 < A123> Or just get Google interested in i2p...</p>
17:20 < jrandom> heh</p>
17:24 < jrandom> ok, if there's nothing more for the meeting...</p>
17:25 * jrandom winds up</p>
17:25 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

526
i2p2www/meetings/15.log Normal file
View File

@@ -0,0 +1,526 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 15{% endblock %}
{% block content %}
<h3>I2P (invisiblenet) Development Meeting 15</h3>
<div class="irclog">
Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
--- Log opened Tue Oct 15 23:31:29 2002
23:31 < logger> test
23:32 < mason> sorry, that test did not work
23:32 < mason> :)
23:32 -!- mode/#iip-dev [+o mids] by Trent
23:32 <@mids> Tue Oct 15 21:32:19 UTC 2002
23:32 <@mids> meeting starts in 1:30 hours
--- Day changed Wed Oct 16 2002
00:44 < geully> hi all
00:50 <@mids> Public IIP meeting in 10 minutes here
00:50 < Robert> Hello all.
00:51 <@mids> shhh
00:51 <@mids> not yet
00:51 <@mids> 9 more minutes
00:51 < Grishnav> lol
00:51 < al-jabr> Tue Oct 15 22:51:23 UTC 2002
00:51 * Robert zips his lip.
00:51 < al-jabr> lalala
00:53 -!- geully is now known as Geully
01:00 <@mids> Tue Oct 15 23:00:02 UTC 2002
01:00 <@mids> welcome to the n-th public IIP meeting
01:00 <@mids> logfiles are on http://mids.student.utwente.nl/~mids/iip/
01:00 < nop> hehe
01:00 <@mids> oh, 15th
01:00 < nop> 15th
01:00 < nop> yes
01:00 <@mids> agenda for today:
01:01 <@mids> - new IIP developer
01:01 <@mids> - IIP logo contest
01:01 <@mids> - bug fixes
01:01 <@mids> - question rounds
01:01 <@mids> ,
01:01 <@mids> .
01:01 < nop> ok
01:02 < nop> welcome back all
01:02 < nop> to another round of meetings ;)
01:02 < nop> for all that work in a corporate office
01:02 < nop> you have permission to sleep
01:02 < nop> ok
01:02 < nop> new IIP developer
01:02 -!- mode/#iip-dev [+o nop] by mids
01:02 <@nop> and is a talented and quick learning C programmer
01:02 -!- mode/#iip-dev [+o UserX] by mids
01:02 <@nop> and has already added some patches and some grunt work that was needed to the code
01:03 <@mids> hurray!
01:03 <@nop> we are glad to have him
01:03 <@nop> and we feel that he will be an essential part of the team
01:03 * al-jabr claps
01:03 <@nop> ok
01:03 <@nop> next on list
01:03 <@nop> IIP logo contest
01:03 <@nop> any graphix designers etc
01:03 <@mids> graphix? you mean graphics?
01:04 < Grishnav> No, he means graphix :P
01:04 < hobbs> nop: maybe. Me or my mom. She's good, and she got a tablet recently. :)
01:04 <@nop> who would like to come up with a cool slogan and/or logo for invisiblenet, and IIP (yes I mean graphics) for t-shirts can submit their entries to iip@invisiblenet.net
01:04 <@nop> the winner
01:04 <@nop> will win a free t-shirt
01:04 <@nop> black or white
01:04 <@nop> of his choice
01:04 <@nop> or her choice
01:04 <@mids> woohoo!
01:04 <@nop> and 10.00 DRAN
01:04 < hobbs> nice.
01:05 <@nop> this can definitely include slogans as well
01:05 <@nop> so there could be two winners
01:05 <@nop> if one comes up with logo
01:05 -!- mode/#iip-dev [+o Chocolate] by mids
01:05 <@nop> and one comes up with an awesome slogan
01:05 -!- mode/#iip-dev [+o Chocolate] by Trent
01:05 <@nop> but submit to iip@invisiblenet.net
01:05 <@nop> and they will be reviewed
01:05 <@nop> I hope that if you're not a graphics guy, that you can tell a friend
01:05 <@nop> and maybe split the profits
01:05 <@nop> ;)
01:06 <@nop> because we would like to have cool shirts
01:06 <@nop> for the e-store
01:06 <@nop> and in general
01:06 <@nop> as well
01:06 <@nop> for bumper stickers etc
01:06 <@nop> maybe a mascot would be good too
01:06 <@mids> :)
01:06 <@nop> either way
01:06 <@nop> do what you can
01:06 <@nop> submit them
01:06 <@nop> and we'll decide at the end of the month
01:06 < philocs> our only mascot is satan
01:06 <@nop> well
01:06 <@nop> that's taken
01:06 <@nop> BSD
01:06 <@nop> ;)
01:07 < philocs> we could make a scarier satan
01:07 < hobbs> that's a DAEMON!
01:07 <@nop> hehe
01:07 <@Chocolate> black
01:07 <@nop> ok
01:07 <@nop> next
01:07 <@nop> bugfixes
01:07 <@Chocolate> tshirt must be black
01:07 <@nop> ok
01:07 <@nop> yeah
01:07 <@nop> all artist must make inversed drawings
01:07 <@nop> so that it caters to black or white backgrounds
01:07 <@nop> and you can use color :)
01:07 <@nop> oh
01:07 <@nop> and the winner
01:08 < nemesis> http://www.stk.com/products/50_beta/about50.cfm
01:08 <@nop> will of course get full credit by having his logo on the t-shirt
01:08 < nemesis> nice
01:08 * al-jabr fears that this T-shirt may be hopelessly dorky
01:08 <@mids> al-jabr: make a better one
01:08 <@mids> okay...
01:08 <@mids> next poing?
01:09 <@mids> point :)
01:09 <@mids> beeing: bugfixes
01:09 <@mids> UserX fixed even more bugs then reported
01:09 <@mids> there are still a few (possible) bugs out there..
01:09 <@mids> if you found some that aren't mentioned
01:09 <@mids> please tell us
01:10 < al-jabr> I personally couldn't replicate the terminal bug, unless that was something in CVS
01:10 <@mids> without bugreports we cant fix
01:10 <@nop> neither could i
01:10 <@mids> al-jabr: I have had it in the past; but couldn't repeat
01:10 <@mids> I'll ask Jeekay for more details
01:10 < philocs> where do I find list of outstanding bugs?
01:11 <@nop> well everyone is encouraged to use the sourceforge bug tracker
01:11 <@nop> but most people don't
01:11 <@nop> ;)
01:11 < philocs> bug tracker is good
01:11 <@nop> we should probably link to that on our main site
01:11 <@mids> http://www.sourceforge.net/projects/invisibleip/
01:11 <@nop> for a bug submital
01:11 < firegod> too bad it doesnt have an IRC frontend (:
01:11 <@mids> most bugs are mailed to the iip-dev mailinglist though
01:11 < philocs> ok I just subscribed yesterday
01:11 <@mids> cool
01:12 < nemesis> cause the logo, whate resolution? and dpi ?
01:13 <@nop> any one knowing graphix have a suggestion for resolution and dpi?
01:13 < firegod> start big
01:13 < firegod> it can be resized
01:13 <@nop> ok
01:13 <@nop> kewl
01:13 < firegod> down if needed
01:13 < nemesis> -e
01:13 < firegod> it is much more difficult going the other way (:
01:13 < nemesis> hehe
01:13 < nemesis> firegod
01:13 < nemesis> something
01:14 < hobbs> nop: would you be interested in having it in a vector graphics format, if that just happens to be how it's done?
01:14 < firegod> always good to have high res masters
01:14 < nemesis> 10 megapixels
01:14 <@nop> svg?
01:14 < nemesis> 72dpi
01:14 < hobbs> (not that I even own a vector program, but somebody might care)
01:14 < nemesis> or 1000 ?
01:14 < nemesis> ;)
01:14 < nemesis> very dificult
01:14 < nemesis> +f
01:15 < firegod> sure, if they are creative..
01:15 < firegod> but svg isnt widly used just yet
01:15 < al-jabr> Question: I'm patching IIP to use /dev/random. Would you be interested in incorporating this? I'm doing it #ifdef linux for until I or someone configurifies the source.
01:15 < firegod> so standard raster formats would be more usable atm
01:15 < firegod> al-jabr: finish the patch and submit it to the mailing list
01:15 <@nop> al-jar
01:15 < al-jabr> okay
01:15 < hobbs> al-jabr: I'd suggest making it #ifdef SOME_FLAG_THAT_CAN_GO_IN_MAKEFILE
01:15 < al-jabr> yeah
01:16 < al-jabr> will do
01:16 < hobbs> (and have a well-commented DFLAGS line in Makefile)
01:16 <@nop> yarrow is a very good prng
01:16 <@nop> it's known to be secure
01:16 <@nop> and we have done a test with our randomness via chi-square
01:16 < al-jabr> nop: I believe yarrow would be redundard when we have /dev/urandom
01:16 <@nop> and it got 25% which is good
01:16 <@nop> yes, but yarrow is portable
01:16 <@nop> and known to be stronger
01:16 <@mids> al-jabr: the problem is that not all operating systems have a good implementation for /dev/random
01:16 < firegod> not at all
01:17 <@nop> I would rather rely on what a cryptography expert developed
01:17 <@nop> then the /dev/random on the machines
01:17 < hobbs> true. A -DUSE_DEV_RANDOM might end up being useful, or it might just hurt a lot of people who don't know what they're doing.
01:17 <@mids> otoh, giving the more modular future of IIP, maybe several alternatives could be an option
01:17 < hobbs> and not the best odds on the first. :)
01:17 <@nop> yes
01:17 <@nop> and we do plan to add more entropy in the future
01:18 < al-jabr> Well, linux /dev/random and /dev/urandom are some of the most scrutinized crypto out there... I'm mostly thinking of that because it's a very good entropy pool that's out there on very many machines running IIP
01:18 <@nop> to increase this
01:18 < firegod> general question: with iip2 are we going to have more feedback from the proxy?
01:18 < al-jabr> you wouldn't have to go querying the user for entropy.
01:18 <@nop> yes firegod
01:18 <@nop> well you usually don't
01:18 <@nop> but it's definitely added plus
01:18 <@nop> if there isn't enough
01:18 <@nop> it will query
01:19 <@nop> and we will probably look into adding a form of /dev/random entropy very soon
01:19 < hobbs> does linux /dev/random support O_NONBLOCK ?
01:19 <@nop> because we intend on really strengthening the pool
01:19 <@nop> I'm sure it does hobbs
01:19 <@nop> /dev/random let's you select your pool size
01:19 < hobbs> nop: yeah, but there's a softlimit, and a hardlimit in the kernel, and the hardlimit isn't that big.
01:19 <@nop> al-jabr it would be best to hold off
01:19 < al-jabr> nop: personally I'd trust linux more, which uses SHA1 and uses all kinds of hardware sources of entropy, than a newbie who might just go entering 'aaaaaaaaaa...' but anyway it's only an option
01:20 <@nop> al-jabr
01:20 < al-jabr> ok
01:20 <@nop> thats not all the entropy
01:20 <@nop> there is more
01:20 <@nop> there are network timings, and dh calculation timings as well
01:20 < al-jabr> but it only has access to user-mode entropy
01:20 <@nop> and we plan to add more
01:20 < al-jabr> why reinvent the wheel. i recommend using /dev/random and for those who don't have it, EGD.
01:20 <@mids> nop: would it harm to give al-jabr a try, and maybe use it as plugin for entropy?
01:20 < al-jabr> since the GPG and linux people are doing it
01:21 <@mids> nop: alww
01:21 < al-jabr> why don't we concentrate on doing what we do best?
01:21 <@nop> that's fine
01:21 <@mids> nop: always good to have alternatives around
01:21 <@nop> if you want to submit a patch
01:21 <@nop> please do
01:21 <@nop> I'm not against it
01:21 <@nop> and we definitely want to add more entropy
01:21 < philocs> is the darwin /dev/random good? is it the same one in linux or openbsd?
01:21 <@nop> so please submit it to iip-dev when you've added it
01:21 < firegod> thats what mailing lists are for, people can digest it better
01:22 < al-jabr> okay, will do.
01:22 <@nop> thnx
01:22 <@nop> is that all?
01:22 <@nop> no more questions?
01:22 <@mids> hehe
01:22 <@nop> or suggestions
01:22 <@nop> or complaints
01:22 < nemesis> hm..
01:22 < philocs> I have a dumb newbie question ...
01:22 <@nop> sure
01:22 < firegod> well. release dates?
01:22 < nemesis> cache in the nodes
01:22 <@mids> sjoet
01:22 <@nop> oh oh on
01:22 <@nop> that wasn't on the list
01:22 <@nop> but
01:23 <@nop> we are at this time working on a short term todo list
01:23 <@nop> that will be publicized
01:23 < philocs> if someone hacks a relay to log, does that mean they can see the trafic for private channels that go through it?
01:23 <@nop> no
01:23 <@mids> philocs: all traffic is encrypted node-node and end-end
01:23 < philocs> ok, so you can only get the cleartext at the server, right?
01:23 < firegod> but not contextually withing IRC
01:23 <@nop> right
01:24 < firegod> right
01:24 < firegod> and the client
01:24 <@mids> philocs: correct
01:24 <@nop> yes
01:24 < philocs> good
01:24 < firegod> how far are you from encrypted channels?
01:24 < hobbs> and the client -- well, can only see stuff that's actually sent to it.
01:24 <@mids> firegod: nop is working on a roadmap and syncing it with the developers (if I understood well)
01:24 < nemesis> add an multicast option for filetransfers, when one user, will send the same file to some multiple clients
01:24 < hobbs> which means, if you don't even know that a channel exists, then you can't (intentionally or accidentally) snoop it.
01:24 <@nop> firegod it will be done when we decentralize
01:24 <@nop> which is our next goal
01:25 <@nop> after 1.1 stable
01:25 < nemesis> that the nodes between the nodes cache it
01:25 < firegod> okay. roadmap.
01:25 < hobbs> nemesis: actually.... that's worth thinking about -- talk to chocolate. :)
01:25 < philocs> is there an advantage to having "channel key encryption" before decentralization?
01:25 <@mids> nemesis: well, filetransfer isnt implemented in IIP itself anyway
01:25 < nemesis> lol
01:25 < firegod> hobbs: well, knowing about a channel is easy
01:25 <@mids> nemesis: it CAN do multicast, just send it to a channel :)
01:25 < hobbs> nemesis: it should be possible to add a hack to fileserv to have it use a channel, and then anyone who wants to receive just joins. :)
01:25 < hobbs> firegod: oh, is it?
01:25 < nemesis> what can you do with an anonymous network
01:26 < nemesis> when you can share code?
01:26 < nemesis> whats about some c code?
01:26 < firegod> multicast is a problem due to not spectacular widespread support..
01:26 <@mids> philocs: yes, I'd think so... less trust needed on the server
01:26 < nemesis> when the complet internet are banned for open source?
01:26 < hobbs> firegod: not multicast IP, just "multicast" :)
01:26 < firegod> hobbs: re fileserv channel: that gives you encrypted channels btw (:
01:26 < nemesis> how you can share this information?
01:26 < hobbs> firegod: oh, how's that?
01:27 < nemesis> &lt;hobbs&gt; nemesis: it should be possible to add a hack to fileserv to have it use a channel, and then anyone who wants to receive just joins. :)
01:27 < firegod> hobbs: sure, if you join IIP at all it is simple to /list the channels
01:27 < nemesis> not a hack
01:27 < philocs> I might start thinking about some 'channel key encryption'. it doesn't seem like it would be terribly complicated thing to me, just keep private keys in some directory maybe
01:27 < nemesis> built in
01:27 < nemesis> and an "server node" option
01:27 < nemesis> to allow that
01:27 < nemesis> or not
01:27 <@mids> philocs: you could implement it client side...
01:27 < hobbs> nemesis: okay, I'm just behind the times. I haven't worked on fileserv for... months
01:27 < nemesis> and an option for the cache size for it
01:27 <@mids> philocs: look at the blowfish.pl scripts for irssi and xchat
01:27 < firegod> philocs: and perl plugins on clients
01:27 <@mids> s/blowfish/blowjob/
01:28 < philocs> mids: would it make sense to implement it in the client side of isproxy?
01:28 <@mids> nemesis: caching wouldnt make much sense when everything goes still through the central ircd
01:28 < philocs> that way it would work with all clients
01:28 < nemesis> &lt;mids&gt; nemesis: caching wouldnt make much sense when everything goes still through the central ircd
01:28 <@mids> philocs: maybe; but that would require the 'vircd'
01:28 < nemesis> i think there are planned to be an p2p network?
01:28 < nemesis> and then theres no central hub
01:28 <@mids> nemesis: for IIP 2
01:29 < nemesis> only some nodes
01:29 < nemesis> where cache the datas
01:29 <@mids> nemesis: but that is long term; first IIP 1.2
01:29 < philocs> nemesis: I think you want freenet maybe
01:29 < nemesis> no
01:29 < philocs> p2p file transfers with caching
01:29 < nemesis> only an option to share some public files
01:29 < nemesis> or larger text
01:29 < philocs> thats what freenet does
01:29 < firegod> any merging of namespace possible between freenet and iip?
01:29 < nemesis> that you don'*t copy it line for line in the channel /query
01:29 < hobbs> what sits on top of the IIPv2 network could be a lot of interesting things -- but that's a while off. :)
01:29 <@mids> nemesis: first we would need decentralized routing...
01:30 < nemesis> k
01:30 < firegod> every isproxy was a freenet node?
01:30 < nemesis> but don't forget it ;)
01:30 < philocs> I don't think it makes sense to cannabalize freenet ...
01:30 <@mids> nemesis: once we have that; ask again :)
01:30 < firegod> philocs: does it do the job?
01:30 < nemesis> lol
01:30 <@mids> philocs: giving recent freenet-shit; I'd say no, indeed it doesn't
01:30 < firegod> philocs: and I like 'incorporate' a bit better
01:30 < hobbs> it should be possible to write a mini-freenet on top of IIP... but it would be better to leave freenet at what it does, and take advantage of the high speed and "pushiness" of IIP to write even better things.
01:30 < nemesis> in how many years? *fg*
01:31 < firegod> alright (:
01:31 < firegod> people do want to exchange chunks of binary data thru their messaging clients, in this case IIP
01:31 < firegod> how will that be addressed?
01:31 < philocs> firegod: well, I think it does the job well, and it will only get better. yes I agree that it would be better to have iip implement the freenet protocol for freenet type things rather than make something incompatible
01:31 < hobbs> for example, IIPv2 should be able to support the niftiest "anonymail" anyone's ever seen (without a bot), unless I'm hallucinating. :)
01:31 < nemesis> hm..
01:32 < nemesis> hacker ethic
01:32 < nemesis> the slogon
01:32 < nemesis> for..
01:32 < nemesis> miiiids!!
01:32 <@mids> hobbs: IIPv2 will be so smart that it could do your math homework
01:32 < hobbs> that's good, 'cause I don't do mine often enough.
01:32 < philocs> speaking of which
01:33 <@UserX> firegod: the intention is to do a DCC emulation using Freenet as the transport for files
01:33 < Grishnav> Sorry if this has already been suggested, I've missed much of the conversation being in and out of the room, but how about some sort of API for IIP to create modules? After IIP gets completely distributed (with v2) you could have all sorts of interesting modules pop up... a file transfer mod, perhaps a freenet node mod if you only wanted one service running...
01:33 < firegod> UserX: that'll work (:
01:33 < philocs> UserX: I think that is the best solution
01:33 < hobbs> Grishnav: that's more or less the plan, as I understand it. And if it's not, we'll beat nop with halibut until it is.
01:33 < Grishnav> lol
01:34 < firegod> UserX: but if IIPv2 is decenteralized, would this dcc emulation need freenet? you already can do point multipoint point transfers, you just need a session handshake for that kind of transfer
01:34 < firegod> albiet dcc
01:34 < nemesis> waaaaaaaaaah
01:34 < philocs> plus if every iip user was running some sort of freenet implementation, that would make freenet much better
01:34 < nemesis> ardvark
01:34 < nemesis> grrrrrr
01:34 < nemesis> where is he?
01:34 < nemesis> where can speak german?
01:34 < hobbs> also, it should be (more) convenient to have multiple IIPv2 networks, but I think that's a given. :)
01:34 < nemesis> or known only a little bit german
01:34 < firegod> philocs: thats what I'm saying (:
01:34 < nemesis> and have the english hacker ethic?
01:34 < firegod> whos working on IIPv2?
01:35 < philocs> I need to go study for my german test soon
01:35 < philocs> firegod: are you left handed or in oz or something?
01:35 <@mids> hm, ppl; I got to go; keep chatting here
01:35 <@mids> bbl
01:35 < nemesis> hrhr
01:35 < nemesis> mids!!!
01:35 < firegod> philocs: nope, just a freak
01:35 < nemesis> don't drunk to much ;p
01:35 < nemesis> *fg*
01:36 < firegod> mids is working on IIPv2 I'm sure, anyone else? UserX?
01:36 < nemesis> nop
01:36 <@UserX> firegod: in theory yes. but currently we want to keep IIP low bandwidth. freenet would me suited transfering large volumes of data (and better because it doesn't have a constraint of realtime routing that IIP needs)
01:36 < nemesis> i think
01:36 <@nop> yes
01:36 < nemesis> aaaaaah
01:36 < nemesis> nop
01:36 < philocs> I guess what is really needed is for someone to write a C implementation of freenet ...
01:36 < firegod> UserX: this is true.
01:37 < firegod> UserX: or at least an opt-in on that feature
01:37 <@UserX> firegod: yes i am working v2
01:37 < hobbs> philocs: I agreed with that pretty heavily a few months ago, but right now I'm happy to let java fred do its thing, and settle down, before anyone clones.
01:37 < hobbs> (now that it _works_, that is)
01:37 < firegod> UserX: how have you solved scaling issues for resource location? ie: how do you find nodes originating #channels?
01:37 < philocs> UserX: yes well thats a good reason to not make it easy for people to do 'dcc' and to encourage them to use freenet
01:38 < firegod> philocs: it should just be opt-in.. people wanting to abuse their bandwidth, can go right ahead.. those on modems dont get killed (:
01:38 < hobbs> UserX: would be nice to keep in mind, though, that freenet is good at pulling things, and iip is good at pushing things. :)
01:38 < philocs> hobbs: well I agree, I think the java version is fine but if we are going to basically package freenet with iip somehow then eventually (and probably when freenet hits 1.0?) we will want a c implementation
01:38 < firegod> philocs: those wanting freenet backed features, change a setting and BLAM it just works
01:38 <@UserX> firegod: haven't worked out highly scalable system yet
01:39 < firegod> hobbs: IIP is a great way of grouping freenet keys (:
01:39 < hobbs> philocs: that's some pretty long thinking. :)
01:39 < firegod> UserX: ah. If you havnt peaked at Circle, I encourage you to (:
01:39 < firegod> I know mids said he'd played with it
01:39 < philocs> hobbs: well freenet is getting more stable all the time
01:40 < youkai> yeah, i would never run freenet as long as its only java
01:40 < firegod> theres a slogan for ya d-:
01:40 < firegod> "getting more stable every day"
01:40 < youkai> too bulky
01:41 < philocs> youkai: its not too bad
01:41 < youkai> plus i think its shitty to have os software that only compiles on a corp owned language
01:41 < Grishnav> I don't like Java anymore than the next guy, but I certainly am a freenet fan. I'll use the java one, but only until I hear about a C implementation. :)
01:42 < youkai> i mean if you guys were using the os non sun java i wouldent mind as much
01:42 < youkai> ah yes
01:42 < youkai> blackdown
01:42 < hobbs> youkai: freenet works fine on a few flavors of non-sun java.
01:42 < hobbs> blackdown has sun behind it.
01:42 < youkai> you just cant win with java then :/
01:42 < firegod> so?
01:42 < youkai> i dont trust sun any more then i do microsoft
01:43 < firegod> java is not your friend (:
01:43 < Grishnav> Does anyone have a link to the souce download for Blackdown? (Their site is less than helpful)
01:43 < firegod> I encourage those who are disatisfied with java, to try phthon for their scripting needs (it is NOT java)
01:43 < youkai> yeah python is cool
01:44 < youkai> but i dident stop running m$ operating systems just so i could let another corp in the door (sun)
01:44 < hobbs> Grishnav: er. It's in "non-free" for a reason, isn't it?
01:44 < philocs> you are wanting me to write freenet in python? would a python module be distributed with iip?
01:44 < Grishnav> Ahh... I was under the impression is was free. my mistake.
01:45 < youkai> thats the only problem i have with freenet
01:45 < philocs> java is not evil, sun treats java differently than MS treats windows
01:45 < hobbs> Grishnav: no. If you ask sun, it's impossible to create a free java2 implementation, and they've done a good job of making it true.
01:45 < youkai> i mean java is a lot easier to code in because you dont have to worry about memory leaks and stuff as much
01:45 < Grishnav> rofl
01:45 < youkai> the garbage collector lets you be lazy
01:45 < philocs> hobbs: why is it impossible?
01:45 < Grishnav> [16:45] &lt;youkai&gt; i mean java is a lot easier to code in because you dont have to worry about memory leaks and stuff as much -- yeah, it's no wonder that all java apps are so goddamn memory hoggy!!
01:46 < youkai> yeah thats because they need the whole jre loaded in memory with the software
01:46 < hobbs> philocs: because if you write anything that's java2, and claims to be "java", then sun will destroy you. :)
01:46 < philocs> hobbs: yes but you can make java, just don't call it 'java'
01:46 < hobbs> er... without obtaining the appropriate license and signing the appropriate agreements first, that is. :)
01:46 < Grishnav> call it coffee
01:46 < philocs> kaffe
01:46 < Grishnav> hehe
01:46 < Grishnav> yeah
01:47 < Grishnav> I've played with Kaffe
01:47 < hobbs> philocs: true. But nobody's done it.
01:47 < Grishnav> not quite mature enough yet, but getting there
01:47 < philocs> hobbs: uh yes, the FSF has done it
01:47 < hobbs> philocs: oh?
01:47 < philocs> yes
01:47 < youkai> but seriously i think java is right up there with VB
01:47 < philocs> Kaffe
01:47 < hobbs> philocs: Kaffe is not java2.
01:47 < youkai> its for lazy programmers
01:47 < youkai> who dont mind being owned by a corp
01:47 < philocs> hobbs: but there is no reason it could not implement java2
01:47 < hobbs> philocs: except for the fact that it doesn't.
01:47 < philocs> plus gccj or whatever its called
01:48 < hobbs> er...
01:48 < youkai> the other thing is java2 is huge, and they have a gigantic team of programmers working on it all the time
01:48 < hobbs> yeah. gcj/gij are also nice.
01:48 < firegod> not to interupt, but java wars work out better in apropriatly named channels (:
01:48 < philocs> hobbs: but its not a legal issue, the java spec is an open standard, the java name is not
01:48 < youkai> gcj?
01:48 < philocs> youkai: gcc that compiles java code
01:48 < youkai> huh
01:49 < youkai> to binary or does it still need a jre
01:49 < philocs> binary I believe
01:49 < hobbs> philocs: that's a pretty heavy restriction, though.
01:49 < hobbs> You can't say: this is java, this is compatible with java, or this smells like java.
01:49 < philocs> hobbs: well I don't think so. You can make the claim that 'this software is not java, but you will probably find that it works the same'
01:50 < philocs> which most people would understand
01:50 < hobbs> probably.
01:50 < youkai> anyway, why rewrite java when you could just use c++
01:50 < youkai> its almost the same language
01:51 < philocs> arg, I would rather use java over c++
01:51 < philocs> but I'm not getting into that
01:51 < philocs> anyway, I forgot where this horrible diatribe started
01:51 < hobbs> youkai: not really. c++ doesn't force you to use OO crap when it's completely inappropriate, like java does. :)
01:51 < firegod> round and round we go, where we stop nobody knows
01:51 < firegod> philocs: exactly
01:51 < philocs> ok, so in isproxy, is there like a client side and a node side?
01:52 < firegod> philocs: you know how many times I've seen this exact same 'argument' ? (:
01:52 < youkai> hobbs: hah
01:52 < firegod> philocs: there are relays, and proxys and 'servers'
01:52 < firegod> as I see it
01:52 <@UserX> philocs: can you clarify your question?
01:52 < philocs> I mean, would it make sense to put channel key encryption in isproxy, the part that actually talks to the irc client on 6667?
01:52 < hobbs> philocs: sorta. there are nodes, and there are nodes. :)
01:52 < firegod> philocs: dont forget you have multiple clients for each isproxy
01:53 < hobbs> and nodes 1) talk to clients 2) talk to nodes 3) (one of them) talks to the server.
01:53 < philocs> firegod: really? I've never been able to see this behavior, actually maybe its just my configuration
01:53 < firegod> (:
01:54 < philocs> but anyway, does my question make sense?
01:54 < youkai> i just came here to beg you guys not to write the next ver of iip in java :D
01:54 < firegod> which question d-:
01:54 < firegod> youkai: i think thats a given
01:54 <@UserX> philocs: currently IIP 1.x is essentially a tunnel. having the client implement channel encryption would require a lot of work to do. and would become redunant when v2 gets done
01:54 < youkai> also if theres freenet people around, a c++ ver would be nice
01:55 < firegod> UserX: how about isproxy functioning as an http tunnel?
01:55 < firegod> UserX: IIPv2 as well?
01:55 < nemesis> &lt;youkai&gt; i just came here to beg you guys not to write the next ver of iip in java :D
01:55 < nemesis> noooooo
01:56 < philocs> I'm thinking that you could have it so that there ways like a 'keys/' directory and then you could have in that 'channel.key' or something and then just run blowfish or whatever on what goes in and out of that channel, understand?
01:56 < nemesis> native code are the best thing
01:56 < philocs> and fuck c++, I'll take java over c++ anyday
01:56 < philocs> but I also think that c is nice
01:57 <@UserX> firegod: 1.x could be used to tunnel to a single fixed HTTP server
01:57 < firegod> okay, enough language wars please?
01:57 < nemesis> m$ sponsored his .net campain, and will place his IL on the front
01:57 < youkai> k :D
01:57 < firegod> User: hrmm
01:57 < nemesis> you can controll the compiller
01:57 < philocs> youkai keeps brining it up, if he likes c++ so much, he should marry it
01:57 < nemesis> thats the different
01:57 < firegod> oh jebus
01:57 < youkai> heh philocs: if you like java so much you should go work for sun
01:57 < nemesis> can't
01:58 < philocs> UserX: would that make sense or is it better to wait for next version to do that?
02:00 < youkai> UserX: thats a good idea
02:00 <@UserX> philocs: to do that with 1.x network would require giving nodes the intelligence to read and parse recompose IRC client messages/commands
02:01 < philocs> oh I see
02:01 < nemesis> &lt;UserX&gt; philocs: to do that with 1.x network would require giving nodes the intelligence to read and parse recompose IRC client messages/commands
02:01 < nemesis> xml ;)
02:01 <@UserX> it's possible but would take a fair amount of effort which i want to put into v2
02:01 < nemesis> very flexible
02:01 < philocs> I understand
02:02 < philocs> later
02:11 < logger> logging ended
--- Log closed Wed Oct 16 02:11:14 2002
</div>
{% endblock %}

148
i2p2www/meetings/150.log Normal file
View File

@@ -0,0 +1,148 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 150{% endblock %}
{% block content %}<h3>I2P dev meeting, October 4, 2005</h3>
<div class="irclog">
16:16 < jrandom> 0) hi</p>
16:16 < jrandom> 1) 0.6.1.1</p>
16:16 < jrandom> 2) i2phex</p>
16:16 <@protokol> speaking of, whats the news on legion and i2phex</p>
16:16 < jrandom> 3) syndie</p>
16:16 < jrandom> 4) ???</p>
16:16 < jrandom> 0) hi</p>
16:16 * jrandom waves</p>
16:16 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2005-October/000939.html</p>
16:17 <+postman> hi</p>
16:17 < jrandom> might as well jump into 1) 0.6.1.1</p>
16:18 <+postman> ya</p>
16:18 < jrandom> the network has been growing in number and in usage, but things have been doing pretty well</p>
16:18 <+postman> .. apart from the irc servers</p>
16:18 < jrandom> aye, thats an interesting one</p>
16:19 < jrandom> (the irc servers are currently running an older rev, and we're still working on some debugging to understand exactly why things are the way they are)</p>
16:19 <+Ragnarok> what happened?</p>
16:20 < jrandom> hopefully we'll get the irc servers upgraded sooner rather than later, as there has been some good stuff lately</p>
16:20 < cervantes> Ragnarok: server&lt;-&gt;server link is shakey under 1.1</p>
16:20 <+Ragnarok> weird</p>
16:20 < jrandom> 0.6.1.1, that is ;)</p>
16:20 <+Complication> protokol: see forum, he finally opted for a sensible approach</p>
16:20 <+postman> cervantes: don't mention the time travel, idiot</p>
16:20 < cervantes> 0.6.1.x</p>
16:20 <+postman> :)</p>
16:21 < cervantes> oop</p>
16:21 <+postman> jrandom: i hope i'll be able to build a test ircd this week</p>
16:21 <+postman> jrandom: we could link to an instance run by you or cervantes </p>
16:22 < jrandom> aye, that'd be great. we could even split off the different tunnels into different jvms, using different streaming libs and router versions, to isolate the issue further</p>
16:23 < jrandom> it'd be cool if we could do that before 0.6.1.2, but if not, no big deal</p>
16:24 < jrandom> ok, anyone else have anything for 1) 0.6.1.1?</p>
16:24 <+postman> jrandom: apart from that: runs like hell</p>
16:24 < jrandom> would that be a good hell or a bad hell? :)</p>
16:24 <+postman> a hell of a hell :)</p>
16:25 <+Complication> Eh, managed to cause a few more errors (but those were really, really borderline stuff, router restart under a running i2phex.) Will send privately.</p>
16:26 < jrandom> ah cool, thanks Complication </p>
16:26 <+Complication> (e.g. they probably won't hurt anyone in real life)</p>
16:26 < jrandom> heh never underestimate people's ability to break things :)</p>
16:27 < cervantes> or the ingenuity of fools in testing fool proof systems</p>
16:27 <+postman> yea, make something fool proof and you'll be rewarded with a new kind of fool</p>
16:28 < jrandom> hallelujah</p>
16:29 < jrandom> ok, anything else for 1), or shall we move on to 2) i2phex</p>
16:30 < jrandom> there has been a lot of discussion as of late, and legion has agreed to merge back the changes made into sirup's i2phex codebase. </p>
16:30 <+postman> move</p>
16:30 < jrandom> this is quite cool, as it'll be great for us all to benefit from legion's hard work while remaining entirely open and secure</p>
16:31 <+Ragnarok> what did he actually do?</p>
16:33 < jrandom> latest changes include the addition of systray4j, striker's timeout updates, increased tunnel length defaults, some nsis and jni stuff, and a few other changes</p>
16:33 <+Ragnarok> hm, ok</p>
16:33 <+postman> jrandom: so there're a bunch of improvements - those will be kept tho?</p>
16:34 < jrandom> certainly, all good stuff will be integrated into i2phex</p>
16:34 < jrandom> there are a few things i'm not so sure of, but that'll be discussed with legion outside of the meeting ;)</p>
16:35 <+postman> k</p>
16:36 < jrandom> ok, anyone else have anything for 2) i2phex? or shall we move on to 3) syndie?</p>
16:37 * postman prepares his syndie500 franchising goods</p>
16:37 < jrandom> heh</p>
16:37 < jrandom> ok, Ragnarok, wanna give us the rundown on the latest?</p>
16:37 <+Ragnarok> hm, ok</p>
16:38 <+Ragnarok> Syndie will now get new posts from an archive automatically. </p>
16:38 <+Ragnarok> you can set which archives you want to get updates from, and set how often you do it in the syndie config file</p>
16:39 <+Ragnarok> more details about that are in history.txt</p>
16:39 <+Ragnarok> it needs a ui, but otherwise it's essentially done</p>
16:39 <+Ragnarok> 'course, no one seems to be posting anything recently, so maybe it's not that useful :)</p>
16:40 < jrandom> [insert field of dreams quote here]</p>
16:40 < jrandom> thanks Ragnarok, this has been an oft requested feature</p>
16:41 <+Ragnarok> cool</p>
16:41 <+Ragnarok> happy to do it, wasn't really that much work</p>
16:42 <+Ragnarok> mostly just scratching my own itch :)</p>
16:42 < cervantes> oh wasn't it? or forget it then :P</p>
16:42 < cervantes> or=oh</p>
16:42 <+postman> (hush, the genius must not admit that it needs to work hard too)</p>
16:42 <+Ragnarok> hehe</p>
16:43 <+Ragnarok> anyway, if anyone's got bug reports/feature requests/boos/cheers/etc. let me know</p>
16:43 < jrandom> (cheers!)</p>
16:43 <+Ragnarok> next thing I'm thinking of is auto matically importing petnames seen in posts into the routers petname db, but that looks like it could be complicated...</p>
16:44 <+Ragnarok> but, it would essentially allow syndie to replace addressbook</p>
16:44 < jrandom> that would be Very Cool</p>
16:44 <+nickless_head> yeah :)</p>
16:45 <+Ragnarok> I just have to figure out how to get a list of petnames out of the archive</p>
16:45 <+Ragnarok> everything else is trivial</p>
16:45 <+nickless_head> ragnarok: are your changes already in cvs? (too lazy to read the whole discussion) :)</p>
16:45 <+Ragnarok> yeah</p>
16:45 <+nickless_head> :happy:</p>
16:45 * nickless_head considers cvs update</p>
16:45 <+Ragnarok> have been since yesterday</p>
16:45 <+nickless_head> nah, probably better to wait for the next release</p>
16:45 < jrandom> perhaps get the petnames whenever they're rendered, exposed via the HTMLRenderer (in the addressReceived)</p>
16:46 <+Ragnarok> ok, I'll look into that</p>
16:46 < jrandom> cool, thanks Ragnarok </p>
16:47 <+Ragnarok> well, that's it from me, unless there's questions</p>
16:49 < jrandom> wr0d. ok, jumping on to 4) ??? </p>
16:49 < jrandom> anyone have anything else to bring up for the meeting?</p>
16:49 < cervantes> aye</p>
16:49 * nickless_head looks at cervantes interestedly</p>
16:50 <+fox> &lt;mancom&gt; is there anything new on Q or feedspace?</p>
16:50 <+postman> nickless_head: hey, he's mine - don't dare to stare at him like that :)</p>
16:50 <+nickless_head> I'm not staring at him .. I'm looking at him interestedly.</p>
16:51 < cervantes> After some deliberation I've revived the "Forum User of the Month" spot - and this month it deservedly has gone to Complication for outstanding forum contributions</p>
16:51 <+nickless_head> congratulations complication!</p>
16:51 <+postman> kudos :)</p>
16:51 < cervantes> so he gets an avatar (whether he likes it or not) :P</p>
16:51 <+Complication> Heh, I hope my blunders have been less outstanding. :O :D</p>
16:52 <@protokol> oh yeah</p>
16:52 < jrandom> w00t! thanks Complication </p>
16:52 < cervantes> (which is active now)</p>
16:52 <@protokol> hows that Yellow Submarine i2phex test going</p>
16:52 <@protokol> any notable speeds or lack thereof?</p>
16:52 <+Complication> It's going.</p>
16:52 < jrandom> mancom: nothing new regarding Q or feedspace</p>
16:53 <+Complication> No hyperfast speeds, but a guaranteed good-enough speed, I'd say.</p>
16:53 < jrandom> protokol: last i heard was 10-20KBps, but thats just stuff on the forum</p>
16:53 <@protokol> im downloading it right now</p>
16:53 * nickless_head understands what postman implied</p>
16:53 * nickless_head blushes</p>
16:53 <+Complication> (also: I re-read part of the tech intro, and couldn't find flaw with the network comparisons. I think they're good enough.)</p>
16:54 <+postman> nickless_head: LOL (sorry)</p>
16:54 * Complication looks at the avatar and grins :D</p>
16:54 <+nickless_head> postman: *GG* (no problem)</p>
16:54 < cat-a-puss> Has anything been done in an effort to get "Amazon honor system" as an alternate method of collecting donations?</p>
16:54 <+Complication> Spot on. :P</p>
16:55 <@protokol> cat-a-puss: what do you mean?</p>
16:55 < jrandom> not yet cat-a-puss, haven't seen wilde around</p>
16:55 < jrandom> woah, hey phedy</p>
16:55 < phedy> Hi jrandom.</p>
16:55 < cat-a-puss> protokol: it's like pay-pal, except you can use an account you have with amazon.com to make payment</p>
16:56 < jrandom> Complication: thanks re: the comparisons. there are a few cleanups left, but its coming along</p>
16:56 <@protokol> weak</p>
16:56 <+Complication> (not that I know Tor or Freenet in decent degree, although I've used both)</p>
16:57 * cat-a-puss is thinking of creating a bounty for helping finish the distributed search engine. </p>
16:57 < jrandom> (before putting the doc out on the normal website i'll run it by those folks for comment)</p>
16:58 < cervantes> Complication: it's an art installation on a roundabout in London that causes havoc with the traffic ;-)</p>
16:59 < jrandom> cat-a-puss: i've got to work out some other financial stuff soon anyway, so shall let you know asap</p>
16:59 < jrandom> ok, anyone else have anything to bring up for the meeting?</p>
16:59 < cat-a-puss> oh if we want documents translated to some other languages before 1.0, I may know people who could help with Spanish and Chinese.</p>
16:59 < cat-a-puss> ok</p>
16:59 < jrandom> kickass, that'd be great</p>
17:00 <+Complication> cervantes: thanks for telling, I wasn't aware where such an, umm... effect occurred :D</p>
17:00 < jrandom> there's a draft tech intro floating around in cvs, and we'll eventually want whatever our website redesign turns out to contain to be translated</p>
17:03 * nickless_head goes to sleep</p>
17:03 < jrandom> i suppose i should grab the baffer...</p>
17:03 < jrandom> if there's nothing else</p>
17:03 * jrandom winds up </p>
17:03 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

240
i2p2www/meetings/151.log Normal file
View File

@@ -0,0 +1,240 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 151{% endblock %}
{% block content %}<h3>I2P dev meeting, October 11, 2005</h3>
<div class="irclog">
16:29 < jrandom> 0) hi</p>
16:29 < jrandom> 1) 0.6.1.2</p>
16:29 < jrandom> 2) I2PTunnelIRCClient</p>
16:29 < jrandom> 3) Syndie</p>
16:29 < jrandom> 4) I2Phex</p>
16:29 < jrandom> 5) Stego and darknets (re: flamewar)</p>
16:29 < jrandom> 5) ???</p>
16:29 < jrandom> 0) hi</p>
16:29 <@cervantes> (6)</p>
16:29 <+postman> you mean 6)?</p>
16:29 < jrandom> yeah, i can't count ;)</p>
16:30 * postman high-fives cervantes </p>
16:30 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-October/000990.html</p>
16:30 < wiht> Questions should be item 6.</p>
16:30 < jrandom> since i'm 30 minutes late, y'all have already read through those notes, I'm sure, so lets get this underway ;)</p>
16:31 < jrandom> 1) 0.6.1.2</p>
16:31 <@cervantes> 6) Discuss jrandom's roommate's poor judgement in timing</p>
16:31 < jrandom> *cough* ;)</p>
16:31 < jrandom> ok, as mentioned in the email, the 0.6.1.2 release seems to be doing pretty well</p>
16:32 < jrandom> we've found the bug that had kept the irc servers back on an older build, and they're now up to date too (w00t!)</p>
16:32 <+postman> :)</p>
16:32 < wiht> Speaking of that, in the netDB on the router console, would it be possible to list the table with routers and their versions at the top of the page?</p>
16:33 < jrandom> the number of routers per version, right? sure, that could be done pretty easy, maybe integrate it into the peers.jsp table (showing per-peer version) and a new table at the bottom?</p>
16:34 < jrandom> its kind of nice seeing 9 versions playing well together, though of course newer ones work best</p>
16:35 < jrandom> ok, anyone else have something to bring up regarding 1) 0.6.1.2?</p>
16:35 <+postman> one of my routers shows 1080 known</p>
16:35 < jrandom> zounds</p>
16:35 <+postman> i think this is a bit off track?</p>
16:35 < jrandom> is that on 0.6.1.2?</p>
16:35 <+postman> yeah, think so</p>
16:36 < jrandom> hmm, yeah, thats a... bit high. i'm seeing about half that many right now</p>
16:36 <+Complication> Sustainably 400-ish here</p>
16:37 <+bar> same here</p>
16:37 < wiht> I see 260 known routers.</p>
16:37 < jrandom> postman: perhaps we can dig into whats going on in that router after the meeting (could you tar.bz2 me netDb/routerInfo-*?)</p>
16:38 <+postman> jrandom: yeah thanks</p>
16:38 < jrandom> gracias</p>
16:38 < jrandom> yeah, not everyone will see every netDb reference, so thats normal for there to be fluctuation</p>
16:40 < jrandom> ok, if there's nothing else on 1) 0.6.1.2, lets swing on over to 2) I2PTunnelIRCClient</p>
16:40 <@cervantes> nice one dust</p>
16:40 < jrandom> as mentioned in the email, we've got a new IRC-protocol-specific filter available in CVS, and it should be rolled out as the default in the next rev</p>
16:41 <+postman> cool</p>
16:41 < jrandom> yeah, this is very cool, people have been asking for something like it for ages</p>
16:41 <+Myo9> Jrandom, you have become more open recently, we have learned about your ex, and now your room mate, etc. Do recall: http://www.navysecurity.navy.mil/st031204.jpg</p>
16:41 < jrandom> *cough*</p>
16:42 < dust> if you wish to see what your client send you can add net.i2p.i2ptunnel.I2PTunnelIRCClient=INFO and then look at the logs to see it all</p>
16:43 < dust> i've tested some clients but there are many..</p>
16:43 < jrandom> yeah, i've been watching it for a lil bit, but the filtering seems sound</p>
16:44 < jrandom> there are some neat things we may be able to do in the future too - e.g. PING/PONG locally, to cut down on network activity</p>
16:44 <+Complication> dust: thanks for the "info" :)</p>
16:44 <+bar> awsome dust, thanks a lot</p>
16:44 < wiht> Does this mean we don't need to set up an extra IRC tunnel?</p>
16:44 < jrandom> wiht: no, you'll need an irc tunnel, but it can replace the one you use already</p>
16:45 <+Complication> wiht: just worry less about our IRC client giving away our ass</p>
16:45 < jrandom> postman/cervantes: any thoughts on increasing or removing the server ping/pong timeouts? </p>
16:45 < wiht> That explains it, thanks.</p>
16:46 <+postman> mmh, i would not remove them, my client completely freaked when i played around with it</p>
16:46 < jrandom> postman: well, i'm thinking if it responded to them locally, so the client would get a really, really fast PING/PONG</p>
16:46 <@cervantes> postman: the proxy could respond to pings</p>
16:46 < jrandom> (but the ping/pong wouldn't need to go over the network)</p>
16:47 < jrandom> i don't know the impact, but it may be worth looking into.</p>
16:47 <@cervantes> but I'm not sure how the servers would react, you might end up with a bunch of zombie clients</p>
16:47 <+postman> jrandom: well</p>
16:47 < jrandom> well, the streaming lib's keepalive should handle that</p>
16:47 * Complication has occasionally experienced zombification</p>
16:47 < jrandom> Complication: recently?</p>
16:47 <+postman> jrandom: if the proxy pings for the client, the proxy must ping/pong to the client as well</p>
16:48 <+Complication> A week ago, I think.</p>
16:48 < jrandom> postman: a PING from the client to the proxy would have the proxy respond directly to the client with a PONG without sending anything over i2p</p>
16:48 <+Complication> But my "copy" was dropped eventually.</p>
16:48 <@cervantes> jrandom: the connection would be held open...the servers would need to lower their threshold for deciding at what point a client is stale and need ejecting</p>
16:48 < jrandom> Complication: ah, the irc servers weren't up to date back then, shouldn't happen anymore</p>
16:49 <+Complication> Without me using "ghost". Recent uses of the ghost command have been due to operating with many nodes.</p>
16:49 <+postman> jrandom: and the lag measurement?</p>
16:49 < jrandom> cervantes: right. and/or if necessary, the proxy could inject an extra PING message to the server if it /needs/ one. </p>
16:49 <+postman> i find it quite useful to know if i am lagged or not</p>
16:49 < jrandom> postman: i do too, but you can always /msg yourself</p>
16:50 < dust> you could perhaps reduce the number of pings</p>
16:50 < jrandom> it would save a substantial amount of bandwidth, since tunnel messages are 1024byte blocks, sent over 2*k+1 hops</p>
16:50 < jrandom> that too</p>
16:50 < jrandom> i don't know, just an idea. what we have now is kick ass regardless </p>
16:51 <+postman> ok, i would try to patch a testserver</p>
16:51 <@cervantes> perhaps we could look into reducing the number...but I think we should still send some real pings do determine if the clients are still alive</p>
16:51 <+postman> maybe it works</p>
16:51 < jrandom> seems reasonable cervantes. i don't think it'd need any patching on the server, i hope?</p>
16:52 <+postman> jrandom: to deactivate maybe - but lowering the interval is conf parameter</p>
16:53 * postman chews on the ircd documentation ( again )</p>
16:53 < jrandom> cool, no rush. just something we can look into sometime</p>
16:53 <@cervantes> class servers</p>
16:53 <@cervantes> {</p>
16:53 <@cervantes> pingfreq 120;</p>
16:54 <@cervantes> class clients { pingfreq 90 }</p>
16:54 <@cervantes> that's my current config</p>
16:54 <+postman> cervantes: yes, i know - the question is if it can be deactivated at all</p>
16:54 <@cervantes> I wouldn't deactivate them...just look into reducing them</p>
16:55 <+postman> ok, let's start with that</p>
16:55 <+postman> cervantes: how about 180 secs?</p>
16:56 <@cervantes> in at the deep end with 240</p>
16:56 <@cervantes> but perhaps we should ge tthe ircproxy side of things ready first</p>
16:57 <@cervantes> *discuss after meeting*</p>
16:57 <+postman> agreed</p>
16:57 < jrandom> w3rd. ok, anything else on 2) I2PTunnelIRCClient, or shall we move on to 3) Syndie?</p>
16:57 <@cervantes> anything to reduce my current 40kb/sec average router traffic ;-)</p>
16:58 < jrandom> heh, for some reason i doubt thats all irc ;)</p>
16:58 < jrandom> ok, movin' on</p>
16:59 * cervantes hides is pony video downloads he's been leeching from jrandom all week</p>
16:59 <@cervantes> is=the</p>
16:59 <+postman> LOL</p>
16:59 < jrandom> as mentioned in the mail, there's some pretty cool stuff going on with syndie</p>
16:59 < jrandom> the cli is trivial, but dust's new Sucker looks really promising</p>
16:59 < jrandom> dust: wanna give us a rundown?</p>
17:00 < dust> oh,</p>
17:01 < dust> well, it uses rome for parsing the feeds and then converts it to sml, like described in jrandoms blog</p>
17:02 < dust> it's not what you'd call robust yet, but it's only two days old :)</p>
17:02 < dust> i've got some dilbert in my syndie..</p>
17:02 < dust> :)</p>
17:02 < dust> .</p>
17:02 < jrandom> nice</p>
17:03 < jrandom> ok, what are your thoughts on where its going - should we toss it into the syndie source and expose it as a cli, or keep it separate and distribute it independently, or something else?</p>
17:04 * dust don't know, you decide</p>
17:04 < dust> the less separate tools the better</p>
17:04 < jrandom> yeah, probably easier to bundle it all together, that way everyone knows they can use it</p>
17:05 < jrandom> we'd then be able to do things like integrate it into the web interface, and maybe into Ragnarok's scheduler (syndicating with other nodes and pulling from rss/atom/etc)</p>
17:07 < jrandom> ok, anyone have any questions/comments/concerns on 3) Syndie?</p>
17:07 < wiht> If you keep integrating software into I2P, it may become a bloated software package.</p>
17:07 < wiht> Of course, I can turn off Syndie if I am not using it.</p>
17:08 < jrandom> the i2p sdk 13KLOC</p>
17:08 < jrandom> and the i2p router is only 22KLOC</p>
17:08 < jrandom> but yeah, there is an impact on download times of the install</p>
17:09 < jrandom> if someone wanted, they could build a stripped down router with no client apps, using just the router.jar, jbigi.jar, and i2p.jar</p>
17:09 < wiht> Yes, I was referring to the download.</p>
17:09 < jrandom> (but its much more useful when there's a web interface to control it, and i2ptunnel, and the streaming lib, etc ;)</p>
17:11 < jrandom> smeghead was working on a distribution system (like emerge, for java), and there's the jpackage folks too</p>
17:11 < jrandom> if someone wants to look into a seamless and reliable way to manage the apps without bundling, it'd be pretty cool</p>
17:12 < jrandom> ok, if there's nothing else on that, lets jump on over to 4) I2Phex</p>
17:13 < jrandom> I don't really have much to add beyond whats in the status notes</p>
17:13 < jrandom> redzara: you around?</p>
17:13 <+redzara> yes i'm</p>
17:13 <+redzara> I'm already working on the next version, while waiting for the meeting with Gregor.</p>
17:13 < jrandom> ah great</p>
17:13 <+redzara> Work, for the moment, primarily consists in identifying the differences and the needs related to the use of I2P such as for example tcp/udp vs i2p, management of the parameters specific to I2P (and management of the update of these same parameters at the time of the next versions, ...) port of GWebCache to I2P, use RSS or not, use push or not... </p>
17:14 <+redzara> I have much documentation and code to read</p>
17:15 < jrandom> wow, yeah, sounds like a lot. let me know if you've got any questions regarding i2p integration, or if you just want someone to bounce ideas off</p>
17:16 < jrandom> getting the I2Phex part into a plugin for the mainline Phex would be really kickass</p>
17:17 < jrandom> ok, anyone else have anything for 4) I2Phex?</p>
17:18 <+redzara> I would need certainly assistance for the petname part</p>
17:19 <+redzara> and maybe too for fine tunning tunnels's parameters</p>
17:19 < jrandom> cool, the naming is pretty easy - at a basic level, you could even get by without using names at all (this is how I2Phex does it now)</p>
17:20 < jrandom> tunnel config shouldn't be a problem either, though that brings up the idea that maybe Phex would need an "advanced configuration" section for plugins</p>
17:20 < jrandom> (we'd obviously want to have good defaults anyway)</p>
17:21 <+redzara> maybe something like ircclient, an filter to be sure</p>
17:22 <@cervantes> better to get the app in shape imho</p>
17:22 < jrandom> that might work, though dealing with arbitrary byte sequences may be tough</p>
17:23 < jrandom> though, a proxy like ircclient might be able to allow any gnutella client to use it. but it'd be a bunch of work.</p>
17:23 <+redzara> humm, it's just an idea ;)</p>
17:23 * jrandom doesn't know the protocol well enough to say what the best approach is, so suggest going with the simplest thing that could possibly work :)</p>
17:25 < jrandom> ok, if there's isn't anything else, perhaps we can swing through 5) stego and darknets briefly</p>
17:26 < jrandom> i'm not sure if there's anything i have to add beyond whats being said on the list (and major discussion should probably continue there)</p>
17:27 < jrandom> that said, is there anything people want to bring up about the issues raised?</p>
17:27 < wiht> Freenet version 0.5 and 0.7 were mentioned in the discussion. Is there a version 0.6 for Freenet?</p>
17:27 < jrandom> 0.6 is their current "unstable" branch of the network</p>
17:27 < jrandom> afaik</p>
17:27 <+postman> ohh and i thought it has been stolen by alien forces</p>
17:28 < jrandom> while blaming the aliens is usually a safe bet, this is one of the few instances where they're not at fault</p>
17:28 <+postman> :)</p>
17:28 < wiht> Toad was talking about being able to harvest the IP addresses of I2P or FreeNet nodes, right?</p>
17:28 < jrandom> among other things</p>
17:29 < wiht> Just wanted to clarify that, thanks.</p>
17:29 < jrandom> np. ok, anyone else have anything on 5), or shall we move on over to the good ol' fashioned 6) ???</p>
17:30 <+postman> ok, i got one for 6)</p>
17:30 < jrandom> consider us moved.</p>
17:30 < jrandom> whats up postman?</p>
17:30 <+postman> we all have seen that protocol specific filter capable proxies are good and needed</p>
17:31 <+postman> would it be feasable to invest thinking in a generic proxy</p>
17:31 <+postman> that can be fed with a protocol description</p>
17:31 <+redzara> I would like to have an application like cron using beanshell to run code java code dynamically</p>
17:31 <+postman> along with stuff to watch for/filter/disguise</p>
17:31 <+postman> like a filter/sanitize xml description </p>
17:32 <+postman> so that we dont need new source but just a new filter file/profile</p>
17:32 <+postman> (just a question if its worth to think about it)</p>
17:32 < jrandom> very, very complicated postman. it'd be possible to use a lexer like javacc to build input languages and an app to translate that language into the output format</p>
17:32 <@cervantes> it's catching the stuff that deviates from the protocol that's tricky</p>
17:33 <+postman> it was just an idea to trigger a process of brainstorming</p>
17:33 <+postman> imho something like a generic proxy with modeled filter/parser is very usable</p>
17:33 < wiht> Has anyone been able to connect to eepsites.i2p? I have tried several times over the past week, but was always unsuccessful.</p>
17:33 < jrandom> wiht: i loaded it once, its the same as eepsites.com</p>
17:34 < jrandom> (or is it .net? or .org? i forget)</p>
17:34 * wiht visits eepsites.com</p>
17:34 < jrandom> postman: if someone could come up with something that'd work, that'd kick ass</p>
17:34 <+postman> jrandom: ok, i'll do some thinking together with susi</p>
17:34 < jrandom> w3wt</p>
17:34 <+postman> jrandom: maybe we'll drop it next week </p>
17:35 < wiht> It is eepsites.com, and it is a search engine for eepsites.</p>
17:35 <+postman> but i had a dream that it worked</p>
17:35 <+postman> :]</p>
17:35 < jrandom> :)</p>
17:36 * Complication suspects that descibing all the subtleties which occur in protocols... requires code, and nothing less than code</p>
17:36 <+Complication> (for most protocols, at least)</p>
17:36 <@cervantes> nah just some eeevul regex</p>
17:36 <+postman> Complication: maybe this suspicion is the reason that keeps us from further investigation</p>
17:37 <+postman> Complication: i am not yet sure, but suspicion alone will not put me to rest on that matter</p>
17:37 < jrandom> well, an important point here is something dust demonstrated for us -</p>
17:37 * Complication fears a regex capable of such things</p>
17:37 < jrandom> code isn't necessarily that scary.</p>
17:37 <+postman> see? :)</p>
17:37 <+postman> a good filter modelling language will do the same</p>
17:38 <+postman> :)</p>
17:38 <@cervantes> tcl? :)</p>
17:38 <+Complication> It would have to be good.</p>
17:38 * jrandom sees that you've got your own flying ponies too postman ;)</p>
17:38 * dust also felt bad about duplicating code here and there</p>
17:38 <+postman> jrandom: no cows :)</p>
17:38 < jrandom> working code &gt;&gt;&gt; theoretical improvements in code </p>
17:39 <+postman> mmh</p>
17:40 <+postman> one thing i learned from i2p</p>
17:40 < wiht> &gt;&gt;&gt; means "much, much better?"</p>
17:40 <+postman> do not give up on first looks</p>
17:40 < jrandom> true enough postman </p>
17:40 < jrandom> yes wiht </p>
17:41 < jrandom> it would be really cool</p>
17:41 < jrandom> ok, anyone else have something to bring up for the meeting?</p>
17:41 <+bar> well, how's the IMAP working, postman? (i read about it in the forums but haven't tried it yet myself)</p>
17:41 <+postman> bar: try it yourself - i have no user reports yet</p>
17:41 * cervantes rolls in the pony shaped gong</p>
17:42 <+bar> ok, will do :)</p>
17:42 <+postman> bar: and for me it works FINE :)</p>
17:42 < jrandom> nice</p>
17:42 <+bar> cool</p>
17:42 <+postman> cervantes: you're fixated</p>
17:42 <@cervantes> me?!</p>
17:42 <@cervantes> :)</p>
17:43 < jrandom> ok, before we reach the 90 minute mark</p>
17:43 * jrandom winds up</p>
17:43 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

276
i2p2www/meetings/152.log Normal file
View File

@@ -0,0 +1,276 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 152{% endblock %}
{% block content %}<h3>I2P dev meeting, October 18, 2005</h3>
<div class="irclog">
16:10 < jrandom> 0) hi</p>
16:10 < jrandom> 1) 0.6.1.3</p>
16:10 < jrandom> 2) Freenet, I2P, and darknets (oh my)</p>
16:10 < jrandom> 3) Tunnel bootstrap attacks</p>
16:10 < jrandom> 4) I2Phex</p>
16:10 < jrandom> 5) Syndie/Sucker</p>
16:10 < jrandom> 6) ???</p>
16:10 < jrandom> 0) hi</p>
16:10 * jrandom waves</p>
16:10 < jrandom> weekly status notes are up at http://dev.i2p.net/pipermail/i2p/2005-October/001017.html</p>
16:10 < dust> yay, works now. thanks Gregor</p>
16:10 < cervantes> hullo</p>
16:11 <+fox> &lt;blx&gt; heloa</p>
16:11 < jrandom> ok, jumping into 1) 0.6.1.3</p>
16:11 < jrandom> y'all have updated at a pretty good clip, thanks! </p>
16:12 < jrandom> things seem to be in reasonable condition, but I don't have much to add beyond whats in the status notes</p>
16:12 < jrandom> anyone have any questions/comments/concerns re: 0.6.1.3?</p>
16:13 < jrandom> ok if not, lets jump on in to 2) Freenet, I2P, and darknets (oh my)</p>
16:13 < cervantes> 609 known peers!</p>
16:14 < cervantes> (w00t)</p>
16:14 < jrandom> aye, network has been growin'</p>
16:14 <+fox> &lt;blx&gt; oh my!</p>
16:14 * cervantes is holding a sweepstake for how long until the big 1000</p>
16:14 < jrandom> heh</p>
16:14 < tethra> heheh</p>
16:15 < tethra> are we betting with digital cash? ;)</p>
16:15 < cervantes> but it show how solid i2p core has got lately that the user uptake has been accelerating</p>
16:16 < cervantes> nah...jrandom has already unknowningly donated all his beer money for this year</p>
16:16 < jrandom> hehe</p>
16:16 < jrandom> ok, on 2), i'm not sure if i've got anything else to add to the subject (i think we've flogged that horse). anyone have any questions/comments/concerns on it?</p>
16:18 < cervantes> as you said, if nothing else it has stimulated some interesting semi-related security discussions ie 3)</p>
16:18 < jrandom> if not, we can jump forward at a quick pace to 3) Tunnel bootstrap attacks</p>
16:18 < jrandom> aye, that it has</p>
16:19 < jrandom> the issue Michael brought up quantifies a general view i've had, but its nice to make it explicit</p>
16:20 < jrandom> there's going to be some further discussion on the newer attack later this evening (once i can write up a reply), but the former doesn't seem to be much of a problem</p>
16:21 < jrandom> does it make sense to people, or do people have any questions or concerns about it?</p>
16:22 < cervantes> heh...that either means everyone is cool with it or they can't make head of tail of what the issues are</p>
16:23 < cervantes> I'll put myself in the ignorance is bliss category</p>
16:23 < jrandom> heh its basically an attack where the mean guys just happen to be the outbound endpoint of every tunnel you've ever built</p>
16:23 < jrandom> now, when you're just starting up, "every tunnel you've ever built" is a very small number (eg. 0, 1, 2)</p>
16:24 < jrandom> but after a few seconds, the number grows large enough to turn (c/n)^t into a really really small number</p>
16:25 < tethra> (c/n)^t is...</p>
16:25 < jrandom> (this is one of the reasons why we don't start up the i2cp listener - and hence, i2ptunnel/etc - until a little while after startup)</p>
16:25 < jrandom> c == # of colluding peers (bad guys), n == # of peers in the network, t == # of tunnels you've built.</p>
16:25 < cervantes> right...</p>
16:25 < tethra> ah</p>
16:26 < jrandom> so as t grows, the probability of successful attack gets really small</p>
16:26 < cervantes> so for it to be even viable you'd have to start using your router for sensitive tasks within a couple of minutes of it starting up?</p>
16:26 < jrandom> (or, in any case, smaller than the probability of taking over all hops in a tunnel)</p>
16:26 < tethra> ahh, i see</p>
16:27 < jrandom> cervantes: immediately, before the 3rd tunnel is built</p>
16:27 < jrandom> (assuming you use 3 hop tunnels)</p>
16:27 < cervantes> that's fairly improbable</p>
16:28 < cervantes> just from a use case perspective</p>
16:28 < jrandom> 'zactly.</p>
16:28 < jrandom> and since we build more than 3 tunnels on startup before letting any clients run, its not just a probability issue</p>
16:28 < jrandom> but its good to quanitify the attack anyway</p>
16:29 < cervantes> is it worth letting the router churn for a bit longer to guard against any likelyhood?</p>
16:30 < cervantes> or churn harder...</p>
16:30 < jrandom> perhaps. if we ignore connection establishment time as well as nonrandom peer selection, it has no likelihood</p>
16:31 < tethra> that's cause for a "woot!" i take it?</p>
16:32 < jrandom> aye, though from an engineering perspective, we shouldn't ignore those characteristics ;) </p>
16:32 < jrandom> so, for 0.6.2 we may want to look at it during the revamped tunnel peer selection / ordering implementation, to make sure its behaving Sanely</p>
16:34 < jrandom> ok, if there's nothing else on 3), lets move on to 4) I2Phex</p>
16:34 < jrandom> sirup isn't here, and i haven't seen striker on irc - redzara, you around?</p>
16:36 <+redzara> yes</p>
16:36 <+redzara> First pass is nearly completed : port Sirup's mod to lastest phex cvs.</p>
16:36 < jrandom> nice1!</p>
16:36 <+redzara> next : Second pass : diff from Sirup code to base phex code used in initial release, to be sure i don't forget anything :)</p>
16:37 <+redzara> maybe terminated for this W.E.</p>
16:37 < jrandom> wow that'd be great</p>
16:37 <+redzara> Pass three : refactoring comm layer with GregorK</p>
16:37 <+fox> &lt;GregorK&gt; hope you are aware that in latest Phex CVS the download code is not stable and the download file is not compatible with previous releases</p>
16:38 < jrandom> this is i2p, we're used to instability :)</p>
16:38 <+fox> &lt;GregorK&gt; :)</p>
16:38 <+redzara> For the last pass, as I've currently no contact with GregorK, this sould be pretty hard :(</p>
16:38 < jrandom> GregorK: what would you recommend for inegration?</p>
16:39 <+fox> &lt;GregorK&gt; well you now have contact with me ;)</p>
16:39 < jrandom> ah 'k redzara, the first two are big enough in any case :)</p>
16:39 <+redzara> GregorK : hi man</p>
16:40 <+redzara> GregorK : I've read carefully all codes</p>
16:40 <+fox> &lt;GregorK&gt; I have a idea on how to build a layer... I can try to prepare it as good as i can and then we can see how good it fits and what needs to be changed</p>
16:40 <+fox> &lt;GregorK&gt; all?? wow...</p>
16:40 <+redzara> Gregork : yes, all !!</p>
16:41 < cervantes> he even knows the size of your underwear</p>
16:41 < Rawn> :D</p>
16:41 <+fox> &lt;GregorK&gt; great... next time I'm shopping I just need to ask you... </p>
16:43 <+fox> &lt;GregorK&gt; what would be nice if we could maybe have someone from the i2phex team on the phex team too..</p>
16:43 < jrandom> redzara: so, do you think we'll have a 0.1.2 I2Phex release with the results of your second pass before we get everything merged into a plugin layer in the mainline Phex? or will that be all in one go?</p>
16:43 <+redzara> Sorry, but I don't understand / speak /read / write english good enough to laugh with what you have writed</p>
16:43 <+fox> &lt;GregorK&gt; this would also help solve bugs that are on both sides</p>
16:44 < jrandom> GregorK: hopefully we'll find a way that the I2P side is just a thin plugin in Phex though, right?</p>
16:44 < jrandom> or do you think the two should stay separate?</p>
16:44 <+redzara> jrandom : I think we could have an Phex 2.6.4 over I2P, for me I2Phex is down</p>
16:45 < jrandom> down?</p>
16:45 <+fox> &lt;GregorK&gt; i'm not sure if we can make it this way right from the start, but I think the major part of it could be separated into a plugin.</p>
16:45 < jrandom> cool, yeah, its a lot of work, I'm sure</p>
16:46 < jrandom> especially when you look at things like java.net.URL (which leaks DNS requests on instantiation, etc)</p>
16:46 <+redzara> jrandom : down, endded</p>
16:46 <+Ragnarok> grr</p>
16:47 < jrandom> ok right redzara, one we can get everything working in Phex 2.6.4 over I2P, I agree, there wouldn't seem to be much of a need for an I2Phex</p>
16:47 <+fox> &lt;GregorK&gt; right... I think Phex uses the apache URI class in some places to work around this.. but only when necessary</p>
16:48 < jrandom> ah right, I remember playing around with that library, looks good</p>
16:49 < jrandom> we'll definitely be helping audit things a bit for anonymity/security before pushing it for end users over i2p</p>
16:49 < jrandom> (not to suggest there are any problems in Phex, just there are problems in every app, and hopefully we can help sort 'em out)</p>
16:50 <+fox> &lt;GregorK&gt; for some things like Socket use and these things I have an idea on how to integrate it smothly... but other places like different features UDP and such... I'm not sure yet how to solve them best</p>
16:50 <+fox> &lt;GregorK&gt; oh i'm sure there are many problems in phex. :)</p>
16:50 < jrandom> ah, yeah sockets will be easy, but we may need to disable other things. what is udp used for - quick queries?</p>
16:51 <+fox> &lt;GregorK&gt; currently only bootstrapping</p>
16:51 <+fox> &lt;GregorK&gt; UDP Host Cache.. a replacement for GWebCache</p>
16:52 < jrandom> ahhh, ok. </p>
16:52 <+redzara> So we don't need it if we have a descent GwebCache ?</p>
16:53 <+fox> &lt;GregorK&gt; yes... but the standard GWebCache have there security problems too...</p>
16:53 <+redzara> GregorK : not inside I2P I think</p>
16:54 < jrandom> oh, that part could be overcome - I2PSocket is authenticated - you know the 'destination' of the peer on the other end, so they couldn't say "I'm, er... whitehouse.gov.. yeah!"</p>
16:54 < jrandom> but you're right, its soemthing that needs to be verified </p>
16:54 <+fox> &lt;GregorK&gt; also firewall to firewall transfers would be a UDP topic we like to implement once we find a volunteer :)</p>
16:54 < jrandom> ah, well, I2P doesn't need firewall to firewall transfers - I2P exposes an entirely open end to end address space :)</p>
16:55 < jrandom> but... ooh, thats something that might be useful</p>
16:55 < jrandom> if Phex users had "0 hop tunnels", they'd get free NAT traversal/firewall to firewall transfers with pretty decent speed</p>
16:55 <+fox> &lt;GregorK&gt; another one would be LAN broadcasts of queries and such... for easier sharing of contents in private networks</p>
16:56 < jrandom> (0 hop tunnels offers a level of plausible deniability without requiring any intermediary peers to carry the trafffic)</p>
16:57 < jrandom> hmm, lan broadcast is good, though i'm not sure if i2p would really need that (since its an anonymity risk to know where the other peer is :), so perhaps that feature could be disabled when using the I2P plugin?</p>
16:58 < cervantes> *disabled by default</p>
16:58 <+fox> &lt;GregorK&gt; well its not available yet.. but in this case user usually know each other anyway to build that private network..</p>
16:58 < jrandom> oh right cervantes </p>
16:58 < jrandom> right right GregorK</p>
16:59 <+fox> &lt;GregorK&gt; are there any changes regarding the user interface??</p>
17:00 <+bar> well, we won't need flags :)</p>
17:00 < jrandom> at the least, the ability to have a few configuration options related to I2P would be useful.</p>
17:01 < jrandom> i think sirup was able to switch in some of the display to use I2P 'destinations' instead of showing IP + port numbers, so I think it was fine </p>
17:01 <+redzara> And what about bitzyNot for the moment, but flags and countries are unused</p>
17:01 < jrandom> bitzy?</p>
17:01 <+redzara> sorry, wrong coupy/paste :(</p>
17:02 <+fox> &lt;GregorK&gt; can you provide a list of configuration options and optional features you need?</p>
17:03 < jrandom> I'm sure we can get those to you. a host+port that I2P is running on and a few drop downs regarding performance/anonymity tweaks should do it</p>
17:03 < jrandom> we'll get you the details though</p>
17:02 <cervantes> [x] Super transfer speed mode</p>
17:02 <+fox> &lt; GregorK&gt; well bitzi is used to identify files.. is that an anonymity problem?</p>
17:03 < vulpine> &lt;redzara&gt; GregorK : I'm preparing it, but basicly, thre is no changes</p>
17:03 <+fox> &lt; GregorK&gt; :) ask your provider cervantes...</p>
17:03 <redzara> GregorK : maybe, I'm working on it</p>
17:04 <cervantes> GregorK: heh UK resident....no chance ;-)</p>
17:04 <+fox> &lt; GregorK&gt; if you transfer files between 2 Phex instances on the same PC.. transfers are lightning fast ;)</p>
17:05 <cervantes> cool...I have lots of cool movies I can share with myself :)</p>
17:05 <cervantes> * strike that from the meeting notes *</p>
17:06 <bar> jrandom touched the subject before, but, here's that crazy idea again:</p>
17:06 <+bar> how 'bout integrating i2p into Phex, so that ordinary users have 0-hop tunnels?</p>
17:07 <+fox> &lt;GregorK&gt; I think display of flags and IP+port comes from the HostAddress object.. which would be hidden from the new layer.. so you can display something else</p>
17:07 <+bar> (for plausible deniability and udp firewall hole punching)</p>
17:08 <+fox> &lt;GregorK&gt; not sure if I really understand what that means ;)</p>
17:08 <+bar> probably me neither ;)</p>
17:09 < jrandom> GregorK: essentially, it means that Phex users would talk to each other directly, but would get plausible deniability, as they could be talking indirectly</p>
17:09 <+bar> jrandom, i'm sure you're catching my drift here, could you elaborate?</p>
17:09 < jrandom> they'd also get I2P's NAT traversal thrown in for free, as well as data security and protection from sniffing by ISPs/etc</p>
17:09 <+redzara> GregorK : so you have to strip all code related to host+port + IsLocalIP + Is PrivateIP + ...</p>
17:10 < jrandom> on the other hand, (a BIG other hand), it wouldn't be able to talk to gnutella clients that don't run on top of I2P</p>
17:10 < jrandom> (though eventually, they all will ;)</p>
17:10 <+fox> &lt;GregorK&gt; Well I think the first step is - and that step is already big enough - to bring i2p and phex closer together.</p>
17:10 < jrandom> agreed</p>
17:10 <+bar> (damn, didn't think of that)</p>
17:11 <+bar> yeah, def.</p>
17:11 < jrandom> this is flying pony stuff. lets get the practical things first</p>
17:11 <+fox> &lt;GregorK&gt; and after we see how good that worked we can decide how we go further.. </p>
17:11 < jrandom> exactly</p>
17:12 <+fox> &lt;GregorK&gt; redzara: I like to have two implementations of HostAddress one for i2p and on like the current.</p>
17:14 <+redzara> Gregork : no pb, I've commented all code in my mod you could easyly build two implementations. Just let me finish the initial work please</p>
17:14 <+fox> &lt;GregorK&gt; sure.. no problem..</p>
17:14 < jrandom> :) ok, so redzara, you think we may be able to get an alpha test of the new Phex-2.4.2 based version sometime next week?</p>
17:15 < jrandom> (for the phase 2 part. your phase 3 will take more work integrating with the mainline)</p>
17:15 <+redzara> jrandom : next sems to be ok for me</p>
17:16 < jrandom> ok great</p>
17:16 <+redzara> s/next/next week/</p>
17:16 < jrandom> ok, this is pretty exciting stuff, it'll be wonderful to get it going smoothly </p>
17:17 < jrandom> does anyone have anything else to bring up for 4) I2Phex, or shall we move on briefly to 5) Syndie/Sucker?</p>
17:17 < cervantes> I2P will surely benefit from such killer apps</p>
17:18 <+fox> &lt;GregorK&gt; btw there is a Phex CVS mailing list for all CVS changes in Phex... if that is of any help</p>
17:18 < jnymo> *ehem*.. hell yes</p>
17:18 < jrandom> ok great, thanks GregorK</p>
17:18 < jrandom> definitely cervantes </p>
17:19 < jrandom> ok, on 5), I don't really have anything to add beyond whats there</p>
17:19 < jrandom> dust: are you around?</p>
17:19 <+redzara> GregorK : Thanks but handlingone version is far enough for me :)</p>
17:19 < jrandom> hehe redzara </p>
17:19 < dust> I haven't had much spare time lately, but if I do I'm thinking I'll try to get a handle on this addresses.jsp thing, add 'RSS' in the protocol dropdown in there and then build a path through Updater, Sucker to BlogManager.</p>
17:20 < dust> unless anyone have a better idea</p>
17:20 < jrandom> kickass</p>
17:20 < jrandom> that sounds perfect.</p>
17:21 < jrandom> though, hmm, maybe it'd need an additional field (the "what blog to post it in" and "what tag prefix")...</p>
17:21 < jrandom> maybe a separate form/table would make sense, though maybe not</p>
17:22 < dust> oh, I thought addresses.jsp was for one blog only (since you have to login to get there?)</p>
17:22 < jrandom> ah, true, good point</p>
17:23 < jrandom> the updater part is kind of fuzzy, but you're right</p>
17:23 < dust> (we'll figure it out when we get there)</p>
17:23 < jrandom> aye</p>
17:24 * jnymo thinks www.i2p.net could start up a 'merchandise cafe' type thing</p>
17:24 < jnymo> with eyetoopie shirts that say "I am Jrandom" on them ;)</p>
17:24 * mrflibble is still catching up on the "flamewar", which seems to be spiraling into a proper flamewar :)</p>
17:24 < jrandom> heh jnymo </p>
17:25 < jrandom> yeah, there's a lot of content in that thread</p>
17:25 < jrandom> ok, maybe this gets us to 6) ???</p>
17:25 < jrandom> anyone have anything else to bring up for the meeting?</p>
17:25 <+bar> aye, just a quick note on the symmetric nat issue (been doin a lil snoopin'):</p>
17:25 <+nickless_head> jrandom: I know the truth!</p>
17:25 <+fox> &lt;blx&gt; kaffe?</p>
17:25 < mrflibble> oops, sorry jr</p>
17:26 < jnymo> but seriously.. every open source project of any size has their own merchandise section</p>
17:26 <+nickless_head> jrandom: I have definite proof you hacked the last.fm homepage!</p>
17:26 <+nickless_head> (the what you get when you sign up section listed 'a pony')</p>
17:26 < jrandom> jnymo: i think you're right, we will want to explore that avenue, might be a good method of fundraising too</p>
17:27 < jnymo> jrandom: exactly</p>
17:27 * mrflibble would buy the tshirt</p>
17:27 <+bar> right, regarding symmetric nats,</p>
17:27 <+bar> for what it's worth, i think that unlike for the already supported nats, there's no magic trick. the only way to do it properly, is to study and examine each and every symmetric nat's behaviour and use introducers for probing.</p>
17:28 < jrandom> blx: the latest kaffe CVS is completely b0rked. the crypto packages aren't in the source, the prng fails to initialize, and the url handlers can't deal with file:// :(</p>
17:28 < jnymo> You probably wouldn't want to wear it in public until i2p has a few thousand users though ;)</p>
17:28 <+bar> (i believe this is how e.g. Hamachi and Skype do udp hole punching from behind symmetric nats)</p>
17:28 <+nickless_head> jnymo: cups would rule :)</p>
17:28 <+bar> based on what i have read on the 'net so far, symmetric nat prediction algos pretty much suck.</p>
17:28 < jrandom> hmm bar</p>
17:28 < mrflibble> hehe, i wouldn't put my nick on it. oh, and i'm still allive/unarrested even though i've got an IIP ttshirt</p>
17:28 < jrandom> yeah, thats what i read too</p>
17:29 <+bar> i will try gathering some more good, relevant reading material on this.</p>
17:29 <+redzara> Small question : what was the common average percentage of bytes retransmitted in 0.6.1.3 ?</p>
17:29 < jrandom> thanks bar</p>
17:29 <+fox> &lt;jme___&gt; bar, the prediction they got are consistent ? </p>
17:29 <+fox> &lt;jme___&gt; bar, let me rephrase :)</p>
17:29 <+fox> &lt;blx&gt; jrandom, i'm sad to hear</p>
17:30 < jrandom> redzara: I unfortunately forgot to put that into the netDb. I do see 2.6 and 3.8 right now though</p>
17:30 < jrandom> blx: me too :(</p>
17:30 <+fox> &lt;jme___&gt; bar, when you analyze the nat box behaviour and find a formula to predict it. does this always work for this nat box ? or later once it worked, once it fails ?</p>
17:30 < jrandom> blx: i know they're doing some merging with classpath now though, so hopefully once thats sorted</p>
17:30 <+fox> &lt;blx&gt; probably means i wont be joining the party</p>
17:30 < jrandom> blx: are you kaffe-specific, or OSS/DFSG-specific?</p>
17:31 <+fox> &lt;blx&gt; free software</p>
17:31 <+fox> &lt;blx&gt; dfsg you could say</p>
17:31 < jnymo> encase an i2p user wants to use a hosted server for i2p, what would be a liberal, cheap hosted services company to go with?</p>
17:31 <+bar> jme___: hamachi is reportedly able to mediate 97% of all connection attempts. i guess there are some nats out there that show an almost random behaviour when it comes to assigning ports</p>
17:32 < jrandom> ok, I'm sure we'll get something going blx. kaffe used to work, and we don't depend upon anything sun specific</p>
17:32 < jrandom> jnymo: i use sagonet.net, but they've cranked up their prices from 65/mo to 99/mo (but on a fast link w/ 1250GB/mo)</p>
17:32 < jrandom> i know there are some cheap ones in germany too</p>
17:33 <+fox> &lt;jme___&gt; bar, 97% would be terrific</p>
17:33 < jrandom> redzara: what are you seeing for retransmission rate?</p>
17:33 <+bar> jme___: yeah, so i guess most symmetric nats are predictable</p>
17:33 <+fox> &lt;blx&gt; jrandom, i sure hope so. i'm really interested in this shit :)</p>
17:33 <+fox> &lt;jme___&gt; bar, what would you do ? relay, udp hole punching, cnx reversal.. is there others thech ?</p>
17:33 < jnymo> is 99 expensive, on average?</p>
17:34 <+redzara> jrandom between 3;8 and 4.2</p>
17:34 < jrandom> jme___: we're udp, no need for connection reversal :)</p>
17:35 <+bar> jme___: i'm no expert, perhaps i'll have some more info for next week's meeting (but it sure smells like profiling + udp hole punching ;)</p>
17:35 < jrandom> jnymo: for 1250GB, not really. i've seen 60-120USD/mo for 50-100GB/mo</p>
17:35 < jrandom> bar: perhaps UPnP would be a better way to go?</p>
17:35 <+fox> &lt;jme___&gt; jrandom, even with udp it is usefull :)</p>
17:35 <+redzara> jrandom : but only some node done major impact, maybe some olders</p>
17:35 <+fox> &lt;jme___&gt; vulpine: ok</p>
17:35 < jrandom> though that only helps the people who could control their NAT</p>
17:36 <+fox> &lt;jme___&gt; upnp must be supported but it isnt exclusive to other means</p>
17:36 < jrandom> well, we're doing everything we do now without any UPnP</p>
17:36 <+fox> &lt;jme___&gt; because upnp isnt supported by all nat, far from it</p>
17:36 < jrandom> right, e.g. an ISP's nat</p>
17:36 <+bar> jrandom: if there are no security issues with upnp, i guess it can't hurt. though, hamachi doesn't use upnp</p>
17:36 <+fox> &lt;jme___&gt; here by 'must' = to provide the max connectivity</p>
17:37 <+fox> &lt;jme___&gt; ok going back to my c++ :)</p>
17:38 < jrandom> right jme___, though if we can do symmetric hole punching in addition to cone/restrited hole punching, we're in great shape</p>
17:38 < jrandom> l8s jme___</p>
17:38 < jrandom> yeah, it'd be ideal if we didn't need it</p>
17:39 < jrandom> ok, anyone have anything else to bring up for the meeting?</p>
17:41 < jrandom> if not...</p>
17:41 * jrandom winds up</p>
17:41 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

446
i2p2www/meetings/153.log Normal file
View File

@@ -0,0 +1,446 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 153{% endblock %}
{% block content %}<h3>I2P dev meeting, October 25, 2005</h3>
<div class="irclog">
16:24 < jrandom> 0) hi</p>
16:24 < jrandom> 1) Net status</p>
16:24 < jrandom> 2) Fortuna integration</p>
16:24 < jrandom> 3) GCJ status</p>
16:24 < jrandom> 4) i2psnark returns</p>
16:24 < jrandom> 5) More on bootstrapping</p>
16:24 < jrandom> 6) Virus investigations</p>
16:24 < jrandom> 7) ???</p>
16:24 < jrandom> 0) hi</p>
16:24 * jrandom waves</p>
16:24 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-October/001079.html</p>
16:25 * susi23 waves back</p>
16:26 < jrandom> lets jump on in to 1) net status</p>
16:26 < jrandom> as I mentioned, things look pretty reasonable so far. </p>
16:26 <+fox> &lt;Romster&gt; ah meeting sweet</p>
16:27 < jrandom> there is some good stuff coming down the line too, so we'll have a new release later this week</p>
16:27 < jrandom> anyone have anything they want to bring up regarding 1) net status?</p>
16:27 <@cervantes> omg 7 issues</p>
16:27 <+legion> yup looking good :-)</p>
16:27 < jrandom> busy week cervantes :)</p>
16:28 <@cervantes> can only be good</p>
16:28 <+Complication> Works relatively well, dev.i2p even - I can even pull CVS checkouts without EOF messages.</p>
16:28 < jrandom> nice :)</p>
16:28 <+Complication> Might have been release-related overloads, those last ones.</p>
16:28 <+Complication> But I can't tell.</p>
16:28 < jrandom> dev.i2p is on the latest build code too (-7), so it'll be hopefully performing substantially better than before</p>
16:29 < jrandom> s/dev.i2p/cvs.i2p (etc)/</p>
16:29 <+legion> forums.i2p also seems to be much better than before :)</p>
16:29 <@cervantes> *ahem*</p>
16:29 <+fox> &lt;Romster&gt; is i2p safe to let others join etc?</p>
16:29 <+Ragnarok> ok, now I've got to try this miraculous "cvs checkout that works the first time"</p>
16:30 <+fox> &lt;Romster&gt; since there is no known limits now</p>
16:30 <@cervantes> that's because everyone's hammering i2p-list instead of posting to the forum </p>
16:30 <+legion> hmm you sure cervantes?</p>
16:30 < jrandom> Romster: well, we've been growing at a pretty good pace lately, but we should hold off on public beta until 0.6.2</p>
16:30 < jrandom> heh cervantes ;)</p>
16:30 < jrandom> hush Ragnarok, you'll jinx it!</p>
16:31 <+Ragnarok> wow... it's true. I'm speechless</p>
16:31 <+fox> &lt;Romster&gt; k jrandom</p>
16:31 < jrandom> (man my eyes are watering from the curry my roomates are cooking downstairs)</p>
16:31 < jrandom> nice1 Ragnarok </p>
16:32 <+fox> &lt;Romster&gt; lol now that's a strong curry</p>
16:32 < jrandom> ok, if there's nothing else on 1), we can jump quickly through 2) Fortuna integration</p>
16:32 < jrandom> (true that Romster)</p>
16:32 <+fox> &lt;shardy&gt; yay for fortuna integration!</p>
16:32 <+fox> &lt;Romster&gt; moving onto 2) :P</p>
16:32 <+fox> &lt;Romster&gt; what is fortuna?</p>
16:32 < jrandom> heh thought you'd like that shardy :)</p>
16:32 <+fox> &lt;Romster&gt; i've been a bit behind the last month</p>
16:32 <+Complication> PRNG algo, if I remember.</p>
16:33 <+Complication> Supposedly a good one, or so they write. :P</p>
16:34 * Complication knows nothing about its inner workings, though</p>
16:34 < jrandom> shardy: I'd love if you could give it a look sometime</p>
16:34 <+fox> &lt;shardy&gt; of course</p>
16:34 <+fox> &lt;shardy&gt; you're using the gnu implementation?</p>
16:34 < jrandom> Romster/Complication: there are some links in the email</p>
16:34 < jrandom> yeah shardy - http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/gnu/crypto/prng/Fortuna.java</p>
16:35 < jrandom> (integrated with http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/net/i2p/util/FortunaRandomSource.java )</p>
16:36 < jrandom> we vary from the straight gnu-crypto implementation though, since we've already got AES256 and SHA256 code (Cryptix's and Bouncycastle's, respectively)</p>
16:36 < jrandom> ok, anyway, this looks cool, as we've been hacking through getting that support in there for probably a year now</p>
16:37 < jrandom> (fortuna integration was one of the main projects driving smeghead to build 'pants' ;)</p>
16:37 < jrandom> if anyone has any questions/comments/concerns about it, please bounce 'em to the list</p>
16:37 < jrandom> (or email, or forum, of course)</p>
16:38 <+fox> &lt;Romster&gt; yeah where is smeghead hes not been around for awhile now</p>
16:38 < jrandom> smeghead is [redacted] doing [redacted]</p>
16:39 < jrandom> ok, moving on to 3) GCJ status</p>
16:39 < jrandom> i2p works on GCJ! [w00t!]</p>
16:39 <+susi23> nice job</p>
16:39 <+legion> sweet</p>
16:39 < jrandom> at least, it does on GCJ 4.0.2 on linux 2.6.12. I haven't tried any other platforms</p>
16:40 < jrandom> yeah, the GCJ and GNU Classpath folks have worked wonders</p>
16:40 < jrandom> it was really easy to get it building, the old static reference classes I remember weren't necessary</p>
16:41 <+Complication> Which sounds quite positive, given Sun Java's less-than complete openness (with regard to distribution, if I remember correct).</p>
16:41 < jrandom> there's a makefile shipped with I2P now, though for simplicity, I think we'll probably stick with distributing pure java, at least primarily</p>
16:41 <+susi23> (next we try to run it on J2ME ;)</p>
16:42 <+fox> &lt;Romster&gt; GCJ to take over Suns JVM&gt;</p>
16:42 < cat-a-puss> how is preformance with GCJ?</p>
16:42 < jrandom> aye, though sun is entirely open, and we /could/ distribute their JVM along side I2P, but their license prohibits distributing their JVM as a general purpose tool</p>
16:42 < jrandom> cat-a-puss: comparable</p>
16:42 < jrandom> most of the heavy work in i2p is already done by assembler code ;)</p>
16:43 <+fox> &lt;Romster&gt; how would i2p go with C#/mono again with that jave to C# adition (forgot it's name)</p>
16:43 <+fox> &lt;Romster&gt; i remember jrandom and i both tryed it out ages ago</p>
16:43 < jrandom> no idea. but if it works with gcj, it might work with ikvm - the mono jvm thing</p>
16:44 <+Ragnarok> IKVM</p>
16:44 <+Ragnarok> nm</p>
16:44 <+fox> &lt;Romster&gt; ah tahts the one ikvm</p>
16:44 <+fox> &lt;Romster&gt; much difereances with GCJ and IKVM and Sun's?</p>
16:45 < jrandom> i've never used ikvm</p>
16:45 <+fox> &lt;Romster&gt; i'm sure you have once with mono or was that eclipse?</p>
16:45 <+fox> * Romster shrugs</p>
16:45 < jrandom> and i2p as shipped doesn't currently support the router console, though it does support the router operation, i2ptunnel, and sam</p>
16:46 <+Ragnarok> what's blocking the router console?</p>
16:47 <+susi23> xerces, when I remember correctly</p>
16:47 < jrandom> xerces stuff. the xercesImpl shipped with i2p has sun.* dependencies, and when I naively tried to drop in the latest xerces, getting that and jdom and rome and the rest of jetty GCJed was b0rking</p>
16:47 < jrandom> there are some additional requirements of the latest xerces, it seems</p>
16:48 < jrandom> (for jar files we don't currently ship). however, I'm sure we can track it down</p>
16:49 <+fox> &lt;Romster&gt; jrandom is good at tracking down problems :)</p>
16:49 < jrandom> even better at making problems</p>
16:49 <+fox> * Romster featches a coffee</p>
16:49 < jrandom> ok, anything else on 3) GCJ status?</p>
16:49 < jrandom> or shall we move on to 4) i2psnark</p>
16:50 < jrandom> consider us moved</p>
16:50 < jrandom> ok, i2psnark is back (yay)</p>
16:51 < jrandom> not much I have to add to whats in the mail... you have anything Ragnarok?</p>
16:51 <+Ragnarok> nope</p>
16:51 <+susi23> regarding web frontend</p>
16:51 <+Ragnarok> more testing would be nice though, so everyone should try it :)</p>
16:52 <+susi23> supporting it with susibt shouldn't be a problem</p>
16:52 < jrandom> ooh give us the scoop susi23 :) </p>
16:52 < jrandom> nice</p>
16:52 <+fox> &lt;jme___&gt; naive question, why spending time supporting old bt client while other (azureus) support full blown client ?</p>
16:52 < jrandom> jme___: azureus *is* kickass</p>
16:52 <+susi23> major release of susibt is scheduled for november :)</p>
16:53 < jrandom> heh cool susi23 </p>
16:53 <+Complication> To me, Azureus seemed terribly complex.</p>
16:53 <+Ragnarok> azureus blows monkey chunks</p>
16:53 <+susi23> for me, I always need a headless solution</p>
16:53 <+Ragnarok> not to put too fine a point on it</p>
16:53 <+fox> &lt;jme___&gt; ok :)</p>
16:53 < jrandom> jme___: azureus is a bit heavyweight though, but is a great general purpose bt solution</p>
16:53 <+Complication> (I personally could see the day I'd misconfigure something in it, and dent my anonymity.)</p>
16:54 <+fox> &lt;jme___&gt; it make sense, just wanted to know</p>
16:54 <+fox> &lt;Romster&gt; to me azerious never workd well i've moved to bitlord which does work</p>
16:54 < jrandom> i do still plan on helping further improve the azneti2p plugin with the azureus folks, but i2psnark took literally less than 2 hours before I was swarming data</p>
16:54 <+legion> Yeah azureus is just too big and complicated for i2p</p>
16:54 <+Complication> If the goal is bundling a bt client along with i2p, a lightweight client sounds best.</p>
16:54 <+fox> &lt;Romster&gt; KISS principal</p>
16:54 <+Ragnarok> I like the official client best, but i2psnark has the major advantage of being simple enough for me to hack on</p>
16:55 <+legion> thing is i2p doesn't need a heavyweight bittorrent client</p>
16:55 < jrandom> yeah, its really clean code (with oddball gnu formatting ;)</p>
16:55 <+Ragnarok> damn gnu</p>
16:55 <+Ragnarok> worst brace style ever</p>
16:55 < jrandom> heh</p>
16:55 <+fox> &lt;Romster&gt; heh code reformatter :)</p>
16:55 <+Ragnarok> jrandom won't let me :)</p>
16:55 <+Ragnarok> well, for good reason</p>
16:55 <+fox> &lt;jme___&gt; independance and simplicity are criteria i definitly agree with</p>
16:56 <+fox> &lt;Romster&gt; will there be options to enable the bt-torrent program on each i2p node?</p>
16:56 < jrandom> aye, it'd be nice if we can backport multitorrent, piece selection, and web capacity to mjw's mainline snark</p>
16:56 <+Ragnarok> the simpler it is, the more likely it will be maintained</p>
16:56 < jrandom> exaaactly Ragnarok </p>
16:57 <+legion> yeah backporting those would be killer</p>
16:57 <+fox> &lt;Romster&gt; as a OT point here take a look at emules KAD network i think it's rather neat.</p>
16:57 < jrandom> Romster: its now shipped with the build by default, but once we get it into susibt, it'll be on the top nav with the rest of the clients</p>
16:58 <+Ragnarok> we need to be able to ship a .torrent maker as well, though. And a tracker would be nice.</p>
16:58 < jrandom> yeah, actually, snark has both of those, I just disabled them because i didn't want to maintain 'em :)</p>
16:58 <+legion> hmm good point ragnarok</p>
16:58 < jrandom> but getting them back in wouldn't be much trouble</p>
16:59 <+Ragnarok> well, the torrent maker at least shouldn't be that bad</p>
16:59 < jrandom> there's a Tracker.java too, and handling in the PeerAcceptor, but I threw out what wasn't necessary, so one would probably want to look back at http://klomp.org/snark/ for those</p>
17:00 < jrandom> (and review http://dev.i2p/~jrandom/snark_diff.txt for changes)</p>
17:00 <+fox> &lt;Romster&gt; since snarik is back it'll get worked on right :)</p>
17:00 <+legion> actually when it comes to a tracker, it'd be better to come up with a distributed solution</p>
17:00 <+fox> &lt;Romster&gt; snark*</p>
17:00 < jrandom> porting code is easier than building a new distributed tracker legion ;)</p>
17:00 <+fox> &lt;Romster&gt; legion, your your talking</p>
17:00 <+legion> true, that</p>
17:01 < jrandom> but I wouldn't be opposed to integrating a nice clean maintained anonymity-friendly distributed tracker solution :)</p>
17:01 <+fox> &lt;Romster&gt; could be tacked onto the eepsites?</p>
17:01 * jrandom spots a flying pony go past the window</p>
17:01 <+Ragnarok> the official bt client has a kademlia based distributed tracker, but obviously that's only good as a design reference</p>
17:01 <+legion> a place to start ;)</p>
17:02 <+fox> &lt;Romster&gt; actually kademlia = emules KAD netowrk? hmm, if that's the case KAD would be ideal for a tracker but bootstraping is an issue</p>
17:03 <+Ragnarok> they're based on the same algorithm, but they're not in any way compatable</p>
17:03 <+Ragnarok> compatible, even</p>
17:04 <+Ragnarok> doing something like emule's KAD for i2phex would be sort of interesting...</p>
17:04 <+Ragnarok> anyway, flying ponies</p>
17:04 < jrandom> :)</p>
17:04 < jrandom> (agreed on both counts)</p>
17:04 < jrandom> ok, anything else on 4) i2psnark?</p>
17:05 <+Ragnarok> as long as we have something to make .torrent files, the existing trackers are fine</p>
17:05 < jrandom> thats a good point - there's some commented out code in Snark's main I believe</p>
17:05 <+legion> no I think the existing trackers are not fine :(</p>
17:05 < jrandom> whats wrong with them legion?</p>
17:05 < cat-a-puss> don't just hand uesrs a torrent file ether</p>
17:05 <+legion> often have trouble accessing them</p>
17:06 < jrandom> hmm cat-a-puss? oh, you mean, we need to get a web interface to transparently swarm?</p>
17:06 <+legion> sites get flooded with traffic</p>
17:06 < jrandom> ah, thats i2p's issue, hopefully 0.6.1.4 will improve that</p>
17:06 < jrandom> postman was telling me how he was getting tons of hits @ tracker.postman.i2p</p>
17:06 < jrandom> i forget the #s offhand</p>
17:06 < cat-a-puss> If we are handling both the swarming code and the code to get the torrent in the first place, might as well make it transparent for the user</p>
17:07 < jrandom> orion.i2p/bt/ isn't really used though</p>
17:07 < jrandom> (and tracker-fr seems lively)</p>
17:07 <+susi23> with susibt I hope to include trackers rss feed, so you don't need to go on the trackers webpage anymore but get the torrents downloaded automatically :)</p>
17:07 < cat-a-puss> also prevents confusing an i2p torrent with a non-anonymous one</p>
17:07 <+fox> &lt;jme___&gt; http tracker for bt doesnt scale due to poorely designed protocol</p>
17:07 <+fox> &lt;Romster&gt; router watchdog router hung hard restart wtf</p>
17:07 <+legion> right, which is my point some trackers are flooded while others are idle</p>
17:07 < jrandom> cat-a-puss: ah, yeah I'd love to integrate hooks from syndie into susibt :)</p>
17:07 <+fox> &lt;jme___&gt; it can be easily fixed but break the compatibility with official bt protocol</p>
17:08 <+fox> &lt;jme___&gt; it is the road followed by the dht tracker stuff</p>
17:08 < jrandom> (and the other way around, so people can easily syndicate .torrent files, etc)</p>
17:08 <+Complication> Romster: I get those, but the machine I get them on is borderline (300 MHz)</p>
17:08 <+fox> &lt;Romster&gt; the distributed tracker is the solution to hammered trackers</p>
17:08 < jrandom> legion: that can easily be remedied by people using different trackers :)</p>
17:08 <+fox> &lt;Romster&gt; azerius DHT</p>
17:08 < jrandom> code is expensive, using different URLs is cheap</p>
17:08 <+legion> yeah, but they don't seem to be doing that do they?</p>
17:09 < jrandom> but, yes, a distributed tracker would be great. not on my roadmap though, but if someone gets it going, that would Rule.</p>
17:09 <+Complication> In due time... surely someone can go distributed too.</p>
17:09 <+legion> Instead of of posting torrents to tracker sites, they could post a bith and whatever details to their eepsite.</p>
17:10 < jrandom> bith == hash?</p>
17:10 <+legion> yeah, stands for bittorrent hash, not my term</p>
17:10 <+Complication> In the beginning, though... a simple and solid client, in Java, bundled with the router... can solve many problems. (Perhaps even pull signed updates without overloading dev.i2p.)</p>
17:11 <+legion> yeah, that would be great</p>
17:11 < jrandom> aye Complication </p>
17:11 <+fox> &lt;Romster&gt; yeah torrent updates</p>
17:11 <+fox> &lt;Romster&gt; ok next item ont he list :)</p>
17:12 < jrandom> ok, 5) more on bootstrapping</p>
17:12 <+legion> yeah lets move on</p>
17:12 < jrandom> lots of interesting stuff on the list as of late, and no way am i going to summarize it all here :)</p>
17:12 <+fox> &lt;Romster&gt; bootstraping the i2p router database?</p>
17:12 < jrandom> anyone have any questions/comments/concerns they want to discuss about the thread?</p>
17:12 < jrandom> Romster: see the list and/or email</p>
17:12 <+fox> * Romster needs to read that list</p>
17:13 < jrandom> aye, there's good stuff on there :)</p>
17:13 <+fox> &lt;Romster&gt; i've been rather busy laterly</p>
17:13 <+Complication> 26 messages to read through, can't comment yet</p>
17:13 < jrandom> still no end result, but we're looking towards a new way of building tunnels for 0.6.2</p>
17:14 <+fox> &lt;Romster&gt; a new way, is there a flay in the current method?</p>
17:14 <+fox> &lt;Romster&gt; flaw*</p>
17:14 < jrandom> Michael's analysis shows the attack is not really a problem now, as there are easier attacks on the alternatives</p>
17:14 < jrandom> read the list ;)</p>
17:14 <+fox> &lt;Romster&gt; arg later</p>
17:14 <+fox> &lt;Romster&gt; this is now :)</p>
17:15 <+fox> &lt;Romster&gt; i'm noramlly asleep at this time.</p>
17:15 <+fox> &lt;Romster&gt; so i rearly get to be at a meeting</p>
17:16 < cat-a-puss> can you post your ideas for a new way / existing / rejected ways in an email to the list so we can compare</p>
17:16 <+fox> &lt;Romster&gt; so its todo with attack methods and tunnel creation i assume, without reading the list yet</p>
17:16 < cat-a-puss> (that's for Jrandom)</p>
17:16 < jrandom> cat-a-puss: i'm not sure if we've really hashed out an end result yet</p>
17:16 <+fox> &lt;Romster&gt; be an idea cat-a-puss</p>
17:17 <+Complication> Romster: yes, it was more-or-less about giving the endpoint of an exploratory tunnel less influence as a possible attacker</p>
17:17 < jrandom> but http://dev.i2p.net/pipermail/i2p/2005-October/001073.html is the latest for what I see coming out of your suggestion</p>
17:17 < jrandom> well, not influence - i2p is a free route mixnet - but less information</p>
17:18 <+Complication> Yes, that would likely be a more correct term</p>
17:18 < jrandom> (the above linked url is full of arm waving, no solid crypto figured out yet)</p>
17:18 <+fox> &lt;Romster&gt; lesss = better for more robustness agenst attacks, i get what your geting at</p>
17:18 < jrandom> ((but i think its all doable with existing techniques)</p>
17:19 < jrandom> Romster: here's a plot of Michael's attack against the existing algorithm, with the X axist saying what % of the network is compromised - http://dev.i2p.net/~jrandom/fraction-of-attackers.png</p>
17:20 < jrandom> (plain telescopic building would be off the chart before hitting x=200)</p>
17:20 < jrandom> ((so what we have now is literally orders of magnitude better))</p>
17:20 < jrandom> but we can improve upon that further</p>
17:21 < jrandom> though there's also the garlic routing alternative too</p>
17:21 < jrandom> anyway, yeah, more things to be hashed out, keep an eye on the list :)</p>
17:21 <+fox> &lt;Romster&gt; ok i'll have a good read of that list later</p>
17:22 <+fox> &lt;Romster&gt; and see if i can think of anything too add</p>
17:22 < jrandom> cool</p>
17:22 < cat-a-puss> would the "new" telescopic method be fast enough to do on demand construction?</p>
17:22 < jrandom> I'm not sure we want that</p>
17:22 < jrandom> its the O(1) vs O(N) issue</p>
17:23 < jrandom> the new technique would allow tunnel creation without using the exploratory tunnels, leavng the exploratory tunnels for netDb operation </p>
17:23 < jrandom> (and for exploratory tunnel creation :)</p>
17:24 <+fox> &lt;Romster&gt; hrmm would it be worthwhile screwing with the hackers by givving them heaps of false positives thereby masking the real source</p>
17:24 <+legion> sounds good :)</p>
17:24 <+legion> I'd think some screwing like that would be good</p>
17:24 < cat-a-puss> jrandom: right, I was asking if doing do would speed things up enough, so that sometimes that last hops don't know they are the last hop, as disguesed on list.</p>
17:25 <+fox> &lt;Romster&gt; exploratory tunnels to collect netDB router refereances?</p>
17:25 < jrandom> romster: we are the hackers ;) but yeah, if the false positives overwhelmed the true positives, it'd require substantially large number of attacks to get statistically significant data</p>
17:26 < jrandom> hmm right cat-a-puss, but I'm not sure how that'd speed things up though, it'd move us from an O(1) to O(N) tunnel topology</p>
17:26 < jrandom> or what do you mean by speed things up?</p>
17:26 <+fox> &lt;Romster&gt; and if it got to the point of being detected it could then drop off and go silent forawhile?</p>
17:26 < jrandom> using the new technique would reduce the failed tunnel creations, certainly</p>
17:26 <+fox> &lt;Romster&gt; or mistearly change it's key and continue or something heh</p>
17:26 < jrandom> romster: it'd probably be worth digging through the mails to review the attack ;)</p>
17:27 <+fox> &lt;Romster&gt; yeah after sleep</p>
17:27 <+Complication> Romster: afaik, it's a passive attack mostly, so the target can't detect it occurring</p>
17:27 <+fox> &lt;Romster&gt; and fixing a friends pc i got sitting here</p>
17:27 <+fox> &lt;Romster&gt; ah ic complication.</p>
17:27 < cat-a-puss> jrandom: I'm not talking about the O(n) thing. I mean just waiting to construct a client tunnel until we need one for some apps, rather than just having them sit there all the time. </p>
17:28 <+Complication> (but I might be wrong, and those last 26 messages might have active components)</p>
17:28 <+fox> &lt;Romster&gt; would a long term passive attack evently find the target?</p>
17:28 <+fox> &lt;Romster&gt; i'll comment after i've read the list</p>
17:28 < jrandom> ah cat-a-puss, we'll certainly improve the tunnel pooling for 0.6.2. we currently only build the tunnel when we need it (giving ourselves a little time in case the creation fails)</p>
17:28 <+Complication> Romster: well, persisting the attack beyond tunnel lifetime would require resources and patience</p>
17:28 <+fox> &lt;Romster&gt; and understand it better</p>
17:29 <+Complication> But time plays a part in every probability of success. You try long, you get more chances.</p>
17:29 <+fox> &lt;Romster&gt; ah that's the idea tunnel life tiem be too short to actually have a worthwhile attack work.</p>
17:29 < jrandom> each pool has a defined number of backup tunnels, and we by default build replacements between 60-120 seconds before an old one expires</p>
17:29 <+fox> &lt;Romster&gt; time*</p>
17:30 < jrandom> right Complication - each sample occurs only 'm' times every (c/n) tunnels</p>
17:30 <+fox> &lt;Romster&gt; there is no interaction between each tunnel to gather stastics?</p>
17:30 <+fox> &lt;Romster&gt; as one is about to die and another is being built</p>
17:31 < jrandom> romster: the new tunnels do not talk to each other, no, but thats not the attack Michael has been describing</p>
17:31 < jrandom> there are countless attacks out there, most of which we have dealt with, but whenever someone comes up with one that may have a bearing on I2P's operation, we want to analyze it further</p>
17:31 <+fox> &lt;Romster&gt; must read the list, ok i'll leave it at that for now, anyone else got anything to say?</p>
17:32 < jrandom> ok, if there's nothing else, lets move on to 6) virus investigations</p>
17:32 <+fox> &lt;Romster&gt; actually one stastic i can see could be gathered is no 0 hop would mean that the next hop is not the end point so it could be ruled otu but with millions of nodes that analying technique would be useless</p>
17:33 < jrandom> I don't have anything to add beyond whats been discussed on the forum</p>
17:33 < jrandom> right Romster, there are predecessor attacks on tunnel length, which is one of the main things we're addressing in 0.6.2</p>
17:33 <+fox> &lt;Romster&gt; virus, what virus, if it's linux it'll be nonexistant, but windows hmmm</p>
17:34 <+Complication> Well, although I couldn't build a matching binary (hell knows hy) the final difference was small enough... to hopefully be useful to anyone interested in reading assembly code.</p>
17:34 < jrandom> Romster: please, the weekly status notes should explain these agenda items, and the meeting is to discuss things /beyond/ whats in the notes ;)</p>
17:35 <+Complication> I sure couldn't find anything obvious in there, but nor could I explain away all the difference.</p>
17:35 <@cervantes> rtfml and rtff</p>
17:35 <+fox> &lt;Romster&gt; yeah i haven't been upto speed for quite awhile, sorry about taht jrandom</p>
17:35 <@cervantes> ;-)</p>
17:35 < jrandom> aye, the fact that both a known safe bat file and the old one triggered the same detection code is substantial</p>
17:35 <+Complication> Yes, that sort of eases doubts.</p>
17:36 <+Complication> I guess the QBFC might have undocumented differences within the same version number (different builds?)</p>
17:37 * jrandom has no idea, but its possibly just some OS interaction, or whatever. I don't know, you've put up enough analysis for people to make their own informed decision</p>
17:37 <+Complication> I think it's better that way.</p>
17:37 <+Complication> Disassembly is really notably outside my usual playground.</p>
17:37 < jrandom> legion: is there anything you want to mention about this, or should people just go through the forum if they want more info?</p>
17:38 <@cervantes> can I just re-iterate what others have said on the forum, and thank Complication for the time and maticulous attempts he's put in to checking this issue out</p>
17:38 < jrandom> aye, its much appreciated</p>
17:38 <+legion> I've nothing to add, I feel that I've said way too much about it already</p>
17:39 < jrandom> 'k understood. ok, anyone else have anything to bring up on this, or shall we move on to 7) ???</p>
17:39 < jrandom> [consider us moved]</p>
17:40 <+fox> * Romster seconds that :)</p>
17:40 <+legion> ok for 7)??? how about we take a moment to discuss i2phex</p>
17:40 < jrandom> cool, good idea</p>
17:40 <+fox> &lt;Romster&gt; since i'm using it right now even :)</p>
17:40 <@cervantes> no no group hug first</p>
17:40 < jrandom> redzara mentioned he was going to be at the meeting, but progress on the merge is going slow</p>
17:41 <+legion> susi23 inquired about a headless version</p>
17:41 < jrandom> ah cool, i saw your post on that</p>
17:41 <+fox> &lt;Romster&gt; might i add the favourites list needs to be wider to cope with the longer i2p keys</p>
17:42 <+susi23> (that's no must, I was just curious about it)</p>
17:42 < jrandom> well, no one can remember base64 keys, so I'm not sure if you're missing much Romster ;)</p>
17:42 < jrandom> (and the first few bytes should be enough to uniquely identify them)</p>
17:42 <+fox> &lt;Romster&gt; starting i2phex with a server is the major problem i see so far</p>
17:42 <+legion> Actually I'd like to see only like the first 12 characters of keys to displayed in the client</p>
17:42 <+fox> &lt;Romster&gt; heh guess</p>
17:42 * Complication is regrettably majorly busy, and can't do no xml-rpc</p>
17:43 < jrandom> seems reasonable legion </p>
17:43 <+fox> &lt;Romster&gt; what about display as many characters to make the key unique</p>
17:43 < jnymo_> I'm having good results with i2phex</p>
17:44 < jrandom> cool jnymo_, i've been hearing good things too</p>
17:44 <+fox> &lt;Romster&gt; so if 2 keys start with abc it'll be abcx</p>
17:44 < jnymo_> 12 identical characters isn't likely, romster</p>
17:44 <+fox> &lt;Romster&gt; true</p>
17:44 <+Complication> Besides, simpler = quicker</p>
17:44 <+fox> &lt;Romster&gt; but wouldnt need 12 if the keys are that far randomised</p>
17:45 <+Complication> (not that there is much speed to gain from displaying things)</p>
17:45 <+legion> Well maybe there could be a new host properties window, stating the full key and certain information like how much it is sharing and whatever</p>
17:45 <+susi23> (netdb works great with 4 chars only for router ids)</p>
17:45 <+fox> &lt;Romster&gt; or the database and using the keyname=base64 and only displaying the keyname</p>
17:45 < jrandom> hmm, i thought there was already a peer info display legion?</p>
17:46 < jrandom> legion: some things like that would be good to add to the mainline phex, most likely?</p>
17:46 <+legion> hmm could be right...</p>
17:46 < jrandom> (that way Gregor can maintain it ;)</p>
17:46 <+Complication> Well, there's a "Browse host" function, but that may not be the exact same thing. (If it works.)</p>
17:46 < jrandom> Complication: it does</p>
17:46 < jrandom> (work, that is)</p>
17:47 <+Complication> Seems to basically drop the host destkey into the search box</p>
17:47 <+Complication> ...and runs a search.</p>
17:48 < jnymo_> this may be an i2phex mainline issue, but I didn't see an ETA on i2phex downloads</p>
17:48 <+Complication> Hmm... or actually, doesn't run a search.</p>
17:48 <+Complication> Mine seems to wait until I manually start it.</p>
17:48 <+fox> &lt;Romster&gt; whats the nearby i2phex running tickbox for?</p>
17:49 <+legion> I see where there is plenty of room for improvement. ;)</p>
17:49 < jrandom> yep :)</p>
17:50 < jrandom> lots to be done, and the forum is a good place to post up ideas/suggestions/questions(/patches :)</p>
17:50 <+fox> &lt;Romster&gt; despite it's ovous name</p>
17:50 < jrandom> ok, anyone have anything else for the meeting?</p>
17:50 <+fox> &lt;Romster&gt; hmm good point</p>
17:50 <+fox> &lt;Romster&gt; can't think of anything else</p>
17:51 <+fox> &lt;Romster&gt; but anyone working on a distributed data store?</p>
17:51 * cervantes checks his watch</p>
17:51 <+fox> &lt;Romster&gt; like activtely</p>
17:51 < jrandom> Romster: beyond syndie, no</p>
17:51 < jrandom> (not to my knowledge, at least)</p>
17:52 <+legion> well I was wondering about integrating a http download manager into i2p, would make downloading larger content from eepsites easier.</p>
17:52 <+fox> &lt;Romster&gt; q and iphex and one or 2 others but i've not seen anything mentained for awhile now</p>
17:52 <@cervantes> what's the status of feedspace...I haven't heard aught of it in a while</p>
17:52 < jrandom> legion: that would be cool - there's a post about that on the forum too i think</p>
17:53 <+fox> &lt;Romster&gt; ah feedspace another one</p>
17:53 < jnymo_> if this was mentioned in the meeting already, nm.. but, is there news on i2p freenet colab?</p>
17:53 < jrandom> cervantes: last i heard frosk was kind of busy, but if frosk is around, maybe he can tell us more :)</p>
17:53 <+legion> Personally I'd like to see a i2p entropy colab.</p>
17:54 <+fox> &lt;Romster&gt; i have ideas for a datastore, but it be a expansion to existing methods that are in use currently</p>
17:54 <+legion> Given that q, feedspace and such don't seem to be going anywhere fast right now</p>
17:54 < jrandom> jnymo_: I've bounced the freenet folks some code to run on our SSU transport,toad has been joining in on some of the discussions, but freenet won't be in a position for us to run it as a data store on top of i2p for a while (after their 0.7 release comes out, most likely)</p>
17:54 <+fox> &lt;Romster&gt; i want to start a project but not go over what others have done already</p>
17:54 <+legion> wonder if it'd be possible to port entropy to run over i2p...</p>
17:54 < jrandom> legion: entropy would be good, but integration is kind of hard. of course, people could run things like fproxy.i2p for entropy</p>
17:55 * jrandom doesnt know entropy's transport code at all</p>
17:55 <+fox> &lt;Romster&gt; i've put my irc client on hold, there is alot of them in progress already all i2p needs now is a datastore and it'll beat freenet with ease :)</p>
17:55 < jrandom> (but perhaps that'd be a good way to get someone to hack on the GCJ SDK :)</p>
17:56 < jrandom> Romster: helping out on other efforts is a lot more rewarding that starting brand new projects, as you get a lot more done with less effort :)</p>
17:56 < jnymo_> ah.. congrats on the gcj port</p>
17:56 <+fox> &lt;Romster&gt; entropy's is in c or C++ iirc</p>
17:57 < jrandom> right Romster, which is why they'd be able to use I2P's SDK and streaming lib, built with GCJ into native libraries</p>
17:57 <+fox> &lt;Romster&gt; jrandom true, but who :)</p>
17:57 < jrandom> not I</p>
17:57 <+legion> oh and on another issue, just like to mention that today I released a new version of my readme.html update for the i2p router console.</p>
17:57 < jrandom> (the only way to get something you care about done is for *you* to do it :)</p>
17:57 < jrandom> cool</p>
17:57 * dust would like to see some kind of 'squid' syndication for offloading eepsites</p>
17:58 < jrandom> dust: yeah totally, if we can get sucker into that position, that'd be ideal</p>
17:58 < jrandom> e.g. I'd love to get the latest info from orion in syndie, local</p>
17:58 <+fox> &lt;Romster&gt; build a proxy for squid to use :)</p>
17:59 <+legion> I'd been putting it of in the hope that certain improvements to the python eepsitechecker would have been made by now.</p>
17:59 < dust> ah, syndie</p>
17:59 < jrandom> (thats actually what syndie is for - syndication to cut down on load)</p>
17:59 < dust> _the_ answer</p>
17:59 < jrandom> there's a python eepsite checker?</p>
17:59 <+fox> &lt;Romster&gt; first i've heard about it</p>
17:59 <+legion> yeah, it's what I use ;)</p>
18:00 < jrandom> cool legion </p>
18:00 <+legion> really? It's been around for awhile</p>
18:00 <+fox> &lt;Romster&gt; nice i'd like to check that out :)</p>
18:00 <@cervantes> think someone ported baffled's script... can't remember who/when</p>
18:00 <+fox> &lt;Romster&gt; i'm learning python</p>
18:00 < jrandom> ah ok cervantes </p>
18:00 <+fox> &lt;Romster&gt; the hard way by examples and the manual :)</p>
18:00 < jrandom> yeah, i'm lazy, i just use polecat.i2p/i2psurvey/ and orion.i2p/ :)</p>
18:01 < jrandom> (no need for me to spider)</p>
18:01 <+legion> if someone would care to work with me on it, I'd really like to get the code fixed and working with either python 2.3 or 2.4</p>
18:01 <+fox> &lt;Romster&gt; i have 2.4 installed here</p>
18:01 <+Ragnarok> I may have a look at it. Got link?</p>
18:01 <+fox> &lt;Romster&gt; actually think it's 2.4.1</p>
18:02 <+legion> right now it has no py2exe compatibility and half of it works with each version, which means anyone running it needs to have both installed.</p>
18:02 * jnymo_ would love to see an orion.i2p/I2PDirectory hybrid.. info, catagories, stats.. butter</p>
18:02 <+legion> I'll archive it after the meeting and post a link to the forums</p>
18:03 <+Ragnarok> ok</p>
18:03 < jrandom> legion: hmm, do you see lots of people needing to run that though? I mean, only a few people need to spider</p>
18:03 <+fox> &lt;Romster&gt; both eck, might be a bit much for me to translate to the newer dunno untill i look at the code</p>
18:03 < jrandom> (not that there's anything wrong with making it easy for those few people, that is :)</p>
18:04 <+fox> &lt;Romster&gt; cold be disected and used todo other things too?</p>
18:04 <+legion> Well thing is I can see where there could be some uses for everyone that runs i2p.</p>
18:04 <+fox> &lt;Romster&gt; could*</p>
18:04 < jrandom> hmm, I'm not so sure, could you explain how?</p>
18:04 < jrandom> I mean, I don't want everyone to essentially DDoS every eepsite</p>
18:05 <+legion> One of which would be a dynamic bookmarks page, that is auto generated every 12-24 hours or so.</p>
18:05 < jrandom> ah, that is trivial in syndie (actually one of the main features - 'new blogs')</p>
18:05 < jrandom> ((but of course, syndie doesn't have a great ui for that yet))</p>
18:06 <+fox> &lt;Romster&gt; actually would only need a few to spider and throw it into a torrent/dht like database and sync that between nodes</p>
18:06 < jrandom> right Romster (though that torrent/dht-like database to sync, or "syndi"cate, could be syndie ;)</p>
18:06 <+fox> &lt;Romster&gt; could even be a hidden way to learn more i2p nodes and services</p>
18:07 <+fox> &lt;Romster&gt; yeah or syndie</p>
18:07 < jrandom> ok, anyone else have anything for the meeting? the curry is getting cold ;)</p>
18:08 <+fox> &lt;Romster&gt; if syndie is going tobe that great one could store static pages to cashe and the same with images</p>
18:08 <+fox> &lt;reliver&gt; bon appetit, jrandom :-)</p>
18:08 < jrandom> exactly romster, you can do that now </p>
18:09 < jrandom> ok, if there's nothing else...</p>
18:09 * jrandom winds up</p>
18:09 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

182
i2p2www/meetings/154.log Normal file
View File

@@ -0,0 +1,182 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 154{% endblock %}
{% block content %}<h3>I2P dev meeting, November 1, 2005</h3>
<div class="irclog">
15:04 < jrandom> 0) hi</p>
15:04 < jrandom> 1) 0.6.1.4 and net status</p>
15:04 < jrandom> 2) boostraps, predecessors, global passive adversaries, and CBR</p>
15:05 < jrandom> 3) i2phex 0.1.1.34</p>
15:05 < jrandom> 4) voi2p app</p>
15:05 < jrandom> 5) syndie and sucker</p>
15:05 < jrandom> 6) ???</p>
15:05 < jrandom> 0) hi</p>
15:05 * jrandom waves</p>
15:05 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-November/001186.html</p>
15:05 < jrandom> (lets see if this cat will let me use both hands to type...)</p>
15:06 < jrandom> ooh, looks like we're a few minutes early (damn clock skew), but maybe this'll make up for being a few minutes late before ;)</p>
15:07 < jrandom> anyway, jumping into 1) 0.6.1.4 and net status</p>
15:08 < jrandom> I don't have much to add beyond whats in the status notes</p>
15:08 * cervantes is waiting till the correct time to say hi</p>
15:08 < jrandom> heh</p>
15:09 < jrandom> you've got 19 seconds, acording to timeanddate.com :)</p>
15:09 <@cervantes> hi</p>
15:09 < jrandom> ;) ok, anyway, anyone have any comments/concerns on 0.6.1.4? from what i can see, its gone prety well</p>
15:10 <+Complication> Counted 747.6 routers today :P</p>
15:10 < jrandom> yeah, we've had a higher churn than usual lately</p>
15:10 < jrandom> still getting a bunch of referrers in from that digg / gotroot article</p>
15:10 <+Complication> And one trick to "knowing" more peers is simply restarting less often :)</p>
15:10 < jrandom> heh true enough</p>
15:10 <@cervantes> *cough*sourceforge*cough*</p>
15:11 <+polecat> I've had some trouble with number of participating tunnels dropping abruptly now and again. Might be that darn NAT thing.</p>
15:11 * jrandom cringes. have you had many referrers from sf cervantes?</p>
15:11 <+Complication> cervantes: you mean *that* SourceForge page? :eek:</p>
15:11 * cervantes doesn't log referrers</p>
15:11 < jrandom> hmm polecat, could be a problem with your nat, but dropping the # of participating tunnels isn't really a bad thing - it /should/ do that </p>
15:11 < jrandom> ah ok cervantes </p>
15:12 <+polecat> Really? I thought lots of participating tunnels was good.</p>
15:12 <+Complication> polecat: mine used to drop them rapidly when it exceeded practically usable bandwidth</p>
15:12 <@cervantes> I make a point of only logging the minimum required to debug forum issues ;-)</p>
15:12 <@cervantes> since folk seem touchy on the subject</p>
15:12 <@cervantes> I've noticed...</p>
15:13 < jrandom> polecat: sure, but the # should drop if your machine gets loaded or otherwise acts funky</p>
15:13 < jrandom> reasonable enough cervantes </p>
15:13 * jrandom logs everyone's mother's maiden name, to remind people not to trust anyone ;)</p>
15:14 < jrandom> (or do I? you'll never know ;)</p>
15:15 < jrandom> polecat: is your nat just randomly restarting, or losing its ip address, or something else?</p>
15:15 <@cervantes> yeah I might change my mind on that issue....it's way too much fun seeing where everyone follows links from :P</p>
15:16 < jrandom> its how i found the got-root and digg articles :)</p>
15:16 < dust> i've noticed better network throughput lately, or it it just me imagining things again?</p>
15:17 < jrandom> it should be better, especially for short lived connections (e.g. http responses)</p>
15:18 < jrandom> otoh, its not as much of an improvement as i had hoped, so there's still work to be done on that front</p>
15:18 < dust> e.g. i2phex pretty much takes any limit i give it if i give it enough parallel transfers</p>
15:18 < jrandom> nice</p>
15:20 < dust> per-tunnel seems limited &lt;~10k/s</p>
15:20 < dust> or per-transfer</p>
15:20 <+polecat> Okay, my machine does get loaded now and again.</p>
15:21 <@cervantes> have any of the folk on bandwidth restricted connections noticed improvement?</p>
15:22 < jrandom> hmm right, 10KBps per stream seems ballpark to what i'm seeing as well</p>
15:22 < jrandom> cervantes: i think we scared 'em all away (but if anyone with a modem or Really Shitty Connection wants to give it a try and report back, it'd be appreciated :)</p>
15:23 < jrandom> ok, if there's nothing else on 1), lets move on to 2) boostraps, predecessors, global passive adversaries, and CBR</p>
15:23 < jrandom> there's been lots of discussion on this fron over the mailing list (october had more posts than any other month since i2p started!)</p>
15:24 < defnax> did anywere looked eepsites.i2p?</p>
15:24 < jrandom> beyond whats in the status notes, i'm not sure what i have to add at the moment. anyone have any questions/comments/concerns?</p>
15:24 <@cervantes> I think you've successfully generated full tunnel CBR by maintaining a constant level of i2plist mails</p>
15:24 < jrandom> heh cervantes </p>
15:24 < jrandom> defnax: yeah, it looks neat, a nice database growing there</p>
15:25 < jrandom> same with tino.i2p</p>
15:25 < defnax> but i dont like it</p>
15:25 <+polecat> Hey, I'm on a bandwidth restricted connection! i2p gets 10K/s up and 32K/s down. :)</p>
15:26 < defnax> www.eepsites.com then can all normal users on internet search for i2p sites</p>
15:26 < defnax> and mpaa or riaa can browse what sites avaible and </p>
15:26 < jrandom> so?</p>
15:26 < jrandom> mpaa/riaa/etc can just run i2p if they want to see whats on i2p</p>
15:26 < jrandom> w3wt polecat </p>
15:27 < jrandom> (jesus, some sick search queries @ eepsites.com...)</p>
15:27 < defnax> thats not good for anonnymity</p>
15:27 < defnax> then all users now where can find torrents on I2P eepsites</p>
15:27 < jrandom> defnax: same with tino.i2p</p>
15:27 <@cervantes> I like the faux google ads on eepsites.i2p.... but anyway, digression</p>
15:27 < jrandom> defnax: thats not good for /secrecy/. thats different from anonymity.</p>
15:27 < jrandom> people hosting public eepsites should expect that anyone can view their eepsites</p>
15:28 < jrandom> if they want to restrict who can access it, they should do so</p>
15:28 < jrandom> yeah definitely cervantes :)</p>
15:28 <+polecat> Anyone who wants a private eepsite, just don't give it a name in hosts.txt. Problem solved!</p>
15:28 < defnax> but normal internet users must dont know which eepsites is avaible!</p>
15:28 < jrandom> polecat: thats not entirely sufficient</p>
15:29 <+polecat> Really?</p>
15:29 < jrandom> i'm sorry, perhaps I misunderstand defnax. why shouldn't people know what eepsites are available?</p>
15:29 < defnax> i know it then not listend in a search enigine when dont make eespite public</p>
15:29 <+polecat> I thought it was a brute force sweep through the base64 keyspace to find eepsites...</p>
15:29 < jrandom> polecat: right, someone can harvest the netDb</p>
15:29 < defnax> i think this person dont need I2P</p>
15:29 < jrandom> well, harvesting for leaseSets is substantially more work than harvesting for routers...</p>
15:30 < jrandom> defnax: I'm sorry, I don't understand</p>
15:30 < jrandom> eepsites.com is a public interface to a search engine across public eepsites. nothing private is being revealed</p>
15:30 <@cervantes> lol @ last 5 searches</p>
15:30 <+Complication> Yep, the "last searches" box suggests someone (ironically someone who is probably non-anonymous) is a tiny bit sick.</p>
15:30 <+Complication> Ah, whatever.</p>
15:30 < defnax> i mean he dont need I2P ! he tells on public IP on which eespites are torrents or other things avaible!</p>
15:31 < defnax> on I2P is ok , but not on normal internet</p>
15:31 < jrandom> defnax: sure, that person running eepsites.com does not themselves require i2p. you can find out their home address, phone number, etc.</p>
15:31 < jrandom> but, on the other hand, same goes for forum.i2p. </p>
15:31 < jrandom> (and to some extent, www.i2p, though that doesn't give you /my/ info ;)</p>
15:32 < jrandom> some sites are public. thats fine. thats neat. </p>
15:32 <+fox> &lt;jme___&gt; defnax, what attacks is possible thanks to this site, which isnt without this site ?</p>
15:32 <@cervantes> Complication: snigger</p>
15:32 < jrandom> they're offering a potentially useful service to people who may want to try out i2p before installing</p>
15:33 < defnax> ok any news from I2Psnark? </p>
15:33 <+Complication> cervantes: yeah, nothing like good old irony :)</p>
15:33 < defnax> i will become before 0.6.2 a webinterface/gui?</p>
15:33 <@cervantes> defnax: there's been an i2p inproxy for several months</p>
15:33 < jrandom> defnax: nope, but I suppose we should jump forward in the agenda before we hit 6) ???</p>
15:33 < jrandom> ok, is there anything else on 2) boostraps, predecessors, global passive adversaries, and CBR?</p>
15:34 < jrandom> or shall we move on to 3) I2Phex 0.1.1.34</p>
15:34 < jrandom> [consider us moved]</p>
15:35 < jrandom> ok, those not yet on 0.1.1.34 should upgrade, as there's some important stuff in the release. Those already on 0.1.1.34 who want to help test out some not-yet-released improvements, there's further work in CVS, so if you try that out and run into troubles, please post on the forum</p>
15:36 < jrandom> in other news, I've heard some good progress on the gwebcache front as well, but no word on its integration with i2phex yet</p>
15:36 < jrandom> redzara: any word on the merge?</p>
15:37 <+Complication> The post .34 cvs improvements seem to make the GUI *much* more responsive.</p>
15:38 < jrandom> cool, yeah, I couldn't handle the &lt;= ..34 responsiveness, but i'm not sure if the fixes are entirely regression-free, since i don't really understand all the code. but it /seems/ ok :)</p>
15:42 <+redzara> jrandom : sorry, but we have just change hour time in France to Winter Time and work is near finished for I2phex, I've just to track 2 or 3 bugs</p>
15:43 < jrandom> ah cool!</p>
15:43 < jrandom> no rush, just wondering</p>
15:44 <+redzara> and maybe I've to get lastest I??phex code to see if GregorK's mod apply to lastest phex code ?!?</p>
15:45 < jrandom> yeah, disabling the remote request functionality will be required, but it was a trivial two line fix (comment out MAGMA and URI requests).</p>
15:45 < jrandom> same for the latest synchronization issue (remove unnecessary locks on network operations)</p>
15:46 <+fox> &lt;jme___&gt; I??phex &lt;- interesting how typo can reveal location too :)</p>
15:46 < jrandom> not as much as "in France" does ;)</p>
15:46 <+redzara> this is already done in my code</p>
15:46 <@cervantes> hehe</p>
15:46 < jrandom> (but thats another bug thats not yet fixed... the irc charset stuff)</p>
15:46 < jrandom> ok cool redzara </p>
15:47 <+redzara> jme___ : I don't search to hide my location, you konw :-)</p>
15:47 <+redzara> so nothing more to say about i2phex for me</p>
15:47 <+fox> &lt;jme___&gt; redzara, ok :) </p>
15:48 < jrandom> ok great, thanks for the update</p>
15:48 < jrandom> anyone else have anything on i2phex, or shall we move on to 4) voi2p app?</p>
15:49 <+redzara> consider we are moving :)</p>
15:49 < jrandom> for 4), I'm not sure if I've got anything to add beyond whats in the mail, and it seems aum has disconnected, so we'll probably have to wait for an update at a later time</p>
15:49 < jrandom> (unless someone else has something to discuss for 4)?)</p>
15:50 < jrandom> if not, consider us moved to 5) syndie and sucker</p>
15:50 < jrandom> dust: wanna give us the word?</p>
15:51 <@cervantes> so is syndie good at sucking now?</p>
15:51 < jrandom> yes *cough*</p>
15:51 < dust> heh</p>
15:52 < dust> well, the note says pretty much it</p>
15:52 < dust> there are still stuff to do</p>
15:53 < dust> word on the testing and reporting of bugs</p>
15:54 < jrandom> ok great, do you know offhand what the story with rome-0.8 is? worth waiting for a pending release, or should we grab a cvs build and upgrade it later?</p>
15:55 <+fox> &lt;brutus&gt; oi, how about the auto ping-pongin' ircProxy, any progrssthat?</p>
15:55 < jrandom> no progress i know of</p>
15:55 <+fox> &lt;brutus&gt; (ups, sry)</p>
15:55 <+polecat> voi2p, make a mp3 of your voice and i2p bittorrent it.</p>
15:56 < dust> no, dunno the eta on next rome</p>
15:56 < dust> i couldn't get to the cvs</p>
15:57 < dust> (i don't remember why)</p>
15:57 < jrandom> ah 'k, well, we don't need it yet, it'd just be neat. a later date then</p>
15:58 < jrandom> ok, anyone have anyhing else on 5)? or shall we move on to 6) ???</p>
15:59 < jrandom> [consider us moved]</p>
15:59 <@cervantes> brutus: I don't beleive anything has been done concerning that</p>
16:00 < dust> should it be done?</p>
16:01 <+fox> &lt;brutus&gt; oki, yeah, i guess it's pretty low priority as well</p>
16:01 <+polecat> I still want to know how we could make i2p, and anonymity techniques in general, more accessible in poor or dangerous places.</p>
16:01 < jrandom> polecat: by getting someone with a dialup connection to help test ;)</p>
16:01 <@cervantes> free rifle with every installation?</p>
16:02 < jrandom> polecat: we're definitely working on that, but we have so, so much more to do first.</p>
16:02 < jrandom> dust: the irc thing? might be worthwhile, but sucker improvements are probably more important</p>
16:02 < jrandom> (imho)</p>
16:03 <@cervantes> (somewhat biases opinion ;-)</p>
16:03 <@cervantes> *biased</p>
16:03 < jrandom> true that, but i think my bias is Right :)</p>
16:04 * cervantes notes the capital lettering ;-)</p>
16:05 * Complication looks at the phone socket, and wonders if anything good can come of such <things> :D</p>
16:05 <+Complication> Then again, if DSL travels over it, it cannot be inherently evil. :D</p>
16:05 <+polecat> No... not Things!</p>
16:05 <@cervantes> Complication: you can also use it to call people....</p>
16:06 < jrandom> ok, anyone have anything else for 6) ???</p>
16:07 * cervantes wasn't sure we had anything for ??? in the first place</p>
16:07 < jrandom> in that case... </p>
16:07 * jrandom winds up</p>
16:08 * jrandom *bafs* the meeting closed</p>
</div>
{% endblock %}

66
i2p2www/meetings/155.log Normal file
View File

@@ -0,0 +1,66 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 155{% endblock %}
{% block content %}<h3>I2P dev meeting, November 8, 2005</h3>
<div class="irclog">
15:21 < jrandom> 0) hi</p>
15:21 < jrandom> 1) Net status / short term roadmap</p>
15:21 < jrandom> 2) I2Phex</p>
15:21 < jrandom> 3) I2P-Rufus</p>
15:21 < jrandom> 4) I2PSnarkGUI</p>
15:21 < jrandom> 5) Syndie</p>
15:22 < jrandom> 6) ???</p>
15:22 < jrandom> 0) hi</p>
15:22 * jrandom waves</p>
15:22 < jrandom> weekly status notes up at http://dev.i2p.net/pipermail/i2p/2005-November/001206.html</p>
15:22 * bar mumbles greetings from behind his/her false(?) beard</p>
15:23 < jrandom> ok, jumping into 1) Net status / short term roadmap</p>
15:23 < jrandom> Not much to say beyond whats in the mail - hopefully a new release later this week, or this weekend</p>
15:24 < jrandom> there are some new optimizations in cvs which should help improve reliability, and its worked pretty well in the tests i've done, but it probably won't have much of an impact until it gets widespread deployment</p>
15:25 < jrandom> I also haven't picked an arbitrary throughput level I want to reach before continuing on to 0.6.2, though my gut instinct tells me that optimizations should continue until I can justify the choke points by per-router hop delays</p>
15:26 < jrandom> right now, however, that isn't our choke point, so there's still work to be done.</p>
15:26 < jrandom> I don't have much more to add on that front - anyone have any questions/comments/concerns?</p>
15:28 < jrandom> ok, if not, moving on to 2) I2Phex</p>
15:28 < jrandom> I don't have much more to add here beyond whats been said in the email. There have been a bunch of discussions on the forum too, though, so swing by there for more news and ranting </p>
15:31 < jrandom> ok, if not, jumping on over to 3) I2P-Rufus</p>
15:31 < jrandom> this bullet point was really just me repeating a rumor, but we'll see how things go</p>
15:32 < jrandom> Rawn / defnax: do you have anything to add?</p>
15:35 < tealc_> whats i2p-rufus ?</p>
15:35 < jrandom> a port of the rufus bittorrent client for I2P (http://rufus.sourceforge.net/)</p>
15:36 < jrandom> ok, if there's nothing else, we can jump to another quick rumor reportage - 4) I2PSnarkGUI</p>
15:37 < jrandom> I don't have much to add to this beyond saying "hey, cool" :)</p>
15:38 <+bar> yeah, looks nice</p>
15:38 <@frosk> snark is Y.A. BT client?</p>
15:38 < jrandom> yeah, but snark is a bittorrent client bundled with I2P :)</p>
15:38 <@frosk> oh yeah, right :)</p>
15:38 < jrandom> (currently a command line tool, but multitorrent and web interface is on the way, though not imminent)</p>
15:39 <+fox> &lt;ZipTie&gt; who was doing the work for the rarest-first fetching strategy for snark? did that ever get done?</p>
15:39 < jrandom> yeah, Ragnarok implemented that</p>
15:39 < jrandom> its in the current I2PSnark</p>
15:39 <+fox> &lt;ZipTie&gt; cool</p>
15:40 < jrandom> aye, quite</p>
15:41 <+fox> &lt;ZipTie&gt; is i2p-bt going to be decomissioned then in favor of either rufus or snark?</p>
15:41 < jrandom> thats for users to decide</p>
15:42 <+fox> &lt;ZipTie&gt; or maintainability :)</p>
15:42 < jrandom> personally, I think if snark gets a web interface, integrated with the router console, multitorrent capabilities, and offers equivilant performance as the others, it'll be in good shape</p>
15:43 < jrandom> but really, what you mention is the key - who does the maintenance and development is the driving force</p>
15:43 * jrandom does not maintain python apps</p>
15:44 < jrandom> ok, if there's nothing else on 4, lets move on to 5) Syndie</p>
15:45 < jrandom> I've been doing some usability research into how best to proceed, and I think we've got a pretty viable UI on the way, but if you've got an opinion, post it up on syndie or the forum and we can hopefully take it into consideration</p>
15:46 < tealc_> ahh, i thought i2phex was java.. the stuff on the forums offers .exe installers and .exe's in zips</p>
15:47 < jrandom> i2phex is java</p>
15:47 < jrandom> and the .exe works with any platform that java works on</p>
15:47 < jrandom> java -jar i2phex.exe</p>
15:47 < jrandom> (yes, really)</p>
15:49 < jrandom> (cough)</p>
15:49 < jrandom> dust: anything to add re: syndie stuff?</p>
15:50 < dust> nope</p>
15:50 < jrandom> ok cool. unless anyone else has anything on it, lets jump to ol' faithful: 6) ???</p>
15:50 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
15:53 <+fox> &lt;reliver&gt; is the paella ready ? ;-)</p>
15:53 * jrandom grabs a spork</p>
15:54 < jrandom> (on that note...)</p>
15:54 <+fox> &lt;reliver&gt; and the cat still smells like cats ;?)</p>
15:54 * jrandom windos up</p>
15:54 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

351
i2p2www/meetings/156.log Normal file
View File

@@ -0,0 +1,351 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 156{% endblock %}
{% block content %}<h3>I2P dev meeting, November 15, 2005</h3>
<div class="irclog">
15:15 < jrandom> 0) hi</p>
15:15 < jrandom> 1) Net status / 0.6.1.5</p>
15:15 < jrandom> 2) Syndie updates</p>
15:15 < jrandom> 3) I2Phex</p>
15:15 < jrandom> 4) I2P-Rufus</p>
15:15 < jrandom> 5) Issue tracker</p>
15:15 < jrandom> 6) Dynamic Keys</p>
15:15 < jrandom> 7) ???</p>
15:15 < jrandom> 0) hi</p>
15:15 * jrandom waves</p>
15:16 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-November/001210.html</p>
15:17 <+bar> yalla! *fires some rounds into the air*</p>
15:17 * jrandom ducks and covers, diving into 1) Net status / 0.6.1.5</p>
15:18 < jrandom> as mentioned in the mail, there's been a lot of progress, and there should be a new release later tonight</p>
15:18 * jrandom would have released it earlier, but I slept late and didn't want everyone upgrading /during/ the meeting :)</p>
15:20 < jrandom> anyone have any questions/comments/concerns re: 1) net status / 0.6.1.5?</p>
15:20 <+fox> &lt;ailouros&gt; is "please keep up the good work" an acceptable comment?</p>
15:20 < jrandom> :) thanks</p>
15:22 < jrandom> I've been pretty happy with the stability as of late. hopefully the next release will improve throughput beyond 4-8KBps/stream. I've done plenty of local testing, but we need to see it out in the wild</p>
15:22 < tethra> i second ailouros's comment, and furthermore, propose a toast:</p>
15:22 < jrandom> we've also had some more positive reports from users on dialup connections</p>
15:22 < tethra> to jrandom, and i2p! woot!</p>
15:22 < tethra> &lt;3</p>
15:23 < jrandom> w3wt. ok, if there's nothing else, lets jump on over to 2) Syndie updates</p>
15:24 < jrandom> lots of progress on this front, but perhaps it'll be best to discuss it after the release when people can try it for themselves</p>
15:25 < jrandom> hopefully the info up @ http://syndiemedia.i2p.net/about.html (the first link) can explain why you should bother trying it out :)</p>
15:25 <+fox> &lt;ailouros&gt; oh come on, first you don't release it, then you say "try it first"... this is just teasing! :D</p>
15:25 < jrandom> :)</p>
15:26 < jrandom> ok ok, so lets just jump ahead to 3) I2Phex then, so y'all can post up your thoughts about syndie to syndie itself after you upgrade ;)</p>
15:27 < jrandom> there's going to be an announcement for I2Phex 0.1.1.36 later tonight</p>
15:28 < jrandom> the only change is the fix for the annoying "Please insert a disk" popup</p>
15:28 < tethra> that means i can take the disk out the drive without it screaming at me, then? ;)</p>
15:28 < jrandom> heh yes</p>
15:28 < tethra> :D</p>
15:30 < jrandom> ok, if there's nothing more on 3) I2Phex, lets jump on over to 4) I2P-Rufus</p>
15:30 < tethra> what are the plans for i2phex, while we're on the subject?</p>
15:30 < jrandom> ah</p>
15:30 < jrandom> there's a set of feature requests posted to the forum</p>
15:31 < jrandom> I haven't heard anything from redzara about the code merge with Phex, but Gregor is still working on abstracting the networking stuff so we can more easily keep in sync</p>
15:32 < jrandom> generally, the app seems functional, though gwebcache support would be Really Good, so that I2Phex could work out of the box without needing to fetch any files or keys</p>
15:32 < jrandom> I don't know anyone working on getting gwebcache support (back) into I2Phex, but if someone knows java, that'd be Really Useful</p>
15:33 < tethra> cool.</p>
15:33 <+fox> &lt;reliver&gt; _007pig perhaps ?</p>
15:33 <+fox> &lt;ailouros&gt; sorry if I ask, but wasn't gnutella network the one that flooded itself to death some time ago?</p>
15:33 < tethra> the new guys do tend to be a bit confused about it at first</p>
15:33 <+fox> &lt;reliver&gt; you did not take him up on his offer for help, yesterday, jrandom</p>
15:33 < jrandom> _007pig was looking into translation work, but anyone would be great. Phex itself has gwebcache support, but sirup disabled it</p>
15:34 < jrandom> ailouros: gnutella is still around, but yeah, its not ideal.</p>
15:34 < tethra> is anyone looking into perhaps changing the protocol i2phex uses to something else?</p>
15:35 < jrandom> I'm hesitant to demand people work on specific projects, so I instead suggest a few different areas that someone could explore</p>
15:35 < jrandom> tethra: no one that I know of</p>
15:35 <+fox> &lt;ailouros&gt; well, I think I'd rather see Localhost (azureus modification) on i2p then</p>
15:36 < tethra> surely bittorrent is more awkward than gnutella?</p>
15:36 < tethra> in terms of seeding and such</p>
15:36 < jrandom> ailouros: whatever people implement and maintain is good :)</p>
15:36 <+fox> &lt;ailouros&gt; I don't know, I didn't use gnutella since... 6 years I think</p>
15:37 < anti> surely it is more efficient and better test of true scalability?</p>
15:37 <+fox> &lt;ailouros&gt; jrandom yeah that's a good metric :D</p>
15:37 < jrandom> i2phex works pretty well, I've transferred lots of data through it, and found some neat content</p>
15:37 <@cervantes> (pony pr0n)</p>
15:37 <+fox> &lt;ailouros&gt; lol</p>
15:37 < tethra> hahah</p>
15:37 < jrandom> there may be better ways to do things, but something that works is better than something that doesn't exist</p>
15:37 < tethra> cervantes++</p>
15:37 < tethra> ;)</p>
15:38 < tethra> truer words have never been spoken.</p>
15:39 < anti> good point</p>
15:39 <@cervantes> uhoh... jr has taken offense and gone early to dinner</p>
15:39 <@cervantes> (sorry)</p>
15:39 < anti> no, he's probably searching for that (mythical) pony pr0n. ;)</p>
15:40 < jrandom> *cough* ;)</p>
15:40 < tethra> lol </p>
15:40 < tethra> heheh ;)</p>
15:40 < jrandom> ok, if there's nothing else on 3), lets move on to 4) I2P-Rufus</p>
15:40 <+fox> &lt;reliver&gt; i want flying pony pr0n :-)</p>
15:40 < jrandom> Rawn / defnax: anything to add to what was posted on the forum?</p>
15:41 <@cervantes> looks like some good progress is being made</p>
15:41 < jrandom> aye</p>
15:45 < jrandom> ok, if there's nothing on that, lets jump on to 5) issue tracker</p>
15:45 < jrandom> the forum is a bit heavyweight for managing bugs and feature requests, and bugzilla is a bit of a beast... </p>
15:46 <@frosk> isn't there a bugzilla already somewhere?</p>
15:46 < jrandom> i've posted up some general requirements, and cervantes has come up with one workable solution</p>
15:46 < jrandom> nah, the bugzilla was on the old host (@johnscompanies) before we migrated to sago</p>
15:46 <+fox> &lt;ailouros&gt; hot about NNTP? better than forums, usually threaded...</p>
15:46 <+fox> &lt;reliver&gt; strange that bugzilla is so lacking, considering the huge open source community using it ...</p>
15:46 <+fox> &lt;ailouros&gt; how*</p>
15:46 <@frosk> ah ok</p>
15:47 < jrandom> nntp has potential, but there are some benefits over that by using syndie (simple filtering by tag): http://syndiemedia.i2p.net:8000/threads.jsp?visible=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800004&post=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800004&</p>
15:48 < jrandom> but nntp does have the benefits of having decades of battle testing</p>
15:48 <+fox> &lt;ailouros&gt; NNTP reader filter by keyword (the [] tags)? :D</p>
15:49 <@modulus> perhaps not so much testing of late?</p>
15:49 <+fox> &lt;reliver&gt; including spamming and flaming ...</p>
15:49 < jrandom> we'd want something web accessible though, since most people don't use nntp readers</p>
15:49 <+fox> &lt;ailouros&gt; I say Thunderbird is good in that sense, and you can share the enigmail between i2mail and i2nntp</p>
15:49 <@modulus> maybe a web accessible nntp reader?</p>
15:49 <+fox> &lt;reliver&gt; gateways are common</p>
15:49 < jrandom> hmm modulus?</p>
15:50 <@modulus> well, usenet is not so much used anymore i think</p>
15:50 < jrandom> right, so we'd have to have an nntp server and a gateway with filtering support</p>
15:50 <@frosk> i like cervantes' idea though</p>
15:50 <+fox> &lt;ailouros&gt; (and I also say the reason people don't use NNTP readers is because forums are so much prettier and so much heavier)</p>
15:50 <@modulus> hmm, gateway with filtering support? what are you guys talking about, maybe it helps knowing. :-)</p>
15:51 <@modulus> imo forums suck, i hate fucking forums, they're unusable ;-(</p>
15:51 <+fox> &lt;ailouros&gt; LOL I guess he wants the access from the InterNEt</p>
15:51 <+fox> * ailouros agrees with modulus</p>
15:51 <@frosk> modulus: so very true</p>
15:51 < jrandom> heh modulus ;) we're discussing http://syndiemedia.i2p.net:8000/threads.jsp?visible=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800004&post=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800003&</p>
15:51 <+fox> &lt;ailouros&gt; aieee the megabyte long URI</p>
15:52 <@modulus> what I love about syndie URLs is how memorable and simple they are to type</p>
15:52 < jrandom> I do still like http://syndiemedia.i2p.net:8000/threads.jsp?post=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800004&</p>
15:52 < jrandom> heh</p>
15:52 < jrandom> well, go to http://syndiemedia.i2p.net/threads.jsp then and click on the "Issue tracking software" link :)</p>
15:53 <@frosk> bug reporting right from your router console</p>
15:53 <@modulus> hmm, bug tracking.</p>
15:53 < jrandom> using syndie would give us 1) integration with every I2P user's environment 2) trivial filtering 3) threading 4) spam handling (via ignore/favorites) 5) syndie a workout :)</p>
15:54 <+fox> &lt;reliver&gt; sounds great :-)</p>
15:54 <+fox> &lt;ailouros&gt; it is</p>
15:54 < jrandom> aye that is a really good feature frosk... we could even have specialized html forms to post to /syndie/post.jsp</p>
15:54 <+fox> &lt;ailouros&gt; and by the way, wasn't there talk about basing syndie on NNTP? :D :D :D</p>
15:54 <@modulus> hmm, how about the Debian bug tools? they're nice i think, the mailbug</p>
15:54 < anti-> can't argue with what already works!</p>
15:55 <@cervantes> I think you should do it purely from a techdemo perspective</p>
15:55 < jrandom> ailouros: using NNTP to distribute syndie posts, yeah. right now we just use ad-hoc syndication, but further enhancements would be great</p>
15:56 <@cervantes> no better way to demonstrate syndie than with some real world use cases</p>
15:56 < jrandom> true enough</p>
15:56 < jrandom> ok, perhaps we can plan on getting that out in the 0.6.1.6 release</p>
15:56 <+fox> &lt;reliver&gt; what i don't like about forum is they are low entry cost</p>
15:57 <+fox> &lt;reliver&gt; so lots of distractions filling them.</p>
15:57 <@modulus> i don't know, this syndie thing ... i much do not like yet, but maybe i'll get used to it.</p>
15:57 <+fox> &lt;reliver&gt; and you can only work with them online</p>
15:57 < jrandom> modulus: have you read the post linked to from http://syndiemedia.i2p.net/about.html ?</p>
15:57 <@modulus> reliver: high-entry is bad for bug reports though, people are making you a big favour by bothering to report in a sense.</p>
15:57 <+fox> &lt;ailouros&gt; they are not low entry cost: bandwidth comes to mind. They are high noise levels, so you can use [font=54]HELLO WORLD![/font] and annoy a huge number of people in no time</p>
15:57 < jrandom> agreed modulus</p>
15:58 <+fox> &lt;ailouros&gt; oh yeah and you have to be online indeed</p>
15:58 < jrandom> heh ailouros, thats something we need to deal with in Syndie anyway :)</p>
15:58 <@modulus> hmm, probably not, jr, let me check</p>
15:58 <+fox> &lt;ailouros&gt; well, with syndie you can blacklist the users and you're pretty much set</p>
15:58 < jrandom> well, with syndie you can create your bug reports offline, then syndicate them up to a remote archive later when you are :)</p>
15:58 < jrandom> exactly ailouros, with one click in the new release too</p>
15:59 <+fox> &lt;ailouros&gt; with forums either you hope for an admin to come and kill'em, or you keep them</p>
15:59 < anti-> it's more uucp than nntp :)</p>
15:59 <@modulus> hmm, which post in particular linked from there?</p>
15:59 < jrandom> lol *exactly* anti</p>
15:59 < jrandom> modulus: the first link "in syndie itself"</p>
15:59 * cervantes likes the killing option</p>
16:00 <@modulus> bah, uucp == nntp for all practical purposes :-)</p>
16:00 < jrandom> anti-: thats actually the point - as people build newer and better transport mechanisms (uucp, nntp, usenetdht, etc), the content can flow seamlessly</p>
16:00 <+fox> &lt;ailouros&gt; this all reminds me of plan9</p>
16:01 <+fox> &lt;reliver&gt; i2p may be special, but usually bug reporting systems used as firewalls against users ...</p>
16:01 < jrandom> used as firewalls against users?</p>
16:01 <+fox> &lt;reliver&gt; i2p may be special, but usually bug reporting systems are used as firewalls against users ...</p>
16:01 <+fox> &lt;reliver&gt; yes.</p>
16:01 < jrandom> I want it to be really, really easy for people to report bugs</p>
16:01 <+fox> &lt;reliver&gt; mozilla, thunderbird, ubuntu are just examples</p>
16:02 <+fox> &lt;reliver&gt; ok, great :-)</p>
16:02 < jrandom> mozilla/etc have that integrated "feedback agent" for submitting bug reports automatically</p>
16:02 <+fox> &lt;reliver&gt; they don't read those bug reports</p>
16:02 < jrandom> heh</p>
16:02 <@modulus> hmm, that intro is ok, only problem is i just don't like the interface at all, i prefer doing mailish things through the folder metaphor rather than the web-with-sithloads-of-links-on-it method</p>
16:02 <@modulus> but that's just me</p>
16:02 < jrandom> modulus: perhaps the rss export would best serve your needs then?</p>
16:02 <+fox> &lt;ailouros&gt; I agree with modulus (anyone guessed? :D )</p>
16:02 <@cervantes> having to use pastebin to show console errors is a bit of a put-off for some folks</p>
16:03 < jrandom> or we can get susimail integration, as cervantes suggested, to send out reports</p>
16:03 < jrandom> (or to post to syndie)</p>
16:03 <@modulus> it is possible, jrandom, i'll look into it. maybe i need an RSS-to-NNTP or RSS-to-POP?/IMAP converter, i'll think on it.</p>
16:05 <@cervantes> modulus: I'll be curious to find out what you think of the new i2ptunnel interface come the next i2p release</p>
16:05 <@cervantes> whether it's better or worse for you in terms of usability</p>
16:05 <@cervantes> (but I guess you just normally edit the config files?)</p>
16:07 < jrandom> ooh yeah shit, I forgot so much stuff in the status notes...</p>
16:08 <+fox> &lt;ailouros&gt; then let's hurry ahead and skip to the next point in line... that was point number C, right?</p>
16:08 * jrandom thinks it really kicks ass, but we'll get some more feedback as people try it out</p>
16:08 <@modulus> cervantes: is that curious as in "you're going to kill yourself with a small knife in your arse as a better alternative to using it" or on the contrary? :-)</p>
16:08 < jrandom> yeah, jumping to 6), anyone have any thoughts on the Dynamic Keys proposal?</p>
16:09 <@modulus> cervantes: usually use the interface actually, though now i know the config files are editable ... :-)</p>
16:09 <+fox> &lt;ailouros&gt; yeah, I'm pretty certain it will cause the skyrocket in the number of supposed known routers</p>
16:09 <@cervantes> *damn* :)</p>
16:10 <@modulus> this dynamic key is the idea that routers get a new key upon new IP, right?</p>
16:10 <@cervantes> modulus: well, just if it's even worth bothering with WAI bullshit</p>
16:10 < jrandom> heh thats true ailouros</p>
16:10 <@cervantes> anyway...I digress</p>
16:10 < jrandom> right modulus </p>
16:11 <@modulus> well, perhaps it isn't bad that the known peers are actually guesswork, more so than now.</p>
16:11 <+Complication> Well, the only thing I can figure out about Dynamic Keys.. seems that one shouldn't change keys needlessly (or it screws reliability performance tracking).</p>
16:11 <+Complication> But when IP changes (rare enough?) it might not hurt.</p>
16:11 < jrandom> right Complication. it isn't something we'd want by default. most people will *not* want it</p>
16:12 < anti-> i'm not sure of the positive impact of the proposals.</p>
16:12 < jrandom> it won't offer much of an improvement for anonymity either, and no improvement at all against a powerful adversary, but it might help against weak adversaries</p>
16:12 <+fox> &lt;ailouros&gt; wouldn't it also give away which nodes are fixed ip and which aren't?</p>
16:13 * cervantes has had the same key for nearly 2 years :)</p>
16:13 <+polecat> Well at least I can get here.</p>
16:13 < jrandom> ailouros: it would not be used by most people. only a very, very small minority would want to use it</p>
16:13 <+fox> &lt;ailouros&gt; so basically more churn for a bit of protection against weak adversaries?</p>
16:13 < jrandom> right ailouros</p>
16:13 <+fox> &lt;ailouros&gt; oh ok</p>
16:14 <+fox> &lt;ailouros&gt; is there a way to measure the performance hit of that feature once in the wild?</p>
16:14 <@modulus> it would, i think, help against a node-dest intersection attack?</p>
16:14 <+polecat> I still wonder why I keep switching between OK and OK(NAT), puzzling...</p>
16:14 < jrandom> modulus: only for a weak adversary</p>
16:14 <+fox> &lt;ailouros&gt; polecat don't worry, I keep switching between 15h uptime and 0h uptime :|</p>
16:14 < jrandom> ailouros: not sure, though stats.i2p suggests that we can handle the churn</p>
16:15 < jrandom> polecat: hmm, means there's likely some filtering going on</p>
16:15 <@modulus> imo the node-dest intersection attack is the most serious likely feasible attack atm? besides the fact we are too few, i mean.</p>
16:15 <@modulus> so, i think anything which helps on that line is probably a good idea</p>
16:16 <+polecat> I can send UDP packets right over my router at that port, no problem from remote shells. No clue, perhaps i2p detects the NAT, and mistakenly thinks it isn't forwarded.</p>
16:16 <+fox> &lt;ailouros&gt; I agree with the "good idea" as long as the churn doesn't cause a severe performance hit</p>
16:16 < anti-> when the network is bigger, there will be plenty of churn anyway...</p>
16:17 < anti-> *points out the obvious DoS attack involving constantly changing keys every few minutes</p>
16:17 < anti-> what impact would that have?</p>
16:17 <+fox> &lt;ailouros&gt; dos against who? :D</p>
16:18 < jrandom> eh, new peers go in the "not failing" tier by default, and only go up to the "high capacity" or "fast" tiers after they are around for a while</p>
16:18 < jrandom> so it won't DoS peer selection</p>
16:18 < anti-> with a relatively strong opponent... would create an awful lot of apparently dead nodes/netdb churn?</p>
16:18 <+Complication> anti: nobody would consider that node reliable any more</p>
16:18 <+polecat> anti-: We have a shitlist for a reason.</p>
16:19 < anti-> *satisfied</p>
16:19 < jrandom> well, the netDb entries are dropped if the peer is unreachable</p>
16:20 < anti-> then the same performance issues that were just raised about dynamic keys would apply? if the performance wouldn't be too impacted by such an attack, the performance wouldn't be affected noticeably by dynamic keys either... would it?</p>
16:20 <+polecat> incremental trust really does help with handling late onset betrayers, I was thinking.</p>
16:20 <+fox> &lt;ailouros&gt; what's a "late onset betrayer"?</p>
16:20 <+polecat> Trust people more and more as they continue to benefit you, but never so much that they can take away more than they've given...</p>
16:20 < anti-> join for ages, then turn judas.</p>
16:21 < jrandom> right, peers get dropped out of the 'fast' tier quickly if they act poorly</p>
16:21 <+Complication> I'd think it would be someone behaving like "wait until 300 participating tunnels, crash"</p>
16:21 <+polecat> Oh, I make up phrases all the time. Yeah, Judas type betrayal, where you genuinely help someone, then betray them with the idea of cashing in at the last minute.</p>
16:21 < anti-> oh no, the tunnels broken *rebuild*</p>
16:21 < jrandom> the peers promoted to the 'fast' tier during that time they're dropped should then suffice</p>
16:21 <+fox> * ailouros has fun with these incorrect bible refernces :D</p>
16:22 < jmg> speaking of high capacity, wow im getting between 400k and 600K constantly for the router today. (but maybe all those zero hops settings im using are helping)</p>
16:22 < jrandom> 600KBps?!</p>
16:22 <+polecat> Hopefully during the time it takes to get to 300 participating tunnels, you'll be required to help transfer enough data it wouldn't matter if you crashed.</p>
16:22 < jmg> yes</p>
16:22 <+fox> &lt;ailouros&gt; O_O what are you connected to?</p>
16:22 <+Complication> Such bandwidth is news to me :)</p>
16:22 < jrandom> damn, thats fast enough to start running into our bloom filters</p>
16:22 < anti-> ailouros: rude question to anony researchers ;)</p>
16:23 <+polecat> It's gotta be 600KBpm or ph.</p>
16:23 <+fox> &lt;ailouros&gt; sorry anti- :D but he was the first to speak</p>
16:23 <+polecat> puh!</p>
16:23 < jrandom> I'd love to get some stats from the oldstats.jsp page off you. but glad to hear its handling things :)</p>
16:23 < anti-> one day i will try from i2...</p>
16:23 < jrandom> hehe</p>
16:24 <+fox> &lt;ailouros&gt; sounds cool, I2P on I2</p>
16:24 < jmg> jrandom: im keeping graphs, ill monitor more closely, but yes i can confirm 600kB/s sustained for 2 minutes, about 5 minutes ago</p>
16:24 <+polecat> Has anyone tried to traverse a d-link router's firewall? I'm having no luck there whatsoever and my friend keeps forgetting to forward the port.</p>
16:24 < jrandom> nice jmg </p>
16:24 < anti-> polecat: do we do udp holepunching yet? i lost track</p>
16:25 < jrandom> anti-: yes, we do, for all but symmetric NATs</p>
16:25 < jrandom> polecat: if your friend has their model #, there are a few sites online listing what type of NAT it is</p>
16:26 < anti-> regarding late onset betrayal... might be an issue with a powerful adversary?</p>
16:26 < jmg> jrandom: of course bittorrent has been known to rape this connection at 4MB/s sustained, but Iv eased up on that a little lately</p>
16:26 < anti-> 24000 nodes, so you get one crashing every 10 seconds or so?</p>
16:26 <+polecat> symmetric NAT, as opposed to full cone?</p>
16:26 < jrandom> nice jmg </p>
16:26 < jrandom> hmm anti-?</p>
16:26 < jrandom> polecat: or restricted cone</p>
16:27 <+polecat> Wow, it can even do restricted cone that's impressive..</p>
16:27 < anti-> i don't think late onset betrayal would have any significant effect at all unless applied on an incredibly massive scale, at which other attacks would have more of an impact?</p>
16:28 < jrandom> yeah I'm not too worried about it anti-... it'd cost too much, and we can route around failures anyway, so the damage would be minimal</p>
16:28 <+Complication> Late betrayal kind of requires contributing a lot (as to get other machines relying on your machine).</p>
16:28 <+fox> &lt;ailouros&gt; incredibly massive scale = you are all the netries on almost everyone else's router?</p>
16:28 < anti-> that is exactly what anti-p2ps do now, but we do have anti-anti-p2ps now...</p>
16:29 <+fox> &lt;ailouros&gt; no wait anti-p2p send trash instead of good data</p>
16:29 <+fox> &lt;ailouros&gt; that's not the same</p>
16:29 < anti-> that's just a faster way of getting shitlisted, so you would never be listed well.</p>
16:29 < anti-> that wouldn't work against i2p at all, i think.</p>
16:29 <@cervantes> jmg: I've had 4-5mb/s off torrents before, but never anything like 600k over I2P...have you got beefy hardware too?</p>
16:29 <+polecat> I was more thinking independant of i2p persay. My government does a lot of late onset betrayal, though they try to keep it classified.</p>
16:29 < anti-> but we would probably bleed them dry of bandwidth first!</p>
16:29 < jrandom> anti-: if they're reliable for days on end, they can only attack once for less than 10 minutes</p>
16:30 < jrandom> exactly anti- :)</p>
16:30 <+polecat> Or in the context of online banking.</p>
16:30 < jmg> does anyone have easy instructions on setting up the Native BigInteger library for amd64? if not ill just figure it out</p>
16:30 < jrandom> heh polecat </p>
16:30 < jrandom> jmg: its built into jbigi.jar, but it should build on amd64 now</p>
16:30 < jrandom> though, I suppose this means we're now on 6.1) ??? </p>
16:31 < jrandom> anyone have anything else to bring up? :)</p>
16:31 < anti-> you'd need 20000 machines or something, with a rolling crash schedule, and i think the results would be disappointing; you would end up contributing far more to the network than you took away!</p>
16:31 < jrandom> that is the hope anti-</p>
16:31 <+fox> &lt;ailouros&gt; well, worst case scenario is that people must reseed</p>
16:31 < jmg> oh thanks</p>
16:31 <+polecat> 64 bit processor, 4mbit upload bandwidth, sounds like somebody's a lucky bastard.</p>
16:32 < anti-> or running a normal machine at a uni...</p>
16:32 <+fox> * ailouros looks at his uni's hardware list and frowns</p>
16:32 < anti-> a uni that doesn't buy dell ;)</p>
16:33 <+fox> &lt;ailouros&gt; I think we have a couple of dells... from 5 years ago IIRC</p>
16:33 <+fox> &lt;Sonium&gt; i think this is bad:</p>
16:33 <+fox> &lt;Sonium&gt; jvm 1 | java.lang.OutOfMemoryError</p>
16:33 <+fox> &lt;Sonium&gt; jvm 1 | java.lang.OutOfMemoryError</p>
16:33 <+fox> &lt;Sonium&gt; jvm 1 | java.lang.OutOfMemoryError</p>
16:33 <@cervantes> polecat: 4 megabyte ;-)</p>
16:33 < jrandom> Sonium: yeah, once it gets one OOM, it'll die fast</p>
16:34 <+fox> &lt;Sonium&gt; and this too:</p>
16:34 <+fox> &lt;Sonium&gt; jvm 1 | 21:21:44.484 CRIT [ Establisher] sport.udp.EstablishmentManager: Err</p>
16:34 <+fox> &lt;Sonium&gt; or in the establisher</p>
16:34 < jrandom> (subsequent OOMs are safe to ignore)</p>
16:34 < jrandom> once it gets a single OOM, you can ignore all subsequent errors</p>
16:34 <+fox> &lt;ailouros&gt; yeah but you shouldn't have the first OOM :D</p>
16:34 < jmg> polecat: the latency out here on the russian space station in phenominal though..</p>
16:34 < jrandom> true ailouros</p>
16:35 <+fox> &lt;ailouros&gt; oh, by the way... my router gets watchdogged quite often</p>
16:35 < jrandom> hrm, high cpu usage?</p>
16:35 <+fox> &lt;ailouros&gt; I guess it's just my unlucky installation?</p>
16:35 <+fox> &lt;ailouros&gt; not that I know of, the machine is rather unloaded</p>
16:36 <+fox> &lt;ailouros&gt; but I guess this is what I should expect from a buggy JVM on a somewhat bugged linux emulation layer</p>
16:36 < jrandom> what jvm are you using, and what os?</p>
16:36 <+fox> &lt;Sonium&gt; me?</p>
16:36 <+fox> &lt;ailouros&gt; Sun's Java(tm) 2 Standard Edition, JRE 5.0 Update 5 on NetBSD/i386 2.0.2</p>
16:37 < jrandom> ahhh yeah, I have done no testing on nbsd. fbsd is fine, but I don't have any experience w/ nbsd</p>
16:38 < jrandom> might be worth trying out gcj, perhaps we can dig into that after the meeting</p>
16:38 <+fox> &lt;ailouros&gt; it works rather well, but the real fun with this is that sometimes (depending on which bit he flipped when getting off the bed -- err restarting) the netbsd files get created with 540 permission :D</p>
16:38 <+fox> &lt;Sonium&gt; something really sucks here</p>
16:38 <+fox> &lt;Sonium&gt; jvm 1 | # Internal Error (53414645504F494E540E4350500175), pid=3500, tid=345</p>
16:38 <+fox> &lt;Sonium&gt; 6</p>
16:39 <+fox> &lt;ailouros&gt; sorry the netDb files are created 540</p>
16:39 <+fox> &lt;Sonium&gt; I think I will reinstall this later</p>
16:39 < jrandom> Sonium: what OS are you on? the jvm seems to be acting up</p>
16:39 <+fox> &lt;Sonium&gt; winxp</p>
16:39 < jrandom> yeah, if you're on 1.5.0_5, might be worth trying 1.4.2_09</p>
16:39 < anti-> i don't think that's i2p's problem...</p>
16:40 < jrandom> (1.4.2 has been more stable for me, requiring less resources)</p>
16:40 < jrandom> and i2p doesn't use any 1.5-isms, nor do we need the 1.5 GUI improvements</p>
16:40 <+fox> &lt;Sonium&gt; the curious thing is, that is never occured before</p>
16:40 <+polecat> Can't use azureus if you don't have 1.5 though, meh.</p>
16:40 <+fox> &lt;ailouros&gt; and of course I *DO* use azureus :|</p>
16:41 <+fox> &lt;ailouros&gt; but it isn't a real problem... not much, I think...</p>
16:41 <+fox> &lt;ailouros&gt; unless those messages about bob being fourth are relevant</p>
16:41 < jrandom> nah, those are safe to ignore</p>
16:41 < anti-> (am i the only one irked by utorrent and bitcomet not being open?)</p>
16:42 <+polecat> :o Damn you bob!</p>
16:42 < jrandom> ok, anyone have anything else for the meeting?</p>
16:42 < anti-> muffins?</p>
16:42 * cervantes can recommend ibm java 1.4.2 if you're after better resource handling</p>
16:42 <+polecat> anti-: Try mlnet. caml -&gt; weirdest language in the world, but it works well.</p>
16:42 <+fox> &lt;ailouros&gt; caml is cool</p>
16:42 <+fox> &lt;ailouros&gt; (if you can read it :D )</p>
16:42 <@frosk> hey, don't diss caml</p>
16:43 < anti-> prolog deserves a mention there, as does brainf**k et al</p>
16:43 <+polecat> caml has horrible docs. It took me half an hour to figure out that ! usually (sometimes) is a dereference operator.</p>
16:43 <@frosk> i'm paid to write ocaml :)</p>
16:43 <+polecat> jrandom: Didn't know I crashed a meeting, sorry.</p>
16:44 < jrandom> np, we're making up for our short meetings ;)</p>
16:44 * jrandom winds up</p>
16:44 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

144
i2p2www/meetings/157.log Normal file
View File

@@ -0,0 +1,144 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 157{% endblock %}
{% block content %}<h3>I2P dev meeting, November 22, 2005</h3>
<div class="irclog">
16:18 < jrandom> 0) hi</p>
16:18 < jrandom> 1) Net status</p>
16:18 < jrandom> 2) Fox hunt</p>
16:18 < jrandom> 3) ???</p>
16:18 < jrandom> 0) hi</p>
16:18 * jrandom waves belatedly from a house with its power restored</p>
16:18 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-November/001227.html</p>
16:19 < jrandom> 1) Net status</p>
16:20 < jrandom> not much to add beyond whats in the mail.. anyone have anything they want to bring up re: net status?</p>
16:21 < jrandom> if not, movin' on to 2) Fox hunt</p>
16:21 < zzz> great idea</p>
16:22 < jrandom> here, too, I don't have much to add beyond whats in the mail and Raccoon23's proposals..</p>
16:22 <+fox> &lt;ailouros&gt; I have something against the name "Fox hunt". I'd rather call it "Man hunt". Foxes did nothing wrong.</p>
16:22 < Raccoon23> hah</p>
16:22 < jrandom> aye, I concur zzz, it'll be quite helpful to give people a real incentive without the serious dangers of actual use </p>
16:23 < nickless_head> call it "&lt;politically correct animal&gt; hunt</p>
16:23 < Raccoon23> "Fox hunt" is the typical name for a ham radio contest where you try to find a rogue transmitter</p>
16:24 <+fox> &lt;ailouros&gt; I don't care for radio trasmitters called Fox, we're talking i2p here, no anonymous foxes allowed</p>
16:24 <+fox> &lt;ailouros&gt; :D</p>
16:24 * cervantes wonders if ailouros is aware of the name of changate</p>
16:24 < nickless_head> maybe "Dissident hunt"</p>
16:25 <@cervantes> &lt;fox&gt; &lt;ailouros&gt; :D</p>
16:25 <+fox> &lt;ailouros&gt; (err what's changate?)</p>
16:25 < jrandom> heh</p>
16:25 <@cervantes> ailouros: it's the bots that relay chat between different networks</p>
16:26 <+fox> &lt;ailouros&gt; you mean vulpine here?</p>
16:26 <@cervantes> chat over on i2p gets relayed to you as vulpine</p>
16:26 <@cervantes> and you chat is relayed to us via fox</p>
16:26 <@cervantes> ;-)</p>
16:26 <@cervantes> *your</p>
16:26 <+fox> &lt;ailouros&gt; so the hunt is for the poor slave-working bot? :D</p>
16:27 < Raccoon23> so yeah, I think there should be a bounty/info page set up. I think we should shoot for raising $1k</p>
16:27 <+fox> &lt;ailouros&gt; yeah sorry I don't usually go i2pchat :)</p>
16:27 <+fox> &lt;ailouros&gt; now, that's a bounty!</p>
16:28 < jrandom> Raccoon23: I agree, but it may be a bit premature to do so now. </p>
16:28 < jrandom> (we can always allocate funds out of the general fund to the bounty to kick start it when necessary)</p>
16:28 <+fox> &lt;ailouros&gt; start the hunt right now but without a bounty?</p>
16:28 <+fox> &lt;ailouros&gt; I mean, the sooner it starts, the more eyes get open</p>
16:28 < jrandom> for the fox hunt to make sense (aka help I2P), we need to do so carefully.</p>
16:28 < jrandom> no ailouros, I disagree.</p>
16:29 < jrandom> running the contest before I2P is ready would be very bad.</p>
16:29 < Raccoon23> yah</p>
16:29 < jrandom> both because it would waste people's time evaluating something that isn't done, and because it wouldn't tell anything useful</p>
16:30 <+fox> &lt;ailouros&gt; ....point taken</p>
16:30 < Raccoon23> and it would be bad press if vulns were "found" that were scheduled to be fixed in coming versions</p>
16:30 < jrandom> aye</p>
16:33 < jrandom> ok, anything else on 2), or shall we move on over to 3) ???</p>
16:34 < zzz> on the other part of the jrandom/raccoon23 thread, was it a conclusion to move to 2-hop-minimum? any other conclusions?</p>
16:35 < jrandom> hmm, its all a question of who one's adversary is, but it wouldn't really hurt to default to 2 +0-1 and would afford protection against a class of attacker</p>
16:35 < jrandom> other conclusions may be "hey, get rolling on 0.6.2" :)</p>
16:35 <+fox> &lt;ailouros&gt; how do I set the configuration so that the tunnels always have a set value (like 0+1 variance)? I keep getting default values every restart</p>
16:36 < jrandom> ailouros: you should be able to save the settings on /i2ptunnel/ </p>
16:36 < jrandom> or are you changing them on /configtunnels.jsp ?</p>
16:37 < Raccoon23> I think 1 hop tunnels allow a pretty weak attacker to do a lot in 0.6.1 at least. I would argue that 0.6.1.6 should not have 1 hop tunnels by default</p>
16:37 <+fox> &lt;ailouros&gt; configtunnels it is</p>
16:37 < jrandom> aye, agreed Raccoon23 </p>
16:37 < jrandom> ailouros: use /i2ptunnel/ and save your settings</p>
16:37 <+fox> &lt;ailouros&gt; didn't notice the new interface :D</p>
16:38 <@cervantes> ailouros: just added in 0.6.1.5</p>
16:38 < jrandom> yeah cervantes did some great work there ailouros</p>
16:38 <+fox> &lt;ailouros&gt; well, kudos for that</p>
16:39 <@cervantes> while we're on that subject, if folk are having troubles saving settins on the new interface, they might want to use a non-IE browser for now until the next release</p>
16:39 <@cervantes> *grumble* microsoft *grumble*</p>
16:40 <+fox> &lt;ailouros&gt; on a different topic, would anyone be interested if I set up a nethack server on i2p? :D</p>
16:41 <@frosk> ailouros: been thinking about it (playing nethack irl), but the lag would be horrible i'm afraid (and lag sucks really hard when playing nethack)</p>
16:42 <+fox> &lt;ailouros&gt; guess so</p>
16:42 <+fox> &lt;ailouros&gt; okay, idea scrapped</p>
16:43 * frosk just had his first ascension a few months back, woot</p>
16:44 < jrandom> ok, anyone have anything else for the meeting?</p>
16:45 <+fox> &lt;ailouros&gt; yes, some indicator for syndie wen the thread has a new message</p>
16:46 < nickless_head> jrandom: and it would be cool if new messages (the titles) could be printed in bold/italics the first time they're displayed</p>
16:47 < nickless_head> jrandom: is there a _really simple_ way to get to the messages in the syndie database, over http?</p>
16:47 < jrandom> ah yeah ailouros/nickless_head, I'm thinking of color coding/flagging the first column by date (e.g. things posted today get a bright flag, yesterday a less bright, etc). </p>
16:47 < nickless_head> jrandom: preferredly in something nice and importable like xml</p>
16:48 < jrandom> nickless_head: wget -R http://localhost:7657/syndie/archive/</p>
16:48 < nickless_head> if there is, I could write a syndie to nntp exporter</p>
16:48 < jrandom> oh, if you want to export to nntp, use rss to nntp</p>
16:48 < nickless_head> jrandom: ok I'll try that :)</p>
16:48 < nickless_head> jrandom: that already exists? ... damn. ;)</p>
16:49 < jrandom> i'm also thinking about adding per-user message histories to let you mark messages as read/unread, but that probably won't be in 0.6.1.6 (unless someone else implements it :)</p>
16:49 < jrandom> or perhaps a new filter on the thread tree - only show messages posted since [today |v]</p>
16:49 < jrandom> (or yesterday, or 2 days ago)</p>
16:50 < jrandom> nickless_head: http://www.methodize.org/nntprss/</p>
16:50 < nickless_head> jrandom: thanks</p>
16:54 < jrandom> np</p>
16:54 < Raccoon23> jrandom: so it'd be a while before I'd be able to implement it (I wanna get restricted routes done first), but what do you think about optional 1024bit garlic routing for outbound server tunnels?</p>
16:54 < jrandom> tremendous overhead - O(data) is &gt;&gt;&gt; O(tunnels). if we're running into trouble now with O(tunnels), there's no way we can hope for O(data)</p>
16:55 < Raccoon23> are we still having cpu issues? my router has been pretty low, but I don't exactly have a T1 over here..</p>
16:56 < jrandom> not everyone has p4s ;)</p>
16:56 < jrandom> i hear reports of 8-15% usage on slow machines, but that spikes bad under congestion</p>
16:56 < jrandom> (to 100+%)</p>
16:56 <+Complication> About CPU consumption: curiously enough, Java on Mandriva 10.1 consumes a lot less than Java on Mandriva 2006.</p>
16:56 < Raccoon23> yah, but those who don't probably don't have T1</p>
16:56 < Raccoon23> either :)</p>
16:57 <+Complication> Both tweaked, 2006 has jbigi compiled locally.</p>
16:57 < jrandom> weird Complication </p>
16:57 < jrandom> same revs of i2p?</p>
16:57 <+Complication> On 2006 (Celeron 2.4) java can hit 20%.</p>
16:58 <+Complication> On 10.1 it wouldn't go higher than 5%.</p>
16:58 <+Complication> (Usually)</p>
16:58 <+Complication> (usually==not on startup)</p>
16:58 <+Complication> Same revisions.</p>
16:58 <+Complication> Almost the same Java too (_04 versus _05)</p>
16:59 <+Complication> Reminds me to tweak daemons a bit more. Perhaps some of them is obstructing java.</p>
16:59 <+Complication> In some wacky way I cannot figure out.</p>
17:00 <+Complication> But yes, the Cel 300 is feeling notably better. Could have been the adaptive MTU</p>
17:01 < jrandom> ah cool, yeah, we've got some neat stuff on the way :)</p>
17:03 <+Complication> I wonder if there'd be a way to get past the libc-related jbigi problems on certain Linux distros?</p>
17:03 < jrandom> yeah, definitely, just need to rebuild all the jbigis </p>
17:03 < jrandom> (its not libc, its libg++)</p>
17:05 * Raccoon23 decides he doesn't give up his dreams of garlic routing, but will wait for performance to stabilize.. perhaps 2.0</p>
17:05 <+Complication> Oh, you think a proper rebuild will help it?</p>
17:05 < jrandom> Complication: yeah, the jcpuid link errors are unnecessary, as jcpuid is really just an ASM call (and shouldn't have been implemented in c++ anyway ;)</p>
17:06 < jrandom> Raccoon23: cool :) its something we can do eventually over the live net too, just using a different I2NP message type, advertising the right capability, and filtering on that</p>
17:06 < jrandom> (eventually)</p>
17:07 < Raccoon23> like a caps=S for speedy CPU? ;) </p>
17:08 < jrandom> and caps=I for insane ;)</p>
17:08 < jrandom> ok, anyone else have something for the meeting?</p>
17:08 < Raccoon23> haha</p>
17:09 < Raccoon23> what do you think about the stopgap of sharing keys across multiple tunnels? too little payoff for the work?</p>
17:09 < jrandom> why would that be better than just having multiple tunnels and sending the message through one of the multiple tunnels?</p>
17:10 < jrandom> (and, erm, wouldn't it be worse, from a security perspective, and anonymity perspective)</p>
17:10 < Raccoon23> well the idea is that nodes could not tell which traffic was part of one tunnel, so that if you were running i2phex and and eepsite, and choose the same hosts for your tunnels, the traffic from the two would be blended as far as the hops could see</p>
17:11 < Raccoon23> which should make timing attacks harder</p>
17:11 < jrandom> ah, yikes, yeah. that adds Really Bad linkability</p>
17:11 < jrandom> its why we moved to per-client tunnel pools in 0.4</p>
17:11 < Raccoon23> explain?</p>
17:11 < jrandom> i2ptunnel does let people share pools, if they want, by sharing the same destination</p>
17:12 < jrandom> if messages for 2 clients go down a tunnel, you know both of those clients are controlled by the same person</p>
17:12 < jrandom> s/clients/destinations/</p>
17:13 < Raccoon23> well if keys were shared, the early hops could be blended, but the leasesets seperate..</p>
17:13 < Raccoon23> the early hops being the dangerous ones for timing attacks anyways</p>
17:13 < jrandom> it'd still allow a vector for linking the two unlinkable destinations</p>
17:14 < jrandom> one could do some munging to hopefully obfusticate the linkability, but they'd be inherently linked. which isn't necessary, and is bad.</p>
17:18 < Raccoon23> back to dreaming of caps=SI I guess :)</p>
17:19 < jrandom> ah well. ok, anyone have anything else?</p>
17:20 * jrandom winds up</p>
17:20 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

228
i2p2www/meetings/158.log Normal file
View File

@@ -0,0 +1,228 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 158{% endblock %}
{% block content %}<h3>I2P dev meeting, November 29, 2005</h3>
<div class="irclog">
15:25 < jrandom> 0) hi</p>
15:25 < jrandom> 1) Net status and 0.6.1.6</p>
15:25 < jrandom> 2) Syndie</p>
15:25 < jrandom> 3) I2P Rufus 0.0.4</p>
15:25 < jrandom> 4) ???</p>
15:25 < jrandom> 0) hi</p>
15:25 * jrandom waves</p>
15:25 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-November/001234.html</p>
15:26 * bar hands jrandom a baf</p>
15:26 < c3rvantes> not yet!</p>
15:26 * jrandom winds up</p>
15:26 < jrandom> er...</p>
15:26 < jrandom> lets hit the first few agenda items first :) 1) Net status and 0.6.1.6</p>
15:27 < jrandom> lots of things have been updated in the last few releases, but the network still seems reasonably stable. </p>
15:28 < jrandom> we've had some serious spikes in router participation on a few routers, though thats pretty harmless</p>
15:28 <+legion> cool, I agree net status is getting better. Also yeah why not drop tcp for 0.6.1.7</p>
15:28 < jrandom> (er, spikes in tunnel participation, that is)</p>
15:29 <@cervantes> you're not kidding</p>
15:29 < jrandom> not sure legion. there may be some users out there limited to tcp only, but i seem to recall that there was only one or maybe two of those</p>
15:29 <+legion> well I've noticed with 0.6.1.5 the router would sometimes restart on its own.</p>
15:29 <+Complication> Mine's been swinging withint reasonable limits, 100 to 250 participating tunnels</p>
15:29 < jrandom> I can't think of any great reason to keep it, and I can think of a few to drop it</p>
15:30 < jrandom> cool Complication</p>
15:30 < jrandom> (those numbers are fairly average, according to stats.i2p/, but remember, numbers like that can damage anonymity, so shouldn't really be given out, especially not in logged meetings ;)</p>
15:30 <+Complication> My old Celeron is still auto-restarting every 10 hours or so</p>
15:30 <+Complication> Otherwise it's better connected than ever before</p>
15:30 < Pseudonym> what are the reasons to drop it?</p>
15:31 <+Complication> TCP is expensive</p>
15:31 <@cervantes> my router is shagged out</p>
15:31 <+Complication> In terms of threads per connections</p>
15:31 <@cervantes> Complication: multiply that by 10 and you get my router's current range ;-)</p>
15:31 <+legion> Mines been swinging within 200-400 participating tunnels, so it seems better than ever.</p>
15:32 <+Complication> cervantes: ouchie ouchie</p>
15:32 <+Complication> I've seen a freak accident which caused 2000 participating tunnels, but that was in Summer</p>
15:32 < jrandom> Pseudonym: performance (cpu/memory, better scheduling due to our semireliable requirements), maintainability, more effective shitlisting</p>
15:32 <+Complication> A single spike which never repeated again</p>
15:32 <+legion> yeah, with some past versions there were such spikes</p>
15:32 < jrandom> Complication: we've had &gt; 2000 tunnel spikes with this last rev</p>
15:33 < jrandom> but hopefully 0.6.1.7 will take care of that</p>
15:33 <+legion> Well those are some good reasons to drop tcp :)</p>
15:33 < jrandom> but, again, the spikes in tunnel participation is fine, as most of them aren't used</p>
15:34 <@cervantes> Pseudonym: there only seems to be one or two routers still using tcp on the network</p>
15:34 < jrandom> it may also be a good idea to drop tcp in this rev too, since it doesn't have other major changes. that way we can see how it affects things pretty clearly</p>
15:34 < jrandom> (and can reenable it if necessary)</p>
15:35 < Pseudonym> if there are only two routers using it, I can't imagine it would have much effect either way</p>
15:35 < Pseudonym> (except for there being two less routers on the network)</p>
15:35 <@cervantes> 2 disgruntled customers</p>
15:35 < jrandom> well, the transport does show up in some odd situations, which is one of the reasons i want to disable it :)</p>
15:35 <+Complication> I hope they won't take it very personally</p>
15:36 <+Complication> It's really nasty of certain ISP's to filter UDP.</p>
15:36 <+Complication> Nasty, and completely senseless.</p>
15:36 < jrandom> (e.g. when a router is hosed, people mark their SSU transport as failing, and as such, they fall back on the tcp transport)</p>
15:36 * Pseudonym loves his ISP. no restrictions</p>
15:37 <+Complication> So without TCP, one would see how UDP handles it alone?</p>
15:37 <+Complication> "with no auxiliary wheels" :P</p>
15:37 <+legion> huh so how do we get around such nasty filtering without tcp?</p>
15:38 < jrandom> exactly Complication :)</p>
15:38 < jrandom> legion: we don't</p>
15:38 < jrandom> (restricted routes)</p>
15:38 <+Complication> Well, aren't there a number of useful apps besides file-sharing programs, which also use UDP packets sized above DNS packets?</p>
15:39 <+legion> :( doesn't sound good</p>
15:39 <+Complication> Sized similarly to the smallest packet size I2P uses?</p>
15:39 < jrandom> eh legion, its not a problem</p>
15:39 < jrandom> Complication: streaming protocols</p>
15:39 <+Complication> One cannot block UDP directly, ever, without crippling DNS.</p>
15:39 <+Complication> One can limit the packet size.</p>
15:40 <+legion> ok, it did sound like it could be</p>
15:40 <+Complication> VoIP?</p>
15:40 < jrandom> it'd be a problem if it were widespread - if the internet community in general banned udp</p>
15:40 <+Complication> Hmm, does VoIP use big or small packets?</p>
15:40 < jrandom> but if its just a few isps, we can treat them like restricted routes</p>
15:40 <+Complication> Or did you mean more like... video spreaming?</p>
15:40 <+legion> I'd think it'd use a mix of both</p>
15:41 < jrandom> both Complication, RTSP runs over UDP, and real runs over RTSP iirc</p>
15:41 <+Complication> s/p/s</p>
15:42 <+legion> So on to the next item?</p>
15:42 <+Complication> cat /etc/services | grep -c udp</p>
15:42 <+Complication> 227</p>
15:43 < jrandom> I'm still not sure if we'll drop tcp in 0.6.1.7, but probably. </p>
15:43 < jrandom> aye, anyone have anything else on 1)? if not, lets jump on to 2) Syndie</p>
15:43 <+Complication> Meaning, there are at least 227 apps (some possibly obsolete or LAN apps) which use UDP</p>
15:44 < jrandom> bah, this is the intarweb. all you need is proxied HTTP access</p>
15:44 < jrandom> I don't have much to add to 2) beyond whats in the mail (and whats on Syndie)</p>
15:44 <+legion> I'm convinced, yeah drop it. :)</p>
15:44 < jrandom> anyone have anything re: syndie they want to bring up?</p>
15:45 <+legion> I've nothing to say about 2) either.</p>
15:45 * Complication is reading "how Syndie works"</p>
15:46 <+Complication> One little UI effect, keeps surprising me. :D</p>
15:46 <+Complication> When I expand a thread of messages, it always gets me by surprise that the active message moves to become the topmost in the list. :P</p>
15:47 <+Complication> But you can proabably safely ignore that. I'm just very picky, and a creature of habit. :P</p>
15:47 <@cervantes> the threading model is something that's being discussed at length</p>
15:47 <@cervantes> ;-)</p>
15:47 <+Complication> I'll get used to it. :)</p>
15:48 <+Complication> cervantes: in Syndie? I gotta find that thread. :)</p>
15:48 <@cervantes> I don't like that either - but it could well change</p>
15:48 < jrandom> yeah, thats kind of kooky I suppose</p>
15:48 <+legion> yeah</p>
15:48 <@cervantes> "subject: syndie threading"</p>
15:49 <+Complication> Besides, if the expanded message were the bottom-most, it *would* have to move anyway.</p>
15:49 <+Complication> 'Cause otherwise it'd be stuck there.</p>
15:50 < jrandom> well, the nav at the bottom shows 10 *threads* at a time, not 10 messages. so it could expand the bottom thread</p>
15:50 * cervantes is testing some different threading UI style implementations atm</p>
15:51 < jrandom> wikked</p>
15:51 < jrandom> yeah, ideally we'll be able to switch them around in css, or if not, on the server side</p>
15:52 <@cervantes> or rather "threading navigation styles"</p>
15:53 <@cervantes> hmm my tests use pure html nested unnordered lists by default</p>
15:53 <@cervantes> you can layer on as much css and javascript as your need or want</p>
15:53 < jrandom> any eta on when we can see some mockups?</p>
15:53 <@cervantes> (however it's only a proof of concept, not an actual ui implementation)</p>
15:54 <@cervantes> I do most of my coding during I2P meetings ;-)</p>
15:54 < jrandom> heh</p>
15:54 <@cervantes> perhaps the first mockup will be ready this evening</p>
15:54 * jrandom schedules daily meetings</p>
15:54 < jrandom> wikked</p>
15:54 <@cervantes> curses :)</p>
15:55 < jrandom> ok, anyone have anything else for 2) syndie?</p>
15:55 < jrandom> if not, lets move on to 3) I2P Rufus 0.0.4</p>
15:56 < jrandom> I don't have much to add beyond whats in the mail - Rawn/defnax, y'all around?</p>
15:56 <+legion> so how good is 0.0.4? What problems remain if any?</p>
15:57 * jrandom hasn't a clue</p>
15:58 <+legion> Maybe one of its users can answer. Does it seem good and stable?</p>
15:58 < jrandom> ok, seems Rawn and defnax are away atm. if anyone has any questions/comments/concerns regarding I2P Rufus, swing on by the forum and post 'em away</p>
15:58 <+legion> darn, guess we'll have to.</p>
15:59 <+legion> on to 4)?</p>
15:59 < jrandom> aye, so it seems. ok, 4) ??? </p>
15:59 <+Complication> I haven't tried I2P Rufus, unfortunately.</p>
16:00 < jrandom> anyone have anything else they want to bring up?</p>
16:00 < jrandom> (c'mon, we've got to drag this out so cervantes can do some more work!)</p>
16:00 <+legion> yeah, what sort of interesting stuff is coming down the pipe?</p>
16:00 <+bar> is there anywhere i could read more about "restricted routes"?</p>
16:00 <+bar> (i *have* searched)</p>
16:01 <+legion> Maybe we could even discuss i2phex?</p>
16:01 < jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD</p>
16:01 * cervantes poises his mouse over the close button</p>
16:01 < jrandom> er, #future.restricted</p>
16:02 < jrandom> plus the how_* pages & todo</p>
16:02 < jrandom> (on the web)</p>
16:02 <+Complication> Heh, I2P seems to have skipped a build :D</p>
16:02 <+Complication> :D</p>
16:02 <+bar> thanks</p>
16:02 <+Complication> - public final static long BUILD = 1;</p>
16:02 <+Complication> + public final static long BUILD = 3;</p>
16:03 < jrandom> legion: some hacking on the netDb, performance mods, restricted routes, streaming improvements, eepproxy improvements, tunnel improvements, etc. lots of stuff, but nothing ready yet</p>
16:03 <+legion> huh, odd</p>
16:03 < jrandom> anything to bring up re: i2phex legion?</p>
16:03 < jrandom> Complication: yeah, intended. I forgot to increase it for BUILD = 2</p>
16:03 <+Complication> (not that it matters for anything, just wondering if I've seen this rare occasion before :)</p>
16:04 <+legion> sweet, sounds great, thanks!</p>
16:04 < jrandom> oh, that reminds me... it'd be cool if someone wanted to dig into looking at revamping our webpage</p>
16:05 * jrandom doesnt want to think about it, but its got to be done sooner or later</p>
16:05 <+legion> yeah, there is</p>
16:05 <+legion> would it be worthwhile to update i2phex at this point to the latest phex cvs code?</p>
16:06 <+Complication> Not sure, I haven't heard from Redzara recently</p>
16:06 < jrandom> last I recall, redzara was waiting on gregorz's updates to phex</p>
16:06 < jrandom> (so we could have a fairly clean update/extension)</p>
16:08 <+legion> huh, then why have i2phex?</p>
16:08 <+Complication> Just in case?</p>
16:08 < jrandom> hmm?</p>
16:08 < jrandom> i2phex is an extension to phex</p>
16:08 <+legion> Seems like they wanted there to just be phex with a i2p extension</p>
16:09 < jrandom> extension, as in, modification to a very small number of bits</p>
16:09 < jrandom> er, s/bits/components/. so we can easily update the code whenever the phex devs fix things</p>
16:10 <+legion> if so then it shouldn't take much work for me to update it to the latest cvs code, though I know it will.</p>
16:10 < jrandom> last I heard in the forum was that the plan is to have I2Phex and Phex be separate applications, but they'd share a majority of code</p>
16:10 < jrandom> aye legion, that'd be great, but last I heard, Gregor hadn't finished the modifications to Phex yet</p>
16:11 < jrandom> (which is what redzara was waiting on)</p>
16:11 <+legion> ah I see</p>
16:11 < jrandom> so, the alternative is to either help Gregor out or continue modifying the existing I2Phex codebase</p>
16:12 <+legion> well then if I don't wait and just update i2phex with new code, there would be no need for redzara continue</p>
16:12 < jrandom> well, not really. </p>
16:12 < jrandom> updating I2Phex to the current Phex code would be great, yes</p>
16:13 < jrandom> but as soon as the Phex developers update their Phex code, we're out of sync again</p>
16:13 <+legion> ok, I'll probably get to it sometime tonight or within a couple days.</p>
16:13 < jrandom> wikked</p>
16:13 <+legion> That is fine.</p>
16:14 <+legion> Really I'm not looking to have i2phex remain in sync with phex code, it's just that it sounds like the cvs contains fixes which i2phex could certainly use.</p>
16:15 <+legion> Also I'm really looking to drop out any phex code and features which i2phex doesn't need.</p>
16:15 < jrandom> cool</p>
16:16 <+legion> As to any new features and fixing anything that is still not working like the upload queues... Well I've already looked into getting the webcaches working, but have much more to do.</p>
16:17 < jrandom> word. yeah, phex used to have working gwebcache support, but sirup disabled it, as it wasn't necessary at first</p>
16:17 <+legion> I do plan on adding jeti to i2phex eventually.</p>
16:17 < jrandom> neat</p>
16:18 * jrandom has never used jeti, and I hope it stays an optional component, but supporting more things is cool</p>
16:18 <+legion> Yeah it can be optionally, users will be able to download a jeti2phex ;)</p>
16:19 < jrandom> word</p>
16:19 <+legion> There still is much we can do with i2phex, though it is working great as it is.</p>
16:20 <+legion> So far keeping a client connected, up and running for 24/7 is possible and easy.</p>
16:21 < jrandom> yeah, I've had some good success with it... "backing up my licensed recordings"</p>
16:21 <+legion> heh :)</p>
16:22 < jrandom> ok, anyone else have anything for the meeting?</p>
16:23 * cervantes wheels in the chinese gong</p>
16:23 <+legion> Seems like I'm forgetting something... hmm</p>
16:24 <+legion> Oh yeah, any ideas on how we can reduce the amount of memory i2p and i2phex consumes?</p>
16:25 <+Complication> Well, the TCP transport takes a bit</p>
16:25 < jrandom> one could run both in the same jvm</p>
16:25 <+Complication> If that is going, it will free a bit</p>
16:26 <@cervantes> take some ramsticks out of your machine</p>
16:26 < cat-a-puss> anyone with any experence with javolution know if it would help? http://javolution.org/</p>
16:26 < jrandom> (clients.config in the i2p install dir defines the main class and arguments to launch clients)</p>
16:26 <+legion> So if we ran both in the same jvm and when tcp goes, could we bring it down to under 50mb?</p>
16:27 < jrandom> no idea legion. depends on what you mean by 50MB as well. RSS/VSS/etc</p>
16:27 < jrandom> I really wouldn't recommend running both in one JVM though, unless you keep both running all the time, since shutting down one would kill the other</p>
16:27 <@cervantes> legion: limiting bandwith and capping participants might also help</p>
16:27 < jrandom> aye, what cervantes said</p>
16:28 < cat-a-puss> it would seem to me that if we know exactly how many of some type of object we are eventually likely to use, it would help prevent overzellous jvm allocation</p>
16:28 <+Complication> Right, it makes those different allocations, which I've never really managed to make sense of</p>
16:28 < jrandom> aye, we do some of that cat-a-puss (see net.i2p.util.ByteCache)</p>
16:29 <+Complication> (but as said, Java is a very new thing to me)</p>
16:29 < jrandom> I've glanced at javolution before, but it seems to have made a lot of progress. i'll give 'er another look</p>
16:30 < cat-a-puss> jrandom:I know some people at my work use it and are happy with it, though they don't care about memory allocation</p>
16:31 < jrandom> well, it really wouldn't save any memory, but would help cut down on GC churn</p>
16:31 <+legion> Well I personally don't care much about memory allocation, however many people do.</p>
16:31 < jrandom> ooh, and its BSD licensed too</p>
16:31 < cat-a-puss> right</p>
16:31 < jrandom> legion: memory allocation means performance</p>
16:32 <+legion> er, oh, memory consumption then</p>
16:33 <+legion> Many people are so very happy with utorrent because of it's very small memory footprint.</p>
16:33 < jrandom> ah, oh, yeah. we can tweak it down the line, but since i2p runs within the default jvm sizes, i'm not too worried (as we've got lots of room for tweaking)</p>
16:34 < jrandom> ok, anyone have anything else for the meeting?</p>
16:35 <+legion> nah I'm good...</p>
16:37 * jrandom winds up</p>
16:37 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

266
i2p2www/meetings/159.log Normal file
View File

@@ -0,0 +1,266 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 159{% endblock %}
{% block content %}<h3>I2P dev meeting, December 6, 2005</h3>
<div class="irclog">
15:26 < jrandom> 0) hi</p>
15:26 < jrandom> 1) 0.6.1.7 and net status</p>
15:26 < jrandom> 2) Experimental tunnel failures</p>
15:26 < jrandom> 3) SSU and NATs</p>
15:26 < jrandom> 4) Syndie</p>
15:26 < jrandom> 5) ???</p>
15:26 < jrandom> 0) hi</p>
15:26 * jrandom waves</p>
15:26 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2005-December/001237.html</p>
15:26 * ailouros read the notes</p>
15:27 * jrandom is late, so I'll give y'all a moment to read up :)</p>
15:29 < jrandom> ok, might as well jump on in to 1) 0.6.1.7 and net status</p>
15:29 <@cervantes> *cough*</p>
15:29 < jrandom> I don't have much more to add beyond whats in the mail on this point. anyone have any further comments/questions/ideas?</p>
15:30 < Pseudonym> seems like doing performance optimization before changing the the tunnel creation algo might be backwards</p>
15:30 < gott> I am getting a lot of "No HTTP method found in the request.</p>
15:30 < gott> Software caused connection abort: socket write error</p>
15:30 < gott> "</p>
15:30 <@modulus> tunnel lag is much lower, i don't know if you made any changes or my ISP is better all of a suden.</p>
15:30 < gott> from the I2PTunnel Webmanager</p>
15:31 < jrandom> gott: those suggest bad http requests, or things that the eepproxy ouldn't understand</p>
15:31 < jrandom> modulus: cool, we've been doing lots to try and improve things</p>
15:31 < jrandom> Pseudonym: well, so far tunnel creation hasn't been our choke point - our choke point was much higher level stuff</p>
15:32 < jrandom> otoh, the improvements of the last few revs have exposed some issues down there</p>
15:32 < Pseudonym> oh, so the optimization has been related to other parts of the code?</p>
15:32 < Pseudonym> cool</p>
15:33 < jrandom> aye, at the SSU level, as well as the tunnel operation level. tunnel creation is not a performance sensitive operation [except when it is ;]</p>
15:34 < jrandom> I'm doing some live net load testing though, gathering some non-anonymous load stats of different peers to try to narrow things down further</p>
15:34 < ailouros> I wonder why sometimes I see more tunnels than those configured for a destination (eg. eeProxy, inbound 7 tunnels 4 outbound)</p>
15:34 < jrandom> so, over the next few days when you see the router 7xgV transferring lots of data, well, dont mind it ;)</p>
15:35 < jrandom> ailouros: when tunnel creation takes a while, it builds extras, just in case. </p>
15:35 < jrandom> zzz outlines a few of the odd issues on that front too, and there's a patch being worked on to improve things a bit</p>
15:35 < ailouros> I see.. but then why they all expire at the same time?</p>
15:35 <@cervantes> jrandom: out of curiosity, when did you begin those tests?</p>
15:35 < jrandom> cervantes: a few days ago</p>
15:36 <@cervantes> ah cool, it's _not_ that then ;-)</p>
15:36 < jrandom> dunno ailouros, depends on a few conditions. but there are some... *cough* oddities in the tunnel creation code, which I've been holding off messing with since its getting rewritten for 0.6.2</p>
15:38 < ailouros> I see. I thought it was a policy matter... I'd rather see the tunnels die at different times unless there's a good reason not to</p>
15:38 < ailouros> as in, tunnel creations are skewed</p>
15:39 < jrandom> aye, there will be better randomization for 0.6.2, and zzz's patch adds some randomization for the current rev too</p>
15:40 <+Complication> I wonder why an otherwise sane instance of i2phex... would decide to rehash files every other time I start it?</p>
15:40 < jrandom> not a clue</p>
15:40 <+Complication> Damaged configuration sounds the likely cause so far, but I've not deleted my config yet.</p>
15:40 < jrandom> perhaps skewed timestamps?</p>
15:42 <+Complication> Nah, they seem correct too</p>
15:42 * jrandom knows not. never looked at that part of phex's cod</p>
15:42 < jrandom> er, code</p>
15:42 <+Complication> I'll see if deleting old config files does it any good</p>
15:42 < jrandom> cool</p>
15:43 < jrandom> ok, anything else on 1) Net status / 0.6.1.7?</p>
15:43 < jrandom> if not, moving on to 2) Experimental tunnel failures</p>
15:44 < jrandom> we've touched on this a bit already, and there's more in the notes and on zzz.i2p</p>
15:44 < jrandom> zzz: do you have anything you want to add/bring up?</p>
15:46 < jrandom> if not, lets move on to 3) SSU and NATs</p>
15:46 < jrandom> bar: anything you want to add?</p>
15:46 <+bar> nope, i have nothing else to add but what's in the mail</p>
15:47 < jrandom> cool, yeah I've still got to reply to some of the details - i think our retransmission will already take care of some of the issues you bring up</p>
15:48 < jrandom> the trick is going to be detecting which situation is in play, so we can automate the right procedure (or inform the user that they're screwed)</p>
15:48 <+bar> all in due time, no hurry</p>
15:49 <+bar> aye, i suggested a manual user setting to circumvent that problem for the time being, perhaps it's not possible, but we can discuss it later</p>
15:50 < jrandom> yeah, manual overrides will help, but my experience with earlier i2p revs was that everyone (*everyone*) fucked it up ;) so automation is preferred </p>
15:50 < jrandom> (everyone meaning myself included ;)</p>
15:52 <+bar> agree</p>
15:52 < ailouros> lol if I did too then there were something wrong with the docs, as I followed them bit by bit :D</p>
15:53 <+bar> meanwhile, i will spend some time studying the peer testing</p>
15:53 < jrandom> cool, thanks bar!</p>
15:54 <+bar> (perhaps i could generate some useless spam regarding that as well :)</p>
15:54 < jrandom> :)</p>
15:55 < jrandom> ok, if there's nothing else on 3), lets move on to 4) Syndie</p>
15:56 < jrandom> there has been a lot of progress on this front lately, with pretty substantial UI revamps since 0.6.1.7 came out</p>
15:57 < jrandom> there's also a new standalone install/build, though since all of us have i2p installed, we don't need a separate one </p>
15:57 < ailouros> I find that 6.1.7's layout is harder to use than 6.1.6's</p>
15:58 < jrandom> hmm, are you running syndie in single user mode? and/or are you using the latest CVS build or the official 0.6.1.7 build?</p>
15:58 < ailouros> official 0.6.1.7, single user</p>
15:58 < jrandom> are you one of the proponents of the blog-like interface, as opposed to the threaded nav?</p>
15:58 < ailouros> I am not, though I don't really know which is the blog-like</p>
15:58 < ailouros> personally I'd rather have a threaded nav</p>
15:59 < ailouros> (and some color-coding of new messages as well in thread view)</p>
15:59 <+Complication> Relatively late CVS, single user</p>
15:59 <+Complication> I've found a minor oddity (which I think, could be non-intended)</p>
15:59 < jrandom> ah, there has been a lot of progress on that front in CVS ailouros </p>
15:59 < ailouros> great :)</p>
16:00 < jrandom> we've got a new threaded display too, using cervantes' suggested full traversal of just one branch, as opposed to all branches</p>
16:00 <@cervantes> are those changes pushed to syndiemedia.i2p.net?</p>
16:00 <+bla> Would it be a good idea to show some default examples for the location in http://localhost:7657/syndie/syndicate.jsp ?</p>
16:00 < jrandom> syndiemedia.i2p.net is CVS head, yeah</p>
16:00 <+Complication> When you've opened up a thread, and are currently reading its posts... and then choose to apply a filter to which no posts match (e.g. open thread "Syndie threading", apply filter "i2p.i2phex")...</p>
16:00 < jrandom> aye, perhaps bla. new installs will have the three defaults in there, but examples would be good</p>
16:01 <@cervantes> (the actual thread's tree needs to fully open too though)</p>
16:01 <+Complication> ...it appears to leave the current posts displayed, as if they were matching or something...</p>
16:01 <+Complication> Despite me definitely clicking the "Go" button.</p>
16:01 <@cervantes> Complication: yeah I found that confusing too</p>
16:02 < jrandom> hmm Complication, the general idea was to let you browse around while still looking at a post, but perhaps it'd be best to drop the posts being displayed</p>
16:02 < jrandom> cervantes: ah, yeah expanding it to the leaf would be good, and should be trivial to do</p>
16:02 <+Complication> Just noticed, and since it stuck out, thought I'd tell</p>
16:02 <@cervantes> (or make it more obvious that there aren't any matches)</p>
16:03 < jrandom> well, the thread nav says *no matches* :)</p>
16:03 < ailouros> perhaps he's looking for a lighter</p>
16:03 < jrandom> !thwap</p>
16:03 <@cervantes> (or make it even more obvious that there aren't any matches)</p>
16:03 < jrandom> &lt;blink&gt;No matches&lt;/blink&gt;</p>
16:03 <+Complication> Oops :)</p>
16:04 < tethra> seems your !thwap got spaetz__ instead, jr!</p>
16:04 <+Complication> Right, sometimes the thread navigator *does* feel a long distance away :)</p>
16:04 < jrandom> yeah, we're experimenting with some css to float that down the side, as an option</p>
16:05 <@cervantes> with skinning support you could have the thread top buttom left right etc</p>
16:05 <@cervantes> ah as jr said</p>
16:05 <+Complication> The "Threads" link takes one there fairly quick, though</p>
16:05 <+Complication> ...if it's within the viewport currently.</p>
16:06 <+Complication> And those who are used to keyboard-navigating can naturally press "End"</p>
16:06 < jrandom> of course, this stuff is really simple to modify (as you can see from the rapid changes in CVS :), so if anyone has any suggestions (or mockups - html / png / etc), please, post 'em up whenever</p>
16:07 < jrandom> I expect we'll have a main blog overview page in the next few days in cvs</p>
16:08 < jrandom> ok, there's lots of other stuff going on w/ syndie, so swing on by http://localhost:7657/syndie/ for more info :)</p>
16:08 < jrandom> anyone have anything else to bring up on that, or shall we move on to 5) ???</p>
16:09 < zzz> hi just walked in. on 2), I'm looking for testers for my patch. </p>
16:10 < zzz> My results are improvements in job lag and reliability, and reduction in router hangs. So hoping others will try.</p>
16:10 < ailouros> that sounds good enough. what do I have to do?</p>
16:11 < jrandom> heya zzz, ok cool, i'll be bashing it around a bit here too. its got lots of different components to it, so might be worth splitting up into pieces, but it does look good and is on track for 0.6.1.8</p>
16:11 < ailouros> (average uptime is about 10h here :(</p>
16:11 < zzz> If you have source code and ant just apply the patch - or I can put up an i2pupdate.zip if you want</p>
16:12 < zzz> jrandom I'll work on splitting it up</p>
16:12 < ailouros> I'll go for the update, thanks</p>
16:13 < zzz> ailouros will put it on zzz.i2p within an hour - thanks</p>
16:13 < jrandom> zzz: I wouldn't worry about it unless you've got spare time... I can read through the diff :)</p>
16:13 < ailouros> thank you</p>
16:14 < zzz> jrandom OK. There's some miscellaneous stuff that can easily be ripped out by either you or me.</p>
16:16 < ailouros> I guess we're at 5) ??? now?</p>
16:16 < zzz> jrandom other topic was Router OOMs with i2phex and possible SAM issues</p>
16:16 < jrandom> aye ailouros </p>
16:16 < jrandom> ah yeah zzz, it'd be great to track down whats up with SAM</p>
16:17 < ailouros> j346, did you have the chance to check out my app?</p>
16:17 < jrandom> what would Rule is if someone could jump on and take over maintenance of the SAM bridge, as I havent done any substantial work on it, and human hasn't been around for a while.</p>
16:19 < jrandom> not yet ailouros, unfortunately. was a bit unsure about how it worked, so I've got to read through the source first</p>
16:20 < ailouros> feel free to ask</p>
16:20 < ailouros> (and good luck on the journey through the source, it's a good definition for the word "mess")</p>
16:20 < jrandom> hehe</p>
16:21 < zzz> correction my experience has been OOMs when using i2p-bt, not i2phex. Happens after about 24 hours when running one i2p-bt and in a few hours when running two i2p-bt</p>
16:22 <+Complication> Mine happened after some late-night stress-testing.</p>
16:22 <+Complication> (during which, let it be noted, I saw 5-minute averages of 50 KB/s)</p>
16:22 < bar_> could you please remind me what your app is/does, ailouros? my memory is good but short...</p>
16:22 <+Complication> Incoming, that is.</p>
16:22 <+Complication> Outgoing was limited to 35 KB/s</p>
16:22 <@cervantes> Complication: I've never heard it called late-night stress testing before...</p>
16:22 < jrandom> nice Complication </p>
16:23 <+Complication> cervantes: well, one *could* call it semi-daily megaleeching then :P</p>
16:23 < ailouros> bar_: it's a working proof-of-concept for a distributed filesharing app which shares common blocks among differnt files (as suggested by polecat)</p>
16:23 < bar_> ah, right, thanks ailouros</p>
16:24 < tethra> cervantes: heheheh ;)</p>
16:24 < ailouros> you're welcome (if anyone wants to get the source, it's in c/c++)</p>
16:25 <+polecat> ailouros: Be careful, the chance of two binary blocks being the same is sufficiently rare, I'm mostly talking about pure theory that would be unuseful in practice.</p>
16:25 < ailouros> polecat, I agree. My best guess is that it comes useful when you get different versions of the same files</p>
16:25 < ailouros> like, a movie which has a corrupted block</p>
16:25 <+polecat> You could transfer blocks of zeroes at lightning speeds! ("The next block is zeroes" "oh I have that already" "the next block is zeroes" "oh I have that already")</p>
16:26 < ailouros> or an archive of other zip files</p>
16:26 < jrandom> or e.g. modified ID3 tags, etc</p>
16:26 < ailouros> exactly</p>
16:26 <+polecat> True. But an easy way to "fix" a movie with a corrupted block is to tell bittorrent to download on top of it. Most clients will preserve the blocks whose hashes are the same, and overwrite the ones that are different.</p>
16:26 < jrandom> archives of files probably won't work though, since they'd have to break on file boundaries</p>
16:27 < ailouros> j636, that's why I want to implement LBFS's idea of splitting on data marks and not fixed block sizes</p>
16:27 <@cervantes> the DC community used that method, by sharing file distributions in rarsets</p>
16:27 <+polecat> What might be useful is to make a general binary error correction algorithm, then implement it on a huge scale. All blocks could be "corrected" into each other, and you'd only have to transmit the correction data, which might be smaller than transmitting the block itself.</p>
16:29 <@cervantes> and then searches are basedon tiger hashes of those rar parts</p>
16:29 <+Complication> Nice thought... sounds difficult though :)</p>
16:29 <+polecat> But just a hash-for-hash equivalent... you'd never find two blocks alike!</p>
16:29 < ailouros> cervantes, what's a "rarset"? :D (except a "RAR file", that is)</p>
16:29 <+polecat> Unless both sides already had the file, one of them corrupted.</p>
16:29 < ailouros> polecat, uh?</p>
16:29 <@cervantes> ailouros: a split rar archive, with parity files if necessary</p>
16:30 < ailouros> cervantes: I don't understand the advantage of doing that</p>
16:31 <@cervantes> it's main benefit was to add pseudo-multi-source downloading to DC</p>
16:32 < ailouros> well, that's part of the block sharing mechanism between files, isn't it?</p>
16:34 < ailouros> polecat: about the bittorrent overwriting of damaged files, what it doesn't buy you is when you're trying to get multiple versions at once</p>
16:35 <@cervantes> your client only matches/downloads valid parts, if you have parity files you can also recover damaged parts </p>
16:35 < ailouros> with my system there are no damaged parts (files are assembled only when the composing blocks are downloaded and re-checked)</p>
16:36 <@cervantes> stuff bittorrent does by default, except that you can't search specifically for individual parts</p>
16:36 <+polecat> Multiple versions aren't likely to have a single bit in common though... which is why they're so stupid. Some jerk decides to re-encode the movie in postage stamp format, and gives it the same name.</p>
16:37 <+polecat> Or another jerk takes random data and names it by the file you want to download.</p>
16:37 < ailouros> lol that's correct</p>
16:37 <@cervantes> exactly and rarset releases are immune to that...</p>
16:37 < ailouros> but keep in mind that files from other networks (emule, kazaa, whatever) often come corrupted</p>
16:38 <+polecat> rarset releases aren't immune...</p>
16:38 <+polecat> You still have to figure out which rarset is the right one.</p>
16:38 < ailouros> cervantes, how are rarsets immune to an idiot publishing random junk?</p>
16:38 <@cervantes> (provided you have a reliable source)</p>
16:39 <@cervantes> because a release group publishes hashes/distribution information</p>
16:39 < ailouros> hahaha that's easy :D</p>
16:39 <@cervantes> and stuff is marked as nuked if it's poor quality, folk remove it from shares</p>
16:40 < ailouros> cervantes, that much my toy already does</p>
16:40 <@cervantes> cool</p>
16:40 < ailouros> you get the file descriptor from a trusted source, you multiget the file pronto</p>
16:41 <@cervantes> sounds good ;-)</p>
16:41 < ailouros> you don't get to sarch for files, but you can browse through each user's shared dire, so you can use a web crawler and cache the results</p>
16:42 < ailouros> though I might add a search function sometime in the future if deemed necessary</p>
16:44 < ailouros> I believe my toy, proprely developed into an app, can offer the caching and resiliancy the freenet people try to offer</p>
16:44 < ailouros> as in static content distribution and caching</p>
16:45 < ailouros> you read my blog, you cache it and offer it to other people when they want. you don't do anything more than leave the content there</p>
16:45 < ailouros> don't like the content? delete it and we're all set</p>
16:45 < jrandom> hmm, so do you see it as a backing store that could be used for syndie? </p>
16:46 < ailouros> it CAN be used as a backing store</p>
16:46 < ailouros> as it is now, you might even use it in place of jetty, in i2p default installations</p>
16:46 < jrandom> e.g. attachments / links to [clunk hash="$foo"]my file[/clunk]</p>
16:46 < ailouros> (well with a couple of minor changes :D )</p>
16:46 < jrandom> heh</p>
16:47 < jrandom> ok, yeah, I definitely don't understand how clunk works... wanna post about it in syndie, or put up an eepsite? :)</p>
16:47 < ailouros> file hashes are downloaded on file request, and these hashes are automagically downloaded into the full file</p>
16:48 < jrandom> right, but "down"loaded is a question of from where to where, etc. an overal network architecture description would be helpful</p>
16:48 < ailouros> I'll write a decent doc first, then publish it somewhere</p>
16:48 < jrandom> r0x0r, thanks</p>
16:48 < ailouros> downloaded from wherever you got the hash from</p>
16:48 < ailouros> plus everyone else sharing these blocks</p>
16:49 < ailouros> think go!zilla and download accellerator :)</p>
16:49 < jrandom> I think you misunderstand how much I am confused</p>
16:49 < ailouros> but transparent and within i2p</p>
16:49 < ailouros> lol guess so :D</p>
16:50 < jrandom> a very, very basic explanation of e.g. "you run a clunk client, download from a clunk server, get info about clunk peers", etc</p>
16:50 < jrandom> do I use a web browser to query a clunk client? or server? or peer?</p>
16:51 < jrandom> (thats how lost I am)</p>
16:51 < ailouros> redo from 0 :)</p>
16:51 < ailouros> you use your web browser</p>
16:51 < ailouros> you connect to your client</p>
16:51 < ailouros> you browse others' dir with your browser</p>
16:51 < ailouros> you select which files to download with your browser</p>
16:51 < ailouros> your client does the dirty work</p>
16:52 < ailouros> you get the downloaded file back</p>
16:52 < ailouros> is this better? :)</p>
16:52 < jrandom> ok great, thanks - so the "browse other's dir" is done by your client querying their client and responding back with an HTML representation of it</p>
16:52 < ailouros> exactly</p>
16:52 < jrandom> (or pulled from some server/superpeer/etc)</p>
16:53 < jrandom> coo'</p>
16:53 < ailouros> all the dirty work (finding duplicates, multidownloads and so on) is done by your (local) client transparently</p>
16:54 < ailouros> what you see is, basically, a directory tree and some fiels you can download</p>
16:54 < jrandom> cool</p>
16:55 < ailouros> to publish your data you give away your public (p2p) address</p>
16:55 < ailouros> and to share files you copy them (or symlink them) to the pub/ directory (or some subdir). It's that easy</p>
16:57 * jrandom will dig through the source further, and look forward to more info :)</p>
16:57 < jrandom> ok, anyone else have anything for the meeting?</p>
16:57 < bar_> umm.. what's the difference between publishing and sharing, if i may ask? does publishing push the data to some datastore?</p>
16:58 < ailouros> bar_: sharing is giving the blocks to download. publishing is letting the world know what you share</p>
16:58 < ailouros> publishing is a subset of sharing</p>
16:58 < bar_> aha, gotcha, thanks</p>
16:58 < ailouros> for example, if you have half of a file, you share it but don't publish it</p>
16:59 < jrandom> how would people know they ould get those blocks from you then?</p>
16:59 < ailouros> and you have full control over which files you publish (unlike emule where every downloaded file is published)</p>
16:59 < ailouros> because each client periodically sends information to the network about which blocks he has to offer</p>
17:00 < jrandom> coo'</p>
17:00 < ailouros> sends to the network as in server (as is now) or DHT (future)</p>
17:00 < jrandom> so its mnet-esque, with a block tracker</p>
17:00 < ailouros> err mnet-esque?</p>
17:01 < jrandom> similar to how mnet (mnetproject.org) works</p>
17:01 * ailouros is reading mnetproject.org</p>
17:02 < ailouros> well, you have just your personal spaces, no shared spaces</p>
17:02 < ailouros> and you don't PUSH blocks around</p>
17:02 < jrandom> yeah, its not exactly the same as mnet, but it similar structurally</p>
17:03 < jrandom> its like mnet where everyone is too broke to have anyone host their data ;)</p>
17:03 < ailouros> yep</p>
17:03 < ailouros> :D</p>
17:03 < jrandom> ok, anyone else have anything else to bring up?</p>
17:04 < jrandom> if not...</p>
17:04 * jrandom winds up</p>
17:04 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

55
i2p2www/meetings/160.log Normal file
View File

@@ -0,0 +1,55 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 160{% endblock %}
{% block content %}<h3>I2P dev meeting, December 13, 2005</h3>
<div class="irclog">
15:15 < jrandom> 0) hi</p>
15:15 < jrandom> 1) Net status and load testing</p>
15:15 < jrandom> 2) I2PSnark</p>
15:15 < jrandom> 3) Syndie</p>
15:15 < jrandom> 4) ???</p>
15:15 < jrandom> 0) hi</p>
15:15 * jrandom waves</p>
15:15 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-December/001239.html</p>
15:15 < jrandom> (*before* the meeting this week - who woulda thunk it?)</p>
15:16 < jrandom> not that it matters, since y'all wait until the meeting starts to read it anyway ;)</p>
15:16 < jrandom> so, movin' on in to 1) Net status and load testing</p>
15:16 <@cervantes> hey!</p>
15:17 < jrandom> thanks for doing your part cervantes ;)</p>
15:17 <@cervantes> read what?</p>
15:17 -!- DreamTheaterFan [anonymous@irc2p] has quit [Connection reset by peer]</p>
15:17 < jrandom> I don't have much to add beyond whats in the mail, anyone have any questions or comments on 1)?</p>
15:19 < spaetz> is load testing performed on *the* i2p net or do you have a private net for this?</p>
15:19 < jrandom> I'm doing it on the live net</p>
15:19 < spaetz> just curious</p>
15:19 < spaetz> k</p>
15:20 < jrandom> its being done carefully though, backing off hard from peers under load, and it of course honors tunnel rejections</p>
15:20 <@cervantes> recent irc2p instability was unrelated to the tests</p>
15:21 <@cervantes> (in case you were wondering)</p>
15:21 < jrandom> hows the new setup handling things cervantes? </p>
15:21 <@cervantes> been rock solid so far</p>
15:22 < jrandom> cool</p>
15:22 <@cervantes> just took some tedium to track down the source of the gremlins</p>
15:24 < jrandom> ok, anyone else have any questions/omments, or shall we jump on over to 2) I2PSnark?</p>
15:25 < jrandom> consider us jumped</p>
15:26 < jrandom> ok, basically I2PSnark should work again... there were a few attributes not yet in the BT spec but used by azureus and rufus, causing incompatibility, but we're now compatible with the situations I was able to see</p>
15:26 < jrandom> i2psnark now works with all of the torrents i've tested, but if anyone runs into trouble, let me know</p>
15:27 < jrandom> part of the drive for me to fix that up was in relation to some SAM bugs, since I2PSnark doesn't use SAM</p>
15:28 < jrandom> not much more to add on that front... unless anyone has any questions, lets move on over to 3) Syndie</p>
15:29 -!- Xunk [Xunk@irc2p] has quit [Connection reset by peer]</p>
15:30 < jrandom> ok, I don't have much to add beyond the email on that front either</p>
15:31 -!- Xunk [Xunk@irc2p] has joined #i2p</p>
15:31 < jrandom> if there aren't any questions re: Syndie, lets continue on and open the floor with 4) ???</p>
15:31 -!- DreamTheaterFan [anonymous@irc2p] has joined #i2p</p>
15:32 * jrandom remembers that clunk wasn't in the agenda, among other things. anyone have anything they want to bring up?</p>
15:32 <@cervantes> man speeding though</p>
15:32 <@cervantes> *through</p>
15:33 -!- bar [bar@irc2p] has quit [Connection reset by peer]</p>
15:33 < jrandom> aye, no need to talk just to see words on the meeting logs :)</p>
15:33 -!- bar [bar@irc2p] has joined #i2p</p>
15:33 -!- mode/#i2p [+v bar] by chanserv</p>
15:33 -!- mule [mule@irc2p] has joined #i2p</p>
15:35 < jrandom> ok, if there's nothing else...</p>
15:35 * jrandom winds up</p>
15:35 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

122
i2p2www/meetings/161.log Normal file
View File

@@ -0,0 +1,122 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 161{% endblock %}
{% block content %}<h3>I2P dev meeting, December 20, 2005</h3>
<div class="irclog">
15:20 < jrandom> 0) hi</p>
15:20 < jrandom> 1) Net status</p>
15:20 < jrandom> 2) I2PSnark updates</p>
15:20 < jrandom> 3) Syndie blog UI</p>
15:20 < jrandom> 4) ???</p>
15:20 < jrandom> 0) hi</p>
15:20 * jrandom waves</p>
15:20 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2005-December/001240.html</p>
15:22 < jrandom> ok, jumping on in to 1) Net status</p>
15:22 < jrandom> I don't have much to add beyond whats in the status notes.</p>
15:22 <+Complication> If it weren't for the occasional OOM's, I'd dare call it good</p>
15:22 < jrandom> the load testing is looking quite promising, suggesting that we have a lot of room to improve performance</p>
15:23 <+Complication> And I guess the OOM</p>
15:23 < jrandom> heh, i2psnark related OOMs? or from before that?</p>
15:23 <+Complication> 's contribute to flakyness, when either i2p-bt, i2psnark, or i2p-rufus instances do... things.</p>
15:24 < zzz> my theory is that increased torrent traffic is somewhat hurting IRC reliability</p>
15:24 <+Complication> (perhaps I shouldn't be calling the SAM oddity an OOM, since I've not looked at it closely, but it's one of the factors definitely)</p>
15:24 < jrandom> hmm, I'm not sure, as the irc status was similar to before the latest snark updates</p>
15:25 <+Complication> Bandwidth has been solid, part. tunnels solid too... just crashing now and then</p>
15:26 < zzz> In any case I'm optimistic the tunnel build fixes coming in 0.6.1.8 will improve people's IRC experience</p>
15:26 <+Complication> For known reasons, which hopefully go away when their time comes :)</p>
15:26 < jrandom> aye, I think so too zzz, so we'll probably have a release in the next day or so</p>
15:26 <+legion> Well irc might just be too sensitive, maybe just using something like jabber would be better?</p>
15:26 < zzz> especially for people on slower machines and/or connections</p>
15:27 < jrandom> jabber would not change things</p>
15:27 <+Complication> Especially with tunnel redundancy at 2</p>
15:28 <+bar> i'd say irc is an excellent crap-o-meter for determining the network weather</p>
15:28 <+legion> Yeah, the wind just blows a little and irc craps out</p>
15:28 <+bar> exactly :)</p>
15:28 <+Complication> I notice that after the shitlisting fix, "Recent" tends to always exceed "Known"</p>
15:29 <+Complication> Would this be because "Known" doesn't include shitlisted peers, while "Recent" does?</p>
15:29 < jrandom> aye, irc is a good view on things, as its shown substantial variation on different users (e.g. dreamtheaterfan always has trouble, etc)</p>
15:30 < jrandom> hmm, that makes sense Complication </p>
15:30 <+Complication> (I'm not sure if it does, just guessing)</p>
15:30 < jrandom> (as shitlisted peers are dropped from the netDb, but their profiles are not removed)</p>
15:32 <+Complication> Then the indicators seem OK (just wanted to ask in case they wouldn't)</p>
15:33 < jrandom> ok, anything else on 1) Net status?</p>
15:33 < jrandom> if not, lets move on over to 2) I2PSnark updates</p>
15:33 < tealc_> what sort of updates are available?</p>
15:34 < jrandom> see http://dev.i2p.net/pipermail/i2p/2005-December/001240.html for a brief listing ;)</p>
15:34 < jrandom> basically I2PSnark can now handle multiple torrents at once over a single I2P destination, has a web interface, and is built into the router console</p>
15:35 < tealc_> i'm running of the latest cvs builds and i2psnark is causing a lot of memory heap errors or whatever</p>
15:35 <+Complication> ...and it also handles Azureus-created torrents with odd meta-tags.</p>
15:35 <+Complication> Which it previously got stuck on.</p>
15:35 < jrandom> ah, yeah, there are still some things I'm debugging in there tealc_ </p>
15:35 < jrandom> (as mentioned in the weekly status notes ;)</p>
15:35 < jrandom> ah right Complication </p>
15:36 < jrandom> oh, also, the Azureus folks have fixed a bug in their tracker that would keep I2PSnark from using it</p>
15:36 < jrandom> (so people running azureus trackers prior to B16 should upgrade at their earliest convenience)</p>
15:37 <+bar> i'd like to have the possibility to easily disable the i2psnark autostart (for low bw scenarios, etc.)</p>
15:38 < jrandom> that should be easy enough to add in</p>
15:38 <+bar> sounds great</p>
15:39 < jrandom> ok, anything else on 2) I2PSnark updates? </p>
15:40 < jrandom> if not, lets move on to 3) Syndie blog UI</p>
15:40 < zzz> two thumbs up on the new i2psnark - good job</p>
15:41 < jrandom> gracias, mjw did the hard work, making snark so easy to extend</p>
15:41 < jrandom> ok, as mentioned in the status notes, syndie now has a new blog UI</p>
15:42 < jrandom> I think it'll offer a balance between whitelists and blacklists, dealing with the different spam issues available to people</p>
15:43 < jrandom> we'll have that rolled out in the next release, so y'all can dig in to it in a day or two</p>
15:43 <+legion> Is spam really going to become much of a problem anytime soon?</p>
15:44 <+Complication> legion: as someone was kindly willing to demonstrate, it could be</p>
15:44 < jrandom> nah, blacklists take care of authors who flood, and whitelists take care of spammers who create lots of authors</p>
15:44 < dust> (anonymity brings out the worst in a some people)</p>
15:44 < jrandom> (so spamming is not a problem)</p>
15:45 <+Complication> (Although I think the fellow was regenerating keys to avoid perma-blacklisting, which *is* somewhat of a slow-down.)</p>
15:45 <+Complication> Although not a big slow-down, and thus I whole-heartedly agree that whitelists are good too. :)</p>
15:46 <+bar> perhaps some hashcash solution could be feasible down the road, if necessary</p>
15:46 < jrandom> if necessary, but I don't see why it would be</p>
15:46 <+bar> agree, right now, i don't either</p>
15:46 <+Complication> bar: like "don't show unless they've bothered to crunch some numbers"?</p>
15:47 <+bar> yes, something along that line</p>
15:47 <+Complication> Sounds possible, even if probably needless.</p>
15:47 <+bar> probably so.</p>
15:47 < jrandom> if a set of spammers were flooding with lots of new authors all the time, people could still tell other people about new authors by posting their bookmarks and blog references in their own blog</p>
15:47 <+Complication> Or more like, hopefully needless.</p>
15:48 <+Complication> Might be good to consider if Syndie can accommodate such functionality, should need ever arise.</p>
15:49 < jrandom> aye, it can, with headers in the blog post or in the blog's own metainfo</p>
15:49 < jrandom> er, metadata (damn you bt!)</p>
15:51 < jrandom> ok, if there's nothing else on 3) Syndie, lets jump on to 4) ???</p>
15:51 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
15:51 <+legion> yes a couple things</p>
15:52 <+legion> first clunk</p>
15:52 < jrandom> cool, yeah clunk sounds interesting</p>
15:52 <+legion> As I mentioned earlier today in i2p-chat, I've been working on getting it to compile with cygwin and or mingw.</p>
15:53 <+legion> So far just the client is broken, the rest including the server compiles and seems to work</p>
15:53 < jrandom> neat</p>
15:54 < tealc_> i2p could prove to be a real hairball for George Bush's limitless surveillance program. I'll see you guys in the death camps, bring the cards ya</p>
15:54 <+legion> Been trying to not only track down why the client is broken, but also resolve it. At the moment I'm stuck.</p>
15:56 <+legion> The other thing I was meaning to discuss, was could a default tunnel to my jabber server be included in the next update? Just to make things easier for anyone that wants to try out jabber.</p>
15:57 < tethra> 20:34:37 &lt;jrandom&gt; if a set of spammers were flooding with lots of new authors all the time, people could still tell other people about new authors by posting their bookmarks and blog references in their own blog &lt;--- perhaps something to the effect of polecat's way of combining trust could play a role in this? (ie to both block spammers -and- promote popular authors.)</p>
15:57 < tethra> &lt;/$0.02&gt;</p>
15:58 <+polecat> That would be a primitive example of my trust network idea, with a heuristic of 100% trust transfer, yes.</p>
15:58 < jrandom> legion: hmm, adding a disabled config is easy enough for new users, but the hesitancy I have is regarding protocol filtering (and what clients leak what info). what is your experience with different clients?</p>
15:59 < jrandom> aye, there is a lot of room for integration of trust metrics into syndie</p>
16:01 <+legion> Well far as I know jeti doesn't leak, other than its filetransfer, which is disabled in my server settings anyways. Possibly the next jeti version will have it corrected. Other than that I don't know about the other clients.</p>
16:02 <+legion> I do know for sure the groupchat is solid, regardless of clients, it is just contact outside of the groupchat which some clients might leak, though I'm not sure.</p>
16:03 < jrandom> hmm, leaking isn't really a boolean, its a matter of /what information/ the clients leak, not whether they leak any information</p>
16:04 <+legion> Right, I was of course referring to any critical information like ip addresses, though good clients should if they do leak that information only report it as 127.0.0.1 or localhost</p>
16:06 <+legion> So I would recommend only using known clients which don't leak, such as jeti.</p>
16:07 < zzz> could you add a verified-doesn't-leak column to your client chart?</p>
16:07 < jrandom> it'd be useful if you could doc up what jeti does and does not leak (along the lines of what postman put together for the smtp and pop proxy)</p>
16:08 <+legion> According to jeti's developer it does not leak anything that would comprimise ones anonymity. That much is certain without a doubt. I've also looked through its source and have not found anything which would make me think otherwise.</p>
16:09 < jrandom> that the developer said it may be certain, but what the developer understands about anonymity is another question ;)</p>
16:09 <+legion> Yeah zzz I could add another such column</p>
16:09 < jrandom> I don't doubt the possibility that jeti behaves properly, but we need to know what that means</p>
16:10 < zzz> seems like non-leakage can only be verified by protocol tracing</p>
16:10 < zzz> not by looking at source or asking developer</p>
16:12 < jrandom> ok, does anyone have anything else for the meeting?</p>
16:12 <+bar> just a reminder not to forget amd64 jbigi</p>
16:13 <+bar> (but i bet it's on your todo list)</p>
16:13 < jrandom> aye :)</p>
16:13 < jrandom> (win amd64, that is, linux amd64 is already working)</p>
16:13 < jrandom> but, if there's nothing else...</p>
16:14 * jrandom winds up</p>
16:14 <+bar> yes, win amd64.</p>
16:14 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

93
i2p2www/meetings/162.log Normal file
View File

@@ -0,0 +1,93 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 162{% endblock %}
{% block content %}<h3>I2P dev meeting, January 4, 2006</h3>
<div class="irclog">
15:22 < jrandom> 0) hi</p>
15:22 < jrandom> 1) Net status and 0.6.1.8</p>
15:22 < jrandom> 2) Load testing results and peer profiling</p>
15:22 <@cervantes> jrandom: arguably the slowest most horrific punishment since they banned stoning</p>
15:22 < jrandom> 3) 2005 review / 2006 preview / ???</p>
15:22 < jrandom> 0) hi</p>
15:22 < gott> falafel</p>
15:22 < gott> n : small croquette of mashed chick peas or fava beans seasoned</p>
15:22 < gott> with sesame seeds</p>
15:22 <@cervantes> hullo</p>
15:22 * jrandom waves after recovering from the falafel pelting</p>
15:22 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-January/001246.html</p>
15:23 < jrandom> as I'm 10m late, I'm sure y'all have already read those notes and have comments ready</p>
15:23 < jrandom> *cough*</p>
15:23 < jrandom> ok, lets jump on in to 1) net status and 0.6.1.8</p>
15:24 <@cervantes> ie. it works well, except protocol is slowing it down</p>
15:24 < jrandom> I don't have much to add beyond whats in the mail - we had 0.6.1.8 cooking for a while before the release, and its gone pretty well from what I can tell</p>
15:25 < jrandom> heh yeah, I'm not sure if infoshop has posted anything since the last rss import</p>
15:25 < JosephLeBlanc> Hmm, well I have just a couple of comments.</p>
15:25 <+Complication> With regard to status, though I've mentioned before... after build -7 got into CVS, my Celeron 300 seems to behave like an actual computer. It like, transfers data with a resemblance of stability.</p>
15:26 <+Complication> Lets me extensively browse eepsites, and only rarely kicks me from IRC.</p>
15:26 < jrandom> word Complication </p>
15:26 < jrandom> whats up JosephLeBlanc </p>
15:26 <@cervantes> /kick complication</p>
15:26 <@cervantes> doh</p>
15:26 < JosephLeBlanc> I am running the latest CVS and, afaics, most things are in order.</p>
15:27 < JosephLeBlanc> However, I was wondering if that jbigi athlon problem was fixed which I talked to you about some time ago.</p>
15:28 < jrandom> jbigi for amd64 on window isn't yet in jbigi.jar, though I hope to get it into 0.6.1.9</p>
15:29 <+Complication> I *think* (but can't confirm) that it's focusing more tightly on peers it has seen success with... and this approach *may* keeps those paths from collapsing more effectively (it's behind a somewhat too agressive NAT).</p>
15:29 < JosephLeBlanc> Well, the logs are returning: 'NOTICE: Resource name [jbigi] was not found' </p>
15:30 < jrandom> JosephLeBlanc: there is a line after that regarding jbigi - what does it say?</p>
15:31 < JosephLeBlanc> It reads, "INFO: Optimized native BigInteger library 'libjbigi-linux-athlon.so' loaded from resource</p>
15:31 < jrandom> ok great</p>
15:32 < JosephLeBlanc> Just wanted to give you a heads up about that NOTICE line.</p>
15:32 < jrandom> that means it first tries to pull the resource "jbigi", but it doesn't exist (which is normal - the jbigi resource is for very rare situations)</p>
15:32 < jrandom> it then tries to pull the OS/architecture specific resource "libjbigi-linux-athlon.so" and succeeds</p>
15:33 < JosephLeBlanc> Ah, okay. Then, it seems that whatever bug I was experiencing earlier has been fixed in -7</p>
15:33 < jrandom> w3wt</p>
15:33 < JosephLeBlanc> Thanks a billion, bud.</p>
15:34 < jrandom> np</p>
15:34 < jrandom> Complication: aye, I think you're right, and some of the strategies for 0.6.2 will build on that concept further</p>
15:35 < jrandom> ok, anyone else have something for 1) net status / 0.6.1.8?</p>
15:37 < jrandom> if not, lets move on to 2) Load testing results and peer profiling</p>
15:39 < jrandom> ok, lots of stuff in the email, does anyone have any questions on it?</p>
15:40 <+bar> how big was the resonable improvement?</p>
15:41 <+Complication> Late remark about 0.6.1.8 (just tested with my laptop) - jbigi was loaded correctly there too.</p>
15:42 <+Complication> Previously, this machine (Mandriva 2005) was failing to load the correct one.</p>
15:42 <+Complication> Due to the jcpuid problem.</p>
15:42 < jrandom> I'd rather not quote a number in the meeting, as it'll affect people's expectations. measureable improvement, but nowhere near wire speed.</p>
15:43 < jrandom> (and the load test is a bit contrived)</p>
15:43 <+bar> alrighty np :)</p>
15:44 < jrandom> cool complication. Yeah, I finally bundled up scintilla's C jcpuid port :)</p>
15:45 < jrandom> ok, I don't have much to add on 2) beyond whats in the mail. More info on the resulting speed profiling will come out once its shipped in 0.6.1.9.</p>
15:47 < jrandom> if there's nothing else on that, jumping on to 3) 2005 review / 2006 preview / ???</p>
15:49 <+bar> i agree with what's in the mail, 2005 was a fantastic year and i can't see 2006 becoming any worse, i2p wise</p>
15:49 < jrandom> we've come a long way in the last year, and y'all have done lots of great work pushing us forward. this coming year looks to be the big one for us, moving out of the geeky backrooms and into the venues where it matters. </p>
15:50 * tethra came in towards the wrong end of 2005, but it was still pretty damn cool. *thumbs up*</p>
15:51 <+Complication> Hoping for the best.</p>
15:51 < jrandom> I don't have much more to add, so if there's other stuff that people want to bring up for the meeting, the floor is open</p>
15:52 <+Complication> Speaking of which, if someone wanted to translate some docs into Spanish (see Discussion forum), whom would it be best for them to coordinate with?</p>
15:52 <+Complication> e.g. which parts are liable to change heavily, or such matters</p>
15:53 <+Complication> Also, in which format would it be best to have various docs?</p>
15:54 < jrandom> the tech intro doc @ dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD is fairly stable</p>
15:54 <+Complication> Included with the router... on the website... both?</p>
15:54 < jrandom> (there will be updates on 0.6.2 though)</p>
15:54 < jrandom> well, I'm hugely in favor of inline documentation</p>
15:54 < jrandom> but that should probably wait until the new router console is in place</p>
15:55 < jrandom> website intro docs would be good as well, but that should probably wait until the new website is in place</p>
15:55 <+Complication> Aha... so it would be best to not touch that yet...</p>
15:56 <+Complication> ...instead preferring docs like the above.</p>
15:58 < jrandom> probably. ok, is there anything else people want to bring up for the meeting?</p>
15:59 < jrandom> if not...</p>
15:59 < tethra> did we discuss the eepget UI idea yet?</p>
15:59 < gott> If the meeting is still on, please fix the trouble with accents in IRCclient</p>
15:59 < tethra> ie, before i got here</p>
15:59 < jrandom> nope, wanna implement it tethra? :)</p>
15:59 < jrandom> gott: patches welcome</p>
16:00 < gott> If not, please fix the trouble with accents in IRCclient.</p>
16:00 < gott> jrandom: By the time, I fix it, it will be fixed by somebody else ;-)</p>
16:01 < tethra> jrandom: i'm not entirely sure how to go about it, as i'm not much a coder. if you feel like pointing me at any tutorials in writing .war type apps and i'll be glad to have a shot, though.</p>
16:01 < gott> I reserve the right to be defeatist in deed and action.</p>
16:01 < tethra> haha</p>
16:01 <+Complication> :)</p>
16:02 < jrandom> tethra: the oreily servlets books are pretty good</p>
16:02 < jrandom> ok, if there's nothing else...</p>
16:02 * jrandom winds up</p>
16:02 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

176
i2p2www/meetings/163.log Normal file
View File

@@ -0,0 +1,176 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 163{% endblock %}
{% block content %}<h3>I2P dev meeting, January 10, 2006</h3>
<div class="irclog">
15:26 < jrandom> 0) hi</p>
15:26 < jrandom> 1) Net status</p>
15:26 < jrandom> 2) Throughput profiling</p>
15:26 < jrandom> 3) Syndie blogs</p>
15:26 < jrandom> 4) HTTP persistent connections</p>
15:26 < jrandom> 5) I2Phex gwebcache</p>
15:26 < jrandom> 6) ???</p>
15:26 * jrandom waves</p>
15:26 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-January/001247.html</p>
15:27 < jrandom> (yeah, I know... we need a 7) One more thing...)</p>
15:28 < jrandom> jumping on in to 1) Net status </p>
15:28 < jrandom> In general, seems the same ol' same ol', beyond whats in the mail. </p>
15:28 < jrandom> Anyone have anything they want to bring up about 1)?</p>
15:30 < jrandom> ok, if not, moving on over to 2) Throughput profiling</p>
15:31 < tethra> it sounds cool, but may i ask what the objective is?</p>
15:31 < jrandom> find fast peers</p>
15:31 < tethra> (forgive my lack of wit and tact)</p>
15:31 < tethra> ah, cool.</p>
15:32 < jrandom> basically, our old speed profiling wasn't that great (see last week's status notes for a summary), and this seems to be pretty good at finding peers that I know are fast</p>
15:32 < jrandom> (I know they're fast because I've cheated and measured them with non-anonymous techniques)</p>
15:33 < tethra> shocking! ;)</p>
15:33 < jrandom> ((yes, someone could have been crazy and mounted attacks to confuse my measurements, but, well, I doubt it ;)</p>
15:33 < tethra> haha</p>
15:33 < tethra> sweet, so that should make client tunnels more likely to find a 'good' peer and presumably put the 'fast' peers under less pressure, then?</p>
15:35 < tethra> s/'good'/fast/</p>
15:35 < jrandom> yes to the former, but not really to the later - it won't reduce the pressure on them, but it will let people make more effective use of them</p>
15:35 <@cervantes> I guess the folks with fast peers will have to hope the peer throttling is good enough to take the extra participation</p>
15:36 < jrandom> e.g. rather than having $slow--&gt;$fast--&gt;$fast, it'll have $fast--&gt;$fast--&gt;$fast</p>
15:36 < tethra> ah, i see</p>
15:36 < jrandom> aye cervantes, I've been paying attention to the capacity profile as well, and its been doing the trick</p>
15:36 <@cervantes> grand</p>
15:37 < jrandom> the interplay between capacity and speed is important - peers are not considered fast if they are not high capacity, even if their speed is ranked higher than everyone else</p>
15:37 <@cervantes> be interesting to see how it effects througput</p>
15:37 < jrandom> (which is why 'fast' is just shorthand for 'fast and high capacity')</p>
15:37 <@cervantes> +h</p>
15:37 < jrandom> aye cervantes</p>
15:39 < jrandom> ok, if there's nothing else on 2, lets jump on over to 3) Syndie blogs</p>
15:40 < jrandom> I don't have much more to add beyond whats in the mail there</p>
15:41 <@cervantes> it's looking swell</p>
15:41 < tethra> i very much like where the blogs are going, personally. it seems to all be gravy, one might say.</p>
15:41 < tethra> :D</p>
15:41 <+Complication> Bit late, sorry.</p>
15:42 < jrandom> cool, its similar to how it was originally, but I think the blog view has some promise</p>
15:42 < jrandom> wb Complication, no worry, we've got logs :)</p>
15:43 <+Complication> Reading scrollback right now :)</p>
15:43 < jrandom> I do think there's a place for both views, I suppose it just depends on the user</p>
15:43 < jrandom> (and the content, and the author)</p>
15:45 < jrandom> one thing though is that the html aint that grand. cervantes has been helping me revamp my very basic education to a more modern view, but there are lots of issues left</p>
15:46 < jrandom> there will be continuing improvements to syndie's web interface, and if some html volunteer wanted to help out with formatting, design, css, cross browser issues, etc, it would be much appreciated</p>
15:47 <@cervantes> other than having 2 opening &lt;style&gt; tags the code looks pretty clean ;-)</p>
15:47 < jrandom> heh oops</p>
15:48 <@cervantes> I think the emphasis will be on getting the styling clean and readable and perhaps designing some template alternatives</p>
15:48 < jrandom> hmm</p>
15:49 < jrandom> thats one thing I was thinking about for the blog view - it'd be easy to let people customize certain attributes (colors, fonts, sizes), but I'm not sure how much more</p>
15:50 < jrandom> otoh, the blog view, like the thread view, is all just a template over the syndie archive</p>
15:50 <@cervantes> well you certainly don't want to allow deployable templates</p>
15:50 < jrandom> so the question is, a template for whom?</p>
15:50 < jrandom> (what level of experience would those using the template require)</p>
15:51 <@cervantes> I was thinking just a popup config option someone can choose for their blog</p>
15:51 < jrandom> hmm?</p>
15:51 <@cervantes> I want "Pony Look"</p>
15:51 < jrandom> ah, ok</p>
15:51 <@cervantes> so we ship syndie with a variety of skins</p>
15:52 < jrandom> yeah, preset colors/font/etc</p>
15:52 < jrandom> (and icons, etc)</p>
15:52 < jrandom> thats one thing that hasn't really been implemented through the blog view yet</p>
15:54 < jrandom> good idea on the simple theme chooser though, rather than some complex set of options</p>
15:54 <@cervantes> an alternative would be someone can offer their own template presets as a download on their site - which could be saved into a theme folder</p>
15:55 <@cervantes> it's up to the individual if they want to trust the blog author's custom skin</p>
15:55 < jrandom> ... trust?</p>
15:55 < jrandom> nothing in syndie will let you do unsafe html or css</p>
15:55 < tethra> what of unsafe javascript/etc</p>
15:55 < jrandom> the skins would be text files/config files/images, rather than jsp</p>
15:55 < tethra> ?</p>
15:56 < tethra> (page forwards to non-anonymous addresses with js, for instance?)</p>
15:56 <@cervantes> it depends if a theme might also contain structural html changes </p>
15:56 <@cervantes> right ok</p>
15:56 <@cervantes> well that would keep it nice an clean and simple</p>
15:57 < jrandom> tethra: I'm... incredibly hesitant about javascript. seen that new blog post today from default?</p>
15:57 < jrandom> "I'm just curious: does it use AJAX? The page doesn't seem to update as a whole..."</p>
15:57 < tethra> nein, i did not.</p>
15:57 < tethra> i'd find a way to just shag any js that is used, personally.</p>
15:58 < jrandom> since syndie is *local*, its insanely fast, and we don't need do worry about the same latency issues</p>
15:58 < tethra> as i don't trust it as far as i can throw it.</p>
15:58 < tethra> hmm :/</p>
15:58 < jrandom> cervantes: aye, very simple - we could even do things like let people viewing a blog theme they like say "steal this theme"</p>
15:59 <@cervantes> in theory you could provide a library of "safe" functions fo blog user - but by the time you remove everything that is unsafe from the average browser's implementation you're left with the "alert();" function</p>
16:00 < jrandom> heh</p>
16:00 < jrandom> (and you've got all those accessibility issues of javascript)</p>
16:00 <+Complication> cervantes: mind you, alert() in an infinite loop can be bad :P</p>
16:00 * jrandom is quite proud of syndie's lynx-friendliness</p>
16:00 < tethra> lynx &lt;3</p>
16:02 < jrandom> ok, if there's nothing else on 3), lets jump on over to 4) HTTP persistent connections</p>
16:02 < jrandom> I don't have anything to add beyond whats in the mail... zzz, you here?</p>
16:02 <@cervantes> there are other ways of implementing a *spit* AJAX ui, like a mozilla extension</p>
16:03 < jrandom> fire2pe++ :)</p>
16:03 < jrandom> zzz doesn't seem to be around, so we'll probably have to wait for later for more info on 4)</p>
16:03 <@cervantes> fire2pe is just a helper - syndilla is what you mean ;-)</p>
16:03 < jrandom> lol</p>
16:04 < jrandom> (and, the usb keychain version, syndog ;)</p>
16:04 < jrandom> ok, moving on to 5) I2Phex gwebcache</p>
16:05 < jrandom> Complication: p1ng</p>
16:05 <+Complication> Well, since it would make integrating with the net easier...</p>
16:06 <+Complication> ...I've recently worked on reviving the gwebcache code already in I2Phex</p>
16:06 <+Complication> It's already doing some very limited things (like crash neatly) at this stage :)</p>
16:06 <+Complication> Also pesters awup's webcache server with moderate success</p>
16:07 < jrandom> lol nice</p>
16:07 <+Complication> I have hope though, that eventually I'll get it reworked</p>
16:07 <+Complication> (lots of it is currently meant to deal with IP addresses)</p>
16:09 < jrandom> cool, good luck, and lemmie know if there's anything I can do to help</p>
16:09 <+Complication> Will do :)</p>
16:10 < jrandom> ok, anything else on 5) I2Phex gwebcache, or shall we mosey on over to 6) ???</p>
16:11 < jrandom> consider us moseyed</p>
16:11 < jrandom> anyone have anything else for the meeting?</p>
16:11 <@cervantes> another cup of tea would be nice</p>
16:12 < tethra> heheh</p>
16:12 < Pseudonym> how's the roadmap?</p>
16:12 < jrandom> no changes</p>
16:12 < Pseudonym> what's left for 0.6.2?</p>
16:13 < jrandom> all of the 0.6.2-related stuff</p>
16:13 * jrandom ducks</p>
16:14 < Pseudonym> :-P</p>
16:14 <@cervantes> some bling bling</p>
16:14 < Pseudonym> do we have a tentative date/timeline?</p>
16:14 < jrandom> specifically, the new tunnel creation crypto and algorithms, the new peer selection strategies</p>
16:14 < tethra> heheh</p>
16:14 < jrandom> no dates and timelines (at least, not announced in meetings ;)</p>
16:15 < Pseudonym> is there more to peer selection strategies than the throughput stuff you've been working on?</p>
16:16 < jrandom> yes, these peer profiling changes are performance issues, not the anonymity related peer selection and ordering strategies</p>
16:16 <+Complication> jrandom: do I remember correct... if I guess the tunnel creation crypto related to things discussed on the mailing list, during the talk about predecessor (and other) attacks?</p>
16:17 < jrandom> yeah Complication </p>
16:17 <+Complication> s/related/relates</p>
16:19 <+Complication> You're going to try making that fancy lil' datastructure work?</p>
16:19 < jrandom> aye</p>
16:20 < jrandom> (hence, 0.6.2 is not on the 2 week horizon ;)</p>
16:20 <+Complication> Neat. Sounds interesting, I should probably read up about it</p>
16:21 <+Complication> I hope it goes smoothly</p>
16:21 < jrandom> it was only arm-waved around on the list, no spec digitized yet</p>
16:21 < tethra> which neat datastructure is this, sorry?</p>
16:21 <+Complication> Oh, and figured why the link (from the "moo" message) wouldn't work. :D It's freedomarchives.i2p (in the plural, with an "s" at end)</p>
16:21 < jrandom> it'll be backwards incompatible, so smooth won't be its catchphrase, but hopefully won't hurt too much :)</p>
16:21 < jrandom> ah bugger</p>
16:22 < jrandom> tethra: a datastructure that doesn't exist yet for creating tunnels</p>
16:22 < tethra> cool</p>
16:22 < jrandom> (see the predecessor threads from november or so)</p>
16:23 < tethra> what advantages/disadvantages will it have over the current one? (if there is a current one :o)</p>
16:23 < jrandom> (see the predecessor threads from november or so) ;)</p>
16:23 < tethra> ah, ok</p>
16:23 <+Complication> IIRC, to make tunnel creation less transparent to observers</p>
16:23 < tethra> ""</p>
16:23 < tethra> ;)</p>
16:23 < jrandom> but, its not a proposal, there is nothing on the table for 0.6.2 until all of the things prior to 0.6.2 are sorted.</p>
16:23 < jrandom> once the things that should be working are working in the manner that we need them to work, then we move on.</p>
16:24 < Pseudonym> other than fast peer selection, what's not working?</p>
16:25 < jrandom> fast peer selection is a part of "good performance"</p>
16:25 < jrandom> we /do/ have good performance, for an anonymous network, but not good enough to compete with non-anonymous networks</p>
16:25 < jrandom> to compete, we've got to get better performance *and* provide functionality they can't get elsewhere</p>
16:26 < jrandom> (anonymity does not sell)</p>
16:26 < Pseudonym> is there more to it than fast peer selection?</p>
16:27 < jrandom> through the last month or two, benchmarking different aspects of i2p, slow peer selection seems to be the smallest bottleneck. what the next bottleneck will be is unknown.</p>
16:27 < jrandom> (there have also been countless improvements at different points to improve performance)</p>
16:27 < jrandom> (see http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD )</p>
16:28 < Pseudonym> so... release of new peer selection this week? ;-)</p>
16:28 < teal`c_> i2p feels good</p>
16:29 < jrandom> Pseudonym: aye, new peer profile algorithm is in cvs and will be deployed this week with 0.6.1.9</p>
16:30 < jrandom> ok, anyone have anything else for the meeting?</p>
16:30 < Pseudonym> cool</p>
16:31 < jrandom> if not...</p>
16:31 * jrandom winds up</p>
16:32 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

267
i2p2www/meetings/164.log Normal file
View File

@@ -0,0 +1,267 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 164{% endblock %}
{% block content %}<h3>I2P dev meeting, January 17, 2006</h3>
<div class="irclog">
15:40 < jrandom> 0) hi</p>
15:40 < jrandom> 1) Net status and 0.6.1.9</p>
15:40 < jrandom> 2) Tunnel creation crypto</p>
15:40 < jrandom> 3) Syndie blogs</p>
15:40 < jrandom> 4) ???</p>
15:40 < jrandom> 0) hi</p>
15:40 * jrandom waves</p>
15:40 < jrandom> weekly status notes posted @ http://dev.i2p.net/pipermail/i2p/2006-January/001251.html</p>
15:41 <@cervantes> pfff, good job i2p is more reliable than NASA</p>
15:41 < jrandom> heh </p>
15:41 < tethra> haha</p>
15:41 < jrandom> (though I am 20 minutes late... ;)</p>
15:41 < jrandom> anyway, lets jump on in to 1) Net status and 0.6.1.9</p>
15:42 < wmpq> NSA or NASA, not that diffrent are they?</p>
15:42 <@cervantes> I said I2P not jrandom ;-)</p>
15:42 < jrandom> good point cervantes ;)</p>
15:42 < tethra> don't be silly, jrandom IS i2p! ;D</p>
15:42 <@cervantes> oh I thought it was a way of thinking</p>
15:42 < wmpq> [redact]</p>
15:43 < jrandom> heh well, anyway, 0.6.1.9 is out and about, with 70% of the net upgraded (thanks y'all)</p>
15:43 < Pseudonym> mmmm, tasty new release</p>
15:44 <+zzz> client tunnel build success remains &lt; 30%</p>
15:44 < jrandom> I haven't heard many reports of substantially increased end to end throughput, though some routers are more than saturating T1 lines</p>
15:44 <+zzz> down from ~40%</p>
15:44 <+Complication> Bandwidth seems normal, a bit higher than on the last CVS before release. Peer counts look a big higher.</p>
15:45 < jrandom> hmm, yeah, I'm not really worried about that zzz, since its all getting completely reworked for 0.6.2</p>
15:45 <+zzz> avg BW up from ~12K to ~20K</p>
15:45 < jrandom> 0.6.1.9 shouldn't pick peers more liable to agree (meaning, high capacity), but should instead focus on those who have higher throughput</p>
15:46 <+Complication> Retransmission percentage (noted 7% on the night of release) has come down to 6 point something</p>
15:46 < jrandom> aye, with routers pushing 1-300KBps, there's going to be a skew</p>
15:46 < jrandom> hmm, thats a pretty crazy rate Complication, i've only seen 2-3%</p>
15:46 < jrandom> (but I don't doubt what you see)</p>
15:47 <+Complication> I'm maxing out my outbound, pretty much</p>
15:47 <+Complication> (and I mean maxing out the line capacity)</p>
15:47 < jrandom> ah, that'd do the trick</p>
15:47 <+zzz> still getting NULLs before gets which results in 405 bad method, rate may be declining, hard to say for sure</p>
15:48 < jrandom> yeah zzz, there are some things that need to be worked through in the streaming lib, but I probably won't get to that until after the 0.6.2 tunnel revamps</p>
15:48 < jrandom> (but if someone wants to dig in further before that, that would rule, of course)</p>
15:49 < jrandom> Complication: if you reduce your bw limiter to something like 70% of your line capacity, does the failure rate go back to a reasonable value?</p>
15:49 <+zzz> I still think it was something that went in the code just before new years, so better to look at before those recent changes are forgotten :)</p>
15:50 <+zzz> First seen Dec. 29</p>
15:50 < jrandom> yeah zzz, it certainly was. likely related to how we now honor timeouts.</p>
15:51 <+Complication> jrandom: I'm actually trying that currently :)</p>
15:51 <+Complication> Adjusted a few seconds before you asked, but won't know very soon, I guess</p>
15:51 < jrandom> but there is substantial work that needs to be done in there to clean it up, and its more important to get the new tunnel creation code implemented (which will substantially improve tunnel build success rates, as well as add a whole set of anonymity improvements)</p>
15:51 < jrandom> cool Complication, yeah, give it 3-6 hours </p>
15:51 < jrandom> (to clear out the old values / connections)</p>
15:52 <+zzz> ~ 1% - 3% of GETs are corrupted atm</p>
15:54 < jrandom> so do you suggest reverting the streaming lib changes (so that i2psnark will OOM all of its users in 12-48 hours) and put off further streaming lib rework until after the 0.6.2 tunnel work, or push out the 0.6.2 tunnel work for a week or two while revamping the streaming lib?</p>
15:55 <+zzz> certainly don't revert</p>
15:56 <+zzz> your call</p>
15:56 <+Complication> It's a fairly sly bug, I can only say</p>
15:58 < jrandom> there are other bugs in the streaming lib, so if I'm going to roll up my sleeves, I'd want to tackle them all together (since none of the remaining bugs are apparent). </p>
15:59 < jrandom> on the other hand, we'll have substantial bandwidth usage reduction, increased build success percentage, better anonymity, and an improved ability to monitor load balancing on the live net by going with the tunnel work first</p>
15:59 < Pseudonym> if it's only a 1-3% failure rate on surfing, I'd say it can wait, but that's just my opinion.</p>
16:00 < jrandom> I'm leaning towards doing the tunnel work first, since after deploying it, we can passively monitor the network while actively revamping the streaming lib</p>
16:01 < jrandom> (I'd also like to build a GUI for editing/posting to Syndie, but that can wait until after both of those things are sorted ;)</p>
16:01 <+Complication> That's what the rate is like, here too</p>
16:02 <+Complication> (on my eepsite)</p>
16:04 < jrandom> Ok, I think it'd be great if y'all can keep an eye on things to see if those rates changes, but in the meantime, I'll continue on with the tunnel revamp, after which will come the streaming lib revamp (both of which will be in place before 0.6.2)</p>
16:05 < jrandom> (or, if somene wants to dig into the streaming lib [or see if there's some odd interaction with i2ptunnel], lemmie know!)</p>
16:06 <+Complication> jrandom: out of curiosity, could one exclude i2ptunnel with a test app?</p>
16:07 <+Complication> e.g. if something like jnymo's sample app would *also* receive nulls, that would clear i2ptunnel from the list of suspected causes?</p>
16:07 < jrandom> one could wire up a thin (in-VM) I2PSocket implementation to do that, certainly </p>
16:07 <+Complication> Since, IIRC, that sample used the streaming lib directly...</p>
16:08 <+Complication> (or pretty directly)</p>
16:08 < jrandom> aye, of course if something using the streaming lib can duplicate it, it would exonerate i2ptunnel</p>
16:10 <+Complication> Hmm, unless someone else gets first (I'll try finishing with the webcache thingy first) I might try emulating HTTP with something like that...</p>
16:10 < jrandom> wikked, thanks Complication</p>
16:10 < jrandom> ok, anything else on 1) Net status and 0.6.1.9? </p>
16:11 < jrandom> if not, lets mosey on over to 2) Tunnel creation crypto</p>
16:11 <+Complication> Nah, it may lead to nothing useful, or I may stumble on halfway... but it's a possibility which intrigues me</p>
16:11 < jrandom> aye, definitely worth exploring Complication</p>
16:12 < jrandom> (and explorations do not have to have positive results to be worthwhile :)</p>
16:12 * cervantes spots a "moo" exception in the source changes leading up to new year....perhaps that's the issue? :)</p>
16:13 < jrandom> ok, there's a new tunnel creation crypto spec referenced in the email, based on the discussion toad, Michael, and myself had on the mailing list last october</p>
16:14 < jrandom> give 'er a look and lemmie know your thoughts - it won't be deployed on the live net for a while, as there are other things that need to be implemented first, but its coming</p>
16:14 <+Complication> Is "moo" a reserved word for Java? ;P</p>
16:14 <+zzz> on 2) I'll help review references in status mail</p>
16:14 <+Complication> On the tunnel crypto subject, do you mind checking if the following rephrase is decent - I'd just like to ensure I've understood it right...</p>
16:14 < jrandom> thanks zzz</p>
16:15 <+Complication> "Each hop encrypts all records with their reply key, which they decrypted from their record, using their ElGamal private key, and by encrypting in such fashion, reverses one layer of decryption (or should I say, encryption) done by the tunnel owner, rendering the next participants' record readable with the next participant's ElGamal private key?"</p>
16:15 < jrandom> Complication: yes</p>
16:15 <+Complication> Or is my rephrase plain wrong?</p>
16:16 <+fox> &lt;jme___&gt; and way to complicated, if i may</p>
16:16 < jrandom> its correct I believe, but yeah, too many clauses :)</p>
16:16 <+Complication> I didn't think of a better way to visualize it. 'Twas hard enough that way. :P</p>
16:16 < jrandom> (or jme___ are you saying the algorithm is too complicated?)</p>
16:17 <+fox> &lt;jme___&gt; nope i tried rapidely to read the doc and give up as too many things require prior knowledge</p>
16:17 <+fox> &lt;jme___&gt; on the other hand i didnt try much :) other things to do</p>
16:17 < jrandom> Complication: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/java/src/net/i2p/router/tunnel/BuildMessageProcessor.java?rev=HEAD</p>
16:18 <+fox> &lt;jme___&gt; is this peer review a formality, or you are really worried/unsure of it ?</p>
16:19 <+Complication> Well, it's always good to know what an underlying mechanism is doing...</p>
16:19 < jrandom> I'm confident that it does what I intend for it to do, but I am sincerely interested if someone can see a problem</p>
16:19 <+fox> &lt;jme___&gt; if the second i could spend the time, but my knowledge is old and not on top of my head</p>
16:20 <+fox> &lt;jme___&gt; if not i trust :)</p>
16:20 < jrandom> the notes section has some questions - http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.notes </p>
16:22 < jrandom> there's no rush, it'll probably be a week or two before this new crypto is actually used in the router </p>
16:22 <@cervantes> jrandom: on those, would there be much of a performance hit on injecting a random delay between hops?</p>
16:22 <@cervantes> as that seems the most sensible option to prevent timing attacks</p>
16:23 < jrandom> its tunnel creation, so a delay wouldn't hurt, though could cause premature lease set expiration under catastrophic failures</p>
16:25 < jrandom> well, I'm not sure how effective those delays would be. they may help substantially, but they may not. live tunnels, however, can simply use blending to detect colluding peers on that tunnel anyway though, so I'm not sure it matters</p>
16:25 <+fox> &lt;jme___&gt; ok rereading it</p>
16:27 < jrandom> thanks. ok, no rush, but if/when anyone has any thoughts, bounce 'em my way (or to the list, or to your blog, etc)</p>
16:27 < jrandom> ok, anything else on 2, or shall we move on to 3) Syndie blogs?</p>
16:29 < jrandom> (consider us moved)</p>
16:29 < jrandom> ok, new neat bloggy stuff in syndie, dig in ;)</p>
16:29 <@cervantes> v.cool</p>
16:30 < jrandom> the groups on the left can contain links to arbitrary urls, as well as links to blogs, posts within blogs, or attachments to posts within blogs</p>
16:30 < jrandom> there are a whole slew of enhancements possible, too, such as adding per-blog or per-tag styling for posts, icons, etc. if someone wants to dig into that, it'd rule (and have a highly visible impact :)</p>
16:31 <@cervantes> btw external links defined in comments should also have a title attribute set to the target url (as you have done on the left panel)</p>
16:31 <@cervantes> comments/posts</p>
16:32 < jrandom> ah, good idea</p>
16:33 < jrandom> (net.i2p.syndie.sml.BlogPostInfoRenderer method renderLinks(...) :)</p>
16:34 <@cervantes> *scribble*</p>
16:35 < jrandom> what else do the syndie blogs need for them to offer a functional alternative to informational eepsites? obviously, syndie is static content, so you can't do some things, but you can publish content and let people comment</p>
16:36 < jrandom> are there particular customizations you want to be able to do? if so, lemmie know</p>
16:37 < DoubtfulSalmon> jrandom: updating existing content via script?</p>
16:37 <@cervantes> archive by date</p>
16:37 < jrandom> DoubtfulSalmon: via script?</p>
16:37 < jrandom> cervantes: ah, like a little calendar widget, rather than the "5 older entries" links?</p>
16:38 <@cervantes> yup</p>
16:38 < DoubtfulSalmon> jrandom: say I want this file/text to replace that file/text. How do I do that?</p>
16:38 < jrandom> ok cool, yeah, that should be really easy (if someone whips up the html :)</p>
16:38 <@cervantes> or more simply "view last month's posts"</p>
16:39 <@cervantes> jrandom: you just need a 7x6 table with some numbers in it ;-)</p>
16:40 < jrandom> DoubtfulSalmon: changing content that has been published is an interesting direction. across the board, it wouldn't always work, since it'd have to operate like usenet control messages (cancelling an old post, etc)</p>
16:40 < jrandom> DoubtfulSalmon: on the other hand, you can simply post a new file/entry and change the links on the left hand side to point to the new file/entry</p>
16:40 < jrandom> (that way, the old content is still there, but people are directed to the new content)</p>
16:41 < DoubtfulSalmon> jrandom: yeah, it would be ok if the old content was still there, as long as everyone's links pointed to the new content, without them having to change their content.</p>
16:41 < jrandom> building a full blown wiki out of it, essentially posting diffs with syndie rendering them result, is possible, but may be overkill</p>
16:41 < jrandom> hmm, ok I see what you're saying</p>
16:42 < jrandom> so, you want the ability to have redirectable links, rather than the existing links to exact versions of content</p>
16:43 < jrandom> perhaps that could be done by linking to a blog's bookmark, and the exact version is found by loading that blog's current bookmarks and seeing where it points</p>
16:44 < jrandom> otoh, the new version could be marked as a reply to the old post, so when people follow a link, they can follow it to the reply which replaces the content</p>
16:44 < jrandom> (though thats probably not as seamless)</p>
16:44 < DoubtfulSalmon> yeah: say I want to have a link to say: a current radar image, or somthing like that that will be upadated every 10 min. It's ok if the contet doesn't fly all over the net, but if someone else links to my page, the user should see the current image.</p>
16:45 < jrandom> well, that depends on what they want to do - do they want to link to the image as it was when they referred to it, or do they want to link to the service that renders the image when the reader views it</p>
16:45 <+Complication> cervantes: oddity of the day :D Last post in: http://forum.i2p/viewtopic.php?t=1199&start=15</p>
16:46 <+Complication> Felt like it might be another of our robotic overlords :P</p>
16:46 < jrandom> but its a good idea to support both concepts, and I don't think it'd be much trouble</p>
16:46 <@cervantes> thnx</p>
16:46 < jrandom> though it'd need a small extension to sml (e.g. [blog bloghash="ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=" bookmark="radar.png"])</p>
16:47 * cervantes will upgrade forum defenses if we start to get a lot of them</p>
16:47 <@cervantes> (already know how to stop that one)</p>
16:47 < DoubtfulSalmon> jrandom: they should be able to link to both a static version of it, provided the syndicator has not deleted the content, as well as a generic url that points to whatever is the latest version</p>
16:47 < jrandom> (which would look at ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c='s current meta post for bookmarks, pulling the exact uri from the one named "radar.png")</p>
16:48 < DoubtfulSalmon> jrandom: could that be done now with something like: "View most recent one post in tag &lt;weird string&gt;"</p>
16:48 < jrandom> ah, good point - yes, it could</p>
16:49 < jrandom> that could even be restricted to "View most recent post by $author with tag $tag"</p>
16:49 < jrandom> (so other people couldn't spoof it)</p>
16:49 < DoubtfulSalmon> so maybe just put some sort of UI so the user does not have to see weird tags and what not</p>
16:50 < jrandom> there's an example of how that looks up there, though I don't have the uri offhand... but yeah, is a link around the linked text</p>
16:50 < DoubtfulSalmon> I assume all of that information can come in URL form.</p>
16:51 < jrandom> but this is definitely complicated to write the source SML, which is why a GUI to create SML would be useful</p>
16:51 < jrandom> they're attributes on the SML tags, not URLs</p>
16:52 <@cervantes> and SML gui will be tricky without javascript</p>
16:52 < DoubtfulSalmon> but you can bookmark a search result right?</p>
16:52 < jrandom> what is a search result?</p>
16:52 < jrandom> and what do you mean by bookmark?</p>
16:52 <@cervantes> (or a browser extension ;-)</p>
16:52 < jrandom> oh, browser side bookmarks, yes</p>
16:52 <+Complication> A filter result?</p>
16:53 < jrandom> but those bookmarks are not generally shareable</p>
16:53 < DoubtfulSalmon> er: a "get most resent 1 post by X with tag Y" </p>
16:53 < jrandom> (actually, most are, but its not universal, since they're URLs not URIs))</p>
16:53 < DoubtfulSalmon> yeah, it would be good if other bolgs could link to those too</p>
16:54 < jrandom> DoubtfulSalmon: they can, with sml</p>
16:54 < jrandom> [blog tag="Y" bloghash="X"]</p>
16:54 < DoubtfulSalmon> oh goodie</p>
16:55 < jrandom> cervantes: javascript, or xul, or java, or some other OS-specific client app</p>
16:57 <@cervantes> ah cool, so you don't mind a scripting or plugin dependancy</p>
16:57 < jrandom> (when our website gets revamped for 0.6.2, syndie will definitely get a website explaining wtf this whole syndie thing is, and how it can do everything short of wash the dishes ;)</p>
16:57 <@cervantes> (as long as it degrades gracefully)</p>
16:57 < jrandom> cervantes: syndie should be function with lynx, but there's lots of room for rich clients</p>
16:58 < jrandom> (s/function/functional/)</p>
16:58 <@cervantes> right..so lynx uses would get an SML reference chart, but nothing more</p>
16:58 < jrandom> aye, as we have now</p>
16:58 < jrandom> though perhaps a simplified sml, dunno.</p>
17:01 <+Complication> jrandom: do you think it might be even remotely plausible... that the null bug might be related to gzip encoding?</p>
17:01 <+Complication> I was thinking of how to disable gzipping for my eepsite tunnel...</p>
17:01 <+Complication> Or would that be entirely implausible?</p>
17:01 <@cervantes> there was some http compressor stuff added just before new year in i2ptunnel</p>
17:03 < jrandom> aye, it could - yo ucan disable it on the client side with i2ptunnel.gzip=false (on /configadvanced.jsp). atm I don't think you can disable it in i2ptunnelhttpserver though</p>
17:03 <+zzz> it's on the request side where there isn't any compression</p>
17:03 <+zzz> server won't compess if client set to false</p>
17:03 <+Complication> zzz: oh, right, I forgot that</p>
17:04 < jrandom> (but without too much trouble you could add it to I2PTunnelHTTPServer [line 310, etc)</p>
17:04 * Complication is a fool, and apologizes for that</p>
17:04 <@cervantes> (or you could use a normal tunnel)</p>
17:04 <+Complication> Aha, thanks...</p>
17:05 < jrandom> hmm, though by the time the i2ptunnelhttpserver receives the GET, the null is already there</p>
17:05 <+zzz> yup I did get orion moved back to HTTP tunnel which greatly helps load times for his pages since now compressed again</p>
17:05 <+Complication> I somehow entirely forgot that gzipping starts when the client and server have *agreed* to do it</p>
17:05 < jrandom> so it may be on the client side, but definitely not the server side</p>
17:05 < jrandom> yeah zzz, its pretty insanely fast now :)</p>
17:05 <+zzz> its on the _request_ side not the _response_ side - could be on either client or server side</p>
17:06 < jrandom> true</p>
17:09 < jrandom> ok, anyone else have anything on 3) Syndie blogs?</p>
17:09 < jrandom> if not, lets jump on to 4) ???</p>
17:09 < jrandom> anyone have anything else to bring up for the meeting?</p>
17:10 < cat-a-puss> Complication: Java's gzip stream + I2P tunnels. Does NOT work and it's sun's bug</p>
17:10 < jrandom> hmm cat-a-puss? really?</p>
17:10 <+zzz> HTTP persistent connections update: client side mostly done, server side making good progress, lots of bulletproofing and testing to do, est. completion 2-4 wks</p>
17:10 < jrandom> nice1 zzz!</p>
17:11 < cat-a-puss> jrandom: yeah I talked to you about that a long time ago, I could probably find the long explination as to why, but it's probably best to just document that somewhere as there is no reason to do it.</p>
17:12 < jrandom> hmm I'm out of context, what exactly does not work? what is sun's bug? </p>
17:14 < dust> i get weird logs like this: 21:21:59.816 WARN [%d0%a2%d1%4f] net.i2p.util.EepGet : ERR: status &lt;html&gt;</p>
17:14 < jrandom> hmm, interesting</p>
17:15 < jrandom> what tracker?</p>
17:15 < cat-a-puss> jrandom: As I recall sun uses headerless zips and some magic number to tell that it's a zip stream. But the number just so happens to be negitive, so if you endup creating a zip stream within a zip stream for some reason, it reads the data out of the stream as a sequence of unsigned bytes and so the magic number gets converted to some other positive number. (I am probably missing some detail but that is the gist of it)</p>
17:16 < dust> for example the OSDevWithCVS_3E.pdf.torrent</p>
17:17 < dust> d8:announce540:http://YRgrgTLGnbTq2aZOZDJQ...</p>
17:17 < jrandom> hmm, I don't know anything about that, and I'm not sure how it'd affect gzip stream over i2ptunnel (if it /did/, they'd all fail, because we gzip evertthing)</p>
17:19 < jrandom> ok cool dust, so postman's tracker. hmm, are you on 0.6.1.9 dust?</p>
17:20 < cat-a-puss> jrandom: yeah it's been almost a year now sense I had that problem so I don't remember too well, and I don't know if it is fixed in 1.5 but I did have a reall devil of a time trying to figure out why every normal type of stream would work, but as soon as I wrapped them in a compressed stream they would all fail.</p>
17:20 < dust> yes</p>
17:20 < jrandom> cat-a-puss: we've changed things dramatically for compression over i2p in the last year ;)</p>
17:21 < jrandom> (and I don't personally use 1.5)</p>
17:21 < jrandom> but we do our own zip encoding explicitly, rather than use their packaged stream (but for anonymity / efficiency reasons, not compatability)</p>
17:22 <@cervantes> zzz: where exactly in the request does the null happen? right after GET?</p>
17:22 <+Complication> Before, if I remember</p>
17:23 <+fox> &lt;lordalbert&gt; hi</p>
17:23 <+Complication> Sidenote: Celeron 300 shows twice lower retran. percentage than Sempron</p>
17:23 < jrandom> 'lo lordalbert</p>
17:23 < jrandom> cool Complication, 2-3% is reasonable (though I'd prefer lower, of course)</p>
17:23 <@cervantes> would be interesting to fire off a load of HEAD requests or something...</p>
17:24 < jrandom> yeah, a set of local tests would be great, though iirc Complication tried that a while back with no errors</p>
17:24 <+fox> &lt;lordalbert&gt; can anyone make a anonymous tracker? I try it but i dont' understand how use the tunnel</p>
17:24 <+Complication> cervantes: I once tried provoking it, with a recursive wget between my 2 nodes</p>
17:24 <+Complication> Grew tired before it happened</p>
17:25 <@cervantes> heh</p>
17:26 <+fox> &lt;lordalbert&gt; 'lo b0unc3 ;)</p>
17:26 <+fox> &lt;b0unc3&gt; lordalbert, :D</p>
17:26 <+Complication> lordalbert: which part would you need advise about?</p>
17:27 <+Complication> About setting up trackers, I unfortunately don't know.</p>
17:27 <+Complication> About I2PTunnel, I could try explaining...</p>
17:27 <+fox> &lt;lordalbert&gt; I have installed BTtracker, and it work perfectly</p>
17:28 <+Complication> It should also be noted that, for the tracker to *remain* anonymous, it should likely run a pretty careful config</p>
17:28 <+fox> &lt;lordalbert&gt; now, i'd like anonimise it</p>
17:28 <+fox> &lt;lordalbert&gt; so</p>
17:28 < jrandom> I'm sure we can help work through it after the meeting. you shouldn't use generic trackers, you need one built for anonymity</p>
17:28 <+fox> &lt;lordalbert&gt; i have just made a i2ptunnel</p>
17:29 < jrandom> (e.g. the bytemonsoon modification that you can find on any of the i2p trackers, or in the cvs)</p>
17:29 <+fox> &lt;lordalbert&gt; now, i'd like to know how use this tunnel. I have made a tunnel yet</p>
17:29 < jrandom> ok, anyone have anything else for the meeting?</p>
17:30 < jrandom> lordalbert: http://localhost:7657/i2ptunnel/ should let you create an 'http server tunnel' pointing at your webserver/tracker, but your tracker will not work unless it has been modified for anonymous use</p>
17:30 <+fox> &lt;lordalbert&gt; jrandom, what tracker i must use?</p>
17:31 <+Complication> postman uses a modified version of ByteMonsoon, I think</p>
17:32 < jrandom> i2p-bytemonsoon has been modified for anonymous use - there's a zip up @ http://i2p-bt.postman.i2p/, and there's the cvs in http://dev.i2p.net/cgi-bin/cvsweb.cgi/bytemonsoon/ but I really don't know much about it</p>
17:32 <+fox> &lt;lordalbert&gt; isn't bytemonsoon obsolete?</p>
17:32 < jrandom> if it works, its not obsolete. it works</p>
17:33 <+fox> &lt;lordalbert&gt; ok XD</p>
17:33 < jrandom> there are many trackers out there, and if some developer wants to modify it to work safely and anonymously, that'd be great</p>
17:33 <+Complication> May well be oldish... but definitely works with destkeys instead of IP's...</p>
17:33 <+Complication> Can't tell about security and leakproofness</p>
17:34 < jrandom> (it was modified by duck et al for anonymity and security)</p>
17:34 <+Complication> But it's been up for a while, and seems to manage...</p>
17:35 < jrandom> ok, if there's nothing else for the meeting...</p>
17:36 * jrandom winds up</p>
17:36 * jrandom *baf*S the meeting closed</p>
</div>
{% endblock %}

114
i2p2www/meetings/165.log Normal file
View File

@@ -0,0 +1,114 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 165{% endblock %}
{% block content %}<h3>I2P dev meeting, January 24, 2006</h3>
<div class="irclog">
15:25 < jrandom> 0) hi</p>
15:25 < jrandom> 1) Net status</p>
15:25 < jrandom> 2) New build process</p>
15:26 < jrandom> 3) ???</p>
15:26 < jrandom> 0) hi</p>
15:26 * jrandom waves</p>
15:26 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2006-January/001254.html</p>
15:26 -!- Teal`c [tealc@irc2p] has joined #i2p</p>
15:26 -!- gloin [gloin@irc2p] has quit [Connection reset by peer]</p>
15:26 < bar> hi</p>
15:26 < jrandom> lets jump on in to 1) Net status</p>
15:26 -!- gloin [gloin@irc2p] has joined #i2p</p>
15:27 < jrandom> I don't have much more to add beyond whats in the mail... anyone have any questions/comments/concerns?</p>
15:27 <+Complication> Moving to CVS build -6 has been... challenging</p>
15:28 < jrandom> aye, understandable</p>
15:28 <+Complication> Net is probably doing fine. It's just my node whcih isn't.</p>
15:28 <+Complication> =which</p>
15:28 < bar> it's a rough road, but it's the right road. i'm 100% supportive of this move</p>
15:29 < jrandom> tunnel building on 2+ hop tunnels is a pain, with nasty failure rates as has been reported</p>
15:29 < jrandom> much of this is likely to be addressed with 0.6.2's new creation crypto, but I'm not convinced that all of it will be.</p>
15:30 < jrandom> I do wonder whether we'll be able to get it reliable enough prior to that though. But we'll try</p>
15:31 <+Complication> If there's any stats I can provide (though you probably have more than enough of them at your own disposal) just ask</p>
15:31 < jrandom> so, 1 hop tunnels are fairly reliable on the latest builds, but those who need 2+ hop tunnels should expect... bumps</p>
15:31 < jrandom> thanks Complication</p>
15:32 <+Complication> Most of my apps are 2+0..1</p>
15:32 <+Complication> And the router itself too, if I remember correct</p>
15:33 < jrandom> well, I could suggest staying at the release, but the release will be building short tunnels anyway if and when it encounters catastrophic failures</p>
15:34 < jrandom> (s/short/1hop/)</p>
15:34 <+Complication> Right, I could probably adjust it to 2+0</p>
15:34 <+Complication> And have less spectacular effects</p>
15:35 < jrandom> aye, though that'll still, in effect, turn to 2+/-1, but it'll try its best to stay at 2hops</p>
15:36 <+Complication> With build -6 too?</p>
15:36 -!- gloin [gloin@irc2p] has quit [Connection reset by peer]</p>
15:36 < jrandom> no, the current release will fail hard rather than go to fallback tunnels</p>
15:37 <+Complication> Or is there probability involved, which never quite goes zero?</p>
15:37 < jrandom> the trouble there is that if it goes for 10 minutes without building the tunnels, it'll restart the router (due to the watchdog)</p>
15:37 <+Complication> Saw it once :)</p>
15:37 < jrandom> no, -5 or newer will use exactly the hop lengths allowed by the client (2+/-0 means only 2 hop tunnels. never anything else)</p>
15:39 < jrandom> ok, anyone have anything else for 1) Net status?</p>
15:39 < jrandom> or, I suppose we're already discussing 2) New build process ;)</p>
15:40 < jrandom> does anyone have anything else to discuss on 2) New build process?</p>
15:40 <+Complication> Not much here, anymore :D</p>
15:41 < jrandom> hehe ok, if not, lets shimmy on over to 3) ???</p>
15:41 < jrandom> anyone have anything else they want to discuss?</p>
15:42 < bar> may i ask, how many backwards incompatible changes are lined up now, and if some (all?) can be put into one release?</p>
15:42 < bar> i mean, is there more than one backwards incompatible release planned, until 0.6.2?</p>
15:42 < jrandom> bar: the hope is to do them all at once</p>
15:42 < jrandom> (though there may be further ones down the line)</p>
15:43 -!- Complication [Complicati@irc2p] has quit [Connection reset by peer]</p>
15:43 -!- Complication2 [Complicati@irc2p] has joined #i2p</p>
15:43 < bar> hmac bug, new crypto and restricted routes at once?</p>
15:43 < bar> that's a tall order :)</p>
15:43 < jrandom> restricted routes?</p>
15:43 < jrandom> the hmac bug "fix" is changing one value ;)</p>
15:44 < bar> ah :)</p>
15:44 -!- Complication2 is now known as Complication</p>
15:44 < bar> umm.. perhaps restricted routes was 2.0..</p>
15:44 < jrandom> yeah, but restricted routes will be doable without losing backwards compatability</p>
15:45 < jrandom> (in fact, it can be done with 0.6.2, if done carefully, to a degree)</p>
15:45 < bar> ok, great</p>
15:45 < jrandom> I'm also thinking of when to drop tcp... maybe in the next release</p>
15:46 < jrandom> or maybe after, so we don't have /too much/ at once</p>
15:49 < jrandom> ok, anyone have anything else for the meeting?</p>
15:51 < jrandom> if not</p>
15:51 * jrandom winds</p>
15:51 < stealth> I have some question: I noticed that all eepsites are mapped to the external internet e.g. http://tracker.postman.i2p.tin0.de/. Is that wanted ?</p>
15:51 < jrandom> [saved]</p>
15:51 < jrandom> sure, I think thats cool</p>
15:51 < jrandom> anyone who publishes information should expect that their information is public </p>
15:52 -!- gloin [gloin@irc2p] has joined #i2p</p>
15:52 < jrandom> I think tino has a way for people to topopt out as well</p>
15:52 < tethra> that was short</p>
15:53 < stealth> They are also indexed by google...</p>
15:53 < jrandom> isnt that a good thing stealth?</p>
15:53 < Complication> Did it not involve some convention similar to "robots.txt"</p>
15:54 < jrandom> aye Complication </p>
15:54 < Complication> (might be best to ask tin0)</p>
15:54 <@postman> damn, i am too late</p>
15:54 <@postman> (again)</p>
15:54 < jrandom> nah, hasn't ended yet postman :)</p>
15:54 < Complication> He wrote about it in the forum, at some point</p>
15:54 < Complication> Might be findable there</p>
15:54 <@postman> ahh cool ( hello then) :)</p>
15:55 < jrandom> yeah, its opt-out-able, but I don't understand the concept of opt-out for the i2p content (are people pushing some idea of 'copyright' - "don't copy my stuff or make it visible other places"?)</p>
15:55 < jrandom> but, whatever, tino is being nicer than I would be regarding inproxies ;)</p>
15:56 -!- Rawn [Rawn@irc2p] has quit [Connection reset by peer]</p>
15:56 -!- gloin [gloin@irc2p] has quit [Connection reset by peer]</p>
15:57 -!- Karellen [Karellen@irc2p] has quit [Connection reset by peer]</p>
15:57 < Complication> Yes indeed, the assumption shouldn't follow that other providers of in-proxies will be equally nice</p>
15:58 -!- Karellen [Karellen@irc2p] has joined #i2p</p>
15:58 -!- Rawn [Rawn@irc2p] has joined #i2p</p>
15:58 -!- mode/#i2p [+v Rawn] by chanserv</p>
15:59 < Complication> Information intended to be secret... is best simply not published</p>
15:59 < tethra> indeed :/</p>
15:59 < stealth> Yes but it might turn too much publicity to i2p before evrything is really totally save. The problem seems to me that I2p has at the moment not enough nodes for a very good anonymity...</p>
16:00 -!- Complication [Complicati@irc2p] has quit [Connection reset by peer]</p>
16:00 < jrandom> our anonymity isn't dependent upon the size, and i2p has been googled plenty</p>
16:01 < jrandom> (or, the base level of anonymity isn't dependent upon the size)</p>
16:01 < jrandom> but, of course, no one who needs hard anonymity should use i2p now.</p>
16:01 -!- digger3 [digger3@irc2p] has quit [Connection reset by peer]</p>
16:01 -!- digger3 [digger3@irc2p] has joined #i2p</p>
16:02 < bar> i wouldn't worry, 99% would just ignore the seemingly dead link that turns up on google... the other 1% is likely somewhat geeky and would want to know more</p>
16:03 -!- gloin [gloin@irc2p] has joined #i2p</p>
16:03 < bar> (well.. dead, that depends on tino's inproxy being up or not, of course)</p>
16:05 < jrandom> ok, anyone have anything else for the meeting?</p>
16:06 < jrandom> if not</p>
16:06 * jrandom winds up</p>
16:07 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

142
i2p2www/meetings/166.log Normal file
View File

@@ -0,0 +1,142 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 166{% endblock %}
{% block content %}<h3>I2P dev meeting, January 31, 2006</h3>
<div class="irclog">
15:19 < jrandom> 0) hi</p>
15:19 < jrandom> 1) Net status</p>
15:19 < jrandom> 2) 0.6.1.10 status</p>
15:19 < jrandom> 3) ???</p>
15:19 * jrandom waves</p>
15:19 < jrandom> status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-January/001257.html</p>
15:20 < jrandom> ok, jumping on in to 1) Net status</p>
15:21 < jrandom> as mentioned in the mail, those on 0.6.1.9-0 (the full release) should have the same-ol'-same-ol'</p>
15:21 < jrandom> though users on newer builds (those since 0.6.1.9-5 or newer) may have trouble</p>
15:21 < jrandom> ("trouble" is perhaps an understatement...)</p>
15:21 <+Complication> CVS -8 was a bit flaky, so running -2 instad (works nice enough)</p>
15:22 < gloin> :-)</p>
15:22 <+Complication> =instead</p>
15:22 < Pseudonym> things seem unstable lately (I'm on 0.6.1.9-0)</p>
15:22 < jrandom> cool, I was considering reverting the process changes but including dust's ircclient update and the i2ptunnel httpserver patch on head, but 0.6.1.10 probably isn't that far away</p>
15:23 < jrandom> hmm Pseudonym, accessing eepsites, irc, or other services, or hosting them?</p>
15:23 <+Complication> Unstable with -0? How does the problem exibit itself?</p>
15:23 < Pseudonym> I notice IRC primarily (playing idlerpg)</p>
15:24 < jrandom> ("playing" ;)</p>
15:24 < Pseudonym> also, somtimes the router goes wonky and has to be restarted (no active peers)</p>
15:24 < Pseudonym> heh</p>
15:24 < jrandom> hmm, internet connectivity issues?</p>
15:24 <@frosk> -0 is stable here, of course except for the twice-daily "router hung!" restarts</p>
15:24 < jrandom> hrm frosk, real "router hung", or "router hung" due to leaseSet expiration?</p>
15:25 < Pseudonym> internet connectivity is fine. when I restart the i2p router it comes right back</p>
15:25 <+Complication> My Cel300 also hangs after a while, but the periods have been increasing, and I'm not up-to-date on its reason</p>
15:25 <@frosk> jrandom: lease expiration, i'm pretty sure</p>
15:25 < jrandom> hmm 'k</p>
15:26 < jrandom> pretty much all of that has been rewritten for the new creation and management code, so we'll see how it goes in 0.6.1.10</p>
15:27 <@frosk> cool</p>
15:27 <@frosk> i'll be glad to help test it</p>
15:28 < Pseudonym> I don't need you to troubleshoot the problem right now. I just wanted to add a datapoint about stability</p>
15:28 < jrandom> wikked, once its stable locally I'll certainly need to recruit some help :)</p>
15:28 < jrandom> cool, thanks Pseudonym </p>
15:28 < jrandom> ok, anyone else have something for 1) Net status?</p>
15:30 < jrandom> if not, lets jump on in to 2) 0.6.1.10 status</p>
15:30 < jrandom> as mentioned in the mail, rather than pile tweak upon tweak on the live net, we're going to go straight to the source</p>
15:31 < jrandom> it won't be backwards compatible, so it will have a... bump, and while we'll roll up a few other backwards incompatible changes with it, there is the possibility for another one afterwards</p>
15:32 < jrandom> more specifically, one idea I'm toying with is migrating to 1024bit ElGamal for the tunnel creation code, rather than 2048bit</p>
15:32 < jrandom> but that may not be necessary. it depends on how hard it hits us on the live net</p>
15:34 < jrandom> if it does, it would just mean a network upgrade, but all destinations/etc would stay the same.</p>
15:34 < jrandom> but, anyway, thats something to explore after 0.6.1.10 comes out</p>
15:34 <+Complication> A loosely related question: is the key length in any way related to the tunnel-creation datastructure length?</p>
15:34 < jrandom> yes</p>
15:35 < jrandom> directly related: key length * 2 * max # hops == data structure size</p>
15:36 < jrandom> (so, 256*2*8 = 4KB, which also happens to be the size of full streaming lib messages)</p>
15:37 < jrandom> ((ElGamal has a 2x expansion factor))</p>
15:38 <+Complication> Aha, thanks. :)</p>
15:38 < jrandom> ah, one other thing re: the new spec. during implementation I found one other data point I need (a 4 byte "reply message ID") which I've added to the spec locally, using some of the reserved bits</p>
15:40 < jrandom> I'm hoping to get everything working in the next few days though, so perhaps there'll be some early (non-anonymous) testing by the weekend</p>
15:40 < jrandom> but, of course, more info on that as it comes</p>
15:41 < jrandom> ok, anyone have any questions/comments/concerns on the 0.6.1.10 stuff?</p>
15:41 < bar> another loosely related question: during the rol out of .10, how about keeping i2p.net on .9 for a couple of days for all the auto updating folks?</p>
15:41 < bar> rollout*</p>
15:41 < jrandom> aye, definnitely</p>
15:42 < jrandom> I'll probably have two or three routers on that box during the migration</p>
15:42 < jrandom> and there will be loud warnings at least 5 days in advance of the release</p>
15:42 < bar> smooth</p>
15:42 <+Complication> This way it would be smoother indeed.</p>
15:43 <+Complication> Forum seems a good channel. News box on the Router Console too...</p>
15:43 * jrandom remembers the days when every release was backwards incompatible... we got a lot of practice then ;)</p>
15:43 < jrandom> aye, forum, news box, list, website</p>
15:43 <+Complication> So those who attend their machines would know.</p>
15:43 < tethra> heheh</p>
15:44 < jrandom> and those on 0.6.0.1 still, well, they're fscked anyway ;)</p>
15:44 <@frosk> off with their heads</p>
15:44 <+Sugadude> Totally un-related: Can we have more backwards incompatible changes more often to force these old routers out?</p>
15:44 <+Complication> I think they just forgot I2P running :)</p>
15:44 < jrandom> heh Sugadude</p>
15:45 < jrandom> well, if they're compatible, we can make use of their resources, but if there's some reason why we can't, we should mark them as incompatible</p>
15:47 < jrandom> ok, if there's nothing else on that, lets jump on over to our catch-all: 3) ???</p>
15:47 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
15:48 < tethra> it says somewhere on the router console that users behind symmetric NATs aren't currently supported, is that going to change at some point soon? </p>
15:48 < tethra> or am i showing immense ignorance of something</p>
15:49 <+Complication> Regarding webcache code... it seems I'm pretty much ready.</p>
15:49 < jrandom> there are a few techniques to help users behind symetric nats, which bar has outlined on the list and the forum, though I don't know of any immediate progress on it</p>
15:49 < jrandom> oh, nice1 Complication, lemmie know when to push the release :)</p>
15:50 <+Complication> Got the watchdog aborting downloads reasonably, doing some testing and clean-up (it currently logs way more than decent)..</p>
15:50 <+Complication> I have one webcache server up, awup has another... for some realistic testing, we may want to turn limiting on...</p>
15:51 <+Complication> ...if I manage to encounter legion, I'll ask if he might be interested in running one too.</p>
15:52 < jrandom> cool, even a single webcache would be a great start</p>
15:52 <+Complication> And if anyone else wants to run the script (available from awup.i2p, Python script using SAM)... their references can be added, though currently adding refs to more "seed webcaches" does require a recompile of sources.</p>
15:53 <+Complication> (not in a file but the header of GWebCacheContainer.java)</p>
15:53 * gloin don't know what this webcache stuff is.</p>
15:53 < jrandom> gloin: it lets you connect to i2phex without having to download an i2phex.hosts file the first time</p>
15:54 <+Complication> gloin: for easier integration of I2PHex</p>
15:55 * cervantes arrives late</p>
15:55 <+Complication> And for later reconnecters (e.g. people who've run out of live peer refs) it can offer fresh refs</p>
15:55 < gloin> ok.</p>
15:57 <+Complication> Oh, offline again</p>
15:58 < stealth> what about an automatic startup of i2phex after i2p has started ?</p>
15:58 <+Complication> Seems like overkill</p>
15:58 <+Complication> At current phase, at least</p>
15:58 < jrandom> stealth: you can have the i2p router launch any java application you want by adding entries into your client.config file</p>
15:59 <+Complication> Besides, I think I2Phex can be started before I2P runs</p>
15:59 <@frosk> at any phase</p>
15:59 <+Complication> Theoretically, it should keep trying to connect until I2P gets up</p>
15:59 <+Complication> (haven't tested, though)</p>
15:59 < jrandom> though remember, if you tell it to launch i2phex, when i2phex closes, chances are the i2phex client will kill the JVM (restarting your router)</p>
16:00 <+Complication> Besides, one could script it fairly easily too...</p>
16:00 <+Complication> e.g. "cd /home/i2p; sh i2prouter start; cd /home/i2phex; sleep 100; sh run.sh;"</p>
16:00 <+Complication> (or however it was)</p>
16:01 <+Complication> Sorry, /home/user/i2p more likely :)</p>
16:01 < cervantes> don't forget to start /usr/games/tetris before the sleep 100</p>
16:02 < jrandom> damn straight</p>
16:02 < jrandom> ok, anyone have anything else for the meeting?</p>
16:03 < stealth> well I thought about it just start the exe. the i2psnark solution with always on is better because people forget to share their files if they are not downloading...</p>
16:04 < jrandom> aye, though I've yet to hear of a gnutella client that is thin enough (that could be integrated)</p>
16:05 < cervantes> isn't the work being done on the current Phex to abstract the UI? perhaps the client eventually become skinny</p>
16:05 <+Complication> I haven't read that part of Phex CVS</p>
16:06 < jrandom> if phex could be run as a .war, that would indeed rule</p>
16:06 < cervantes> isn't the=isn't there</p>
16:06 < cervantes> I'm probably mistaken</p>
16:06 <+Complication> Sirup certainly was working on an XML-RPC interface, but I'm not sure if Gregor & co are too</p>
16:07 <+Complication> So I'm not sure if sirup ported it in, or started writing it from scratch</p>
16:09 < jrandom> iirc he was just importing apache's xmlrpc lib and exposing some of i2phex's internals, but there hasn't been any work on that in probably 6-8 months, and it was never functional afaik</p>
16:10 < fox_> &lt;tethra> mutella is a web based gnutella client that is fairly lightweight, iirc. not sure if it will be any help, but heh, might be worth someone (more talented) checking it out.</p>
16:10 < fox_> &lt;tethra> might not be what is being looked for, though.</p>
16:12 < jrandom> porting a new one is a chunk of work, especially a C/C++ one, unfortunately</p>
16:12 <+Complication> I'm personally unlikely to tinker with XML-RPC. Attempting to catch various bugs... is in my near-term plans, though.</p>
16:13 * Complication wants the rehash effect gone for good, since it's such a waste of time</p>
16:13 < jrandom> ooh, perhaps thats triggered by timezone shift?</p>
16:14 < jrandom> when the I2P SDK connects to the router, it gets the current I2P (NTP) time from it, and forces the SDK's JVM into UTC</p>
16:14 <+Complication> Sounds unlikely... but at this stage, I can't exclude much</p>
16:15 < jrandom> (and if the rehash depended upon ordering and file timestamps, perhaps the shift of a few hours would change that)</p>
16:15 < jrandom> yeah, you've dug into a lot of it, just mentioning a possibility</p>
16:15 * jrandom doesn't know anything about it beyond your bug reports :)</p>
16:16 <+Complication> It occurs occasionally, and *seems* related to something happening when the "sharedlibrary" config file is being loaded/rewritten</p>
16:16 <+Complication> Hmm, interesting possibility...</p>
16:16 <+Complication> I've not dug enough to exclude that</p>
16:18 < jrandom> ok, anyone else have something for the meeting?</p>
16:19 < jrandom> if not...</p>
16:19 * jrandom winds up</p>
16:19 * bar wishes jrandom good luck with .10 and hands him a shiny baf</p>
16:19 < jrandom> gracias :)</p>
16:19 * jrandom *baf*s the meeting closed </p>
</div>
{% endblock %}

151
i2p2www/meetings/167.log Normal file
View File

@@ -0,0 +1,151 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 167{% endblock %}
{% block content %}<h3>I2P dev meeting, February 7, 2005</h3>
<div class="irclog">
15:36 < jrandom> 0) hi</p>
15:36 < jrandom> 1) Net status</p>
15:36 < jrandom> 2) _PRE net progress</p>
15:36 < jrandom> 3) I2Phex 0.1.1.37</p>
15:36 < jrandom> 4) ???</p>
15:36 < jrandom> 0) hi</p>
15:37 * jrandom waves</p>
15:37 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-February/001258.html</p>
15:37 < bar> hello</p>
15:38 < jrandom> while y'all dig through that oh-so-exciting material, lets jump on in to 1) Net status</p>
15:38 < jrandom> there hasn't been much changed on the live net in the last week, from an i2p perspective, so I don't really have much to add here</p>
15:39 < jrandom> anyone have anything they want to bring up regarding the current net status?</p>
15:39 < KBlup> I have seen terrible spikes of failing clients when running i2p for long... dunno if thats fits to 1)</p>
15:39 < jrandom> KBlup: does that correlate to high cpu load or bandwidth consumption?</p>
15:40 < KBlup> resuluts in msg-delay &gt; 10000ms :-/</p>
15:40 < jrandom> ah, very likely one of the causes of the _PRE net being developed :)</p>
15:40 < KBlup> I think it then tries to establish new tunnels and fails constantly, which results in 300+ jobs some times...</p>
15:41 < KBlup> my maschine is quite strong but overloaded with that...</p>
15:41 < jrandom> aye, thats all been reworked along the way for 0.6.1.10, hang tight until thats ready</p>
15:43 < jrandom> ok, anything else on 1), or shall we mosey on over to 2) _PRE net progress</p>
15:43 <+Complication> 0.6.1.10 seems to contain substantial changed indeed</p>
15:45 < jrandom> yeah, there's a lot of meat under here. The current state is that the new creation code is in place and seems to be working properly, but now I'm using this opportunity to debug some of the underlying issues further</p>
15:46 <+Complication> You mentioned having to cough up a lot of CPU time in advance</p>
15:47 <+Complication> Would this cost now be associated with building any sort of a tunnel?</p>
15:48 <+Complication> (meaning, before the construction, during a short while, you'd have to perform a batch of heavy crypto)</p>
15:48 < jrandom> yes, all tunnel build requests will need to do k heavy crypto operations (where k = number of hops in the tunnel being built)</p>
15:49 <+Complication> Whad I wanted to ask... is the interval just tighter than before, or the amount bigger too?</p>
15:50 < jrandom> the amount is both bigger, smaller, and tighter. tighter, in that they're all done upfront. bigger, in that we can't short circuit and not do the encryption for a hop if an earlier hop rejects it, and smaller in that earlier hops fail a lot less</p>
15:51 < jrandom> in addition, however, unlike earlier releases, we're no longer using ElGamal/AES+SessionTag for the tunnel requests - we use (fairly) straight ElGamal</p>
15:52 <+Complication> ...and it couldn't be pre-calculated, unless one knew the final set that's going to succeed?</p>
15:52 < jrandom> that means that while we used to be able to cheat without an asymmetric operation, we don't try to cheat anymore (as the cheating itself exposed a class of attacks)</p>
15:53 <+Complication> (set of peers)</p>
15:53 < jrandom> hmm, it could certainly be precalculated, assuming you know who the peers in the tunnel that are going to be asked</p>
15:54 < jrandom> the new tunnel creation process is done on a separate thread, so it doesn't bog down the main job queue under load, and so that it can throttle itself better</p>
15:54 <+Complication> Could one also assume that, barring change in available knowledge, one knows a few whom one is going to ask from, if attempts fail?</p>
15:54 < jrandom> hmm, not entirely sure I follow</p>
15:55 <+Complication> Or is knowing them already useless, since the struct must be redone from scratch?</p>
15:56 <+Complication> (meaning: the ElGamals redone from scratch, at least)</p>
15:56 < jrandom> ah, the structure is http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.requestRecord</p>
15:56 < jrandom> so, yes, if the next hop changes, the ElGamal must be redone</p>
15:56 < jrandom> (if you precompute)</p>
15:56 <+Complication> Right, I wasn't sure enough about that instantly</p>
15:57 <+Complication> Now I realize it, though</p>
15:57 < jrandom> otoh, we're really trying to get our build success rate up, and the new build process should be able to adapt to minimize unnecessary creations</p>
15:58 <+Complication> How does it seem doing in reality?</p>
15:58 < jrandom> (oh, that structure has been slightly modified on the _PRE branch: http://dev.i2p.net/cgi-bin/cvsweb.cgi/~checkout~/i2p/router/doc/tunnel-alt-creation.html?rev=1.1.2.1;content-type=text%2Fhtml#tunnelCreate.requestRecord )</p>
15:59 <+Complication> I noticed the detail about ElGamal encrypts taking a leap towards quickness...</p>
15:59 < jrandom> well, the build success rate is much much higher than it is on the live net, but that may just be due to the small _PRE net size</p>
16:00 < jrandom> yeah, creating a 2 hop structure, for instance, takes an average of 44ms over 1120 runs, as compared to the live net's ElGamal encryption time of 542ms (over 1344 runs)</p>
16:02 < jrandom> (on the same box)</p>
16:02 <+Complication> Would this 542 include retries on failure too, or just the pure building?</p>
16:02 <+Complication> If it's pure building, I need to find my lower jaw... it's on the floor somewhere. :P</p>
16:02 < KBlup> about that change of the exponent : at what scale does that affect anonymity?</p>
16:02 < jrandom> no, thats the pure elGamal stat, since the live net doesn't build the new _PRE net structure</p>
16:04 < jrandom> KBlup: anonymity? none. security? according to what I've read, 228 bits is more than enough to match 2048bit ElGamal</p>
16:04 * Complication doesn't know much about ElGamal's x and y</p>
16:04 <+Complication> Not enough to comment meaninfully</p>
16:06 <+Complication> If serious researchers consider the shorter x hard enough, and those crypto wonks didn't run away screaming...</p>
16:06 <@cervantes> well not only that, but the implications of dropping to 1024/160</p>
16:07 < KBlup> i guess i have to read the paper later ;)</p>
16:07 <+Complication> cervantes: yes, it's better than that, for sure</p>
16:08 <+Complication> Besides, what is the foremost attack this cipher must repel, and how long is the attack viable?</p>
16:09 <+Complication> Could it be something which benefits you only if you break it quick, or also benefits if you break it eventually?</p>
16:11 <+Complication> If I understand right, the immediate secret it guards is the next tunnel participant, right?</p>
16:11 <+Complication> (or more precisely, the next-to-next one)</p>
16:11 <@modulus> meeting ongoing?</p>
16:11 <+Complication> (which only the next one may know)</p>
16:11 <@cervantes> modulus: ayre</p>
16:11 <@cervantes> -r</p>
16:11 < jrandom> for a practical (yet insanely powerful) adversary, breaking it during the tunnel lifetime would be necessary. breaking it after that tunnel lifetime would only help if you logged all network traffic and broke all tunnels (that is, after breaking the ephemeral transport layer crypto and working on the tunnel layer crypto)</p>
16:11 < jrandom> so, we're talking on the order of minutes here, not decades</p>
16:12 < jrandom> (so 1024bit is probably even overkill)</p>
16:12 <@cervantes> is there a way to measure the risk in a meaningful way?</p>
16:13 <+Complication> Besides, for a tunnel with more hops, the adversary would have to break several, right?</p>
16:13 <+Complication> (though the builder would have to build several too)</p>
16:13 <@cervantes> if we need no more than 1024 bits, then is it really necessary to use more? </p>
16:14 <@cervantes> we can always use a stronger algo in 3 years time when we've got vastly more powerful quantum computers</p>
16:14 <@modulus> jrandom: if the adversary would know that at time hh:mm something important is going to be tunneled is it likely they could break it somehow by logging?</p>
16:14 < jrandom> Complication: right, they'd have to break several (and the DH keys protecting the transport layer)</p>
16:14 <@modulus> afaik 1024bit is break()able with a lot of power</p>
16:15 < jrandom> a lot of power and a decade</p>
16:15 < jrandom> (or three)</p>
16:15 <@cervantes> jrandom: is it difficult to try the weaker cipher?</p>
16:15 <@modulus> i was under the impression that 1024bit composits were factorizable these days in a few months.</p>
16:15 <@cervantes> could we roll out to the pre net </p>
16:15 <@cervantes> and see whether it actually offers much benefit</p>
16:16 <@cervantes> modulus: yes but they'd need to break several</p>
16:16 <@modulus> if this is based on discrete log domain and all that stuff then i don't know anything</p>
16:16 <@modulus> cervantes: aha</p>
16:16 < jrandom> cervantes: it requires changes to a lot of structures, since we currently use 512byte slots. though, perhaps we could just fill the first 256 bytes with 0x00 for testing</p>
16:17 < jrandom> modulus: ElGamal is based on discrete log</p>
16:17 <@cervantes> jrandom: worthy of testing?</p>
16:17 <@modulus> right right, i was imagining RSA</p>
16:17 <@cervantes> or better to focus on other things and return to it if necessary</p>
16:18 < jrandom> definitely worth testing, though for the moment I'm hacking away at some transport layer evaluations</p>
16:18 <+Complication> I guess it depends on how their calculation can be handled in real life.</p>
16:18 < jrandom> (and the 44ms encryption time is good enough for the moment, though a 4ms encryption time would be even better :)</p>
16:19 <+Complication> If it holds together with current computers, it will improve with newer machines.</p>
16:19 <@modulus> especially if there comes crypto hw, as it is starting to come in some</p>
16:19 < jrandom> but, of course, changing this parameter will not be done lightly or immediately. but if someone has a good reason to avoid it, please get in touch</p>
16:21 < jrandom> modulus: I've heard of dedicated AES and RSA chips, but nothing on DH/ElGamal. otoh, when one looks to the NSA/etc as an adversary, where they can build their own, its possible</p>
16:22 <@cervantes> they have crypto machines built on ring sprinkled donut technology</p>
16:23 * Complication is willing to upgrade the Celeron 300 to Athlon 600, if it holds the tide of ring-sprinkled donuts :D</p>
16:23 < tethra> heheh</p>
16:24 < jrandom> mmMMmm donuts</p>
16:25 < jrandom> ok, anyone have anything else on 2) _PRE net progress?</p>
16:25 < jrandom> if not, lets jump on over to 3) I2Phex 0.1.1.37</p>
16:26 < jrandom> Complication: wanna give us the skinny?</p>
16:26 <+Complication> Well, it seems to work. :)</p>
16:26 <+Complication> There is hope of getting more webcaches for extra redundancy soon.</p>
16:27 < jrandom> word</p>
16:27 < jrandom> hmm, do you think we need more webcaches? don't we just need one to be up? not that more hurts, of course</p>
16:27 <+Complication> (if legion manages to solve the mysteries which haunted his initial try)</p>
16:27 <+Complication> There's also a mystery bug in there, but it doesn't byte hard, and I'm trying to find it.</p>
16:28 <+Complication> One up is enough</p>
16:28 <+Complication> More just increases the chances that one is up</p>
16:28 < jrandom> cool</p>
16:28 <+Complication> Because at current stage, it will never drop webcaches as bad. Too few of them altogether.</p>
16:29 <+Complication> (that routine will activate if there exist more than 10)</p>
16:29 <+Complication> (if I remember correctly)</p>
16:29 <+Complication> As for the bug: after a long time operating, the webcache subsystem sometimes stalls</p>
16:30 <+Complication> Likely because a httpclient's GET request can't be aborted successfully</p>
16:31 <@modulus> so it needs to die from time to time?</p>
16:31 <+Complication> It's safe, and never seems to bite freshly joined machines</p>
16:31 < jrandom> hmm, what does that mean, functionally? after a while, it will stop registering with the webcache, so new people won't be given references to them?</p>
16:31 <+Complication> If it bites a machine already well integrated, that machine can get enough peers from the peers it's already connected to</p>
16:31 <+Complication> So currently the impact seems close to 0</p>
16:31 <@modulus> cool</p>
16:32 <+Complication> It's curious, just</p>
16:32 <@modulus> no rule about when it will fail or anything?</p>
16:32 <+Complication> modulus: generally not before 20 hours</p>
16:33 <+Complication> And since I have no way of forcing it to occur, debugging is a bit slow</p>
16:33 <@modulus> :_)</p>
16:34 <+Complication> Either way, should I find it, I'll fix it, and should I not find it, I'll find other stuff to tinker with :)</p>
16:34 < jrandom> :)</p>
16:34 < jrandom> sounds like its just a symptom of some bugs we've seen in the streaming lib / eepproxy, so fixing those should fix this</p>
16:35 <+Complication> Could be</p>
16:38 < jrandom> ok great, nice work Complication</p>
16:38 < jrandom> anyone have anything else on 3) I2Phex 0.1.1.37, or shall we jump on over to the catch-all, 4) ???</p>
16:41 < jrandom> (consider us jumped)</p>
16:41 < jrandom> ok, anyone have anything else for the meeting?</p>
16:42 < tmp> Or forever hold your breath?</p>
16:43 < jrandom> and ever and ever</p>
16:43 * jrandom winds up</p>
16:43 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

74
i2p2www/meetings/168.log Normal file
View File

@@ -0,0 +1,74 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 168{% endblock %}
{% block content %}<h3>I2P dev meeting, February 14, 2006</h3>
<div class="irclog">
15:39 < jrandom> 0) hi</p>
15:39 < jrandom> 1) Net status</p>
15:39 < jrandom> 2) 0.6.1.10</p>
15:39 < jrandom> 3) Syndie activity</p>
15:39 < jrandom> 4) ???</p>
15:39 < jrandom> 0) hi</p>
15:39 * jrandom waves</p>
15:39 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-February/001260.html</p>
15:39 < jrandom> (I'm a lil late with that, so I'll give y'all a minute to skim through those brief notes)</p>
15:40 <+Complication> hello</p>
15:40 <@cervantes> 'lo</p>
15:41 < jrandom> well, its brief enough, so lets just jump on in to 1) Net status</p>
15:41 < jrandom> I don't have anything to add to this one, anyone have something on it to discuss?</p>
15:41 <@cervantes> &lt;jrandom&gt; (damn flakey net connection)</p>
15:41 <+Complication> A bit congested occasionally, but graphs suggest it's nothing new</p>
15:42 < jrandom> heh cervantes, well, thats due to one of my roommates using limewire, not i2p ;)</p>
15:43 <@cervantes> we've had various server problems too with irc and postman's tracker over the past couple of weeks - postman has done a lot of migrations, so things should be more stable for folk</p>
15:43 <+Complication> It must be hard letting them do that, but I guess... such is life :O</p>
15:43 <+Complication> do that=use limewire</p>
15:44 <+Complication> This morning, tracker.postman.i2p was refusing connections, though</p>
15:44 < jrandom> Complication: disk was full, fixed now</p>
15:44 < jrandom> (new machines have their new quirks)</p>
15:46 < jrandom> ok, anyone have anything else on 1) Net status?</p>
15:46 < jrandom> otherwise, lets shimmy on over to 2) 0.6.1.10</p>
15:47 < jrandom> As mentioned, we're going to have a new backwards incompatible release in a few days</p>
15:48 < jrandom> while it alone won't revolutionize our performance, it will improve a few key metrics to get us on our way</p>
15:48 < jrandom> there are also a whole bunch of bug fixes in there too</p>
15:49 <@cervantes> will zzz's server tunnel improvements make the fold?</p>
15:49 < jrandom> oh, and there's that whole improved anonymity thing... ya know, sine qua non</p>
15:50 < jrandom> cervantes: probably not, haven't heard much since that post to zzz.i2p last week. i did do some minor bugfixes in cvs though (to should support lighttpd, etc), but we won't have zzz's persistent connections</p>
15:50 < jrandom> (yet)</p>
15:51 <@frosk> what DH key size/etc did you land on?</p>
15:51 <@cervantes> yeah, I saw those newline issues a few weeks ago, but I held off changing them because of zzz's impending improvements</p>
15:51 < jrandom> ah, for the moment we'll be sticking with 2048bit crypto with small exponents</p>
15:52 <@frosk> so some lower cpu consumption can be expected?</p>
15:52 < jrandom> aye</p>
15:53 <@frosk> excellente</p>
15:53 < jrandom> switching to 1024bit would cut another order of magnitude to the CPU load, but would require some reworking of the tunnel creation structures (1024bit asym isn't large enough to convey the data we need to convey). </p>
15:54 < jrandom> we may explore that in the future though, but this next release should substantially cut down cpu overhead</p>
15:54 < jrandom> I've also disabled the TCP transport, because I'm a mean and vicious person</p>
15:55 <@frosk> do you expect any more incompatible upgrades before 1.0?</p>
15:55 < jrandom> hope not</p>
15:55 * cervantes must be a danish cartoonist</p>
15:55 <@frosk> i don't think we'll miss tcp :)</p>
15:55 <@cervantes> I mean jrandom must be</p>
15:55 <@cervantes> ;-)</p>
15:55 * jrandom watches the embassy burn</p>
15:56 < jrandom> ok, anyone have anything else on 2) 0.6.1.10?</p>
15:56 < void> why wouldn't it support lighttpd earlier?</p>
15:56 < jrandom> (ah, as an aside, there have also been some interesting improvements to the streaming lib for 0.6.1.10, such as tcp-style fast retransmit, etc, so we'll see how that helps)</p>
15:57 <@cervantes> void: malformed headers</p>
15:57 < jrandom> void: bug where we weren't standards compliant</p>
15:57 < void> ah, are these inconsistent newline bugs also fixed?</p>
15:58 < void> and what about the null character one? are you waiting for zzz's persistent connection patch?</p>
15:58 < jrandom> the newline bug is the malformed header, and is fixed</p>
15:58 < jrandom> no news on the null character one</p>
15:59 < void> ok</p>
16:00 < jrandom> ok, if there's nothing else on 2, lets swing on by 3) Syndie activity briefly</p>
16:00 < jrandom> well, I don't really have much to add...</p>
16:01 < jrandom> (I /did/ say briefly)</p>
16:01 < jrandom> so lets jump on to 4) ???</p>
16:01 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
16:01 <+fox> &lt;duck&gt; too busy reading Syndie to comment</p>
16:01 < jrandom> ;)</p>
16:02 * Complication is too busy issuing meaningless signatures to comment :D</p>
16:05 < jrandom> ok cool. just another reminder for people to stay away from CVS for the next day or two until the release, as CVS HEAD is going to get the _PRE branch's changes, and the _PRE branch is going to be retired</p>
16:05 * jrandom winds up</p>
16:05 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

122
i2p2www/meetings/170.log Normal file
View File

@@ -0,0 +1,122 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 170{% endblock %}
{% block content %}<h3>I2P dev meeting, February 28, 2006</h3>
<div class="irclog">
15:11 < jrandom> 0) hi</p>
15:11 < jrandom> 1) Net status and 0.6.1.12</p>
15:11 < jrandom> 2) Road to 0.6.2</p>
15:12 < jrandom> 3) Miniprojects</p>
15:12 < jrandom> 4) ???</p>
15:12 < jrandom> 0) hi</p>
15:12 * Complication quickly reads notes</p>
15:12 * jrandom waves</p>
15:12 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-February/001266.html</p>
15:12 < jrandom> (and here I was posting the notes more than 15 minutes before the meeting! ;)</p>
15:13 < jrandom> ok while y'all read those oh-so-exciting bits, lets jump on in to 1) Net status and 0.6.1.12</p>
15:14 < jrandom> as mentioned, the primary goals of the 0.6.1.10-0.6.1.12 releases seem to have been met, addressing the tunnel creation crypto change and improving creation reliability substantially</p>
15:16 < jrandom> the bumps we saw at 0.6.1.10 are gone, and irc stability seems quite good again</p>
15:16 < jrandom> anyone have anything else to bring up for 1) Net status and 0.6.1.12, or shall we mosey on over to 2) Road to 0.6.2?</p>
15:17 <+Complication> Net status over here: no more going back under 20 KB/s :)</p>
15:18 < jrandom> cool, yeah 0.6.1.12 fixed a pretty large bug in 0.6.1.11 where it wouldn't exploit the bandwidth available. it should now make better use of available resources</p>
15:20 < jrandom> ok, lets jump on to 2)</p>
15:20 < jrandom> as mentioned, there are a few things that need to get sorted before the last functional change is put in place for 0.6.2, but we're making progress on that front</p>
15:20 < nymisis> net status is fine :)</p>
15:22 < jrandom> word. there'll be more info available on the specifics of the new peer ordering strategies before they come out, but the gist of them should be clear from their brief mention in the notes</p>
15:23 < jrandom> anyone have any questions/comments/concerns regarding 2) road to 0.6.2?</p>
15:23 < postman> jrandom: any testnets this time?</p>
15:24 < postman> (need any routers, particpants to test stuff)</p>
15:24 < postman> ?</p>
15:24 <+Complication> The essence of the matter seemed quite straightforward - to limit opportunity for an adversary to harvest diverse statistical data</p>
15:25 <+Complication> Sounds like a fairly desirable feature</p>
15:25 < jrandom> postman: the new stuff should work transparently on the live net using local-only info, so shouldn't need a separate net to test</p>
15:25 < jrandom> aye, exactly Complication </p>
15:26 < postman> ok</p>
15:26 < postman> jrandom: are you bold enough to disclose an ETA for 0.6.2 ? :)</p>
15:27 < blubb> 1 april</p>
15:27 < jrandom> well, seeing as today is the end of feb, i'd guess march or april</p>
15:27 < postman> hehe</p>
15:27 < jrandom> blubb: we've already got an mi6 backdoor scheduled for then ;)</p>
15:29 <@cervantes> more like an mi6 catflap</p>
15:29 <@cervantes> (budget cuts)</p>
15:29 < postman> in an elephant house</p>
15:30 < nymisis> That's SIS, not MI6, if you're going to be accurate. :)</p>
15:30 < jrandom> well, lets just call them Them ;)</p>
15:31 < jrandom> ok, anything else for 2)?</p>
15:31 < jrandom> if not, lets shimmy on over to 3) miniprojects</p>
15:31 <@cervantes> sorry "the firm"</p>
15:34 < jrandom> ok, I just wanted to point out a few neat things that would be 1) simple to do and 2) really useful</p>
15:34 <+Complication> On the miniprojects side, I'm not sure if my Syndie reply made it or not, but I'm wondering if I could snatch one.</p>
15:34 <+Complication> Not sure which one yet. Currently practising a little more Java (doing a micro-project :D) just to have added certainty that when I try, I'll be able to handle one</p>
15:35 < DeltaQ> hmm if i upp the bw on the console is the chanes immediate or reboot needed?</p>
15:35 <+Complication> When I get ready with the "micro-project" (assuming of course the table hasn't been cleared yet), I'll try picking one</p>
15:35 < jrandom> w3wt, great Complication </p>
15:36 < jrandom> DeltaQ: immediately </p>
15:36 <@cervantes> isn't 1) syndie scheduler a tie in with 4) Download Manager / eepget scheduler</p>
15:36 <+Complication> DeltaQ: takes effect almost instantly (within the periods that bandwidth gets averaged over)</p>
15:37 <@cervantes> seems to me that a more generally functional up and download manager would service both needs</p>
15:37 < jrandom> cervantes: hmm, not necessarily. 1) is pretty focused, and also includes pushes, while 4) is prety generic</p>
15:37 <+Complication> cervantes: sounds like it could</p>
15:37 < jrandom> but yeah, the engine behind both is EepGet</p>
15:37 < jrandom> (eepget does syndie's http transfers, programatically)</p>
15:38 < DeltaQ> avg doesnt seem yto go above 13kb/s</p>
15:38 < DeltaQ> i set 64kb/s with 192 burst down</p>
15:38 < DeltaQ> 32/64 up</p>
15:38 <@cervantes> so a generic pushing and pulling eepget with a scheduling and management api...</p>
15:39 <@cervantes> still, in probably ceases to become a mini-project at that point</p>
15:39 <+Complication> DeltaQ: the average also depends on how much load your client tunnels (and other peers' participating tunnels) generate</p>
15:39 <+Complication> sorry, s/average/actual bandwidth</p>
15:39 < jrandom> cervantes: yeah, there's substantial logic involved in the syndie stuff though.</p>
15:40 < DeltaQ> heh it finally went up</p>
15:40 < DeltaQ> 1s: 30.82/29.33KBps</p>
15:40 < DeltaQ> guess i needed up upp the ul bw</p>
15:40 < jrandom> DeltaQ: the average will also be affected by how other people view you, which depends upon your actions, not any advertized rate, so it'll take a bit</p>
15:40 <+Complication> DeltaQ: for pass-though traffic (participating tunnels), what comes in must also get out</p>
15:41 <+Complication> DeltaQ: so very different ul/dl rates would choke participating traffic to the lower of the two</p>
15:42 <+Complication> DeltaQ: also, participating traffic depends on how other nodes "perceive" your node's routing capacity</p>
15:42 < DeltaQ> oki</p>
15:43 <+Complication> If they think it can route well, they'll ask more often</p>
15:43 < jrandom> ok, if there's nothing else on 3) miniprojects, lets jump on over to 4) ???</p>
15:43 < jrandom> anyone have anything else to bring up for the meeting?</p>
15:43 < DeltaQ> well i am behind a router but i did map port 8887 to this pc</p>
15:43 <+Complication> If it's new, or has only recently increased in capacity, they're a bit shy</p>
15:44 < DeltaQ> oh sorry i didnt mean to intervere a meeting ^^</p>
15:44 <+Complication> Someone asked the other day, about possible attacks based on clock skew. I think I saw your answer about the tunneling part (creation message holds only tunnel validity period, not time from its creator's perspective)...</p>
15:44 <@cervantes> (thanks for the mention in the status notes) ;-)_</p>
15:46 <+Complication> So I thought, actually, about asking... which points if any at all, in I2P messaging, could contain time from a sender's perspective?</p>
15:47 <+Complication> I've not managed to dig myself up-to-date on this, so I'm a bit clueless about it</p>
15:47 < jrandom> Complication: nothing explicitly says "I think it is now $time", but with sufficient traffic and timing analysis, one could likely narrow it down substantially</p>
15:48 < jrandom> we do quantize the times at a large period, though not as large as our max clock skew, so there is room there</p>
15:49 <+Complication> Do you think there would ultimately be any benefit to receive from a more "streamlined" NTP client?</p>
15:49 <+Complication> One which would / could easier keep skews smaller?</p>
15:50 < jrandom> well, since the sntp client was introduced into i2p, its been getting better and better so that now we don't see the variation we used to</p>
15:51 < jrandom> perhaps we could reduce the minimum-skew limit from 10s to perhaps 2 or 3s, or maybe less</p>
15:51 < jrandom> alternately, we could allow it to look at the ssu clock skews as well to avoid unecessary skews</p>
15:52 <+Complication> Or alternatively, could it be possible to limit further any opportunity to guess at another peer's possible clock value?</p>
15:53 * Complication doesn't know which way would be more practical, just suggesting random possibilities :D</p>
15:53 < jrandom> no, we know the clock skew of directly connected peers</p>
15:55 < Magii> is there anyway to tell if the update was done successfully?</p>
15:55 <+Complication> Aha, so session protocol really depends on that info..</p>
15:55 < tethra> look at your version number</p>
15:55 <+Complication> Magii: it should file a CRIT like "update verified, restarting to install" in logs</p>
15:55 < tethra> :/</p>
15:55 <+Complication> Then, it should count down minutes to a graceful restart</p>
15:56 <+Complication> And finally restart</p>
15:57 <+Complication> Oh, sidenote: does the internal NTP client know of a concept like "clock drift rate"?</p>
15:58 < jrandom> yeah, the version number on the top left corner of http://localhost:7657/index.jsp should be a giveaway :)</p>
15:58 < jrandom> Complication: no, it doesn't guarantee sequential clock ticks</p>
15:59 < jrandom> s/sequential/ordered/</p>
15:59 <+Complication> Nor develop knowledge like "our system clock is 0.00345 times faster than needed"?</p>
16:00 < jrandom> ah, no, though adding that to net.i2p.util.Clock wouldn't be that hard (wanna miniproject? :)</p>
16:00 <+Complication> I was thinking of something along those lines</p>
16:01 <+Complication> I guess I'm now thinking a bit more about it :)</p>
16:01 <+Complication> Other miniprojects first, though :)</p>
16:02 < jrandom> ok, anyone have anything else for the meeting?</p>
16:03 < nymisis> Muffins?</p>
16:04 < jrandom> no, pancakes</p>
16:04 < jrandom> (mmMMmm pancakes)</p>
16:04 < jrandom> speaking of which</p>
16:04 * jrandom winds up</p>
16:04 < nymisis> Oh, darn, good point.</p>
16:04 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

78
i2p2www/meetings/171.log Normal file
View File

@@ -0,0 +1,78 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 171{% endblock %}
{% block content %}<h3>I2P dev meeting, March 7, 2006</h3>
<div class="irclog">
15:08 < jrandom> 0) hi</p>
15:08 < jrandom> 1) Net status</p>
15:08 < jrandom> 2) ???</p>
15:08 < jrandom> 0) hi</p>
15:08 * jrandom waves</p>
15:08 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-March/001267.html</p>
15:09 * jrandom gives y'all hours to read through that huge tome of notes</p>
15:10 * Complication pretends not having noticed yet ;)</p>
15:11 <+Complication> Hi :)</p>
15:11 <+susi23> hi :)</p>
15:12 < jrandom> well, might as well dig on in to 1) net status</p>
15:12 < jrandom> The mail gives my general view of whats going on. how does that line up with what y'all are seeing?</p>
15:13 <+Complication> Throttling fixes seem to have increased reliability, but really suppressed bandwidth</p>
15:13 <+Complication> Just a second, digging for the graph</p>
15:14 <+Complication> http://complication.i2p/files/bw-week.png</p>
15:14 <+Complication> High stretches are on non-latest, low stretches on latest</p>
15:15 <+Complication> Same limiter settings, possibly more lax on stricter (latest) versions</p>
15:16 <+Complication> But it's not much of a problem, since it does transfer</p>
15:16 < jrandom> cool, reduced bandwidth usage is appropriate as you approach your actual bandwidth limit</p>
15:17 <+Complication> Most of time, it seems to bounce back before the "sustained bandwidth" limit</p>
15:17 <+Complication> Never touches the burst limit</p>
15:18 <+Complication> (which, in itself, is sensible - it's the bouncing back before the sustained limit which concerns me)</p>
15:19 < bar> i'm seeing pretty much what Complication is seeing. my total bw consumption is just 50% of my max settings. it used to be ~80% pre 0.6.1.11</p>
15:19 < jrandom> is 200kbps your limiter rate, w/ 300kbps burst?</p>
15:20 < jrandom> (just wondering how much time it used to spend in the burst)</p>
15:20 < jrandom> reduced bandwidth usage though is one of the aims of the recent changes</p>
15:21 <+Complication> ~225 sustained, ~325 burst</p>
15:21 <+Complication> Hey, I could have...</p>
15:22 <+Complication> Have I *interpreted* it wrong?</p>
15:23 <+Complication> Forget it, I'm a fool... did the math wrong, it's not nearly as bad :O</p>
15:23 < jrandom> insufficient data :) it might be indicitive of a problem, but what you've described so far suggests things are behaving as desired</p>
15:23 <+Complication> It's a bit on the conservative side, but not nearly as bad as I thought</p>
15:24 <+Complication> According the Router Console (which measures in the same unit as the limiter) outbound total average is 2/3 of the sustained limit, and 1/2 of the burst limit</p>
15:25 <+Complication> But inbound total average, I have to say, is only slightly above 1/3 sustained limit, and 1/4 burst limit</p>
15:26 <+Complication> for example, assuming a sustained limit of 30, and a burst limit of 40, outbound would be 20 and inbound just above 10 (mostly due to lack of load)</p>
15:26 < jrandom> cool</p>
15:26 <+Complication> But the graph I misinterpreted, due to Kb/KB issues :O</p>
15:27 * Complication wipes the graph from history</p>
15:28 < jrandom> good eye though, definitely lemmie know when things sound funky</p>
15:28 < jrandom> ok, anything else on 1) Net status?</p>
15:28 < jrandom> if not, lets shimmy on over to 2) ???</p>
15:28 < jrandom> anyone have anything else to discuss?</p>
15:30 <+Complication> Well, there's been some jbigi testing, and apparently, someone got results which suggested the 64-bit version for Linux being slowish</p>
15:31 <+Complication> They had it slower than pure Java, not sure if a measurement glitch or not :O</p>
15:32 <+Complication> I couldn't repeat it</p>
15:32 < jrandom> yeah, i wasn't sure exactly what .so they were using for the platform</p>
15:32 <+Complication> Over here, it was about twice faster than pure Java</p>
15:32 <+dust> my experiments with html as an additional message format in syndie is starting to work. my local 'sucker' can now retrieve web pages (with images) and store them as syndie posts</p>
15:33 < jrandom> ah wikked dust </p>
15:33 <+dust> no css tho</p>
15:33 <+Complication> But people on 32-bit spoke of it being *way* faster then pure Java (like 10x or similar)</p>
15:35 < bar> hmm.. Complication, could it be that the current amd64 .so is for 32-bit systems only, and he tested it on a 64-bit OS?</p>
15:36 <+Complication> bar: could be, since I tested it too on a 64-bit OS :O</p>
15:36 < jrandom> iirc the amd64 was built to work on pure64 debian</p>
15:37 <+Complication> Either way, some people suggested that importing a fresher gmp might help</p>
15:37 < bar> just a stab in the dark, i'm no wiz at these things</p>
15:37 < jrandom> eh, we use 4.1.4</p>
15:37 <+Complication> Especially after they've done their soon-to-come version jump</p>
15:38 <+Complication> Since I'm no gmp specialist, I couldn't tell much about it</p>
15:38 < jrandom> (and the upcoming optimizations in gmp aren't likely to have substantial improvement)</p>
15:38 <+Complication> Aside from "perhaps indeed"</p>
15:38 < jrandom> improvements come from per-arch builds</p>
15:40 <+Complication> In my test, provoked by their test, however the 64-bit athlon lib on a 64-bit Sempron, on a 64-bit Mandriva, however... does seem only marginally quicker than pure Java</p>
15:40 <+Complication> (oh, and a 64-bit VM)</p>
15:41 <+Complication> (marginally being twice)</p>
15:41 < jrandom> hmm 'k</p>
15:42 <+Complication> I'll try testing on more platform combinations, and tell if I find anything which seems worth relaying</p>
15:43 < jrandom> cool, thanks</p>
15:43 < jrandom> ok, anyone have anything else for the meeting?</p>
15:46 < jrandom> if not...</p>
15:46 * jrandom winds up</p>
15:47 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

65
i2p2www/meetings/172.log Normal file
View File

@@ -0,0 +1,65 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 172{% endblock %}
{% block content %}<h3>I2P dev meeting, March 14, 2006</h3>
<div class="irclog">
15:09 <@jrandom> 0) hi</p>
15:09 <@jrandom> 1) Net status</p>
15:09 <@jrandom> 2) ???</p>
15:09 <@jrandom> 0) hi</p>
15:09 * jrandom waves</p>
15:09 <@jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-March/001270.html</p>
15:10 <@jrandom> while y'all read that massive missive, lets jump into 1) Net status</p>
15:10 <@jrandom> the net seems to still work (woot)</p>
15:12 < bar> got me a new udp connection high score yesterday, 244</p>
15:12 <@jrandom> I don't have much more to add on that front - anyone have any comments/questions/concerns?</p>
15:12 <@jrandom> ah nice</p>
15:12 <@jrandom> yeah, I'm hitting peak values too, currently 338 SSU connections</p>
15:14 * jrandom has also done some substantial i2psnark transfers, though not always at great rates</p>
15:15 <@jrandom> I've seen some interesting cyclical variations on stats.i2p regarding tunnel selection though, but that'll be seeing some changes as .0.6.1.13 rolls out</p>
15:17 <@jrandom> I've also been doing some low(er) bandwidth testing and optimization, and thats really whats currently holding up ...13. I think we'll have some good stuff down the pipe, but we'll see how it goes</p>
15:18 <@jrandom> ok, if there's nothing else on 1) Net status, lets move on over to the floor - 2) ???</p>
15:18 <@jrandom> anyone have anything they want to bring up?</p>
15:18 <+Complication> I have only record uptimes to report, and to add that build -6 is very conservative on accepting participating tunnels</p>
15:19 <+Complication> (but I mentioned that already earlier)</p>
15:19 <@jrandom> nice - its doing well with the lower peer counts still, too, right?</p>
15:19 <+Complication> Peer counts have recently risen a bit, actually</p>
15:20 <@jrandom> ah 'k</p>
15:20 <+Complication> They are now more like 50...100</p>
15:20 <+Complication> (generally more towards 50 than 100)</p>
15:20 <@jrandom> oh, so still fairly low compared to before</p>
15:20 <+Complication> The around-30 values seem to have been as low as it gets</p>
15:21 <+Complication> But generally, it's doing fine</p>
15:21 <@jrandom> great</p>
15:26 * jrandom would like to take this moment for a brief shout-out to some recent contributors supporting I2P - special thanks go out to bar, $anon, postman, and the rest of the folks up at http://www.i2p.net/halloffame!</p>
15:27 <@jrandom> contributions of code and content of course are critical, but financial support helps keep me out of the normal workforce and crunching on I2P fulltime, plus our varied infrastructure costs</p>
15:28 < bar> me blushes, but thanks :)</p>
15:28 <@cervantes> w00t</p>
15:29 <+Complication> nice :)</p>
15:31 < ripple> jrandom: pastebin.i2p...mission accomplished....</p>
15:32 <@jrandom> ripple: thanks - it looks like it behaves as desired - on OOM, it dies a fast and horrible death, which the service wrapper detects and restarts the router</p>
15:32 <@jrandom> ok, anyone have anything else for the meeting?</p>
15:34 < tmp> Yes, let's pray for the recovery of Betty.</p>
15:34 * tethra prays</p>
15:34 <@jrandom> your prayers have been answered - she's back :)</p>
15:34 < tmp> Faith based I2P.</p>
15:35 < tmp> Ok. ;)</p>
15:35 < tethra> awesome</p>
15:35 < tethra> XD</p>
15:35 < fc> tmp: is that a transport protocol or what?</p>
15:35 < tethra> anonymous prayer?</p>
15:35 <@jrandom> betty == my laptop</p>
15:35 < tethra> not even god knows who you are!</p>
15:36 <@frosk> how about the new machine that bar so awesomely donated?</p>
15:36 <+susi23> jr: you did not name it susi??? shame on you ;)</p>
15:37 <@jrandom> the new machine is currently being assembled, an x86_64 (x2) box for windows, gentoo, and perhaps fbsd</p>
15:37 <@frosk> cool</p>
15:37 <@jrandom> (once its ready, expect some photos on my blog ;)</p>
15:38 < fc> bsd! bsd! bsd! ;)</p>
15:38 <@jrandom> susi23: the new one will need a new name... ;)</p>
15:38 <@cervantes> susan!</p>
15:39 <@jrandom> ;)</p>
15:39 <@jrandom> ok, if there's nothing else for the meeting...</p>
15:39 * jrandom winds up</p>
15:39 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

122
i2p2www/meetings/173.log Normal file
View File

@@ -0,0 +1,122 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 173{% endblock %}
{% block content %}<h3>I2P dev meeting, March 21, 2006</h3>
<div class="irclog">
15:09 <@jrandom> 0) hi</p>
15:09 <@jrandom> 1) Net status</p>
15:09 <@jrandom> 2) jrobin</p>
15:09 <@jrandom> 3) biff and toopie</p>
15:09 <@jrandom> 4) new key</p>
15:09 <@jrandom> 5) ???</p>
15:09 <@jrandom> 0) hi</p>
15:09 * jrandom waves</p>
15:09 <@jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-March/001271.html</p>
15:11 <@jrandom> lets jump briefly on in to 1) Net status</p>
15:12 <@jrandom> we've been a while since a release, but things still seem fairly stable. there are some improvements coming down the pipe though, and I hope to get us a new 0.6.1.13 this week</p>
15:13 <@jrandom> anyone have any questions/comments/concerns regarding the status of the network?</p>
15:13 <+Complication> About the periodism I noticed yesterday on a freshly started node: it desynchronized itself in a few hours</p>
15:14 <@jrandom> ah cool</p>
15:14 <+Complication> Meaning, the highs and lows became a lot more random</p>
15:14 <@jrandom> I think it still may be worthwhile to jumpstart that at the beginning though</p>
15:14 <@jrandom> (for those playing at home, we're talking about the implications of the 10m rebuild period)</p>
15:15 <+Complication> Probably helps prevent tunnel failures</p>
15:15 <+Complication> I'm still observing a healthy amount of those, but haven't counted</p>
15:15 <+tethra> (thanks for the translation :)</p>
15:15 <+Complication> Aside from that, working decently here</p>
15:16 <+Complication> I think I get "as there are no inbound/outbound tunnels available" about once per 2 hours</p>
15:17 <@jrandom> hmm, on an i2phex / i2psnark / eepproxy / ircproxy / eepsite destination?</p>
15:17 <@jrandom> (its possible for clients to overload their own tunnels, which is why I ask which)</p>
15:18 <+Complication> Checking if there's a trend</p>
15:19 <+Complication> Bit of shared clients and Pycache, more of I2Phex</p>
15:20 <@jrandom> hmm ok cool, thanks</p>
15:20 <+Complication> Significantly more of I2Phex</p>
15:20 <+Complication> Might have to limit its bandwidth</p>
15:21 <+Complication> (was at default 16K)</p>
15:23 <@jrandom> ok cool, anyone have anything else for 1) Net status?</p>
15:25 <@jrandom> if not, lets shimmy on over to 2) JRobin</p>
15:26 <@jrandom> jrobin is neat. I like it. it was dirt easy to integrate, fairly small (177KB), fast, has a low memory overhead, and provides visualizations that are easy to understand</p>
15:27 <+Complication> Quite agreed :)</p>
15:29 <+Complication> Convenient graphs, with high enough resolution, help find oddities and help ask about them :)</p>
15:29 <@jrandom> if there are any rrdtool gurus out there, if you want to give the latest cvs a glance and see what we're doing and/or see if there are easier ways to accomplish these tasks, I'd love some advice</p>
15:30 <@jrandom> (rrdtool &lt;--&gt;jrobin info @ http://www.jrobin.org/api/jrobinandrrdtoolcompared.html)</p>
15:31 <@jrandom> (and, if someone wants, they could write a fairly small app to read netDb/routerInfo-*.dat, feed them into jrobin databases, and essentially run your own stats.i2p)</p>
15:32 <@jrandom> the in-console jrobin integration is different from the stats.i2p functionality though, as it summarizes *your* router, not all routers. both are useful</p>
15:34 <@jrandom> ok, if there's nothing else on 2) JRobin, lets swing on over to 3) biff and toopie</p>
15:34 <@jrandom> postman: wanna give us the rundown?</p>
15:34 < postman> aah yes</p>
15:35 < postman> years ago the mailservice had an irc bot called biff could notify you about new mails</p>
15:35 <+Complication> Postman's AI foundry ;P</p>
15:35 < postman> with the migration to a new platform biff became unusauble and i had no time to revamp it</p>
15:35 < postman> now it's back online again</p>
15:35 <@jrandom> (yay!)</p>
15:36 < postman> if you wish to monitor your mailbox over irc just /msg biff .help for a list of commands</p>
15:36 < postman> usage is straightforward</p>
15:36 < postman> question/errors/rants/flames -&gt; postman@mail.i2p</p>
15:36 < postman> 2.</p>
15:37 < postman> in order to cope with the (hopefully) increasing stream of newbies jr, cervantes and me thougt of a Q&A bot that can be asked for helkp on the usual daily topics and problems</p>
15:38 < postman> first draft is named toopie and will soon reside on #i2p (i2p-chat maybe too)</p>
15:38 < postman> it will hold a list of topics, and Q&A sorted by topics and indexed by keywords</p>
15:38 < postman> toopie can speak to the channel as well as privmsg with a user</p>
15:38 <+Complication> Sounds neat, though I've never seen one before :)</p>
15:39 < postman> we hope to fill its brain asap</p>
15:39 < postman> Complication: you can play with it in #irc2p (in private if you wish :))</p>
15:39 <@jrandom> and one of the good parts about it is that we can fill it up with messages on irc :)</p>
15:39 < postman> yes</p>
15:40 < postman> admins can add some lines straight from irc and make it a new q&a</p>
15:40 * tethra suggests an entry purely for the sake of TheJudge/closedshop to the effect of "No, predecessor attacks don't work."</p>
15:40 <+tethra> ;)</p>
15:40 < postman> hee</p>
15:41 < postman> there is still room for the way of structuring the informationm</p>
15:41 <@jrandom> (but they do. though they're not a particular program you "run" to attack someone)</p>
15:41 < postman> more to come soon</p>
15:41 * postman hand back the mike</p>
15:41 <@jrandom> word, thanks postman</p>
15:42 < ashter> postman; will toopie speak in other langages too ?</p>
15:42 < postman> ashter: not (yet)</p>
15:42 <+fox> &lt;mihi&gt; igpay atinlay? *g*</p>
15:42 < ashter> ok</p>
15:42 < postman> ashter: the infrastructure is there ( /me planned this )</p>
15:42 <@jrandom> word</p>
15:42 < postman> ashter: it will be a version 2 feature </p>
15:42 < ashter> great, really nice thank you</p>
15:44 < postman> (thejudge makes alone 50% of alle irc disconnects today)</p>
15:45 < postman> jrandom: ok next topic</p>
15:46 <@jrandom> ok cool, anyone have anything else on 3) biff and toopie?</p>
15:46 <@jrandom> if not, lets swing on by to 4) new key</p>
15:47 <@jrandom> well, there's not really anything to add to what I posted. new key, yadda yadda</p>
15:47 <@jrandom> ok, lets jump on over to 5) ???</p>
15:47 <+tethra> erm</p>
15:47 <@jrandom> anyone have anything else to bring up?</p>
15:48 <+tethra> how does biff know you are you? :/</p>
15:48 <+fox> &lt;mihi&gt; tethra: you have to register</p>
15:48 <+fox> &lt;mihi&gt; just read what is referenced in the weekly notes :)</p>
15:48 < postman> tethra: 1.) you know your mailboxes credentials, 2. you register with an identified nick@biff</p>
15:48 <+fox> &lt;mihi&gt; yes :)</p>
15:48 <+fox> &lt;mihi&gt; what is the point to have expiring keys when you could have expiring subkeys instead?</p>
15:48 <+tethra> postman: ah, ok. thanks.</p>
15:49 <@jrandom> mihi: to compartmentalize compromise.</p>
15:50 <+fox> &lt;mihi&gt; you can delete expired secret subkeys from your keyring if you wish</p>
15:51 <+fox> &lt;mihi&gt; but I guess it is much nicer to have ppl lsign your key every year :)</p>
15:51 <+fox> &lt;mihi&gt; nicer in some sadistic point of view :-&gt;</p>
15:51 < postman> jrandom: now, riddle mihi this :)</p>
15:52 <@jrandom> (assuming only the subkey could be compromised)</p>
15:54 <@jrandom> in any case, anyone have anything else to bring up for the meeting?</p>
15:54 <+fox> &lt;mihi&gt; assume someone compromised your key yesterday. now he can have played a mitm and replaced the new key.</p>
15:54 <+fox> &lt;mihi&gt; i.e. compromise one key -&gt; compromise all future keys, isn't it</p>
15:55 <+Complication> Unless the owner uses a revocation certificate</p>
15:55 <+Complication> invalidate compromised key -&gt; invalidate future ones</p>
15:55 <@jrandom> mihi: and I could revoke the compromised key and tell you not to trust new keys</p>
15:55 <@jrandom> you now have the choice whether to trust the key change or not</p>
15:56 <+fox> &lt;mihi&gt; whom to believe then? :)</p>
15:56 <@jrandom> good question. if you hear a signed revocation in the next day or two, you should discard the new key</p>
15:57 <+fox> &lt;mihi&gt; and if it was a subkey, you'd revoked the amin key and the subkey is automatically discarded :)</p>
15:57 <+fox> &lt;mihi&gt; s/amin/main/</p>
15:58 <+fox> &lt;mihi&gt; agree to disagree?</p>
15:58 <@jrandom> aye, that we can agree to ;)</p>
15:58 <@jrandom> ok, if there's nothing else for the meeting...</p>
15:58 <+fox> * mihi hands jrandom the *baf*er (after years, just like in good old times...)</p>
16:00 <@jrandom> hehe</p>
16:00 * jrandom winds up</p>
16:00 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

78
i2p2www/meetings/174.log Normal file
View File

@@ -0,0 +1,78 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 174{% endblock %}
{% block content %}<h3>I2P dev meeting, March 28, 2006</h3>
<div class="irclog">
15:08 < jrandom> 0) hi</p>
15:08 < jrandom> 1) Net status and 0.6.1.13</p>
15:08 < jrandom> 2) Use case survey</p>
15:09 < jrandom> 3) ???</p>
15:09 < jrandom> 0) hi</p>
15:09 * jrandom waves</p>
15:09 < Complication> Finally loaded, reading :)</p>
15:10 < jrandom> weekly status notes posted up at dev.i2p.net/pipermail/i2p/2006-March/001274.html</p>
15:10 <@cervantes> *** connection reset</p>
15:10 < jrandom> heh</p>
15:11 < jrandom> ok, while y'all dig into that, lets jump on in to 1) Net status</p>
15:12 < jrandom> about 2/3rds of the net has upgraded to 0.6.1.13 (thanks!), and results have been mixed</p>
15:12 < jrandom> anyone out there on low bandwidth links have any experiences they want to share? better / worse / no difference?</p>
15:13 < jrandom> or, any results from folks on dsl-class links?</p>
15:13 * jrandom has heard (and felt) some results on faster links (largely negative, unfortunately)</p>
15:14 <+Complication> Well, I wanted to say that net status is a bit flaky. :) But the net said it first. :D</p>
15:15 <+Complication> On the scale of recent disconnects, this was a very rapid recovery, though.</p>
15:16 <+Complication> Haven't had any more massive message jams, but it still loses a lease now and then</p>
15:17 <+Complication> Also, I think the last router run ended when a lease couldn't be renewed, so it concluded "Router hung!"</p>
15:18 < jrandom> ah col</p>
15:18 <+Complication> Had been ticking for 15 hours or so</p>
15:18 < jrandom> perhaps we should adjust the watchdog to stop restarting the router under those situations</p>
15:19 <+Complication> Retransmission is also the same as before (uncomfortably high, but apparently possible to live with - which in itself is good news)</p>
15:19 < jrandom> the restart used to be necessary, but recurrant tunnel failure should be recoverable</p>
15:19 < jrandom> hmm, &lt;10%, &lt;20%, &gt;20%?</p>
15:20 <+Complication> &gt; 20%</p>
15:20 <+Complication> I don't know many protocols which work tolerably when every third message goes missing</p>
15:21 <+Complication> This one works :) But it used to be around 7%</p>
15:21 < jrandom> well, thats averaged across all of the peers, so its probably quite low for most peers, but quite high for highly congested peers</p>
15:21 < jrandom> (as shown on peers.jsp)</p>
15:22 <+Complication> True, and I haven't taken a look at that side of the distribution yet</p>
15:23 <+Complication> Might need to check, if for nothing else, then to verify how it's distributed</p>
15:24 < jrandom> cool, thanks Complication </p>
15:24 < jrandom> ok, anyone have anything else on 1) Net status?</p>
15:25 < bar> Complication: may i ask what burst limit you are using? mine are set to 60% of my theoretical upload max, and i currently have a retransmission ratio of 11% </p>
15:26 <+Complication> bar: it's around 80% of line speed</p>
15:26 < bar> ok</p>
15:26 <+Complication> On the same level as it was, when retransmission was around 7%</p>
15:26 <+Complication> Had it higher meanwhile, but brought back down</p>
15:28 < bar> i'll try to use 80% for a day or so to see if anything happens</p>
15:28 <+Complication> And sustained transfer limit is around 65%</p>
15:28 <+Complication> Actual transfer, if the total indicator is correct, averages near 60% of line speed</p>
15:29 <+Complication> (peaks are higher)</p>
15:30 < ashter_> for my part lot of 'no lease' thing for local destination (as i said today)</p>
15:30 < ashter_> and a node a bit more congested</p>
15:30 <+fox> &lt;nextgens&gt; hi</p>
15:30 < jrandom> heya nextgens</p>
15:30 < jrandom> ashter_: hmm, are you on dialup, dsl/cable, or faster? or, better said (more anonymously), are you congested?</p>
15:31 <+fox> &lt;nextgens&gt; cool, jrandom is around :) you might help me :)</p>
15:31 < jrandom> (as in, network congestion, not the numbers i2p displays)</p>
15:31 < ashter_> dsl/cable</p>
15:32 < jrandom> ok thanks</p>
15:33 < jrandom> ok, if there's nothing else on 1) Net status, lets jump on over to 2) Use case survey</p>
15:34 < jrandom> I don't expect anwers immediately, but if y'all could put some thought into the questions from the mail and post up replies (either to the forum, syndie, the list, etc), it'd be much appreciated</p>
15:37 <@cervantes> *cough*</p>
15:38 <+tethra> oh dear :/</p>
15:39 < jrandom> (|grep -v -- -\!- ;)</p>
15:39 < jrandom> ok, as I said though, bounce word through whatever fashion you care to use at your convenience. gracias</p>
15:39 < jrandom> movin' on to 3) ???</p>
15:39 < jrandom> anyone have anything they want to bring up for the meeting?</p>
15:40 <@cervantes> http://forum.i2p.net/viewtopic.php?p=7442 &lt;-- sticky thread for use case discussion</p>
15:40 < jrandom> ah cool, thanks cerv</p>
15:42 < ashter> (erf that happened once again, and when this occurs participating tunnels grows insanly :( )</p>
15:43 < jrandom> hmm, to the thousands, or hundreds?</p>
15:43 < jrandom> (there are a few fixes for bursts of new tunnels pending, should be out later this week)</p>
15:43 < ashter> thousands</p>
15:44 < ashter> (ok thank you)</p>
15:44 < jrandom> ok cool. you may want to conider lowering your bandwidth limit or share percentage in the meantime</p>
15:44 < jrandom> ok, anyone have anything else for the meeting?</p>
15:45 < jrandom> if not...</p>
15:45 * jrandom winds up</p>
15:46 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

132
i2p2www/meetings/175.log Normal file
View File

@@ -0,0 +1,132 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 175{% endblock %}
{% block content %}<h3>I2P dev meeting, April 4, 2006</h3>
<div class="irclog">
16:21 < jrandom> 0) hi</p>
16:21 < jrandom> 1) Net status and 0.6.1.14</p>
16:21 < jrandom> 2) Syndie plotting</p>
16:21 < jrandom> 3) Local jbigi optimizations</p>
16:21 < jrandom> 4) ???</p>
16:21 < jrandom> 0) hi</p>
16:21 * jrandom waves</p>
16:21 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-April/001275.html</p>
16:21 * Complication reads</p>
16:22 < jrandom> while y'all read that (briefly put together) post, lets jump on in to 1) Net status</p>
16:23 <@cervantes> (forum back)</p>
16:23 < jrandom> there are a few problems out there affecting use on 0.6.1.13, and most of tem have been tracked down and solved</p>
16:24 < Complication> Over here, with the "fourth" CVS build, I noticed a change in my graphs</p>
16:24 < jrandom> here are still a few kinks getting tested and revamped though, but a release should be out in the next few days</p>
16:24 < Complication> In general, things moved towards more stability and less jumpyness</p>
16:24 < jrandom> oh bugger, I forgot to increment it to -4 didn't I?</p>
16:24 < jrandom> (ok, -5 will be out later this evening)</p>
16:24 < jrandom> cool Complication </p>
16:25 < Complication> But my perceptions could be influenced by jbigi too, as I didn't take steps to exclude that</p>
16:25 < Complication> Now, after a while, retransmission has edged down to 15% too</p>
16:28 < jrandom> hmm, i'm also seeing my average ssu rto approach the 3s ceiling as well</p>
16:28 < jrandom> (though very low retransmission still, under 5%)</p>
16:29 * Complication takes a second look at it</p>
16:29 < Complication> Let's say the raw average is a little over 1500</p>
16:29 < Complication> (over here)</p>
16:30 <+fox> &lt;BrianR___&gt; jrandom: Is there a de-facto "MTU" for i2p packets?</p>
16:30 < jrandom> ah ok, perhapsas that inches up, the retransmission rate will go down</p>
16:30 < Complication> I noticed mine start out with smaller MTUs, now it's upped some to 1350</p>
16:30 < jrandom> BrianR___: yes, either 1350 or 608 (as shown on http://localhost:7657/peers.js)</p>
16:31 < jrandom> if the failure rate is too high at the larger MTU, it falls back to the smaller MTU (and if its too low at the smaller MTU, it jumps up to the higher MTU)</p>
16:31 <+fox> &lt;BrianR___&gt; jrandom: Now is that for the inside payload or the visible IP packets?</p>
16:31 <+fox> &lt;BrianR___&gt; Ie, if I were to send a block of data over an I2P stream, what would be the ideal size for the chunks to minimize overhead?</p>
16:31 < jrandom> that is for the UDP payload</p>
16:32 < jrandom> streams are two layers up</p>
16:32 < jrandom> (there's fragmentation for tunnels, and then fragmentation at the stream/i2cp level)</p>
16:32 <+fox> &lt;BrianR___&gt; Yes... Is there an ideal size to minimize fragmentation?</p>
16:32 < jrandom> the ideal block size of an app using the streaming lib is "large", so that the streaming lib can use the appropriate size.</p>
16:33 < jrandom> (aka ignore the man behind the curtain)</p>
16:33 <+fox> &lt;BrianR___&gt; Aah.. Maybe I should think about pipelining or something then..</p>
16:34 <+fox> &lt;BrianR___&gt; I'm planning an app with lots of request/response traffic...</p>
16:34 < jrandom> i'd recommend batching then to cut down on the chattyness</p>
16:34 < Complication> Perhaps keeping traffic focused would help to some extent</p>
16:37 < jrandom> ok, anyhing else on 1) Net status, or shall e shimmy on over to 2) Syndie plotting</p>
16:38 * jrandom shimmies</p>
16:39 < jrandom> this is largely a placeholder and cfp - there's going to be some substantial revamp to syndie, both in operaion and the ui, so if you've got some key features or use cases you think need to be addressed, get in touch</p>
16:40 < jrandom> (more info will be of course forthcoming as things get fleshed out further)</p>
16:42 < jrandom> thats all i've got to say on that for the moment, so, moving on over to 3) jbigi optimizations</p>
16:42 <@frosk> and i had assumed "plotting" referred to some jrobin stuff in syndie :)</p>
16:43 < jrandom> hehe</p>
16:43 < jrandom> it'd be interesting to plot posts/day, posts/author, new authors/day, etc ;)</p>
16:44 < Complication> Oh, on bit about Syndie (sorry, only now remembered)</p>
16:44 < Complication> =one bit</p>
16:44 <@frosk> which do you want, 0 or 1? :)</p>
16:44 < Complication> Do you think it could be practical, or easy/difficult to separate favourite authors and blacklisted (spam)authors into two different lists?</p>
16:45 < Complication> On addresses.jsp</p>
16:45 < jrandom> oh, yeah without much trouble</p>
16:46 < jrandom> thats a good idea for therevamp too, but perhaps we can get that into the 0.6.1.14 build</p>
16:47 < Complication> Nah, it's not byting me, I just remembered something I noticed back then</p>
16:47 < Complication> Anyway, jbigi gets faster on Linux/AMD64 when you compile locally and use GMP 4.2</p>
16:48 < jrandom> cool</p>
16:48 < jrandom> did you compare that w/ -O3 -m64 on GMP 4.1.2?</p>
16:48 < Complication> And I'm a damn fool for going after way wrong compile flags :O</p>
16:48 <@cervantes> the relevant link was http://forum.i2p/viewtopic.php?t=1523&start=30 btw</p>
16:48 < jrandom> ah thanks cervantes </p>
16:48 < Complication> jrandom: I haven't compared yet, but will</p>
16:49 < Complication> During next scheduled reboot</p>
16:50 < jrandom> the jbigi build process is essentially "build GMP, then build jbigi.o, and link the two together", so any sort of optimizations people want to make on GMP can be made as the first step</p>
16:50 <@cervantes> I've not seen much difference between -O3 and -O2 in any previous tests I've done, whether that's different under x86_64 ... *shrug*</p>
16:50 < jrandom> aye, might be compiler rev dependent as well</p>
16:50 < jrandom> (especially with all these 3.3/3.4/4.0/4.1 issues)</p>
16:51 <@cervantes> just to re-iterate what I mentioned in that thread... we probably won't see windows64 optimised jbigi anytime soon</p>
16:51 <+fox> &lt;BrianR___&gt; Does the i2p stream lib do payload compression?</p>
16:52 < Complication> BrianR: yes</p>
16:52 <@cervantes> unless someone has M$ VC 2005 w/64-bit SDK and fancies some heavy toil to get it to compile gmp</p>
16:52 < Complication> At least to my knowledge</p>
16:53 <@cervantes> (there was a project to port gmp into a vc project somewhere though)</p>
16:53 < jrandom> cervantes: well, we've got one that /works/ for amd64/win, but it doesn't use the most out of the hardware ;)</p>
16:53 < jrandom> (when my new box gets here though i may be able to tweak that, as its an amd64)</p>
16:53 <+fox> &lt;BrianR___&gt; trying to figure if I should use a binary protocol to save bits or if zlib or something is going to smoosh up ascii protocol nice and small..</p>
16:54 <@cervantes> coolio - unfortunately Mingw64 or cygwin64 doesn't seem to be on the near horizon...</p>
16:54 < jrandom> BrianR___: premature optimization being the root of all evil, and all that jazz...</p>
16:55 < Complication> at least partly human readable protocols are generally easier to debug, but I guess it depends what one's doing</p>
16:56 < Complication> ('cause some things like encryption don't like being human-readable, no matter what :) )</p>
16:57 < Complication> But if I2P does the encryption, and also compresses, good chances are that many things which occur on top of it, can be done with human-readable protos</p>
16:58 < jrandom> aye</p>
16:58 < jrandom> ok, anything else on 3) jbigi stuff?</p>
16:58 < jrandom> if not, lets move to 4) ??? </p>
16:59 < jrandom> anyone have anything else for the meeting?</p>
17:01 <+tethra> i recall hearing something about anonymous collaboration tools recently</p>
17:01 <+tethra> care to elaborate on what kind, and whether they'll be syndie-esque or not?</p>
17:02 <@cervantes> irc and syndie is an anonymous collaboration tool :)</p>
17:02 < jrandom> hmm, not sure of what you refer to - or maybe you mean the actual planned syndie revamps? :)</p>
17:02 <+tethra> true.</p>
17:02 * tethra isn't sure either, which is why he asked</p>
17:02 <+tethra> there was talk of it on the forums - reasons for anonymity and stuff</p>
17:03 <+tethra> i'll find the thread so i can get the quote</p>
17:03 < jrandom> ah right</p>
17:03 <+tethra> http://forum.i2p.net/viewtopic.php?t=1618</p>
17:03 < jrandom> the use case thread</p>
17:03 <+tethra> - anonymously hosted & publicly reachable forums/boards/wikis </p>
17:03 <+tethra> yeah</p>
17:04 <+tethra> is there going to be an i2wiki type project that is based around something like syndie or is it up to users?</p>
17:04 < jrandom> there have been some good ideas in there, and some good feedback</p>
17:05 < jrandom> the ability to edit syndie posts is an oft-requested feature, and with that, you could pull off a wiki w/ a rich editor</p>
17:05 < jrandom> but, of course, nothing will exist in a vaccum - if someone believes that is necessary, someone should say "hey, a wiki is essential, and here's why"</p>
17:06 < jrandom> there are an infinite number of apps that /can/ be built, but as we're aiming for strong anonymity and strong security, care must be taken in what is built</p>
17:07 <+tethra> right</p>
17:07 <+tethra> that said, some of the more difficult things to keep anonymous and secure might be better off being done by someone who is good at keeping things anonymous and secure, right?</p>
17:08 < jrandom> likely so, though there is no cabal - anyone can learn</p>
17:08 <+tethra> (key things, basically. not that i'm naming any, but hey.)</p>
17:08 <+tethra> true</p>
17:09 <+tethra> but learning at the cost of your own and other people's anonymity isn't the greatest way of doing it</p>
17:10 < jrandom> everyone has to start somewhere, of course</p>
17:10 <+tethra> (perhaps if someone made a sandbox type thing that allowed people to run $software and have people attack it and stuff that'd be good for someone who is new/inexperienced?)</p>
17:10 <+tethra> yeah</p>
17:14 < jrandom> ok, anyone else have anything for the meeting?</p>
17:15 < jrandom> if not</p>
17:15 * jrandom winds up</p>
17:15 <@cervantes> *ahem*</p>
17:15 * jrandom pauses</p>
17:16 < jrandom> whats shakin' cerv? </p>
17:16 < Complication> Neat, I found a baf ;P</p>
17:17 < jrandom> baf-blocked ;)</p>
17:17 <@cervantes> hups srry, continue baffing</p>
17:17 * jrandom resumes winding</p>
17:18 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

180
i2p2www/meetings/176.log Normal file
View File

@@ -0,0 +1,180 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 176{% endblock %}
{% block content %}<h3>I2P dev meeting, April 18, 2005</h3>
<div class="irclog">
16:09 < jrandom> 0) hi</p>
16:09 < jrandom> 1) Net status and 0.6.1.16</p>
16:09 < jrandom> 2) Tunnel creation and congestion</p>
16:10 < jrandom> 3) Feedspace</p>
16:10 < jrandom> 4) ???</p>
16:10 < jrandom> 0) hi</p>
16:10 * jrandom waves</p>
16:10 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-April/001281.html</p>
16:10 * frosk too</p>
16:10 < jrandom> (almost two hours *before* the meeting, too :)</p>
16:11 < jrandom> ok, since i'm sure y'all've already poured over the notes, lets jump into 1) Net status</p>
16:12 <+Complication> Hi :)</p>
16:12 * Complication quickly grabs the notes</p>
16:12 < jrandom> the 0.6.1.16 release fixed a very long standing but in our prng, which had caused a substantial number of arbitrary tunnel rejections</p>
16:13 < jrandom> (the root cause was injected last october, but is fixed now)</p>
16:13 <+Complication> Status over here: works tolerably with 1 + 0..1 hop tunnels, won't behave with 2 + 0..1 or 2 +/- 0..1</p>
16:14 < jrandom> aye, thats understandable too, especially under slower links</p>
16:14 < jrandom> (unfortunately, "slower" isn't all that slow, either)</p>
16:15 < jrandom> there is still much work to do, and 0.6.1.16 isn't where we need to be, but its progress</p>
16:17 <+Complication> Something I've been thinking of, with regard to what you called "congestion collapse"</p>
16:18 <+Complication> One way to limit its impact might be to actually *require* a router to accept a certain quota of participation requests</p>
16:19 <+Complication> (something specified by the user either directly or indirectly?)</p>
16:19 < jrandom> specified by which user?</p>
16:19 <+Complication> (e.g. some part of share percentage or an additional parameter)</p>
16:19 < jrandom> the local user, or by us as remote users?</p>
16:19 <+Complication> Specified by everyone for themselves</p>
16:19 <@frosk> should we move over to 2) then? :)</p>
16:20 < jrandom> aye, might as well consider us on 2) :)</p>
16:20 <+Complication> So that I could, for example, tell my router "even if you're congested, keep routing a minimum of 4 KB/s"</p>
16:21 < jrandom> Complication: thats not really possible - if a router is too congested, other people will (hopefully ;) stop asking them to participate in tunnels.</p>
16:21 <+Complication> (this would, of course, mean that some local destination could be offline a while longer)</p>
16:21 < jrandom> and if they aren't asked, they /cant/ push other people's data</p>
16:22 <+Complication> Ah, perhaps I should have phrased it significantly clearer</p>
16:24 <+Complication> I imagined it could, under a certain quota of participating traffic, throttle its own tunnel creation messages instead of participating tunnels</p>
16:24 <+Complication> e.g. "I'll never throttle my participating tunnels to less than 4 KB/s. If that would be needed, I'll instead throttle my own traffic."</p>
16:26 < jrandom> hmm, there are anonymity risks in that (though still along the same lines of selective DoS, which we don't defend against anyway)</p>
16:27 < jrandom> but throttling our own local tunnel builds in face of congestion is something i've got in testing now - adding support tooptionally ignore the 4KBps floor should be simple enough</p>
16:28 < spinky> Currently, you get no cover traffic at all when transferring lots of data.</p>
16:29 < spinky> Having a floor for participation bw sounds good.</p>
16:30 < jrandom> well, we do have a floor (both as the share percentage and an internal 4KBps reserved after all bw is assigned)</p>
16:30 <+Complication> Bah, disconnects... I hope much wasn't lost of what I said, but any replies I'll have to read from the log :)</p>
16:32 <@frosk> is there anything significant about 4KBps?</p>
16:33 < jrandom> a few things - 4KB ~= sizeof(tunnel create message), and heuristically, i've never heard of a router running uccessfully on less</p>
16:33 < spinky> Maybe it's the bugs that keep the share percentage from working then?</p>
16:34 < jrandom> what makes you say the share percentage doesn't work?</p>
16:34 <@frosk> i see</p>
16:34 <+Complication> frosk: nah, it's just a number in the current code, and I referred to it while trying to explain what I imagined too</p>
16:35 <+Complication> (not because of meaningful reasons, just because what I imagined was, in a certain sense, its equal opposite)</p>
16:35 < spinky> It's set to 80% and participation goes to 0 when locally generating data. Perhaps I'm misunderstanding things.</p>
16:36 < jrandom> ah, yes, thats not what the share percentage does</p>
16:36 <+Complication> spinky: it's a maximum limit of what may be shared, subject to bandwidth actually available for sharing</p>
16:37 <+Complication> If local traffic takes up 70%, you've only got 10% left for sharing</p>
16:37 <+Complication> If local traffic is heavy, you'll have 0% left, and the top limit of 80% will never be touched</p>
16:37 < spinky> Ok. I see it says 'up to'...</p>
16:38 <+Complication> And also, there's the 4 KB/s reserve</p>
16:38 < jrandom> ah, its share percentage of what you have available</p>
16:38 < spinky> Maybe another setting for the floor participation bw, under which the router will accept more tunnels?</p>
16:38 < jrandom> if you are using 95% of your bw, it will share up to 80% of the remaining 5%</p>
16:39 <+Complication> Oh, then I've partly misunderstood it too</p>
16:40 < fox> &lt;zorglu1&gt; how i2p measure the amount of bw used by other local applications ?</p>
16:40 < spinky> (Just saying, if you consider cover traffic a good thing maybe having it configurable even under heavy local bw usage is a good thing)</p>
16:40 <+Complication> I thought it was applied against the sustained limit</p>
16:40 < jrandom> zorglu1: it measures i2p's bw usage, and knows i2p's bw limits</p>
16:41 < jrandom> oh, hmm, looking back at the code, int availBps = (int)(((maxKBps*1024)*share) - used);</p>
16:41 < jrandom> so you're right Complication </p>
16:42 < jrandom> spinky: cover traffic is only so useful on a low latency mixnet</p>
16:42 < jrandom> it does add some incentive for higher bw routers, but those w/out bw to spare have little recourse</p>
16:49 < jrandom> anyway, the tunnel congestion issue has been around for a while, but only recently exacerbated by the insane tunnel rejection rates</p>
16:49 < jrandom> hopefully the next rev will clear it up for us</p>
16:49 < jrandom> ok, anyone have anything else on 2) tunnel creation and congestion?</p>
16:50 <@frosk> sounds like it would take some changes to the tunnel-building scheme</p>
16:50 <+Complication> I hope it will help improve things :)</p>
16:51 <+Complication> Oh, by the way...</p>
16:52 < jrandom> well, we've got some cheap fixes, such as reducing the max concurrency, throttling our build attempts when congested, reducing the drop frequency (as opposed to explicit rejection), and adjusting the profiling to incentivize explicit rejections as opposed to drops</p>
16:52 <+Complication> ...did you perchance find anything which could explain the big disparity between raw bandwidth indicators and tunnel payload indicators?</p>
16:52 <+Complication> (e.g. total banwidth 1 GB, tunnel payload summed up 300 MB)</p>
16:52 < jrandom> but its true, those only affect the magnitude</p>
16:52 <+Complication> (since I haven't been around IRC lately, I'm not sure if you've been looking at that one recently)</p>
16:54 < jrandom> havent dug into that much, but remember, tunnel build requests for outbound tunnels aren't tunnel messages (and there are lots of them if only .1% are successful. and at 4KB each...)</p>
16:54 * Complication isn't certain if it's the indicators, or a real effect</p>
16:55 <+Complication> Oh... outbound build requests... indeed</p>
16:55 < jrandom> the upcoming -1 build adds a slew of stats for monitoring per-message-type packet monitoring</p>
16:55 <+Complication> That could be precisely it</p>
16:55 < jrandom> (also included in those outbound build requests are build participationg requests - forwarding a reply)</p>
16:56 < jrandom> ((so its not just local stuff))</p>
17:00 <+Complication> &gt; Thanks, that explains it a whole lot :)</p>
17:00 <+Complication> &gt; It ain't voodoo then, but quite real traffic, which I just forgot, since it wasn't specifically counted in the places I checked</p>
17:00 <+Complication> It would indeed have to occur, and would indeed cost a lot of bytes</p>
17:00 <+Complication> Especially with low success rates</p>
17:01 < jrandom> aye, though i shouldn't cost as much as it does, since we should have higher success rates than we do :)</p>
17:01 < jrandom> ok, anything else on 2)?</p>
17:02 < jrandom> if not, lets swing on over to 3) Feedspace</p>
17:02 < jrandom> frosk: wanna give us an update?</p>
17:03 < jrandom> (or tell us to fsck off and read the eepsite? ;)</p>
17:04 <@frosk> well, for those who haven't paid attention to frosk.i2p or feedspace.i2p, feedspace is now basically working (for my own defintion of "basically)</p>
17:04 < jrandom> (w00t)</p>
17:05 <@frosk> there's been some nice additions lately, like infrastructural support for transports other than i2p (tor and non-anonymous tcp/ip comes to mind)</p>
17:06 <@frosk> so in time, we plan to allow syndie (in an upcoming and probably very nice rewrite) to use feedspace as one of its syndication methods</p>
17:06 <@frosk> for now, there aren't any client apps to actually *use* feedspace for anything :) i've been testing with an extremely crude servlet app</p>
17:07 < jrandom> (crude + functional)++</p>
17:07 <@frosk> so there is of course a job opening for a client hacker ;)</p>
17:08 <@frosk> there are still some necessary stuff that feedspace needs before any public testing, but it shouldn't be long now :)</p>
17:08 < jrandom> nice1</p>
17:08 < jrandom> anything we can do to help?</p>
17:08 <@frosk> also i've been working a bit on documentation, which has been lacking</p>
17:09 < spinky> Do you see feedspace being usable for large files?</p>
17:10 <@frosk> 1) client apps using the (still undocumented) xmlrpc api, 2) http://feedspace.i2p/wiki/Tasks, 3) participate in testing when that time comes</p>
17:10 <@frosk> large files support is not a priority for now, but perhaps later</p>
17:10 <@frosk> focus for "1.0" is smaller messages such as blog and discussion entries, and events of any sort</p>
17:11 < jrandom> though feeding .torrent files into an rss/feedspace-enabled bt client wouldn't be a problem</p>
17:11 <@frosk> large files may or may not work :)</p>
17:11 <@frosk> that would be a superneat thing</p>
17:12 < jrandom> feed2snark ;)</p>
17:12 <@frosk> i hope we'll see all sorts of such "adapter" apps :)</p>
17:12 <+Complication> Well, I'm sure people will find ways to move large files using bit... umm, side channels :)</p>
17:15 <@frosk> i feel a bit guilty about the feedspace code using all sorts of java1.5 features. it would probably be hard to compile/use on free java right now, but it will catch up i'm sure :)</p>
17:15 < jrandom> yikes</p>
17:16 < jrandom> well, there are rumors of gcj adopting ecj for 1.5-isms</p>
17:16 < spinky> Complication: Ponies with saddle bags full of hdds?</p>
17:16 <@frosk> yep</p>
17:17 <+Complication> spinky: drones, in my preferred case :P</p>
17:17 * jrandom is still barely moving up to 1.4-isms</p>
17:17 <+Complication> But I guess ponies work too :P</p>
17:17 < jrandom> though 1.6 sure is nice ;)</p>
17:17 <@frosk> to stay gcj-compatible?</p>
17:18 <@frosk> well 1.6 doesn't have a lot of "isms" for most things anyway i think :)</p>
17:18 <+Complication> (or flying hedgehogs airdropping memory cards)</p>
17:18 < jrandom> gcj/classpath/etc, but also for performance (i've found 1.5 a bit heftier than 1.4)</p>
17:19 < jrandom> true, 1.6's improvements are largely vm/bytecode specific</p>
17:19 <@frosk> hm ok</p>
17:20 * jrandom isn't trying to pursuade you not to use 1.5isms. i'm sure you've got your reasons, and e.g. azureus already requires 1.5</p>
17:21 <@frosk> well there's no going back :) hopefully it won't be too bumpy</p>
17:24 < jrandom> aye, i'm ure it'll work out fine :)</p>
17:25 < jrandom> ok cool, anyone have anything else on 3) feedspace?</p>
17:25 * frosk hugs his generics and java.util.concurrent ;)</p>
17:25 < jrandom> heheh</p>
17:27 < jrandom> ok, if there's nothing else on 3, lets move on over to 4) ???</p>
17:27 < jrandom> anyone have anything else for the meeting?</p>
17:27 <+Complication> A little question which I should have asked under 2)</p>
17:28 <+Complication> Do you know, how do idle participating tunnels typically form?</p>
17:28 <+Complication> Are they mostly a sign of failed tunnel builds, where only the creator really knows it failed?</p>
17:28 <+Complication> Or do they have additional reasons?</p>
17:28 <+Complication> (besides, of course, the obvious - namely an app sitting idle)</p>
17:29 < jrandom> an idle app wouldn't have idle tunnels (they'd be tested)</p>
17:29 < jrandom> idle tunnels are failed for some reason or another</p>
17:29 < jrandom> (either failed to be creted fully, or failed during operation)</p>
17:30 <+Complication> Right, so all tunnels are tested anyway, and tunnel testing should cause traffic... indeed</p>
17:30 <+Complication> That actually brings me to the second part of my question: would it offer any benefit to notice that a tunnel is idle, and scrap it early?</p>
17:31 <+Complication> Are there any precious resources to be saved there?</p>
17:32 < jrandom> none - a tunnel that isn't pushing data isn't using up resources</p>
17:32 < jrandom> (ok, its using up some ram, perhaps 32 bytes)</p>
17:32 <+Complication> Or perhaps, could it help a router to keep a better picture of its load and similar parameters...</p>
17:33 < jrandom> predictions on bw usage bsed on the tunnel history is certainly an open question</p>
17:33 <+Complication> Or would it just be pointless work, and it's best to wait until it expires naturally?</p>
17:33 <+Complication> (like it does now)</p>
17:34 < jrandom> we used to do some predictions, but it didn't give us clear benefits, so we're using a simpler algorithm now</p>
17:34 <+Complication> Aha, so no gain...</p>
17:34 <+Complication> Thanks, that was basically all I wanted to ask about it :)</p>
17:34 < jrandom> np, understandable concern</p>
17:34 < jrandom> ok, anyone have anything else for the meeting?</p>
17:35 <+Complication> Yeah, if one did predictions, the percentage of idling tunnels might tilt estimates</p>
17:35 <+Complication> (if it varied significantly)</p>
17:36 < jrandom> aye, we'd want to keep idle % as part of the estimate</p>
17:36 < jrandom> (we used to - see the RouterThrottleImpl.allowTunnel method)</p>
17:37 <+Complication> Oh, didn't know that :)</p>
17:37 < jrandom> and note the new comment:</p>
17:38 < jrandom> // ok, ignore any predictions of 'bytesAllocated', since that makes poorly</p>
17:38 < jrandom> // grounded conclusions about future use (or even the bursty use). Instead,</p>
17:38 < jrandom> // simply say "do we have the bw to handle a new request"?</p>
17:39 * Complication is still browsing towards the file, but thanks :)</p>
17:39 < jrandom> w3rd</p>
17:40 < jrandom> ok, if there's nothing else for the meeting...</p>
17:40 * jrandom winds up</p>
17:41 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

154
i2p2www/meetings/177.log Normal file
View File

@@ -0,0 +1,154 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 177{% endblock %}
{% block content %}<h3>I2P dev meeting, April 25, 2005</h3>
<div class="irclog">
16:12 < jrandom> 0) hi</p>
16:12 < jrandom> 1) Net status and 0.6.1.17</p>
16:12 < jrandom> 2) I2Phex</p>
16:13 < jrandom> 3) ???</p>
16:13 < jrandom> 0) hi</p>
16:13 * jrandom waves</p>
16:13 <@cervantes> 'lo</p>
16:13 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-April/001283.html</p>
16:14 < jrandom> while y'all skim that, lets jump into 1) Net status </p>
16:14 < jrandom> so, as most of y'all have seen, we've got a new release out, and so far, the results have been pretty positive</p>
16:15 <@cervantes> (yay!)</p>
16:15 < jrandom> still not where we need to be, but it pretty much sorts out the main issues we were seeing</p>
16:15 < jrandom> aye, 'tis nice to have halfway decent tunnel build rates again, at 2+ hop tunnels :)</p>
16:16 * jrandom has 50%+ success rates on another router w/ 1hop tunnels</p>
16:17 < jrandom> I think the last few changes in 0.6.1.17 should help avoid this sort of congestion collapse in the future as well</p>
16:17 < jrandom> the user-visible result though is that we'll occationally see lease expirations, but rather than compounding itself, it'll back off</p>
16:17 * cervantes sparks up azureus</p>
16:18 <+Complication> This morning, I recorded client tunnel (length 2 +/- 1) success rates near 35%</p>
16:18 <+Complication> Currently it's lower, since I tried making some modifications, and the latest of them wasn't so great :D</p>
16:18 <@cervantes> jrandom: well done tracking that down - we were beginning to look like freenet for a bit :)</p>
16:19 < jrandom> *cough* ;)</p>
16:20 <+fox> &lt;inkeystring&gt; jrandom: would you mind briefly describing the backoff mechanism? i'm working on something like that for freenet 0.7 at the moment</p>
16:21 < jrandom> inkeystring: we've had a transport layer backoff mechanism in place to cut down transmissions to a peer when the transport layer is overloaded, but that wasn't sufficient</p>
16:21 <@cervantes> *cough* did I say freenet, I meant tor</p>
16:21 <+fox> &lt;inkeystring&gt; :-)</p>
16:22 < jrandom> inkeystring: the new change was to propogate that up to a higher level so that we stopped trying to build tunnels when our comm layer was saturated</p>
16:22 < jrandom> (rather than sending more tunnel build attempts)</p>
16:22 <+fox> &lt;inkeystring&gt; thanks - does the transport layer only back off when packets are lost, or is there some way for the receiver to control the flow?</p>
16:23 * jrandom seems to recall discussing the impact of congestion *vs* routing w/ toad a few times (on irc and my old flog), though i don't recall any net-positive solution :/</p>
16:23 < jrandom> the receiver can NACK, and we've got hooks for ECN, but they haven't been necessary</p>
16:23 <+fox> &lt;inkeystring&gt; yeah the debate has resurfaced on freenet-dev :-) still no silver bullet</p>
16:24 <+fox> &lt;inkeystring&gt; cool, thanks for the information</p>
16:24 <+Complication> They're using UDP too these days, aren't they?</p>
16:24 < jrandom> currently, the highly congested peers have trouble not with per-peer throttling, but with the breadth of the peer comm</p>
16:24 <+Complication> (as the transport protocol)</p>
16:24 <+fox> &lt;inkeystring&gt; breadth = number of peers?</p>
16:24 < jrandom> yes</p>
16:25 < jrandom> with the increased tunnel success rates, peers no longer need to talk to hundreds of peers just to get a tunnel built</p>
16:25 < jrandom> so they can get by with just 20-30 peers</p>
16:25 < jrandom> (directly connected peers, that is)</p>
16:26 <+fox> &lt;inkeystring&gt; i guess that's good news for nat hole punching, keepalives etc?</p>
16:26 < jrandom> otoh, w/ 2-300 active SSU connections, a 6KBps link is going to have trouble</p>
16:26 < jrandom> aye</p>
16:26 <+fox> &lt;inkeystring&gt; Complication: yes</p>
16:27 <+fox> &lt;inkeystring&gt; (in the 0.7 alpha)</p>
16:27 <+Complication> Aha, then they're likely facing some similar stuff</p>
16:27 <+Complication> I hope someone finds the magic bullet :D</p>
16:27 < jrandom> in a different way though. the transport layer is a relatively easy issue</p>
16:27 <+fox> &lt;inkeystring&gt; i think they might have reused some of the SSU code... or at least they talked about it</p>
16:27 < jrandom> (aka well studied for 30+ years)</p>
16:28 < jrandom> but i2p (and freenet) load balancing works at a higher level than point to point links, and has different requirements</p>
16:28 <+fox> &lt;inkeystring&gt; yeah it's the interaction with routing that's tricky</p>
16:29 < jrandom> aye, though i2p's got it easy (we don't need to find specific peers with the data in question, just anyone with capacity to participate in our tunnels)</p>
16:30 <+fox> &lt;inkeystring&gt; so there's no efficiency loss if you avoid an overloaded peer...</p>
16:30 <+fox> &lt;inkeystring&gt; whereas in freenet, routing around an overloaded peer could increase the path length</p>
16:30 <+fox> &lt;inkeystring&gt; anyway sorry this is OT</p>
16:31 < jrandom> np, though explaining why the changes in 0.6.1.17 affect our congestion collapse was relevent :)</p>
16:31 < jrandom> ok, anyone else have anything for 1) Net status?</p>
16:32 <+Complication> Well, as actually mentioned before, while running pure .17, I observed a noticable periodism in bandwidth and active peers</p>
16:32 <+Complication> And a few other people seem to experience it too, though I've got no clue about how common it is</p>
16:33 <+Complication> I've been wondering about its primary causes, mostly from the perspective of tunnel throttling, but no solution yet</p>
16:33 <+Complication> I managed to get my own graphs to look flatter, but only at the cost of some overall deterioration</p>
16:33 <+Complication> Tried modifications like:</p>
16:34 <+Complication> &gt; _log.error("Allowed was " + allowed + ", but we were overloaded, so ended up allowing " + Math.min(allowed,1));</p>
16:34 <+Complication> (this was to avoid it totally refraining from build attempts for its own tunnels)</p>
16:35 < jrandom> ah right</p>
16:35 <+Complication> (oh, and naturally the loglevel is wacky, since I changed those for testing)</p>
16:35 < jrandom> we've got some code in there that tries to skew the periodicity a bit, but it isn't working quite right (obviously)</p>
16:36 * perv just shot his system :(</p>
16:36 <+Complication> But I tried some things like that, and tried reducing the growth factor for tunnel counts</p>
16:36 < perv> is there an undelete for reiser4?</p>
16:36 < jrandom> basically, if we just act as if tunnels expire (randomly) earlier than they actually do, it should help</p>
16:36 <+Complication> Currently reading the big "countHowManyToBuild" function in TunnelPool.java :D</p>
16:36 <+Complication> But I've not read it through yet</p>
16:37 < jrandom> (though it'd obviously increase the tunnel build frequency, which prior to 0.6.1.17, wouldn't have been reasonable)</p>
16:37 <+Complication> perv: there is something</p>
16:37 < jrandom> hmm, putting a randomization in there would be tough Complication, as we call that function quite frequently</p>
16:38 * perv considers salvaging and switching to gentoo</p>
16:38 < jrandom> what i'd recommend would be to look at randomizing the expiration time of successfully built tunnels</p>
16:38 <+Complication> perv: you're better off with reiser than ext3, certainly</p>
16:38 <+Complication> perv: but I don't know it by heart</p>
16:38 <+Complication> jrandom: true, sometimes it could overbuild this way</p>
16:38 < jrandom> (so that the existing countHowManyToBuild thinks it needs them before it actually does)</p>
16:38 <+Complication> (and sometimes it inevitably overbuilds, when tunnels break and it gets hasty)</p>
16:40 <+Complication> Hmm, a possibility I've not considered...</p>
16:41 <+Complication> Either way, playing with it too, but no useful observations yet</p>
16:42 < jrandom> cool, i've got some tweaks i've been playing with on that, perhaps we can get those together for the next build to see how it works on the reasonably-viable net ;)</p>
16:43 < spinky> Is there a stat where you can see the amount of overhead the i2p network adds to the application data?</p>
16:43 < jrandom> "overhead" is such a loaded term... ;)</p>
16:43 < jrandom> we call it the cost of anonymity ;)</p>
16:43 < spinky> hehe</p>
16:45 < jrandom> (aka not really. application layer payload on a perfect net w/ 0 congestion & 1+1hops gets something like 70-80% efficiency for the endpoints)</p>
16:45 < jrandom> ((last i measured))</p>
16:45 < jrandom> but thats really lab conditions</p>
16:45 < jrandom> live net is much more complicated</p>
16:47 < spinky> Right, I meant just the amount of extra data used for setting up tunnels, keys, padding etc </p>
16:47 < spinky> ...compared to the application data transferred</p>
16:47 < jrandom> depends on the message framing, congestion, tunnel build success rates, etc</p>
16:48 < jrandom> a 2 hop tunnel can be built by the network bearing 20KB</p>
16:48 <+Complication> I've wanted to test that sometimes, primarily with the goal of estimating the "wastefulness" of mass transfer applications like BitTorrent and I2Phex</p>
16:48 <+Complication> But I never got around to doing a clean measurement between my two nodes</p>
16:48 <+Complication> Some day, I'll get back to that, though</p>
16:49 < jrandom> Complication: its pretty tough with chatty apps, much simpler to measure wget :)</p>
16:49 <+Complication> How very true</p>
16:50 <+Complication> In what I managed to try, no resemblance of precision was involved</p>
16:54 < jrandom> ok, if there's nothing else on 1), lets slide on over to 2) I2Phex</p>
16:55 < jrandom> Complication: whatcha upta? :)</p>
16:55 <+Complication> Well, yesterday's commit was a fix to certain problems which some people experienced with my silly first-run detector</p>
16:56 <+Complication> The first-run detector is now less silly, and bar reported that it seemed to start behaving normally</p>
16:56 <+Complication> However, since I2Phex seems runnable already in current network conditions,</p>
16:56 <+Complication> I'll try finding the rehash bug too.</p>
16:57 <+Complication> If I only can</p>
16:57 < jrandom> cool, i know that one has been haunting you for months now </p>
16:57 <+Complication> What is interesting that mainline Phex may also have it, and locating + reading their observations is something I'll try doing too</p>
16:58 < jrandom> but nice to hear the startup fix is in there</p>
16:58 < jrandom> ah word</p>
16:58 <+Complication> =is that</p>
16:58 <+Complication> I can't confirm currently if mainline Phex has it or not, though - never seen it personally there</p>
16:59 < jrandom> (intermittent bugs)--</p>
16:59 <+Complication> It's difficult to cause in controlled fashion, and thus difficult to find</p>
17:00 <+Complication> And on my side, that's about all currently</p>
17:00 <+Complication> Later on, I was wondering if it would be worthwhile to limit the number of parallel peer contacting attempts I2Phex fires at a time</p>
17:01 < jrandom> aye, likely</p>
17:01 <+Complication> Since they'd create a whole bunch of NetDB lookups in a short time, and that could be potentially not-so-nice from an I2P router's perspective</p>
17:02 < jrandom> and new destination contacts require elG instead of aes</p>
17:02 <+Complication> But I've not read or written any actual code towards that goal yet</p>
17:04 < jrandom> k np. perhaps the mythical i2phex/phex merge'll bundle a solution :)</p>
17:04 <+Complication> And on my part, that's about all the news from the I2Phex front...</p>
17:04 < jrandom> cool, thanks for the update and the effort looking into things!</p>
17:05 < jrandom> ok, lets jump on over to 3) ???</p>
17:05 < jrandom> anyone have anything else to bring up for the meeting?</p>
17:05 < lsmith> hello! i just want to commend the devs on the fantastic improvements with the latest release, my total bw reads 0.9/1.4 KBps and i remain connected to irc... it's...insanely cool :)</p>
17:05 <+Complication> :D</p>
17:06 < jrandom> thanks for your patience along the way - supporting low bw users is critical</p>
17:06 <@cervantes> lsmith: that's really good to</p>
17:06 <@cervantes> * Connection Reset</p>
17:06 < jrandom> heh</p>
17:07 < lsmith> :)</p>
17:09 < jrandom> oh, one other thing of note is that zzz is back, and with 'im comes stats.i2p :)</p>
17:09 < jrandom> [wewt]</p>
17:11 <+Complication> A quite useful source of comparison data :)</p>
17:11 < jrandom> mos' def'</p>
17:11 < jrandom> ok, anyone have anything else for the meeting?</p>
17:13 < jrandom> if not...</p>
17:13 < jdot> i have a post-baf question or two</p>
17:13 < jrandom> heh ok, then lets get the baffer rollin' :)</p>
17:13 * jrandom winds up...</p>
17:13 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

41
i2p2www/meetings/178.log Normal file
View File

@@ -0,0 +1,41 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 178{% endblock %}
{% block content %}<h3>I2P dev meeting, May 2, 2006</h3>
<div class="irclog">
16:09 < jrandom> 0) hi</p>
16:09 < jrandom> 1) Net status</p>
16:09 < jrandom> 2) Syndie status</p>
16:09 < jrandom> 3) ???</p>
16:09 < jrandom> 0) hi</p>
16:09 * jrandom waves</p>
16:10 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-May/001285.html</p>
16:11 < jrandom> ok, while y'all read through that exciting mail, lets jump on in to 1) Net status</p>
16:13 < jrandom> so far, it seems the whole congestion collapse issue is fixed, yand tunnel creation rates are doing pretty well. still, there are issues left to be sorted out</p>
16:14 < jrandom> the previously discussed cyclic behavior (often running on 10-12 minute intervals) is still in place,causing rejections inversely. there's a new fix to the code as of -1 that should get rid of that though</p>
16:15 < jrandom> (namely, randomize the tunnel expirations /correctly/, unlike the broken randomization before)</p>
16:16 < jrandom> that, plus the improved ssu and tunnel test scheduling should help, but to what dgree, i'm not entirely sure yet</p>
16:17 < jrandom> ok, thats about all i have on that at the moment. anyone have any questions/comments/concerns on 1) Net status?</p>
16:18 < green> humm, max bw limits are never reached and this is really far from previous</p>
16:18 < green> like in 1é-7</p>
16:18 < green> s/1é-7/.12-7</p>
16:18 < jrandom> how is your bw share percentage set? thats now a very powerful control</p>
16:19 < green> 80%</p>
16:19 < green> but only about 40% of total bw is used</p>
16:20 < green> this is just a "do nothing router" :P</p>
16:20 < jrandom> hmm, how often does your bw spike up to 80%, and do you often reject tunnel requests (http://localhost:7657/oldstats.jsp#tunnel.reject.30 and tunnel.reject.*)</p>
16:21 < jrandom> the periodicity seen in tunnel requests often causes people to detect overload when it isn't really there</p>
16:21 < jrandom> (because routers have excess capacity at other times, just not when they're being spiked)</p>
16:22 < green> tunnel.reject.30 is very flat like 1,00 over 14 025,00 events</p>
16:22 < jrandom> oh, sorry, its the event count theselves for that stat thats key - you've rejected more than 14,000 tunnel requests due to bandwidth overload</p>
16:23 < jrandom> (the "value" for that stat is how many tunnels were rejected at the event, and thats always 1, since an event is caused by a message)</p>
16:27 < jrandom> ok, if there's nothing else on 1) Net status, lets slide on over to 2) Syndie status</p>
16:27 < jrandom> I don't have much more to add to whats in the email regarding syndie, just wanted to give an update</p>
16:28 < jrandom> ok, as such, unless there's something someone wants to bring up wrt syndie, lets jump on to ol' faithful, 3) ???</p>
16:28 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
16:31 * tethra would like to say "thanks" (again) for .17, as it has been muchos improvement</p>
16:33 < jrandom> glad to help, and there's more stuff on the way</p>
16:33 < jrandom> ok, but if there's nothing else for toay's meeting...</p>
16:33 * jrandom winds up</p>
16:33 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

67
i2p2www/meetings/179.log Normal file
View File

@@ -0,0 +1,67 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 179{% endblock %}
{% block content %}<h3>I2P dev meeting, May 9, 2006</h3>
<div class="irclog">
16:31 < jrandom> 0) hi</p>
16:31 < jrandom> 1) Net status and 0.6.1.18</p>
16:31 < jrandom> 2) baz</p>
16:31 < jrandom> 3) ???</p>
16:31 < jrandom> 0) hi</p>
16:31 * jrandom waves</p>
16:32 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-May/001288.html</p>
16:32 < jrandom> while y'all read through that, lets jump on in to 1) Net status and 0.6.1.18</p>
16:33 < jrandom> the past week has been pretty bumpy on irc & the net in general</p>
16:33 <+Complication> Watching the graphs, but haven't noticed a perceivable change yet</p>
16:33 <+Complication> Only the beginning too, of course</p>
16:34 < jrandom> aye, its only been a few hours, with under 20% of the net upgraded</p>
16:35 < jrandom> there are still a few big guns left to deploy on the net, but I'd like things to stabilize first before pushing out major changes</p>
16:35 <+Complication> Indeed, it helps to see (as much as seeing is possible) what changes what, and in which direction</p>
16:36 <+Complication> If one deploys everything at once, figuring out what worked may be very tough</p>
16:38 < tmp> *sigh* </p>
16:38 * tmp dreams of IRC stability.</p>
16:39 < jrandom> aye, on all fronts ;)</p>
16:39 <+fox> &lt;roderick_spod1&gt; Roderick dreams of big tits.</p>
16:39 < jrandom> (this is why we can filter the meeting logs... ;)</p>
16:40 < jrandom> ok, anyone have anything else for 1) Net status and 0.6.1.18?</p>
16:41 < jrandom> if not, lets hop on over to 2) </p>
16:42 < jrandom> not much more to add here, just giving a status update on some w32/w64 support</p>
16:43 < jrandom> as mentioned in the mail, gcj doesn't really seem viable on mingw atm, though we might be able to pull some tricks</p>
16:44 < jrandom> there is an older 3.4.4/3.4.5 gcj that works on mingw, but the classpath suport in there is pretty old.</p>
16:45 < jrandom> (and even after stripping a bunch out of hsqldb, there are still some dependencies that 3.4.5 doesn't meet. but maybe we can hack those out too... if necessary)</p>
16:47 < jrandom> ok, if there's nothing else, lets move on over to 3) ???</p>
16:47 < jrandom> anyone have anything else to bring up for the meeting?</p>
16:48 < cervantes> just to say "nice one bar" for his cool donation </p>
16:48 <+Complication> Well, there was a question in the forum about uptimes presented in NetDB...</p>
16:48 * Complication seconds that</p>
16:49 <+Complication> 'bout the uptimes, if you recall, I fuzzified them slightly in March...</p>
16:49 < cervantes> must have missed that amongst the odci.gov rants</p>
16:50 < tmp> What on earth are you doing on that side roderick_spod?</p>
16:50 < jrandom> aye Complication </p>
16:50 <+Complication> Well, since the question was raised, I wondered if they could be fuzzified further, or would it hurt ability to debug?</p>
16:52 < jrandom> i'm not sure of the point - with careful analysis, all of the stat data can reveal a bunch of information</p>
16:52 < arse> do you guys think the network periodicity is gonna subside</p>
16:52 < jrandom> when its time, we will just turn off the stat publhshing whatsoever</p>
16:52 <+Complication> We haven't recently had any router-restarting ones, but that's only recently...</p>
16:52 < jrandom> arse: yes</p>
16:52 <+Complication> (and partly because the watchdog lacks teeth)</p>
16:54 <+Complication> True, it's pretty inevitable that during this phase, some info must be out there</p>
16:55 < jrandom> also, the assumption they've made isn't correct, publishedTimeAgo is how long ago the router /received/ the netDb entry, not when it was signed</p>
16:55 < jrandom> erm, wait, no, thats not true</p>
16:56 < jrandom> never mind me. yeah, it just adds a small variation</p>
16:56 <+Complication> Heh, I'm trying to post a reply, but get "no post mode specified" currently</p>
16:57 <+Complication> Yeah, there's delay involved, and besides, how often was this info published? Not very frequently, IIRC?</p>
16:57 <+Complication> Basically, if I offered to somewhat decrease the precision there, would you mind?</p>
16:58 < jrandom> a new signed entry is published eery 5-15 minutes, but that is only published to the netDb, not all peers</p>
16:58 < jrandom> peers only get the updated one when they either search for it or they reconnect</p>
16:59 < jrandom> but yeah, adding more variation is fine. it'd affect stat.i2p's uptime plots, but as long as it keeps things reasonable, thats cool</p>
17:01 <+Complication> I'll try to keep it reasonable, then :)</p>
17:01 < jrandom> heh cool, thanks Complication </p>
17:04 < jrandom> *cough* (and consistent ;) ok, anyone have anything else for the meeting?</p>
17:04 <+Complication> sidenote: neat, the "post mode" bug yielded to persistence, and I could post a reply too :)</p>
17:05 < jrandom> w3rd Complication </p>
<i>offtopic messages snipped</i></p>
17:08 < jrandom> ok, if there's nothing else...</p>
17:08 * jrandom winds up</p>
17:09 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

179
i2p2www/meetings/18.log Normal file
View File

@@ -0,0 +1,179 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 18{% endblock %}
{% block content %}
<h3>I2P (invisiblenet) Development Meeting 18</h3>
<div class="irclog">
Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
--- Log opened Tue Nov 05 23:14:03 2002
23:14 < logger> test
23:55 < nop> hineo
23:55 < Neo> hinop
23:57 < nop> hi hezekiah
--- Day changed Wed Nov 06 2002
00:00 < Neo> 23:00:00.00 UTC
00:00 < nop> ok
00:00 < nop> welcome
00:00 < nop> I kind of want to wait, looks like a relay died
00:00 < nop> just another minute
00:00 < nop> so that people can re-assimilate ;)
00:01 < hezekiah> Yeah. I got bumped out about 30 seconds ago.
00:01 < nop> right
00:01 < nop> ok
00:01 < nop> ok
00:01 < nop> welcome to the n-th iip-dev meeting
00:02 < hezekiah> 18th!
00:02 < nop> I think it's like the 18th
00:02 < nop> yes
00:02 < nop> thnx
00:02 < nop> on the agenda
00:02 < nop> 1) welcome &lt;-- we're doing this now
00:02 < nop> 2) agenda list &lt;-- we're doing this now
00:02 < nop> 3) ;)
00:03 < nop> 4) IIP logo
00:03 < nop> 5) Dev report
00:03 < nop> 6) RC3 (coming soon, we promise)
00:03 < nop> 7) questions
00:03 < nop> .
00:03 < nop> ok we did the welcome and the agenda
00:03 < nop> let's do the ;)
00:03 < nop> ;)
00:04 < nop> Ok IIP logo
00:04 < nop> and slogan
00:04 < co> Where can we see the logos that have been submitted?
00:04 < nop> none have really been submitted
00:04 < nop> except one
00:04 < nop> and I submitted a slogan for InvisibleNet
00:04 < nop> I'll tell you mine
00:05 < nop> front part of shirt "You can't attack what you can't see..."
00:05 < nop> then back would say
00:05 < nop> InvisibleNet
00:05 < nop> then there's this other one, I'll mail to iip-dev
00:05 < nop> but no one else seems to care
00:05 < nop> so... :(
00:06 < nop> then again
00:06 < nop> no one seems to want to buy shirts for IIP anyway
00:06 < nop> so... what can ya do
00:06 < nop> yes we're working on getting black shirts
00:06 < nop> next on the agenda
00:06 < nop> Dev report
00:07 < nop> same ol' same ol' dev is working on the core control
00:08 < nop> userx will give a brief summary
00:08 < hezekiah> *applause*
00:09 < UserX> core control will provide a system for being able to support multiple cores in iip. each core is esssentially network protocol
00:10 < UserX> .
00:10 < nop> ok
00:10 < nop> thank you UserX
00:10 < nop> man of many words
00:10 < nop> ;)
00:10 < nop> or woman
00:10 < nop> never know
00:10 < nop> anyway
00:10 < nop> RC3
00:11 < nop> it's on it's way out the door, I believe there is an openbsd compatibility that was reported and from what I know, it's been patched and cvs'd
00:11 < nop> (for some reason, I haven't got a listserv about it)
00:11 < nop> but we're hoping that this weekend would be a good time to do an RC3 upgrade
00:11 < nop> and it's not going to conflict with rc2 in any way
00:12 < nop> just mostly bug fixes
00:12 < nop> Questions
00:12 < nop> anyone?
00:12 < codeshark> so everything is in cvs now?
00:12 < dj28> yea
00:12 < dj28> i have a stupid one
00:12 < dj28> when will the IIP core server migrate away from the irc protocol?
00:12 < nop> codeshark - I believe so, please check with UserX to make sure he's comfortable with it
00:13 < nop> this is what the core control dev work puts us in a position to do
00:13 < dj28> and when will it become completely distributed?
00:13 < dj28> oh ok
00:13 < nop> so then we'll be able to build upon that
00:13 < UserX> codeshark: it will be once my server is talking to the internet again
00:13 < nop> and we hope to have 1.2 a fully distributed version
00:13 < dj28> ok. cool
00:13 < nop> at least at communication level
00:13 < nop> the routing might still be run through inform
00:14 < nop> but the communication should be decentralized
00:14 < nop> similar to how freenet 0.3 was
00:14 < dj28> yea
00:14 < nop> any other questions?
00:15 < co> So a core is a package of encryption algorithms that allow network communication?
00:15 < co> Explain that concept again, please.
00:15 < Mak> wow ...i jumped here ...sorry ...
00:16 < nop> well
00:16 < nop> a core is a network protocol
00:16 < nop> this puts us in a modular position
00:16 < nop> to possibly support many routing architectures
00:16 < Neo> oooh nice...
00:17 < nop> this could position us to support many protocols
00:18 < nop> the core control is similar to an API for cores
00:19 < nop> any more questions?
00:19 < co> Thank you.
00:19 < nop> np
00:21 < nop> oh
00:21 < nop> one more thing
00:22 < nop> Many thanks to Phiberoptika for her fine translation of the El Pais newspaper article done on IIP
00:22 < nop> it appears in spanish and with english translation (done by Phiberoptika) on the iip site www.invisiblenet.net/iip
00:22 < nop> it's a good article
00:22 < hezekiah> Cool! I'll have to check that out! Thanks, Phiberoptika! :)
00:22 < al-jabr> I have a question...
00:22 < nop> yes sir
00:22 < al-jabr> Two questions
00:22 < nop> sure
00:22 < al-jabr> I had one problem
00:23 < al-jabr> running IIP in linux, don't know if it's actually an IIP problem
00:23 < al-jabr> after I killed isproxy
00:23 < al-jabr> and tried to run again, it couldn't bind to the port
00:23 < al-jabr> had this problem a couple times, had to change the port number
00:23 < al-jabr> but when i logged of and on again (a few days later) the port was available
00:24 < al-jabr> so I'm not sure that's directly an issue with isproxy
00:24 < hezekiah> Is this reproducable, or just a random happening?
00:24 < nop> right, if you wait like 1 minute with RC2 you can rebind
00:24 < UserX> was something connected to it when you killed it?
00:24 < al-jabr> i'll try to reproduce it
00:24 < al-jabr> but
00:24 < al-jabr> no, nothing was connected to 6667
00:25 < nop> oh that port
00:25 < nop> hmm
00:25 < al-jabr> and it happened like three or four times and i had to keep changing ports
00:25 < al-jabr> yeah
00:25 < al-jabr> not the other one
00:25 < Phiberoptika> re:article: ;)!!!, no problem chicos..
00:25 < al-jabr> i haven't reproduced it since then, but i haven't been trying
00:25 < nop> hehe
00:25 < al-jabr> since i rarely go restarted isproxy
00:26 < al-jabr> i should probably try to. also, i was experiencing a lot of problems with the network for the last few days
00:26 < Povert> I have a question....
00:26 < al-jabr> and i don't know if it's something local
00:26 < UserX> odd. the only reason i know for that to happen is that if the connection is closed properly it will be left hanging and you have to wait for the OS to time it out
00:26 < Povert> is de openbsd thing realy solved?
00:26 < al-jabr> or if it's not really any worse than it's usually been
00:27 < al-jabr> because, before the last couple days, i got kicked off, maybe a couple times a day at MOST, then all of the sudden i was getting kicked off every few minutes, and sometimes not getting on at all, and sometimes lagging
00:27 < UserX> al-jabr: did you try using netstat to see if there were any lingering connections to port 6667
00:27 < al-jabr> and changing node.refs didn't seem to help
00:27 < al-jabr> no, i should have investigated that
00:27 < al-jabr> silly me
00:27 < al-jabr> i'll try it a bit more and i'll do that
00:28 < al-jabr> i didn't think that there could be connections on the other end after the server is killed
00:28 < nop> would netstat give a TIME_WAIT?
00:29 < hezekiah> Also, sometimes a process of isproxy hangs (but that only has happened to me when I'm debugging buggy code.) You should be able to check to see if there are still a hanging process of isproxy by doing: ps -e | grep isproxy
00:29 < al-jabr> i did that
00:29 < al-jabr> no isproxies were running
00:29 < hezekiah> Good. :)
00:30 < al-jabr> no, bad.
00:30 < al-jabr> but anyway, i'll investigate that some more, probably not a big issue
00:32 < Povert> nop
00:32 < Povert> is openbsd kompilation ready solved?
00:32 < Neo> diff -r1.2 sock.h
00:32 < Neo> 45c45
00:32 < Neo> &lt; #elif defined(__FreeBSD__) || defined(__MACH__)
00:32 < Neo> ---
00:32 < Neo> &gt; #elif defined(__FreeBSD__) || defined(__MACH__) || defined(__OpenBSD__)
00:33 < Povert> in codetree I meen
00:34 < nop> it's about to be committed
00:34 < Povert> ok
00:34 < Povert> dank
00:34 < nop> yep
00:37 < nop> any more questions?
00:42 < nop> thanks for attending
00:42 < nop> .
</div>
{% endblock %}

83
i2p2www/meetings/180.log Normal file
View File

@@ -0,0 +1,83 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 180{% endblock %}
{% block content %}<h3>I2P dev meeting, May 16, 2006</h3>
<div class="irclog">
< cervantes> moo: http://dev.i2p.net/pipermail/i2p/2006-May/001289.html
< cervantes> 0) hi
< cervantes> 1) jrandom's not here
< cervantes> 2) ???
< cervantes> 0) hi
< cervantes> hi
< cervantes> moving on to 1)
< cervantes> jrandom isn't here today, but he'll give us a status update tomorrow
< cervantes> 2) ???
< cervantes> does anyone have anything else to add to the meeting?
< bar> i have a question
< cervantes> in that case...
* cervantes winds up
* cervantes stops winding
< Complication> Aha, a question...
< bar> the PRNG fix in cvs, will that improve the general performace or is it related to something else?
< cervantes> it's uncertain what consequences it might have in general
< Complication> I'm personally not aware of its total impact, but it does involve at least two behaviours I'm aware of:
< cervantes> but it specifically fixes a symptom with i2ptunnel
* cervantes lets complication decomplicate
< Complication> tunnel length randomization and IRC server choice (more generically, random selection from a list of I2PTunnel destinations)
< Complication> Tunnel length randomization probably has a significant effect on overall network health, since it allows clients who are permitted to compromise on tunnel length to actually do that
< Complication> So they won't be holding breath and building 2-hop tunnels, but also try some 1-hop tunnels
< Complication> (which on hard times, are much easier to get)
< cervantes> also irc connectivity might improve once it's rolled out. Basically freshcoffee was never getting any client connections because it was second in the list - so with the next release the load should be evenly distributed between both servers
< bar> so the bug made people always go for the longer tunnel lengths if available?
< Complication> If I understood right, every randomization with smallish integers (e.g. pick 0 or 1) was affected
< Complication> I *think* randomizations with bigger integers (e.g. pick an integer between 0 and 100) were less affected
< Complication> if you're interested, you should probably ask jranom for details when he's back
< Complication> I may get the details wrong.
< bar> i see, thanks. good catch
< Complication> well, cervantes came here and started complaining about not getting any overload ;P
< cervantes> that was my understanding of it too
< cervantes> see...you don't get anything in life if you don't grumble :)
< cervantes> do any folk have other questions or topics for the meeting?
< fox> &lt; duck&gt; yes
< Pi> a question about general net health : i see more and more clients get left behind i2p-version wise (2 still using 0.6.1.11 and so on). won't these clients make monitoring effects of changes to the core more and more harder? (as "fewer" seem to want to update)
< fox> * duck repeats above
* w423412323 suggests a topic change along that line. ;)
< fox> &lt; duck&gt; I was wondering, I have seen some funky tuning commits on the cvs mailinglist. are those more experiments? are they based on observations? are they premature?
< Complication> Pi: as long as they aren't present in big numbers, they shouldn't make a big difference
< Pi> 70 of 300 clients using non-0.6.1.18-version according to my netdb now
< Complication> It's a game of numbers and capacity - if either most routers, or additionally the highest-capacity routers are reasonably updated, some people forgetting that they installed I2P shouldn't matter :)
< cervantes> Pi: if the older routers misbehave then the network _should_ adapt and reduce traffice being router via them
< cervantes> *being routed
< cervantes> Complication: did you see duck's question?
< Pi> and a question about a stat on the i2p-console which appeared some time ago : what does handle backlog mean?
< Complication> duck: would you mean the tunnel throttle adjustments? They're tuning in the sense that they won't bring much inherently new, but they should be fairly well-tested now (e.g. they probably won't byte)
< Complication> But they might byte a little, if you run an exotic setup which is completely outside the parameters I could think of
< fox> &lt; duck&gt; Complication: I was wondering if '2' instead of '3' thingies really mattered that much
< fox> &lt; duck&gt; but it seemed that the random problem might have been a big baddy
< fox> &lt; duck&gt; (though the relative impact of that towards network unhealth depends on when it was introduced)
< cervantes> Pi: handle backlog is the number of pending inbound tunnel join requests (quoted from the changelog)
< Complication> If you mean the random nextInteger() problem, and effect on tunnel length randomization, I feel it would have significant effect
< Complication> The cost difference of building a 1-hop and 2-hop tunnel is pretty significant
< Pi> thx, cervantes :)
< fox> &lt; duck&gt; when was it introduced?
< Complication> duck: I think it was introduced with some switchovers to the Fortuna generator, or some modification therein
< fox> &lt; duck&gt; ok; thanks a lot for your input
< Complication> Let me check the cvsweb for more detail...
< cervantes> Pi: I believe there's code in place now that drops inbound tunnel requests if the queue fills up (to help reduce cpu load)
< Complication> Pi: yes, that should be the visible indicator of another parameter used for deciding "do we have enough capacity to participate in another tunnel?"
< cervantes> duck: I certainly experience a large change in router behaviour since the fix was introduced. - not all good I have to say :)
< Complication> big handle backlog == congestion, no point in trying to join other people's tunnels
< cervantes> had a load average of 14 and 12000 participating tunnels the other day
< Complication> Handle backlog seems important particularly on high-capacity routers (referring to what cervantes saw)
< Complication> Low capacity routers generally throttle their tunnel acceptance for bandwidth reasons
< Complication> (or tunnel test time reasons, to be correct)
< Complication> (or at least, to try that)
< cervantes> wow we've managed half an hour....
< Complication> Indeed :D
< cervantes> anyone want to bring anything else to the table?
< cervantes> in that case...
* cervantes winds up
* cervantes *baffs* the meeting closed
< fox> &lt; duck&gt; thx for taking care of the meeting
< cervantes> heh I was expecting to baf it closed before anything said anything....but bar ruined that plan :)
</div>
{% endblock %}

58
i2p2www/meetings/181.log Normal file
View File

@@ -0,0 +1,58 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 181{% endblock %}
{% block content %}<h3>I2P dev meeting, May 30, 2006</h3>
<div class="irclog">
16:00 < jrandom> 0) hi</p>
16:00 < jrandom> 1) Net status</p>
16:00 < jrandom> 2) Peer filtering</p>
16:00 < jrandom> 3) Syndie status</p>
16:00 < jrandom> 4) ???</p>
16:00 < jrandom> 0) hi</p>
16:00 * jrandom waves</p>
16:01 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-May/001291.html</p>
16:01 < jrandom> (up an hour early, even [or a few weeks late, if you want to pick on me ;])</p>
16:02 < jrandom> ok, lets jump on in to 1) Net status</p>
16:02 < jrandom> things arent in the shape they should be in. they're better than they were during the congestion collapse, but it should be better than it is now</p>
16:03 < jrandom> i don't have much more to add on that though, unless anyone has any questions/concerns on 1)?</p>
16:03 <@frosk> i get days of irc connection with .19, so no complaints here</p>
16:04 < jrandom> nice</p>
16:04 < jrandom> yeah, its good for some, just not good enough or consistent enough. stats in the db aren't looking that great either</p>
16:06 < jrandom> ok, anyone have anything else on 1) Net status, or shall we move on over to 2)Peer filtering?</p>
16:07 < jrandom> [insert moving sounds here]</p>
16:09 < jrandom> as mentioned in the mail, the gist of things is to give our peer selection a bit of a boost. at first, it'll be a bit dangerous, allowing some active partitioning attacks, but if it works as I hope, we can avoid those</p>
16:10 < jrandom> (but avoiding it requires essentially killing all router identities, which would essentially serve as a network reset, so i'd like to avoid that unless its worthwhile)</p>
16:11 < bar> reset them once or repeatedly?</p>
16:11 < bar> s/reset/killing</p>
16:11 < jrandom> at least once, but also on all subsequent drastic config changes</p>
16:12 < jrandom> (aka putting some criteria into the router identity's certificate, which in turn means changing the ident hash, so they can't pretend to push one setting to some people and others to others)</p>
16:13 < bar> gotcha</p>
16:14 < jrandom> ok, i dont think i have anything else on that topic atm, unless anyone has any questions/comments/concerns?</p>
16:15 < jrandom> (hopefully there'll be a build out in the next day or two, release after it stabilizes)</p>
16:17 < jrandom> ok, hitting 3) briefly..</p>
16:18 < jrandom> syndie is coming along, and although the amd64/amd32/x86/swt/gcj battle hasn't always been pretty, we'll have a build ready in june</p>
16:19 < jrandom> (but still don't talk to me about mingw/gcj ;)</p>
16:19 < jrandom> i don't have much more to add on there at the moment though, unless anyone has any questions/concerns re: the syndie revamp?</p>
16:21 <@cervantes> how's mingw/gcj support coming along?</p>
16:21 <@cervantes> *duck*</p>
16:22 <@cervantes> do we get some screenies before the june release? :)</p>
16:23 < jrandom> i'm sure i'll try to rope some eager volunteers into pre-release testing ;)</p>
16:23 < tethrar> count me in ;)</p>
16:23 < jrandom> w3wt</p>
16:24 < jrandom> ok, lets swing over to the bullet point i know y'all have been waiting for: 4) ???</p>
16:24 < jrandom> wazaaaap?</p>
16:24 < green> Is there any plan to have to have a "real" working I2P router with Via C7 ? jbigi give only 30% better than full java</p>
16:25 < jrandom> is 30% still too cpu intensive? what makes it not "real"?</p>
16:25 < jrandom> but no, i do not have the math or c7 asm skill to make a better libGMP for C7.</p>
16:25 < green> sure too cpu intensive with 100% cpu load :P</p>
16:26 < jrandom> 100% cpu load suggests that the problem isn't jbigi, but the fact that jbigi needs to be used too much</p>
16:26 < jrandom> and for that, yes, there is lots we've got on the way.</p>
16:26 < jrandom> (e.g. reducing the connection reestablishments, improving tunnel build success rates, etc)</p>
16:27 < jrandom> ((and not getting as many tunnel requests if the router is not capable of handling them))</p>
16:29 < green> humm, this is with a dedicated box with 100Mb/s so It should be capable</p>
16:30 < jrandom> no, bandwidth is not the only resource constrained here, cpu obviously is ;)</p>
16:33 < jrandom> ok, anyone have anything else for the meeting?</p>
16:36 < jrandom> *cough*</p>
16:37 * jrandom winds up</p>
16:37 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

63
i2p2www/meetings/182.log Normal file
View File

@@ -0,0 +1,63 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 182{% endblock %}
{% block content %}<h3>I2P dev meeting, June 13, 2006</h3>
<div class="irclog">
16:05 < jrandom> 0) hi</p>
16:05 < jrandom> 1) Net status</p>
16:05 < jrandom> 2) 0.6.1.21</p>
16:05 < jrandom> 3) ???</p>
16:05 < jrandom> 0) hi</p>
16:05 * jrandom waves</p>
16:05 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-June/001293.html</p>
16:06 < jrandom> while y'all dig through that, lets jump on over to 1) Net status</p>
16:07 < jrandom> the network's behavior isn't that great at the moment - it works pretty well for some people, but for others, it doesn't work at all</p>
16:07 < modulus> .20 works pretty well for me, where .19 didn't work at all, but i guess that's just anecdote.</p>
16:08 < jrandom> you say anecdote, i say data point :)</p>
16:08 < jrandom> there'll be a new release tomorrow though which should improve things a bit</p>
16:09 < jrandom> oh, i suppose thats 2)... anyone have anything else on 1) net status they'd like to discuss first?</p>
16:10 < jrandom> if not, lets jump to 2) 0.6.1.21</p>
16:11 < jrandom> 0.6.1.20-7 is cvs head, and will become 0.6.1.21 sometime tomorrow</p>
16:12 < jrandom> it should improve the ability for fast peers to handle more tunnels, which in turn should improve everyone's success rates</p>
16:13 * jrandom currently gets ~30-60% success rates (excluding expirations) - hopefully the expirations will be cut further</p>
16:14 < jrandom> ok, I don't have much more to add on that front- the changes are listed in the history.txt, so keep an eye out tomorrow for the release</p>
16:14 < jrandom> (also, remember that it may take up to 12 hours to push the release out, so its probably best to either build -7 or wait until the actual announcement on the mailing list/website)</p>
16:15 < jrandom> ok, lets shimmy on over to 3) ???</p>
16:15 < jrandom> anyone have anything else they want to bring up?</p>
16:15 < user-land> are there recommendations for routers that can take the load from i2p ?</p>
16:15 < NickyB> yes</p>
16:15 < NickyB> about the ircproxy</p>
16:15 < user-land> and what holds up i2p 1.0 ? :-)</p>
16:16 < jrandom> user-land: to the first question, no (other than "patience")</p>
16:16 < jrandom> to the second question, see the first question</p>
16:16 < NickyB> first, sorry for my poor english. My ircProxy is set to be reachable on my lan, like all others proxy (eeproxy too) but my 6668 is reachable on the Net....</p>
16:17 < jrandom> NickyB: when you say on your lan, what is the *interface* it is bound to (on http://localhost:7657/i2ptunnel/index.jsp)</p>
16:18 < jrandom> NickyB: if the interface is "0.0.0.0", yes, it will accept connections from anywhere. if its "127.0.0.1" it will only accept connections from the localhost. if its "10.0.0.123" or "192.168.1.42", then it will accept connections from your LAN</p>
16:19 < NickyB> err, for my console, i did a change in client.config</p>
16:19 < NickyB> clientApp.0.args=7657 192.168.0.1 ./webapps/</p>
16:19 < NickyB> 192.168.0.1 is the adresse gived to all my proxy </p>
16:19 < NickyB> Reachable by:</p>
16:20 < NickyB> LAN Hosts</p>
16:20 < NickyB> 192.168.0.1</p>
16:20 < NickyB> and my 4444 is not reachable on the net, but my 6668 yes</p>
16:20 < jrandom> NickyB: you need to stop and start that particular i2ptunnel proxy for the changes to take effect</p>
16:21 < jrandom> though, perhaps we can continue debugging after the meeting (as this is all logged ;)</p>
16:21 < NickyB> will try, thank you</p>
16:21 < jrandom> np, thanks for your patience</p>
16:21 < jrandom> ok, anyone have anything else for the meeting?</p>
16:21 < fedo> why the .21 will not be a *mandatory* release ? i ask that because we have a lot of .12 .13 etc. routeurs. This may not help for the network health ...</p>
16:23 < jrandom> the old routers don't hurt much, and there arent too many of them (something like 2-300 stay within 1 release of current)</p>
16:23 < user-land> my hardware router crashed under i2p load. that is why i asked for hardware recommendations.</p>
16:24 < jrandom> ah, sorry, misundertood your question user-land. i've been able to get by with cheap linksys and belkins, though i dont know what switches they have at the current colo</p>
16:24 < user-land> thanks.</p>
16:25 < jrandom> fedo: the real key of ...21 is that 1) fast routers upgrade (and they're the most likely to anyway) and 2) that users be on ...19 or higher</p>
16:26 < fedo> ok Jr</p>
16:26 < jrandom> ok, anyone have anything else for the meeting?</p>
16:28 < user-land> thanks for your efforts :-)</p>
16:28 * ashter2 seconds user-land</p>
16:28 < user-land> and http://www.savetheinternet.com/</p>
16:29 < jrandom> (bah, never trust politics to defend us. use technology)</p>
16:29 < jrandom> ok, if there's nothin' else...</p>
16:30 * jrandom winds up</p>
16:30 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

191
i2p2www/meetings/183.log Normal file
View File

@@ -0,0 +1,191 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 183{% endblock %}
{% block content %}<h3>I2P dev meeting, August 1, 2006</h3>
<div class="irclog">
16:02 < jrandom> ok, might as well get this rolling</p>
16:03 < jrandom> hi, pre-meeting notes posted up at http://dev.i2p.net/pipermail/i2p/2006-August/001304.html</p>
16:03 < jrandom> rather than have me essentially reread that message to y'all here, lets just skip to our standard ??? section -</p>
16:04 < jrandom> anyone have anything they want to bring up and discuss?</p>
16:04 <@cervantes> eerm</p>
16:04 * cervantes scurries to read the post</p>
16:05 <+Complication> With regard to network status, all fine over here...</p>
16:05 <+Complication> But one question (actually relaying from forum) about the NTCP transport,</p>
16:06 <+Complication> namely, does it sound likely that activating it could cause someone CPU load issues (they were on XP)?</p>
16:06 <@cervantes> I have to say I've actually been seeing lower CPU usage since switching over :)</p>
16:07 < jrandom> well, you can't *deactivate* it (unless you've been reading the source code and know the magic incantation ;)</p>
16:07 <+Complication> The person who spoke of this problem (can't easily repeat it, and no big CPU use here) mentioned that their experience of high CPU usage seemed to correlate with NTCP</p>
16:07 < jrandom> so, i assume they mean not accepting inbound ntcp connections</p>
16:07 <+polecat> NTCP causes my router to instantly clock the CPU, and I repeated it twice before manually having to alter the config file to get a working router again.</p>
16:07 < jrandom> (while still using outbound ntcp connections)</p>
16:07 <+Complication> (over here it's only a tiny bit up from usual levels, and that's likely because of pumping *way* more data)</p>
16:08 <+Complication> ( http://forum.i2p/viewtopic.php?t=1815 )</p>
16:08 < jrandom> when you establish an ntcp connection, you do a heavyweight crypto calculation (or three)</p>
16:08 < jrandom> if you are accepting inbound ntcp connections, you may get lots of inbound attempts at once, since there are hundreds of i2p routers out there</p>
16:09 < jrandom> polecat: that wasn't ntcp's fault, it was the fault of a bad ntp server in the ntp pool</p>
16:09 <+polecat> Yes. So I can't handle that myself, apparantly.</p>
16:09 < jrandom> (thanks to cervantes for tracking down that ntp server and getting the pool folks to !thwap 'em :)</p>
16:10 < jrandom> ((and Complication for making it so we avoid those crazy bastards in the future :))</p>
16:10 <@cervantes> heh I think their server watchdogs only work on weekdays ;-)</p>
16:10 <+Complication> Well, the current avoidance is pretty limited</p>
16:10 <@cervantes> http://www.pool.ntp.org/scores/216.52.237.153</p>
16:11 <+Complication> I hope to get something more paranoid coded eventually</p>
16:11 <+polecat> Oh, so enabling NTCP won't clock the CPU anymore?</p>
16:11 < jrandom> (it never did polecat, 'twas a coincidence ;)</p>
16:12 <+Complication> "clock" in which particular sense?</p>
16:12 < jrandom> (see cervantes' link)</p>
16:12 * polecat clocks Complication upside the head.</p>
16:12 <@cervantes> whatcha smoking polecat</p>
16:12 <+Complication> :P</p>
16:12 <+polecat> Er, I mean, stole all clock cycles. :)</p>
16:13 <+Complication> If it jumped 30 seconds forward or backward, it could have lost many, many sessions, and resorted to all kinds of heavy, heavy crypto</p>
16:13 <+Complication> That could steal plenty of CPU cycles, I think</p>
16:13 <+Complication> Indeed, perhaps the person in the forum actually saw the same, and mis-correlated it? Have to ask...</p>
16:13 < jrandom> ah.. well, bursts of valid inbound ntcp connections will cause bursts of cpu, while outbound-only ntcp will only try to talk to so many new ntcp peers at a time</p>
16:14 < jrandom> there is nothing wrong with not enabling inbound ntcp. </p>
16:15 <@cervantes> Complication: the server was corrected mid-monday, so it might be worth seeing if they've had issues since then</p>
16:15 < jrandom> ok, anyone else have something they want to discuss?</p>
16:16 <+Complication> cervantes: indeed, could be worth a try</p>
16:16 <@cervantes> I've had reports of some folk still losing leases periodically... is that a known problem?</p>
16:16 <+void> how much does the ntcp implementation differ from ssu?</p>
16:17 <+polecat> How do we tell if we lose leases?</p>
16:18 < jrandom> void: there's a slightly higher per-message andwidth overhead in ntcp (though perhaps offset by the OS's likely-more-efficient reliable transmission implementation)</p>
16:18 <+Complication> polecat: tunnels.jsp will show no tunnels for a particular tunnel pool (e.g. "shared clients")</p>
16:18 < jrandom> cervantes: aye, our tunnel build success rates still aren't where they need to be</p>
16:18 <+void> polecat: the router console says so</p>
16:18 <+Complication> And like void says, the left sidebar of the console will tell so</p>
16:19 <+polecat> I get those "No leases" messages a lot... that's what you mean, right?</p>
16:19 <@cervantes> yup</p>
16:20 <+polecat> That's usually what kills my IRC connection. Thought it was normal!</p>
16:21 * jrandom cringes</p>
16:24 <+tethra> lol ;)</p>
16:25 < jrandom> ok, anyone have anything else for the meeting?</p>
16:25 <@cervantes> jrandom: have you made any progress on syndie lately or have you had your hands full with ntcp/bug fixing/ISP hunting/bicycling ?</p>
16:27 <+tethra> any news on feedspace, or should i just go to their eepsite?</p>
16:28 < jrandom> when the live net hit the shitter i pushed syndie to the side. but with the net moving back on track again, syndie has been reclaiming my time, and I hope to have a small cli system out shortly (with focused guis coming after that, based on user feedback)</p>
16:28 < jrandom> (the implemented swt gui is in pretty good shape, but its probably best to start off with the cli to adjust expectations)</p>
16:29 * jrandom hasn't heard any news on feedspace</p>
16:29 <@cervantes> cool</p>
16:29 < jrandom> frosk: any word? :)</p>
16:29 <+polecat> I'm glad you're working on syndie again. The new one does sound pretty promising. Any thoughts on ACL for stuff such as deleting blogs from a node, or doing administrative account-independant tasks?</p>
16:30 <@cervantes> &lt;jrandom&gt; DELETE FROM messages WHERE postedOn &lt; NOW()-14*24*60*60;</p>
16:31 < jrandom> local archives will likely remain essentially trusted (since if you can access the local archive db, you can change the file however you want)</p>
16:32 < jrandom> however, for shared blogs, yeah there's a whole set of crypto structures in place for authenticating and / or authorizing posts and changes</p>
16:33 < jrandom> (but there'll be a way for people to view 'unauthorized' posts as well, but they'll be very much off to the side)</p>
16:33 <+polecat> I'm sure once someone floods syndicates with thousands of giant blog posts, the technique to physically delete posts will be perfected.</p>
16:34 <+tethra> heheh</p>
16:35 < jrandom> physical deletion is trivial, its the question of what posts to accept in the first place ;)</p>
16:36 < jrandom> (i have no interest in making syndie into a movie distriution platform, etc)</p>
16:36 <+polecat> One cannot be sure of what one is accepting, until a sample has been accepted. I envision something like allowing only a whitelist of blogs, and allowing new IDs on a trial basis before adding them, insta-deleting on spam betrayal.</p>
16:36 < jrandom> aye</p>
16:37 <+polecat> I'm more interested in its application for colluding streams of conversation together: we could make a BBS that had no central server, just a tag in common!</p>
16:37 < jrandom> (manually allowing new ids, manually kickbanning ids that flood, etc)</p>
16:37 < jrandom> there's even inherent support for that in the crypto polecat :)</p>
16:37 <+polecat> Possibly a moderator signing approved messages for the BBS, and people collecting those approval lists from the moderator's blog.</p>
16:38 <+polecat> Ooh excellent.</p>
16:38 <@frosk> jrandom: been working on gui stuff lately, but it's been hard to combine with starting a new job :(</p>
16:39 * cervantes contacts Human Resources to get frosk fired</p>
16:40 < jrandom> ah cool, hopefully once syndie is out there pushing kludged http syndication we'll tempt you on it again ;)</p>
16:40 <@frosk> at least my boss follows i2p development now :)</p>
16:40 * jrandom waves to frosk's boss</p>
16:40 <@frosk> oh yes, i'm still determined (damn it!) :)</p>
16:40 < jrandom> (gives frosk more time off, we need 'im!)</p>
16:41 <@cervantes> hopefully he won't read about how you've been posting classified company information onto your syndie blog</p>
16:41 < bar> gui is good, we like gui. you're forgiven.</p>
16:41 <+Complication> Hehe :)</p>
16:41 <@frosk> it's weird to walk into his office and catch him reading syndie :)</p>
16:41 < jrandom> hah awesome</p>
16:42 <+polecat> Congratulations frosk, even if you get fired in shame and infamy, at least you showed one more person how cool syndie can be.</p>
16:43 <@frosk> hehe yeah</p>
16:43 <+tethra> haha</p>
16:44 <@frosk> the gui (in swt) is/will be a testbed for all things feedspace, to kickstart it</p>
16:44 < jrandom> r0x0r</p>
16:45 <+void> jrandom: perhaps you should cross-post everything that goes onto the mailing lists to syndie as well?</p>
16:45 < jrandom> we should totally merge it in with the syndie swt gui (basic paradigm is a browser, though not displaying html pages in the tabs)</p>
16:46 <+polecat> That'd be nice. I can't seem to get the mailing list anymore.</p>
16:46 < jrandom> void: it'd be pretty easy for someone to write up a small shell script to pipe procmail into the syndie CLI</p>
16:46 <@cervantes> are these fancy swt gui's tied into the applications? or are they tops for cli executables or use tcp etc etc </p>
16:46 <@frosk> that makes sense</p>
16:46 < jrandom> (iirc there's a post in my blog a while back explaining how to use the syndie cli to insert posts)</p>
16:47 <+polecat> Currently one can make RSS feeds to feed into syndie, though it's kind of cludgy still.</p>
16:47 < jrandom> cervantes: jdbc in event handlers, inline with jni and msvc callouts, of course ;)</p>
16:47 * jrandom ducks</p>
16:48 <+polecat> Microsoft Visual Classes?</p>
16:49 <@cervantes> jrandom: so anything that can talk SQL can administer syndie then</p>
16:49 < jrandom> (from syndie's perspective, all of the functionality is basically implemented in lots of tiny cli apps which just update the jdbc database, and there's an swt ui to browse around the db)</p>
16:51 <+polecat> And since the database has two interfaces, JDBC, and SQL, a client communicating in either protocol can screw with syndie.</p>
16:51 < jrandom> cervantes: well, yes and no - there's a good portion of the database thats encrypted, so not all fields are readable</p>
16:51 <+void> will the current web interface still be there?</p>
16:51 < jrandom> (jdbc == sql)</p>
16:51 < jrandom> void: no</p>
16:51 <+polecat> I thought you said that JDBC wasn't a stupid human readable protocol?</p>
16:51 <+Complication> jdbc == java database interface, perhaps a bit similar to odbc</p>
16:51 < jrandom> ((jdbc ~= sql))</p>
16:51 <+Complication> Something you talk SQL over</p>
16:52 <+void> jrandom: what will happen to syndie.i2p/syndiemedia.i2p.net?</p>
16:52 <+polecat> Oh. Well I never liked SQL anyway, for the record.</p>
16:52 <@cervantes> jrandom: so it's best to create a top for syndieTools (tm) than to try and leech the data yourself</p>
16:53 < jrandom> void: time will tell. likely they'll 1) serve as syndie's website/eepsite, 2) serve as a public archive of posts to syndicate with, and eventually, when a web interface is written, 3) serve up a web interface</p>
16:53 <+polecat> Why not submit bytecode as database queries, instead of archaic COBOL statements?</p>
16:53 < jrandom> aye cervantes</p>
16:53 < jrandom> !lart polecat</p>
16:54 <+void> hehehe</p>
16:54 <+polecat> Ah, my secret weakness.</p>
16:54 <@cervantes> * you have 6 larts left in your inventory, there is a door to the north and an unconsious polecat on the floor</p>
16:54 < jrandom> cervantes: thats actually cli app #3 (extracting individual posts, which comes after app #2, listing individual posts (after #1, creating individual posts, and after #0, managing nyms)))</p>
16:54 < jrandom> lol</p>
16:54 <+tethra> haha</p>
16:55 <+Complication> feature proposal: instead of bytecode, why not submit live $agency agents as database queries? ;P</p>
16:56 <+Complication> Would be far easier to validate for safety :P</p>
16:56 <@cervantes> jrandom: gotcha</p>
16:56 <+tethra> do they act like carrier pigeons under the right climate, Complication? </p>
16:56 <+Complication> tethra: only if you manage to push them through the TCP stack intact :P</p>
16:56 <+polecat> Yes, database queries over CPP!</p>
16:57 <+Complication> I imagine that getting wrinkled in TCP might corrupt them</p>
16:58 <+Complication> (sorry, should really keep jokes to #i2p-chat, but sometimes can't help)</p>
16:58 * cervantes senses a baff is soon approaching</p>
16:58 <+Complication> database queries as shellcode?</p>
16:59 < jrandom> ok, anyone have anything else for the meeting?</p>
16:59 <+polecat> http://www.blug.linux.no/rfc1149/ &lt;- we could tunnel i2p over this, really.</p>
16:59 * Complication would rather stick with SQL</p>
17:00 <+void> jrandom: do other langauges than java have libraries for hsqldb databases?</p>
17:01 <+Complication> Oo would seem likely to, since they seem to use it</p>
17:01 <+void> looks like a "no" to me</p>
17:01 <+void> oh, hmm</p>
17:01 <@cervantes> openoffice uses it so I would guess so</p>
17:01 <+Complication> But I'm not sure what OpenOffice is written in</p>
17:01 < jrandom> not that i know of. but someone could run syndie against another jdbc database (mysql, oracle, etc)</p>
17:01 < jrandom> oo uses java</p>
17:02 <+void> what exactly does openoffice use this database for?</p>
17:02 <+Complication> But seems to only partially use it</p>
17:02 < jrandom> void: for pdf generation and for their access-like database app</p>
17:02 < jrandom> (among other things)</p>
17:02 <+Complication> Given that it recommends an external JRE</p>
17:02 <+void> okay</p>
17:03 <+void> it's a pain in the ass to write portable sql though</p>
17:03 <+Complication> if one doesn't do triggers or stored procedures, shouldn't be a big pain, though</p>
17:04 < jrandom> eh, its not that bad, and easy to externalize</p>
17:04 <+void> especially when aiming oracle ;)</p>
17:05 < jrandom> actually, hsqldb supports pl/sql ;)</p>
17:06 < bar> are there any other plans for this database, such as for stats, peer profiles, netdb..?</p>
17:06 < jrandom> no, this is syndie only</p>
17:06 < bar> ok</p>
17:07 < jrandom> (though when we ship the hsqldb code, we can use it in i2p 'for free')</p>
17:07 <@cervantes> since syndie is not an I2P application, just an application that can run over I2P correct?</p>
17:07 < jrandom> aye cervantes, there is no dependency upon i2p</p>
17:07 <+Complication> Good to keep Syndie portable, since it might have other transports besides I2P</p>
17:07 < bar> right</p>
17:08 <+Complication> However, I take it wouldn't be difficult to run many hsqldb instances on the same machine</p>
17:08 <+Complication> So if other apps would need it, it seems they could just use it</p>
17:08 < jrandom> trivial, and 0-cost if you just use the in-jvm dataase</p>
17:08 <+Complication> (use their own instance, preferably)</p>
17:10 <+void> there's no jdbc driver for sqlite?</p>
17:11 < jrandom> dunno, never used it</p>
17:11 <+void> ah, looks like there is *something*</p>
17:13 < jrandom> ok, anything else for the meeting?</p>
17:13 < jrandom> if not...</p>
17:13 * jrandom dinws up</p>
17:13 * jrandom steps back</p>
17:13 * jrandom winds up</p>
17:13 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

268
i2p2www/meetings/184.log Normal file
View File

@@ -0,0 +1,268 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 184{% endblock %}
{% block content %}<h3>I2P dev meeting, September 12, 2006</h3>
<div class="irclog">
16:06 < jrandom> 0) hi</p>
16:06 < jrandom> 1) 0.6.1.25 and net status</p>
16:06 < jrandom> 2) I2PSnark</p>
16:06 < jrandom> 3) Syndie (what/why/when)</p>
16:06 < jrandom> 4) Syndie crypto questions</p>
16:06 < jrandom> 5) ???</p>
16:06 < jrandom> 0) hi</p>
16:06 * jrandom waves</p>
16:06 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-September/001307.html</p>
16:07 < jrandom> since those notes came up hours and hours ago, y'all should have already read them and have notes ready, right? ;)</p>
16:07 < jrandom> jumping forward to 1) 0.6.1.25 and net status</p>
16:08 < vulpine> &lt;Complication&gt; Regarding 0.6.1.25 seems to have worked fine over here, only one previously unseen error</p>
16:08 < jrandom> cool, whats the prob?</p>
16:08 < vulpine> * Complication searches logs</p>
16:09 < jrandom> the net size seems larger than before, though still same orer of magnitude</p>
16:09 < vulpine> &lt;Complication&gt; "Unknown error reading the net.i2p.data.i2np.GarlicMessage: wtf, fromLong got a negative? -840"</p>
16:10 < vulpine> &lt;Complication&gt; Started with "ERROR [NTCP read 1 ] .router.tunnel.FragmentHandler: Error receiving fragmented message (corrupt?)"</p>
16:10 < jrandom> ah ok cool, that one has been around for a long time, safe to ignore</p>
16:11 < vulpine> &lt;Complication&gt; Single occurrence</p>
16:11 < vulpine> &lt;frosk&gt; i've gotten several of that last one</p>
16:11 < vulpine> * jrandom pokes fox</p>
16:12 < vulpine> &lt;Complication&gt; Oh, and one more: "router.tunnel.TunnelDispatcher: wtf, took 1121 to dispatch net.i2p.data.i2np.TunnelBuildMessage@XXXX out YYYYY in net.i2p.router.tunnel.PumpedTunnelGateway@ZZZZ"</p>
16:12 < vulpine> &lt;Complication&gt; (seems non-significant too, maybe simple congestion)</p>
16:12 < jrandom> aye, likely </p>
16:13 < jrandom> irc is, obviously, a bit rough at the moment still</p>
16:13 < jrandom> (but, for once, its not i2p's fault :)</p>
16:14 < jrandom> ok, anyone have anything else for 1) Net status and 0.6.1.25?</p>
16:15 < kostya213> just want to add that .25 fixed all my problems i've been having the past few months</p>
16:15 < jrandom> wikked!</p>
16:16 < vulpine> &lt;green&gt; please, change status calcul when only using NTCP</p>
16:16 < jrandom> 'k, but its not recommended to disable udp (i believe i've explicitly said that i won't tell people how to disable udp too)</p>
16:17 < jrandom> but the status should be updated to take into consideration that udp is not the only transport</p>
16:17 < jrandom> i'll get that fixed in the next rev, thanks</p>
16:17 < vulpine> &lt;green&gt; jrandom : sure you don't tell, but i'm able to read code ;)</p>
16:18 < jrandom> right, though when i don't recommend something, and tell people not even to try, don't be suprised if a display message comes up confusing ;)</p>
16:19 < vulpine> &lt;green&gt; sure, i could also juste display "OK" in console :)</p>
16:19 < jrandom> true 'nuff</p>
16:21 < jrandom> ok, lets jump on over to 2) I2PSnark </p>
16:21 < jrandom> zzz doesn't seem to be over there atm</p>
16:22 < jrandom> there are some changes zzz is working on to improve the scheduling in i2psnark</p>
16:23 < jrandom> (its a bit.. simplistic atm iirc, though i'm not entirely certain of the mods zzz is hacking on)</p>
16:23 < jrandom> ((but i look forward to the progress!))</p>
16:25 < jrandom> ok, if there's nothing else on 2) I2PSnark, lets move forward to 3.*) Syndie stuff</p>
16:26 < jrandom> lets jump in to 3.1) what is syndie first, since there's so much to cover</p>
16:27 < jrandom> i got a few questions before the meeting regarding the encryption for posts</p>
16:27 < jrandom> basically, posts are *symmetrically* encrypted - anyone with the symmetric key can read the post, as they're authorized</p>
16:28 < jrandom> channel replies are asymmetrically encrypted to the public key associated with the channel/forum</p>
16:28 < jrandom> some posts can use passphrase based encryption to generate the symmetric key for reading</p>
16:29 < jrandom> and some posts can include the symmetric key in the post's readable headers (so that anyone can read it)</p>
16:29 < modulus> what's the point of that last one?</p>
16:29 < jrandom> and some forums themselves can include the symmetric key in the forum metadata, so that anyone can read the post but only if they have the channel metadata</p>
16:29 < jrandom> modulus: so that everything is always encrypted, even publicly readable stuff</p>
16:29 < jrandom> (so that trivial wiretapping is useless)</p>
16:30 < modulus> right, i see.</p>
16:31 < jrandom> ok, i think that covers the encryption questions that were asked before the meeting</p>
16:31 < jrandom> does anyone have any questions on 3.1) what is syndie?</p>
16:31 < jrandom> (I mean, more will be clarified as it is pushed out there, of course)</p>
16:32 < vulpine> &lt;void&gt; hmm</p>
16:33 < jrandom> que tal void?</p>
16:33 < vulpine> &lt;void&gt; &lt;void&gt; i guess that the message (.zip) archive can also include other messages, possibly from other people, such as the messages being quoted?</p>
16:34 < jrandom> well, yes, you can include .snd files as attachments, but there is an explicit namespace, so you can do standard References: style links to previous messages</p>
16:34 < jrandom> (aka you don't have to do frost-style "threading")</p>
16:35 < vulpine> &lt;void&gt; ok, right</p>
16:37 < vulpine> &lt;Complication&gt; About Syndie, I wondered how people would go about solving the problem of granting people access to some multiple-poster forum (like accounts on an ordinary message board) but not granting this irrevocably, and avoiding undesired mess when need to revoke access (for whatever reasons) occurs</p>
16:38 < vulpine> &lt;Complication&gt; One solution, of course, seemed for the author to specify a recommendation of whose replies clients should display</p>
16:38 < jrandom> Complication: create a new pub/private keypair, give the private key to (temporarily) authorized people, and include the public key as the list of "keys allowed to post"</p>
16:38 < vulpine> &lt;Complication&gt; ..and for clients, unless they desire to research history, to follow this recommendation (or more specifically its latest version)</p>
16:38 < jrandom> (and when they are no longer authorized, remove that key from the list of "keys allowed to post")</p>
16:39 < kostya213> jrandom: you might want to use a different extension than .snd since it's a widely used extension for audio applications, mime will confuse it</p>
16:39 < jrandom> ah, right - all forums have an "owner" (a signing private key) who can manage the list of who is allowed to post, etc</p>
16:39 < vulpine> &lt;Complication&gt; "keys allowed to post" would be metadata attached to the author's latest post, or some other message, right?</p>
16:39 < jrandom> good point kostya213, though we may be stuck with .dat then ;)</p>
16:40 < jrandom> Complication: ah sorry, no, its like the current/old syndie- separate signed metadata posts for the forum/channel itself</p>
16:40 < vulpine> * Complication believes that someone has even claimed .dat for something :)</p>
16:40 < jrandom> yes, the application called "octet-stream" ;)</p>
16:40 < vulpine> &lt;void&gt; it doesn't look like .syn is used for anything noteworthy</p>
16:41 < vulpine> &lt;Complication&gt; Aha, special metadata posts... right, that could do it</p>
16:41 < jrandom> oh neat, we get to syn!</p>
16:41 < jrandom> (good eye void, thanks kostya213)</p>
16:41 < vulpine> &lt;void&gt; hmm, "</p>
16:41 < vulpine> &lt;void&gt; hmm, "Word Synonym File", Company: Microsoft</p>
16:42 < jrandom> well, i'm sure we'll work 'er out</p>
16:42 < kostya213> yes it's used by word</p>
16:42 < vulpine> &lt;void&gt; but we might as well ignore that :)</p>
16:42 < kostya213> don't lose hope, i think it's possible to find something that won't cause problems with widely used mimetypes</p>
16:43 < jrandom> ok, anything else on 3.1) What is syndie?</p>
16:43 < vulpine> &lt;void&gt; err, then again, why would we stick with three-letter extensions? it's a relic from the DOS ages</p>
16:43 < kostya213> one thing that must be asked, why limit to a three-letter extension? nobody uses DOS anymore</p>
16:44 < jrandom> heh</p>
16:44 < kostya213> jinx on void</p>
16:44 < kostya213> .syndie seems good to me</p>
16:44 < vulpine> &lt;void&gt; .synd wouldn't conflict with any</p>
16:44 < kostya213> good as well</p>
16:45 < vulpine> &lt;void&gt; damn lag :(</p>
16:48 < jrandom> ok, lets jump on over to 3.2) Why does Syndie matter?</p>
16:48 < vulpine> &lt;void&gt; jrandom: wait</p>
16:48 < cervantes> (because you say it does)</p>
16:48 * jrandom waits</p>
16:48 < jrandom> !thwap cervantes ;)</p>
16:48 < vulpine> &lt;void&gt; the status notes post mentions that an avatar can be attached to a post, otherwise a default will be used</p>
16:49 < vulpine> &lt;void&gt; but what if a person wants to have several predefined avatars instead of a single "default" one?</p>
16:49 < jrandom> aye, the author can include a default avatar in their own channel's metadata</p>
16:49 < vulpine> &lt;void&gt; attaching the other one every time isn't going to be efficient</p>
16:49 < jrandom> good question void - lets jump to that script code in the notes</p>
16:50 < jrandom> listauthkeys --authorizedOnly true</p>
16:50 < jrandom> authenticate 0</p>
16:50 < vulpine> &lt;void&gt; (?)</p>
16:50 < jrandom> listauthkeys will display all of the identities you can sign the message saying that you are, while "authenticate 0" picks an identity to sign with</p>
16:51 < jrandom> so, that identity has its own channel, and that channel has its own metadata, which may include an avatar</p>
16:51 < vulpine> &lt;void&gt; hmm, a separate identity means a separate keypair?</p>
16:51 < jrandom> yes</p>
16:51 < vulpine> &lt;void&gt; what if a person wants to have several avatars on a single identity?</p>
16:52 < jrandom> they have a default avatar on their channel metadata, and they can override it on a per-message basis</p>
16:52 < kostya213> dubious value</p>
16:52 < vulpine> &lt;void&gt; several "default" avatars he can choose from</p>
16:52 < vulpine> &lt;void&gt; or am i splitting hair here? :)</p>
16:53 < jrandom> ah, i understand what you're saying. nah, not supported at first</p>
16:53 < jrandom> maybe later</p>
16:53 < vulpine> &lt;void&gt; true kostya213, never mind then</p>
16:53 < vulpine> &lt;void&gt; :)</p>
16:53 < jrandom> (but the avatars will be very limited in size, so shouldn't be much trouble to include)</p>
16:53 < vulpine> * Complication thinks the adding of per-message ones could be coded to be easy enough</p>
16:53 < vulpine> &lt;void&gt; so, 3.1) What is syndie?</p>
16:53 < vulpine> &lt;Complication&gt; (eventually)</p>
16:54 < vulpine> * cervantes glues the irc servers together</p>
16:54 < vulpine> &lt;void&gt; Complication: jrandom just said he is going to do that already :)</p>
16:54 < jrandom> (per message ones will be in the baseline complication, its the idea of having many 'defaults' to choose from, picking it by saying "use avatar 1" in a message rather than including the avatar itself)</p>
16:54 < vulpine> &lt;Complication&gt; latency, latency...</p>
16:54 < jrandom> ok, anything else for 3.1?</p>
16:54 < jrandom> if not, lets jump to 3.2</p>
16:55 < vulpine> &lt;void&gt; i think that's all</p>
16:55 < jrandom> wr0d.</p>
16:56 < jrandom> other than cervantes' snark, anyone have any questions/comments/concernts re "why"?</p>
16:56 < jrandom> (er, "concerns")</p>
16:58 < vulpine> &lt;Complication&gt; cervantes: did you clean the surface with alcohol before applying glue on the ircd? ;)</p>
16:58 < kostya213> imo syndie doesn't need justification, its value should be self-evident to anyone who's already interested in anonymizing networks</p>
16:58 < kostya213> and aware of the dangers of centralization of information</p>
16:59 < vulpine> &lt;Complication&gt; (repost, please ignore if reached server)</p>
16:59 < vulpine> * Complication thinks that Syndie matters because Joe Sixpack running phpBB would suffer pwnage too quickly, and Joe Sixpack running $random_blogging_tool would suffer it too</p>
16:59 < vulpine> &lt;Complication&gt; (even if probability might vary)</p>
16:59 < vulpine> &lt;void&gt; indeed</p>
16:59 < jrandom> aye, plus anyone facing actual hostile adversaries (not even necessarily state level)</p>
17:00 < jrandom> ok, cool, just wanted to run things by y'all</p>
17:00 < jrandom> anything else on 3.2, or shall we move over to 3.3) when can we use syndie?</p>
17:01 < vulpine> &lt;void&gt; well, essentially it's a forum/blogging/e-mail/communication tool based on cryptographic primitives and independent from a transport layer</p>
17:01 < vulpine> &lt;Complication&gt; ...and in the far-out scenario that Joe Sixpack's adversary would mount intersection attacks, anyone running an eepsite of any kind would suffer pwnage eventually (except in an enormous network)</p>
17:01 < kostya213> it might be a harder sell to those who don't see immediate value in privacy/anonymity</p>
17:01 < jrandom> kostya213: aye, though we may be able to pull some tricks, like being able to safely browse offline</p>
17:02 < vulpine> &lt;Complication&gt; They might appreciate security regardless</p>
17:02 < jrandom> (e.g. an offline rss reader that also pulls in the full set of pages referenced, not just the rss summary)</p>
17:02 < vulpine> &lt;void&gt; so yeah, i can't see why it needs justification :)</p>
17:02 < vulpine> &lt;void&gt; kostya213: they needn't be anonymous to use syndie</p>
17:02 < cervantes> when can we use syndie or when will syndie be useable?</p>
17:02 < jrandom> word void :)</p>
17:03 < cervantes> for the text interface I imagine there needs to be a fairly hefty amount of usage documentation</p>
17:03 < jrandom> cervantes: right now, syndie is functional (you can create posts, manage channels, read posts, reply to posts, etc)</p>
17:03 < kostya213> jrandom: how does syndie handle redundancy? how resilient is it against content disappearing?</p>
17:03 < cervantes> (before it's useable)</p>
17:03 < jrandom> cervantes: there's inline menus with each command doc'ed (at least minimaly)</p>
17:04 < cervantes> cool, any plans on some use case examples?</p>
17:04 < jrandom> kostya213: syndie works at the content layer - redundancy is handled by something else. if you post to usenet, its replicated across usenet (for instance)</p>
17:04 < cervantes> I think the trick will be learning how they all script together</p>
17:04 < vulpine> &lt;void&gt; kostya213: that's out of the scope of syndie, it's dependant on the transport mechanism</p>
17:04 < vulpine> &lt;void&gt; unfortunately</p>
17:04 < jrandom> good idea cervantes</p>
17:05 < jrandom> the first syndie release will include an http replication system like the old/existing syndie</p>
17:05 < jrandom> cervantes: perhaps some of the beta users can put together their favorite scripts for us to distribute :)</p>
17:05 < modulus> mmm, is this a console app?</p>
17:05 < jrandom> modulus: yes, the first text based app</p>
17:06 < modulus> excellent!</p>
17:06 < cervantes> jrandom: provided the beta users can work out how to use it ;-)</p>
17:06 < jrandom> hehe</p>
17:06 * jrandom considered curses/etc, as well as cli-only, but an interactive scriptable text interface is probably the simplest and most useful</p>
17:07 < jrandom> (sans gui, that is)</p>
17:07 < cervantes> modulus: see, jrandom listened to your relentless feedback :)</p>
17:07 < vulpine> &lt;Complication&gt; If people want, they can probably build more interactive textual interfaces on top of it</p>
17:07 < jrandom> aye, certainly</p>
17:08 < jrandom> (the code is built to support easy integration with an irc client, like pircbot)</p>
17:08 < modulus> cervantes: hehe</p>
17:09 < modulus> i guess you could put a gui on top of it too for that matter, if it works roughly as i imagine</p>
17:09 < modulus> although that'd be lots more work.</p>
17:09 * kostya213 waits for the emacs plugin</p>
17:09 < modulus> hahaha</p>
17:09 < jrandom> heh</p>
17:09 < modulus> actually an emacs mode isn't such a bad idea, maybe would attract more crazies to it.</p>
17:10 < cervantes> press ctrl-alt-shift-break-uparrow-num7-b to choose your identity</p>
17:10 * jrandom will leave that to elipsers to hack through ;)</p>
17:10 < kostya213> no offense, but i'm not sure this project needs to attract more crazies</p>
17:10 < vulpine> &lt;Complication&gt; would those sort of crazies code, too?</p>
17:11 < jrandom> hopefuly complication</p>
17:11 < jrandom> ok, hopefully 3.3) explains a it of whats coming down the line</p>
17:11 < jrandom> as for *when*, well, we'll see, but i'm hoping "soon" ;)</p>
17:12 < jrandom> ok, anyone have anything else for 3.3)?</p>
17:12 < vulpine> * Complication would welcome a few hordes of those crazies then :D</p>
17:12 < cervantes> well there's coding and then there's writing obfuscated perl interpreted tcl</p>
17:12 < kostya213> a plugin for FUSE might be useful too</p>
17:13 < jrandom> aye</p>
17:13 < jrandom> ok, lets jump on over to 4) crypto for syndie</p>
17:13 < jrandom> anyone have any comments on those issues?</p>
17:14 < vulpine> &lt;Complication&gt; I wish I had, but I'm not competent to estimate the strength of those ciphers/hashes/key lengths</p>
17:15 < vulpine> &lt;void&gt; how long are elgamal/rsa signatures? 4kbit for a 2kbit key?</p>
17:15 < vulpine> * Complication leaves that talk entirely for others</p>
17:15 < jrandom> dunno offhand</p>
17:15 < vulpine> &lt;void&gt; vs dsa?</p>
17:16 < jrandom> (though ecc looks nice'n'tiny)</p>
17:16 < modulus> ElGamal signatures are hard and long. as gnupg's team found out.</p>
17:16 < jrandom> aye, though some of those tricks were related to key reuse</p>
17:16 < vulpine> &lt;void&gt; ah, ok</p>
17:16 < vulpine> &lt;void&gt; yeah, it does</p>
17:16 < tethra> modulus: if they're hard and long, there's a fetish site for it</p>
17:17 < jrandom> ok, that point was really just a heads up and call for comments whenever y'all have thoughts</p>
17:17 < cervantes> could it not be possible to implement some kind of pluggable ciphers - when a better method of creating keys is standardised we can add that to syndie and new posts will begin using them, but can still use obsolete methods for older posts</p>
17:17 < tethra> (sorry)</p>
17:17 < jrandom> cervantes: it includes a DSA: prefix, so an Elg: prefix would work</p>
17:17 < modulus> are you using 1024-limited dsa or not?</p>
17:18 < modulus> also what has? sha1 or higher order revs?</p>
17:18 < cervantes> so really you are just concerned with getting syndie off to a good start</p>
17:18 < jrandom> dsa is only 1024bit (there are dsa2 proposals for longer, but they aren't standardized yet)</p>
17:18 < jrandom> and yes, dsa requires sha1</p>
17:18 < modulus> hmm, my understanding is that they were quite strong pre-standards.</p>
17:18 < kostya213> cervantes has a good point, having syndie content in fixed ciphers offers poor forward-secrecy, you never know when an algo will go titsup</p>
17:18 < modulus> but i don't follow the process closely enough so you are probably right</p>
17:19 < jrandom> kostya213: but choice is bad for crypto, so we should have fixed values when we can</p>
17:19 < jrandom> (bad because of anonymity)</p>
17:19 < vulpine> &lt;void&gt; do you know why aren't more people/protocols using ecc, anyway? are they afraid of the lack of research, or just worried about compatibility?</p>
17:19 < modulus> patents.</p>
17:20 < jrandom> patents and fud, yet some concerns in implementation</p>
17:20 < vulpine> &lt;void&gt; ah, right modulus</p>
17:20 < modulus> btw, is there are a good reason to go dsa vs rsa-sha512 for instance?</p>
17:20 < tethra> patents and fud and the state (oh my)</p>
17:20 < modulus> not trying to be annoying, just considering that gpg for instance has gone this way, among others.</p>
17:20 < jrandom> haven't reviewed that option in years modulus</p>
17:21 < modulus> obviously dsa is a standard, which speaks for it, but the keys are small and the hashes are weak. not that i think it's likely to end up being the weakest link ;-)</p>
17:23 < cervantes> I wouldn't propose "choice" - but new versions of syndie would package increasingly secure (mandatory) ciphers</p>
17:23 < vulpine> &lt;Complication&gt; Leaving some leeway in the structures for future change, seems reasonable regardless of which current crypto proves best, I'd think</p>
17:23 < jrandom> aye, though that implies the fallback to weaker/older versions to interoperate</p>
17:23 < jrandom> but, ok, we'll work through it</p>
17:24 < jrandom> ok, lets jump on over to 5) ???</p>
17:24 < jrandom> anyone have anything else to bring up for the meeting?</p>
17:25 < cervantes> no being able to read the latest posts from your favourite source is a good incentive to make sure everyone stays upgraded</p>
17:25 < jrandom> to a degree</p>
17:26 < cervantes> no=not</p>
17:26 < jrandom> (aye, its an incentive, but people are lazy/not interested in "upgrading software", etc)</p>
17:27 < jrandom> s/people/some people/</p>
17:27 < cervantes> I guess that's their issue though</p>
17:27 < jrandom> true that</p>
17:27 < kostya213> the i2p implementation at least can have painless upgrading</p>
17:28 < jrandom> certainly</p>
17:28 < cervantes> as for ??? - apologies for the irc connectivity - the ISP should be restoring one if it's major network carriers "as soon as possible"</p>
17:29 < jrandom> w3wt</p>
17:29 < vulpine> &lt;Complication&gt; To the ??? topic, I could perhaps add that the second (more extensive) part of NTP modifications is close to working, and I hope to have it committed for testing soonish</p>
17:29 * cervantes pinches salt</p>
17:29 < kostya213> what's the near-term plans for router development? is the roadmap accurate?</p>
17:29 < jrandom> wikked complication</p>
17:29 < vulpine> &lt;Complication&gt; It's goal is to second-guess NTP servers basing on peer clock skews</p>
17:29 < jrandom> kostya213: stabilization until syndie is out</p>
17:30 < jrandom> (from my perspective)</p>
17:30 < vulpine> &lt;Complication&gt; (and avoid taking potentially connectivity-damaging action)</p>
17:31 < cervantes> grand</p>
17:32 < jrandom> ok, anything else for the meeting?</p>
17:34 * jrandom winds up</p>
17:34 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

85
i2p2www/meetings/185.log Normal file
View File

@@ -0,0 +1,85 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 185{% endblock %}
{% block content %}<h3>I2P dev meeting, October 17, 2006</h3>
<div class="irclog">
16:01 < jrandom> 0) hi</p>
16:01 < jrandom> 1) Net status</p>
16:01 < jrandom> 2) Syndie dev status</p>
16:01 < jrandom> 3) ???</p>
16:01 < jrandom> 0) hi</p>
16:01 * jrandom waves</p>
16:01 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-October/001314.html</p>
16:02 <+fox> * dm waves</p>
16:02 < jrandom> w3wt, ok, while y'all read that oh-so-fun missive, lets jump on to 1) net status</p>
16:03 < jrandom> the net seems to be maintaining the steady state right now, though with a slight growth trend</p>
16:04 < jrandom> there are some discussions on the big cpu-related issue on the forum, though no big win yet, afaics</p>
16:04 < jrandom> anyone have anything to bring up re: 1) net status?</p>
16:05 < jrandom> (the last full week w/ 0.6.1.26 seems to have gone well [yay])</p>
16:06 <+fox> &lt;dm&gt; well, I better say something</p>
16:06 <+fox> &lt;dm&gt; is there a consistent metric that is being used to monitor net status</p>
16:06 <+fox> &lt;dm&gt; or is it just ad-hoc experiences?</p>
16:07 <+fox> &lt;dm&gt; like is there an application out there that tries to connect to random places every day while measuring response times and failures.</p>
16:07 < jrandom> i'm going largely by irc behavior, as well as the stats and activity on the routers i run (stats.i2p is down for a week or two, but it usually is a solid enchmark to run against)</p>
16:08 <+fox> &lt;dm&gt; cool, I'll check that site out.</p>
16:08 < jrandom> there are several people running stat monitoring apps - orion.i2p, tino.i2p, eepsites.i2p, as well as stats.i2p</p>
16:09 <+fox> &lt;dm&gt; thank you!</p>
16:09 < jrandom> np :)</p>
16:09 < jrandom> ok, if there's nothing else on 1), lets jump on over to 2) syndie dev status</p>
16:10 < jrandom> lots going on, as mentioned in the status notes (and you can finally see a non-hideous-looking website at syndie.i2p.net :)</p>
16:11 <+fox> &lt;dm&gt; down at the moment?</p>
16:11 <+fox> &lt;dm&gt; scratch that</p>
16:11 <+fox> * dm shuts up</p>
16:11 < jrandom> :)</p>
16:12 < marlowe> jrandom, the diagram on the front page is very helpful</p>
16:12 < marlowe> i know understand the concept behind syndie</p>
16:12 <+fox> &lt;dm&gt; it's pretty as well</p>
16:13 <+fox> &lt;dm&gt; but how do you access syndie without download/installing it? I remember you could do this before?</p>
16:13 < jrandom> great, glad its clear marlowe - it can be a confusing concept in just text :)</p>
16:13 < jrandom> dm: the old syndie (syndiemedia.i2p.net/) was web based, but this new one is, well, brand new, completely redesigned</p>
16:14 <+fox> &lt;dm&gt; it's not web-based?</p>
16:14 < jrandom> (and thanks to cervantes for turning my ugly ms-paint-style image into the slick pic you see there :)</p>
16:14 < jrandom> no, its not web based - current release is actually text only, but work continues on a gui</p>
16:14 < jrandom> http://syndie.i2p.net/roadmap.html</p>
16:14 <+fox> &lt;dm&gt; text-only! wow. ok. downloading.</p>
16:14 < jrandom> w3wt</p>
16:15 < jrandom> one important thing you need to know to effectively use it is the location of a syndie archive that you can push posts to and pull posts from</p>
16:15 <+fox> &lt;dm&gt; wow.. this is hardcore stuff. (Next Command:) hehhehe</p>
16:15 < jrandom> there's currently one at http://syndie.i2p.net/archive - you can sync up with that via "menu syndicate" "getindex --archive http://syndie.i2p.net/archive" and "fetch" :)</p>
16:16 < jrandom> its a fairly simple system, though with very specific design features</p>
16:16 < jrandom> (and incredibly robust - it can run on anything :)</p>
16:17 <+fox> &lt;dm&gt; there's something cool about really complex apps running with a text frontend</p>
16:17 <+fox> &lt;dm&gt; anyway...</p>
16:17 <+fox> * dm shuts up again</p>
16:19 * jrandom hopes to bring us up to 1.0 sometime this month, so beta testing would be great</p>
16:20 < jrandom> (kick the tires, tell me whats broken, etc)</p>
16:20 < jrandom> 1.0 won't include the gui, of course, thats 2.0</p>
16:20 <+fox> &lt;dm&gt; of course</p>
16:21 < jrandom> ok, anyone have any comments/questions/suggestions/toenails on 2) Syndie dev status?</p>
16:22 < jrandom> oh, one thing i wanted to bring up - as i posted in my syndie blog, we need a logo! so, see urn:syndie:channel:d7:channel44:bF2lursCrXhSECJAEILhtXYqQ6o-TwjlEUNJLA5Nu8o=9:messageIdi1160962964161ee :)</p>
16:23 <+fox> &lt;dm&gt; there's a good place to get free or semi-free very high quality logos</p>
16:24 < jrandom> flickr? :)</p>
16:24 <+fox> &lt;dm&gt; http://www.worth1000.com/ &lt;--- photoshop geeks around try to outdo each other for a little fame and/or money</p>
16:24 < jrandom> ah cool</p>
16:25 <+fox> &lt;dm&gt; example of a previous 'contest' http://www.worth1000.com/cache/contest/contestcache.asp?contest_id=12170&start=1&end=10&display=photoshop</p>
16:25 <+fox> * dm shuts up again</p>
16:26 < jrandom> wikked, thanks dm</p>
16:27 < jrandom> ok, if there's nothing on 2, lets jump to 3) ???</p>
16:28 < jrandom> anyone have anything else for the meeting?</p>
16:28 < bar> perhaps we should save that for the 1.99b version and have a little contest/bounty thing going to plug syndie 2.0?</p>
16:28 < jrandom> ah, thats a good idea, since 1.* is going to be text anyway</p>
16:30 < bar> think about it, i'm sure we can dig up some funding</p>
16:30 <+fox> &lt;dm&gt; how's funding going anyway? </p>
16:31 <+fox> &lt;dm&gt; are you still doing this full-time jr?</p>
16:31 < jrandom> aye, still getting by, thanks to some insanely generous contributors (thanks!)</p>
16:31 < jrandom> http://www.i2p.net/halloffame</p>
16:32 <+fox> &lt;dm&gt; ah yes.. the shoestring budget. I remember now</p>
16:32 < jrandom> hehe</p>
16:34 < jrandom> ok, anyone have anything else to bring up?</p>
16:34 <+fox> &lt;dm&gt; just dropped you a c-bill. Make sure it's only used for alcohol or other frivolous uses.</p>
16:34 <+fox> &lt;dm&gt; oh and keep my real name secret!</p>
16:34 < jrandom> w00t! thanks dm</p>
16:36 < jrandom> ok, if there's nothing else...</p>
16:36 * jrandom winds up</p>
16:36 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

103
i2p2www/meetings/186.log Normal file
View File

@@ -0,0 +1,103 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 186{% endblock %}
{% block content %}<h3>I2P dev meeting, October 24, 2006</h3>
<div class="irclog">
16:03 < jrandom> 0) hi</p>
16:03 < jrandom> 1) Net status</p>
16:03 < jrandom> 2) Syndie dev status</p>
16:03 < jrandom> 3) ???</p>
16:03 < jrandom> 0) hi</p>
16:03 * jrandom waves</p>
16:03 * Complication stumbles to somewhere within reach of keyboard (week's beginning was hell, but it's over now)</p>
16:04 < jrandom> (hooray to hellish beginnings!)</p>
16:04 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-October/001315.html</p>
16:04 <+Complication> Hello</p>
16:05 < jrandom> while y'all read the (short) notes, lets jump to 1) Net status</p>
16:05 * jrandom has been connected to freshcoffee for 3 days now w/out discon, and it looks like both of the irc servers have a good number of users on them</p>
16:06 < jrandom> stats.i2p is back too, and the tunnel success rate has been doing some odd jumps, but generally in good shape too</p>
16:06 < jrandom> (though still in the 20-30 range)</p>
16:06 < jrandom> ((which is much better than 5-10, but much worse than 60-80))</p>
16:07 < jrandom> ok, anyone have anything to bring up for 1) net status?</p>
16:08 <+Complication> Similar here, but no extra-persistent connections</p>
16:08 <+tethra> other than applause, nothing from me!</p>
16:08 <+Complication> I just wanted to drop a little line related to NTP issues</p>
16:09 <+Complication> Basically, on Sunday, Oct 29, some times zones will jump off dailight saving time</p>
16:09 < jrandom> (its going to suck)</p>
16:10 <+Complication> I personally hope it doesn't cause anyone any problems, but I'm not well versed enough in NTP to be sure</p>
16:10 <+Complication> So, just in case the recent NTP server sanity check (added with version .26) should inconvenience someone that night...</p>
16:11 <+Complication> ...I thought it'd be better if I mentioned the configuration key using which it can be disabled (if need should exist)</p>
16:11 <+Complication> (so folks who read status notes would know)</p>
16:12 <+Complication> Disabling it can be done by entering the line "router.clockOffsetSanityCheck=false" into http://localhost:7657/configadvanced.jsp</p>
16:12 <+Complication> But as mentioned, I do hope nobody needs that</p>
16:13 <+Complication> It will be interesting to watch and see how the network behaves that night, though, as different time zones start switching</p>
16:13 <+Complication> I'll certainly observe, in hope that if any anomaly is seen, perhaps it can be fixed by Spring :D</p>
16:14 < jrandom> the minute-of will probably be pretty jumpy, but should heal shortly</p>
16:14 <+Complication> ...and that's all I had. :)</p>
16:14 < jrandom> but, hopefully it'll work out, and if not, as you say, there's spring :)</p>
16:14 < bar> and should things indeed b0rk, there were two possible suggestions for future improvement that surfaced in the chat the other day:</p>
16:15 < bar> "prevent skewed routers from forming subnets by handing over control to NTP if peers &lt; some number"</p>
16:15 < bar> ...and "do not delete floodfill peer router infos from netdb if there are too few of them"</p>
16:15 < jrandom> aye</p>
16:16 <+Complication> Indeed, adjusting the required number of data points (available peer clock skews) which are required to deem peer skew measurements reliable</p>
16:16 <+Complication> (oops, some redundancy in my last sentence)</p>
16:17 <+Complication> ...and yes, the floodfill check. I take that no similar check exists currently?</p>
16:18 < jrandom> right</p>
16:18 <+Complication> Seems like some people, sometimes, either with luck or magic, may be managing to lose track of floodfill peers</p>
16:19 < jrandom> that should certainly be remedied</p>
16:19 < jrandom> (it hit some folks the other day, when one of 'em was null routed)</p>
16:20 < jrandom> (if #floodfill == 0, perhaps randomly treat a few as floodfill)</p>
16:20 <+Complication> If that's doable, possible also</p>
16:21 <+Complication> Though, perhaps doing that in addition to keeping at least 2 (or something like that) floodfill peers would be a doubly safe bet</p>
16:22 < jrandom> aye</p>
16:25 < jrandom> ok, anyone have anything else for 1) net status? or shall we move on over to 2) syndie dev status?</p>
16:25 < badger> re irc stability: seeing much much much fewer reconnects at the server end.</p>
16:25 < badger> you could almost call it a service :)</p>
16:26 < jrandom> :)</p>
16:28 < jrandom> ok, jumping on to 2) syndie dev status</p>
16:28 < jrandom> lots of progress here, as mentioned in the status notes</p>
16:28 < jrandom> there's also been a bunch of discussion on it here over the last few days</p>
16:28 < jrandom> anyone have anything they want to bring up on that front?</p>
16:30 <@cervantes> install something other than mspaint</p>
16:30 < jrandom> heh</p>
16:30 < jrandom> well, there's value in using *ugly* things to sketch - limits expectations</p>
16:31 <+fox> &lt;HotTuna&gt; the links in the forumpost seem to be down ... some are anyway..</p>
16:31 <@cervantes> I think that's mentioned in the posts</p>
16:31 <+fox> &lt;HotTuna&gt; oh. . sorry</p>
16:31 < jrandom> hottuna: they're mirrored @ dev.i2p.net/~jrandom/mockup/</p>
16:31 <@cervantes> some should be mirrored further down</p>
16:32 <+Complication> One question: so, do you think it's easier to (safely) implement limited HTML from ground up, without picking apart some web browser?</p>
16:33 * jrandom just uploaded two more pics: dev.i2p.net/~jrandom/mockup/forum.png and blog.png (showing the discussion of the last few days regarding different ways to view a forum)</p>
16:33 <@cervantes> most definitely easier to do that safely</p>
16:33 <+Complication> (just being curious as to what's going in on the GUI side, having been somewhat unaware of it)</p>
16:33 < jrandom> Complication: i've got nearly everything done for general formatting purposes already</p>
16:33 <@cervantes> especially given the limited subset of html that syndie will support</p>
16:34 <+Complication> Aha</p>
16:34 < jrandom> (fonts, alignment, sizes, colors, images, links, lists (including nested), headers, paragraphs, html entities)</p>
16:35 < jrandom> now, going in and doing divs for placement or tables requires substantially more work, but i'm not tackling that now</p>
16:35 <+Complication> Sounds nice enough</p>
16:36 <@cervantes> and of course the &lt;blink&gt; tag</p>
16:36 * jrandom pelts cervantes with &dagger;</p>
16:37 <@cervantes> ouch, skewered by an entity</p>
16:37 < jrandom> we'll see though. as it gets deployed and used, perhaps it'll be necessary to switch to a full blown html rendering engine</p>
16:38 * jrandom wants the codebase to be as small as possible though, so there is less to debug and review for security and anonymity issues</p>
16:39 <+Complication> Indeed, there are doubtless benefits to handling text/plain</p>
16:40 <+Complication> (which hopefully only supports natural-language attacks ;P )</p>
16:41 <+Complication> What are your opinions about the possibility of hashcash antispam measures? Too early to tell? Do you think they'd be easy to tack on later?</p>
16:42 <@cervantes> well I guess using bbcode or wiki syntax would reduce the risk of markup injection in a full html engine</p>
16:42 <@cervantes> *rendering engine</p>
16:43 < jrandom> quite easy to tack on Complication - just a new public header (hashcalc'ed against the canonical syndie uri, verified on import, created on signing)</p>
16:44 * Complication thought about some a few days back, but only lightly</p>
16:44 < jrandom> the hashcash can be done at several levels too - per new channel (meta.syndie), per updated channel, or per post (perhaps even graduated against sizeof(post) or #msgs/day)</p>
16:44 <+Complication> If one wanted to implement hashcash as proof of work, I wonder what the poster of the message would be best required to caclulate collisions against?</p>
16:45 <+Complication> Aha, the uri... might be indeed</p>
16:45 <+Complication> Oh, indeed</p>
16:45 <+Complication> That's some things I didn't think about</p>
16:48 < jrandom> cervantes: true enough</p>
16:48 < jrandom> ok, anyone have anything else for 2) syndie dev status?</p>
16:51 < jrandom> ok, if not, lets jump to 3) ???</p>
16:51 < jrandom> anyone have anything else they want to bring up?</p>
16:54 < jrandom> ok, if not...</p>
16:54 * jrandom winds up</p>
16:54 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

76
i2p2www/meetings/187.log Normal file
View File

@@ -0,0 +1,76 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 187{% endblock %}
{% block content %}<h3>I2P dev meeting, October 31, 2006</h3>
<div class="irclog">
15:33 < jrandom> 0) hi</p>
15:33 < jrandom> 1) Net status</p>
15:33 < jrandom> 2) Syndie dev status</p>
15:33 < jrandom> 3) ???</p>
15:33 < jrandom> 0) hi</p>
15:33 * jrandom waves</p>
15:33 < jrandom> weekly status notes up at http://dev.i2p.net/pipermail/i2p/2006-October/001316.html</p>
15:33 * tethra waves back!</p>
15:34 < jrandom> lets jump on in to 1) net status</p>
15:34 < jrandom> no news on this front afaik... things seem stable</p>
15:34 < jrandom> anyone have anything they want to bring up on it?</p>
15:35 <+tethra> nothing here</p>
15:36 < jrandom> ok lets jump on to 2) Syndie dev status then</p>
15:37 < jrandom> as mentioned in the notes, i've been exploring some wysiwyg editor components, but it seems a big pain in the ass (no suprise), and no great solution exists afaik</p>
15:38 < jrandom> so, right now my thoughts are to go with a basic editor with helpers like you see on forums like forum.i2p.net. not wysiwyg, but helpful</p>
15:39 <+tethra> makes sense. might wysiwyg be a progression later on, then?</p>
15:39 < jrandom> of course, if someone tracks down a good small oss wysiwyg editor, i'd love to hear about it (though i've reviewed a dozen options)</p>
15:39 < jrandom> aye, thats a great way for later enhancement</p>
15:40 <+tethra> less of a jump between geek and non geek that way :)</p>
15:40 <+tethra> (have you looked at Nvu?)</p>
15:41 < jrandom> aye, huge, but promising</p>
15:41 <+tethra> which others had you looked at?</p>
15:42 <+tethra> out of interest</p>
15:42 < jrandom> everything i could google into. no list at hand</p>
15:42 <+tethra> ah, right</p>
15:44 < koff> Would it be useful to have a split view with the html at the bottom and a realtime updating rendering of the page at the top?</p>
15:45 <+tethra> or maybe left/right (being able to choose would be lovely</p>
15:45 <+tethra> )</p>
15:45 < jrandom> aye, thats a good idea (not entirely realtime, but semi-realtime)</p>
15:46 <+tethra> yeah, refresh button etc</p>
15:46 < jrandom> perhaps on 5s idle or a button press</p>
15:46 < jrandom> right</p>
15:48 < koff> You could maybe even have two cursors, so you almost feel like you're navigating both at the same time?</p>
15:48 <+tethra> that'd be a bit confusing :/</p>
15:48 < koff> maybe :)</p>
15:50 < jrandom> ok, anyone have anything else on 2) syndie dev status?</p>
15:51 < jrandom> if not, lets move on to 3) ???</p>
15:51 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
15:54 <+fedo> yeah Jr , can hope to have a "joe 6 pack"'s guide to use syndie 1.0 ? ie : what we can do with that text mode console ...</p>
15:55 <+fedo> i'll love to help to test syndie but i'm still unable to understand how to use syndie ! :)</p>
15:55 < jrandom> fedo: does http://syndie.i2p.net/manual.html and http://syndie.i2p.net/features.html and http://syndie.i2p.net/usecases.html help?</p>
15:55 < jrandom> is it a question of "what can you do with syndie", or "how can you do $x"?</p>
15:55 <+fedo> hm not really Jr :-/</p>
15:56 <+fedo> really, i try to do it ...</p>
15:56 <+fedo> how i can use syndie ...</p>
15:57 <+fedo> the text mode console is not a problem</p>
15:57 < jrandom> how you can use syndie /to do what/? or is that the question itself - why would you install and use syndie?</p>
15:57 <+fedo> but what to do when i've installed Syndie is one :-s</p>
15:57 < jrandom> ah</p>
15:58 < jrandom> ok, think of syndie like a customized web browser - you install it so that you can participate in forums. once you install it, you need to tell it what forums you want to participate in</p>
15:59 < jrandom> the current 0.919b install will out of the box tie in to the syndie archive at http://syndie.i2p.net/archive/ - you can just install it, log in, and sync up</p>
16:00 < jrandom> and once you've synced up, you can read posts to the various forums, post up replies, or post up to your own forum</p>
16:01 <+fedo> Jr : i'm thinking that you could made a breif note to explain how to use Syndie : ie how to sync, how to fecth a post ...</p>
16:02 <+tethra> (or even, an example repository (syndie.i2p.net ?) to sync to)</p>
16:02 <+tethra> oh, didn't read above :/</p>
16:02 <+tethra> nvm</p>
16:03 < jrandom> fedo: good idea, i'll write one up</p>
16:03 * fedo waves</p>
16:05 < jrandom> ok cool, anyone have anything else for the meeting?</p>
16:05 <+fedo> we know that you to enable the use of syndie on freenet : tell us how to do it ... (you know that i'm unable to find by reading the syndie's code :-/ )</p>
16:05 <+fedo> ((help me :))</p>
16:06 < jrandom> http://syndie.i2p.net/manual.html#syndicate_freenetpost</p>
16:06 < jrandom> and http://syndie.i2p.net/manual.html#syndicate_getindex</p>
16:07 <+fedo> many 'neurones' to burn but i'll try :)</p>
16:07 < burl> fedo: Complication has written a brief and pretty handy startup guide on the forum here: http://forum.i2p/viewtopic.php?p=8860#8860</p>
16:08 < jrandom> ah right, thats a good one burl</p>
16:08 <+fedo> thanks burl : i'll have a look to that note ;)</p>
16:12 < jrandom> word, ok, if there's nothing else for the meeting...</p>
16:12 * jrandom winds up</p>
16:12 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

93
i2p2www/meetings/188.log Normal file
View File

@@ -0,0 +1,93 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 188{% endblock %}
{% block content %}<h3>I2P dev meeting, November 7, 2006</h3>
<div class="irclog">
15:09 < jrandom> 0) hi</p>
15:09 < jrandom> 1) Net status</p>
15:09 < jrandom> 2) Syndie dev status</p>
15:09 < jrandom> 3) I2Phex mods</p>
15:09 < jrandom> 4) ???</p>
15:09 < jrandom> 0) hi</p>
15:09 * jrandom waves</p>
15:10 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2006-November/001317.html</p>
15:10 * spaetz waves back</p>
15:10 < mrflibble> cool, i was the only one in #i2p-dev a minute ago :)</p>
15:10 < jrandom> hehe</p>
15:10 < jrandom> yeah, the i2p-dev chan migration didn't last too long ;)</p>
15:10 < jrandom> ok, lets jump into 1) Net status</p>
15:11 < spaetz> ad 1) net seems stable</p>
15:11 < spaetz> however, as you noted, reseeding is needed every 7 days or so</p>
15:11 < jrandom> aye, 'tis unfortunate, and fixable</p>
15:12 < jrandom> though the kludge fix is kind of ugly, and the long term fix is pretty involved</p>
15:12 < spaetz> yep, that would be nice. My firewall is too tight for reseeding</p>
15:12 < jrandom> damn, doesn't allow outbound http to dev.i2p.net?</p>
15:12 < spaetz> I need to poke additional holes in it :-)</p>
15:13 < spaetz> jrandom: outbound yes, but all the reply data gets stopped by default :-)</p>
15:13 < spaetz> but that OT. go on.</p>
15:14 < jrandom> lol ok, interesting</p>
15:14 < jrandom> its something that needs to get addressed, though its not on my do-immediately pile</p>
15:15 < jrandom> i dont really have much more to add to 1).. anyone have anything else they want to bring up re: net status?</p>
15:15 < spaetz> I get disconnected on IRC every 1-2 hours</p>
15:15 < spaetz> but I would call that stable :-)</p>
15:16 < spaetz> ok, on to 2)</p>
15:16 < jrandom> heh cool, 2) it is</p>
15:17 < jrandom> lots of progress on this front</p>
15:17 < spaetz> Is the new Syndie going to be integrated into i2p when it goes gold?</p>
15:18 < jrandom> hmm, if you mean bundled with, i'm not sure. if you mean capable of seamlessly using, yes, definitely</p>
15:19 < spaetz> I actually meant bundled. I2p seems to come "with batteries included"</p>
15:19 < jrandom> the reason i'm not sure is that syndie will weigh a good deal (swt native libs, translations, spellcheck dictionaries, etc)</p>
15:19 < jrandom> we will have an option to bundle them, certainly</p>
15:20 < jrandom> and maybe that'll be the most common download</p>
15:20 < spaetz> ok, I'm for an optional install then. alright. </p>
15:21 < jrandom> bundling the text UI is certainly doable without a doubt, thats quite lightweight</p>
15:22 < spaetz> that might be good enough to tease people</p>
15:22 < spaetz> SOme might want to run the gui on a different machine than their i2p peer anyway</p>
15:22 < spaetz> (I will)</p>
15:23 < jrandom> word</p>
15:23 < jrandom> ok, some teaser images for the gui dev status:</p>
15:23 < jrandom> html rendering: http://dev.i2p.net/~jrandom/mockup/render_snap.png</p>
15:23 < jrandom> forum tree: http://dev.i2p.net/~jrandom/mockup/syndie_refchooser.png</p>
15:23 < jrandom> message tree / filter: http://dev.i2p.net/~jrandom/mockup/syndie_msgchooser.png</p>
15:24 < jrandom> (the html rendering has been seen before, and the reference chooser may have been, and the message chooser was just implemented last night ;)</p>
15:25 < jrandom> there'll be lots of little add-ons, but i'm focusing on first getting gui message generation in place</p>
15:25 < jrandom> (which requires being able to browse forums and messages anyway, to pick links)</p>
15:26 < spaetz> cool</p>
15:26 < spaetz> although the beauty of syndie was its seamless integration through the web interface</p>
15:26 < spaetz> but I bet that would be possible to implement</p>
15:27 < jrandom> well, a web interface would technically be possible, but it would have all the security issues of the browser plus all the problems for interactive content that javascript/etc can cause</p>
15:28 < spaetz> mmh, I see the hell you'd get into. I remember the corresponding freenet discussions a few years back</p>
15:28 < jrandom> technically, we can pull in the mozilla engine to do html rendering with the SWT Browser widget, but doing so just isn't safe</p>
15:29 < jrandom> aye, exactly</p>
15:29 < jrandom> (and what, 5-8 years on, they still just found another security hole in their filter the other week)</p>
15:30 < jrandom> ((my point is not that their filter isn't great, its that doing the filter is insanely dangerous))</p>
15:30 < spaetz> ok, if there's a document "syndie for dummies" I'd give it a shot. (the text UI). IS the manual the right document for this?</p>
15:30 < spaetz> It seemed a bit specific already</p>
15:31 < jrandom> ah - check out Complication2's post: http://forum.i2p.net/viewtopic.php?t=1935</p>
15:31 < spaetz> ok, thanks.</p>
15:31 < jrandom> that's getting wrapped up into a page for the syndie site, but isn't up yet</p>
15:32 < spaetz> ok, that's great. all I needed</p>
15:34 < jrandom> cool. ok, thats about it for gui stuff atm</p>
15:34 < jrandom> there's a little teaser for the p2p folks in the status notes regarding a swarming syndication system</p>
15:35 < jrandom> thats an area quite ripe for playing around in, for those who'd like to do some network hacking</p>
15:36 < jrandom> but, thats just a side note</p>
15:36 < jrandom> ok, if there's nothing else on 2) syndie dev status, lets jump over to 3) i2phex mods</p>
15:36 < jrandom> Complication2: wanna give us the rundown?</p>
15:38 < jrandom> or, if you're not here, those of y'all interested can check the status notes for my synopsis</p>
15:39 < spaetz> mmh, gone fishin'</p>
15:39 < jrandom> ok, lets jump on over to 4) ???</p>
15:39 < jrandom> anyone have anything else to bring up for the meeting?</p>
15:39 * mrflibble sticks his hand up</p>
15:40 < spaetz> nahh, looking forward to see (the new) Syndie getting more useful</p>
15:40 < mrflibble> on http://dev.i2p.net/pipermail/i2p/2006-November/001317.html, what does "hi y'all, good luck with the subpoena power" mean exactly?</p>
15:40 < spaetz> will the first codename be "will the real Syndie please stand up?" :-)</p>
15:41 < jrandom> mrflibble: http://www.electoral-vote.com:2006/</p>
15:41 < jrandom> hehe spaetz </p>
15:41 < mrflibble> oh!</p>
15:41 * bar impregnates a ballot</p>
15:43 < jrandom> (not that the democrats would be any better for the world, but the ability to subpoena the us president via congressional investigations would likely throw a few wrenches into the war machine for a bit)</p>
15:44 < jrandom> ok, anyone have anything else for the meeting?</p>
15:45 < jrandom> if not...</p>
15:46 * jrandom winds up</p>
15:46 * jrandom *baf*S the meeting closed</p>
</div>
{% endblock %}

96
i2p2www/meetings/189.log Normal file
View File

@@ -0,0 +1,96 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 189{% endblock %}
{% block content %}<h3>I2P dev meeting, November 14, 2006</h3>
<div class="irclog">
15:07 < jrandom> 0) hi</p>
15:07 < jrandom> 1) Net status</p>
15:07 < jrandom> 2) Syndie dev status</p>
15:07 < jrandom> 3) I2Phex mods</p>
15:07 < jrandom> 4) ???</p>
15:07 < jrandom> 0) hi</p>
15:07 * jrandom waves</p>
15:07 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-November/001318.html</p>
15:07 < jrandom> (i'm late, so i'll let y'all catch up on those)</p>
15:09 < jrandom> ok, lets jump on in to 1) net status</p>
15:10 < jrandom> [eom] :)</p>
15:10 * jrandom has had a good irc connection now (4+ days), so things are in pretty good shape.</p>
15:11 < jrandom> we've also got those new peer capacity graphs on stats.i2p, detailing some interesting ratios </p>
15:13 < jrandom> ok, anyone have anything else for 1) net status?</p>
15:14 < striker> just that it looks nice.</p>
15:14 < jrandom> w00t :)</p>
15:15 < jrandom> ok, lets hop on over to 2) syndie dev status then</p>
15:15 < green> I dunno U can have 4+ days conection on IRC,, I'm disconnected somewhat every 24h even with a router not so overloaded</p>
15:15 < jrandom> green: unfortunately, its pretty arbitrary.</p>
15:16 < jrandom> (or, more precicely, the cause is dependent upon many factors without a good control over them)</p>
15:17 < green> any chance to really know why ?</p>
15:17 < green> I've plenty of tunnels even where IRC goes down</p>
15:18 < green> s/when</p>
15:18 < jrandom> yes, there's lots we can do, but i'm focusing my time on getting syndie out first</p>
15:18 < green> I know, so I've just to way more ;)</p>
15:19 < green> s/wait</p>
15:20 < green> gr f..ing keyboard</p>
15:20 < green> ok, no more on 1 let's got to 2</p>
15:20 < jrandom> w3rd</p>
15:21 < jrandom> ok, not much more to add beyond whats in the notes (well, that can reasonably be brought up)</p>
15:21 < jrandom> the webcaching discussion thread is http://forum.i2p.net/viewtopic.php?t=1958</p>
15:22 < green> is there any plan on phpbb to syndie converter ?</p>
15:22 < jrandom> and the latest mockup image referred to is http://dev.i2p.net/~jrandom/mockup/forum.png</p>
15:23 < jrandom> green: hmm, i thought we discussed that in one of the meetings, but looking back at the logs, it occurred outside of a meeting</p>
15:24 < jrandom> short answer: doable, and maybe it'll get done, but its not on the immediate roadmap</p>
15:24 < jrandom> at least, not bidirectional phpbb&lt;--&gt;syndie operation</p>
15:24 < jrandom> phpbb--&gt;syndie is easy (just suck in the posts, or use server side generation)</p>
15:25 < jrandom> syndie--&gt;phpbb is easy too</p>
15:25 < jrandom> i'm not sure if the phpbb model of operation is what people will end up using syndie for though</p>
15:25 < jrandom> but we'll see</p>
15:28 < green> even just an phpbb -&gt; syndie would be enough</p>
15:30 < jrandom> cool, that'll be trivial (pulling phpbb's rendered html into a page & posting it). a bit more complex would be pulling from phpb's database itself, though that'd give more control (but then only the phpbb admin could do it - the former method can be done by anyone)</p>
15:31 < badger> phpbb's admin is fairly flat.... not a challenge to get a hook of</p>
15:32 < badger> and there are various rss plugins available for it</p>
15:33 < jrandom> ah cool. actually, if someone wanted to start looking into that, it'd rule - just generate an HTML page (and if you need to reference other resources, do so with the syndie URIs [syndie.i2p.net/spec.html#uri] </p>
15:34 < jrandom> (and if you need images/etc, just reference them as img src="attachment1" etc)</p>
15:34 < jrandom> (and then we can shove 'em into a syndie post with no problem)</p>
15:35 < jrandom> currently the message editor has "add text page" and "add html page" features... eventually we can toss in an "add page from the web..." that prompts you for a URL to fetch</p>
15:37 < badger> http://forum.i2p/rss_news.php</p>
15:38 < badger> translating that to syndie markup would probably be straightforward</p>
15:39 < jrandom> aye (though remember, syndie markup /is html/. the uris are just... long and hard to read :)</p>
15:41 < jrandom> ok, anyone have anything else on 2) syndie dev?</p>
15:42 < jrandom> if not, lets jump to 3) i2phex mods</p>
15:43 < jrandom> strike1 / Complication: wanna give us an update?</p>
15:43 < strike1> I did a quick sanity check in regards to solving the connect to self problem</p>
15:43 < strike1> http://forum.i2p.net/viewtopic.php?t=1965</p>
15:44 < strike1> It seems to be working okay, but is merely preventing the local dest from being added to i2phex.hosts</p>
15:44 < strike1> I am also looking into the hashing problems, and the downloading issues</p>
15:45 < jrandom> kickass!</p>
15:45 < strike1> The new mods in cvs seem to make for a slightly better i2phex so far too, I must say.</p>
15:48 < strike1> Hopefully between Complication, I, and anyone else who wants to help we can solve them all soon. :)</p>
15:49 < jrandom> wikked, thanks strike1 (& complication et al!)</p>
15:50 < jrandom> ok, anyone have anything else for 3) i2phex mods?</p>
15:51 < jrandom> if not, lets jump to 4) ???</p>
15:51 < jrandom> anyone have anything else they'd like to bring up for the meeting?</p>
15:54 < green> any chance to have a dijjer port on I2P ?</p>
15:55 < green> wow, don't worry, just a simple question ;)</p>
15:55 < jrandom> probably not (dijjer port being a large number of public squid outproxies that cache)</p>
15:56 < jrandom> but the ability to have content hosted when you're not online will be there with syndie</p>
15:56 < jrandom> (and syndie can run over i2p)</p>
15:56 < green> sure but how syndie can handle large content ?</p>
15:57 < jrandom> technically, yes, but practically, no</p>
15:58 < green> so using cache is not a so bad idea ?</p>
15:58 < jrandom> otoh, we can have syndie distributed .torrent files for torrents that are encrypted with session keys that only those authorized on syndie know</p>
15:59 < jrandom> there's a use case for caching large files, though i'm not sure if the freenet/dijjer caching method is the best route</p>
15:59 < jrandom> (no pun intended)</p>
15:59 < green> humm .torrent files so we have to rely on a cetral server / tracker</p>
15:59 < green> s/central</p>
16:00 < jrandom> (for instance, see http://freehaven.net/anonbib/#redblue )</p>
16:01 < jrandom> green: torrents can be distributed, and you can put the same data on lots of swarms</p>
16:01 < jrandom> but functionally, we know that torrents work for transfering truckloads of data</p>
16:03 < green> There isn't so much goo tracker on I2P, so currently we rely on a central server even if it's doable to distribute torrent over a lot of tracker</p>
16:05 < jrandom> hmm, the trackers we have are good, there just isn't that much content :)</p>
16:06 < strike1> I agree though looking at postman's tracker I was impressed with what I found there as opposed to last year.</p>
16:07 < jrandom> aye, quite</p>
16:07 < strike1> Lots of nice stuff :)</p>
16:09 < jrandom> ok, anything else for the meeting?</p>
16:10 < green> (baf) :)</p>
16:10 * jrandom winds up</p>
16:10 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

120
i2p2www/meetings/190.log Normal file
View File

@@ -0,0 +1,120 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 190{% endblock %}
{% block content %}<h3>I2P dev meeting, November 21, 2006</h3>
<div class="irclog">
15:02 < jrandom> 0) hi</p>
15:02 < jrandom> 1) Net status</p>
15:02 < jrandom> 2) Syndie dev status</p>
15:02 < jrandom> 3) ???</p>
15:02 < jrandom> 0) hi</p>
15:02 * jrandom waves</p>
15:02 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-November/001319.html</p>
15:03 < jrandom> since that one is pretty short, lets jump on in to 1) net status</p>
15:04 < jrandom> things are looking pretty good atm, network seems pretty steady</p>
15:04 <+zzz> I invented a "peer capacity index"</p>
15:04 <+zzz> on the dashboard...</p>
15:04 <+zzz> so far not sure it is helpful though</p>
15:04 < jrandom> ah yeah, sorry, metioned that one last week - looks quite useful, thanks!</p>
15:05 < jrandom> interesting to see the disparity out there so clarly</p>
15:05 <+zzz> the idea is the ratio of high-cap routers to low-cap routers, which is obviously important to tunnel build %</p>
15:06 <+zzz> I'm removing routers from stats that I don't get a netdb update for in 1.5 hours but that seems too quick, I think it is skewing the stats</p>
15:07 < jrandom> ah, ok, that would explain it. are you still harvesting?</p>
15:07 < jrandom> (or wget'ing from dev.i2p.net?)</p>
15:08 <+zzz> yes</p>
15:08 < jrandom> cool</p>
15:08 <+zzz> netDb.harvestDirectly=false</p>
15:08 <+zzz> netDb.shouldHarvest=true, right?</p>
15:09 < jrandom> so the stats we've had before were largely based on routers that were so bad the user shut them down & disapeared then?</p>
15:09 < jrandom> right</p>
15:10 <+zzz> it's always been 1.5 hours, but plotting the M/N/O routers, they seem to come and go when intuitively they should stay pretty constant</p>
15:10 < jrandom> ah ok</p>
15:10 <+zzz> you can see spikes/dips in all the data that last 1.5 hours :)</p>
15:11 < spaetz> net seems pretty stable. Yep</p>
15:12 <+zzz> thats all I have for that topic</p>
15:12 < spaetz> I'd like to know if jrandom completely focuses on syndie nowadays or if he still looks at i2p dev.</p>
15:12 < spaetz> or if this is just a bit on hte backburner temporarily</p>
15:13 * jrandom completely focuses on syndie nowadays, but will work on i2p both when there are problems and once syndie is established</p>
15:13 * spaetz thanks for the information</p>
15:14 * spaetz is fine with this</p>
15:15 < jrandom> w3wt. yeah, steadystate means syndie dev can continue, but if there are problems, of course i reprioritize</p>
15:15 < jrandom> ok, anyone have anything else on 1) net status?</p>
15:15 < Walter> I have a random question.</p>
15:15 < jrandom> hit me Walter </p>
15:17 < Walter> Assume you have 100Mb/s BW, what kind of server would you need to saturate it as an I2P node?</p>
15:17 < jrandom> doesnt matter</p>
15:17 < jrandom> i2p does not and will not saturate 100Mbps</p>
15:18 < Walter> Assume one wanted to make use of available BW.</p>
15:18 < jrandom> you would not.</p>
15:19 < spaetz> I've got 150kbs up and down and it uses like 25% of a vserver (Dell shared with a dozen others)</p>
15:19 < jrandom> that exceeds the capacity of the entire network</p>
15:19 < spaetz> 25%CPU that is</p>
15:19 * spaetz admits that's not really a precise answer and shuts up</p>
15:20 < jrandom> the routers themselves have a mem v. throughput tradeoff, making it less likely that a router can even push &gt; 3-350KBps</p>
15:20 < jrandom> (of course, that tradeoff can be tweake to allow higher rates, but thats not an issue)</p>
15:21 < jrandom> using bandwidth is *BAD* unless that bandwidth is being used only when necessary</p>
15:22 <+zzz> the network is averaging about 1.5 MBps (=12 Mbps) total traffic over the last 3 months</p>
15:23 < Walter> I see.</p>
15:24 <+fox> &lt;LeerokKitchen&gt; Field trip!</p>
15:26 < jrandom> ok, if there's nothing else for 1) net status, lets jump on over to 2) syndie dev status</p>
15:26 < jrandom> progress here continues, and i've been doing testing both on windows and linux</p>
15:28 < jrandom> current battle is on the forum management interface, though since the text interface is already embedded, all functionality is already in place</p>
15:29 < jrandom> not much more news to discuss on that front though</p>
15:30 < jrandom> anyone have any questions/comments/concerns on 2) syndie dev status?</p>
15:33 < jrandom> ok, lets jump on to 3) ???</p>
15:33 < jrandom> y'all have anything else for the meeting?</p>
15:34 <+fox> &lt;blx&gt; when will gpl java be usable with i2p=</p>
15:34 <+fox> &lt;blx&gt; ?</p>
15:35 < Complication3> I guess it depends on when gpl java will be usable on various distros</p>
15:35 < Complication3> Or available for download from Sun</p>
15:36 < Complication3> But it feels like a moot point, since it's the same Java which is usable already now</p>
15:36 < Complication3> GPL would only let it be packaged more conveniently, and improved upon</p>
15:37 < jrandom> (and i2p already works with gcj/kaffe, though not all of the client apps)</p>
15:37 * Complication3 quickly reads backlog</p>
15:37 < jrandom> ((and syndie works with gcj/kaffe completely))</p>
15:38 <+fox> &lt;blx&gt; Compilation, thats what they want you to think ;)</p>
15:38 <+fox> &lt;blx&gt; but ok, i got my question answered.</p>
15:38 <+fox> &lt;blx&gt; Complication even. misread</p>
15:39 < Complication3> blx: well, the sources are available already now, it's just that few read and compile them</p>
15:39 < jrandom> (and you can even modify and use those modifications, you just can't distribute your mods)</p>
15:40 < koff> when will i2p have the logging functionality suggested by the proposed laws i heard about?</p>
15:41 < jrandom> never</p>
15:41 <+zzz> hahahaha</p>
15:41 * Complication3 suspects never :)</p>
15:41 <+fox> &lt;blx&gt; what laws?</p>
15:41 * jrandom assumes you refer to .de/.eu data retention issues</p>
15:41 < Complication3> Someone in the forum talked of a (proposed) law in Germany</p>
15:42 < jrandom> (and then the .us ones in a few years)</p>
15:42 < Complication3> They could have spelled it out better though</p>
15:42 < jrandom> aye, 'tis just proposed, but not a big suprise</p>
15:43 < Complication3> I personally think: it's not like data retention laws aren't being broken left and right already</p>
15:43 < Complication3> Breaking a dozen more of them? I personally wouldn't care much...</p>
15:44 < Complication3> In short, I want to see how they're going to enforce it</p>
15:44 < tea> like they did with napster : arrest everyone</p>
15:45 < Complication3> If they manage to make a good try, something will need to be found to thwart that ("not in my country" peering principle for countries where insanity prevails)</p>
15:45 <+fox> &lt;LeerokLacerta&gt; That reminds me of a song.</p>
15:45 <+fox> &lt;LeerokLacerta&gt; http://2ch.ru/mu/src/1163070550597.mp3</p>
15:46 < tea> turning all data traffic over to anonymous networks might help ...</p>
15:47 < Complication3> Just ignoring them en masse has worked for plain ordinary pirates...</p>
15:47 < Complication3> You can arrest one person ignoring you. Can't do that with several hundred thousand.</p>
15:47 < tea> that's no argument for a german :)</p>
15:47 <+fox> &lt;modulus&gt; you can</p>
15:47 <+fox> &lt;modulus&gt; hitler did</p>
15:48 < Complication3> That's only because nobody bothered removing him</p>
15:48 < jrandom> *cough*</p>
15:48 < Complication3> Had they taken up arms, it wouldn't have worked</p>
15:48 < Complication3> (sorry, far off topic, yes)</p>
15:48 < tea> still, one does feel important in being paranoid</p>
15:48 <+fox> &lt;modulus&gt; that said i think i2p could comply with data retention laws without damaging anonimity, but there's no reason to do that.</p>
15:48 < jrandom> ok, well, i think we've addressed the i2p-related issue there ;)</p>
15:48 < tea> sry</p>
15:49 < jrandom> aye modulus</p>
15:49 < jrandom> (we already assume individual users are logging everything anyway, as are the isps)</p>
15:49 <+fox> &lt;modulus&gt; right, so a DR-enabled i2p wouldn't be the end of the world</p>
15:51 < Complication3> Someone would have to bother forking that, though... :P</p>
15:52 * jrandom keeps my mouth shut ;)</p>
15:52 < jrandom> ok, anyone have anything else for the meeting?</p>
15:53 < jrandom> if not</p>
15:53 * jrandom winds up</p>
15:53 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

58
i2p2www/meetings/191.log Normal file
View File

@@ -0,0 +1,58 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 191{% endblock %}
{% block content %}<h3>I2P dev meeting, November 28, 2006</h3>
<div class="irclog">
15:14 < jrandom> 0) hi</p>
15:14 < jrandom> 1) Net status</p>
15:14 < jrandom> 2) Syndie dev status</p>
15:14 < jrandom> 3) ???</p>
15:14 < jrandom> 0) hi</p>
15:14 * jrandom waves</p>
15:14 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-November/001320.html</p>
15:14 < jrandom> (sorry for the delay, small kitchen emergency)</p>
15:14 < gott> Hello, jrandom.</p>
15:15 < jrandom> heya gott</p>
15:15 < jrandom> ok, lets jump in to 1) net status</p>
15:15 * jrandom has nothing more to add for 1) net status, beyond mentioning that i've been connected to irc for 13 days now w/out discon)</p>
15:16 < gott> I have been able to download my favourite modernist movie Metroland from the Frenchmen in #fr via i2psnark</p>
15:16 < gott> Going at download rate of 4400 kb/s; upload around the same.</p>
15:16 < gott> 6 peers.</p>
15:16 < gott> Very good for the propagation of European modernist fiction.</p>
15:16 < jrandom> !thwap</p>
15:17 < jrandom> (or, if you are actually getting 4Mbps, both sides are using 0hop tunnels)</p>
15:17 < gott> bytes a second.</p>
15:18 < jrandom> anyone have anything else to bring up for 1) net status?</p>
15:20 < jrandom> ok, lets jump on over to 2) syndie dev status</p>
15:20 < gott> Is it possible to make i2p better somehow in this regard?</p>
15:20 < jrandom> gott: oh, you mean 4400 Bps, not kbps?</p>
15:20 < jrandom> then i take back the 0hop tunnel thing</p>
15:21 < jrandom> 4KBps is typical atm, and can be improved with better peer selection and congestion management</p>
15:22 < jrandom> ok, for syndie dev status, lots of progress going on, as mentioned in the notes</p>
15:23 < jrandom> there's still a bunch of gaps to fill, but they're largely just filling gaps, not writing new components</p>
15:24 < jrandom> ok, anyone have anything else on 2) syndie dev status?</p>
15:25 < jrandom> ok, lets jump on over to 3) ??? then</p>
15:26 < jrandom> anyone have anything else to bring up in this short meeting?</p>
15:26 < JosephLeBlanc> Do you need any money?</p>
15:26 < JosephLeBlanc> oh for fuck sake</p>
15:26 < JosephLeBlanc> well, do you need any money?</p>
15:27 < JosephLeBlanc> Do you want a computer?</p>
15:27 < JosephLeBlanc> Do you want beer?</p>
15:27 < JosephLeBlanc> What?</p>
15:27 < jrandom> atm, finances are in pretty good shape, though contributions are always appreciated, of course</p>
15:27 < JosephLeBlanc> Out with it</p>
15:27 < JosephLeBlanc> Alright, then</p>
15:27 <+zzz> post a bounty for emule client :)</p>
15:28 < jrandom> (but if you've got money burning a hole in your poket, it'd be great to snag a mac mini for osx gui testing ;)</p>
15:28 < jrandom> lol zzz</p>
15:28 < JosephLeBlanc> Not everyone is a lesbian snob who has a 40 thousand dollar student loan that needs paying off</p>
15:28 <+zzz> keep up the good work jr</p>
15:28 < jrandom> just in case that wasn't closedshop: i appreciate the interest and support, but i won't have any time to work on a file sharing app in the future</p>
15:29 < JosephLeBlanc> Can you implement modulus' lovesoc</p>
15:29 < JosephLeBlanc> ?</p>
15:29 < jrandom> thanks zzz, you as well (your services and code definitely help tons!)</p>
15:29 <+zzz> get the baf lol</p>
15:30 * jrandom runs to the corner</p>
15:30 * jrandom winds up</p>
15:30 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

58
i2p2www/meetings/192.log Normal file
View File

@@ -0,0 +1,58 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 192{% endblock %}
{% block content %}<h3>I2P dev meeting, December 5, 2006</h3>
<div class="irclog">
15:00 < jrandom> 0) hi</p>
15:00 < jrandom> 1) Net status</p>
15:00 < jrandom> 2) Syndie dev status</p>
15:00 < jrandom> 3) iToopie</p>
15:00 < jrandom> 4) ???</p>
15:00 < jrandom> 0) hi</p>
15:00 * jrandom waves</p>
15:00 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-December/001321.html</p>
15:01 < jrandom> (almost two hours before the meeting, too! :)</p>
15:01 < jrandom> ok, lets jump on in to 1) net status</p>
15:01 < jrandom> things are going pretty well, no big change on this front</p>
15:02 * jrandom has been connected to irc here for 20 days now, too (a record, i believe)</p>
15:03 < jrandom> not much more to add on this front though atm</p>
15:03 < jrandom> so, if there's nothing else on it, lets jump forward to 2) syndie dev status</p>
15:04 < jrandom> progress continues here, with more bits and bobs becoming workable</p>
15:04 < jrandom> its still quite rough though... "utilitarian", but graphically utilitarian ;)</p>
15:05 < jrandom> the alpha isn't imminent though, but i hope to have it ready soon</p>
15:07 < jrandom> in any case, more info as it comes about :)</p>
15:08 < jrandom> ok, lets jump briefly on over to 3) iToopie</p>
15:08 < jrandom> as mentioned in the notes, Thanks y'all! :)</p>
15:08 < jrandom> ok, continuing on in rapid fire to 4) ???</p>
15:08 < jrandom> anyone have anything they'd like to bring up for the meeting?</p>
15:10 < jrandom> (its probably been a year or two since our last 10 minute meeting, but perhaps that's for the best)</p>
15:10 <+fox> &lt;Ch0Hag&gt; Hey wow. Totally by accident I am actually present for an I2P meeting.</p>
15:11 <+fox> &lt;Ch0Hag&gt; Hi mum!</p>
15:11 <+fox> &lt;Ch0Hag&gt; This is going in the logs right? :)</p>
15:11 < jrandom> heh yeah ch0 ;)</p>
15:12 <+fox> &lt;Ch0Hag&gt; Because of course my mum reads I2P meeting logs...</p>
15:12 < burl> i was going to ask about the licensing but i just read the answer on www.i2p (why not gpl?)</p>
15:13 < jrandom> gpl kills babies</p>
15:13 * jrandom ducks</p>
15:13 < burl> i have to print them out for my mum. she's not very good with computers</p>
15:13 < jrandom> heheh</p>
15:14 < burl> i've been reading all about the free software movement recently. ethically it seems bang on</p>
15:14 < burl> closed source is evil :)</p>
15:14 < jrandom> good, evil, they're all the same. what matters here is that closed source is /insecure/ ;)</p>
15:15 < jrandom> (syndie license summary @ http://syndie.i2p.net/faq.html#license less religious license info for i2p @ http://www.i2p.net/licenses )</p>
15:15 < burl> yeah, that did cross my mind too. if some evil company stole syndie and made a "better" closed version, who'd trust it?</p>
15:16 < jrandom> you can't steal whats free</p>
15:16 < burl> yeah, but i mean made changes to the source and didn't let you see them</p>
15:17 < jrandom> changes to /your copy/ of the source. my copy of the source is still exactly as it was before, and still exactly as free ;)</p>
15:17 < jrandom> but, yeah, i understand. disagree, but understand</p>
15:18 < jrandom> all things considered, open source&gt;&gt;closed source, and while gpl has some nasty limits, its sufficient for many things, and open enough for security</p>
15:18 < burl> because no-one would trust the closed version so it could never take over in popularity</p>
15:20 < jrandom> aye</p>
15:21 < jrandom> licence rants are always good ways to fill up 10m of meeting logs ;)</p>
15:21 < jrandom> ok, anyone have anything else for the meeting?</p>
15:23 <+fox> &lt;Ch0Hag&gt; Well if you need more meeting time - why Java?</p>
15:23 <+fox> &lt;Ch0Hag&gt; I mean ewww!</p>
15:23 < jrandom> !thwap</p>
15:24 * jrandom winds up</p>
15:24 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

26
i2p2www/meetings/193.log Normal file
View File

@@ -0,0 +1,26 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 193{% endblock %}
{% block content %}<h3>I2P dev meeting, December 12, 2006</h3>
<div class="irclog">
15:03 < jrandom> 0) hi</p>
15:03 < jrandom> 1) Net status</p>
15:03 < jrandom> 2) Syndie dev status</p>
15:04 < jrandom> 3) ???</p>
15:04 < jrandom> 0) hi</p>
15:04 * jrandom waves</p>
15:04 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-December/001322.html</p>
15:04 < jrandom> lets jump on in to 1) net status</p>
15:05 < jrandom> no real changes here, though its good to note that stability seems quite sufficient on irc, even with long tunnels</p>
15:05 < jrandom> though, of course, thats not necessarily the case for eveyone, and can vary substantially</p>
15:05 < jrandom> but, 'tis nice to see anyway</p>
15:05 < jrandom> ok, anyone have anything to bring up for 1) net status?</p>
15:07 < jrandom> if not, lets swing over to 2) syndie dev status</p>
15:07 < jrandom> lots going on here, though summarized in the mailing list post</p>
15:08 < jrandom> the new http server isn't in use on the syndie.i2p.net/archive/ archive yet, so you cant push up new messages atm, though you can pull (or, of course, run your own 'httpserv' and let people post)</p>
15:11 < jrandom> ok, anyone have anything to discuss for 2) syndie dev status?</p>
15:11 < jrandom> if not, lets shimmy over to 3) ???</p>
15:12 < jrandom> anyone have anything else to bring up for the meeting?</p>
15:16 < jrandom> if not</p>
15:16 * jrandom winds up</p>
15:16 * jrandom *baf*s the meeting closed</p>
{% endblock %}

160
i2p2www/meetings/194.log Normal file
View File

@@ -0,0 +1,160 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 194{% endblock %}
{% block content %}<h3>I2P dev meeting, December 26, 2006</h3>
<div class="irclog">
15:02 < jrandom> 0) hi</p>
15:02 < jrandom> 1) Net status</p>
15:02 < jrandom> 2) Syndie 1.000a</p>
15:02 < jrandom> 3) ???</p>
15:02 < jrandom> 0) hi</p>
15:02 * jrandom waves</p>
15:02 < jrandom> weekly status notes up at http://dev.i2p.net/pipermail/i2p/2006-December/001324.html</p>
15:03 < jrandom> lets jump on in to 1) net status</p>
15:03 < Complication2> Oh, I entirely forgot it's a Tuesday</p>
15:03 < jrandom> things are going pretty well, as mentioned, though my router finally had a restart after a 45 day uptime</p>
15:04 < jrandom> (but frankly, i'd be quite happy if we could consistently get 1+ month uptimes :)</p>
15:04 < Complication2> Net status is a bit flakier than before for me, but that's because one of my I2P routers is having a recurring (once about 10 days) problem</p>
15:04 < Complication2> Other router is capable of pulling one-month uptimes, but it's not a very high-traffic router</p>
15:05 < Complication2> Rather modest, in fact</p>
15:05 < jrandom> stats.i2p has been showing a slightly reduced build success rate in the past week, but that may just be seasonal</p>
15:07 <+fox> &lt;hottuna&gt; Ive been getting some weird wrapper log messages</p>
15:07 <+fox> &lt;hottuna&gt; INFO | jvm 1 | 2006/12/26 01:00:00 | 2006-dec-26 00:00:00 org.mortbay.util.RolloverFileOutputStream removeOldFiles</p>
15:07 <+fox> &lt;hottuna&gt; INFO | jvm 1 | 2006/12/26 01:00:00 | INFO: Log age 2006_09_26.request.log</p>
15:07 <+fox> &lt;hottuna&gt; INFO | jvm 1 | 2006/12/26 01:00:00 | 2006-dec-26 00:00:00 org.mortbay.util.RolloverFileOutputStream removeOldFiles</p>
15:07 < jrandom> irc is still doing pretty well though, even with 3 hop tunnels</p>
15:07 < jrandom> oh interesting hottuna, sounds like some verbose commons-logging stuff</p>
15:08 < jrandom> (jetty uses their own logger, not ours)</p>
15:08 <+fox> &lt;hottuna&gt; nothing to worry about then .. </p>
15:08 <+fox> &lt;hottuna&gt; but still ahven been running my router due to BW starvation</p>
15:09 < jrandom> starvation being "not enough bw for i2p", or "i2p using too much bw"?</p>
15:11 <+fox> &lt;hottuna&gt; Well, both but since Im running i2p to donate bw the first alternative fits me best</p>
15:11 < jrandom> ah heh, ok</p>
15:11 <+fox> &lt;hottuna&gt; I just started syndie for the first time and Im feling a bit overwhelmed, dont really know where to begin</p>
15:11 <+fox> &lt;hottuna&gt; nice touch with adding the standard archive though</p>
15:13 < jrandom> thanks :) there's lots that we need to do to reduce the overwhelmed sensation, though lets do that in our jump to 2) Syndie 1.000a :)</p>
15:13 < jrandom> 1.000a is out, download and enjoy!</p>
15:14 < jrandom> out of box experience should basically be: install, start, "add the standard archive", tell Syndie to sync with the standard archive "now" (then hit save), and it'll start pulling messages</p>
15:15 < jrandom> it'll add a line to that table below the save button, one per message and one per forum - right clicking on messages & forums brings them up, or you can browse via the Forum-&gt;Read all menu</p>
15:15 < bar> congratulations on the syndie alpha release, you've been working long and hard on this. respect.</p>
15:16 < Complication2> Same here. Impressive database and quite promising interface. :)</p>
15:16 <+fox> &lt;hottuna&gt; Im using syndie right now and reading the epic syndie and i2p direction post</p>
15:16 < gloin> btw, build.xml contains a hardcoded value: build.xml: &lt;property name="swt.win32" value="../swt-I20061214-1445-win32-win32-x86/swt.jar" /&gt;</p>
15:16 < jrandom> thanks, there's lots to do to get syndie where it needs to be, but its a start</p>
15:17 <+fox> &lt;hottuna&gt; there is much work to be done on the usability front but still you have come a long way</p>
15:17 < jrandom> gloin: aye, 3 of 'em (swt.win32, swt.osx, and swt.linux32) - they're only used for "ant dist"</p>
15:18 < Complication2> does "ant" default to "ant clean jar", by the way?</p>
15:18 * Complication2 checks</p>
15:18 < jrandom> hottuna: thats where you (and y'all :) come in - my head is deep in the innards of syndie, so its often hard for me to get the right perspective for making syndie more usable</p>
15:19 < jrandom> i need your opinions, feedback, and suggestions to improve things</p>
15:19 < Complication2> Aha, dependency check and jar</p>
15:19 < Complication2> (without the cleanup part)</p>
15:19 < jrandom> right Complication2, no 'clean' by default</p>
15:21 < gloin> does "ant dist" build versions for linux, win32 and so on?</p>
15:21 < jrandom> gloin: yeah, building installers, .exe files, etc</p>
15:22 < jrandom> if you just want to build and run syndie for your own use, "ant jar" and copy the lib/syndie.jar to your syndie install, or "ant run" to launch it in place</p>
15:23 < Complication2> darn, I overlooked the "run" target then</p>
15:23 < jrandom> (specifying the necessary -Dswt.dir=/blah flags, or placing them in the (new) file nbproject/private/private.properties as swt.dir=/blah/)</p>
15:23 < Complication2> Cooked up a run.sh :D</p>
15:24 < Complication2> two-liner, though, so nothing time-consuming</p>
15:24 < jrandom> that works too :)</p>
15:24 < Complication2> Yep, "ant run" worked nicely</p>
15:24 < gloin> ant run seem to work, the install linux32.exe complains about missing swt.</p>
15:24 < Complication2> Just tested</p>
15:26 < jrandom> hmm gloin, and swt.jar exists in the installed syndie lib dir?</p>
15:27 < gloin> yes.</p>
15:28 < jrandom> and you're running "java -jar /some/path/to/that/syndie/bin/syndie.exe"? or do you mean the linux installer?</p>
15:29 < gloin> the installer was fine. it created the syndie-1.000a directory.</p>
15:31 < gloin> Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-pi-gtk-3235 in java.library.path</p>
15:33 < Complication2> One little question (I'm testing out the Linux binary)</p>
15:33 < jrandom> hmm, did it create the libswt-pi-gtk-3235.so in /tmp/ gloin?</p>
15:33 < Complication2> Where to obtain the public key "393F2DF9"?</p>
15:33 < jrandom> thats a good question... </p>
15:34 < gloin> who? when?</p>
15:34 < gloin> at the moment, theres no libswt-pi-gtk-3235.so in /tmp/</p>
15:35 < jrandom> gloin: the new swt (3.3M4) shipped with syndie extracts the native libs to /tmp/ when it can't find them</p>
15:36 < jrandom> gloin: can you run (cd ~/syndie-1.000a/ ; java -cp lib/syndie.jar:lib/swt.jar:lib/hsqldb.jar syndie.gui.SWTUI ) and see if that finds them?</p>
15:36 < jrandom> Complication2: it'll be up on the various keyservers and the website after the meeting</p>
15:37 < Complication2> Thanks :)</p>
15:37 < jrandom> (its on my keyrings which aren't accessible from my windows box)</p>
15:37 < Complication2> Meanwhile, I found out using more conventional means that my download of the binary *did* abort early</p>
15:37 * Complication2 fetches the end again</p>
15:38 < gloin> no. Maybe I rebuild the the installer</p>
15:39 < jrandom> gloin: could you check the swt.jar to make sure it contains the libswt-pi-gtk-3235.so (jar tvf lib/swt.jar)?</p>
15:40 < jrandom> in any case, we'll keep on debugging as things come up</p>
15:41 < gloin> it's not in it.</p>
15:41 < jrandom> thats about it for syndie 1.000a - there will of course be updates over time, and they'll be announced in meetings or mails</p>
15:42 < jrandom> (there are much smaller downloads for upgrading syndie than the full 4-5+MB ones - see syndie.i2p.net/download.html)</p>
15:42 <+fox> &lt;hottuna&gt; whats is the i2p syndie archives url on the i2p network ?</p>
15:43 < jrandom> gloin: could you priv msg me the jar tvf output?</p>
15:43 < jrandom> hottuna: http://archive.syndie.i2p/</p>
15:43 <+fox> &lt;hottuna&gt; thank you</p>
15:45 < jrandom> (note that archive.syndie.i2p / syndie.i2p.net:8080 are just instances of syndie with the built-in HTTP server running)</p>
15:45 <+fox> &lt;hottuna&gt; oh :) wicked :)</p>
15:45 <+fox> &lt;hottuna&gt; oh btw the syndie clock doesnt match the clock on my system</p>
15:46 < jrandom> so, anyone can run their own syndie archive and let people sync off 'em - just give them a link to your archive (which you can do via irc/html/etc, or in syndie itself with an 'archive link'/reference)</p>
15:46 < jrandom> syndie clock?</p>
15:46 <+fox> &lt;hottuna&gt; or the time stamps on messages in syndie</p>
15:47 <+fox> &lt;hottuna&gt; wait a second. . now they seem to be right..</p>
15:47 <+fox> &lt;hottuna&gt; a restart later</p>
15:52 < gloin> how do I build a headless archive server? I assume that the import.cgi is not 'supported' anymore?</p>
15:53 < jrandom> right, import.cgi is incompatible with the latest - you can run a headless server with a normal syndie install by running syndie "--cli", causing it to run the text engine. </p>
15:55 < jrandom> the integrated http server can be run from the text engine via the 'httpserv' command (http://syndie.i2p.net/manual.html#general_httpserv )</p>
15:55 < gloin> thanks a lot.</p>
15:56 < jrandom> if you're going to be firing up your archive again, i should be thanking you :)</p>
15:57 < gloin> puh.. even with a gui, it looks complicated :)</p>
15:58 < jrandom> aye, y'all've got your work cut out for you - help make it usable and useful :)</p>
15:59 < jrandom> we'll have lots more to cover as people start kicking the tires and issues start coming up, but for the time being, feel free to dig in, post away, and see whats going on</p>
15:59 < jrandom> shimmying on over to 3) ???, anyone have anything else to bring up for the meeting?</p>
16:00 < Complication2> Tested the Linux binary installer, runs nicely</p>
16:00 < Complication2> It's only curious that when it tried creating a shortcut in the KDE menu, the shortcut ended up in the group "Development"</p>
16:00 < Complication2> Along with NetBeans and stuff</p>
16:01 < Complication2> I might be mistaken, but I think I recall it writing that it was going to try creating a group called Syndie...</p>
16:01 < jrandom> ah, yeah. izpack and the java packagers/installers are still working through the kde integration</p>
16:02 < Complication2> Anyway, small detail</p>
16:02 < Complication2> But wanted to mention just in case</p>
16:02 < jrandom> it /should/ create a Syndie group, but as you can see, the kde menu doesn't have per-app folders (it has categories of apps, and then per-app folders)</p>
16:02 < jrandom> hopefully to be fixed when izpack fixes it (its on their radar)</p>
16:03 < Complication2> Right</p>
16:03 < Complication2> Either way, the shortcut appeared, and the uninstaller shortcut appeared too</p>
16:03 < jrandom> wewt</p>
16:03 < Complication2> And the uninstalled worked nicely too (used it too since I typically compile from sources)</p>
16:03 < Complication2> =uninstaller</p>
16:04 < bar> i have two questions, slightly related to each other</p>
16:04 < bar> 1. any plans yet on when to nuke the old syndie?</p>
16:04 < bar> 2. could we have an i2p gateway, syndie.i2p, to syndie.i2p.net, or would that perhaps collide with the old syndie infrastructure?</p>
16:05 < Complication2> On 2, I think it currently would collide</p>
16:06 < jrandom> hmm, i actually haven't thought about that much. i'm tempted to say "nuke it, move everyone to the new syndie now now now" :)</p>
16:07 < Complication2> ...going to "http://archive.syndie.i2p" through "localhost:4444"</p>
16:07 < bar> the reason i'm asking is, it's sometimes a bit of a pain having to use squid.i2p to access the syndie web pages</p>
16:07 < jrandom> ah, understood. ok, i can redirect syndie.i2p to point to syndie.i2p.net, and old-syndie users can still use syndiemedia.i2p</p>
16:09 < bar> loverly :)</p>
16:09 < Complication2> oh, you meant the web pages</p>
16:10 < Complication2> I thought you meant the archive :)</p>
16:10 < bar> correct Complication2, sorry for not being clear on that</p>
16:10 < gloin> the own forum is the own identity?</p>
16:11 < Complication2> There's definitely a default identity / pseudonym created in a new Syndie instance</p>
16:11 < Complication2> I'm not sure if it auto-creates a forum</p>
16:11 < jrandom> gloin: every identity has a forum (and every forum is owned by an identity)</p>
16:12 < jrandom> a forum, in syndie, is just a public key</p>
16:12 < jrandom> (as is an author)</p>
16:12 < Complication2> I've forgotten how I went about doing it, and it was in October with the text interface anyway, I think :)</p>
16:12 < jrandom> ((in the database and code, they're both called 'channels', but the ui talks about forums and authors/nyms))</p>
16:13 < bar> on the topic of closing down the old syndie, may i suggest something along the lines of "keeping it online for another month but closing the archive for new posts, along with leaving an informative note"</p>
16:14 < gloin> the gui let me create forums only. Does that means, when I a want that you can post in my forum I authorize the jrandom forum and not the jrandom person?</p>
16:15 < Complication2> Or perhaps even leaving it open for a short while after posting the note, so if someone desperately needs it at this stage (gasp!) they can exchange some data for a short while still</p>
16:15 < jrandom> gloin: forums and identities are the same thing - when you create a new forum, you craete a new ientity (and to authorize jrandom the person to post in your forum, authorize jrandom's forum)</p>
16:15 < jrandom> seems reasonable Complication2 & bar</p>
16:17 < jrandom> gloin: this stuff is definitely not-obvious, and we need to do a lot of work on making it easier</p>
16:21 < Complication2> Oops, I've not noticed multiple suggestions for I2Phex tuning by striker on the old Syndie</p>
16:21 * Complication2 makes local copies</p>
16:23 < jrandom> :) the old syndie will still remain accessible at syndiemedia.i2p/ and syndie.i2p.net:8000/ </p>
16:23 < jrandom> ok, anyone have anything else for the meeting?</p>
16:25 < gloin> In the forum configuration I can set the privay level (all/auth/passphrase). But with each post I can set it, too. Which counts?</p>
16:27 < jrandom> both count, though for the time being, i'd recommend keeping the forum privacy as 'public' (since i havent written up the gui for passphrase protected forums yet, only passphrase protected messages)</p>
16:27 < jrandom> the forum privacy covers the forum's metadata (links to other sites, bundled keys, etc), while individual messages have their own policy</p>
16:33 < jrandom> (syndie.i2p --&gt; syndie.i2p.net as of now, syndiemedia.i2p still points to syndie.i2p.net:8000/)</p>
16:33 < jrandom> ok, if there isn't anything else for the meeting</p>
16:33 * jrandom winds up</p>
16:33 * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}

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