2016-11-13-logs-for-the-Kovri-dev-meeting-held-on-2016-11-13.md 18.1 KB
Newer Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
---
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  

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