<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: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: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] <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: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] <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: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: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> 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] <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>[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: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: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: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: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: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>
