diff --git a/i2p2www/meetings/logs/221.log b/i2p2www/meetings/logs/221.log
new file mode 100644
index 0000000000000000000000000000000000000000..1e050604001efd4abb725d465653da41e4ccce91
--- /dev/null
+++ b/i2p2www/meetings/logs/221.log
@@ -0,0 +1,319 @@
+21:01:00 <dg> So, who is here?
+21:01:11 <orion> Me.
+21:01:18 <str4d> o/
+21:01:37 <lillith-> i'm here :)
+21:02:10 <dg> eche|on, Meeh, KillYourTV, psi, hottuna
+21:02:21 <Umlaut> count me in too (as a spectator)
+21:02:28 * nom is listening, while coding on some side projects
+21:02:39 <dg> Feel free to contribute if you feel you have something to add.
+21:03:04 * dg waits a minute or two more
+21:03:27 <lillith> rundown of topics in the meantime dg?
+21:03:42 <dg> Topics:
+21:03:45 <dg> * Motivating the community - "are bounties appropriate?"
+21:03:45 <dg> * Managing money
+21:03:46 <dg> ** Making the project "official" - benefits/negatives/how
+21:04:24 <lillith> i had something to add *thinks*
+21:04:31 <dg> hm?
+21:06:37 * lillith can't remember... probably nothing too important anyway :)
+21:09:14 * dg frowns at the lack of others
+21:09:44 * LaughingBuddha spectates
+21:10:27 <dg> Let's start then
+21:10:54 * lillith remembered!
+21:10:59 <dg> hm?
+21:11:14 <dg> RN: ping
+21:11:25 <lillith> as kytv|away pointed out, if we're deciding on voting we need some sort of elegibility criteria :)
+21:11:49 <dg> aye
+21:12:07 <dg> Let's get started
+21:12:10 <dg> * Motivating the community - "are bounties appropriate?"
+21:12:13 <lillith> i expect asdfsdafsdafsd wishes to be invluded int points 1+2 :)
+21:12:24 <orion> Are bounties working?
+21:12:43 <dg> Everything merged into one big argument last time over bounties, management and BTC so trying to spread it out this time & be dignified.
+21:12:53 <LaughingBuddha> Who's the guy for bounties? eche|on?
+21:13:00 <lillith> yep
+21:13:11 <LaughingBuddha> Is he here?
+21:13:11 <str4d> Determining if bounties are working depends on what the defined purpose of a bounty is.
+21:13:11 <dg> define "working". Are they, IMO, bringing in the developers or fixes we need? No.
+21:13:18 <lillith> he's in control of all money - point 2 :)
+21:13:25 <orion> Then let's think of something else.
+21:13:40 <dg> The bounty system does not seem to be working for even the bounties themselves.
+21:13:54 <lillith> i think there should be some sort of benefit or incentive further than loving i2p
+21:14:09 <dg> A lot of the links on the page are 404s too but that's an unrelated issue
+21:14:12 <str4d> From the bounties page: " Instead, we are making use of a bounty system, whereby anyone can get support for working on something that people want implemented, and people who want to contribute to I2P can be assured that their support goes to what they care about."
+21:14:12 <lillith> we have to draw people in then keep them with our charm and civility ;)
+21:14:23 <LaughingBuddha> Not that I'm in the position to work on any of the bounties, but they seemed to quite vague last time i looked at them
+21:14:30 <LaughingBuddha> to be*
+21:14:37 <orion> The only thing that will draw attention to I2P is content.
+21:14:45 <dg> eche|on posted his thoughts here - http://zzz.i2p/topics/1359 - if he could not attend.
+21:14:48 <nom> imo bounties do not work, because a code base is only as good as its maintenance, and paying someone for 'completion' gives the wrong ideas/incentives about what we need in terms of developers, for code to be worth using on a distributed scale, it has to be continually worked on by motivated people. having one person create a code base, get paid and possibly disappear does nothing to benefit the community
+21:14:51 <iRelay> Title: zzz.i2p: Managing the project (at zzz.i2p)
+21:14:57 <lillith> str4d: instead, as opposed to...?
+21:15:17 <str4d> From that statement above, the purpose of bounties would seem to be to finance one-off drives to get specific features implemented.
+21:15:20 <Umlaut> are bounties appropriate? - I think it depends, imo bounties for devs, for particular project and where no contest/conmpetiotion is involved - in such cases they are appropriate
+21:15:26 <iRelay> <weltende@freenode> nom: it worked in the past if you look at the bounty page..
+21:15:30 <dg> str4d: Is that what we want?
+21:15:41 <LaughingBuddha> nom: agreed
+21:15:48 <str4d> Does that work? Somewhat.
+21:16:03 <str4d> weltende, exactly. There are clear examples of bounties being taken.
+21:16:18 <dg> http://www.i2p2.de/bounties.html
+21:16:29 <iRelay> Title: Bounties - I2P (at www.i2p2.de)
+21:16:34 <str4d> Bounty uptake IS slow, due to a lack of visibility/advertising/marketing/whatever, but the bounties are slowly getting taken.
+21:16:41 <dg> I don't know if the bounties which are being fufilled are perhaps not being fufilled the way we want too.
+21:17:03 <str4d> But, of the claimed bounties, not a single developer is currently with I2P.
+21:17:10 <dg> For example: "Datastore over I2P" - "CLAIMED for 700 €" - "duck, smeghead"
+21:17:20 <lillith> perhaps, change bounties to ..... and maintain your work for a reasonable time
+21:17:23 <nom> to get actual continuous development going, a better model is one of project/stipends, where people donate to a project with stated goals, and the people running that project pay the money out continuously to people who are actively working to accomplish those goals
+21:17:34 <dg> The solution was, IMO, hacky, the bountry $$$ was rather high for the hack and the two developers for that bounty are nowhere to be found.
+21:17:46 <str4d> dg: that's irrelevant - as per the current bounty outline, it is up to the donor to decide on the completion.
+21:18:01 <dg> What if multiple donors exist?
+21:18:08 <str4d> First donor.
+21:18:11 <orion> I don't like bounties. IMO, the one way to draw developers in is to draw attention to I2P.
+21:18:15 <str4d> (as per current outline)
+21:18:21 <iRelay> <weltende@freenode> lillith: not really needed imho if it's in the core router..
+21:18:25 <str4d> If a bounty is funded by I2P, then it does become relevant as I2P itself is the judge.
+21:18:32 <dg> Oh. That doesn't seem right. :s.
+21:18:54 <orion> IMO, the best way to draw attention to I2P is by providing content.
+21:19:06 <dg> Right, but some of the bounties can lead to content.
+21:19:13 <str4d> I'm not arguing for the current bounty system, just outlining it.
+21:19:44 <dg> str4d: right, and thanks.
+21:20:03 <nom> honestly i think a big part of the problem is that were conflating things that are directly part of the i2p code base, with things that are simply run ontop of i2p. ex translation vs datastore
+21:20:03 <str4d> The biggest problem with a semi-anonymous project like I2P is developer retention. The current bounty model does nothing to help that.
+21:20:42 <dg> I'm against the bounty system as it doesn't help the ecosystem we have, evidently (none of the developers are here today..) and I feel project funds could be better allocated.
+21:20:57 <nom> a bounty/payment for one person to do one specific part of the code base is fine in theory, but they don't work for creating continuous development of apps/systems that run ontop of i2p
+21:21:12 <str4d> I concur.
+21:21:17 <iRelay> <weltende@freenode> dg: well.. if there aren't taken, then the money isn't spent..
+21:21:54 <dg> weltende: The funds are in reserve, they cannot be spent as they are allocated for spending on $bounty.
+21:21:57 <nom> like adding unit tests to i2p could be worth a bounty, but it would probably be better to make an arrangement with coders who will be paid a small amount continuously to keep adding more unit tests as needed
+21:22:03 <iRelay> <weltende@freenode> if you however think that for a certain bounty the code isn't good enough or so.. it might be a good idea to specify more clearly in the bounty description what needs to be done
+21:22:26 <iRelay> <weltende@freenode> dg: which is only a problem if we have to spend the money right away
+21:23:01 <iRelay> <weltende@freenode> it's not reserved forever as you can see in the bounty page.. funds have gone back to the money pool before
+21:23:21 <dg> weltende: I doubt we will ever be at the point where we NEED the funds allocated to bounties but it seems redundant.
+21:23:44 <str4d> Fund allocation is beside the current point.
+21:23:59 <iRelay> <weltende@freenode> dg: exactly my point
+21:24:11 <lillith> dg: are competitions included in bounties or are they point 1.5?
+21:24:14 <str4d> There will always be money, in one way or another.
+21:24:26 <str4d> (Or not)
+21:24:29 <nom> i think the datastore is a great example of where bounties shouldn't be used, for something as complex as a universal datastore to be viable, it has to be its own project with active developers, paying someone for completion will get you something that is marginally functional, but it will never improve
+21:24:40 <LaughingBuddha> ^
+21:24:40 <str4d> nom: agreed.
+21:24:43 <dg> lillith: Competitions hadn't occurred to me but I suppose it would be the point after this.
+21:24:46 <Umlaut> Let me refer to the i2p artwork contest for 29c3 - Was that really a dev project? Was it appropriate to use bounties in it? While there was no even strict criteria stated?
+21:24:57 <str4d> The result will satisfy the bounty, but likely will not scale.
+21:25:00 <dg> nom: Couldn't have said it better myself.
+21:25:26 <iRelay> <weltende@freenode> nom: torrents were nothing but a bounty either..
+21:25:34 <LaughingBuddha> Umlaut: i thought they were echelons personal funds?
+21:25:54 <Umlaut> if I was willing to contribute to the contest, the bounty would rather discourage me?
+21:26:01 <lillith> (most) bounties are set by users - between giving them a choice and them not donating at all, at least with a bounty they have some say in what happens
+21:26:32 <nom> to put it another way... there are no bounties at google....
+21:26:32 <Umlaut> LaughingBuddha really? then sorry, I wasn't aware about that
+21:26:32 <nom> weltende yes but zzz is continuing to work on snark isn't he?
+21:26:47 <str4d> If I2P had an established structure for spinning off projects (or acting as an umbrella for them) then that would be a different matter (but that ties in to the later point about "official"ness).
+21:26:51 <LaughingBuddha> Umlaut: I might be mistaken but I thought i read that somewhere
+21:27:04 <str4d> I think that bounties are useful, but not in the way that they are currently being marketed.
+21:27:08 <lillith> LaughingBuddha: all i2p's funds are technically eche|on's personal money
+21:27:11 <dg> nom: zzz was around anyway though. I think his motivations and such are different than gaining rewards and the bounty program has little to do with it. I do not believe he gained anything from the torrent bounty either.
+21:27:18 <str4d> And that they shouldn't be the main focus.
+21:27:21 <iRelay> <weltende@freenode> nom: yes.. but without the bounty there wouldn't have been a codebase to begin with.. (and he was not part of the bounty dev team)
+21:27:21 <dg> We'll get to the money later..
+21:27:40 <LaughingBuddha> lillith: Doesn't he "manage" it?
+21:27:47 <LaughingBuddha> dg: ok
+21:28:10 <str4d> weltende, you are making a good point.
+21:28:14 <lillith> i2p is no legal entity, so it can't own anything. hence it is eche|on's personal money.
+21:28:29 <str4d> Bounties are useful for kickstarting code, not for continued development.
+21:28:36 <LaughingBuddha> lillith: I see
+21:28:36 <nom> if you want continuous development you should pay developers continuously to work on things they want to work on. donating money to get something done is fine, but it shouldn't be given as a lump sum to whoever can get an 0.0.1 working first, it should be used to fund project development over time
+21:28:39 <lillith> he could legally leave with it all one day (he wouldnt', but he could)
+21:28:48 <iRelay> <weltende@freenode> nom: and I don't really see your point with no bounties at google.. the people that work for google get paid to work there..
+21:28:52 <lillith> ^this
+21:29:27 <LaughingBuddha> But it seems we agree with the first part of nom's statement. No?
+21:29:30 <lillith> eg bounty of $X per month to work on something
+21:29:45 <LaughingBuddha> Yeah
+21:29:52 <iRelay> <weltende@freenode> or perhaps define milestones in the bounty?
+21:29:56 <Meeh> Seems like a good solution
+21:30:07 <iRelay> <weltende@freenode> (and upon reaching milestone $X you get $Y amount of money)
+21:30:07 <dg> That sounds good.
+21:30:14 <LaughingBuddha> milestones seem like a good idea
+21:30:17 <LaughingBuddha> but they need to be clearly outlined
+21:30:20 <dg> Milestones + continuous payment?
+21:30:20 <nom> lol thats what my point was, they get paid, and they do work, and the work they do isn't directly connected with how they get paid. ofc if they stopped doing work, they would stop getting paid, but their not getting paid for completing a specific piece of code, their getting paid enough to live on and spend their lives coding
+21:30:23 <str4d> Milestones is sort of like what the Unit Tests bounty currently has.
+21:30:27 <lillith> is it eche|on we have to ask nicely to change the website etc?
+21:30:38 <dg> no, website is in mtn
+21:30:41 <Umlaut> nom I agree with your point, paying to the devs who are reliable and known for being good contributors
+21:30:44 <str4d> lillith: no, anyone can change the website.
+21:30:54 <Meeh> Or keep a part of the bounty as a "continued support" payment per month of the application/whatever
+21:31:22 <Meeh> So we don't get outdated apps, libs, etc.
+21:31:29 <LaughingBuddha> Would the project be judged at every milestone then?
+21:31:44 <dg> LaughingBuddha: good point. Who by?
+21:32:00 <nom> eh, milestones are just smaller bounties... a simpler solution is to have a pool of money for a project, and someone/group of someones who pay the money to people who are actively working on it
+21:32:03 <dg> The "board"? (Againg, getting to this later).
+21:32:10 <LaughingBuddha> Dev board?
+21:32:10 <LaughingBuddha> yeah
+21:32:29 <nom> generally you would end up with the dev board being the same people who are getting paid ofc...
+21:32:46 <lillith> to make anything decided upon here 'official', is that as simple as someone checking an update to the website into mtn?
+21:32:55 <LaughingBuddha> how many active devs are there working on the i2p codebase?
+21:32:58 <Umlaut> also you need to take under consideration how the current donating system looks from the potential donor (someone new to i2p community especially) point of view
+21:33:04 <lillith> LaughingBuddha: one
+21:33:07 <dg> lillith: Kinda. And posting ot zzz.i2p. ;_;
+21:33:15 <dg> The dev board determine the state of $project and decide if it should continue to get funding?
+21:33:18 <Umlaut> i could be one of them
+21:33:25 <dg> LaughingBuddha: 2, 3?
+21:33:32 <LaughingBuddha> hmm
+21:33:47 <nom> the board / employees model seems to work pretty well for 99% of the corporations in the world. you have a group of people who are the most committed and have already contributed a lot who manage the money, and you have people who join and contribute and get paid for their efforts based on the judgement of the long time contributors
+21:33:54 <LaughingBuddha> What if we set up a board of min. 5 people who are knowledgeable on the subject?
+21:34:01 <LaughingBuddha> Devs + Users
+21:34:09 <Umlaut> and i would trust the system more if there was more than one person, something like mentioned already dev-board which handles the money
+21:34:24 <orion> What if you had to pay to be on the board?
+21:34:31 <LaughingBuddha> wut
+21:34:38 <nom> (this only works tho if you can separate i2p proper projects, from projects that just run on i2p, which should not be managed by the i2p dev team itself)
+21:34:38 <str4d> orion: not a good model.
+21:34:47 <str4d> inb4 Russian oligarch takes over I2P
+21:34:57 <LaughingBuddha> haha
+21:35:06 <nom> inb4 already happened, zzz = vladimir
+21:35:10 <orion> Pay in code.
+21:35:29 <LaughingBuddha> And how do you measure how much you have to pay?
+21:35:32 <LaughingBuddha> 200 lines of code?
+21:35:35 <lillith> some people are big contributers without coding
+21:35:46 <orion> No idea, just brainstorming.
+21:35:49 <nom> like any oligarchy the only natural system is election by the existing board
+21:35:49 <str4d> Exactly.
+21:36:03 <dg> So, would the normal "dev" (team) board (coming up later) decide if $project is worth paying out to?
+21:36:15 <dg> Overcomplication will lead to it not being done
+21:36:22 <lillith> 3 tiers: inner circle, outer circle, others
+21:36:30 <LaughingBuddha> lillith: i like that
+21:36:37 <lillith> other = new/ unknown people
+21:36:51 <lillith> outer circle = known/ trusted people
+21:36:51 <LaughingBuddha> because we don't seem to have enough devs for a real judge panel
+21:37:02 <Umlaut> dg I would think so as the devs should know *best* what project are most important/urgent/worth spending money on
+21:37:05 <lillith> inner circle voted for by outer circle
+21:37:20 <nom> its a hierarchy, the i2p project as a whole is more than just the i2p dev team, but they are the tip of the spear so to speak. they get / have the most donations / resources. but other projects built ontop of i2p wouldn't be managed by the i2p dev team, but could get funding from i2p proper
+21:37:23 <lillith> kind like meetings but more structured hierachally
+21:38:13 <dg> imo <+dg> Overcomplication will lead to it not being done
+21:38:37 <iRelay> <weltende@freenode> +1
+21:39:15 <dg> The whole (team/dev) "board" idea ties in nicely as we will be discussing this next anyway
+21:39:22 <dg> Should we leave this for another time or ...?
+21:39:28 <nom> in short, zzz eche and whoever else they consider to be part of the 'board' of i2p are in charge of the money/decisions (they already are), and other projects on i2p should be structured similarly with their own boards of decision makers. instead of bounties for a sub project (datastore, btc client, etc) the bountie should be given to the board for that project, and let them decide how to spend it to get things done
+21:39:39 <lillith> so shall we get back on topic or has bouties been discussed to death?
+21:40:49 <nom> and the decision to give a bounty to a board of devs for a project obviously has to be made by the board of i2p, that way you don't have 3 people show up, say their gonna do something, get the money and then never do it.
+21:41:13 <dg> nom: +1
+21:41:21 <Meeh> nom: +1
+21:41:24 <LaughingBuddha> nom: I think it's payed out upon completion
+21:41:34 <iRelay> <str4d@freenode> nom++
+21:41:46 <LaughingBuddha> nom: +1
+21:41:54 <dg> I think that's a good note to end on? :)
+21:42:14 <Meeh> Agreed
+21:42:24 <nom> in the future it would be better for donators to give directly to the sub project if a board/group already exists, instead of donating to eche to create a bounty. since if theres already a group working on it, they would be the best to determine how to use the money to accomplish those goals
+21:42:53 <dg> ok, moving on
+21:42:58 <Umlaut> nom that makes perfect sense
+21:43:01 <Umlaut> nom++
+21:43:11 * nom raises his glass, cheers mates
+21:43:18 <dg> I feel we have covered "managing money" mostly and it comes under "making the project official" anyway
+21:43:21 <LaughingBuddha> :)
+21:43:21 <dg> So let's do the latter?
+21:43:47 <lillith> clarify the position on money first for lurkers?
+21:43:54 <iRelay> <weltende@freenode> for an e.V. we would at least 7 people who are willing to go public as members
+21:43:55 <LaughingBuddha> Official = Register as Organisation?
+21:44:26 <dg> LaughingBuddha: yes
+21:44:29 <Meeh> in case register as a organization, in which country?
+21:45:01 <dg> lillith: Bounty funds should go to teams assigned by the core I2P board.. if we go ahead with that.
+21:45:04 <dg> Meeh: US, I assume?
+21:45:07 <Meeh> that also need deanonymization of sertiant people
+21:45:14 <Umlaut> ok so who are the brave souls to give up their anonymity (if that means going official)?
+21:45:17 <orion> What did you guys decide on?
+21:45:20 <iRelay> <str4d@freenode> Not necessarily the US
+21:45:28 <nom> idk if 'offical' designation would really be all that useful... i honestly can't see what the benefit would be
+21:45:31 <lillith> presumably the people have to be in the US too?
+21:45:54 <lillith> nom: a legal entity to donate to
+21:45:54 <nom> other than to put the project/people more on the radar of the powers that be...
+21:46:06 <Meeh> I can give out my identity, so no problem for me.. But I guess I'm not allowed into the US, so yea.
+21:46:17 <orion> Registration is stupid.
+21:46:28 <LaughingBuddha> dg: What are the benefits?
+21:46:39 <orion> Let's just spread out the money among different "accounts" managed by different people.
+21:46:55 <orion> I.e, the eche|on account, the zzz account, the dg account, etc.
+21:46:57 <LaughingBuddha> A wallet for each (sub)project?
+21:47:04 <dg> LaughingBuddha: Managing the project's money under "I2P" and not a singular person, or persons. An official guise is far less suspicious and accountable.
+21:47:09 <orion> No.
+21:47:12 <Umlaut> Do you think that going official would bring some real benefits to the i2p-world?
+21:47:14 <iRelay> <weltende@freenode> orion: not sure if the tax office might not find tht fishy
+21:47:14 <orion> Just different "accounts".
+21:47:32 * nom thinks the focus should be more on the logistics of the hierarchy of boards / democracy / voting thing. to actually have a system like that we would need either a well run website, or some sort of distributed system for it
+21:47:35 <LaughingBuddha> dg: I see
+21:47:46 <iRelay> <weltende@freenode> it would certainly bring a lot of paperwork
+21:47:54 <lillith> Umlaut: no more complaining about eche|on holding the money
+21:48:04 <iRelay> <str4d@freenode> nom++
+21:48:13 <iRelay> * str4d@freenode clones nom's brain
+21:48:14 <dg> nom: perhaps so, yeah. If we can arrange that, then we can come to a consensus on this..
+21:48:44 <orion> For the record, if you guys want to do something that requires giving up anonymity, I will do it.
+21:48:57 <dg> git clone http://git.repo.i2p/repo/nom.git
+21:49:00 <LaughingBuddha> I'd consider it
+21:49:03 <iRelay> <str4d@freenode> Going "official" is primarily a financial decision IMHO; it doesn't really contribute to the structure.
+21:49:22 <orion> Even though I am opposed to the idea of going to the government, I will do it if that is what the project decides is best.
+21:49:40 <dg> So, let's change the focus to the organizational structure
+21:49:51 <dg> (As that supercedes this anyhow)
+21:50:06 <iRelay> <weltende@freenode> str4d: well.. e.V. requires the members to vote for an board once a year... so we already have procedure for voting for the board then ;)
+21:50:14 <dg> "The Debian project only allows voting to be done by 'Debian Developers' (where "$developer" = "any sort of contributor"). If there is any sort of voting system enabled here it would need to be limited in a similar fashion, otherwise the system would be ripe for abuse, allowing for a small but vocal clique to push its demands through."
+21:50:21 <dg> Should we adopt a similar approach?
+21:50:25 <LaughingBuddha> (for the e.V.)
+21:50:44 <lillith> how much do you need to contribute to be a contributer?
+21:50:59 <iRelay> <str4d@freenode> The problem with the "Debian Developers" approach is the number of developers I2P has (very few)
+21:51:05 <lillith> ie is being active in #i2p-help enough?
+21:51:25 <Meeh> we must find a definition on contributer
+21:51:33 <sigint> for what?
+21:51:36 * lillith does not read 'contributer' as 'code contributer'
+21:51:55 <dg> str4d: "any sort of contributor".
+21:51:59 <lillith> sigint: read scrollback on sighup ;)
+21:52:10 <sigint> will do
+21:52:12 <iRelay> <str4d@freenode> dg, yeah, just read that part *derp*
+21:52:12 <nom> org structure is pretty simple in theory, just have a three tiered system of board members (elected by the existing board oligarchy), contributors (elected at large by the existing group of contributors), and users (everyone else, including people who /want/ to be seen as contributors, but havn't been around long enough for people generally to trust them)
+21:52:27 <lillith> sighup's like your little brother ;)
+21:52:39 <Umlaut> it all depends on the scale of contribution, reliability of the contributor and other factors
+21:53:06 <nom> sorta like, royalty, nobility, and the commoners....
+21:53:13 <Umlaut> reliability = being trusted by others
+21:53:16 <lillith> maybe a good start will be starting with rough numbers and working from there?
+21:53:31 <Umlaut> nom i'm actaually referring to what you have said
+21:54:09 <Umlaut> not reliable = someone who promised to do something, raised some hope and then run away (with a bounty..)
+21:54:24 <nom> hmm yah
+21:55:35 <dg> nom: "existing"?
+21:56:15 <orion> I gotta go. In closing I just want to say that having funds in one central location makes it easier to steal by oppressive governments, and that if we need to do something which requires giving up my anonymity, I will do it. Cya
+21:56:26 <nom> perhaps, supreme court(board), senate(contributors) and house(users) would be better... the board has the real control over all the decisions, but they take into account the votes of the contributors who are trusted identities, and the votes of the general population of users too, but you don't weigh that too much as theres no real protection against people making tons of user idents to vote with
+21:56:33 <lillith> bye orion :)
+21:56:37 <dg> Should we cut now and continue this next week at the same time?
+21:56:40 <nom> o/ orion
+21:56:50 <dg> An hour is long, I don't want this to drag on.
+21:57:04 <orion> Whatever you want.
+21:57:07 <lillith> dg: i'm up for that
+21:57:17 <iRelay> <str4d@freenode> I'm happy to continue next week.
+21:57:26 <lillith> gives time to ponder what has already been said
+21:57:29 <nom> sure, sounds good
+21:57:31 <iRelay> <str4d@freenode> We need to think this over.
+21:57:43 <iRelay> <str4d@freenode> And hopefully a few more people show up then ^_^
+21:58:07 * nom thinks the main takeaway here is that we could use a site / system to have group decision making / voting on
+21:58:07 <lillith> yes...
+21:58:14 <dg> I agree, sounds good guys. I'll update the zzz.i2p topic soon (poke me if I don't in 24 hours).
+21:58:25 <dg> thanks all. :)
+21:58:29 <LaughingBuddha> Good session
+21:58:32 * lillith picks up the baffer menacingly
+21:58:42 <dg> ;) go
+21:58:53 <Umlaut> thanks for letting me join
+21:58:53 <lillith> *baf* meeting closed :)
+21:59:04 <Umlaut> lights out!
+21:59:06 <lillith> thank you, and goodnight :)
+21:59:19 <sigint> Great. I joined in right at the end. I forgot that there even was one :|
+21:59:22 <nom> inb4 massive well timed netsplit
+21:59:25 <sigint> brb, reading backlog
+21:59:28 <sponge> o/
+21:59:40 <Umlaut> sigint timezone fail?
+21:59:50 <iRelay> <str4d@freenode> o/ sponge.
+21:59:50 <sponge> :-)
+21:59:57 <lillith> sigint: same time next week ;) say anything you missed the chance to then :)
+22:00:12 <sponge> orion wants to know about my ideas I see...
+22:00:50 <iRelay> <str4d@freenode> I pointed him in your direction sponge - figured pooling the creative juices was a good idea.
+22:01:05 <sigint> lillith: i hadn't explicitely planned on joining this meeting, but it would have been nice. no big deal though. i do have an idea that would be good to bring up in next week's meeting.
+22:01:09 <sponge> Yes, excellent.
+22:01:32 <sponge> I need people to help with my ideas... I have too many
+22:01:35 <sigint> idea: offer btc rewards for security vulnerabilities
+22:01:39 <lillith> sigint: it's dg you'll want to talk to on that then :)
+22:01:41 <iRelay> <str4d@freenode> (And orions work on i2pcpp has proven that he is good at implementing stuff ^_^)
+22:01:58 <iRelay> <str4d@freenode> sigint, post any ideas for next week in the zzz.i2p thread.
+22:01:59 * lillith raises eyebrows
+22:02:07 <lillith> vairy interesting
+22:02:10 <sigint> will do
diff --git a/i2p2www/meetings/logs/221.rst b/i2p2www/meetings/logs/221.rst
new file mode 100644
index 0000000000000000000000000000000000000000..aa831b9ebb3a1feda72b179f2d1dfa7fbf4255df
--- /dev/null
+++ b/i2p2www/meetings/logs/221.rst
@@ -0,0 +1,19 @@
+I2P dev meeting, March 26, 2013 @ 21:00 UTC
+===========================================
+
+Quick recap
+-----------
+
+* **Present:**
+ dg,
+ LaughingBuddha,
+ lillith,
+ Meeh,
+ nom,
+ orion,
+ str4d,
+ Umlaut,
+ weltende
+
+* **Next Meeting**
+ The next meeting is scheduled for Tuesday, April 2 @ 21:00 UTC (9:00PM)
diff --git a/i2p2www/meetings/logs/222.log b/i2p2www/meetings/logs/222.log
new file mode 100644
index 0000000000000000000000000000000000000000..f1211097ddfe2b3547a768a21a6fe8675984ebc1
--- /dev/null
+++ b/i2p2www/meetings/logs/222.log
@@ -0,0 +1,354 @@
+20:52:42 <lillith> okay meeting topics for today:
+20:54:22 <lillith> 1. Are bounties appropriate?
+20:54:29 <lillith> 2. Managing money
+20:54:29 <lillith> 2a. The ssl certs
+20:54:32 <lillith> 3. Making the i2p project official
+20:56:38 <lillith> 4. Procedure regarding decicions for the project (for example making it official)
+20:56:53 <lillith> for scrollback from last week if you were not here, http://sighup.i2p/irclogs/show?search=&user=&from_date=26+Mar+2013&to_date=26+Mar+2013&channels[]=#i2p-dev&per_page=3&page_format=Html
+20:56:53 <lillith> relevant zzz.i2p posts: http://zzz.i2p/topics/1359 for the meeting thread
+20:56:53 <lillith> http://zzz.i2p/topics/1366 for the bounties thread
+20:57:07 <iRelay> Title: zzz.i2p: Managing the project (at zzz.i2p)
+20:57:09 <iRelay> Title: zzz.i2p: I2P Bounty System - 2013 (at zzz.i2p)
+20:57:55 <trolly> chosen download bin file from zzz.i2p?
+20:58:02 <lillith> 1. Are bounties appropriate, and further bounty discussion
+20:58:05 <dg> Huh. Corruption again!
+20:58:50 <lillith> not sure who (if anyone) woud like to be pinged, so i'l go on
+20:59:22 <dg> trolly: that's a bug
+20:59:30 <trolly> haha, no problem
+20:59:41 <lillith> Last week it was decided that while bounties can be a good thing they may well need some looking at
+20:59:48 <trolly> a trojan bug? just joking..
+20:59:59 <dg> try to nab the output of `http_proxy="http://127.0.0.1:4444/" http://zzz.i2p/whateverurlbrokebefore` and check /logs for anything important
+21:00:05 <dg> it seems to be corruption, we saw this on id3nt.i2p in the past
+21:00:19 <lillith> i suggested some revisions of the 50 BTC syndie bounty to echelon, and he has updated it
+21:01:06 <lillith> which led me to two questions: can/should we employ people, ie give them a small amount of money regularly over an extended period?
+21:01:57 <lillith> and what exactly is the procedure on bounties funded by i2p's money, not directly from a donor
+21:02:20 * lillith opens up the floor for discussion
+21:04:50 <str4d_> dg: if it's occuring on another site, that suggests an I2P tunnel problem.
+21:05:26 <dg> str4d_: This happened before, is what I am saying. I do not know if the person affected == trolly but it was a few months back and none of us had any answer.
+21:05:41 * str4d_ was affected by it.
+21:05:52 <dr|z3d> dg: !!!
+21:05:56 <dg> Okay, more than one person.
+21:06:10 <dg> I believe zab was still around at the time which may tell you the period..
+21:06:21 <dg> dr|z3d: !!!
+21:06:24 <str4d_> But the issue is orthogonal to the current discussion =)
+21:06:36 * dr|z3d lols.
+21:06:47 <lillith> str4d_: implying discussion ;)
+21:08:32 <Shinobiwan> should i2p employ people? yes and no IMO. yes the people that continue to provide services that make i2p of higher quality (such as running the default IRC network and the more popular things like id3nt.i2p) are the best candidates to receive funds... in addition to the developer stuff which may have bounties attached.
+21:09:27 <str4d_> Shinobiwan: I wouldn't consider that employment though.
+21:09:50 <str4d_> "Employment" would be payments for the purpose of direct I2P development (code or otherwise).
+21:10:19 <dr|z3d> Shinobiwan: i2p should award effort and achievement.
+21:10:43 <lillith> what i had initially proposed was a small monthly payment for maintaining syndie, getting and keeping it into repos, bug fizing, etc
+21:12:25 <dr|z3d> otoh, i2p should not award aspiration, lazinesss or failure to deliver.
+21:12:32 <str4d_> That seems like a good compromise between the current bounty system and "proper" employment (which is hard for anonymous dev work)
+21:13:20 <str4d_> Right. So if a monthly system were set up, the payment would be subject to "sufficient" work having been done.
+21:13:31 <lillith> dr|z3d: absolutely. there is plenty of money to give to people who deserve it
+21:14:06 <str4d_> (So it would require a monthly meeting between the deciding people to analyze the various outputs during that period)
+21:14:09 <dr|z3d> lillith: we're swimming in it.
+21:14:35 <str4d_> I don't think that failure to deliver in one particular month should be cause for complete funding cuts, though.
+21:15:03 <dr|z3d> commitment, dedication, service.
+21:15:04 <lillith> people have afk commitments as well as internet ones
+21:15:07 <Shinobiwan> derp, pingout.
+21:15:37 <dr|z3d> remind me again why str4d_ isn't getting compensated? :)
+21:16:07 <str4d_> I'd propose a more flexible system where the "employee" gets paid for the months they do sufficient work in.
+21:16:07 <str4d_> (extended absences would be grounds for discontinuing funding though)
+21:16:22 <str4d_> lillith: exactly (like zzz currently)
+21:17:02 <str4d_> dr|z3d: under my proposed system, I wouldn't be at present =P
+21:17:26 <dr|z3d> the threat of halebopp dropping indent inspires zzz to offer hosting costs. so why does str4d_ have to battle with eche|on to get hosting funding?
+21:17:53 <dr|z3d> i offer one word: incompetence.
+21:17:56 <str4d_> dr|z3d: that's on a tangent.
+21:18:42 <dr|z3d> str4d_: more than likely.
+21:18:45 <darrob> what kind of maintenance work are we talking about here? shouldn't bugs and specific goals like repo inclusion be separate bounties so more than one person can claim them?
+21:18:56 <str4d_> There are two kinds of potential funding that I can see - the bounty/employment hybrid above, and donations from I2P towards community services. These should be treated separately.
+21:19:25 <dr|z3d> value added recompense.
+21:20:00 <dr|z3d> anything else is jizz. like paying 10btc for dogpoo.
+21:20:03 <lillith> str4d_: and competitions too, if there were ever to be another
+21:20:10 <str4d_> darrob: what we are trying to do is promote developers staying around.
+21:20:13 <str4d_> lillith: true, that's a third category.
+21:20:40 <dr|z3d> also beer. my bad.
+21:21:34 <RN> I wouldn't mind being paid beer for my humor... ;)
+21:21:43 <lillith> from echelon.i2p: - the I2P general fund will cover all needed costs of I2P - discussed by dev team and will be noted here and on official webpage
+21:22:09 <lillith> i think most things would be acceptable as long as they are discussed and agreed upon beforehand
+21:22:12 <str4d_> darrob: So rather than paying out a large lump sum for an arbitrary milestone and then the dev goes AWOL, we define smaller milestones and tasks within the confines of (what is currently called) the bounty, and the dev gets continual smaller payments.
+21:23:55 <str4d_> The bounty system would still exist for bounties proposed by third parties (as they have control over how their funds are used), but for bounties that would be proposed by I2P itself from I2P funds, the new system should be better for I2P IMHO.
+21:24:26 <dr|z3d> bounties are shit. hit and run contributors.
+21:25:09 <lillith> dr|z3d: hence why we are discussing a new system
+21:25:12 <dr|z3d> not to mention "i paid $200, I'm important attitudes"
+21:25:26 <str4d_> Part of the problem IMHO is that the current system only has a general description, with no concrete structure.
+21:25:49 <dr|z3d> lillith: excuse me if i'm not quite following the finer points of the argument :)
+21:25:52 <str4d_> For the new system, we need an agreed set of guidelines for proposing and managing funded tasks.
+21:26:59 <lillith> dr|z3d: if people want to waste/spend their money on bounties for improperly completed features, they should still be allowed to imho
+21:27:58 <str4d_> lillith: yep. Or they can choose to use the new system, by donating their money to I2P and putting in a request through whatever process we decide on to set up a new funded task.
+21:28:16 <lillith> i agree - there is money there, and we might as well use it, so we might as well use it properly and effectively
+21:28:56 <lillith> and then if the donor goes awol it's still technically a community owned bounty
+21:28:59 <darrob> i'd like to see people sticking around too, of course, but i don't see how bounties are shit at all. on the other hand the monthly thing sounds like trouble but i don't mean to dismiss it too quickly.
+21:29:02 <str4d_> Tasks funded via the new system need to be funded with money controlled by I2P, because it will be a panel of I2P representatives who decide what counts as "sufficient" work, not the donor themselves.
+21:29:03 <dr|z3d> lillith: i disagree. donate to the project and let the project decide how to distribute rewards.
+21:29:06 * Shinobiwan not sure if my other msgs went through
+21:29:17 <Shinobiwan> <Shinobiwan> bounty and employment != donation ... both should take place I think... employment/bounty for dev specific stuff... and perhaps donations for things like community services
+21:29:19 <Shinobiwan> <Shinobiwan> the employment part would need more of a specific set of conditions
+21:29:24 <Shinobiwan> <Shinobiwan> the community service part, really just needs the community to decide what's worth supporting
+21:29:27 <Shinobiwan> <Shinobiwan> and then dish out something appropriate
+21:29:50 <str4d_> dr|z3d: both options will be there.
+21:29:53 <K1773R> Shinobiwan: they didnt, now they did :)
+21:30:04 <str4d_> Shinobiwan: http://killyourtv.i2p/irclogs/latest.log.html for scrollback.
+21:30:07 <iRelay> Title: #i2p-dev logs for Tuesday, 2013-04-02 (at killyourtv.i2p)
+21:30:12 <dr|z3d> "oh we need russian" no we don't. we need commitment. not money chasing rats that disappear as soon as the bounty is awarded.
+21:30:24 <Shinobiwan> thx str4d, K1773R
+21:30:47 <lillith> dr|z3d: a new, private infrastructure may well appear for paying individuals for work - it might as well all be in together
+21:31:27 <str4d_> darrob: the reason most proposals sound like trouble is because we don't have a large enough developer base to properly run/support them. Therefore, a proposal that should result in a larger developer base is a good idea.
+21:31:42 <dr|z3d> money should not be able to dictate the project. period.
+21:32:01 <KillYourTV> and http://killyourtv.i2p/irclogs/%23i2p-dev.2013-04-02.log for "live" scrollback (the HTMLized logs are processed every 10 minutes or so)
+21:32:16 <dr|z3d> sponsor the project, great, but don't tell us how to spend the money.
+21:32:27 <darrob> dr|z3d: i like it if a money chasing rat fixed certain features in syndie and ran. what's the problem? maybe someday syndie will get a real developer again but that person won't necessarily need payment then. actually, as far as committed maintainers are concerned, it might actually be counterproductive to offer a pay for the job.
+21:33:05 <Shinobiwan> thx KillYourTV
+21:33:19 <KillYourTV> np
+21:33:36 <dr|z3d> darrob: the "problem" is money thinking it can dictate the agenda.
+21:33:39 <lillith> dr|z3d: i2p isn't being told how to spend its money, because bounty money never was i2p's. i2p/echelon just act as an escrow service
+21:33:39 <str4d_> Interesting point dr|z3d - I think part of this depends on what we define as the I2P project.
+21:34:42 <str4d_> lillith: I think the point dr|z3d is making is that, rather than being told how to spend its money, I2P is being told how to proceed, i.e. the development path is decided by the person with the most money.
+21:34:57 <darrob> dr|z3d: bounties are just offers (or cries for help). where do you get the negative attitude?
+21:35:21 <str4d_> And if the bounty process was adhered to as-is, that could potentially be rather problematic wrt the threat model.
+21:36:18 <lillith> that is a good point - i hadn't thought of it in that way before
+21:36:47 <Shinobiwan> a set of rules that says "This person must be paid on this date" is a good idea in that, that person can count on the income to be there when they need it. But on the other hand, it also may create drama when people fail to meet other people's expectations of what that money is really going towards... so I think it's probably not inappropriate to have meeting specifically for 'paydays' or whatever... if there's going to be a 'regular' thing.
+21:37:35 <dr|z3d> bounties are shit. show me ongoing commitment from bounty hunters and i'll change my view. except you can't. hit and run merchants.
+21:37:49 <str4d_> So maybe what needs to happen is that any tasks/sub-projects that affect I2P directly must be funded and controlled by I2P itself.
+21:37:52 <dr|z3d> darrob: i get the "negative" attitudes from half complete work that's awarded a bounty, only to disappear before you can say "um, i think you missed..."
+21:38:03 <dr|z3d> darrob: also, next time you pretend str4d_ is a css artist, don't bother. you insult yourself.
+21:38:10 <dr|z3d> and you also lose a friend.
+21:38:13 <lillith> dr|z3d: didn't str4d_ and zzz claim some bounties for the unit tests?
+21:38:17 <darrob> dr|z3d: what?
+21:38:20 <str4d_> dr|z3d: OT
+21:38:55 <dr|z3d> str4d_: yeah. also, beer. darrob: if you don't get it, *yawn*
+21:39:03 <str4d_> lillith: that was after the unit tests bounty was split up into sub-tasks/milestones (which I'd say was a step towards the proposed new system).
+21:39:45 <str4d_> dr|z3d: keep on-topic in here please =)
+21:39:56 <lillith> I think everything has been said on this topic now no?
+21:40:03 <Shinobiwan> if bounties exist IMO they should go towards the things that nobody currently part of the community knows how to or can do, IMO... not the things they dont have time for.
+21:40:06 * dr|z3d recalibrates.
+21:40:06 <darrob> i guess all i'm trying to say is that i question that hit and run improvements are necessarily a bad thing.
+21:40:19 <Shinobiwan> I2P will survive with everyone supporting it, not just the people who get paid
+21:40:30 <str4d_> darrob: they are good for kickstarting development in a new area
+21:40:37 <str4d_> But the I2P router/project is not a new area, IMHO
+21:40:53 <str4d_> So, how about the following:
+21:41:20 <dr|z3d> Shinobiwan: like design! *laughs* 5 years of asking for help, and not one iota of thought to offer a bounty *laughs*
+21:41:58 <str4d_> Projects that directly affect the I2P program/network can be funded only from I2P funds, and donors who want to contribute just donate to I2P.
+21:42:21 <dr|z3d> because designers aren't coders, ergo worth nothing. except when you're offering 10BTC/100$ for anything, including crayons.
+21:42:47 <str4d_> Projects that don't directly affect the I2P program/network but are still I2P-related (e.g. syndie) are eligible for bounties on new/substantial work.
+21:42:58 <dr|z3d> sorry, but I can't take this conversation _too_ seriously, built as it is on an anthill of incompetence.
+21:43:01 <str4d_> (But can also be managed via I2P if the donor wants)
+21:43:23 <lillith> dr|z3d: i'l ping you when we move on then :)
+21:43:26 <str4d_> But a bounty would need to be more accurately-defined than the current system allows.
+21:43:46 <dr|z3d> lillith: very good, sir :)
+21:44:04 <str4d_> s/allows/does
+21:44:10 <darrob> str4d_: does that imply that there will be an i2p management board to make those decisions? i think that was another week's discussion, right?
+21:44:32 <str4d_> darrob: yes.
+21:44:42 <str4d_> This is separate to any "official-ness".
+21:45:05 <lillith> str4d_: sounds good :)
+21:45:32 <str4d_> But there would be a panel of (elected) developers (coders/designers/contributors) who are trusted with steering the I2P project.
+21:45:46 <str4d_> I.e. something a bit more formal than what we currently have.
+21:46:00 <lillith> darrob: that's either coming up or later, depending on whether we want to continue
+21:46:26 <str4d_> Mmm. My proposal works under the assumption that such a panel exists in some form.
+21:47:05 <str4d_> (exact specifics being discussed later as above)
+21:47:21 <Shinobiwan> lulz
+21:47:28 <Shinobiwan> what's #i2p-dev then?
+21:47:35 <lillith> i disagree with the panel idea tbh
+21:47:38 <lillith> meetings seem to work well, and they let new people have a say too
+21:47:38 <lillith> it would need to be large enough to get a variety of perspectives
+21:47:38 <lillith> you never know who might offer then next amazing idea
+21:48:04 <str4d_> lillith: exactly.
+21:48:11 <Shinobiwan> it's that panel, but yea... it would need to become officially official
+21:48:18 <str4d_> But with the current size of the developer base, that's hard.
+21:48:25 <str4d_> It's a chicken-and-egg problem.
+21:48:35 <str4d_> And we need to break into the loop somewhere.
+21:51:05 <lillith> Shinobiwan: yea, thats basically what i'm trying to say :)
+21:51:05 <lillith> actually no it's not
+21:51:05 <lillith> #i2p-dev along with mailing lists, zzz.i2p, syndie, etc
+21:51:05 <lillith> anyone who wants a say should have a chance imho
+21:52:35 <str4d_> lillith: yes, but there still needs to be a group of people with a final say.
+21:52:53 <Shinobiwan> people need to know eachother w/out knowing one another... to the point I can say, str4d, KYTV, dr|z3d ... (a lot more but just for example) have been on the network for so long, and IMO all make I2P of higher quality. Collectively I think people can figure out and reach an agreement who would go on such a panel... even though nobody really knows eachother AFK. Opinions from new people to the project should be listened to also
+21:52:53 <Shinobiwan> however
+21:53:00 <str4d_> (i.e. the people who control the funds. Currently, that is a single person - eche)
+21:53:25 <str4d_> At least to begin with.
+21:53:52 <str4d_> The Debian developer model is a good one for making decisions like you suggest lillith - all done via voting.
+21:53:55 <lillith> so, everyone has a say, a few (3 or 4) people have the final say?
+21:54:10 <str4d_> (And a "developer" is just someone who has contributed in some way IIRC)
+21:54:25 <str4d_> But a voting system needs a larger base of "developers" first, I think.
+21:54:51 <str4d_> lillith: anyone can suggest an idea - that's never going to change.
+21:55:06 <Shinobiwan> in my mind it's more than 3 or 4 people.. more like 12+ and growing... but people that fail to make the meetings don't get to vote... (and if their vote is especially important/relevant, then the meeting might happen another time)
+21:55:12 <str4d_> But I2P has finite resources, and those resources need to be allocated appropriately.
+21:56:06 <str4d_> (the biggest resource being time from continual developers)
+21:56:20 <KillYourTV> as I wrote on zzz.i2p, I think votes such as via gpg signed messages to a mailing list would be better than irc. We've got mailing lists and they should be utilized.
+21:56:20 <str4d_> s/biggest/most important but currently most limited/
+21:56:23 <iRelay> str4d_ meant: (the most important but currently most limited resource being time from continual developers)
+21:56:28 <str4d_> KillYourTV: agreed.
+21:56:43 <Shinobiwan> ya gpg signed == much better
+21:56:54 <str4d_> Provides a transparent and verifiable archive of votes.
+21:57:09 <lillith> is that topic 1 over then?
+21:57:09 <darrob> i agree also. don't expect to accomplish any serious discussion on irc.
+21:57:12 * KillYourTV is 'stealing' ideas from Debian's system(s)
+21:57:19 <str4d_> http://www.debian.org/vote/
+21:57:22 <iRelay> Title: Debian Voting Information (at www.debian.org)
+21:57:39 <lillith> it's all open source, its there to be 'stolen' :)
+21:58:06 <lillith> 2. Managing money
+21:58:10 <KillYourTV> and with mailing lists you have the oh-so-helpful 'plonk' mechanism available if needed to raise the signal to noise ratio.
+21:58:21 <lillith> eche|on: ping
+21:58:24 <K1773R> KillYourTV: dont copy the "GPL Nazis" idea pls :P
+21:59:46 <lillith> afaict the money management wrt bounties has already been discussed enough
+22:00:12 <str4d_> KillYourTV: if we go the mailing-list route, the mailing-list needs to be usable entirely within I2P (currently not the case).
+22:00:23 <str4d_> (But also usable externally)
+22:00:33 <lillith> but there are other, non- bounty uses for money, for example purchasing ssl certificates
+22:00:36 <KillYourTV> agreed
+22:00:53 <darrob> str4d_: the nntp interface should qualify.
+22:00:53 <KillYourTV> and agreed to lillith's last point (ofc)
+22:01:04 <lillith> dr|z3d welt weltende welterde echelon
+22:01:07 <darrob> ...which i *think* is functional.
+22:01:10 <KillYourTV> are they linked?
+22:01:30 <KillYourTV> I know they were supposed to be but the last I checked (months ago) they weren't.
+22:01:38 <Shinobiwan> purchasing ssl certificates would go w/ donations IMO ... community services ... the same way to decide what the money goes towards as donations.
+22:01:41 * KillYourTV fires up the nntp tunnel
+22:01:41 <darrob> you can at least read through it.
+22:01:44 <lillith> can we keep this ontopic guys, project management is coming up :)
+22:02:01 <Shinobiwan> i.e.. have a meeting... say "we need this"... "agree?" ... panel says OK ... majority of panel green light
+22:02:32 <Shinobiwan> not so quickly, but the general idea.
+22:02:32 <Shinobiwan> hehe
+22:02:47 <str4d_> Shinobiwan: can fall under the same vote system proposed above.
+22:03:14 <Shinobiwan> yep
+22:04:16 <iRelay> <weltende@freenode> well the ML interface is accesible via i2p more or less.. http://vmfwbic2brek2ez223j6fc6bl5mmouzqvbsch45msvyyzih3iqua.b32.i2p/ still contains redirects to lists.i2p2.de.. not sure what to do about those
+22:04:24 <iRelay> <iRelay@freenode> Title: lists.i2p2.de Mailing Lists (at vmfwbic2brek2ez223j6fc6bl5mmouzqvbsch45msvyyzih3iqua.b32.i2p)
+22:04:32 <Shinobiwan> if there is such a panel, it is not finalized at a fixed number of people... IMO... it should grow, and grow and grow... so, whatever panel currently exists, should have some procedure to bring in new panel members regularly
+22:04:43 <darrob> we need a central party with a politburo and the users' congress. :)
+22:04:46 <KillYourTV> FTR, the mailing lists as currently set up are not available via nntp.
+22:05:04 <iRelay> <weltende@freenode> (haven't added it to the hosts.txt yet)
+22:05:42 <KillYourTV> (at least not under i2p.*)
+22:06:27 <iRelay> <weltende@freenode> hmm.. they should be.. but maybe not under i2p.*
+22:06:46 <iRelay> <weltende@freenode> I didn't set it up.. so don't really know anymore ;)
+22:06:58 <darrob> KillYourTV: i think i2p. are welt's preexisting groups. the new ones are alt.privacy.i2p.dev/general and alt.privacy.syndie.dev/general.
+22:08:42 <KillYourTV> ah...nvm me. now that I refreshed the list again I see those new ones.
+22:09:00 <KillYourTV> sorry
+22:09:03 <iRelay> <weltende@freenode> ah.. right.. slrn didn't show them as they didn't contain unread messages
+22:09:34 <darrob> i'm still confused why there are no messages. i really thought i saw a couple of test messages before.
+22:09:45 <lillith> can we get back on topic please?
+22:10:23 <lillith> i, and surely others want to know what's going on with ssl certificates for the i2p domains
+22:11:17 <KillYourTV> i didn't see the topic change, just <lillith> but there are other, non- bounty uses for money, for example purchasing ssl certificates /me zips it
+22:11:56 <lillith> ahh, sorry
+22:12:06 <lillith> <lillith> can we keep this ontopic guys, project management is coming up :)
+22:12:23 <KillYourTV> and what's the topic? ;) (I didn't see that switch)
+22:12:30 <lillith> <lillith> 2. Managing money
+22:12:41 <lillith> <lillith> afaict the money management wrt bounties has already been discussed enough
+22:12:41 <str4d_> lillith: eche is currently sourcing the required money.
+22:12:48 <lillith> <lillith> but there are other, non- bounty uses for money, for example purchasing ssl certificates
+22:13:16 <str4d_> <kytv2> eche|on: any updates on the certificate situation? I haven't had to get "real "certs for a while and don't know how long the verification process takes nowadays.
+22:13:19 <str4d_> <eche|on> kytv2: I am on the hunt for 3k € and cert requests...
+22:13:29 <lillith> so it's under control then?
+22:13:36 <iRelay> <weltende@freenode> and pushed..
+22:14:14 <KillYourTV> yes, it's being taken care of
+22:14:21 <orion> Can I reiterate my opinion that it's dangerous to have one person managing all the money?
+22:14:45 <orion> ok
+22:15:00 <dg> Current topic = ?
+22:15:03 <orion> It's not being put in to some off-shore corporation, right?
+22:15:14 <lillith> <lillith> 2. Managing money
+22:15:21 <str4d_> orion: no.
+22:15:58 <iRelay> <weltende@freenode> afair eche wanted to speak with an lawyer about making i2p an official entity of some kind
+22:15:58 <lillith> dr|z3d: ping :)
+22:16:12 <str4d_> Currently our funds lie in a (bank?) account owned by eche|on and (mostly) in a Bitcoin wallet held by eche|on.
+22:16:49 <KillYourTV> yes, that's right, in .at IIRC
+22:17:07 <KillYourTV> (wrt: 'official entity')
+22:18:46 <lillith> at as in austria?
+22:18:53 <dg> yes
+22:19:19 <iRelay> <weltende@freenode> (not australia *scnr*)
+22:19:46 <iRelay> <weltende@freenode> (running gag from EEVblog if you are curious)
+22:20:26 <lillith> okay, looks like we've moved on again
+22:20:41 <lillith> 3. Making the project official
+22:21:12 <str4d_> lillith: re: money management, it's rather dependent on both the "official" status of the project, and the project management status.
+22:21:30 <str4d_> (The former re: where funds are kept, the latter re: how funds are spent)
+22:22:14 <lillith> ok, fair enough :) we can straddle points 2 and 3 for a while then :)
+22:25:16 <trolly> must go
+22:25:19 <trolly> bye
+22:25:47 <trolly> later I'll send yo new translaion str4d_
+22:29:26 <lillith> or not, as the case may be
+22:30:11 <lillith> i'd suggest time to move on :)
+22:30:28 <iRelay> <jenkins@kytv> Starting build #28 for job I2P-Bote
+22:30:28 <lillith> 4. Procedure for making decisions in i2p
+22:31:27 * KillYourTV votes for taking long discussions about important decisions to a mailing list
+22:31:30 <iRelay> <jenkins@kytv> Project I2P-Bote build #28:SUCCESS in 1 min 3 sec: http://jenkins.killyourtv.i2p/job/I2P-Bote/28/
+22:31:34 <lillith> so, mailing list, hierachy, etc
+22:31:37 <KillYourTV> That way anyone can take part when he/she can
+22:31:50 <lillith> i'd like to put in an honourable mention for syndie here
+22:31:56 <iRelay> <weltende@freenode> +1
+22:32:03 <iRelay> <weltende@freenode> (@ML)
+22:32:04 <lillith> everything is signed by default, for a start
+22:33:18 <KillYourTV> I like syndie too (ofc), but mailing lists would be easier for outsiders to take part
+22:33:45 <lillith> but yes, i agree in principle. no point hanging around waiting for discussion that clearly isn't happening
+22:33:48 <KillYourTV> that's not to say that discussions can't be mirrored to syndie...
+22:34:33 <iRelay> <weltende@freenode> yeah.. nntp syndie gateway or so would be nice to have
+22:34:36 <lillith> and of course, officially moving is only one thread away ;)
+22:35:54 <KillYourTV> 21:00 UTC isn't handy for everyone. On a mailing list time zones mean nothing. On a mailing list there no netsplits, relay problems, or ping outs. For meaningful discussions a mailing list (IMHO) is _THE_ way to go.
+22:36:30 <dg> KillYourTV: I agree.
+22:37:54 <KillYourTV> irc is good when you need pretty-damn-close-to-realtime...but "we need a new domain" doesn't have that kind of urgency. Post it and it'll be addressed when $user can address it.
+22:37:54 <lillith> imho syndie has all the benefits of mailing lists and more, the only issue is accessability for outsiders
+22:38:32 <lillith> then again, how many people that we want to include already use mailing lists?
+22:39:03 <KillYourTV> There's been talk of a Syndie webapp" but I don't think that's gone (and will) go anywhere.
+22:40:20 <KillYourTV> I'd gather that more use mailing lists than IRC.
+22:40:31 <lillith> i don't want to dominate a discussion on syndie vs ml here, but i think it's something woth considering
+22:41:25 <iRelay> * weltende@freenode prefers his mail/nntp client tbh
+22:42:04 <KillYourTV> syndie via mutt would = 'win'
+22:43:14 <lillith> this topic also includes hierachy, which was touched upon before but imo needs some expansion
+22:45:09 <dg> I don't know if we can come to a consensus on anything AND have a discussion easily with IRC meetings anymore.
+22:45:28 <dg> It worked in 2006 when it was more of a quick update on the project but it's not anymore and it involves lengthy debates/discussion.
+22:46:40 <lillith> having more time to think through things would result in on topic, well thought out, clear discussion
+22:46:47 <lillith> threading also = win
+22:47:13 <iRelay> <weltende@freenode> +1
+22:47:21 <KillYourTV> +1
+22:47:28 <dg> +1
+22:47:39 <dg> might I add: nntp, fuck yeah.
+22:47:50 <lillith> irc meetings were always an experimental thing, and the experiment failed :)
+22:48:05 <dg> hey, lillith, at least we're having the discussions now, right? :)
+22:49:40 <iRelay> <weltende@freenode> imho we should keep irc meetings and move things that take a long time in the meeting or which has a lot of discussion to the ML
+22:50:11 <lillith> yep :) seems like no-one actually likes meetings anyway haha
+22:50:15 <dg> I think it's mainly due to the timing.
+22:50:18 <dg> And pressure to respond in a fast manner..
+22:50:18 <dg> postman: http://zzz.i2p/topics/1367
+22:50:18 <lillith> but there's no chance of getting a time thats good for _everyone_
+22:50:18 <lillith> plus some people have irregular schedules
+22:50:18 <dg> Exactly.
+22:50:25 <iRelay> Title: zzz.i2p: I2P and e-mail (at zzz.i2p)
+22:50:30 <lillith> with a heavy heart, and feeling rather poetic, i'd gladly baf the last meeting ;)
+22:50:41 <dg> weltende: I was thinking this.. keep irc meetings for discussion of some things in the ML (actually doing something & such). W
+22:50:44 <dg> go for it, lillith.
+22:51:26 * lillith bafs the meeting closed
+22:51:36 <lillith> thank you, and goodnight :)
+22:52:01 <iRelay> <jenkins@kytv> Starting build #103 for job I2P
+22:52:09 <lillith> can susimail handle mailing lists?
+22:52:41 <KillYourTV> sure, but I'd use a 'real' client like claws or mutt
+22:53:04 <KillYourTV> (just a matter or preference)
+22:54:55 <lillith> ahh, thats okay then :)
+22:56:33 <iRelay> <jenkins@kytv> Project I2P build #103:SUCCESS in 4 min 34 sec: http://jenkins.killyourtv.i2p/job/i2p/103/
+23:01:15 <iRelay> <jenkins@kytv> Project I2P UnitTests build #74:SUCCESS in 4 min 31 sec: http://jenkins.killyourtv.i2p/job/UnitTests/74/
+23:04:51 <KillYourTV> and +1 to meetings continuing with the bigger things being taken to mailing lists/forums/syndie.
+23:05:54 <KillYourTV> IRC is good for quick status updates..but a "newsletter" of sorts could work for that purpose too.
+23:06:19 <lillith> it's nice to have a start, with some goals, and an end, with a consensus
+23:06:22 <dg> mailing list also works for alerts. see how tor do it with consensus issues.
+23:06:46 <lillith> 'today THIS is what we decided and THIS is what we're going to do about it'
+23:07:29 <lillith> i'm not sure but i imagine ml discussions as dragging on with no distinct endpoint
+23:07:52 <lillith> +1 for newsletter though
+23:08:33 <KillYourTV> they can, sure...but I think more will be accomplished on a long ML discussion than a 4-5 hour long irc meeting.
+23:09:08 * lillith signs up with an open mind :)
+23:09:38 * psi likes the idea of a mailing list
+23:09:53 <K1773R> where is the ML?
+23:10:01 * KillYourTV really likes MLs but they (the ones on the Internet) will probably cause his AFK identity to be leaked...heh
+23:10:12 <KillYourTV> lists.i2p2.de i think
+23:10:39 <KillYourTV> and (/me scrolls up)
+23:10:54 <KillYourTV> http://vmfwbic2brek2ez223j6fc6bl5mmouzqvbsch45msvyyzih3iqua.b32.i2p/
+23:11:08 <iRelay> Title: lists.i2p2.de Mailing Lists (at vmfwbic2brek2ez223j6fc6bl5mmouzqvbsch45msvyyzih3iqua.b32.i2p)
+23:11:24 <dg> it just redirects
+23:11:55 <KillYourTV> there's also nntp.welterde.i2p
+23:12:37 <KillYourTV> alt.privacy.i2p.*, alt.privacy.syndie.*
+23:13:16 <KillYourTV> (cheers darrob for pointing me to the right usenet groups)
+23:14:57 * RN wanders off to tinker with thundirbird
+23:17:46 <str4d_> +1 to meetings continuing (but sticking to time) and +1 to "important" discussions on the ML.
+23:19:32 <iRelay> <weltende@freenode> for you interested.. posting is atm allowed for the following groups:
+23:19:35 <iRelay> <weltende@freenode> post: "i2p.*,alt.anonymous,alt.anonymous.*,alt.privacy.anon-server,alt.privacy.anon-server.*,alt.privacy.i2p.*,alt.privacy.syndie.*"
+23:25:35 <KillYourTV> this will have to be fixed before "important" discussions make their way there http://lists.i2p2.de/pipermail/i2p-general/
+23:25:42 <iRelay> Title: The I2p-general Archives (at lists.i2p2.de)
+23:26:27 <KillYourTV> ...unless the messages were purposely wiped (which wouldn't make sense)
+23:30:13 <iRelay> <weltende@freenode> hmm..
+23:30:21 <iRelay> <weltende@freenode> no idea atm.. but heading to bed now
diff --git a/i2p2www/meetings/logs/222.rst b/i2p2www/meetings/logs/222.rst
new file mode 100644
index 0000000000000000000000000000000000000000..6432b8b80a118d2c606dc1e488e8c4ae9ae4e5c2
--- /dev/null
+++ b/i2p2www/meetings/logs/222.rst
@@ -0,0 +1,17 @@
+I2P dev meeting, April 2, 2013 @ 21:00 UTC
+==========================================
+
+Quick recap
+-----------
+
+* **Present:**
+ dg,
+ dr|z3d,
+ K1773R,
+ KillYourTV,
+ lillith,
+ orion,
+ RN,
+ Shinobiwan,
+ str4d,
+ weltende
diff --git a/i2p2www/meetings/logs/223.log b/i2p2www/meetings/logs/223.log
new file mode 100644
index 0000000000000000000000000000000000000000..d870bf07d7559c0ad8fc612a32486793d9a467c9
--- /dev/null
+++ b/i2p2www/meetings/logs/223.log
@@ -0,0 +1,165 @@
+19:56:52 <hottuna> Hi@all && (welt||welterde||weltende)
+19:57:24 <eche|on> ;-)
+20:00:33 <iRelay> <jenkins@kytv> Starting build #182 for job I2P
+20:01:11 <hottuna> Mathiasdm, Meeh, postman, str4d, _sponge, KillYourTV, Complication
+20:01:19 <hottuna> Alright, lets get this meeting started
+20:01:33 <eche|on> meeting? hmm
+20:01:33 <hottuna> Agenda:
+20:01:39 <hottuna> * New bounty system
+20:01:44 <hottuna> * New bounties
+20:01:49 <hottuna> * Misc?
+20:02:21 <hottuna> __New bounty system___
+20:03:25 <hottuna> During this summer I'll have some time over for I2P development, but I also have to pay my rent which is why a new bounty system or at least a new set of bounties and sub-bounties will be suggested
+20:03:51 <dg> \o
+20:04:37 <iRelay> <jenkins@kytv> Project I2P build #182:SUCCESS in 4 min 7 sec: http://jenkins.killyourtv.i2p/job/I2P/182/
+20:05:00 <hottuna> after discussing the idea with eche|on, it seems like the best option for payed work is via the bounty system
+20:05:44 <hottuna> to make it work I'll suggest at least one large bounty and then create sub-bounties for it
+20:06:27 <hottuna> the sub bounties will be created and closed on a bi-weekly schedule
+20:06:41 <hottuna> (preferably by holding a meeting like this when a sub bounty is to be closed)
+20:07:27 <eche|on> you know my opinion, and so I just wait for input ;-)
+20:07:35 <hottuna> Currently the i2p project has a lot of funds which aren't doing us any good
+20:08:10 <hottuna> and allowing me to contribute to some much needed problem areas in i2p should be a good thing overall
+20:08:51 <hottuna> Does anyone have any questions or feedback at this idea?
+20:09:26 <hottuna> I've talked to zzz, eche|on, postman and Mathiasdm earlier and they have approved
+20:10:07 <hottuna> I've tried to reach welt/welterde/weltende, _sponge, badger and KillYourTV but have not gotten any response from them
+20:10:23 <iRelay> <jenkins@kytv> Project I2P UnitTests build #153:SUCCESS in 5 min 36 sec: http://jenkins.killyourtv.i2p/job/UnitTests/153/
+20:10:35 <hottuna> But I'd like to know what the rest of the inhabitants of #i2p-dev think about the idea
+20:10:52 <dg> I agree that we should be doing something with the funds
+20:11:08 <dg> An organized method of doing so is useful, I don't disagree at all so I'm remaining mute
+20:12:04 <hottuna> dg, does this seem like a good way of doing something useful?
+20:13:00 <dg> yes. The bounty system already works, we should build upon it
+20:13:19 <zzz> you're proposing using existing funds? euros or BTC?
+20:13:21 <hottuna> As far as bounty amounts go, 325€ per bi-weekly sub-bounty is what I need to cover my basic costs of living
+20:13:47 <hottuna> euros are safer and simpler for me
+20:14:07 <hottuna> but maybe parts could be payed in btc
+20:14:42 <hottuna> in any case the bounty should be set in euros and then possibly payed out in btc
+20:14:47 <zzz> eche|on, whats our balances?
+20:15:27 <hottuna> and to answer your question, Im proposing using existing funds
+20:15:27 <eche|on> http://echelon.i2p/donations/index.html - still on those sums
+20:15:32 <iRelay> Title: Donations (at echelon.i2p)
+20:15:40 <eche|on> so ~28k€ and 626 BTC
+20:16:47 <dg> hottuna: What work will you be performing?
+20:17:22 <zzz> appx. how many hours a week are you proposing to work?
+20:17:35 <hottuna> that is point two on the agenda, but i'm primarily thinking about improving on our floodfill issues
+20:17:57 <hottuna> 40 h/week. So full time.
+20:18:56 <zzz> so round numbers, 8 euros/hour
+20:19:18 <zzz> nope. 4 euros/hour
+20:19:20 <hottuna> in my mind that sounds reasonable/cheap
+20:19:35 <zzz> 325/80
+20:20:13 <zzz> mcdonalds isn't hiring? :)
+20:20:35 <hottuna> i think burger king has payed me more an hour :P
+20:21:06 <eche|on> you worked for a burger king? hell,... I should have visited your working office^^
+20:21:35 <zzz> appx. how many weeks you propose to work?
+20:21:56 <hottuna> lets see.. this will be a rough number
+20:23:19 <hottuna> I should manage at least 8, but it could be more or less than that
+20:24:10 <zzz> so a 1300 euro commitment from us
+20:24:24 <hottuna> yeah
+20:24:49 <hottuna> more than that would have to be discussed in a meeting
+20:25:18 <zzz> anybody remember what we paid jrandom monthly?
+20:26:08 <hottuna> let's see what the internet archive says
+20:26:10 <eche|on> less. ~500$ IMHO
+20:26:39 <zzz> he was more of a hippie than tuna is :)
+20:26:50 <hottuna> $465 USD/month
+20:27:11 <hottuna> I'm hippying as hard as I can damnit!
+20:27:52 <dg> hippy harder!!
+20:28:49 <hottuna> alright, so does anyone have any objections or questions?
+20:29:15 <zzz> no objection
+20:29:41 <Mathiasdm> sounds good
+20:30:25 <dg> ditto
+20:30:54 <hottuna> Alright. Then we are all happy about this
+20:31:32 <hottuna> For the record: As no complaints have been raised, we'll proceed with the new bounty system.
+20:31:47 <hottuna> __New bounties__
+20:32:34 <hottuna> The floodfill system has some issues, including attack resistance and scalability.
+20:33:02 <hottuna> Replacing it is the first bounty that I will suggest.
+20:33:30 <hottuna> I've talked to zzz about some alternatives
+20:33:47 <hottuna> and step one appears to be to move to a kademlia based netdb
+20:34:30 <hottuna> zzz has in fact already started by implementing kademlia in i2psnark
+20:34:59 <hottuna> this is probably a good base for for a netdb network
+20:35:53 <hottuna> there are some modifications that can be made to kad to make it more probabilistic and avoid the worst aspects of eclipse and sybil attacks.
+20:36:01 <zzz> I'm not sure "replace" is the right word. And also not sure it's the top of my list. Our ff system is actually in pretty good shape right now. But I'm not sure how much you want to get into discussing it now.
+20:36:27 <zzz> A reasonable sub-bounty may be just to analyze the current situation and make proposals
+20:36:41 <hottuna> replace would be a long term goal, initially adding a second netdb backend would be the goal
+20:36:58 <hottuna> yeah, replace is the wrong word.
+20:37:09 <zzz> but sure, the UCSD folks highlighted some issues.
+20:37:35 <zzz> ignoring vulnerabilities for a moment, I think we're actually good for a couple years of growth w/o changes
+20:38:06 <Mathiasdm> 22:37 < zzz> A reasonable sub-bounty may be just to analyze the current situation and make proposals <-- sounds like a good idea if it's time-boxed
+20:38:53 <hottuna> spending two weeks on an analysis might be overkill, but having a meeting and discussing the alternatives after a week might be good
+20:38:55 <zzz> what's _not_ realistic is replacing ffs with R5N this summer.
+20:39:09 <hottuna> zzz, agreed
+20:41:24 <hottuna> there might also be a need for some work surrounding development like multirouter support
+20:41:24 <hottuna> which would make development easier
+20:41:24 <zzz> fyi for everybody, the netdb roadmap in my head is 1) encrypted lookup responses and 2) migrate the snark kad back to router
+20:41:24 <Meeh> like the ideas
+20:41:35 <Meeh> ./roadmap
+20:41:49 <dg> yeah
+20:44:21 <hottuna> I don't think that 2 full weeks are needed for this
+20:44:27 <Meeh> yea
+20:45:21 <dg> "alternative exploration"?
+20:45:30 <Meeh> as in the exploration tunnels right or?
+20:45:30 <zzz> depends how long before your head explodes
+20:45:37 <zzz> what else on your list?
+20:45:45 <hottuna> "alternative exploration" = {what technology?, if dht-which?, what code-base?}
+20:46:03 <hottuna> maybe one week, and if I have time to spare I'll start with the multirouter stuff.
+20:47:09 <hottuna> I'm not sure, but some of the bounties like ipv6 will have to be completed soon as ipv6 looks to be actually deployed now
+20:47:40 <dg> zzz is working on ipv6 a load but he my appreciate help
+20:48:12 <eche|on> I try to add IPv6 on my root server for I2P use.
+20:48:15 <hottuna> Resolving issues regarging an openitp submission has been suggested by zzz
+20:48:22 <eche|on> as soon as I find time to understand and get it up...
+20:48:57 <Meeh> I have a dev server that I can let developers into for testing.. It have multiple ipv6 adresses
+20:49:00 <hottuna> having us accepted into OpenITP would be a major thing for us
+20:49:07 <Meeh> Could setup more of them now for testing
+20:49:22 <eche|on> and now gone for a good night time...
+20:49:25 <zzz> here's my list: IPv6 (incl. testing), Crypto (see trac wiki), OpenITP prep (see trac wiki), NTCP and SSU protocol obfuscation (old zzz.i2p post, Lance James might be able to help), other state firewall resistance, Symmetric NATs (ticket #873), ...
+20:49:32 <iRelay> http://trac.i2p2.i2p/ticket/873 - (accepted defect) - Port changing .. obscurely
+20:49:40 <Meeh> zzz: want access to a ipv6 server for testing?
+20:49:51 <dg> hottuna: major thing, yes, but, in case you (or others) are not aware: OpenITP are not long term funders. They fund short, achievable goals to improve projects "quickly".
+20:51:05 <zzz> Meeh yes, in a couple weeks. I'd like to see the minor fix in 0.9.5 to ignore published IPv6 addresses get out there before we start publishing them
+20:51:24 <zzz> s/0.9.5/0.9.6/
+20:51:24 <hottuna> crypto is another thing that I know a bit about, so my time might be well spent there
+20:51:27 <iRelay> zzz meant: Meeh yes, in a couple weeks. I'd like to see the minor fix in 0.9.6 to ignore published IPv6 addresses get out there before we start publishing them
+20:51:48 <Meeh> ok :) I can setup multiple too if needed
+20:51:51 <hottuna> maybe if we're lucky I'll be somewhat done with the floodfill system by the time zzz is done with ipv6
+20:51:58 <Meeh> got a /48 net
+20:52:14 <hottuna> that way we could both attack the crypto problem
+20:52:21 <zzz> heck what about i2pcpp
+20:52:37 <dg> orion is 404 atm
+20:52:48 <Meeh> sindu might help there when he got time, great C coder
+20:52:59 <Meeh> talked about it earlier, know him from RL
+20:53:26 <hottuna> that sounds interesting
+20:53:49 <zzz> if orion is at least willing to accept help, that's a big step - he wasn't before -
+20:53:52 <hottuna> but I think that I should spend time where makes the most difference which in my mind is floodfills/ipv6 and crypto
+20:54:11 <hottuna> *it
+20:54:14 <zzz> sure, my list doesn't necessarily match your skills or interest
+20:54:29 <Meeh> also, he should get some creds for spreading the i2p stickers around Oslo, Norway. He have placed it all around the city
+20:54:44 <Meeh> hottuna: if you want, send more.. soon emtpy again:P
+20:55:11 <zzz> oh yeah, hottuna if you aren't coming to DEFCON I need some too
+20:55:30 <hottuna> im planning on coming to defcon
+20:55:44 <hottuna> i havent bought any plane tickets yet, but I will soon.
+20:55:47 <zzz> oh hella yes.
+20:56:23 <Meeh> hottuna: if you got files, I might be able to get some free printups myself
+20:56:43 <hottuna> the files are in the i2p.graphics branch
+20:56:46 <Meeh> if you got the sticker in png/ai/whatever format
+20:56:49 <Meeh> ok thanks
+20:57:00 <hottuna> if im remembering correctly
+20:57:16 <hottuna> alright.
+20:57:51 <hottuna> Is everyone ok with the first bounty being for the floodfill system?
+20:58:02 <dg> aye
+20:58:25 <Meeh> yepp
+20:58:50 <Mathiasdm> ok, so first 1 week of research into the options, followed by implementation (currently most likely kademlia)? sounds good
+20:59:06 <hottuna> yes, that's the idea
+21:01:56 <hottuna> ok
+21:03:15 <hottuna> For the record: The first bounty to be introduced is adding a new netdb backend. The first sub bounty should be divided into alternative exploration, multirouter research and discussion with you guys
+21:03:26 <hottuna> __Misc__
+21:04:38 <hottuna> How is the website deployment going?
+21:09:27 <hottuna> Everyone died?
+21:09:31 <hottuna> str4d?
+21:12:57 <Mathiasdm> oh
+21:13:04 <Mathiasdm> I was curious :)
+21:14:22 <hottuna> did I miss anything exciting?
+21:14:29 <Mathiasdm> only this:
+21:14:32 <Mathiasdm> 23:10 -!- hottuna [hottuna@irc2p] has quit [Quit: leaving]
+21:14:32 <Mathiasdm> 23:12 <+Mathiasdm> oh
+21:14:35 <Mathiasdm> 23:13 <+Mathiasdm> I was curious :)
+21:15:12 <hottuna> Alright, if no one knows, let's see next week
+21:15:38 * hottuna baf's with the meeting ending hammer
+21:19:59 * Mathiasdm lurks onward :)
diff --git a/i2p2www/meetings/logs/223.rst b/i2p2www/meetings/logs/223.rst
new file mode 100644
index 0000000000000000000000000000000000000000..20fcb43f673f5541622180bfa4be5c1393b19148
--- /dev/null
+++ b/i2p2www/meetings/logs/223.rst
@@ -0,0 +1,13 @@
+I2P dev meeting, May 21, 2013 @ 20:00 UTC
+=========================================
+
+Quick recap
+-----------
+
+* **Present:**
+ dg,
+ eche|on,
+ hottuna,
+ Mathiasdm,
+ Meeh,
+ zzz
diff --git a/i2p2www/meetings/logs/224.log b/i2p2www/meetings/logs/224.log
new file mode 100644
index 0000000000000000000000000000000000000000..314f624dc8c80fdd8b9b40817b05f87e83123811
--- /dev/null
+++ b/i2p2www/meetings/logs/224.log
@@ -0,0 +1,489 @@
+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)
diff --git a/i2p2www/meetings/logs/224.rst b/i2p2www/meetings/logs/224.rst
new file mode 100644
index 0000000000000000000000000000000000000000..79146123a0d9b1de37368fc487c1c2174bbe477f
--- /dev/null
+++ b/i2p2www/meetings/logs/224.rst
@@ -0,0 +1,37 @@
+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.
diff --git a/i2p2www/meetings/logs/225.log b/i2p2www/meetings/logs/225.log
new file mode 100644
index 0000000000000000000000000000000000000000..466eb4fe9ff2af9cc803a1de64614cc0f1181223
--- /dev/null
+++ b/i2p2www/meetings/logs/225.log
@@ -0,0 +1,108 @@
+20:00:08 <zzz> 0) hi
+20:00:23 <zzz> 1) RI verifies disabled in a point release?
+20:00:30 <zzz> 2) misc. topics led by Meeh
+20:00:33 <zzz> 3) baffer by Meeh
+20:00:36 <zzz> -------------
+20:00:36 <zzz> 0) hi
+20:00:51 <zzz> 1) RI verifies disabled in a point release?
+20:01:02 <zzz> welterde brought this up the other day
+20:01:33 <zzz> if I'm going to do it it has to be in the next few days, as I'm AFK ~ 13th - 29th
+20:01:53 <zzz> echelon is traveling but for the moment we'll assume we can get a hold of him and he can do the news
+20:02:14 <zzz> so welterde, please make your case for why we should do this
+20:03:08 <welterde> the attack outlined in the paper is quite an serious attack for your not-well used destinations, as the required statistics are not very large
+20:04:14 <zzz> does it attack the server dests, or the (client) users that connect to them?
+20:04:21 <welterde> and for long-lived destinations it's even more dangerous as you can keep the attack going for as long as it takes to get enough statistics
+20:05:08 <welterde> zzz: the client that connects to some dest... say irc link tunnels over dedicated destination would be a prime target (if you get hold of the destination somehow)
+20:06:29 <welterde> zzz: however.. there is an option to disable RI verifies in the advanced options.. maybe news update to users to disable it?
+20:06:29 <zzz> have you always considered it serious or have you changed your mind recently?
+20:06:56 <zzz> I thought I just added that option last week?
+20:07:15 <welterde> oh
+20:07:18 <dg> you did, I made the same mistake.
+20:07:34 <welterde> thought you just changed the default value of that option.. ok.. not an option then
+20:07:57 <zzz> maybe I didnt explain it well in some post...
+20:08:59 <welterde> zzz: and in the paper they also didn't take timing into account.. I guess that can be used to further improve the attack
+20:09:02 <zzz> We've had a preprint of their paper for almost 5 months, since March 10. If this is a drop-everything problem, we've done an incredibly poor job of responding.
+20:09:33 <zzz> So I'm wondering if you have always thought it critical or have changed your mind recently, if so why?
+20:10:33 <welterde> well.. I was under quite a bit of stress until recently.. so didn't really take a look until now
+20:11:30 <welterde> zzz: buts it's really hard to say as we don't really have that much data on these things..
+20:11:48 <zzz> what happened to that page on trac with our openitp responses, and our lack of security criteria...
+20:12:11 <dg> If it is a drop-everything problem, waiting 1 1/2 more months is a problem too.
+20:12:30 <zzz> sure
+20:12:40 <zzz> but is it
+20:13:12 <zzz> is the problem the RI verifies or is it Sybil? If it's Sybil then we don't have any near-term fixes
+20:13:27 <welterde> zzz: it's the RI verifies
+20:13:46 <zzz> i.e., is there a large class of hostile-ff attacks
+20:14:16 <welterde> zzz: and an variant of the attack might be possible with RI lookup and then waiting for an connect as well.. but that attack would be magnitudes more difficult.. so I wouldn't worry about that one just yet
+20:14:35 <zzz> if an attacker takes over a portion of the keyspace, isn't there any number of things he could do?
+20:15:20 <welterde> zzz: given enough time the attacker doesn't have to occupy an large portion of the keyspace
+20:15:23 <zzz> I guess I always looked at this as a Sybil issue. Doesnt me I was right.
+20:15:30 <zzz> *mean
+20:16:07 <welterde> he only has to occupy the space surrounding the target LS
+20:16:53 <welterde> zzz: hmm.. what would be nice for stats.i2p or so would be an visualization of the ff over the keyspace.. (if there is no such thing yet)
+20:18:50 <zzz> ok thanks for making the case welterde. Let me now ask for others to jump here with their opinions
+20:18:53 <welterde> non-subtle attacks might be visible there then
+20:19:00 * welterde looks for the openitp page you mentioned
+20:19:22 <zzz> str4d set it up but I don't see it linked on the home page any more
+20:19:35 <dg> q: Could someone pull off the RI attack without full keyspace Sybil?
+20:19:45 <dg> I think yes but ???
+20:20:05 <zzz> http://trac.i2p2.i2p/wiki/OpenITPReview/Criteria
+20:20:35 <zzz> Vulnerability Response Process Maturity and Transparency
+20:21:20 <zzz> we aren't ever talking about full keyspace sybil here. You're targeting a particular slice
+20:21:31 <welterde> dg: he only has to capture most LS lookups.. and as many RI lookups as possible; the latter portion only depends on how much time he has for the attack
+20:22:17 <dg> "most"? For the network?
+20:22:20 <zzz> it's just really bugging me that we could have done this months ago for no effort.
+20:22:39 <dg> right. it looks shit if we do it now, really.
+20:22:49 <zzz> but I guess that's irrelevant
+20:23:14 <zzz> who else has an opinion, please speak up
+20:23:43 <topiltzin> dd if=/dev/null of=opinion.txt
+20:24:13 <zzz> last call. we doing this?
+20:24:27 <welterde> of course if someone was bored he could whip up an simulation.. that would certainly help ;)
+20:25:09 <zzz> maybe I'm just pissed at myself that I didn't think of just turning off the verifies.
+20:25:32 <dg> zzz: don't worry about it. you aren't expected to cover everything always.
+20:25:43 <zzz> ok everybody with an opinion please enter yes to do a release this week or no for don't
+20:26:06 <welterde> (or i am here if you don't care one way or the other..)
+20:26:58 <zzz> If I don't see any votes we arent doing it
+20:27:21 <topiltzin> will the release contain *only* disabling RI verifies?
+20:27:32 <topiltzin> vs. whatever is in trunk now?
+20:27:35 <welterde> maybe we shouldn't have skipped the who is here phase of the meeting
+20:27:54 <dg> I'm just not qualified enough.
+20:27:57 <zzz> I don't care who is here. I care who has an opinion.
+20:28:24 <welterde> zzz: well.. who isn't here doesn't have an opinion ;)
+20:28:46 <welterde> zzz: I guess we are talking more about an small release, right?
+20:28:59 <dg> welterde: what do you mean
+20:29:02 <zzz> It would be just RI verifies + anything else tiny we decide to pluck from trunk
+20:29:17 <zzz> and probably called 0.9.7.1?
+20:29:28 <welterde> yeah.. that's what I had in mind as well
+20:29:39 <kytv> no knowledge of this topic therefore no opinion, if we do it i'll of course be able to do the uploads to the various places, etc.
+20:29:58 <zzz> for gods sake somebody vote. welterde at least
+20:30:13 <zzz> who else has read the UCSB paper?
+20:30:16 <welterde> oh I am for it if that's not clear ;)
+20:30:41 <dg> I've read it..
+20:31:16 <topiltzin> I'm anxious to test the other stuff in trunk so the more we decide to pluck the more "Yes" my vote becomes. No opinion strictly on RI verification.
+20:31:54 <welterde> str4d: your opinion? you were quite active in the discussion on the forum ;)
+20:33:56 <welterde> zzz: maybe we should do the vote on the paper thread.. so str4d and tuna (and the others in the thread who are not here) have a say as well..
+20:33:56 <zzz> I would want to keep the "other stuff" list very short as I would be doing this very fast and then blowing out of town, unable to fix problems
+20:33:59 <zzz> tuna is almost completely afk for a while yet
+20:34:51 <dg> a no would be better than silence
+20:35:03 <welterde> zzz: well.. or kytv could do the build..
+20:35:10 <zzz> in theory kytv can do releases too, he's the other one with signing keys, yes
+20:36:35 <zzz> ok then lets do it. I'll put a thread up on zzz.i2p if you want to propose other stuff to go in, final decision in about 24 hours, and I'll do the build maybe thursday. Can somebody contact echelon?
+20:36:53 <zzz> anything else on this topic?
+20:37:37 <dg> I don't think so.
+20:38:23 <zzz> http://zzz.i2p/topics/1443
+20:38:40 <zzz> please review the 17K line diff from 0.9.7 and history.txt for other pluck candidates
+20:38:47 <zzz> 2) Meeh's topics
+20:38:50 <zzz> take it away Meeh
+20:54:33 <topiltzin> zzz: the tag is "i2p-0.9.7"
+20:54:36 <topiltzin> not "0.9.7"
+20:54:47 * topiltzin preparing his plucklist
+20:55:26 <welterde> same here
+20:55:32 <zzz> thx
+20:55:47 <dg> zzz: pm ok?
+20:57:06 <zzz> only if it's of zero interest to anybody else
+20:58:51 <dg> draft for email to zooko
+20:58:55 <dg> http://pastethis.i2p/show/0bZ3iFeE9uABCORkfXV6/
+20:58:58 <iRelay> Title: Paste #0bZ3iFeE9uABCORkfXV6 | LodgeIt! (at pastethis.i2p)
+20:59:10 <dg> I didn't include status or anything yet. I may be way off base. Feedback appreciated.
+21:01:00 <zzz> 3) /me *baf*s the meeting closed for Meeh
+21:03:29 <zzz> dg that's a really great start.
diff --git a/i2p2www/meetings/logs/225.rst b/i2p2www/meetings/logs/225.rst
new file mode 100644
index 0000000000000000000000000000000000000000..28338222f027825ec80aa233651be3994c77db74
--- /dev/null
+++ b/i2p2www/meetings/logs/225.rst
@@ -0,0 +1,12 @@
+I2P dev meeting, August 6, 2013 @ 20:00 UTC
+===========================================
+
+Quick recap
+-----------
+
+* **Present:**
+ dg,
+ kytv,
+ topiltzin,
+ welterde,
+ zzz