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