--- layout: post title: Logs for the Kovri Dev Meeting Held on 2016-11-13 summary: Brief review of what has been completed since last meeting, prepration of Alpha release, and code & open tickets discussion tags: [dev diaries, i2p, crypto] author: dEBRUYNE / fluffypony --- *November 13th, 2016* ### Logs **\ {-anonimal}** Proposed meeting items: **\ {-anonimal}** 1. Greetings **\ {-anonimal}** 2. Brief review of what's been completed since the previous meeting **\ {-anonimal}** 5. Code + ticket discussion / Q & A **\ {-anonimal}** 3. Preparing for alpha release **\ {-anonimal}** 4. Moving meeting agenda issues from monero-project/kovri to monero-project/meta **\ {-anonimal}** 6. Any additional meeting items **\ {-anonimal}** Hi **\ {-anonimal}** 7. Confirm next meeting date/time **\ {-anonimal}** JFTR for the log: people think the meeting is at 19:00 when it is actually at 17:00 so we may be a bit shorthanded today **\ {-anonimal}** 2. Brief review of what's been completed since the previous meeting **\ {-anonimal}** The general focus of the past two weeks has been "escaping comfort zone" work: **\ {-anonimal}** i.e., pursuing a few long-standing issues that I've avoided because they weren't fun: **\ {-anonimal}** Build: **\ {-anonimal}** - Builds builds builds! All builds are now in the GREEN! **\ {-anonimal}** - ARMv7/8 and Win32/64 builds are now online! Static builds online! **\ {-anonimal}** - Win32/64 run-time is now available after patching an upstream issue **\ {-anonimal}** - ARMv7 has a non-Kovri runtime issue, ARMv8 box still needs testing **\ {-anonimal}** - Much build-related work with pigeons, partly noted in monero-project/meta **\ {-anonimal}** - Setup kovri per-platform IRC clients for testing, say hi to them in #kovri-dev **\ {-anonimal}** Code: **\ {-anonimal}** - Resolved all Coverity defects (details in #263)! **\ {-anonimal}** - Bug fixes in addressbook + shutdown, https on windows **\ {-anonimal}** - Design and planning: global refactoring, study, and testing **\ {-anonimal}** - SSU Server testing (nothing merge-able at the moment) **\ {-anonimal}** - Debugging, attending to open milestone issues **\ {-anonimal}** - Mentoring: working with other contributors to "Make Kovri Great Again" **\ {-anonimal}** - guzzi doing his civic duty while also working on http proxy (WIP) **\ {-anonimal}** - olark providing great netdb/socks proxy documentation and refactoring **\ {-anonimal}** Misc: **\ {-anonimal}** - 7z/installer research for platform-agnostic bundling of data-dir with static binary **\ {-anonimal}** - README/Doc updates, misc. project maintenance **\ {-anonimal}** - Too many other things to mention here or things that I've simply forgotten **\ {-anonimal}** Note: confirmed earlier: run-time is online on ARMv8! **\ {-anonimal}** Anything else on point 2.? **\ {-olark}** Sums up the past 2 weeks well. **\ {-anonimal}** Side-note, JFTR: slack relay is not working and fluffypony isn't running meeting relay to #monero-dev **\ {-anonimal}** Ok, moving on, **\ {-anonimal}** 3. Preparing for alpha release **\** Here fyi **\ {-anonimal}** Oh good, hi guzzi (I PM'd you earlier) **\** Ok **\ {-anonimal}** So, 3. looking at https://github.com/monero-project/kovri/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.1.0-alpha **\ {-anonimal}** A few of these can be moved to next milestone (they aren't urgent), **\ {-anonimal}** If I can't resolve the rest by Dec 1st. in addition to everything else that needs attention, then maybe Dec. 14th at the latest. **\ {-anonimal}** Really there are only a few key issues that *must* be resolved for an alpha release and they are, IMHO: **\ {-anonimal}** #375 and #119 <-- at an absolute bare minimum **\ {-anonimal}** because they *really* can get in the way. **\ {-anonimal}** But that's a bare-minimum not-ideal scenario and I know we can get more done by then. **\ {-anonimal}** Any thoughts? **\ {-olark}** Yeah those are the big ones. I'll go over the addressbook and add/remove the destinations that don't work. **\** 119 looks easy for u. I dont disagree **\** Sorry i meant 375 **\ {-anonimal}** Well, it looks straightforward, we'll see what it really looks like when the time comes :) **\ {-anonimal}** olark: re: destinations, which issue # is this? **\ {-olark}** Keep it a small list. **\ {-olark}** Some are just dead. **\ {-olark}** So we have a small list of eepsites that do work and may be useful for a new user. **\ {-olark}** Not in the milestone I believe. **\** Agree on the eepsite list actually containing valid sites **\** 119 looks like a critical fix for sure. **\ {-olark}** re: subscription file **\ {-olark}** Not high priority but maybe something nice to have for the first release. **\ {-anonimal}** olark: oh that, well that's very low priority but if it's an issue than ok, but how can you confirm if they are dead? Were some removed in the .27 java i2p release? **\ {-olark}** Just some of them never connect ever. **\ {-olark}** I'll go over them again in the coming days. **\ {-anonimal}** Ok, sounds good. **\ {-anonimal}** guzzi: well, I wouldn't say critical because it doesn't effect all routers and it certainly hasn't effect the OSX instances **\** Ok understood **\ {-anonimal}** And there's always the option to disable ssu at run-time, but yes I think it should be resolved. **\ {-anonimal}** fluffypony hinted at *not* having a release before 33C3 but he may be trying to get out of https://github.com/monero-project/kovri/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.1.0-alpha+assignee%3Afluffypony **\* guzzi** needs to find out what ssu is before i **\ {-anonimal}** ;) **\* guzzi** open my mouth **\ {-olark}** Semi-Secure UDP **\** Thanks **\ {-anonimal}** guzzi: checkout the new Moneropedia entries I made that are now live on the website **\ {-anonimal}** guzzi: link is in README.md **\ {-anonimal}** (on current HEAD) **\** Awesome **\* guzzi** Todo tonight **\ {-anonimal}** So, re: release, **\ {-anonimal}** Let's keep hacking away for the next two weeks and see where we stand. **\ {-anonimal}** Any objections? **\** Ok i will read your pm when i get back **\ {-olark}** Keep on hacking away ;) **\** On phone now **\ {-anonimal}** The difference between a Dec. 1st alpha release and Dec. 14th alpha release IMHO will be noticeable to an end-user. Neither is useful without package resolution nor more monero input/participation; so I want to wait for a final decision until fluffypony speaks up. We can talk more this coming week. **\** I agree boss. **\ {-anonimal}** lol guzzi **\ {-anonimal}** My biggest concern is that for reasons not of my doing, a release doesn't happen before 33c3, and I really hate having to change dates like this. **\ {-anonimal}** But I'll have to be flexible for now because there are many moving parts. **\ {-anonimal}** Anything else on point 3.? **\** No **\ {-anonimal}** olark: ? **\ {-olark}** We can keep moving along. **\ {-anonimal}** 4. Moving meeting agenda issues from monero-project/kovri to monero-project/meta **\ {-anonimal}** So, as this meeting has proven, no one else in Monero looks at the meeting agendas I prepare for every meeting :) **\ {-anonimal}** With the creation of monero-project/meta, I think it would be better to not clutter the kovri repo with meeting agendas. **\** Agree 100% **\ {-anonimal}** I would hope that more monero people get inolved with meeting agenda preparation and start using the meta repo too. **\ {-anonimal}** I'd like to move agendas to meta from now on. guzzi is on board. Anyone else? **\ {-olark}** Sounds good to me. **\ {-anonimal}** Alright, I'll start doing that. **\ {-anonimal}** Moving on, **\ {-anonimal}** 5. Code + ticket discussion / Q & A **\ {-iDunk}** i built kovri on win64 successfully but the build failed on linking for win32 **\ {-anonimal}** We've basically covered this in point 3, but I did add some new notes to #187 **\ {-iDunk-kovri-win64}** hiii **\ {-anonimal}** For #187 not sure if EinMByte is around. **\ {-anonimal}** Yay, hi iDunk-kovri-win64 :) **\ {-iDunk-kovri-win64}** :) **\** Do we care about 32 **\ {-anonimal}** iDunk: can you paste error after the meeting? **\ {-iDunk}** will do **\ {-anonimal}** iDunk guzzi: our win32 build is working with buildbot https://build.getmonero.org/waterfall **\** Ok so it is isolated **\ {-anonimal}** Yep, most likely, we'll see. **\ {-anonimal}** Anyone have any questions/comments on open/closed issues? **\** Nice work idunk thank you **\** None here. You know where i am at **\ {-iDunk}** np **\ {-anonimal}** lol, sipping up a pina colada I imagine **\** Lol yes. **\ {-anonimal}** olark: any questions/comments on open/closed issues? **\** I also had meant you know where i am at code wise **\ {-olark}** All good ;D **\ {-anonimal}** Oh, haha! **\ {-anonimal}** * glances over issues **\ {-olark}** re: APIs **\ {-olark}** How is that coming along? **\ {-olark}** #351 and #350 **\ {-anonimal}** Once more client/router work is completed, they will be easier to implement. **\ {-anonimal}** So that first, API second. **\ {-olark}** Ya, still got a little ways to go. Haven't written APIs in a while so could be a good place to refresh myself ;) **\ {-anonimal}** I'm getting a better idea of how I'd like to implement but I'd like to compare notes with EinMByte when he returns before moving on anything. **\ {-anonimal}** (because he has strong opinions on the matter and he has great experience) **\ {-olark}** Yeah his input is very valuable. **\ {-olark}** Well known in the i2p community. **\<_Slack> \** Lol **\ {-anonimal}** I'll continue to comment in those tickets as other work progresses. **\ {-anonimal}** I always keep the APIs in mind when doing other work, **\ {-anonimal}** which always leads to more work that needs to be resolved before returning to APIs **\ {-olark}** Yep **\ {-anonimal}** (etc. etc.) **\ {-anonimal}** Ok, anything else on this point? **\ {-anonimal}** If not we can talk more about it later this week. **\ {-olark}** That is all on my side. **\ {-olark}** Ok. **\** None here **\ {-anonimal}** 6. Any additional meeting items **\ {-anonimal}** Nothing from me. We have a clear plan, we're executing the plan as planned. **\** None here. You will be busy. I will try to correspond efficiently s possible the next two weeks **\<_Slack> \** Slight general question about i2p - if I'm running kovri in the future, would a malicious agency be able to detect that? **\ {-olark}** ISPs can figure out you are using i2p. **\ {-anonimal}** nanoakron: that depends on the agency **\** A malicious one. **\* moneromooo** runs **\<_Slack> \** Lol **\ {-anonimal}** nanoakron: good question, I think that was one of the SE questions I bookmarked to answer **\<_Slack> \** Are there any loose thoughts on the step beyond kovri? Steganographic encoding within normal router traffic? **\ {-anonimal}** Now that moneropedia is merged, I'll answer them. **\ {-olark}** I would like to explore better ways to obscure i2p traffic in with regular clearnet traffic, but that is for future research. **\<_Slack> \** Of course **\ {-olark}** SSU is pretty resistant to DPI and kovri already takes some countermeasure to hide the fact i2p is being used. **\ {-anonimal}** Stego obfuscation within encryption? That makes as much sense as encrypting the encryption more than it is already encrypted. **\ {-olark}** But there are lots of avenues to explore. **\ {-olark}** Packet size I believe is the biggest giveaway among others. **\ {-anonimal}** nanoakron: do you have any research on that? **\ {-anonimal}** (proving any effectiveness?) **\<_Slack> \** Sadly not :( **\<_Slack> \** It's just something I heard being discussed between two more technical people where I work a while ago. **\ {-anonimal}** nanoakron: it would probably me more effective to simply add another layer of encryption (but that isn't really necessary) **\<_Slack> \** Stego to hide bitcoin **\ {-anonimal}** (but maybe I'm not understanding your point exactly) **\ {-anonimal}** Oh, well that makes sense. **\ {-anonimal}** They're not dealing with layered encryption like we do. **\<_Slack> \** At the router level **\ {-anonimal}** (afaik) **\ {-anonimal}** I'm not sure how effective that would be for us, but nanoakron if you get more info please feel free to send to #kovri-dev **\<_Slack> \** How easy would it be for the North Korean government to shut down all i2p traffic for example. Anyway...it's highly theoretical stuff right now. **\<_Slack> \** Of course! **\ {-anonimal}** nanoakron: and olark pointed out important overlay-network facts **\<_Slack> \** Yep **\ {-anonimal}** North Korea? Can't they basically do whatever they want whenever they want to on any network level? **\ {-olark}** North Korea has no internet infrastructure aside from government use afaik. **\<_Slack> \** That would be the worst case scenario. For example if our governments decided to ban all non-fiat currencies. **\ {-olark}** But if it is any indication, I2P can be run in China. **\ {-anonimal}** Doesn't their "internet" exist entirely in a class C subnet? **\<_Slack> \** Anyway, I'm just spitballing **\ {-olark}** It is important to keep those things in mind though. **\ {-anonimal}** Spitball all you want, we have 7 minutes left :) **\<_Slack> \** ;) **\** Lol. True **\<_Slack> \** Something for the monero research lab **\** We should at least worry about packet sizes. **\** In the future **\** We are going to add user agent options **\<_Slack> \** Deterministic packet sizes to prevent fingerprinting and sniffing **\<_Slack> \** ? **\ {-olark}** Blending in with SSL traffic is the ideal scenario. **\<_Slack> \** Ah yes **\<_Slack> \** Will my little Odroid C2 node (ARMv8) be able to run kovri alongside monero in its final embodiment? **\ {-anonimal}** NTCP2 is addresses TCP packet length obfuscation. **\ {-anonimal}** olark: blending in with SSL, I don't see how that would be ideal, what do you mean? **\ {-olark}** To fly under the radar more. **\ {-anonimal}** nanoakron: I'm running kovri on ARMv8 linaro right now **\<_Slack> \** Neat **\ {-olark}** If I am a mouse my best bet is to sneak in with all the other rats into the kitchen right? ;) **\ {-olark}** Hoping no one realizes I am a mouse. **\ {-anonimal}** olark: they'll tend to shutdown SSL connections before detecting NTCP/UDP signatures, I'm pretty sure of that. **\<_Slack> \** Yes, not true stego but mimickry. **\** Agree. **\** Any other doomsday senerios? **\<_Slack> \** Lol **\** 1 min? **\ {-anonimal}** Btw: a TLS transport is still an open draft proposal from 2009 https://geti2p.net/spec/proposals **\ {-anonimal}** TLS/SSL makes it's case but I'm not strongly in favor. We can talk more about that at the next meeting if anyone wants to, just add a note in the agenda. **\ {-anonimal}** Moving on, **\ {-anonimal}** 7. Confirm next meeting date/time **\ {-anonimal}** moneromooo: will next meeting be 18:00 for #monero-dev? **\ {-olark}** Hmmm **\ {-anonimal}** Or 17:00? **\ {-fluffypony}** oh **\ {-fluffypony}** sorry anonimal **\ {-anonimal}** Thanks for understanding fluffypony. **\ {-fluffypony}** my apologies **\ {-fluffypony}** I must've misunderstood the timing discussion **\ {-anonimal}** fluffypony: apologies accepted! Are #monero-dev meetings now at 17:00 or 18:00 **\ {-anonimal}** (fluffypony: we're idling on 7. Confirm next meeting date/time) **\ {-fluffypony}** anonimal: let's update after the Monero meeting **\ {-anonimal}** Alright, I'll start with 17:00 **\ {-anonimal}** Meeting in two weeks. **\ {-anonimal}** Thanks everyone! **\ {-olark}** Good talk everyone :D