20:00:01 0) Hi 20:00:01 1) 0.9.27-29 roadmap: http://i2p-projekt.i2p/en/get-involved/roadmap 20:00:05 0) Hi 20:00:07 hi 20:00:35 1) 0.9.27-29 roadmap: http://i2p-projekt.i2p/en/get-involved/roadmap 20:00:57 hi 20:01:17 hi 20:01:17 my goal today is to split up the 27-29 roadmap into 27 and 28-29, at a minimum 20:02:05 keeping in mind my two long-term goals: 1) grow the network; 2) improve security 20:02:55 so let's look at the 27-29 list. Anything jump out as being high-priority that we need to have in 27, or at least start working on? 20:05:08 "Crypto migration for existing hidden services" <-- I assume this is adding the backend and UI bits to enable people to do the migration? 20:05:13 (as well as doing so on stats.i2p etc.) 20:05:49 "Initial work on new crypto" <-- This rates very highly for me, but implementation is still blocking on design work 20:05:51 yeah, building off the subscription feed work in 26 20:06:21 we could call it 'initial design work' 20:06:34 Mmm 20:06:41 Let's figure out the actual dependency graph here 20:06:53 (for the other first few items) 20:07:11 a - Initial work on NTCP2 20:07:24 b - Initial work on New DH 20:07:29 c - Initial work on new crypto 20:07:29 d - Initial work on LS2 with multi-destination support 20:07:33 e - Initial work on new netdb ("next backend") 20:08:23 anything labeled 'initial work' probably doesn't have dependencies 20:08:23 LS2 requires new netDB code to support, no? 20:08:46 Well yes, if it is internal support for the router parsing bits of it 20:09:23 But how the router gets that data to parse will have dependencies 20:09:39 'new netdb' is the tuna stuff like R5N, so it's orthogonal to LS2 20:09:51 * str4d is trying to separate the things we can implement sooner from the things we need to focus design work on that may be blocking other tasks 20:09:54 Okay 20:10:34 c depends on d, at least 20:10:52 because at the e2e layer, the crypto is in the LS 20:11:08 What do you mean by b? 20:11:27 (because b would appear to be a prerequisite for a otherwise) 20:12:08 b = make a list of DH candidates, with info on code availability, speed, etc 20:13:04 Okay, then b *is* semi-independent of a :) 20:13:04 c = make a plan, make a list 20:13:51 a lot of this 'initial work' stuff is pretty much dead on the vine. Nobody's thought about it in months or years, no recent discussion 20:14:04 somebody's got to get their head back into it 20:14:07 Ah, I see my mistake. I assumed that everything on the list was referring to things actually landing as code 20:15:41 maybe, maybe not 20:15:52 Okay, my priorities now are all of them at once ;D 20:16:25 But probably starting with something that will have a shorter turnaround 20:16:30 a lot of it requires consensus building and design with i2pd and kovri before coding 20:17:02 Mmm 20:18:34 What needs to happen IMHO for a and d is a small group of people reviewing all the existing proposals and getting some clarity, then having some kind of design discussion meeting 20:18:48 With as little meeting as possible ideally :P 20:19:28 b will have some impact on a from a design perspective, but can be delayed 20:20:14 I'd be happy with revitalizing the discussions on zzz.i2p for starters. We have 20-30 proposals up now, most have landed with a thud or are forgotten. 20:20:37 Likewise with c on d 20:20:37 Of those five though, e will probably have the most effect on network reliability... 20:20:40 As a result we are very poorly positioned for future development atm 20:21:39 At this point we're putting aside tunnel-level crypto, which I have no problem doing (we want to wait a bit and see what comes out of the Tor work here) 20:21:47 which is another reason why summer of x could be a better place to put resources. At least what needs to be done for all the x's is more clear 20:22:21 is 'tunnel-level crypto' even on a list or post at all? 20:22:41 IDK 20:22:53 This is something we will figure out better once I get the proposals on the website :P 20:23:40 * str4d will be working on the precursor to that today. 20:23:51 I would ask you what you'd most want to work on, but that seems silly given that you have months and months of past-due things on your list atm 20:24:43 Well, a lot of that was just overly ambitious and unrealistic todo scheduling on my part 20:25:21 (not taking into account the actual work required, like e.g. the Android release...) 20:25:55 I'm pretty pessimistic about progress right now, even for .26, which I haven't started yet and could take quite a while 20:26:03 For 0.9.26 we already have a list of things that need implementing. But we can also get started on design discussions. 20:26:16 And I may have to take several weeks off of coding to figure out launchpad and debian 20:26:30 Hmm, yeah.. 20:27:04 so at this point 27 feels a long way off 20:27:21 Okay, let's say we can only do one of [ transport encryption | e2e encryption ] 20:27:33 (in terms of doing design planning alongside other implementation stuff) 20:27:41 Which is more important to get finished? 20:28:26 Transport encryption is important wrt third-party adversaries 20:28:56 E2E encryption is important wrt OBEPs and IBGWs who see that encrypted packet, and also to tunnel performance 20:29:09 I'm leaning toward transport stuff DH/NTCP2/padding/PT. It's less blue-sky and we have more sketched out already. THe path is more clear 20:30:29 Then let's focus on that for .27 20:31:52 you think that's more impt than LS2? LS2 is in a similar state as transport stuff. Lots of proposals, zero recent discussion 20:32:28 Ideally I'd like to work on them both in parallel 20:32:41 But I'm trying to be realistic here about what we will actually achieve :) 20:32:47 gun to head, pick one 20:33:30 transport 20:33:39 ok, agreed 20:33:46 tls lookalike transport when? 20:34:08 Transport stuff is beneficial to the anonymity properties we provide our *current* users 20:34:21 LS2 stuff is beneficial to *future* users (as well as current) 20:34:26 not on any list or proposal iirc psi 20:34:34 Also I have many more questions in my head re: LS2 than transport 20:34:47 kk 20:35:12 str4d, if you could get those q's into the zzz.i2p threads that would be a start 20:35:19 zzz, not sure that's true, I know at the very least it is on the Trac wiki 20:36:19 basically there's about 20 proposals on zzz.i2p dying for participation from str4d, psi, orignal, anonimal. If we move a couple to the top of the list as we just did today, hopefully they will get more eyeballs 20:36:19 Might be more apt to say "question marks" 20:36:36 mmm 20:36:38 sure, some of the LS2 stuff is pretty throw-it-at-the-wall 20:37:01 So in my mind, my #1 todo task right now is getting the proposals onto the website 20:37:31 in my mind, android is #1 for you 20:37:42 (and my other #1 todo task is fixing the ProGuard bug in I2P Android) 20:37:50 Yah 20:38:08 I'm fine with any proposal as soon as they get moved forward 20:38:08 Worst-case, I just back out the Samsung 4.2 fix for this release 20:38:09 so for 27, the list is transport stuff: progress on DH, NTCP, and PT 20:38:21 anything else for 27? 20:38:39 Mmm. Put LS2 design work into .28 20:39:17 zzz, initial console design planning would be nice 20:39:45 I personally can't wait for a new crypto, especially for destinations, so LS2 should be implemented asap 20:40:08 (inasmuch as deciding on a direction and roadmap, no actual implementing) 20:40:08 ok 20:41:18 I think that's a pretty ambitious 27: crypto migration for existing hidden svcs + the transport stuff 20:41:20 orignal, likewise; hence I want to make sure we get it right :) 20:41:43 I'll put LS2 and related stuff in 28 and move everything else to 29? 20:42:35 Sounds reasonable 20:42:35 .27 then has a good mix of design and implementation 20:42:38 anything else on 1) roadmap ? 20:43:18 Not from me at this time. 20:43:27 any other topics? 20:43:34 We want to revisit this of course, probably part-way through .26 20:44:08 (to ensure we are on-track with the necessary prep for .27) 20:44:50 2) How are we doing re: kytv disappearance recovery? 20:44:55 Next monthly meeting is April 5. I want to say in advance that if nobody reports that they've done anything since the March 3 meeting, I'm going to declare this new project management style a failure. If nobody's doing anything, there's nothing to manage and no need to have monthly meetings 20:45:33 You mentioned launchpad and debian above. Is there anything else you consider urgent to recovery? 20:45:35 2) Meeh was doing some research on launchpad/debian which is our major outage. I need to compare notes with him 20:46:05 echelon and I traded emails with tails, they are worried about him and looking for a replacement. 20:46:18 I told them it's not going to happen from our side soon, their problem for now 20:46:58 all the other stuff around the build (geoip, tx) I have covered. 20:47:16 but launchpad/deb is a disaster. Nobody else knows anything, and nothing's written down 20:47:58 and what he did for 24 is incomplete, so there's even some more work to do on 24 before we get to 25 20:48:16 anything else on 2) ? 20:48:42 Would it be useful to put out a call for a new packager? 20:48:50 (e.g. Twitter?) 20:48:53 sure 20:49:07 * zzz reaches for the baffer 20:49:20 sadie can figure out precise wording of the call 20:49:49 (we want it to be welcoming and encouraging without being too panicked ;) ) 20:49:56 don't delegate every tweet to sadie, you are allowed to tweet also :) 20:50:04 * zzz *bafffs* the meeting closed