I2P dev meeting, June 4, 2013 @ 20:00 UTC
christoph2, dg, hottuna, inscrutable, KillYourTV, Meeh, orion, psi, sponge, str4d, topiltzin, zzz
- The next NetDB backend
- Fast key rotation is probably meaningless according to discussions with christop egger.
- Regarding building a completely new overlay, that may be difficult task.
- Ticket #729 - properties location on osx
- zab/topiltzin will merge. Meehs attention is requested for some testing.
- Ticket #741 - process renamer on windows
- KillYouTV agreed to some Win8 x84/x64 testing.
- Defaults of the new i2p exe are not set up/working yet.
- Icons for the I2P executables are not available in high quality/svg. -> Bad looks.
- Sponge: Bridge API for UDP (BOB) RFC
- Sponge: IPV6 and de-anonymization since the address space is so large that each user and device is likely to have an address.
- Sponge: Will be around more Real Soon Now (tm).
- Orion: i2pcpp supports ipv6.
Registo Completo do IRC
19:52:28 <hottuna> zzz, christoph2: syn 19:54:26 <topiltzin> yay, dev beating! 19:54:33 <topiltzin> s/beating/meeting/ 19:54:37 <iRelay> topiltzin meant: yay, dev meeting! 20:00:03 * hottuna baf's the meeting opened 20:00:07 <hottuna> Agenda: 20:00:14 <hottuna> * The next NetDB backend 20:00:14 <hottuna> * Ticket #729 - properties location on osx 20:00:14 <hottuna> * Ticket #741 - process renamer on windows 20:00:14 <hottuna> * Misc? 20:00:22 <iRelay> http://trac.i2p2.i2p/ticket/729 - (assigned enhancement) - on OSX ~/.i2p -> ~/Library/Application Support/i2p 20:00:33 <iRelay> http://trac.i2p2.i2p/ticket/741 - (accepted enhancement) - Make I2P easier to deal with with Windows firewall software 20:00:45 <hottuna> __ The next NetDB backend__ 20:01:16 <hottuna> I've been working on a proposal, the first RFC is ready 20:01:35 <hottuna> http://trac.i2p2.de/wiki/NetDB/NextBackend 20:01:38 <iRelay> Title: NetDB/NextBackend – I2P (at trac.i2p2.de) 20:02:14 <hottuna> The general idea is to use a Kademlia base and extend it with features that improve performance and/or reliability. 20:02:59 <hottuna> Some of the initial code for Kademlia has already been written by zzz 20:03:34 <hottuna> In fact a full BEP5 implementation. BEP5 is the mainline bittorrent implementation of Kademlia. 20:04:13 <hottuna> Several DHTs have been considered: Chord, Freenet and Pastry. 20:04:47 <hottuna> However Kad is fast, extendible and relatively reliable. 20:05:05 <topiltzin> some other Kad derivatives that are used in production: Azureus kad, eMule kad, Mojito Kad (Limewire) 20:05:24 <topiltzin> Overnet (eDonkey, now defunct) 20:05:47 <topiltzin> no p2p app uses chord or pastry (to my knowledge) 20:05:54 <hottuna> I've had a look through the Az-Kad and it's not very compatible. Mojito might be interesting 20:05:57 <hottuna> On top of Kad a few changes have been proposed. 20:06:05 <hottuna> Recursive tunnels for faster lookups. 20:06:20 <hottuna> And Random Recursive lookups for more reliable lookups. 20:07:13 <hottuna> Insertions will be standard Kad until Random Recursive Stores are implemented. 20:07:45 <hottuna> Alright, so that is the overview. Does anyone have any questions? 20:08:17 <topiltzin> One objection to recursive tunnels is that it renders local ip banlists useless 20:08:40 <topiltzin> for example, I could have manually added the ips of a hostile party to my ban list 20:09:18 <topiltzin> the nodes that participate in the recursive lookup/store will not know that 20:09:37 <hottuna> That is true. 20:10:00 <hottuna> Recursive queries are somewhat frail, and should only be used for speed. 20:10:35 <hottuna> Random Recursive queries will however, eventually find a path which doesnt involve the banned nodes. 20:11:05 <hottuna> For what kind of situations would you not trust the ban-list of another node? 20:11:25 <dg> sponge: want udp 20:11:28 <dg> eche|on: count is not persistent after network changes ("soft restart") 20:11:51 <topiltzin> for the situation where the operator of that node hasn't been diligent in updating the banlist 20:12:02 <topiltzin> or for the situation where the other node has no banlist at all 20:12:29 <hottuna> But what would happen if the query passed through a 'banned' node? 20:12:51 <hottuna> Either it is forwarded, dropped or recorded. 20:13:31 <zzz> iterative never passes thru anybody 20:13:34 <topiltzin> whatever the sybil/eclipse attack does - probably droped? 20:14:38 <hottuna> That is the thing about Recursive. It's ok if it fails. We have more reliable methods for keys that are under attack. 20:15:09 <hottuna> Like Iterative or Random Recursive 20:15:24 <zzz> how to select a mode? 20:15:35 <topiltzin> theoretically you could include a small bloom filter of banned ips to the query 20:15:54 <hottuna> mode selection an open question. 20:15:57 <hottuna> is an* 20:16:28 <hottuna> In my mind a parallel version would be interesting 20:16:39 <hottuna> A sequential failover version would be slow 20:17:03 <hottuna> But it is a bandwidth vs. max_latency tradeof 20:17:51 <hottuna> topiltzin: R5N includes a bloomfilter in queries. But I don't think the really is needed. 20:18:14 <hottuna> We build this thing to work even if failures are encountered 20:18:14 <topiltzin> how much slower is the iterative lookup, and is that slowness a bottleneck of any kind? Do we really need to be optimizing that? 20:18:45 <zzz> I think we gotta start with adding stat code (where necessary) to netdb and snark and gathering stats on current performance of those two impls 20:18:52 <hottuna> When you visit an eepsite, a lookup has to be done. 20:19:25 <hottuna> topiltzin: the speed of lookups can be seen under the 'Lookup' part of http://trac.i2p2.de/wiki/NetDB/NextBackend 20:19:28 <iRelay> Title: NetDB/NextBackend – I2P (at trac.i2p2.de) 20:20:16 <zzz> netdb has lots of stats, if we add stats to equivalent places in snark we can start to put a picture together 20:20:35 <hottuna> query latencies etc? 20:21:06 <topiltzin> zzz: +1 on moar stats 20:21:06 <zzz> latencies, queries-per-success, etc, yes 20:22:26 <hottuna> Having access to those stats would be interesting. Especially when developing something new. However comparing I2PSnark-DHT to FloodFill is comparing apples to oranges. 20:22:29 <zzz> as I said the other day, I think the snark code could be moved back to netdb but only if we choose K and B to swallow the whole local netdb into the routing table 20:22:57 <zzz> if the routing table is missing most of the local netdb we may as well just keep sorting 20:23:55 <zzz> your proposal (and yes it's been my plan for a couple years as well) is to replace the orange with the apple, so it's kindof important to compare them. 20:23:58 <hottuna> Im am not against setting a high B, lookup latency is a real issue 20:24:55 <hottuna> regarding K I think keeping it at 8 may be reasonable. 20:25:18 <hottuna> of course the new dht would have to be evaluated. 20:26:05 <zzz> you can't pick K in isolation. You have to pick K and B to make the routing table work as well as sorting does now, for a given local netdb size. 20:27:03 <hottuna> Both can be tweaked while deploying. 20:27:29 <hottuna> So I'd go for an initial guesstimation base on what we know and what we need. 20:28:17 <zzz> also depends greatly on whether it's the ffs or everybody that's in the new dht 20:29:24 <hottuna> Not making every node a participant in the new dht would be a mistake an keep us vulnerable to attacks like that presented in the UCSB paper 20:30:15 <zzz> I don't see info on who's in or out in your proposal 20:30:18 <hottuna> I suppose I wasn't very clear about that in the proposal. 20:30:25 <hottuna> ;) 20:31:30 <zzz> not at all sure you want everybody (natted, android, hidden, chinese, mobile phones, etc) in it 20:31:46 <zzz> check out jr's extensive comments on where it all went bad 20:31:53 <topiltzin> node churn is not good for the dht. You should have some minimal uptime requirements 20:32:32 <hottuna> topiltzin: node churn isnt much of an issue since all our data is mutable and republished every 37 seconds - 30 minutes 20:33:09 <hottuna> nat:ed nodes should probably not participate. android probably should 20:33:17 <zzz> sure, N=500 and B=-8 was the disaster he never figured out, but there were other causes too, that are still present in our network... and could get much much worse if android takes off 20:33:25 <hottuna> chinese.. i don't know.. 20:34:04 <hottuna> other than likely having higher churn, how is android different? 20:34:32 <topiltzin> node churn affects routing negatively.. so if the goal of this effort is to improve routing you cannot ignore it 20:34:39 <zzz> I mean phones, not android in particular 20:34:58 <hottuna> android==phnoes for me aswell 20:35:22 <zzz> mobile devices have lower bandwidth and horsepower and intermittent connectivity 20:35:57 <hottuna> How is it done now? 20:36:12 <zzz> what? 20:36:39 <hottuna> regarding android devices that want to be an ff? 20:36:42 <hottuna> christoph2: is lurking somewhere 20:36:49 * christoph2 hides 20:37:00 <topiltzin> there are some criteria for becoming an FF, one of them is uptime 20:37:11 <hottuna> how would fast key-rotation interfere with an eclipse attack? 20:37:57 <hottuna> and how long does it take for a node to integrate into the netdb of the other nodes? (ie pollute their routing tables) 20:38:32 <zzz> androids become ff automatically like anybody else, if they meet the criteria. But seems unlikely anybody would do that over the air 20:38:38 <christoph2> well you have time T it takes to integrate a node into I2P (untill it's reasonably well connected) and time t the rotation. you need T/t + safety nodes for eclipse 20:38:53 <hottuna> topiltzin: uptime is really not much of an issue. R5N has some pretty aggressive replication factors. So churn is not an issue 20:39:00 <christoph2> * nodes needed to actually eclipse 20:40:27 <christoph2> hottuna: not exactly following code changes. was less than 30 minutes in december 20:40:27 <hottuna> I did some quick calculations yesterday 20:40:27 <christoph2> well 0.9.2 iirc 20:40:27 <hottuna> nodes_needed_for_eclipse = (60/key_rot_interval)*eclipse_integration_time*attackers_per_eclipse 20:40:27 <hottuna> nodes_needed_for_eclipse = (60/10)*24*20 = 2880. Which might be prohibitive for an attacker. 20:40:27 <zzz> hottuna, how would a new keyspace (either a different permutation formula, different rotation schedule, or both) work? I don't see how we could ever migrate over. 20:40:27 <hottuna> ok, that sounds reasonable 20:40:49 <hottuna> We'd use both in parallel? the current implementation will remain separate until we can safely move away from it. 20:41:26 <zzz> what I really want to know is what can we do in the next two weeks to improve resistance 20:41:29 <hottuna> christoph2: are those calculations sensible? and would 2880 nodes be an issue at all? 20:41:36 <zzz> if that's making the class N routers ff, lets do that. 20:41:36 <topiltzin> I find it very hard to believe that node churn isn't an issue. The bigger the churn, the worse the routing table of each individual node 20:42:29 <zzz> how could we ever 'move safely away' and maintain compatibility? How could we handle the conn limit issues of two parallel impls? How would we migrate from one to the other? 20:42:33 <hottuna> topiltzin: the value K, which is the size of each bucket in the routing table is chosen to be a number of nodes that are highly unlikely to drop out of the dht in an hour. 20:42:33 <topiltzin> ^^ class F but !windoze 20:43:04 <topiltzin> s/F/N/ 20:43:08 <iRelay> topiltzin meant: ^^ class N but !windoze 20:43:12 <zzz> sure, we could do class N non-windows. No idea how many there are 20:43:35 <zzz> it would also expose those routers as being non-windows, small anon issue 20:43:35 <christoph2> hottuna: you get ~20 on a moderately expensive server. 100 of these may or may not be a problem depending on whom you defend against. and I'm not sure if you couldn't get several times more nodes per server with proper code 20:44:22 <hottuna> alright, so it could be a bit of an issue. However it won't be for long the way technology tends to evolve 20:45:28 <zzz> what else could we do for 0.9.7? 20:45:28 <topiltzin> true re: anon issue.. so maybe just do all N and hope we don't piss users off too mch 20:46:18 <christoph2> didn't read everything. what was the issue with windows? 20:46:25 <hottuna> re connections: old nodes would carry on as usual. new nodes would balance their queries amongst both nets. 20:46:49 <dg> christoph2: baked in connection limits 20:46:52 <hottuna> christoph2: windows doesnt allow for a large number of connections 20:47:07 <christoph2> ah ok 20:47:27 <hottuna> christoph2: alright, so that answers the key rotation issue. it is probably not worthwhile 20:47:34 <topiltzin> actually it's the rate at which new connections are opened that's limited 20:49:07 <zzz> hottuna, I don't see how we get from here to there. I can see how to move the snark code to netdb with the same iterative lookups in the same keyspace. I don't know whether its worth it, but at least I can see how. After that it all seems really hard and mysterious. 20:50:02 <hottuna> We would change the key-space? Or what are you referring to as keyspace? 20:50:05 <topiltzin> +1 with starting with snark code and figuring other stuff $later 20:50:40 <zzz> keyspace = key->routing key algo, including rotation 20:52:14 <hottuna> so step one while deploying is having something that works (likely iterative only). then we add new KRPC messages for Recursive and Random Recursive 20:52:54 <hottuna> And when the net has upgraded to mostly support them we can enable them in the originator nodes. 20:53:27 <hottuna> deploying will even help us figure out performance while under massive attack 20:53:38 <zzz> (for background, I started with the netdb kbucket code to make a generic library in i2p.zzz.kademlia, with arbitrary K, B, hash size, and eviction algo. Then I unit tested it to death. Then I moved it to snark for BEP 5 and more testing. The last part of the original plan is to move it back to netdb to complete the circle) 20:54:54 <hottuna> zzz.kad && i2psnark seems like a good base. I've been reading some of the code today, and it makes a lot of sense to me. 20:55:01 <zzz> you're proposing different keyspace, different rotation, and different participants. i.e. a completely new overlay. 20:55:33 <hottuna> I'd like to do a completely new overlay. 20:56:04 <zzz> oh good. code reading++. 20:56:47 <hottuna> alright. If this makes sense and no one has any objections I'd like to move this meeting along. 20:57:42 <hottuna> __Ticket #729 - properties location on osx__ 20:57:49 <hottuna> topiltzin, Meeh 20:58:11 <topiltzin> yep, that's some very low-hanging fruit that's been dangling around 20:58:39 <zzz> new overlay sounds like misery to me. 21:00:12 <topiltzin> ... awkward moment ... 21:00:59 <topiltzin> we still on dht? 21:02:09 <dg> imho discussion on dht isn't over but for the benefit of the meeting it should be 21:02:23 <dg> no decisions seem clear 21:02:26 * dg returns to shadows 21:03:16 <topiltzin> I think the decision for the immediate future 0.9.7 is moar FFs .. the long-term view is still foggy 21:03:42 <topiltzin> I'm gonna go ahead with #729 . Meeh, you around bro? 21:04:16 <trolly> sry, I forgot about meeting 21:04:57 <hottuna> alright topiltzin, what's up with #729? 21:05:35 <topiltzin> So, I've been running it for a while now, propagating trunk to branch i2p.i2p.729 21:05:50 <topiltzin> works fine, straight-forward 21:06:21 <topiltzin> affects only new installs on OSX, so low impact, etc. 21:06:44 <topiltzin> I'd like to merge it and get it over with 21:07:03 <hottuna> zzz, up for the #729 merge? 21:07:45 <hottuna> I don't have mac access, but Im assuming that topiltzin and Meeh does. 21:08:12 <topiltzin> Yeah, we're probably the only osx users around here :) 21:08:15 <topiltzin> here's a diff: 21:08:15 <topiltzin> mtn diff -r h:i2p.i2p -r h:i2p.i2p.729 21:09:14 <hottuna> I don't have repo access on this machine :/ 21:09:41 <dg> "access"? 21:10:00 <hottuna> as in set up :P 21:10:07 <zzz> no objections 21:10:38 <topiltzin> pastebin coming for those who care 21:10:50 <zzz> just needs some testing, but probably wont get more unless its merged 21:10:50 <hottuna> thanks! 21:11:35 <zzz> I lobbied for merging months ago as you will see in #729 comments 21:11:42 <topiltzin> http://pastethis.i2p/show/3404/ 21:11:45 <iRelay> Title: Paste #3404 | LodgeIt! (at pastethis.i2p) 21:12:01 <hottuna> let's go ahead with the merge then 21:12:17 <topiltzin> ok great. Meeh, speak now or forever hold your peace 21:12:28 <topiltzin> (or whatever it is the priest says at the wedding) 21:13:18 <zzz> I'd like him to speak later too if that's when he tests it :) 21:13:21 <topiltzin> ok, I'll merge after the meeting 21:13:56 <hottuna> __Ticket #741 - process renamer on windows__ 21:14:11 <topiltzin> str4d: you around for this? 21:15:54 <topiltzin> mmk, this ticket is not so small 21:16:57 <topiltzin> background - on windows, i2p runs with a process name of "java" 21:16:57 <sponge> hi 21:17:24 <sponge> meeting today? 21:17:27 <topiltzin> which means any security settings that are applied to i2p become valid for any and every java application 21:17:41 <hottuna> sponge: yes. http://zzz.i2p/topics/1397?page=1#p6616 21:17:48 <iRelay> Title: zzz.i2p: Meeting [4th June] (at zzz.i2p) 21:17:48 <sponge> ty 21:17:59 <sponge> bout time I made one of these... 21:18:48 <sponge> this day is always difficult for me to do anything at this particular hour 21:18:55 <zzz> can we do anything on 741 w/o str4d ? 21:19:29 <sponge> I finally have a machine with windows on it 21:19:36 <topiltzin> if we have a copy of visual studio then we can do everything without him 21:19:59 <sponge> 7 iirc, never use it though, so i can help/test 21:20:14 <hottuna> I could get a VS license from microsoft, if anyone knows how to use it.. 21:20:41 <topiltzin> it's a good idea for the project to have such license 21:20:41 <zzz> I mean as far as discussion. So back to the beginning, topiltzin you put this on the agenda why? just to try to get things moving? 21:20:41 <sponge> vs is pretty painful from what I have heard 21:21:07 <topiltzin> exactly - get some action going 21:21:37 <hottuna> Alright, str4d isn't around. Should we table this? 21:21:48 <sponge> aye 21:22:28 * sponge has some 'misc' for discussion 21:22:41 <sponge> let me know when I got the talking stick 21:23:03 <hottuna> Ill take that as a resounding yes. 21:23:03 <hottuna> Moving along.. 21:23:06 <hottuna> __Misc__ 21:23:09 <topiltzin> if you guys want to table it fine, but let's not forget about it competely 21:23:21 <hottuna> topiltzin: agreed 21:23:46 <topiltzin> (I will bring it up next meeting too) 21:23:57 <topiltzin> ;-) 21:24:08 <hottuna> sponge: Misc was it? 21:24:51 <sponge> MISC-- Bridge API for UDP (BOB) -- I have a few ideas on how it could be done, but I need some feedback, and need to know if it is even wanted 21:25:18 <sponge> basically we need some sort of standard that is expandable 21:25:22 <sponge> and to stick with it 21:25:43 <sponge> it also has to be able to not mess with what is out there already 21:25:57 <sponge> well-- adapt easily 21:26:56 <hottuna> So the question is what people would use it for? 21:27:03 <zzz> we already have a thread going at http://zzz.i2p/topics/1393 --- how about putting your proposal there? 21:27:10 <iRelay> Title: zzz.i2p: UDP Trackers (at zzz.i2p) 21:27:10 <sponge> two ways I am thinking of is either wrap a UDP packet with <<destination><data>> or <<handle><data>> 21:28:13 <dg> hottuna: trackers, voip? 21:28:16 <sponge> I'm curious on demand 21:28:16 <dg> dare i say it, games 21:29:03 <sponge> and I need people to discuss this. I have been trying for YEARS to talk with someine, to get more ideas, and nobody wants to think on the problem 21:29:03 <dg> oh, anonet. psi was pushing for that. 21:29:03 <sponge> *someone 21:29:03 <zzz> gotta read up on how SOCKS does it too 21:29:03 <sponge> there are apps out there that do use IDP 21:29:06 <sponge> *UDP 21:29:22 <sponge> don't forget gnutella 21:29:25 <inscrutable> voip (mumble) has been implemented and seen some use 21:29:44 <zzz> that's tcp 21:29:47 <sponge> bote uses a udp-ish packet too 21:29:54 <sponge> gnutella can use udp 21:29:58 <inscrutable> zzz: My bad 21:30:29 <orion> When is the next meeting? 21:30:40 <hottuna> Whenever someone wants to hold one 21:30:40 <zzz> it's all easy inside the JVM. I could add udp to zzzot in a day. It's the external i/f that is a pita. 21:30:40 <sponge> so is there demand? and if you got implementation ideas that can expand and not go stale, post 21:30:45 <orion> Oh crap. We're in a meeting. 21:30:45 <hottuna> I won't host one next week. 21:31:06 <hottuna> orion: we're at __Misc__ now.. 21:31:25 <dg> sponge: yes. 21:31:32 <sponge> number 2 misc--- ipv6 and it's implications on de-anoning 21:31:35 <orion> hottuna: Thank you. 21:31:50 <sponge> concerns? 21:32:01 <sponge> haw close are we to using ipv6 21:32:08 <sponge> how 21:32:12 <hottuna> what concerns are you having sponge? 21:32:27 <sponge> ipv6 can link to who you are very easily 21:32:46 <Meeh> damn, overslept the meeting -.- 21:32:53 <zzz> IPv6 thread: http://zzz.i2p/topics/109 21:32:56 <hottuna> since the address space is larger? 21:32:59 <iRelay> Title: zzz.i2p: IPV6 TODO (at zzz.i2p) 21:33:03 <sponge> yes 21:33:03 <sponge> I was thinking 21:33:14 <sponge> zzz: this is different, but related 21:33:17 <dg> ipv6 does not deanonymize? WHOIS _may_ be more accurate as _may_ be determining if a NAT is in place (Bob and Ryan are behind a NAT, you do not know which is which) -- with IPv6, you can perhaps know if it is Bob or Ryan. 21:33:24 <dg> IMO, it makes no practical difference to I2P. 21:33:27 <sponge> i2p could get an ipv6 space 21:33:39 <psi> socks 5 udp would be awesome 21:33:42 <sponge> farm that out to users via tunnel 21:33:45 <str4d> o/ 21:33:48 <orion> Side note: i2pcpp will have full ipv6 support. 21:33:54 <str4d> Apologies for being late. 21:33:57 <hottuna> dg: I agree. 21:34:06 <zzz> awaiting sponge to list his concerns (post #66) 21:34:20 <dg> hottuna: Can we move on if sponge has nothing to add? 21:34:35 <dg> i feel it's a non issue 21:34:35 <zzz> schedule? merge for 0.9.8, enable by default in 0.9.9 21:34:38 <sponge> so in short.... will i2p provide an ipv6 tunnel for persons of high concern? 21:34:53 <topiltzin> hey str4d, you missed the i2p.exe discussion :( 21:35:04 <sponge> should wee? 21:35:07 <hottuna> I don't think our threat model includes I2P being illegal to run. 21:35:31 <hottuna> If that was the case ipv4 would be problematic as well. 21:35:42 <zzz> orion, I'm trying to keep our docs up to date w.r.t IPv6. The docs should match what's in my ipv6 branch now. 21:35:45 <sponge> ht: in some countries (china?) it is 21:36:20 <hottuna> And who runs i2p is the only additional information that would be leaked. 21:36:39 <zzz> the best way thru the GFW may be via IPv6, hard to see how it's a negative 21:38:09 <sponge> last misc from me--- So sorry I have been missing all the previous meetings. Again, difficult for me to do this day of the week, and hour. I will be more active very soon on everything as well... the talking stick is for the next persion... 21:38:13 <orion> zzz: Thank you. 21:39:03 <hottuna> Meeh: you missed #726, but are requested to do some testing of the patches that will be merged by topiltzin (i think that is the summary) 21:39:15 <hottuna> str4d: #741 was tabled for next meeting 21:39:22 <hottuna> sponge: nice :) 21:39:29 <sponge> I say bring up 741 now 21:39:32 <hottuna> Okay, anything else? 21:39:32 <Meeh> hottuna: noted. 21:39:39 <sponge> he's here, why not 21:39:46 <hottuna> fine by me 21:39:46 <orion> hottuna: Yes, minor thing. 21:40:01 <hottuna> ok, go orion! 21:40:04 <topiltzin> de-tablizing 741 ... :) 21:40:20 <orion> I was wondering if someone could get me my credentials for the firstname.lastname@example.org email account. 21:40:27 <orion> As well as update the website. 21:40:46 <sponge> orion: website is in mtn 21:40:56 <hottuna> update what part of the website? 21:41:03 <str4d> And no credentials required to update website. 21:41:18 <str4d> (Just create a mtn key and go) 21:41:25 <orion> str4d: email account 21:41:43 <hottuna> welterde handles that domain as far as I know. 21:41:46 <orion> Or, nevermind. The team.html page has already been updated. 21:41:46 <zzz> you'll be sorely disappointed, as I don't think we've ever gotten a single email there, but welterde is the person to ask to get added. It's just a redirector to a list, there's no account. 21:42:02 <orion> So right now it's just the email account. 21:42:20 <orion> I Will speak to welterde, thank you. I yield my time. 21:42:30 <hottuna> excellent 21:42:38 <hottuna> __Ticket #741 - process renamer on windows__ 21:42:45 <str4d> Okay, so briefly de-tablizing 741? 21:42:45 <hottuna> topiltzin, str4d 21:42:52 <hottuna> yes 21:42:58 <sponge> :-) 21:43:05 <str4d> Current situation: the process renamer works. 21:43:12 <str4d> (When called by the Tanuki wrapper) 21:43:23 <str4d> (or passed CLI arguments) 21:44:01 <str4d> I've tested it on Win7. topiltzin has verified that the code has been run on pretty much everything except Win8. 21:44:12 <str4d> So it needs testing there. 21:44:34 <hottuna> Does anyone have win8 access? 21:44:37 <zzz> 32/64? 21:44:52 * KillYourTV can 21:44:59 <str4d> The one part that is not working currently is the internal defaults - the arguments that are used if no arguments are provided externally (i.e. wrapper or CLI). 21:45:02 <KillYourTV> (win 8, x64 and/or x86) 21:45:09 <sponge> My daughter was going to upgrade to 8, but we found out it is really bad. 21:45:12 <str4d> zzz: I was running 64-bit Win7 21:45:30 <str4d> (IIRC) 21:45:30 <hottuna> so KillYourTV, you're up for some testing? 21:45:37 <KillYourTV> always 21:45:44 <hottuna> :) 21:45:52 <str4d> Thanks KillYourTV :) 21:46:11 <topiltzin> two remaining points I can see: 21:46:11 * KillYourTV will set up some VMs 21:46:14 <str4d> Testing just requires dropping the new i2p.exe into the install folder, and tweaking wrapper.config to use "i2p" instead of "java". 21:46:21 <topiltzin> 1. Icons - need them in different sizes, alpha channels, b.s. 21:46:36 <topiltzin> 2. Strings like license, description, etc. need reviewing 21:46:55 <str4d> 1. - I've set the VS file to refer to the icon in the installer/ dir in i2p.i2p. 21:47:22 <str4d> So it should be using the same icon as the launch4j-based i2p.exe uses. 21:47:25 <KillYourTV> I've not noticed but is the proposed "renamer" already in i2p.i2p? 21:47:36 <str4d> 2. - Agreed. 21:47:36 <hottuna> re Icons: i don't think that any high quality/svg files exist 21:47:51 <str4d> KillYourTV: yes - installer/c/i2pExe 21:48:10 <zzz> if it doesnt work w/o arguments, isnt that a problem? 21:48:10 <KillYourTV> cheers, I can handle the rest then ^^ 21:48:28 <str4d> zzz: yes it is. 21:48:35 <topiltzin> then some things like control panel are going to look weird 21:48:43 <str4d> That needs to be fixed if it is going to replace the launch4j-based i2p.exe 21:48:54 <topiltzin> str4d: are you sure it's a problem? I thought you hardcoded some defaults 21:49:17 <str4d> topiltzin: I did, but it just crashes and I couldn't work out why at the time. 21:49:29 <sponge> hardcodeing can be a bad thing, Do a path search first. 21:49:47 <str4d> But when I pulled out (what should have been) the exact same arguments and used them via the CLI, it worked fine.. 21:50:02 <str4d> sponge: different defaults. 21:50:13 <sponge> ahh 21:50:35 <str4d> sponge: these are the settings that I2P is run with if nothing else is there (no wrapper.config). See installer/i2pstandalone.xml 21:50:38 <topiltzin> str4d: in order KillYourTV to test you need to build the actual i2p.exe or have you commited that in mtn? 21:50:46 <str4d> (and the doBuildExe target in build.xml) 21:50:49 <sponge> str4d: you may have to do like I did for BOB, basically a double main() 21:50:53 <KillYourTV> topiltzin: it's in mtn 21:51:07 * KillYourTV already asked ^^ 21:51:14 <str4d> topiltzin: needs to be built - I wasn't going to commit the binary until we were close to actually using i. 21:51:21 <str4d> KillYourTV: I meant that the source is in mtn ^_^ 21:51:24 <sponge> the first main inserts missing args, passes it to the actual main() 21:51:31 <KillYourTV> oh...heh 21:51:58 <str4d> sponge: that's pretty much what is done - if args are passed they are used, otherwise default args are constructed. 21:52:05 <sponge> so you got main() and _main() 21:52:08 <topiltzin> ok so the i2p.exe is not in mtn? 21:52:08 <str4d> topiltzin: what is the format of launch.properties? 21:52:27 <str4d> topiltzin: correct. Just installer/c/i2pExe/i2p.c etc. 21:52:30 <sponge> the first is just a cleanup 21:52:37 <str4d> sponge: see installer/c/i2pExe/i2p.c for the code. 21:52:37 <dg> topiltzin: src yes, binary no 21:52:48 <sponge> will look, thanks 21:53:11 <sponge> I'll get back to you on why it is broken 21:53:27 <str4d> topiltzin: there were also several commented-out methods that I couldn't work out their purpose. 21:54:04 <topiltzin> that's fine, I can explain offline 21:54:15 <topiltzin> but KillYourTV needs a binary to test, can you build one? 21:54:54 <str4d> topiltzin: sure. 21:55:21 <topiltzin> launch.properties - I believe one line per property, need to double-check 21:55:39 <str4d> (unless you already have VS2008 KillYourTV - that's what it is built with) 21:56:05 <topiltzin> which brings up another interesting __misc__ point: 21:56:08 <str4d> topiltzin: I'm thinking that launch.properties could be like wrapper.config but for the standalone case. 21:56:23 <topiltzin> yeah 21:56:42 <str4d> (Because the current standalone i2p.exe is not adjustable at all) 21:58:33 <topiltzin> now that the project is loaded with cash (because some mysterious person donated 1000 BTC when they were still cheap) we should have some software licenses for things like vmware, visual studio, etc. 21:59:21 <hottuna> visual studio I can get for free or one of you guys 21:59:24 <topiltzin> I'm sure that KillYourTV has legally purchased his copies of Windows 8 :-D but technically it's the project that should be funding that 21:59:39 <zzz> microsoft is advertising $450 win8 computers on tv (Asus? Acer?), we could just buy one of those 22:00:05 <sponge> excellent idea zzz 22:00:16 <KillYourTV> (dreamspark copies, "for educational use") 22:00:27 <maidenboi2> tiger direct often has deals for 300-400 on low end laptops 22:00:27 <orion> If Microsoft offers student discounts, I can get them. 22:00:34 <orion> If you want to go that route. 22:00:37 <topiltzin> hottuna yes please (re VS) 22:00:51 <dg> wait 22:01:01 <dg> is the gamer laptop we bought win. 8? 22:01:19 <hottuna> do we really need toys? couldnt the testing be done on a vm? 22:01:27 <KillYourTV> echelon had his own windows. 22:01:45 <KillYourTV> and I do my testing in clean VMs 22:01:52 <sponge> str4d: I have vs around some place (it is very old) but I won't be using that. I'll simply review your code once pull and apply is finished here and advise you 22:02:14 <str4d> sponge: thanks. 22:02:59 <topiltzin> a vm is always better 22:02:59 <orion> I agree with hottuna regarding the VM. 22:02:59 <topiltzin> and we can pass around images for easier debugging etc. 22:02:59 <hottuna> alright. so are we happy with this topic/discussion? 22:02:59 <sponge> str4d: no problem. I've head my head buried in C, C++ and ASM for the last month 22:03:02 <zzz> a win8 netbook would be a hella lot cheaper than VS 22:03:52 <orion> zzz: What if I got a student copy of VS? 22:04:03 <hottuna> I was thinking of donating my student copy as well. 22:04:14 <topiltzin> orion: if you get a student copy i2p cannot technically use it 22:04:21 <sponge> My daughter could possibly get a student version too 22:04:27 <topiltzin> s/technically/legally/ 22:04:31 <iRelay> topiltzin meant: orion: if you get a student copy i2p cannot legally use it 22:04:31 <hottuna> topiltzin: why not? 22:04:34 <str4d> hottuna: yes over here. Two main action items: Fix the defaults (and provide a launch.properties); build an i2p.exe for KillYourTV to test. 22:04:37 <orion> It's for my education. 22:05:07 <hottuna> and not for a for-profit company/project 22:05:07 <topiltzin> beause it is a student copy for orion's education - it means only he can use it 22:05:26 <hottuna> ok. in that case I cant provide VS. 22:05:49 <topiltzin> what license does yours have? 22:05:58 <hottuna> and this stuff cant be built by mingw? 22:05:58 <hottuna> topiltzin: student 22:06:46 <topiltzin> you can use it to build i2p.exe or other stuff for i2p, the only thing you can't do is give it to someone else 22:07:23 <KillYourTV> what about vs2008 express? Is that limited to 32bit only? 22:07:46 <sponge> str4d: note! It is not good style to mix C++ comments in C code ;-) use /* */ 22:08:01 <KillYourTV> I suppose we need i2p.exe 64bit _and_ i2p.exe 32bit 22:08:32 <topiltzin> I *think* 32-bit only is good enough 22:08:35 <sponge> I also already see your problem 22:09:01 <topiltzin> good enough = runs on both 64 and 32 bit windows 22:09:19 <KillYourTV> I'm not sure a 32bit i2p.exe can load the 64bit wrapper. The 32bit wrapper can't load the 64bit jvm 22:09:36 <KillYourTV> dunno though about this 22:10:48 <sponge> str4d: i2p.c line 54, and the loop below -- you are not assiginging correctly... it should be '*new_argv' not 'new_argv' same for the loop below that. The final NULL should be OK 22:11:06 <K1773R> KillYourTV: how about a x86 which starts the x86 or x64 launcher? 22:11:44 <sponge> str4d: Try that, and it should work for you 22:11:47 <KillYourTV> that's what I'm saying, I don't know if it can work. 32bit binaries _usually_ cannot call x64 binaries. 22:12:47 <sponge> actually the first line may be OK, but the loop does need to be a * 22:13:26 <sponge> read_options, if returning as a pointer, needs to copy the pointer 22:13:45 <K1773R> KillYourTV: trough cmd.exe it should work as last resort, tough thats a win problem 22:13:48 <sponge> new_argv[i] = &(read_options[i-1]); 22:13:51 <sponge> like so 22:14:57 <topiltzin> sponge do you have access to a windows box? Can you help test this? 22:15:17 <topiltzin> sponge: also post any comments on trac #741 22:15:35 <sponge> I have a win 7 laptop, but can't test today. I'm short on time, and had to budget time to be here 22:16:17 <sponge> otherwise i would jump at it 22:16:52 <sponge> point is that you have a pointer to an array of pointers 22:17:41 <KillYourTV> I can basically test any/all versions of Windows 22:17:44 <sponge> you are not copying the pointer, your code is copying the first few chars, which will point to random crap and cause your crash 22:18:46 <sponge> new_argv = argv; <-- that is okay 22:18:59 <sponge> new_argv[i] = read_options[i-1]; <-- random crap 22:19:13 * hottuna is readying the meeting closing hammer 22:20:21 <hottuna> alright.. closing time 22:20:24 <str4d> sponge: I'm pretty sure that section is still the same as it was for limewireExe 22:20:31 <micster> Before everyone goes, I've been thinking of "non profit 501(c)(3) status" for the Invisible Internet Project. Would this be the place to talk about that or somewhere else? 22:20:38 <str4d> (Which *should* have been in a working state, according to topiltzin) 22:20:45 <hottuna> micster: yes 22:21:04 <dg> hottuna: we're done with #741? 22:21:22 <hottuna> i doubt we'll become done with it :P 22:21:29 <sponge> str4d: problem 2 22:21:33 <sponge> free(read_options); 22:21:45 <sponge> don't free them there 22:21:48 <micster> I saw a post in the forum about someone wanting to incorporate in Germany. I'm in the US and have an interest in pursuing this. 22:21:52 <str4d> KillYourTV: re: 32/64, what currently happens with the launch4j-based i2p.exe? That starts a separate java.exe process; is it built separately for 32 and 64 bit? 22:21:55 <hottuna> sponge: I've gotta go. Could you take care of the rest of the meeting? 22:21:58 <sponge> free them at the very end 22:22:09 <sponge> I'm about to go too 22:22:15 <hottuna> it just needs a final baf, and it's done 22:22:18 <hottuna> darnit! 22:22:25 <dg> micster: Great! Sadly, timing's pretty bad. Post about it on zzz.i2p ("the forum") if you can? 22:22:28 <str4d> sponge: I'll try your suggestion and report back. 22:22:31 <sponge> I think it is done 22:22:38 <micster> Ok 22:22:41 <str4d> (later though - afk now o/) 22:22:59 <sponge> str4d: double check that it is a pointer 22:23:01 * hottuna baf's the meeting closing hammer 22:23:06 * hottuna **baf** 22:23:17 <sponge> **BARF** :-) 22:23:35 <hottuna> summary posted at: http://zzz.i2p/topics/1397 22:23:42 <iRelay> Title: zzz.i2p: Meeting [4th June] (at zzz.i2p) 22:23:50 <RN> :) 22:23:57 <sponge> cool, I can now go run my errands 22:24:08 <topiltzin> great meeting everyone! 22:24:19 <dg> micster: the meeting is now finishing up and everyone seems to have a lot they want to get across. You'll get more exposure and brain time if you post it there. 22:24:53 <micster> Ok, I'll make the post. Maybe it can be discussed in a future meeting. 22:25:01 <micster> Just wanted to see if I was in the right place. 22:26:52 <RN> lots of good discussion. thanks for making the time to particpate y'all 22:27:07 <hottuna> :) 22:28:54 <zzz> micster, the correct thread for that is http://zzz.i2p/topics/1388 22:28:58 <iRelay> Title: zzz.i2p: Official I2P group (at zzz.i2p)