monero-project/monero-site
monero-project/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2024-12-23 12:09:49 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Logs for the Kovri and Dev meetings held on 2016-11-13 & 2016-11-27

Browse source
This commit is contained in:
dEBRUYNE-1 2016-11-30 17:47:53 +01:00
parent 1415d6afac
commit 6e4fea1be9
No known key found for this signature in database
GPG key ID: B9145F6EBFA81C32
4 changed files with 1087 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

247
_posts/2016-11-13-logs-for-the-Kovri-dev-meeting-held-on-2016-11-13.md Normal file
View file

@ -0,0 +1,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

327
_posts/2016-11-13-overview-and-logs-for-the-dev-meeting-held-on-2016-11-13.md Normal file
View file

@ -0,0 +1,327 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-11-13
summary: Meta repository, Fluffy Blocks, and official GUI
tags: [dev diaries, core, crypto, 0mq]
author: dEBRUYNE / fluffypony
---
*November 13th, 2016*
# Overview
An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-dev-meeting-note-highlights-2016-11-13).
# Logs
**\<@ArticMine>** Hi
**\<+moneromooo>** Oh hi
**\<@fluffypony>** oh and pigeons
**\<Softich>** allright boys, get it started :P
**\<@fluffypony>** and tewinget
**\<medusa_>** Jaquee ping too
**\<pigeons>** hi
**\<@fluffypony>** ok so let's start with an infrastructure update
**\<Jaquee>** hi!
**\<@fluffypony>** pigeons: how goes it
**\<pigeons>** good
**\<@fluffypony>** pigeons: do you want to tell people about the new repo we're using for issues?
**\<pigeons>** github.com/monero-project/meta
**\<Softich>** https://github.com/monero-project/meta
**\<_Slack> \<nanoakron>** Please explain?
**\<Softich>** for the lazy
**\<pigeons>** for stuff realted to build machines, build infrastructure, etc
**\<pigeons>** anonimal has been using it some to get things setup for kovri needs
**\<pigeons>** so feel free
**\<luigi1112>** I got some emails about issues
**\<luigi1112>** I was like cool
**\<@fluffypony>** ok so
**\<@fluffypony>** please use /meta for organisational issues
**\<@fluffypony>** "organisational" as in something that isn't project specific
**\<_Slack> \<nanoakron>** Roger
**\<pigeons>** there is also an empty repo there now, i'll check in some build infrastructure settings there and vm templates
**\<i2p-relay> {-anonimal}** pigeons: can I PM you on Irc2p or are you AFK from that instance?
**\<pigeons>** yes i'm online there
**\<i2p-relay> {-anonimal}** \* has to leave soon
**\<@fluffypony>** ok so
**\<_Slack> \<nanoakron>** Ha
**\<_Slack> \<nanoakron>** Ja
**\<@fluffypony>** we've had quite a few PRs merged in the last 2 weeks
**\<@fluffypony>** some big things like "fluffy blocks" that need testing and fiddling to check for edge cases
**\<_Slack> \<nanoakron>** Can I run a testnet client in parallel with my main net one from the same box?
**\<@fluffypony>** yes I do
**\<@fluffypony>** on my laptop
**\<iDunk>** i also do
**\<_Slack> \<nanoakron>** Could you make some details public, maybe in the readme?
**\<_Slack> \<nanoakron>** I mean instructions
**\<iDunk>** what details?
**\<@fluffypony>** @NanoAkron for running testnet and mainnet?
**\<_Slack> \<nanoakron>** Yes please
**\<@fluffypony>** ./monerod --testnet
**\<@fluffypony>** ./monerod
**\<iDunk>** start moderod normally for mainnet
**\<@fluffypony>** in two different windows
**\<_Slack> \<nanoakron>** And they're happy to play together?
**\<iDunk>** and monerod --testnet for testnet
**\<medusa_>** yes very happy
**\<pero>** needs annotated screenshots imho
**\<luigi1112>** they play separately
**\<medusa_>** like 2 small pupies
**\<_Slack> \<nanoakron>** Ok cool.
**\<_Slack> \<nanoakron>** Will get that up and running when I'm home next week.
**\<iDunk>** you also need to start monero-wallet-cli --testnet
**\<iDunk>** for a testnet wallet
**\<_Slack> \<nanoakron>** Are there any decisions on making the whole network fluffy at the next hardfork?
**\<+moneromooo>** Veto.
**\<@fluffypony>** I think they're already enabled by anyone running a node that supports it
**\<iDunk>** it is not necessary
**\<luigi1112>** not next like jan
**\<luigi1112>** and it doesn't need a fork?
**\<gingeropolous>** right. it doesn't need a fork.
**\<@fluffypony>** the fork would only have been done to avoid old nodes showing weird error messages
**\<iDunk>** client that support fluffy blocks talk fluffy
**\<@fluffypony>** but honestly it's not a big deal
**\<iDunk>** and those that don't, don't afaik
**\<_Slack> \<nanoakron>** But to make it compulsory. Reducing block sizes would also help obfuscation.
**\<+moneromooo>** It kind of is. If there's a nasty bug once close to 100% of the nodes switched, boom.
**\<iDunk>** there is no block size reduction
**\<dEBRUYNE>** \<pero> #58 is not fixed \<= apologies, should be reopened then
**\<_Slack> \<nanoakron>** There's no block size reduction? I think you're mistaken
**\<@fluffypony>** @NanoAkron it doesn't reduce block size, just reduces traffic
**\<+moneromooo>** He is not.
**\<iDunk>** nonaoakron: i am nitz
**\<iDunk>** not*
**\<iDunk>** lol
**\<@fluffypony>** ie. you have the transactions already in the mempool, so no need to re-send them
**\<@fluffypony>** but the block size stays the same
**\<+moneromooo>** Hi nitz.
**\<_Slack> \<nanoakron>** Yes ok I wasn't precise enough
**\<iDunk>** :)
**\<+moneromooo>** hi
**\<_Slack> \<nanoakron>** It reduces block transmission and reduplication, reducing overall network traffic and 'burstiness'
**\<@fluffypony>** yes
**\<_Slack> \<nanoakron>** Thereby improving obfuscation efforts ;)
**\<@fluffypony>** ok
**\<_Slack> \<nanoakron>** And kovri
**\<_Slack> \<nanoakron>** Should also benefit
**\<+moneromooo>** Can we leave that till after we're done with the meeting though ?
**\<_Slack> \<nanoakron>** Due to packet size reduction and traffic reduction. Good reasons to make it compulsory at some point in the future.
**\<gingeropolous>** ^^
**\<_Slack> \<nanoakron>** Ok will leave it now.
**\<@fluffypony>** @NanoAkron it *is* compulsory
**\<@fluffypony>** ok so
**\<_Slack> \<nanoakron>** Ja
**\<@fluffypony>** Jaquee / medusa_ could you give us a GUI update, based on the stuff that's been done in the past 2 weeks ?
**\<Jaquee>** yeah
**\<Jaquee>** We've made great progress last couple of weeks. A lot of great contributions and inputs from new people. Great to see!
**\<Jaquee>** All critical issues i know of are fixed and we have a very good looking, working gui with all basic functionality in place.
**\<Jaquee>** I believe next step is building binaries to make it possible for more people to test it
**\<@fluffypony>** ok
**\<Jaquee>** Since the 0.10 daemon isnt compatible with gui we also need to make sure we have a working monerod build to release with the gui.
**\<@fluffypony>** we'll try couple that with a new 0.10 point release
**\<Softich>** nice, can you give us an ETA for the download? :)
**\<Jaquee>** sounds good
**\<@fluffypony>** so it will take a couple of days to wrap up a point release too
**\<Jaquee>** ok. makes sense
**\<_Slack> \<nanoakron>** Can I ask about translations/localisation?
**\<Jaquee>** yes
**\<@fluffypony>** sure
**\<Jaquee>** i haven't worked on those parts very much though. but i can try to answer your questions.
**\<_Slack> \<nanoakron>** Is there an easy way I could try to translate some stuff for you - I speak a bit of Malay. Is there a transifex or maybe a way to scan the transifex of another coin (ahem) and pull in their translations?
**\<Jaquee>** i think dEBRUYNE is planning to publish the translation files somewhere.
**\<dEBRUYNE>** I've been intending to put the strings up on transifex, but I have spent the time that I had on testing in the last few weeks
**\<dEBRUYNE>** And it's a bit of a pita to get the strings out
**\<_Slack> \<nanoakron>** Makes more sense to test right now anyway
**\<maitscha>** today I tried to update german translations, but there seems to be a bug choosing the language (at least under macos)
**\<Jaquee>** maitscha: i'm not sure if translations are fully implemented yet
**\<medusa_>** yes we took them out basically
**\<_Slack> \<nanoakron>** Some wizard could probably whip up a way to pull translations from another coin... ;)
**\<medusa_>** to get it as stable a spossible for now
**\<maitscha>** ok, I think the translation stuff needs some fixes to get it working. should we open a ticket?
**\<Jaquee>** maitscha: yes please
**\<Jaquee>** speaking of issues...
**\<Jaquee>** the issue page is hard to grasp sometimes. Labels would help out alot. is that possible somehow?
**\<@fluffypony>** yes
**\<@fluffypony>** we have a small issue with that in that only collaborators can add labels
**\<@fluffypony>** and GitHub aren't adding fine-grained permissions for non-collaborators
**\<Jaquee>** ok. and collaborator = write access right?
**\<@fluffypony>** yes
**\<@fluffypony>** so it's too much of a security risk to hand out
**\<Jaquee>** yes. ofc
**\<@fluffypony>** my suggestion is that we have a Google Docs spreadsheet
**\<@fluffypony>** with a column for each label
**\<@fluffypony>** and then issue number -> mark the appropriate columns
**\<@fluffypony>** and I'll go and add labels
**\<medusa_>** personally i think we should increase the circel of caloborators by at least 1
**\<@fluffypony>** medusa_: the entire Core Team have access
**\<medusa_>** it seemed to me it is hard to keep track, at least this week
**\<medusa_>** also for core?
**\<@fluffypony>** the issue is that the people that can manage issues != the people that can be responsible for merging code
**\<Jaquee>** yeah. how is your work load currently fluffypony? would it make sense to have more ppl doing merges in the future?
**\<@fluffypony>** (most of the time anyway)
**\<medusa_>** im fine with that, just make sure those people capable can also merge to monero-core in case we have a small "merge jam"
**\<@fluffypony>** Jaquee: my work load is fine when the in-laws aren't visiting
**\<medusa_>** haha
**\<Jaquee>** fluffypony: lol ok
**\<_Slack> \<nanoakron>** I think it would be reasonable to give mooo merge access as a paid major contributor who has demonstrated talents
**\<_Slack> \<nanoakron>** Lol FP...I know the feeling
**\<@fluffypony>** I'm trying to let PRs sit for a while so that other people review them besides me
**\<medusa_>** yes but sometimes if we are active that causes issues
**\<Jaquee>** makes sense. there were a lot of code conflicts last week that could have been avoided
**\<medusa_>** or can cause issues
**\<@fluffypony>** medusa_: merging stuff rapidly is a bad idea, we need eyes on code
**\<Jaquee>** \*merge conflicts
**\<+moneromooo>** I asked for PRs to stay open for a while so I have a change to see htem and review (monero repo anyway).
**\<@fluffypony>** which means small PRs, that multiple people have looked at
**\<@fluffypony>** I know it means that some PRs have to be rebased 3 times (sorry moneromooo)
**\<medusa_>** i agree the right balance isnt easy, im sure we get the balance again
**\<@fluffypony>** but it's better than stuff slipping in to the code
**\<medusa_>** normally it also wroks well
**\<+moneromooo>** No worries, it's less work than making them in the first place usually :)
**\<medusa_>** this week was pretty extreme in all forms
**\<@fluffypony>** medusa_: the QML stuff is pretty rough in terms of merge conflicts too
**\<endogenic>** maybe there can be a structure where the required reviewers are identified by the master maintainer, notified, and must sign off before the thing can be merged ?
**\<_Slack> \<nanoakron>** I agree that issues should sit and ferment for a while, but sometimes there are hotfixes required like with fluffy blocks
**\<@fluffypony>** endogenic: too structured; has a bus factor
**\<gingeropolous>** is dev branch happening?
**\<@fluffypony>** gingeropolous: no not atm
**\<Jaquee>** ok. security first. i'm sure it works ok most of the time. 2 last weeks was extreme.
**\<@fluffypony>** indeed
**\<Jaquee>** but we could keep this in mind and evaluate further on?
**\<medusa_>** yes you stay on watch ;-)
**\<Jaquee>** :D
**\<@fluffypony>** Jaquee: yes absolutely
**\<gingeropolous>** would the dev branch approach be a way to get around the merge "bottleneck" ? i assume its still complicated b/c of zeromq..
**\<gingeropolous>** or are u talking about core. (i will shut up now)
**\<_Slack> \<nanoakron>** What's the plan if something horrible happens to you FP, like going on holiday for a month without internet access?
**\<proxmr>** Hello guys
**\<@fluffypony>** gingeropolous: no, you still can't have fine-grained collaborators on a per-branch basis
**\<endogenic>** nanoakron: dead pony switch?
**\<_Slack> \<nanoakron>** Lol. Yeah :) (also :( )
**\<endogenic>** yeah
**\<endogenic>** :’(
**\<Jaquee>** but you can have branch specific permissions right?
**\<Jaquee>** not sure if it would help though.
**\<maitscha>** "protected branches"
**\<@fluffypony>** Jaquee: you can, and it might be worth fiddling with later on
**\<Jaquee>** all right
**\<Jaquee>** imo we can leave this subject for now.
**\<Jaquee>** any more questions regarding the gui?
**\<asdef>** irc logs anywhere? for people who came too late
**\<proxmr>** Is the gui coming in 2 days ?
**\<maitscha>** Jaquee: how can I start the GUI under MacOS and get the console output?
**\<@fluffypony>** proxmr: no, that's not how software development works
**\<Jaquee>** maitscha: one sec
**\<maitscha>** Jaquee: that would help debugging ...
**\<Jaquee>** maitscha: build/release/bin/monero-core.app/Contents/MacOS/monero-core
**\<asdef>** any screenshots already existing? so we can see an be happy?
**\<Jaquee>** in monero-core dir
**\<proxmr>** Sorry, some guy just told me on some forum, so i came to check. i appologize
**\<maitscha>** ah ok
**\<iDunk>** maitscha: doesn't it give outout when started from the command line like on linux?
**\<medusa_>** asdef: check reddit
**\<_Slack> \<nanoakron>** No worries.
**\<maitscha>** I always started it with the finder
**\<dEBRUYNE>** Please don't interrupt the dev meeting
**\<Jaquee>** iDunk: yes. but it's not that easy to find the binary
**\<Jaquee>** it's in the .app package
**\<iDunk>** ok
**\<maitscha>** Jaquee: works, thanks
**\<Jaquee>** yw
**\<Jaquee>** all right.
**\<Jaquee>** more gui related?
**\<_Slack> \<nanoakron>** None here
**\<maitscha>** there are at least 2 people who would like to make a style guide
**\<_Slack> \<nanoakron>** That's a good idea
**\<maitscha>** should this be coordinated?
**\<medusa_>** i think the best place to discuss specific stuff is either on github or here in the channel
**\<Jaquee>** yes. that would be good. not sure how. but i can ask them to get in contact with each other to start
**\<vertp>** Can we discuss an issue freeze for the beta release? I think we have all the features we need for an "MVP" and there doesnt seem to be any major outstanding bugs.
**\<maitscha>** or at least a place where people can post design/ux-related improvements?
**\<@fluffypony>** github
**\<Guest5849>** Confused ... ? Quote: \<@fluffypony> so it will take a couple of days to wrap up a point release too. Does that not relate to the GUI being released?
**\<_Slack>** **\<tfi_charmers>** Yes, styleguide, one was me. I’m still able to help.
**\<@fluffypony>** Guest5849: a beta, yes
**\<medusa_>** vertp: the features are basically freezed, we just change what we think is worth changing (and the treshold for that goes up each day)
**\<@fluffypony>** vertp: "freezing" things doesn't really work for a fluid open-source project
**\<_Slack> \<nanoakron>** Where's the best place to coordinate a style guide? A new Git repo or a wiki?
**\<medusa_>** always considering risk reward ofc
**\<@fluffypony>** people open issues, they get fixed, eventually you hit enough milestones / new features for a new release
**\<vertp>** I mean freeze in the sense that of course you allow new issues to be open, but the work is prioritized based on existing issues and bugs
**\<@fluffypony>** vertp: can't really force someone to work on anything
**\<maitscha>** vertp: you can't stop people from working on features ;)
**\<@fluffypony>** so if people want to work on new features instead of tackling bugs that's their prerogative
**\<vertp>** I agree, I mean more for illya and jaquee
**\<pero>** generally an 'issue freeze' is a bad idea
**\<@fluffypony>** can't force them either ;)
**\<medusa_>** vertp: we have to always allow people opening issues. their feedback is very valuable
**\<pero>** a feature freeze is an entirely different thing and is already somewhat implemented
**\<vertp>** I agree medusa_
**\<Jaquee>** vertp: me and ilya are more or less frozen for the moment. :P
**\<@fluffypony>** yes
**\<Jaquee>** as in agreed on that current version can be released as beta
**\<_Slack> \<nanoakron>** Vertp: we just follow a simple alpha -> beta -> release methodology, keeping in mind that even point releases are beta software under constant development
**\<vertp>** Awesome, thats what I was going for Jaquee
**\<vertp>** I just feel that its stable enough at this point to justify a beta without doing any additional feature dev. Thats what I meant by issue freeze
**\<vertp>** Which I think we all agree on
**\<Jaquee>** yes
**\<vertp>** great!
**\<medusa_>** yes wa try to be very pragmatic
**\<_Slack> \<nanoakron>** This has side tracked us slightly. Where's the best place to coordinate a style document?
• moneromooo: eyes this suspiciously
**\<@fluffypony>** Github has this new thing called Projects
**\<iDunk>** wat
**\<Jaquee>** nanoakron. not sure. github best place for the moment
**\<@fluffypony>** aI want to play with it and see if it's suitable for that
**\<_Slack> \<nanoakron>** Cool
**\<Jaquee>** fluffypony: sounds interesting.
**\<Jaquee>** tfi_charmers: can you sync with that other ux guy?
**\<_Slack> \<nanoakron>** Does sound interesting
**\<Jaquee>** so you don't end up working on the same issues
**\<@fluffypony>** ok - can we call this meeting done?
**\<_Slack>** **\<tfi_charmers>** @jaquee can do.
**\<Jaquee>** great
**\<Jaquee>** fluffypony: yes
**\<@fluffypony>** ok tks
**\<+moneromooo>** Just one thing before: when does someone else do the builds ?
**\<_Slack> \<nanoakron>** I was going to raise the issue of databases if hyc, fp and mooo are in the same room
**\<iDunk>** hyc is roaming belfast
**\<_Slack> \<nanoakron>** A veritable vipers nest of opinions ;)
**\<iDunk>** anyway, i'm with fluffypony and moneromooo on the db issue
**\<_Slack> \<nanoakron>** Why do we need the ability to iterate and test the database back end in production code?
**\<_Slack> \<nanoakron>** And aren't we effectively overruling our resident database expert, hyc?
• moneromooo: facepalms
**\<iDunk>** ^
**\<gingeropolous>** where's this discussion? i totally missed this one. not that I can do anything.
**\<_Slack> \<nanoakron>** It's a PR of mine
**\<_Slack> \<nanoakron>** Mooo, why the facepalm? When or where are we going to need to change the database away from LMDB in the future in such a way that we need the selection code?
**\<_Slack> \<nanoakron>** As it stands we're shipping code thats never run, with requirements that are never used.
**\<+moneromooo>** Because being an expert in databases does not extend to having an expert opinion on whether a selection system in a particular project is best or not.
**\<+moneromooo>** And not knowing the particulars of a future db implementation does not by itself imply any groundworks should be dismantled at once.
**\<gingeropolous>** and the prebuild binaries are all LMDB, right? so its not like anything's being shipped...
**\<gingeropolous>** \*prebuilt
**\<+moneromooo>** The current ones all are, yes.
**\<dogecoinsarefun>** fluffyblocks still LMDB too right?
**\<+moneromooo>** Unrelated.
**\<dogecoinsarefun>** ok sorry
**\<+moneromooo>** I mean, this was an obvious appeal to authority, in a context where the authority is only tangential.
**\<+moneromooo>** I find it counterproductive to remove a useful thing, if its removal will make it a lot easier to break the ability to add another db. It's not like it's a lot of code I think.
**\<iDunk>** agreed
**\<+moneromooo>** There was a all RAM db being worked on, though I'm not sure it still is.
**\<_Slack> \<nanoakron>** So has the compiler been smart enough to strip the selection stuff or is there still bloat and overhead that could be trimmed?
**\<_Slack> \<nanoakron>** Appeal to authority is only a fallacy when the authority is not relevant to the issue at hand
**\<@ArticMine>** There was at one point the idea that Monero could use different databases in the future.
**\<+moneromooo>** You actually might make a good argument by removing it all and see whether performance figures support you bloat claim.
**\<_Slack> \<nanoakron>** I'll try that
**\<+moneromooo>** Now, the threshold where an improvement becomes larger than the loss of generality is pretty subjective too.
**\<_Slack> \<nanoakron>** As for the PR - would you reject it for stripping out the Berkeley DB selection in CMakeLists.txt, or is that acceptable because we're not going back to BDB?
**\<gingeropolous>** is it just for compiling performance?
**\<+moneromooo>** IIRC, I said keep the selcetion code, just remove the bdb option.
**\<_Slack> \<nanoakron>** I'm happy to keep the selection code in the main body, but are you happy with the structure of the current PR wrt stripping BDB from CMakelists.txt? There wasn't a selector in there afaik
**\<+moneromooo>** Basically, you should be able to add another db by duplicating the lmdb bits. Anything that's shared needs to stay for this to be useful.
**\<_Slack> \<nanoakron>** I'm happy to leave the selector alone in the main code
**\<+moneromooo>** In the details ? I'll have to go read the code to know for sure.
**\<+moneromooo>** And I'm busy debugging some cold signing stuff now, so that'll be later.
**\<_Slack> \<nanoakron>** Understood. Please have a look at the PR and what's been stripped wrt BDB when you can. If that's still to much then I'll close and amend. By the time we get to using additional databases the CMakeLists file will have been changed many more times anyway.
**\<_Slack> \<nanoakron>** And the final thing I wanted to ask today was whether FP could keep killing cold issues ;)
**\<_Slack> \<nanoakron>** Tis all from me

265
_posts/2016-11-27-logs-for-the-Kovri-dev-meeting-held-on-2016-11-27.md Normal file
View file

@ -0,0 +1,265 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-11-27
summary: Brief review of what has been completed since last meeting, Alpha release, and code & open tickets discussion
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*November 27th, 2016*
# Logs
**\<i2p-relay> {-fluffypony}** ok anonimal
**\<i2p-relay> {-fluffypony}** Kovri meeting start, all yours
**\<i2p-relay> {-meeting-bot} [anonimal]** 1. Greetings
**\<i2p-relay> {-meeting-bot} [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<i2p-relay> {-meeting-bot} [anonimal]** 3. Status of alpha release preparations - https://github.com/monero-project/kovri/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20milestone%3A0.1.0-alpha%20
**\<i2p-relay> {-meeting-bot} [anonimal]** 4. Code + ticket discussion / Q & A
**\<i2p-relay> {-meeting-bot} [anonimal]** 5. Any additional meeting items
**\<i2p-relay> {-meeting-bot} [anonimal]** 6. Confirm next meeting date/time
**\<i2p-relay> {-meeting-bot} [anonimal]** Hi
**\<i2p-relay> {-meeting-bot} [anonimal]** 1.
**\<i2p-relay> {-fluffypony}** hi
**\<i2p-relay> {-guzzi}** hi
**\<i2p-relay> {-fluffypony}** asl?
**\<ArticMine>** Hi
**\<i2p-relay> {-iDunk}** hi
**\<i2p-relay> {-olark}** Greetings
**\<moneromooo>** Hi
**\<i2p-relay> {-meeting-bot} [anonimal]** Hi fluffypony guzzi olark iDunk ArticMine moneromooo
**\<i2p-relay> {-meeting-bot} [anonimal]** EinMByte is idling as are the others, afaict.
**\<i2p-relay> {-meeting-bot} [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<binaryFate>** late greetings. watching.
**\<i2p-relay> {-meeting-bot} [anonimal]** I'll keep it generic: bug fixes (many were difficult bugs) + refactoring, mentoring, and research.
**\<i2p-relay> {-meeting-bot} [anonimal]** *Poof!* done.
**\<i2p-relay> {-meeting-bot} [anonimal]** Anything else on 2? :)
**\<i2p-relay> {-fluffypony}** can I add to 2?
**\<i2p-relay> {-meeting-bot} [anonimal]** git log and github are available for details.
**\<i2p-relay> {-meeting-bot} [anonimal]** Of course fluffypony
**\<i2p-relay> {-fluffypony}** I'd like to congratulate anonimal on completing his first milestone, even if he won't admit to it yet :-P
**\<i2p-relay> {-fluffypony}** first full-time FFS "employee", first milestone :)
**\<i2p-relay> {-meeting-bot} [anonimal]** Grr! Well, thank you fluffypony.
**\<i2p-relay> {-guzzi}** and thanks for mentoring.
**\<i2p-relay> {-fluffypony}** and we didn't even need to blockchain it!
**\<i2p-relay> {-olark}** Good work. ;)
**\<i2p-relay> {-meeting-bot} [anonimal]** Because of the large amount of non-code work, I hadn't felt comfortable with a payout yet. I'll get to that this week.
**\<i2p-relay> {-fluffypony}** I think everyone here will attest to the amount of work you do
**\<i2p-relay> {-guzzi}** no doubt.
**\<i2p-relay> {-meeting-bot} [anonimal]** No problem guzzi, thank *you* for your great progress.
**\<i2p-relay> {-fluffypony}** "anonimal made me the man I am today" - fluffypony, 2016
**\<i2p-relay> {-olark}** He's called anonimal for a reason haha
**\<i2p-relay> {-fluffypony}** olark: coupled with my quote I think that's one for the history books
**\<i2p-relay> {-meeting-bot} [anonimal]** lol oh you guys, thanks for acknowledgements. I'm glad to be here with you all.
**\<i2p-relay> {-meeting-bot} [anonimal]** I'd love to dwell on the work accomplished over the past two weeks but I think we can move on, any objections?
**\<i2p-relay> {-guzzi}** onward
**\<i2p-relay> {-fluffypony}** let's move on
**\<i2p-relay> {-meeting-bot} [anonimal]** 3. Status of alpha release preparations - https://github.com/monero-project/kovri/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20milestone%3A0.1.0-alpha%20
**\<i2p-relay> {-meeting-bot} \* anonimal** clicks
**\<i2p-relay> {-meeting-bot} [anonimal]** Ok, don't be alarmed, but it's actually not a lot if you look carefully.
**\<i2p-relay> {-meeting-bot} [anonimal]** Some of these can even be moved to next milestone if needed.
**\<i2p-relay> {-meeting-bot} [anonimal]** fluffypony: can you give a status on 33c3 and your thoughts on a release (like we spoke about earlier)?
**\<i2p-relay> {-fluffypony}** yes
**\<i2p-relay> {-fluffypony}** so our original plan was to co-host an assembly with i2p at 33C3
**\<i2p-relay> {-fluffypony}** basically hosting an i2p + Monero table
**\<i2p-relay> {-fluffypony}** and then have the Kovri alpha ready by then
**\<i2p-relay> {-fluffypony}** unfortunately this year's congress ticketing setup has been a mess
**\<i2p-relay> {-fluffypony}** through no fault of their own, this is the most popular CCC ever
**\<i2p-relay> {-fluffypony}** we tried to book 10+ tickets at all 3 of the public booking dates
**\<i2p-relay> {-fluffypony}** and got nothing
**\<i2p-relay> {-meeting-bot} [anonimal]** Wow, that's insane.
**\<i2p-relay> {-fluffypony}** I managed to get tickets for myself and othe, after the fact
**\<i2p-relay> {-fluffypony}** but it's not enough to man a table - we'd have needed 8+ community members for htat
**\<i2p-relay> {-fluffypony}** that
**\<i2p-relay> {-fluffypony}** in view of the foregoing, we're no longer obligated to hit our alpha release date
**\<i2p-relay> {-meeting-bot} [anonimal]** Ok, well that's great to hear you at least got two tickets.
**\<i2p-relay> {-fluffypony}** this doesn't mean we won't stick to it, but it means we can choose how we want to plan it
**\<i2p-relay> {-meeting-bot} [anonimal]** Ok, well here are my thoughts on the reality of the situation, I'll try to choose my words wisely:
**\<i2p-relay> {-meeting-bot} [Jake__]** Is their any news on the GUI beta binaries.
**\<i2p-relay> {-meeting-bot} [fluffypony]** Jake__: this is the Kovri meeting
**\<i2p-relay> {-meeting-bot} [fluffypony]** you can ask later
**\<i2p-relay> {-meeting-bot} [Jake__]** Nvm
**\<i2p-relay> {-meeting-bot} [Jake__]** My mistake
**\<i2p-relay> {-meeting-bot} [anonimal]** even with all milestone issues resolved, the release wouldn't be a spectacular one, and frankly may have more negative consequences than positive.
**\<i2p-relay> {-meeting-bot} [anonimal]** I mean, sure, I can most likely get everything done in time, but is it really worth it?
**\<i2p-relay> {-fluffypony}** anonimal: that's fair
**\<i2p-relay> {-meeting-bot} [anonimal]** The packaging aspect alone will be 'fun' to deal with, *especially* come upgrade time.
**\<i2p-relay> {-fluffypony}** are we auto-upgrading ala Java i2p?
**\<i2p-relay> {-meeting-bot} [anonimal]** And really, an auto-updater would be great on that front - and that's not terribly hard to do now that more work has been done elsewhere.
**\<i2p-relay> {-meeting-bot} [anonimal]** We wouldn't if we released this month unless I dropped other higher priority issues.
**\<i2p-relay> {-meeting-bot} \* anonimal** thinking
**\<i2p-relay> {-fluffypony}** look
**\<i2p-relay> {-fluffypony}** zzz2 will attest to the fact that part of i2p's network stability is due to the auto-updater
**\<i2p-relay> {-fluffypony}** so let's not rush something out that doesn't have that
**\<moneromooo>** Do I understand code that will fetch more code and run it on the user's machine ? Unprompted ?
**\<moneromooo>** Or merely tell the user there's an update to install at their earliest convenience ?
**\<i2p-relay> {-fluffypony}** moneromooo: it's opt-out, yes
**\<moneromooo>** That;s not nice.
**\<i2p-relay> {-fluffypony}** moneromooo: you could do a decaying prompt
**\<moneromooo>** What is this ?
**\<i2p-relay> {-fluffypony}** prompt the user, if after 15 days they haven't installed it, then install it for them
**\<i2p-relay> {-meeting-bot} [anonimal]** The current UI does not provide any useful control to an end-user.
**\<moneromooo>** I suppose that's less nasty.
**\<i2p-relay> {-fluffypony}** moneromooo: there's just been a spate of bannings on the network, of old clients that aren't updated
**\<i2p-relay> {-fluffypony}** if there's data leakage on older clients it can compromise newer ones
**\<i2p-relay> {-fluffypony}** so it's not something to be taken lightly
**\<i2p-relay> {-meeting-bot} [anonimal]** So, we could fix that first and then focus on release imho. Really who benefits from a release? Will it be developers? Will developers suddenly become more interested in kovri? Or is it purely for the end-user's benefit?
**\<i2p-relay> {-fluffypony}** end users
**\<i2p-relay> {-fluffypony}** do we even have a stable API for devs?
**\<i2p-relay> {-guzzi}** realease implies end users imo.
**\<i2p-relay> {-meeting-bot} [anonimal]** Nope, more router issues to fix first.
**\<i2p-relay> {-fluffypony}** ok so then end users :)
**\<i2p-relay> {-meeting-bot} [anonimal]** I agree with guzzi, but I still like the idea of feeling accomplished with a release by the end of the year.
**\<i2p-relay> {-meeting-bot} [anonimal]** I guess anything called "release" will hold a certain weight,
**\<i2p-relay> {-meeting-bot} [anonimal]** Maybe we can compromise, find a middle-ground somehow.
**\<i2p-relay> {-fluffypony}** true
**\<i2p-relay> {-meeting-bot} [anonimal]** I'd like to work with pigeons on nightly releases, that could be a start.
**\<i2p-relay> {-meeting-bot} [anonimal]** I don't think we'll have the website done in time (will we?)
**\<i2p-relay> {-meeting-bot} [anonimal]** As for "release", I can simply throw the bundle together in nightly releases.
**\<i2p-relay> {-meeting-bot} [anonimal]** I think what people really want is something that "feels" released.
**\<i2p-relay> {-meeting-bot} [anonimal]** The title means nothing really.
**\<i2p-relay> {-fluffypony}** we can couple nightlies with the Monero nightlies
**\<i2p-relay> {-meeting-bot} [anonimal]** Sounds fair.
**\<i2p-relay> {-fluffypony}** on the list of alpha issues
**\<i2p-relay> {-fluffypony}** we've made progress on the Zoho setup
**\<i2p-relay> {-fluffypony}** it's been a bit of a PITA, but pigeons has figured most of it out
**\<i2p-relay> {-fluffypony}** we'll be moving getmonero.org over in the next week or so, and then we can do Kovri emails too
**\<i2p-relay> {-meeting-bot} [anonimal]** Ok, sounds good.
**\<i2p-relay> {-meeting-bot} [anonimal]** So, nightly releases for kovri would be slightly different that monero because we have to bundle certificates and other things along with a static binary.
**\<i2p-relay> {-meeting-bot} [pigeons]** I beleive you said currently the make system doesnt have an option yet for a static build, right?
**\<i2p-relay> {-meeting-bot} [anonimal]** I could consider it a fair compromise if, instead of both nightly release and official alpha release, to stick focus more on ensuring reliable nightly releases (which would also give me more time to work on more important issues).
**\<i2p-relay> {-meeting-bot} [MEATPLOW]** im here for the free food
**\<i2p-relay> {-meeting-bot} [anonimal]** pigeons: for kovri? No, we can build static.
**\<i2p-relay> {-meeting-bot} [fluffypony]** MEATPLOW: we have snacks and beer after the meetings
**\<i2p-relay> {-meeting-bot} [pigeons]** wow i thought thats why you told me to remove the build uploads
**\<i2p-relay> {-iDunk}** win builds are not realy static
**\<i2p-relay> {-meeting-bot} [anonimal]** pigeons: no, I said we need to bundle files or else the static build is useless (people will download, run it, and it won't get to reseed).
**\<i2p-relay> {-meeting-bot} [pigeons]** OK
**\<i2p-relay> {-meeting-bot} [anonimal]** iDunk: if there are windows static issues then that would be another thing we could focus on for a solid nightly build
**\<i2p-relay> {-iDunk}** win64 is not static at all, win32 looks static but still requires dlls from msys2
**\<i2p-relay> {-meeting-bot} [anonimal]** fluffypony: so final verdict for alpha release: focus on getting nightly releases ready in place of a single release?
**\<i2p-relay> {-fluffypony}** yes
**\<i2p-relay> {-meeting-bot} [anonimal]** (at least for this month)
**\<i2p-relay> {-fluffypony}** make pigeons work
**\<i2p-relay> {-meeting-bot} [anonimal]** lol
**\<i2p-relay> {-fluffypony}** :-P
**\<i2p-relay> {-iDunk}** :)
**\<i2p-relay> {-meeting-bot} [anonimal]** Ok, how does that sound to everyone? Yay? Nay?
**\<i2p-relay> {-iDunk}** Yay
**\<moneromooo>** Sounds good to this member of the peanut gallery
**\<i2p-relay> {-olark}** Nightly builds are a good compromise imo.
**\<i2p-relay> {-olark}** Yay
**\<i2p-relay> {-meeting-bot} [anonimal]** Awesome. guzzi, any thoughts?
**\<i2p-relay> {-guzzi}** sounds awesome
**\<i2p-relay> {-meeting-bot} [anonimal]** He may be AFK.
**\<i2p-relay> {-guzzi}** excited
**\<i2p-relay> {-meeting-bot} [anonimal]** Oh there you are, ok great.
**\<i2p-relay> {-guzzi}** this will be motivating
**\<i2p-relay> {-meeting-bot} [anonimal]** Excellent! Moving on,
**\<i2p-relay> {-meeting-bot} [anonimal]** 4. Code + ticket discussion / Q & A
**\<i2p-relay> {-meeting-bot} [anonimal]** Focusing on those milestone issues,
**\<i2p-relay> {-meeting-bot} [anonimal]** fluffypony: I've seen someone pop into #monero-dev from time to time offering webdev, did anything come of that?
**\<i2p-relay> {-fluffypony}** no, they're mostly put off when they get told they can't use Javascript
**\<i2p-relay> {-fluffypony}** :-P
**\<i2p-relay> {-meeting-bot} [anonimal]** lol
**\<i2p-relay> {-meeting-bot} [anonimal]** Ok, so once zoho is resolved then the site (server) can come online?
**\<i2p-relay> {-meeting-bot} [anonimal]** And the rest is a matter of code/content?
**\<i2p-relay> {-fluffypony}** yes
**\<i2p-relay> {-fluffypony}** well two things actually
**\<i2p-relay> {-fluffypony}** Zoho is for email
**\<i2p-relay> {-fluffypony}** the new hosting infrastructure is for site
**\<i2p-relay> {-fluffypony}** both are running parralel-ish
**\<i2p-relay> {-fluffypony}** parallel-ish
**\<i2p-relay> {-meeting-bot} [anonimal]** https://github.com/monero-project/kovri/issues/46#issuecomment-242990742
**\<i2p-relay> {-meeting-bot} [vertp]** Is there a new site going up to replace getmonero?
**\<i2p-relay> {-meeting-bot} [anonimal]** lol, time will fly.
**\<i2p-relay> {-meeting-bot} [vertp]** Oh, kovri. sorry
**\<i2p-relay> {-meeting-bot} [anonimal]** vertp: good question, fluffypony is getmonero getting work done too?
**\<i2p-relay> {-fluffypony}** no
**\<i2p-relay> {-fluffypony}** same deal
**\<i2p-relay> {-fluffypony}** every time someone says "WE MUST REDESIGN THE WEBSITE"
**\<i2p-relay> {-fluffypony}** then I go "ok, make sure to design the forum to match, and you must have non-JS fallbacks"
**\<i2p-relay> {-fluffypony}** and they slink off into the distance
**\<i2p-relay> {-meeting-bot} [pero]** website is fine imo
**\<i2p-relay> {-meeting-bot} [anonimal]** hahaha
**\<i2p-relay> {-meeting-bot} [vertp]** I think getmonero is perfectly fine as is for the record, just was wondering what "this" site was in reference to
**\<i2p-relay> {-meeting-bot} [ferretinjapan]** :)
**\<i2p-relay> {-fluffypony}** I'm going to write a garbage collector daemon called Waste
**\<i2p-relay> {-fluffypony}** and the binary will be wasted
**\<i2p-relay> {-meeting-bot} [anonimal]** muh js
**\<i2p-relay> {-meeting-bot} [pero]** it has a refreshing aura of authenticity
**\<i2p-relay> {-fluffypony}** and the website will be getwasted.org
**\<i2p-relay> {-meeting-bot} [hyc]** lol
**\<i2p-relay> {-meeting-bot} [MrWatcher]** he
**\<i2p-relay> {-meeting-bot} \* anonimal** lol, hears drum rimshot
**\<moneromooo>** So... next time someone asks about the website, I've got a ready made answer: "slink off"
**\<i2p-relay> {-fluffypony}** "slink you too, buddy!"
**\<i2p-relay> {-meeting-bot} [anonimal]** I think the rest of the issues speak for themselves. One question though,
**\<i2p-relay> {-meeting-bot} [anonimal]** Can anyone reproduce #434 on their armv7 device?
**\<i2p-relay> {-fluffypony}** the only arm device I have access to right now is the one under my sleeve device
**\<i2p-relay> {-fluffypony}** but I'll try it when I'm back home
**\<i2p-relay> {-guzzi}**
**\<i2p-relay> {-meeting-bot} [anonimal]** lol, more drum rimshots, fluffypony is on a roll.
**\<i2p-relay> {-meeting-bot} [anonimal]** guzzi olark: anything on point 4 "Code + ticket discussion / Q & A"?
**\<i2p-relay> {-olark}** All good ;)
**\<i2p-relay> {-meeting-bot} [anonimal]** guzzi is probably at the beach again.
**\<i2p-relay> {-olark}** Slurping up a margarita.
**\<i2p-relay> {-meeting-bot} [anonimal]** hah
**\<i2p-relay> {-meeting-bot} [anonimal]** Ok, moving on. 5. Any additional meeting items
**\<i2p-relay> {-fluffypony}** the glamorous life of a Kovri contributor
**\<i2p-relay> {-fluffypony}** nothing from my side
**\<i2p-relay> {-fluffypony}** * eyes his beer
**\<i2p-relay> {-meeting-bot} [_Slack] \<nanoakron>** Beer? Sacrilege for a South African…although I hear there’s a good craft scene developing.
**\<i2p-relay> {-meeting-bot} [anonimal]** Quite glamorous indeed.
**\<moneromooo>** I'll mention again that I reaaally hate software that will take it upon itself to download/run stuff.
**\<i2p-relay> {-meeting-bot} [anonimal]** Nothing additional from me.
**\<i2p-relay> {-fluffypony}** moneromooo I know, but think about the average Kovri user
**\<i2p-relay> {-fluffypony}** (in the future, not now)
**\<moneromooo>** The average kovri user may well be prompted.
**\<i2p-relay> {-meeting-bot} [taushet]** moneromooo, so no 30-day trial from McAfee with the Kovri binaries then?
**\<i2p-relay> {-fluffypony}** LOL
**\<i2p-relay> {-meeting-bot} [iDunk]** LOL
**\<i2p-relay> {-olark}** Now that fluffypony brang up using TweetNaCl in the monero meeting. Are there any boundaries for Kovri using TweetNaCl functions where possible?
**\<i2p-relay> {-fluffypony}** and a personal introductory video from McAfee himself ?
**\<i2p-relay> {-olark}** I just have recently been fascinated with TweetNaCl, Salsa20 etc that it seems Kovri could benefit from some of those functions.
**\<i2p-relay> {-olark}** A compact crypto library for a compact i2p router. Am I right? ;D
**\<i2p-relay> {-meeting-bot} [anonimal]** moneromooo: me too. I think as long as it's optional we should be ok.
**\<moneromooo>** Excellent. So opt-in :)
**\<moneromooo>** (and banned until upgraded is fine as a protection)
**\<i2p-relay> {-olark}** Just spitballing anyway.
**\<i2p-relay> {-guzzi}** all good for me on #4. i am learning a ton. as fast as I am able to.
**\<i2p-relay> {-fluffypony}** olark: yeah definitely
**\<i2p-relay> {-meeting-bot} [anonimal]** cryptopp has salsa20.
**\<i2p-relay> {-fluffypony}** I think the important thing is identifying where TweetNaCl's correctness is useful
**\<i2p-relay> {-fluffypony}** because it sacrifices performance for verifiable correctness
**\<i2p-relay> {-olark}** Right.
**\<i2p-relay> {-olark}** Salsa20 is faster than AES256, but ya in general because of the conciseness of the code it is not as effecient as it could be. Favouring it being easy to audit.
**\<i2p-relay> {-olark}** etc
**\<i2p-relay> {-meeting-bot} [anonimal]** I'd want to review before jumping on the tweenacl train.
**\<i2p-relay> {-meeting-bot} [anonimal]** If it can't replace supercop then I don't see much of a point.
**\<i2p-relay> {-meeting-bot} [anonimal]** *If*.
**\<i2p-relay> {-olark}** Taking advantage of TweetNaCl's verifiable correctness I think is more valuable then the slight downside of mildly less effecient operations.
**\<i2p-relay> {-olark}** TweetNaCl has ed25519 signing operations.
**\<i2p-relay> {-olark}** Is the most recent paper afaik
**\<i2p-relay> {-olark}** https://tweetnacl.cr.yp.to/tweetnacl-20140917.pdf
**\<i2p-relay> {-fluffypony}** TweetNaCl is the successor to SUPERCOP in many ways
**\<i2p-relay> {-meeting-bot} [anonimal]** Release dates not being one of them if latest tweetnacl was 2014.
**\<i2p-relay> {-fluffypony}** they're not adding functions
**\<i2p-relay> {-fluffypony}** so there aren't new releases except to fix bugs
**\<i2p-relay> {-olark}** It is the original 25 NaCl functions.
**\<i2p-relay> {-fluffypony}** and given its conciseness there haven't been many of those
**\<i2p-relay> {-meeting-bot} [anonimal]** Needs more research on our end. We also use other functions from supercop.
**\<i2p-relay> {-meeting-bot} [anonimal]** 18:00, out of time, I'll be around after the meeting.
**\<i2p-relay> {-fluffypony}** kk
**\<i2p-relay> {-meeting-bot} [anonimal]** 6. Confirm next meeting date/time
**\<i2p-relay> {-fluffypony}** meeting bot going down
**\<i2p-relay> {-olark}** I agree. TweetNaCl is definitely something to consider. Will take more consideration, but I think could be very useful for both Kovri and Monero.
**\<i2p-relay> {-meeting-bot} [anonimal]** Same time, two weeks?
**\<i2p-relay> {-fluffypony}** oh after 6
**\<i2p-relay> {-olark}** Sounds good.
**\<i2p-relay> {-meeting-bot} [anonimal]** fluffypony: 17:00 ok? Same time?
**\<i2p-relay> {-guzzi}** ok with me
**\<i2p-relay> {-fluffypony}** ok
**\<i2p-relay> {-fluffypony}** done and dusted
**\<i2p-relay> {-olark}** Good talk everyone :D
**\<i2p-relay> {-fluffypony}** meeting bot off

248
_posts/2016-11-27-overview-and-logs-for-the-dev-meeting-held-on-2016-11-27.md Normal file
View file

@ -0,0 +1,248 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-11-27
summary: Brief update on next point release, Ring CT, 0MQ (and authentication), GUI, and crypto libs
tags: [dev diaries, core, crypto, 0mq]
author: dEBRUYNE / fluffypony
---
*November 27th, 2016*
# Overview
An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-dev-meeting-note-highlights-and-transcript-2016-11-27).
# Logs
**\<tewinget>** ugh, I wanted to stay up for the dev meeting, but I just...can't.
**\<tewinget>** I'll put an update here in a minute or two though, someone can paste it for me perhaps.
**\<fluffypony>** tks tewinget
**\<tewinget>** so the daemon and wallet talk via zmq now (yay!)
**\<tewinget>** both have the requisite command line parameters. I added new ones for the daemon since I'm leaving the old RPC in place for now, but that's specifics that can change on a whim, of course.
**\<tewinget>** (parameters like bind port/address and such)
**\<tewinget>** don't have any rpc security features like user agent and what-not put in yet, that'll come with time.
**\<tewinget>** modifications to wallet to use new rpc are "complete", but not working yet. needs iteration. was working on that now, but I'm fucking exhausted, hence the not staying up for the meeting.
**\<moneromooo>** user-agent was a quick fix anyway. It should not be merged in 0MQ. Proper auth should be done instead.
**\<tewinget>** once I get *that* ironed out, I'll put together some simple documentation on what the rpc calls look like
**\<moneromooo>** And ty and good night :)
**\<tewinget>** my python script is a bit broken, but I updated one of the functions to work
**\<tewinget>** (because I changed it to be JSON-RPC 2.0 compliant)
**\<tewinget>** I'll pastebin that and paste a link here in a sec
**\<tewinget>** hard_fork_info() is the one that uses the jsonrpc format, others can be easily modified to comply
**\<tewinget>** err...that more or less sums things up, I think. any qvestions?
**\<tewinget>** https://paste.fedoraproject.org/490609/57957148/
**\<tewinget>** need python's zmq libs, of course, and zmq version 4ish should suffice as far as OS libs for building
**\<tewinget>** I'll stay up a few more minutes in case anyone has any questions, but I do need to go and sleep.
**\<ferretinjapan>** yo
**\<fluffypony>** welcome, welcome
**\<fluffypony>** ok so
**\<fluffypony>** since we last met
**\<Jaquee>** hi
**\<fluffypony>** there have been quite a few merge sessions
**\<fluffypony>** or merge sesh's as I like to call them
**\<fluffypony>** coz, you know, when you've been a maintainer as long as I have, you learn to give things little names otherwise you'll go mad
**\<Jaquee>** lol
**\<fluffypony>** there have been some major reworks to the threading model, courtesy of vtnerd
**\<fluffypony>** who also split part of monero-wallet-cli off into monero-wallet-rpc
**\<fluffypony>** (which we had previously done on the old dev branch, as you may recall)
**\<fluffypony>** gingeropolous started pushing more code than a troll dev should, so he's kinda progressed beyond that
**\<fluffypony>** moneromooo shot down bug after bug
**\<fluffypony>** kenshi84 started working on one-time addresses without using the integrated address format we currently have
**\<fluffypony>** @NanoAkron also fixed some errant armv8 things
**\<fluffypony>** and then on the Monero Core side tons of fixes, small and large, primarily by moneromooo and Jaquee
**\<fluffypony>** abrkn also had their first PR merged to Monero Core, so welcome to a new contributor
**\<fluffypony>** xmr-eric also had a pair of PRs, so he's almost at 5 PRs which is excellent
**\<fluffypony>** as it stands right now there is a weird segfault occurring occasionally, at least on macOS
**\<fluffypony>** and possibly other operating systems
**\<fluffypony>** this is a blocker to the next tagged release
**\<ferretinjapan>** ubuntu as well^
**\<fluffypony>** also running LMDB in "fast" mode may be unsuitable for Windows - hyc, what are your thoughts on that?
**\<asok>** debian also ^
**\<hyc>** still gathering data
**\<hyc>** asked that user what happened oin his prior run, whether PC crashed etc
**\<fluffypony>** ok - so that's a possible blocker to the tagged release
**\<fluffypony>** and then in new, relevant info, Shen has begun a thorough review of the RingCT implementation
**\<fluffypony>** and already there are a couple of nigglies, some carried across from his rough implementation
**\<fluffypony>** so this means we will have to have a mandatory tagged release out before the Jan hard fork
**\<moneromooo>** yay!
**\<fluffypony>** given that there are 2-3 blockers to the tagged release, and given its nature, we will likely release it alongside the GUI
**\<fluffypony>** so that we get a fair degree of pre-fork adoption
**\<ArticMine>** That makes a lot of sense
**\<fluffypony>** in the meantime
**\<fluffypony>** pigeons is setting up links to built binaries on the buildbot infrastructure
**\<fluffypony>** and I'll set forwarders up or something for those
**\<fluffypony>** so that people will be able to grab nightlies of both Monero and Monero Core
**\<fluffypony>** this is not a small amount of work, but it should make it a LOT easier for non-developers to test
**\<fluffypony>** and we need ongoing functional testing, over and above test suite regressions
**\<fluffypony>** speaking of which; the next step on that is to run and publish performance test data on a per-PR basis
**\<fluffypony>** so we can spot performance improvements / regressions
**\<fluffypony>** last thing that I want to open the floor to
**\<fluffypony>** is issue 1271
**\<fluffypony>** https://github.com/monero-project/monero/issues/1271
**\<fluffypony>** opened by paragonie-scott
**\<fluffypony>** currently we hit /dev/urandom for a random seed, basically
**\<fluffypony>** and then use the Keccak sponge function for random numbers thereafter
**\<fluffypony>** a userland PRNG is not ideal, but this doesn't really represent an attack surface that an attacker can take advantage of right now
**\<fluffypony>** to alleviate this we need to pick a crypto lib, and slowly start using it in various parts of the application
**\<fluffypony>** refactoring out the in-source implementations we currently have for most things
**\<fluffypony>** the only two really worth considering are CryptoC++ and libsodium
**\<fluffypony>** if anonimal is around, maybe he can tell us why Kovri settled on cryptocpp
**\<i2p-relay> {-olark}** What about TweetNaCl?
**\<fluffypony>** oh yes
**\<fluffypony>** so
**\<fluffypony>** TweetNaCl is great for the core crypto bits where the most important thing is getting it verifiably right
**\<fluffypony>** TweetNaCl's simplicity lends itself towards formal verification
**\<fluffypony>** a larger library like libsodium or cryptocpp will NEVER be formally verified
**\<hyc>** I'm not convinced of the original argument. userland PRNGs are not a liability
**\<hyc>** and haveged itself was recently recommended on crypto list http://www.metzdowd.com/pipermail/cryptography/2016-November/030930.html
**\<fluffypony>** hyc: I agree, but there's also nothing wrong with just hitting /dev/urandom each time
**\<i2p-relay> {-anonimal}** Since there is a heavy reliance on crypto, and most of the implementation was already written with crypto++ in mind (though it is more 'abstracted' now), any swap-out of crypto would *not* be worth the benefits gained.
**\<fluffypony>** haveged would still be of benefit there as it affects the chain from /dev/random -> /dev/urandom
**\<moneromooo>** There's a tendency for security researchers to hype every small thing too, fwiw.
**\<hyc>** hitting /dev/urandom every time leaves an obvious footprint. I suppose it's more of an issue for closed-source s/w
**\<fluffypony>** hyc: yeah - for Monero a root user would be able to trivially trap for any obfuscation we add
**\<hyc>** IME, reverse engineering closed source, it's harder to break a PRNG n a binary with no symbols and no syscalls
**\<hyc>** but yeah, not relevant for open source
**\<ArticMine>** Yes but we are not implementing DRM here
**\<i2p-relay> {-anonimal}** * was responding to fluffypony's ping for kovri, what wasn't an endorsement or argument for/against anything for monero
**\<i2p-relay> {-anonimal}** s/what/that/
**\<fluffypony>** anonimal: sure, but it's advantageous if Kovri and Monero use the same lib
**\<hyc>** less code to maintain, yeah
**\<hyc>** bigger impact if a flaw is found
**\<fluffypony>** (for functions TweetNaCl doesn't have, or where performance greater than TweetNaCl's is required)
**\<fluffypony>** sure, but we're not protecting ourselves by using libsodium vs. cryptocpp
**\<fluffypony>** unless we know in advance that one will have an implementation flawthat the other won't
**\<endogenic>** is a C++ dep an issue going into the future with talk of porting to pure C?
**\<i2p-relay> {-anonimal}** Can someone give a tl;dr of all crypto schemes required by monero (aside from ed25519, keccak, and any PRNG concern)?
**\<fluffypony>** blake256, chacha8, groestl, skein, jh, keccak
**\<hyc>** cryptonight uses keccak, groestl,
**\<hyc>** yeah what fluffy said
**\<fluffypony>** lol
**\<moneromooo>** There's all the stuff in crypto-ops.c
**\<fluffypony>** moneromooo: that's covered by TweetNaCl
**\<fluffypony>** ie. covered by SUPERCOP
**\<hyc>** I presume we're gonna support TLS on rpc connections too?
**\<moneromooo>** Do you mean that it'd be still used if we were to change to cryptocpp ?
**\<fluffypony>** hyc: kinda - vtnerd is working on it atm
**\<fluffypony>** we're going to have easy instructions on TLS wrappers, and then authentication on the RPC layer
**\<fluffypony>** moneromooo: yes
**\<moneromooo>** Why change, then ?
**\<moneromooo>** If it's only part change, I mean.
**\<fluffypony>** \<vtnerd> I wanted to mention that I would recommend _not_ adding SSL support directly to the codebase. I think using SSH tunneling or a SSL proxy like hitch would be better. I can write a guide and some basic strategies if you have someone in particular that wants the rpc stream encrypted
**\<fluffypony>** \<vtnerd> one of the advantages is not having to configure all of the keys, etc. I'm thinking about adding a warning that can only be suppressed with a CLI option or user-input if someone binds to a non-loopback IP
**\<i2p-relay> {-anonimal}** I used that argument for kovri last year, it was quickly shot down by str4d and zzz.
**\<vtnerd>** https://github.com/varnish/hitch
**\<fluffypony>** moneromooo: to get away from the in-source implementations that are mostly obscure or not massively common
**\<vtnerd>** i2p-relay: do you recall the arguments against doing it that way?
**\<i2p-relay> {-anonimal}** Expecting users to use a guide or 3rd party is probably not a good idea.
**\<i2p-relay> {-anonimal}** vtnerd: there may be a log pasted in a closed github issue
**\<hyc>** I would just use stunnel, it's already proven and pretty simple
**\<i2p-relay> {-anonimal}** Basically what I just said.
**\<moneromooo>** It's a lot easier to do the wrong thing thogh.
**\<fluffypony>** I think if we can detect and warn users that their behaviour is unsafe, but here's what they can do to fix it, that's enough
**\<moneromooo>** The same users that asked a question that I had answers with a red message when bitmonerod stopped, but they had somehow missed ? :)
**\<i2p-relay> {-anonimal}** openssl is a dependency for kovri anyway, implementing tls/ssl sockets is trivial. Are we talking more about than sockets though?
**\<vtnerd>** if SSL support is integrated public keys still have to be generated, stored, and then copied remotely ... so its still frustrating
**\<fluffypony>** moneromooo: what if it won't start when bound to an external IP, unless you pass a flag to override it?
**\<hyc>** that's life. we can write a certificate generator/mini-CA
**\<moneromooo>** Maybe. I don't know near enough about this to have a useful opinion anyway.
**\<hyc>** I already have one I wrote for OpenLDAP back in 2000 (mini-CA)
**\<vtnerd>** CA key still has to be distributed ...
**\<moneromooo>** CA key ?
**\<hyc>** CA cert, not key
**\<i2p-relay> {-anonimal}** Certs for whom?
**\<vtnerd>** its still just a public key
**\<i2p-relay> {-anonimal}** Is there an open issue for this with discussion so I catch up?
**\<pigeons>** my understanding is that one reason bitcoin is removing integrated tls support from their rpc server is to discourage people from exposing that surface to the internet when they don't have the resources to give it the same review as p2p/etc interfaces
**\<hyc>** on a personal node, you only care that your personal clients can connect. you generate your own CA, a server cert for your node, and a client cert for your wallets.
**\<pigeons>** but for monero, there is already remote daemon support so perhaps not relevant
**\<i2p-relay> {-anonimal}** Oh, personal nodes, ok thanks hyc.
**\<hyc>** and you use full cert verification in both directions, to prevent any foreign apps from connecting.
**\<fluffypony>** hmmmm
**\<vtnerd>** which can be done with SSH easily too
**\<i2p-relay> {-anonimal}** Not everyone has access to ssh nor know how to use ssh.
**\<hyc>** yeah, if you're going to keep a long running ssh tunnel alive
**\<vtnerd>** I haven't seen an easy way to "auto-configure" because the clients still need to know server pub key
**\<hyc>** node and client need a copy of the CA cert
**\<vtnerd>** I guess blindly accepting the cert is better ?
**\<fluffypony>** with TLS clients can just approve a fingerprint
**\<fluffypony>** then it's a visual comparison to a self-signed cert's fingerprint
**\<pigeons>** tofu seems acceptable to people, despite its weaknesses
**\<hyc>** ugh.
**\<pigeons>** i know
**\<hyc>** if you're going to document best practice for TLS, don't document shortcuts. that's garbage.
**\<fluffypony>** we're bikeshedding - we need to put a peg in the sand and make a decision, even if it's the wrong decision
**\<fluffypony>** I'm in favour of not building things and ripping them out later
**\<fluffypony>** but rather not having them until there is an overwhelming demand for it
**\<moneromooo>** erf
**\<hyc>** yeah, fine. no built-in TLS support for now
**\<moneromooo>** I'd be fine with that plus the --force-plaintext-bind-to-non-local-ip
**\<fluffypony>** we'll use the fail-on-start method if there are RPC bindings to non-loopback addresses, and we'll have a guide that documents hitch and stunnel
**\<vtnerd>** I already have a patch ready that forces a user to confirm if the rpc-bind-ip is not loopback
**\<fluffypony>** hyes
**\<fluffypony>** vtnerd: can we make it fail-unless-overridden-by-flag?
**\<fluffypony>** we're trying to avoid interaction on the daemon
**\<vtnerd>** the patch has both. Without the flag set it prompts the user
**\<vtnerd>** --confirm-external-bind
**\<moneromooo>** Maybe test if stdin is tty, fail if not.
**\<moneromooo>** Oh, wait, windows. Nevermind.
**\<hyc>** sounds like just fail without the flag is simpler
**\<vtnerd>** definitely. will do then
**\<vtnerd>** that is_yes patch is less useful now, but I guess it did cleanup simpler_wallet.cpp some
**\<moneromooo>** Next thing. Did shen give an idea when he might have a first pass of things that need fixing ?
**\<moneromooo>** I have time to fix, and we're pressed for time :D
**\<fluffypony>** othe: ^^
**\<fluffypony>** ok
**\<fluffypony>** we wait for othe
**\<moneromooo>** Later, then.
**\<fluffypony>** in the meantime - anyone want to bring up anything else?
**\<fluffypony>** oh - also, if anyone has any strong opinions on the crypto lib we should be using, now is a good time to mention them
**\<fluffypony>** my inclination is to cryptocpp for a few reasons
**\<fluffypony>** https://en.wikipedia.org/wiki/Comparison_of_cryptography_libraries is a good starting point if anyone wants to compare it to the others
**\<pero>** i had some discussion points wrt to the gooey if no one else has anything
**\<fluffypony>** pero: go ahead
**\<pero>** i think the navigation menu might need a 2nd level
**\<fluffypony>** medusa_ / dEBRUYNE ^^
**\<fluffypony>** slash Jaquee
**\<pero>** perhaps an advanced or something to that effect to house verify payment and sign/verify
**\<pero>** those are features that are not going to be very often
**\<pero>** especially sign/verify
**\<pero>** sign/verify needs to be renamed to 'Signatures' i think
**\<pero>** it's kind of confusing with 'verify payment'
**\<pero>** but i think if they were thrown into an Advanced top-level tab then there would be less possible confusion for most users
**\<pero>** the other thing- what's up with that qt title bar?
**\<pero>** isnt that best left for the OS to handle
**\<moneromooo>** IIRC, people slightly preferred keeping it.
**\<pero>** i dont think 'preferring' makes it the right decision
**\<hyc>** oh, as a point of curiosity - monerod runs quite happily on a phone even on 2G. using --out-peers 2.
**\<hyc>** hardly any bandwidth used.
**\<pero>** i have 2 titlebars in gnome
**\<pero>** is that the case for all OSs?
**\<iDunk>** no
**\<fluffypony>** no
**\<pero>** doesnt apple have it's buttons on the left side?
**\<moneromooo>** I have two too. But then I have a special setup.
**\<fluffypony>** then it's a bug
**\<fluffypony>** moneromooo: you *are* special
**\<fluffypony>** :-P
**\<fluffypony>** 2 minutes and then I bring up meeting bot, so let's wrap this up
**\<Jaquee>** i agree on using the os default
**\* fluffypony** hates the OS default
**\<pero>** we're also going against OS-specific consistent user experience
**\<moneromooo>** ... wat...
**\<Jaquee>** and that we need to work on the ux.
**\<pero>** against their design standards
**\<Jaquee>** yes
**\<i2p-relay> {-olark}** re: crypto libraries, imo, use TweetNaCl for what you can. Cryptopp for everything else.
**\<hyc>** agree with pero - app should leave widgets to user's window manager
**\<fluffypony>** olark: agreed
**\<hyc>** title bar included
**\<fluffypony>** we don't want it looking like it's from 1995 tho :-P
**\<hyc>** we don't want it looking different from everything else on their desktop
**\<fluffypony>** I'd prefer that the Monero Core app is consistent across platforms
**\<hyc>** it was a pretty jarring experience for me running it on windows
**\<pero>** well it's just a titlebar
**\<fluffypony>** ok let's discuss it later, meeting bot coming online
**\<Jaquee>** ok
**\<pero>** it's not going to consistent - some platforms might have it maximized
**\<pero>** like on mobile