623 lines
47 KiB
HTML
623 lines
47 KiB
HTML
{% extends "_layout.html" %}
|
|
{% block title %}I2P Development Meeting 65{% endblock %}
|
|
{% block content %}<h3>Tuesday, November 18, 2003 21:02:50 UTC</h3>
|
|
<div class="irclog">
|
|
<p>[22:02] <jrand0m> agenda: </p>
|
|
<p>[22:02] <jrand0m> 0) welcome </p>
|
|
<p>[22:02] <jrand0m> 1) i2p dev status </p>
|
|
<p>[22:02] <jrand0m> - 0.2.1.1 is out (peer and tunnel updating and testing, tuning enhancements, tunnel throttling, a DoS defense) </p>
|
|
<p>[22:02] <jrand0m> - don't use bw limiting (still some debugging) </p>
|
|
<p>[22:02] <jrand0m> - keep your clocks generally correct (30 minute fudge factor) [used for lease expirations and garlics] </p>
|
|
<p>[22:02] <jrand0m> 2) kademlia, 0.3, and idn </p>
|
|
<p>[22:02] <jrand0m> 3) roadmap revise (0.2.3 --> 0.4, 0.2.2 --> 0.3.1)? </p>
|
|
<p>[22:02] <jrand0m> 4) app status [ppp2p, i2ptunnel, im, ns, squid] </p>
|
|
<p>[22:02] <duck> 5) why does jrand0m drink cheap local beer?</p>
|
|
<p>[22:02] <jrand0m> 5) comments / questions / etc </p>
|
|
<p>[22:02] <jrand0m> heh </p>
|
|
<p>[22:02] <jrand0m> so yeah, basically that fits under 5 :) </p>
|
|
<p>[22:02] <mihi_> double 5 ;)</p>
|
|
<p>[22:03] <mihi_> oops...</p>
|
|
<p>[22:03] <jrand0m> 0) welcome </p>
|
|
<p>[22:03] * mihi_ did not look 2 the left column</p>
|
|
<p>[22:03] <jrand0m> hi. 65th meeting I suppose. </p>
|
|
<p>[22:03] <jrand0m> hehe </p>
|
|
<p>[22:03] <jrand0m> 1) that code stuff </p>
|
|
<p>[22:04] <jrand0m> 0.2.1.1 came out last night </p>
|
|
<p>[22:04] <jrand0m> lots of goodness in there. </p>
|
|
<p>[22:04] * mihi tests it atm.</p>
|
|
<p>[22:04] <jrand0m> tunnels are tested and fail fast, penalizing all participants so they won't likely get into the rebuild </p>
|
|
<p>[22:05] <jrand0m> messages in i2ptunnel are also throttled to max 64k size (larger messages caused badness) </p>
|
|
<p>[22:05] <jrand0m> there are some bugs being worked out with the bw limiting code, so make sure your bw limits in router.config are negative values </p>
|
|
<p>[22:06] <jrand0m> (i2p doesn't have enough traffic on it to cause real load atm anyway) </p>
|
|
<p>[22:06] <jrand0m> (but bw limiting will be unit tested and fixed for 0.2.1.2) </p>
|
|
<p>[22:07] <jrand0m> also, please try to keep your clocks close to correct. it sucks that we have to need that, but right now we do. </p>
|
|
<p>[22:07] <jrand0m> we may be able to work out a way to not require semi-sync'ed clocks, but its delicate. </p>
|
|
<p>[22:07] <jrand0m> 2) fun stuff </p>
|
|
<p>[22:08] <jrand0m> a lot of the bugs being worked out in the last few releases are related to the crappy kludge of a BroadcastNetworkDB. </p>
|
|
<p>[22:08] <jrand0m> since its planned for replacement in 0.3, might as well at least mention what its being replaced with </p>
|
|
<p>[22:09] <jrand0m> kademlia is a structured distributed hash table (DHT) that lets us insert and fetch in under O(log(N)) time, guaranteed </p>
|
|
<p>[22:09] <jrand0m> [with one small caveat thats still being worked out] </p>
|
|
<p>[22:10] <jrand0m> that kademlia code needs to get written for 0.3 so we can do insert and fetch of RouterInfo and LeaseSet structures. </p>
|
|
<p>[22:10] <jrand0m> however, things would be simpler if it were implemented seperately - and hence testable seperately. </p>
|
|
<p>[22:10] <jrand0m> (unit testing == good) </p>
|
|
<p>[22:11] <jrand0m> so, whats a simple way to unit test a dht? to write a simple file store/lookup service on it. </p>
|
|
<p>[22:11] <dm> insert fetch? are we talking about content?</p>
|
|
<p>[22:11] <jrand0m> enter idn: (Link: http://wiki.invisiblenet.net/iip-wiki?I2PIDN)http://wiki.invisiblenet.net/iip-wiki?I2PIDN </p>
|
|
<p>[22:11] <Ophite1> dm: No, only routerinfo and leaseset structures.</p>
|
|
<p>[22:12] <jrand0m> dm> i2p's networkDatabase currently contains only two specialized structures, as ophite said </p>
|
|
<p>[22:12] <dm> okay, thanks.</p>
|
|
<p>[22:12] <Ophite1> may or may not be useful to use it for bootstrapping other protocols too, but it's not anonymous itself. (?)</p>
|
|
<p>[22:12] *** grimps (~grimp@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[22:12] <tusko> one question: which protocol is used now for networkDatabase?</p>
|
|
<p>[22:13] <jrand0m> sorry, phone. </p>
|
|
<p>[22:13] *** Signoff: godmode0 (Ping timeout)</p>
|
|
<p>[22:13] <jrand0m> correct, kademlia is not anonymous, but not non-anonymous either </p>
|
|
<p>[22:13] <Ophite1> modified kademlia will scale. random will not.</p>
|
|
<p>[22:13] <jrand0m> tusko> currently we do a flooded broadcast </p>
|
|
<p>[22:13] <duck> what about kademlia getting splitted?</p>
|
|
<p>[22:13] <dm> no cell phones allowed into meeting.</p>
|
|
<p>[22:13] <duck> <insert zooko comments></p>
|
|
<p>[22:13] <Ophite1> flooded broadcast aka gnutella method definitely won't ;)</p>
|
|
<p>[22:13] <jrand0m> Ophite1> right, kademlia doesn't use random ones :) </p>
|
|
<p>[22:13] <duck> Ophite1: works better as freenet routing :)</p>
|
|
<p>[22:14] <jrand0m> duck> exactly (<jrand0m> [with one small caveat thats still being worked out] ) </p>
|
|
<p>[22:14] <Ophite1> duck: i rest my case... ;)</p>
|
|
<p>[22:14] *** Signoff: mihi (Ping timeout)</p>
|
|
<p>[22:14] <tusko> is kademlia some sort of hypercube?</p>
|
|
<p>[22:14] <Ophite1> no, a circle.</p>
|
|
<p>[22:14] *** Signoff: mihi_ (Ping timeout)</p>
|
|
<p>[22:14] <jrand0m> and/or a xor tree :) </p>
|
|
<p>[22:15] <Ophite1> splits/joins... reshuffle tree? can we take a peek at emule's overnetalike for this? :)</p>
|
|
<p>[22:15] <jrand0m> its a fairly easy protocol, but we can definnitely look around. </p>
|
|
<p>[22:16] <jrand0m> icepick has implemented kademlia in python too, for ent (as kashmir) </p>
|
|
<p>[22:16] *** mihi (~mihi@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[22:16] <Ophite1> consider also malicious nodes deliberately fragmenting the tree.</p>
|
|
<p>[22:16] <jrand0m> absolutely. but its fairly attack resistant </p>
|
|
<p>[22:16] <Ophite1> 256 bit keyspace is more resistant to that though.</p>
|
|
<p>[22:17] <Ophite1> plus would have to make a lot of routeridentity structures = hard.</p>
|
|
<p>[22:17] <tusko> i found interesting the papers of gravepine: (Link: http://grapevine.sourceforge.net/)http://grapevine.sourceforge.net/</p>
|
|
<p>[22:17] <jrand0m> this is also why I want to implement it first as an application, rather than rip out the core of i2p - so we can work out all the messy details first </p>
|
|
<p>[22:17] <Ophite1> so I'm pleased with sec 3 of 0.9 draft.</p>
|
|
<p>[22:17] *** Signoff: nickthief54450 (Excess Flood)</p>
|
|
<p>[22:18] *** nickthief54450 (~chatzilla@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[22:18] <tusko> look to (Link: http://grapevine.sourceforge.net/tech-overview.php)http://grapevine.sourceforge.net/tech-overview.php</p>
|
|
<p>[22:18] <Ophite1> though I might point out that if message 0, DatabasePing, is inplemented, you might want to include a hashcash in it.</p>
|
|
<p>[22:18] <jrand0m> interesting tusko, I think their economic model might require some revision, as with their sybyl defenses </p>
|
|
<p>[22:19] <Ophite1> (you may already; haven't ready that part)</p>
|
|
<p>[22:19] <jrand0m> absolutely Ophite1. I was actually thinking about putting hashcash certs into all of the messages (DatabaseLookup included) </p>
|
|
<p>[22:20] <Ophite1> good idea. though, be careful of performance and tuning vs. dos defense there, and you might want to run hashcash calc in a separate, lower-priority thread?</p>
|
|
<p>[22:21] <jrand0m> well, hashcash verification should be near instantaneous </p>
|
|
<p>[22:21] <jrand0m> and hashcash generation shouldn't be able to be precompiled </p>
|
|
<p>[22:21] <jrand0m> er, precomputed </p>
|
|
<p>[22:21] <dm> Ophite1 must be an avatar created by jrand0m so that he can finally talk about I2P with someone who understands wtf he's saying.</p>
|
|
<p>[22:22] <jrand0m> lol </p>
|
|
<p>[22:22] * dm is not fooled.</p>
|
|
<p>[22:22] *** godmode0 (~enter@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[22:22] <Ophite1> one way of preventing that is to use derivatives of session keys as part of the hashcash..</p>
|
|
<p>[22:22] <jrand0m> right. and/or put in a nonce and the date </p>
|
|
<p>[22:22] <Ophite1> date leads to those troublesome timing problems though. that could be a real issue.</p>
|
|
<p>[22:22] <Ophite1> unless you feel like rewriting ntp as well ;-)</p>
|
|
<p>[22:22] *** Signoff: mihi (Ping timeout)</p>
|
|
<p>[22:23] <jrand0m> heh </p>
|
|
<p>[22:23] <jrand0m> well, we've already run into that a little bit </p>
|
|
<p>[22:23] <jrand0m> (hence the 30 minute fudge factor) </p>
|
|
<p>[22:23] <jrand0m> a session hash may be workable though. good idea. </p>
|
|
<p>[22:24] <Ophite1> and no, i'm not jrand0m's clone ;)</p>
|
|
<p>[22:24] <jrand0m> ok, so for idn, I'm probably only going to implement the stuff on that I2PIDN wiki page </p>
|
|
<p>[22:25] *** Signoff: dm (Ping timeout)</p>
|
|
<p>[22:25] <jrand0m> what would probably rule would be if someone would take that and run with it - make a real user interface, better get/store apps, fec/ecc/etc. </p>
|
|
<p>[22:25] <jrand0m> also, I had some ideas about a search network built in parallel as well </p>
|
|
<p>[22:26] <jrand0m> but, well, its probably more useful to i2p that I focus my time on the router </p>
|
|
<p>[22:26] <Ophite1> it runs on top of i2p?</p>
|
|
<p>[22:26] <jrand0m> (making it functional, scalable, and secure) </p>
|
|
<p>[22:26] <jrand0m> yes </p>
|
|
<p>[22:26] <jrand0m> i2p lets idn be anonymous </p>
|
|
<p>[22:27] <Ophite1> what were your search network ideas?</p>
|
|
<p>[22:27] <jrand0m> note: its not written yet, but its looking like its #2 on my task list </p>
|
|
<p>[22:27] <Ophite1> can another dht be built through tunnels?</p>
|
|
<p>[22:27] *** mihi (~mihi@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[22:27] <jrand0m> basically a distributed replicated db, with hashcash inserts and syncs, where people store idn keys along side metadata / etc </p>
|
|
<p>[22:27] *** dm (~as@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[22:28] <jrand0m> hmm, yes, certainly. but i2p isn't inherently tunnel based - its message based (i2p is IP, i2ptunnel is TCP) </p>
|
|
<p>[22:28] <Ophite1> if ~all node participate = very useful for "discovering" other protocols.</p>
|
|
<p>[22:28] <jrand0m> definitely </p>
|
|
<p>[22:28] <Ophite1> so, should be standard.</p>
|
|
<p>[22:28] <Ophite1> dhcp/zeroconf for the i2p? :)</p>
|
|
<p>[22:28] <jrand0m> idn would be a very good app to bundle with i2p to let people have an 'out of box experience' </p>
|
|
<p>[22:29] <Ophite1> If it's meant to be a fully featured communication/file transfer/storage application, I'd like to propose the name "Darknet".</p>
|
|
<p>[22:29] <jrand0m> :) </p>
|
|
<p>[22:29] <Ophite1> You, of course, probably already know where that comes from. :)</p>
|
|
<p>[22:30] <dm> Where does it come from?</p>
|
|
<p>[22:30] <Ophite1> MS Research's paper: The Darknet and the Future of Content Distribution.</p>
|
|
<p>[22:30] *** Signoff: godmode0 (Ping timeout)</p>
|
|
<p>[22:30] <TC> link?</p>
|
|
<p>[22:30] *** tonious (~Flag@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[22:30] <jrand0m> well, tim may says he invented the term ~11 years ago ;) </p>
|
|
<p>[22:30] <tusko> where is the I2PIDN wiki page?</p>
|
|
<p>[22:30] <dm> (Link: http://crypto.stanford.edu/DRM2002/darknet5.doc)http://crypto.stanford.edu/DRM2002/darknet5.doc</p>
|
|
<p>[22:30] <jrand0m> tusko> (Link: http://wiki.invisiblenet.net/iip-wiki?I2PIDN)http://wiki.invisiblenet.net/iip-wiki?I2PIDN </p>
|
|
<p>[22:30] <Ophite1> also implies that the network works "in the dark" - noone knows who anyone is ;)</p>
|
|
<p>[22:30] <jrand0m> exactly. </p>
|
|
<p>[22:31] *** mihi_ (~mihi@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[22:31] <jrand0m> well, i2p itself is a darknet in that sense, but its generic messaging - it is the IP layer for such a darknet. </p>
|
|
<p>[22:31] <jrand0m> i2ptunnel is the TCP layer, and idn is NFS :) </p>
|
|
<p>[22:31] <Ophite1> i2p is the protocol that allows such a network to be created from something broadly like overnet.</p>
|
|
<p>[22:31] <Ophite1> speaking of which... is there a way to specify priority in messages?</p>
|
|
<p>[22:32] *** mihi is now known as nickthief76430</p>
|
|
<p>[22:32] *** mihi_ is now known as mihi</p>
|
|
<p>[22:32] <jrand0m> funny that you mention that :) </p>
|
|
<p>[22:32] *** nickthief76430 is now known as mihi_backup</p>
|
|
<p>[22:32] <mihi> oops...</p>
|
|
<p>[22:32] <jrand0m> I was just reading some of the upcoming HotNets2 papers ((Link: http://nms.lcs.mit.edu/HotNets-II/program.html)http://nms.lcs.mit.edu/HotNets-II/program.html) and got inspired for some QoS over i2p mechanisms </p>
|
|
<p>[22:33] <Ophite1> would a bulk/low-latency bit compromise anonymity slightly (intersection attack?) by allowing traffic linkage? well, even if it were sometimes flips?</p>
|
|
<p>[22:33] <Ophite1> ah, well that might work better of course =)</p>
|
|
<p>[22:33] <Ophite1> Don't worry about local plausible denability.</p>
|
|
<p>[22:33] <jrand0m> right, i2p assumes the local machine is trusted </p>
|
|
<p>[22:33] *** Signoff: dm (Ping timeout)</p>
|
|
<p>[22:33] <Ophite1> That is a problem to be solved by Rubberhose/Marutukku and Thermite, not I2P.</p>
|
|
<p>[22:34] <jrand0m> exactly. (otherwise, the software is compromised and it doesn't matter what we do) </p>
|
|
<p>[22:34] * TC hopes his local machine is trusted</p>
|
|
<p>[22:34] <jrand0m> heh </p>
|
|
<p>[22:34] <Ophite1> TC: easy way to find out; make death threats against bush and see if SS agents turn up at your door ;-)</p>
|
|
<p>[22:34] <jrand0m> lol </p>
|
|
<p>[22:34] <TC> done and done</p>
|
|
<p>[22:34] *** Signoff: tonious (Ping timeout)</p>
|
|
<p>[22:34] <jrand0m> hah! </p>
|
|
<p>[22:35] * jrand0m watches my squid proxy get taken down by the fbi</p>
|
|
<p>[22:35] <TC> its a trap!</p>
|
|
<p>[22:35] <jrand0m> get an axe! </p>
|
|
<p>[22:35] <jrand0m> :) </p>
|
|
<p>[22:35] <TC> anybody play uplink?</p>
|
|
<p>[22:35] <Ophite1> completed it. cracked it. released it.</p>
|
|
<p>[22:35] <Ophite1> trained it too ;)</p>
|
|
<p>[22:36] * jrand0m takes that as a "yes"</p>
|
|
<p>[22:36] *** dm (~as@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[22:37] <Ophite1> there may be some dos possibilities in caching, in memory stuff...</p>
|
|
<p>[22:37] <jrand0m> ok, so thats what I'm thinking with idn/kademlia. get idn implemented and working over the 0.2. code, smash it in a bit, then implement 0.3 with that kademlia implementation </p>
|
|
<p>[22:37] <jrand0m> oh certainly. the todo list has 'sync pending and large messages to disk' :) </p>
|
|
<p>[22:37] <dm> shouldn't IDN be implemented after I2P is tested and mature?</p>
|
|
<p>[22:38] <jrand0m> thats one of the problems we ran into testing a large file of TC's eepsite </p>
|
|
<p>[22:38] <Ophite1> dm: not given as it's a testbed for the fancy db.</p>
|
|
<p>[22:38] <jrand0m> dm> I was thinking that too, but I need to implement the kademlia code to get 0.3 ready. basically the kademlia code IS 0.3 </p>
|
|
<p>[22:38] <Ophite1> I do like the hybrid dht nature such a network would provide though.</p>
|
|
<p>[22:39] <dm> aha... </p>
|
|
<p>[22:39] <jrand0m> but if no one wants to toss a normal UI onto it until i2p 1.0, that might be a good idea as well </p>
|
|
<p>[22:39] <Ophite1> dht node discovery + ngr-like routing = scalability capable of handling critical mass</p>
|
|
<p>[22:39] <dm> what happened to that original milestone list. secure-->anonymous-->not harvestable, etc...</p>
|
|
<p>[22:39] <Ophite1> jrand0m: I will refrain from advertising it to pirates until it's ready. that enough?</p>
|
|
<p>[22:39] <jrand0m> well, minus the ngr-like routing :) we tunnel :) </p>
|
|
<p>[22:39] <TC> as long as we keep the cli</p>
|
|
<p>[22:39] <dm> ah scalable was one of the items in that chain.</p>
|
|
<p>[22:39] <jrand0m> dm> 0.3 is necessary for scalable. which is before not harvestable </p>
|
|
<p>[22:39] <jrand0m> thanks Ophite1 :) </p>
|
|
<p>[22:40] <jrand0m> definitely TC. I'll need the cli to test it </p>
|
|
<p>[22:40] <Ophite1> scalability of the actual anonymous stuff is directly related to choices made in the routing for the tunnels, and that's a router implementation thing?</p>
|
|
<p>[22:40] <jrand0m> (and, c'mon, we'll probably do software distribution / releases with idn) </p>
|
|
<p>[22:40] *** godmode0 (~enter@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[22:40] <dm> alrighty... sounds okay then.</p>
|
|
<p>[22:40] <jrand0m> absolutely ophite. </p>
|
|
<p>[22:40] <Ophite1> suggestion: maximum message size?</p>
|
|
<p>[22:40] <jrand0m> thats the Hard problem </p>
|
|
<p>[22:41] <jrand0m> max message size is currently insanely large (4g) but I'm thinking of trimming it to 64k or 128k </p>
|
|
<p>[22:41] <jrand0m> but I don't want to resort to that yet </p>
|
|
<p>[22:41] * Ophite1 goes digging in notes</p>
|
|
<p>[22:41] <Ophite1> BitTorrent/Scone scalability notes indicate 512K.</p>
|
|
<p>[22:42] <jrand0m> heh ok cool. (any refs I can dig into?) </p>
|
|
<p>[22:42] <Ophite1> but, think of it like tcp window size.</p>
|
|
<p>[22:42] <jrand0m> right </p>
|
|
<p>[22:42] <Ophite1> not for scone, sorry - friend's research project.</p>
|
|
<p>[22:42] <jrand0m> coo', no worry </p>
|
|
<p>[22:42] *** Signoff: mihi_backup (Ping timeout)</p>
|
|
<p>[22:42] <Ophite1> fwiw, your kademlia is about as good as his though :)</p>
|
|
<p>[22:42] <jrand0m> hehe </p>
|
|
<p>[22:42] <jrand0m> (well, I haven't implemented it yet ;) </p>
|
|
<p>[22:42] <Ophite1> uh, hers I mean :/</p>
|
|
<p>[22:42] <jrand0m> oh wikked </p>
|
|
<p>[22:43] <dm> boner..</p>
|
|
<p>[22:43] *** mihi_backup (~mihi@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[22:43] <jrand0m> heh </p>
|
|
<p>[22:43] <jrand0m> so, thats 2) kademlia, 0.3, and idn </p>
|
|
<p>[22:43] <Ophite1> she named her toys after puddings. custard, crumble (Waste-like), strudel.. her bittorrent-a-like was the fastest pudding in the world - 'scone ;)</p>
|
|
<p>[22:43] <jrand0m> haha </p>
|
|
<p>[22:45] <Ophite1> she's a math.</p>
|
|
<p>[22:45] <jrand0m> even better </p>
|
|
<p>[22:45] <jrand0m> there's a lot of stats gathering / analysis that will be coming up for advanced peer selection </p>
|
|
<p>[22:45] <Ophite1> but I'll see if I can bounce stuff past her. scalability from i2np 0.9 was from her - she likes it.</p>
|
|
<p>[22:45] <jrand0m> (unfortunately we can't cheat like mnet, mixminion, and tor) </p>
|
|
<p>[22:46] <jrand0m> great to hear </p>
|
|
<p>[22:46] <Ophite1> one comment - dsa?</p>
|
|
<p>[22:46] *** nickthief54450 (~chatzilla@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[22:46] <Ophite1> dsa 1024 bit, as in SHA-1?</p>
|
|
<p>[22:46] <jrand0m> yea </p>
|
|
<p>[22:47] <Ophite1> 'spose it is tried and tested.</p>
|
|
<p>[22:47] <Ophite1> also small.</p>
|
|
<p>[22:47] <jrand0m> right. but I'm not 100% tied to our particular crypto impls </p>
|
|
<p>[22:47] <Ophite1> anyway. to roadmap.</p>
|
|
<p>[22:47] <TC> haha, lets name a windows version 'Microsoft Darknet (r)'</p>
|
|
<p>[22:47] <jrand0m> heh tc </p>
|
|
<p>[22:48] <jrand0m> ok, 3) roadmap revise (0.2.3 --> 0.4, 0.2.2 --> 0.3.1)? </p>
|
|
<p>[22:48] <jrand0m> because of all the bugs I've been running into wrt the broadcast db, I want to escalate the 0.3 (kademlia db) release </p>
|
|
<p>[22:48] <TC> its nice not being limmited by trademarks like a normal open source project</p>
|
|
<p>[22:49] *** tonious (~Flag@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[22:49] <jrand0m> 0.2.3 is restricted routes / trusted peers, and probably not a hard feature requirement that anyone here has. it can be shuffled out to 0.4 without problem, I think </p>
|
|
<p>[22:50] <jrand0m> 0.2.2 is tunnel mods, but I think a lot of the pressure to get that implemented will be eased with the 0.2.1.1 release (which tests and rebuilds tunnels as necessary, rather than waiting 10 minutes) </p>
|
|
<p>[22:50] <Ophite1> trusted peers is an area that needs some revision imho.</p>
|
|
<p>[22:50] <jrand0m> agreed. </p>
|
|
<p>[22:50] *** dm_backup (~as@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[22:50] <Ophite1> only area that doesn't give me warm fuzzies.</p>
|
|
<p>[22:50] <Ophite1> though that may just be the word "trusted". :)</p>
|
|
<p>[22:50] <jrand0m> basically my current thoughts are to publish tunnels to routers </p>
|
|
<p>[22:50] <jrand0m> heh </p>
|
|
<p>[22:51] <jrand0m> (if we publish tunnels to routers, we can get away with untrusted gateways, which drops the 'trusted' from trusted peers) </p>
|
|
<p>[22:51] *** Signoff: dm (Ping timeout)</p>
|
|
<p>[22:51] *** dm_backup is now known as dm</p>
|
|
<p>[22:51] <Ophite1> need to analyse anonymity implications of that.</p>
|
|
<p>[22:51] <jrand0m> but trusted peers is inherently necessary in a militant grade anon system, where /all/ nodes you can contact are considered attackers. </p>
|
|
<p>[22:52] <Ophite1> don't think that is truly possible...</p>
|
|
<p>[22:52] <jrand0m> certainly. yet another reason it should get 0.4 </p>
|
|
<p>[22:52] <jrand0m> Ophite1> trusted nodes with timed / triggered self destruct. </p>
|
|
<p>[22:52] <jrand0m> set up a patsy, route through it, kill it </p>
|
|
<p>[22:52] <jrand0m> exactly, if patsies delete their logs after N hours / N bytes / N messages </p>
|
|
<p>[22:52] <Ophite1> I mean if you want me to release a worm that sets up a couple of million...</p>
|
|
<p>[22:53] <Ophite1> logs? what logs?</p>
|
|
<p>[22:53] <jrand0m> :) </p>
|
|
<p>[22:53] <jrand0m> ok, format the disks ;) </p>
|
|
<p>[22:53] * Ophite1 wrote kernel-level stealth trojan</p>
|
|
<p>[22:53] <jrand0m> nice </p>
|
|
<p>[22:53] * dm wrote kernel level outlook calendar plugin.</p>
|
|
<p>[22:53] <Ophite1> ...when I was 19 :)</p>
|
|
<p>[22:53] <Ophite1> still works. :)</p>
|
|
<p>[22:54] <Ophite1> not going to include it in this though, don't worry, or, uh, check my code, which would probably be a Good Thing To Do anyway ;)</p>
|
|
<p>[22:54] <dm> when I was 12.</p>
|
|
<p>[22:54] <jrand0m> I don't think i2p will want /that/ large distribution until after 1.0 is stable and heavily peer reviewed </p>
|
|
<p>[22:54] <jrand0m> heh Ophite1 </p>
|
|
<p>[22:54] <jrand0m> heh dm </p>
|
|
<p>[22:54] <Ophite1> frankly, think that is a fluff feature.</p>
|
|
<p>[22:54] <jrand0m> perhaps. </p>
|
|
<p>[22:55] <jrand0m> restricted routes is a necessity though </p>
|
|
<p>[22:55] <jrand0m> its basic functionality for people behind firewalls </p>
|
|
<p>[22:55] <jrand0m> (very restrictive firewalls) </p>
|
|
<p>[22:55] <Ophite1> hello, transports.</p>
|
|
<p>[22:55] <Ophite1> we'll get to that.</p>
|
|
<p>[22:55] <Ophite1> or is now the appropriate time to discuss them?</p>
|
|
<p>[22:55] <jrand0m> sure, lets dig in :) </p>
|
|
<p>[22:56] <jrand0m> we've already run into a problem with an unreachable peer that could be solved with restricted routes </p>
|
|
<p>[22:56] *** tusko has left #iip-dev</p>
|
|
<p>[22:56] <jrand0m> even though it was due to misconfiguration, it could be more common </p>
|
|
<p>[22:57] <Ophite1> Also: given two cooperating peers behind inbound-filtering firewalls that drop bad packets, and one cooperating peer which is not behind a firewall and can send packets with forged IP source addresses to both of the other peers...</p>
|
|
<p>[22:57] <Ophite1> You can establish a TCP connection between the two firewalled peers that both firewalls think is outbound.</p>
|
|
<p>[22:57] <jrand0m> definitely </p>
|
|
<p>[22:57] <dm> forged IP addresses?!?</p>
|
|
<p>[22:58] <Ophite1> believe me, firewalls are a VERY common problem.</p>
|
|
<p>[22:58] <Ophite1> sometimes they are user-controlled but the user is a doofus. that can be handled with the installer handling the firewall :)</p>
|
|
<p>[22:58] <dm> I2P is gonna use IP spoofing? :)</p>
|
|
<p>[22:58] <jrand0m> definitely. if i2p can't operate behind firewalls / NATs / proxies, there's no reason to continue. </p>
|
|
<p>[22:59] <Ophite1> sometimes they are actively hostile, corporate or educational gateways seeking to deliberately mess up everything. It's got to traverse those, and traverse them cleanly.</p>
|
|
<p>[22:59] <jrand0m> dm> transport options </p>
|
|
<p>[22:59] <jrand0m> absolutely Ophite1 </p>
|
|
<p>[22:59] <Ophite1> dm: I have a working implementation - in the Direct Connect protocol.</p>
|
|
<p>[22:59] <jrand0m> i2p wants to be the battleground for that code. </p>
|
|
<p>[22:59] <Ophite1> dm: If *that* can handle it, i2p can.</p>
|
|
<p>[22:59] *** Signoff: tonious (Ping timeout)</p>
|
|
<p>[23:00] <Ophite1> I suggest leaving it turned off by default though. Only a very few want it turned on, and it would be nice if they can advertise which they are so requests can be routed to them.</p>
|
|
<p>[23:00] <dm> you can't spoof IPs without native code can you?</p>
|
|
<p>[23:00] <Ophite1> the advantage is that they don't have to route *through*, just help the setup.</p>
|
|
<p>[23:00] <Ophite1> = massive speed boost.</p>
|
|
<p>[23:01] <jrand0m> definitely Ophite1, thats what the RouterInfo.routerAddress[] structure is for </p>
|
|
<p>[23:01] <Ophite1> dm: yeah, like this isn't going to be rewritten?</p>
|
|
<p>[23:01] *** tonious (~Flag@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[23:01] <dm> okay, just checking...</p>
|
|
<p>[23:01] <jrand0m> right dm, I have no qualms whatsoever with including native code in i2p </p>
|
|
<p>[23:01] <Ophite1> I would like to state that I don't think java is a permanent solution.</p>
|
|
<p>[23:01] <Ophite1> And that I regard java router as testbed/prototype.</p>
|
|
<p>[23:01] <jrand0m> thats fine. if it gets us to 1.0, works out the protocol, etc, good enough. </p>
|
|
<p>[23:02] <Ophite1> ...and hope it doesn't get stuck there as freenet has ;)</p>
|
|
<p>[23:02] <dm> IPAddress.Spoof(192.168.32.1);</p>
|
|
<p>[23:02] *** alient (alient@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[23:02] <jrand0m> lol dm </p>
|
|
<p>[23:02] <dm> import IPSpoofing;</p>
|
|
<p>[23:02] <Ophite1> mmm... raw sockets in java ;)</p>
|
|
<p>[23:02] <jrand0m> fcntl / ioctl in java... mmMMmm </p>
|
|
<p>[23:02] <mihi> hmm, raw sockets require root on unix, don't they?</p>
|
|
<p>[23:02] <dm> women with large breasts lickig my penis.. mmMMmmm</p>
|
|
<p>[23:02] <jrand0m> so we include a rootkit </p>
|
|
<p>[23:03] <jrand0m> ;) </p>
|
|
<p>[23:03] <Ophite1> jrand0m: got it covered =)</p>
|
|
<p>[23:03] <jrand0m> heh </p>
|
|
<p>[23:03] <Ophite1> besides as I said; only a few need it.</p>
|
|
<p>[23:03] <jrand0m> right </p>
|
|
<p>[23:04] <jrand0m> and only for legitimate reasons, of course. </p>
|
|
<p>[23:04] <Ophite1> on my dc hub, only one (bot) had the capability, and the hub told it when passives wanted to connect to passives.</p>
|
|
<p>[23:04] <Ophite1> caused a bit of amazement that did.</p>
|
|
<p>[23:04] <jrand0m> hehe </p>
|
|
<p>[23:04] <Ophite1> also got the bot's host shut down, hence my suggestion to perhaps turn it off by default :)</p>
|
|
<p>[23:04] <jrand0m> thats definitely a good feature to have avail </p>
|
|
<p>[23:04] <jrand0m> lol </p>
|
|
<p>[23:05] *** Signoff: nickthief54450 (Excess Flood)</p>
|
|
<p>[23:05] <jrand0m> ok, so with restricted routes pushed to 0.4, we have a month or so to continue the debate as to whether the functionality is necessary </p>
|
|
<p>[23:06] <jrand0m> any other thoughts / things that should be in the roadmap that aren't, things that are in the wrong place, etc? </p>
|
|
<p>[23:06] <Ophite1> I say push it to 0.4 definitely. It will cause firewall issues at the moment but we are still in testing...</p>
|
|
<p>[23:06] <Ophite1> ...someone that can't open a firewall port probably shouldn't be trying it yet.</p>
|
|
<p>[23:06] *** nickthief54450 (~chatzilla@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[23:06] <jrand0m> right. and even with firewalls, PHTTP lets them through. </p>
|
|
<p>[23:07] <Ophite1> though need to test phttp against hostile proxies.</p>
|
|
<p>[23:07] * jrand0m is behind a firewall I don't control and I participate fully in i2p</p>
|
|
<p>[23:07] <dm> hax0r</p>
|
|
<p>[23:07] <jrand0m> well, yes, hostile proxies can fake confirm, but its all signed, so the message can't go to the wrong place / etc </p>
|
|
<p>[23:08] <jrand0m> but the phttp relay and transport does have a lot of features needed </p>
|
|
<p>[23:08] <Ophite1> in particular, to examine the future possibilities application level routers might have at detecting/fucking up the protocol.</p>
|
|
<p>[23:08] <jrand0m> hm? </p>
|
|
<p>[23:08] <Ophite1> have some experience with firewall tunnelling though.</p>
|
|
<p>[23:08] <Ophite1> might want to include a GET fallback.</p>
|
|
<p>[23:09] <jrand0m> hmm. GET goes into logs. but perhaps as a fallback </p>
|
|
<p>[23:09] <jrand0m> (POST can be to /index.html) </p>
|
|
<p>[23:09] <Ophite1> jrand0m: but it's all signed/encrypted if noderefs are cool...?</p>
|
|
<p>[23:10] <Ophite1> unless the proxy becomes an active attacker too, that's going to be quite hard for it.</p>
|
|
<p>[23:10] <jrand0m> all messages are encrypted to the destination router, and the designation as to what phttp relay to go through is signed in the routerInfo </p>
|
|
<p>[23:10] <jrand0m> right. phttp proxy as is certainly isn't strong enough to go against an active attacker </p>
|
|
<p>[23:11] *** Signoff: grimps (Leaving)</p>
|
|
<p>[23:12] <jrand0m> I think it'd be great if people posted some alternate transport ideas to the wiki :) </p>
|
|
<p>[23:12] <jrand0m> ok, 4) app status [ppp2p, i2ptunnel, im, ns, squid] </p>
|
|
<p>[23:12] <jrand0m> damn, tusko left </p>
|
|
<p>[23:12] <jrand0m> tusko wrote a python script (ppp2p) to let people run ppp over i2p via i2ptunnel </p>
|
|
<p>[23:13] <Ophite1> Told you someone would do that :)</p>
|
|
<p>[23:13] <dm> ppp over i2p?</p>
|
|
<p>[23:13] <jrand0m> I haven't looked at it, but last I heard he was running a vpn over i2p with 5s ping times </p>
|
|
<p>[23:13] <jrand0m> heh yeah </p>
|
|
<p>[23:13] <Ophite1> dm: of course.</p>
|
|
<p>[23:13] <dm> when could you use that?</p>
|
|
<p>[23:13] <dm> could/would</p>
|
|
<p>[23:13] <jrand0m> dm> anonymous outproxy </p>
|
|
<p>[23:13] <Ophite1> dm: anonymous ANYTHING.</p>
|
|
<p>[23:13] <jrand0m> to, say, run a kazaa node anonymously, or whatever </p>
|
|
<p>[23:13] * Ophite1 points out that anyone running an outbound i2p->ppp link is insane and will probably be blacklisted/hunted down</p>
|
|
<p>[23:13] <dm> ah, I understand.</p>
|
|
<p>[23:13] <jrand0m> definitely Ophite1 </p>
|
|
<p>[23:14] <jrand0m> so right now, its only for trusted peers. </p>
|
|
<p>[23:14] <Ophite1> see also: the dresden JAP cascade... :)</p>
|
|
<p>[23:14] <jrand0m> which, well, doesnt really make sense for anonymity... </p>
|
|
<p>[23:14] <jrand0m> heh </p>
|
|
<p>[23:14] <Ophite1> also most of the stuff going out of their node will be unencrypted...</p>
|
|
<p>[23:14] * jrand0m thinks about ike over ppp over i2p</p>
|
|
<p>[23:15] * jrand0m watches my head explode</p>
|
|
<p>[23:15] *** fiaga (~po@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[23:15] <Ophite1> jrand0m: why not i2p over ppp over i2p?</p>
|
|
<p>[23:15] <jrand0m> definitely doable. aint recursion fun? </p>
|
|
<p>[23:15] <soros> i2p over i2p :-o</p>
|
|
<p>[23:15] <jrand0m> or i2p over ppp over i2p over i2p over freenet over kazaa </p>
|
|
<p>[23:15] <Ophite1> now that's just silly. Freenet wouldn't possibly work ;)</p>
|
|
<p>[23:16] <godmode0> over slow connect :)</p>
|
|
<p>[23:16] <jrand0m> heh it'd have latency issues, certainly :) </p>
|
|
<p>[23:16] <mihi> ... over an icmp tunnel over ...</p>
|
|
<p>[23:16] <Ophite1> ooh yes, loki :)</p>
|
|
<p>[23:16] <Ophite1> 0ldsk00l :)</p>
|
|
<p>[23:17] <Ophite1> I2P addresses, being the public keys, are ... rather long.</p>
|
|
<p>[23:17] <jrand0m> yes. </p>
|
|
<p>[23:17] <jrand0m> actually, since we're on agenda item 4: ns </p>
|
|
<p>[23:17] <Ophite1> As in an I2P www url being actually too long to paste into any sane place (>512 chars?!!)</p>
|
|
<p>[23:17] <mihi> co promised to write a naming service...</p>
|
|
<p>[23:17] <jrand0m> yeah. </p>
|
|
<p>[23:17] <jrand0m> I think with idn implemented, it would be very easy for someone to adapt the kademlia code into a distributed dns </p>
|
|
<p>[23:17] <mihi> Ophite1: post them to the eepsite forum.</p>
|
|
<p>[23:18] <Ophite1> trouble with namespace as I can figure it out is that there has to be either some degree of central control OR you have to allow collisions.</p>
|
|
<p>[23:18] *** Signoff: fiaga (Ping timeout)</p>
|
|
<p>[23:18] <jrand0m> (just toss on a CA or WoT CAs, and voila. (Link: www.mihi.i2p)www.mihi.i2p) </p>
|
|
<p>[23:18] <jrand0m> not necessarily. </p>
|
|
<p>[23:18] <Ophite1> please enlighten me with your better ideas then.</p>
|
|
<p>[23:18] <jrand0m> Ophite1> check out co/wiht's specs on the iip-dev list. </p>
|
|
<p>[23:19] <Ophite1> best I could come up with is root key creates signed namespaces. dnssec stylee.</p>
|
|
<p>[23:19] <jrand0m> he doesn't go the full route with a dht, but he manages groups </p>
|
|
<p>[23:19] <jrand0m> just like how we do now - we /all/ can choose who our root dns servers are. </p>
|
|
<p>[23:19] <jrand0m> in the same vein, we /all/ should be able to choose who our CA (or CA WoT) is </p>
|
|
<p>[23:20] <jrand0m> so I guess technically there /could/ be collisions, but only once there are multiple CA groups that don't interact </p>
|
|
<p>[23:20] * Ophite1 notes that is unlikely</p>
|
|
<p>[23:20] <jrand0m> agreed </p>
|
|
<p>[23:20] <Ophite1> you either trust the root CA or you don't.</p>
|
|
<p>[23:20] <jrand0m> and if you don't trust the root, you create your own </p>
|
|
<p>[23:21] <jrand0m> (or find another) </p>
|
|
<p>[23:21] <Ophite1> and if you don't trust the root CA it's for a reason, a reason that will rapidly get around.</p>
|
|
<p>[23:21] <jrand0m> exactly </p>
|
|
<p>[23:21] <jrand0m> especially when there's anonymous publishing :) </p>
|
|
<p>[23:21] <Ophite1> being as CA's only real purpose is to insure anti-collision - like Trent...</p>
|
|
<p>[23:21] <jrand0m> right </p>
|
|
<p>[23:22] <Ophite1> about the only thing that would cause lack of trust in CA is (1) key leakage or (2) refusal to register something that isn't already registered.</p>
|
|
<p>[23:22] * jrand0m notes verisign's "trustworthiness"</p>
|
|
<p>[23:23] * Ophite1 notes that Verisign purports to verify the identity of the certificate holder - one of the properties that an I2P namespace is in fact guaranteed NOT to do</p>
|
|
<p>[23:23] <jrand0m> self signed certs+++ </p>
|
|
<p>[23:24] <Ophite1> also I'd point out that distributed systems - like Darknet, as I will call it from here on in until it sticks :) - built on top of i2p probably wouldn't use the namespace.</p>
|
|
<p>[23:24] <Ophite1> It's for servers, really.</p>
|
|
<p>[23:24] <jrand0m> heh </p>
|
|
<p>[23:24] <jrand0m> right </p>
|
|
<p>[23:24] <Ophite1> Servers don't scale. That problem will be in i2p as much as in IP.</p>
|
|
<p>[23:24] <Ophite1> so, I think that the usage in practice will actually be surprisingly limited.</p>
|
|
<p>[23:24] <jrand0m> the idn ("darknet") would keep references to destinations - the full 387 bits of their keys, not some pretty name </p>
|
|
<p>[23:24] <jrand0m> agreed. </p>
|
|
<p>[23:25] <jrand0m> except / until someone writes a distributed outproxy system </p>
|
|
<p>[23:25] <jrand0m> aka o-r / freedom over i2p </p>
|
|
<p>[23:25] <TC> how many diffrent keys can we have?</p>
|
|
<p>[23:25] * jrand0m looks forward to that day</p>
|
|
<p>[23:25] <jrand0m> tc> 2^2048 </p>
|
|
<p>[23:25] <Ophite1> jrand0m: at which point the root key signs them a namespace: .proxy.i2p</p>
|
|
<p>[23:26] <dm> This must be the most hypothetical/megalomaniac open source development meeting ever :)</p>
|
|
<p>[23:26] <jrand0m> aint subspaces grand :) </p>
|
|
<p>[23:26] <jrand0m> lol dm </p>
|
|
<p>[23:26] <jrand0m> hey, we're alowed to aim high, aint we? </p>
|
|
<p>[23:26] <dm> I'm sure most devl meetings are like: "So, do we put 3 bits for the mpeg-5 header or 4?"</p>
|
|
<p>[23:26] <Ophite1> jrand0m: oddly as it may seem, not every number works for elgamal ;-)</p>
|
|
<p>[23:26] <TC> dm, youve seen debian meetings right?</p>
|
|
<p>[23:26] <jrand0m> awww c'mon, 000000000000000000000000000 is a secure key </p>
|
|
<p>[23:26] * Ophite1 hands out Chocolate Digestives</p>
|
|
<p>[23:26] <dm> TC: no, what are the like?</p>
|
|
<p>[23:26] <Ophite1> jrand0m: ooh, identity.</p>
|
|
<p>[23:26] <TC> dm, i dont know, i was asking</p>
|
|
<p>[23:27] <jrand0m> ok. thecrypto isn't here either... anyone have im thoughts? </p>
|
|
<p>[23:27] <Ophite1> damn, I was about to ask about that.</p>
|
|
<p>[23:27] <Ophite1> quite an important app.</p>
|
|
<p>[23:27] <dm> Anyway, this type of meeting is more lurker-friendly, so I'm all for it.</p>
|
|
<p>[23:27] * dm is entertained.</p>
|
|
<p>[23:27] <jrand0m> heh </p>
|
|
<p>[23:27] <TC> where is co?</p>
|
|
<p>[23:27] <Ophite1> as many people will expect i2p to be iip's successor.</p>
|
|
<p>[23:28] <jrand0m> iip over i2p is fairly easy, if we don't want dcc </p>
|
|
<p>[23:28] <Ophite1> (I guess it could be, if we just run an iip irc server over i2p...)</p>
|
|
<p>[23:28] <jrand0m> iip over i2p with dcc requires a new app </p>
|
|
<p>[23:28] <jrand0m> exactly Ophite1 </p>
|
|
<p>[23:28] <jrand0m> 0 coding </p>
|
|
<p>[23:28] <TC> cant we just run irc over i2p?</p>
|
|
<p>[23:28] <Ophite1> I don't like that idea 'cause ... well, it doesn't give us anything we don't already have :)</p>
|
|
<p>[23:28] <jrand0m> but last I heard, thecrypto was doing some work on an IM app </p>
|
|
<p>[23:28] <jrand0m> certainly tc </p>
|
|
<p>[23:29] <jrand0m> right Ophite1, and it doesn't scale </p>
|
|
<p>[23:29] <jrand0m> (all the traffic gets funneled to the ircd) </p>
|
|
<p>[23:29] <Ophite1> Also the IRCd can spy on traffic.</p>
|
|
<p>[23:29] <TC> ah, goodpoint</p>
|
|
<p>[23:29] <jrand0m> (this would be when UserX should show up and discuss his ideas for iip2.0) </p>
|
|
<p>[23:29] <jrand0m> right Ophite1 </p>
|
|
<p>[23:29] <jrand0m> all the problems of the current iip </p>
|
|
<p>[23:29] <Ophite1> jrand0m: And absolutely nothing different.</p>
|
|
<p>[23:29] <jrand0m> more lag. </p>
|
|
<p>[23:30] <Ophite1> except it's in java. lovely. :)</p>
|
|
<p>[23:30] <jrand0m> heh </p>
|
|
<p>[23:30] <Ophite1> Now, shitloads of people have cut their undergraduate teeth trying and failing to build distributed chat applications.</p>
|
|
<p>[23:30] <jrand0m> ok, so someone should either help thecrypto out or push him along some more :) </p>
|
|
<p>[23:30] * Ophite1 points out IRC3</p>
|
|
<p>[23:30] <jrand0m> yeah, its a perfect school project </p>
|
|
<p>[23:30] <Ophite1> ..and SILC...</p>
|
|
<p>[23:30] <Ophite1> ...and...</p>
|
|
<p>[23:31] <Ophite1> well about a gazillion others.</p>
|
|
<p>[23:31] <jrand0m> 'zactly </p>
|
|
<p>[23:31] <Ophite1> Literally all of these, I might add, are pre-DHT as far as I can tell.</p>
|
|
<p>[23:31] <jrand0m> yup </p>
|
|
<p>[23:31] <Ophite1> That's disappointing 'cause that's a freakishly useful structure.</p>
|
|
<p>[23:31] <jrand0m> a DHT for lookup / P3P, and then direct con for IM </p>
|
|
<p>[23:31] <jrand0m> group chat is harder though, but not too hard </p>
|
|
<p>[23:31] <Ophite1> well, direct in the i2p sense :)</p>
|
|
<p>[23:31] <jrand0m> heh right </p>
|
|
<p>[23:32] <Ophite1> what about darkmail/i2pmail?</p>
|
|
<p>[23:32] <soros> group sex too</p>
|
|
<p>[23:32] <dm> soros: agreed.</p>
|
|
<p>[23:32] <jrand0m> group sex isn't that hard soros ;) </p>
|
|
<p>[23:32] <jrand0m> lol </p>
|
|
<p>[23:32] <jrand0m> email over i2p is easy. someone just needs to run a pop server </p>
|
|
<p>[23:32] <jrand0m> or webmail </p>
|
|
<p>[23:32] <jrand0m> hahah </p>
|
|
<p>[23:33] <Ophite1> jrand0m: sure, as long as literally everyone is okay with bloody pgp :)</p>
|
|
<p>[23:33] * Ophite1 gets CKT nightmares again</p>
|
|
<p>[23:33] <jrand0m> oh, true. that'd expose the contents to hte server ;) </p>
|
|
<p>[23:33] <Ophite1> Also... spam.</p>
|
|
<p>[23:33] <jrand0m> yup </p>
|
|
<p>[23:33] <Ophite1> We have this thing called hashcash.</p>
|
|
<p>[23:33] <Ophite1> They sort of fit together, no?</p>
|
|
<p>[23:34] <jrand0m> ok, so yeah, someone should get working on an i2p specific email app :) </p>
|
|
<p>[23:34] <Ophite1> obviously that would work best as part of the im.</p>
|
|
<p>[23:34] <Ophite1> What, after all, is the distinction between irc and email?</p>
|
|
<p>[23:34] <jrand0m> true, like an IM VMB </p>
|
|
<p>[23:34] <Ophite1> Whether or not you can page up and see what you missed after you rejoin...</p>
|
|
<p>[23:34] <jrand0m> placed into the dht </p>
|
|
<p>[23:34] <jrand0m> good point </p>
|
|
<p>[23:35] * jrand0m wishes we had a team of a dozen coders</p>
|
|
<p>[23:35] <Ophite1> note, however, that mail requires storage, as it is offline communication. irc requires no storage, as it is online communication.</p>
|
|
<p>[23:35] <dm> also email has a lot more penis enlargement adverts.</p>
|
|
<p>[23:35] <Ophite1> jrand0m: ask around for funding.</p>
|
|
<p>[23:35] <Ophite1> dm: see above re: hashcash.</p>
|
|
<p>[23:35] <jrand0m> right, the P3P could contain pending messages </p>
|
|
<p>[23:36] <Ophite1> dm: A primitive that was not available to the bloke who hacked up email in a night.</p>
|
|
<p>[23:36] <Ophite1> (At least we won't have to use ! paths to specify the tunnel manually. heh. heh. heh.)</p>
|
|
<p>[23:36] * dm is gonna miss clear-text dead simple protocols.</p>
|
|
<p>[23:36] <jrand0m> jrandom%ophite!dm!mihi </p>
|
|
<p>[23:37] <Ophite1> no, this is i2p. Insert ~520 garbage characters between the bangs then you're closer ;)</p>
|
|
<p>[23:37] <jrand0m> haha </p>
|
|
<p>[23:37] <Ophite1> several of these things *are* sort of related.</p>
|
|
<p>[23:37] <jrand0m> true, 387 bytes base64 encoded... </p>
|
|
<p>[23:38] <Ophite1> or to put it another way, ELONGURL :)</p>
|
|
<p>[23:38] <jrand0m> heh </p>
|
|
<p>[23:38] <Ophite1> [does IE chop at 512?]</p>
|
|
<p>[23:38] <jrand0m> naw, works fine </p>
|
|
<p>[23:38] <Ophite1> you admit to using IE?</p>
|
|
<p>[23:38] <Ophite1> To browse anonymously?!</p>
|
|
<p>[23:38] <jrand0m> ;) </p>
|
|
<p>[23:38] * Ophite1 pulls out six of Liu De Yiu's best and waits =)</p>
|
|
<p>[23:38] * jrand0m uses ie for eppsites, moz for squiding</p>
|
|
<p>[23:39] <duck> what item are we now?</p>
|
|
<p>[23:39] <duck> 4?</p>
|
|
<p>[23:39] <jrand0m> yeah, ok ok </p>
|
|
<p>[23:39] <Ophite1> still 4 I think.</p>
|
|
<p>[23:39] <jrand0m> i2ptunnel. still kicks ass. </p>
|
|
<p>[23:39] <jrand0m> any thoughts? any comments mihi? </p>
|
|
<p>[23:40] <jrand0m> one thing I want to note wrt the squid outproxy is that I've updated the header filtering to ALLOW COOKIES and replace the user agent with something silly </p>
|
|
<p>[23:40] * mihi just waits for naming service...</p>
|
|
<p>[23:40] <jrand0m> mihi (or someone else)> it'd be really easy to bootstrap such a naming service with an /etc/hosts style i2p ns </p>
|
|
<p>[23:41] <mihi> btw: are there any other public dests except your squid and tc's eepsite?</p>
|
|
<p>[23:41] <jrand0m> i2pcvs.dest </p>
|
|
<p>[23:41] <jrand0m> (points at the i2p cvs pserver) </p>
|
|
<p>[23:41] <jrand0m> (but isn't always up) </p>
|
|
<p>[23:41] *** yodel (yodel@anon.iip) has joined channel #iip-dev</p>
|
|
<p>[23:41] <jrand0m> hola yodel </p>
|
|
<p>[23:41] <yodel> hela</p>
|
|
<p>[23:42] <jrand0m> ok, I think thats it for 4) apps </p>
|
|
<p>[23:42] <jrand0m> 5) comments / questions / etc </p>
|
|
<p>[23:42] <mihi> gui installer?</p>
|
|
<p>[23:42] <TC> hi yodel</p>
|
|
<p>[23:43] <yodel> I have to start experimenting putting the xml-rpc over i2p</p>
|
|
<p>[23:43] <yodel> should work with httptunnel</p>
|
|
<p>[23:43] <jrand0m> good question mihi. last I heard MrEcho had some of it working </p>
|
|
<p>[23:43] <jrand0m> awesome yodel </p>
|
|
<p>[23:43] <jrand0m> definitely. </p>
|
|
<p>[23:43] <jrand0m> how large are the streams? </p>
|
|
<p>[23:43] <jrand0m> (aka how chatty is the protocol?) </p>
|
|
<p>[23:44] * Ophite1 plans to try BitTorrent over I2P as a stress test</p>
|
|
<p>[23:44] <yodel> xml over http</p>
|
|
<p>[23:44] <yodel> the ssl layer wont be needed with i2p</p>
|
|
<p>[23:44] <Ophite1> so, uh, very chatty? :)</p>
|
|
<p>[23:44] <jrand0m> ah cool, large POST or large replies? </p>
|
|
<p>[23:44] <jrand0m> (or just small and small?) </p>
|
|
<p>[23:45] <jrand0m> damn you Ophite1 :) </p>
|
|
<p>[23:45] <yodel> equal sizes</p>
|
|
<p>[23:45] <yodel> does httptunnel support gzipped http?</p>
|
|
<p>[23:45] <jrand0m> but doesn't bt use IP addresses? </p>
|
|
<p>[23:45] <jrand0m> hmm, httptunnel doesn't have any inherent compression, its just a bitstream </p>
|
|
<p>[23:45] <TC> hmm, package i2p+ppp\vpn+gui as a security solution for wireless windows shares</p>
|
|
<p>[23:45] <yodel> so should work...</p>
|
|
<p>[23:45] <godmode0> jrand0m> you test i2p in nntp news server ?</p>
|
|
<p>[23:45] <jrand0m> yup yodel </p>
|
|
<p>[23:45] <yodel> 500-1000 byte send, same for reply</p>
|
|
<p>[23:46] <jrand0m> hmm I haven't tested that yet godmode0 </p>
|
|
<p>[23:46] <yodel> much less when zipped</p>
|
|
<p>[23:46] <jrand0m> oh cool yodel, that'll work without any problem </p>
|
|
<p>[23:46] <yodel> what is the latency for a single msg/package/whatever?</p>
|
|
<p>[23:46] <jrand0m> 2-5s, sometimes up to 10s </p>
|
|
<p>[23:46] <jrand0m> (currently) </p>
|
|
<p>[23:46] <Ophite1> not bad for a pre-dht :)</p>
|
|
<p>[23:46] <yodel> so 20s roundtime?</p>
|
|
<p>[23:47] <jrand0m> I usually pull up a web page in 5-10s </p>
|
|
<p>[23:47] <yodel> ah</p>
|
|
<p>[23:47] <yodel> goo</p>
|
|
<p>[23:47] <yodel> +d</p>
|
|
<p>[23:48] <jrand0m> damn, we're coming up to the 2 hour mark. anyone have any other questions / thoughts? </p>
|
|
<p>[23:48] <Ophite1> Pie is good.</p>
|
|
<p>[23:48] <duck> jrand0m: why do you drink cheap local beer?</p>
|
|
<p>[23:48] <Ophite1> Orgy and pie is better.</p>
|
|
<p>[23:48] <jrand0m> rofl duck </p>
|
|
<p>[23:49] <Ophite1> duck: It's better than Tesco Value Lager?</p>
|
|
<p>[23:49] * Ophite1 spits from reflex</p>
|
|
<p>[23:49] <jrand0m> heh </p>
|
|
<p>[23:49] * duck is concerned about jrand0m's health</p>
|
|
<p>[23:49] <jrand0m> you're concerned about my cheap beer habits but not my good whiskey habits? </p>
|
|
<p>[23:50] * Ophite1 reminds about the single malt on Cary Sherman's head</p>
|
|
<p>[23:50] <duck> do you eat well?</p>
|
|
<p>[23:50] <godmode0> corona</p>
|
|
<p>[23:50] <duck> do you do your daily exercises?</p>
|
|
<p>[23:50] <jrand0m> well, i'm one of those veggies </p>
|
|
<p>[23:50] <Ophite1> Isn't that a personal question, duck?</p>
|
|
<p>[23:50] <jrand0m> does typing count? </p>
|
|
<p>[23:50] <duck> you did drink that much already?</p>
|
|
<p>[23:50] <duck> that you became a veggie</p>
|
|
<p>[23:50] <jrand0m> heh </p>
|
|
<p>[23:50] <Ophite1> cheap beer will do that.</p>
|
|
<p>[23:51] <duck> Ophite1: jrand0m's health should concern us all, since it is essential for I2P</p>
|
|
<p>[23:51] *** Signoff: mihi_backup (mihi hands jrand0m the *BAF*er)</p>
|
|
<p>[23:51] <jrand0m> heh ok ok mihi </p>
|
|
<p>[23:51] * jrand0m winds up</p>
|
|
<p>[23:51] * jrand0m *baf*s the meeting closed</p>
|
|
</div>
|
|
{% endblock %} |