I2P dev meeting, June 4, 2013 @ 20:00 UTC

Quick recap

  • Present:

    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.
  • Misc?
    • 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.

Registro 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 press@i2p2.de 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[0]' not 'new_argv[0]' 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[0] = argv[0]; <-- 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)