I2P dev meeting, December 20, 2005

Quick recap

  • Present:

bar, Complication, dust, jrandom, legion, polecat, tealc_, tethra, zzz,

تمام وقایع IRC

15:20 < jrandom> 0) hi
15:20 < jrandom> 1) Net status
15:20 < jrandom> 2) I2PSnark updates
15:20 < jrandom> 3) Syndie blog UI
15:20 < jrandom> 4) ???
15:20 < jrandom> 0) hi
15:20  * jrandom waves
15:20 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2005-December/001240.html
15:22 < jrandom> ok, jumping on in to 1) Net status
15:22 < jrandom> I don't have much to add beyond whats in the status notes.
15:22 <+Complication> If it weren't for the occasional OOM's, I'd dare call it good
15:22 < jrandom> the load testing is looking quite promising, suggesting that we have a lot of room to improve performance
15:23 <+Complication> And I guess the OOM
15:23 < jrandom> heh, i2psnark related OOMs?  or from before that?
15:23 <+Complication> 's contribute to flakyness, when either i2p-bt, i2psnark, or i2p-rufus  instances do... things.
15:24 < zzz> my theory is that increased torrent traffic is somewhat hurting IRC reliability
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)
15:24 < jrandom> hmm, I'm not sure, as the irc status was similar to before the latest snark updates
15:25 <+Complication> Bandwidth has been solid, part. tunnels solid too... just crashing now and then
15:26 < zzz> In any case I'm optimistic the tunnel build fixes coming in will improve people's IRC experience
15:26 <+Complication> For known reasons, which hopefully go away when their time comes :)
15:26 < jrandom> aye, I think so too zzz, so we'll probably have a release in the next day or so
15:26 <+legion> Well irc might just be too sensitive, maybe just using something like jabber would be better?
15:26 < zzz> especially for people on slower machines and/or connections
15:27 < jrandom> jabber would not change things
15:27 <+Complication> Especially with tunnel redundancy at 2
15:28 <+bar> i'd say irc is an excellent crap-o-meter for determining the network weather
15:28 <+legion> Yeah, the wind just blows a little and irc craps out
15:28 <+bar> exactly :)
15:28 <+Complication> I notice that after the shitlisting fix, "Recent" tends to always exceed "Known"
15:29 <+Complication> Would this be because "Known" doesn't include shitlisted peers, while "Recent" does?
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)
15:30 < jrandom> hmm, that makes sense Complication 
15:30 <+Complication> (I'm not sure if it does, just guessing)
15:30 < jrandom> (as shitlisted peers are dropped from the netDb, but their profiles are not removed)
15:32 <+Complication> Then the indicators seem OK (just wanted to ask in case they wouldn't)
15:33 < jrandom> ok, anything else on 1) Net status?
15:33 < jrandom> if not, lets move on over to 2) I2PSnark updates
15:33 < tealc_>  what sort of updates are available?
15:34 < jrandom> see http://dev.i2p.net/pipermail/i2p/2005-December/001240.html for a brief listing ;)
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
15:35 < tealc_> i'm running of the latest cvs builds and i2psnark is causing a lot of memory heap errors or whatever
15:35 <+Complication> ...and it also handles Azureus-created torrents with odd meta-tags.
15:35 <+Complication> Which it previously got stuck on.
15:35 < jrandom> ah, yeah, there are still some things I'm debugging in there tealc_ 
15:35 < jrandom> (as mentioned in the weekly status notes ;)
15:35 < jrandom> ah right Complication 
15:36 < jrandom> oh, also, the Azureus folks have fixed a bug in their tracker that would keep I2PSnark from using it
15:36 < jrandom> (so people running azureus trackers prior to B16 should upgrade at their earliest convenience)
15:37 <+bar> i'd like to have the possibility to easily disable the i2psnark autostart (for low bw scenarios, etc.)
15:38 < jrandom> that should be easy enough to add in
15:38 <+bar> sounds great
15:39 < jrandom> ok, anything else on 2) I2PSnark updates?  
15:40 < jrandom> if not, lets move on to 3) Syndie blog UI
15:40 < zzz> two thumbs up on the new i2psnark - good job
15:41 < jrandom> gracias, mjw did the hard work, making snark so easy to extend
15:41 < jrandom> ok, as mentioned in the status notes, syndie now has a new blog UI
15:42 < jrandom> I think it'll offer a balance between whitelists and blacklists, dealing with the different spam issues available to people
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
15:43 <+legion> Is spam really going to become much of a problem anytime soon?
15:44 <+Complication> legion: as someone was kindly willing to demonstrate, it could be
15:44 < jrandom> nah, blacklists take care of authors who flood, and whitelists take care of spammers who create lots of authors
15:44 < dust> (anonymity brings out the worst in a some people)
15:44 < jrandom> (so spamming is not a problem)
15:45 <+Complication> (Although I think the fellow was regenerating keys to avoid perma-blacklisting, which *is* somewhat of a slow-down.)
15:45 <+Complication> Although not a big slow-down, and thus I whole-heartedly agree that whitelists are good too. :)
15:46 <+bar> perhaps some hashcash solution could be feasible down the road, if necessary
15:46 < jrandom> if necessary, but I don't see why it would be
15:46 <+bar> agree, right now, i don't either
15:46 <+Complication> bar: like "don't show unless they've bothered to crunch some numbers"?
15:47 <+bar> yes, something along that line
15:47 <+Complication> Sounds possible, even if probably needless.
15:47 <+bar> probably so.
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
15:47 <+Complication> Or more like, hopefully needless.
15:48 <+Complication> Might be good to consider if Syndie can accommodate such functionality, should need ever arise.
15:49 < jrandom> aye, it can, with headers in the blog post or in the blog's own metainfo
15:49 < jrandom> er, metadata (damn you bt!)
15:51 < jrandom> ok, if there's nothing else on 3) Syndie, lets jump on to 4) ???
15:51 < jrandom> anyone have anything else they want to bring up for the meeting?
15:51 <+legion> yes a couple things
15:52 <+legion> first clunk
15:52 < jrandom> cool, yeah clunk sounds interesting
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.
15:53 <+legion> So far just the client is broken, the rest including the server compiles and seems to work
15:53 < jrandom> neat
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
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.
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.
15:57 < tethra> 20:34:37 <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 <--- 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.)
15:57 < tethra> </$0.02>
15:58 <+polecat> That would be a primitive example of my trust network idea, with a heuristic of 100% trust transfer, yes.
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?
15:59 < jrandom> aye, there is a lot of room for integration of trust metrics into syndie
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.
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.
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
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 or localhost
16:06 <+legion> So I would recommend only using known clients which don't leak, such as jeti.
16:07 < zzz> could you add a verified-doesn't-leak column to your client chart?
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)
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.
16:09 < jrandom> that the developer said it may be certain, but what the developer understands about anonymity is another question ;)
16:09 <+legion> Yeah zzz I could add another such column
16:09 < jrandom> I don't doubt the possibility that jeti behaves properly, but we need to know what that means
16:10 < zzz> seems like non-leakage can only be verified by protocol tracing
16:10 < zzz> not by looking at source or asking developer
16:12 < jrandom> ok, does anyone have anything else for the meeting?
16:12 <+bar> just a reminder not to forget amd64 jbigi
16:13 <+bar> (but i bet it's on your todo list)
16:13 < jrandom> aye :)
16:13 < jrandom> (win amd64, that is, linux amd64 is already working)
16:13 < jrandom> but, if there's nothing else...
16:14  * jrandom winds up
16:14 <+bar> yes, win amd64.
16:14  * jrandom *baf*s the meeting closed