Dev meeting and Kovri meeting logs for meetings held on 2016-10-16 & 2016-10-30

parent 1bbe9468
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-10-16
summary: Brief review of what has been completed since last meeting, Kovri API discussion, Kovri Logo, and code & open tickets discussion
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*October 16th, 2016*
# Logs
**\<i2p-relay> {-anonimal}** 17:00!
**\<moneromooo>** Go go go!
**\<ArticMine>** Let's start
**\<i2p-relay> {-anonimal}** I can't copy/paste as quickly as usual so here's in bits:
**\<i2p-relay> {-anonimal}** 1. Greetings
**\<i2p-relay> {-anonimal}** 2. Brief review of what's been completed since the previous meeting
**\<i2p-relay> {-anonimal}** 3. libclient API discussion (#351)
**\<i2p-relay> {-anonimal}** 4. logo
**\<i2p-relay> {-anonimal}** 5. Code + ticket discussion / Q & A
**\<i2p-relay> {-anonimal}** 6. Any additional meeting items
**\<i2p-relay> {-anonimal}** 7. Confirm next meeting date/time
**\<i2p-relay> {-EinMByte}** Hi
**\<i2p-relay> {-anonimal}** Hello
**\<i2p-relay> {-anonimal}** 2. Brief review of what's been completed since the previous meeting
**\<i2p-relay> {-anonimal}** Very little on the codebase work this period because I've been busy with getting the full-time prop ready/funded and working on the documentation prop:
**\<i2p-relay> {-anonimal}** - Tons of work on #256 (see my monero-site fork for details)
**\<i2p-relay> {-anonimal}** - Minor AES-NI impl fixes/refactor
**\<i2p-relay> {-anonimal}** - Client fix to allow saving privates when behind a transproxy
**\<i2p-relay> {-anonimal}** - Bump dependency versions in submodules
**\<i2p-relay> {-anonimal}** (the issue is probably *when client doesn't have everything it wants when router expects inbound peers*)
**\<i2p-relay> {-anonimal}** - REMOVED TRAVIS-CI! YAY! We now have all-platform build support thanks to pigeons
**\<i2p-relay> {-anonimal}** - Minor things and some doc fixes
**\<i2p-relay> {-anonimal}** - New contributor dadude (welcome, dadude)
**\<i2p-relay> {-anonimal}** One more note:
**\<i2p-relay> {-anonimal}** My full-time funding proposal was fully funded in a record ~2-3 days https://forum.getmonero.org/9/work-in-progress/86967/anonimal-s-kovri-full-time-development-funding-thread
**\<i2p-relay> {-anonimal}** Absolutely unbelievable and I'm so thankful and proud to be a part of this community. The latest reddit thread I think is here https://www.reddit.com/r/Monero/comments/579t3a/kovri_dev_funded_congrats_everyone/
**\<i2p-relay> {-anonimal}** Huge note: this doesn't mean we don't need more contributors, so please let's continue to get the word out there about kovri and get more people on board so we can grow stronger.
**\<i2p-relay> {-anonimal}** Anything else on 2.?
**\<_Slack>** Action: anonimal sees dadude typing
**\<_Slack> {dadude}** thank you. And congrats on that anonimal! that's actually pretty amazing.
**\<imans>** reading...
**\<i2p-relay> {-anonimal}** Thanks dadude, its really the community to thank; such a great crowd.
**\<i2p-relay> {-EinMByte}** Good to see you're funded now, anonimal
**\<_Slack> {dadude}** yep! and 'by word out there about kovri' you mean in monero community or just more people in general?
**\<i2p-relay> {-EinMByte}** That gives me a good excuse to do little development :)
**\<i2p-relay> {-anonimal}** s/saving privates/saving private keys/ \<-- lol, oops
**\<i2p-relay> {-anonimal}** Thanks EinMByte. If an FFS would help you put more time in, I'll be the first to donate (or will try to be unless someone else beats me to it).
**\<i2p-relay> {-anonimal}** dadude: all humans on the planet if possible (preferably with internet availability)
**\<_Slack> {dadude}** got it :slightly_smiling_face:
**\<i2p-relay> {-anonimal}** Anything else on 2. or dare we dive into API chat?
**\<sdgsdug9sd>** whats the expected date for release of i2p?
**\<i2p-relay> {-anonimal}** sdgsdug9sd: checkout our roadmap
**\<sdgsdug9sd>** link?
**\<i2p-relay> {-anonimal}** github.com/monero-project/kovri/wiki \<--something like that, whatever wiki url is
**\<i2p-relay> {-anonimal}** We set a date of nov. 1st for first pre-alpha release. I'd rather push the date to the 0.1.1 release and move 0.1.1 to next year.
**\<_Slack> {dadude}** https://github.com/monero-project/kovri/wiki/Roadmap
**\<ArticMine>** https://github.com/monero-project/kovri/wiki/Roadmap
**\<i2p-relay> {-anonimal}** (like I said, barely any codebase work in 2 weeks)
**\<i2p-relay> {-anonimal}** Ok, let's move to 3. and we can add other items/open questions to 6.
**\<i2p-relay> {-anonimal}** 3. libclient API discussion (#351)
**\<i2p-relay> {-anonimal}** moneromooo: did you get a chance to research my question(s)?
**\* moneromooo** suddenly appears very busy with somehting else
**\<moneromooo>** ... no. Sorry...
**\<moneromooo>** Many bugs...
**\<sdgsdug9sd>** lol is this real? i hardly believe those target dates
**\<imans>** seems codebase is very weak at this time. Needs of lot of testing I think
**\<i2p-relay> {-anonimal}** Guys, we're on API discussion now, we'll chat more later in the meeting.
**\<imans>** okay
**\<i2p-relay> {-anonimal}** moneromooo: I'll try to rephrase then
**\<moneromooo>** There is talk of switching the P2P API to zmtp too (I know nothing about it).
**\<moneromooo>** Should still be mostly streaming thoug.h
**\<i2p-relay> {-anonimal}** moneromooo: I'm betting most of my questions can be answered with more research on my end
**\<moneromooo>** OK, I think maybe ask questions here, and I will try to answer with what I can.
**\<i2p-relay> {-anonimal}** moneromooo: where can I get a good tl;dr of how monero handles timeouts?
**\<moneromooo>** From what I can tell, it uses boost's asio system for this.
**\<moneromooo>** Then you get a callback with a "cancelled" state IIRC.
**\<i2p-relay> {-anonimal}** by 'handle' I mean internally (if something needs to get to blockchain but doesn't quickly enough)
**\<moneromooo>** (from boost)
**\<i2p-relay> {-anonimal}** That's too obvious moneromooo :) I mean purely internally
**\<moneromooo>** to blockchain ? I'm talking avbout the P2P comms here.
**\<moneromooo>** Hmm, well, I don't know more about timeouts, sorry.
**\<i2p-relay> {-anonimal}** I'll try to rephrase again, if a node's internet connection is unreliabe, is behaviour undefined?
**\<imans>** it will not get a proper sync simple
**\<moneromooo>** Hopefully not. Connections to a peer are dropped if "weird" stuff is received, but to what extent this is pervasive, I'm not sure.
**\<moneromooo>** There's a query/reply system, with a handful of possible messages IIRC.
**\* pero** will brb 5min - knows he's next up on agenda
**\<moneromooo>** This seems rather high level though.
**\<i2p-relay> {-anonimal}** \* is thinking ahead, wants to know how a node will deal with dropped tunnels on a noticeable scale
**\<i2p-relay> {-EinMByte}** anonimal: backup tunnels like java i2p could work
**\<moneromooo>** Well, it should be resistant to that. If it's not, we'll have to make it.
**\<moneromooo>** I2P can keep a tunnel for a few minutes reliably enough, right ?
**\<i2p-relay> {-anonimal}** EinMByte: good point.
**\<i2p-relay> {-EinMByte}** But AFAIK, we still aren't sure that monero actually needs connections?
**\<i2p-relay> {-anonimal}** moneromooo: technically, any tunnel and blow at any moment IIRC
**\<i2p-relay> {-anonimal}** s/and/can/
**\<moneromooo>** At any moment is fine, but monero would need to be at least one of high enough duration to reveive a chunk of blokcs when syncing.
**\<i2p-relay> {-anonimal}** If Joe shuts off his router unexpectedly, we have to wait to build a new tunnel from the pool (IIRC)
**\<i2p-relay> {-anonimal}** How big are those chunks usually?
**\<moneromooo>** Again, this is fine. As long as we can get a minute of comms at one point.
**\<moneromooo>** Currently, 200 times the size of a block, which is... hmm... from 250 bytes to 60 kB.
**\<moneromooo>** That 200 can be changed when running with kovri if needed.
**\<i2p-relay> {-anonimal}** moneromooo: ok, scenario question: what if we *can* get a reliable connection but syncing has to wait for it but will be notified "try again in X minutes". Will that break monero?
**\<i2p-relay> {-EinMByte}** with streaming it doesn't really matter
**\<i2p-relay> {-EinMByte}** datagrams are limited in size, though
**\<ArticMine>** but does this set a limit on the blocksize in Monero?
**\<moneromooo>** I think that, for now, that connection will be dropped, and another attempted. But that doesn't seem too hard to change.
**\<moneromooo>** ArticMine: no, the 200 is the number of blocks. Though if one block is 100 MB in the future... I guess it needs to be downloaded without interruption.
**\<i2p-relay> {-EinMByte}** dropping and re-attempting sounds like a good strategy
**\<moneromooo>** The re-attempt would be to another random peer.
**\<i2p-relay> {-anonimal}** \* eek
**\<moneromooo>** (currently anyway)
**\<i2p-relay> {-anonimal}** Ok, well what I'm poking at I think is for more in the future (and based on passing thoughts this week).
**\<i2p-relay> {-anonimal}** \* was not prepared for API chat this week because of point 2.
**\<i2p-relay> {-anonimal}** EinMByte: any other questions/thoughts?
**\<i2p-relay> {-anonimal}** ^ moneromooo
**\<moneromooo>** Not from me.
**\<i2p-relay> {-EinMByte}** Just that I don't think disconnections would be that much of an issue
**\<i2p-relay> {-anonimal}** I have been envisioning more of the API on our end though, but purely in my head.
**\<i2p-relay> {-EinMByte}** but let's move on
**\<ArticMine>** I have to leave now.
**\<i2p-relay> {-anonimal}** * one more thing
**\<i2p-relay> {-anonimal}** Actually, nevermind because I don't want to put dadude on the spot and it's probably unrelated
**\<_Slack> {dadude>}** well if I left the node on and the connection is bad, I wouldn't want it to stop, as bad as mightbe. I'll probably be thinking that its syncing. So what about an timed retry till the network gets back on? If it is very bad, then you can set up an option like --retry x-times
**\<i2p-relay> {-anonimal}** dadude if you have API questions as related to torrenting, now's the chance
**\<_Slack> {dadude>}** Oh, I
**\<i2p-relay> {-anonimal}** (no rush, there are plenty more meetings to be had)
**\<_Slack> {dadude>}** I'll read up on how vuze does it and get back to you guys if I have any questions
**\<i2p-relay> {-anonimal}** dadude: good point, I'm sure the API will cover that
**\<i2p-relay> {-anonimal}** dadude: we can explain how vuze does it after the meeting if you'd like
**\<moneromooo>** A torrent based syncing process was suggested before. It'd be quite a departure from what we have now, but would be a good thing I guess.
**\<i2p-relay> {-anonimal}** Ok, nothing else on 3.?
**\<_Slack> {dadude>}** thanks. unrelated: How does relay handle edits to a post here on slack
**\<i2p-relay> {-anonimal}** dadude: let's save that until later in the meeting
**\<moneromooo>** (for initial sync anyway)
**\<_Slack> {dadude>}** Oh I wasn't talking about to sync the blockchain, I was talking about torrenting inside the i2p netowkr
**\<i2p-relay> {-anonimal}** moneromooo: is there a post or link re: that proposal?
**\<moneromooo>** It was mentioned in one of the MRL papers IIRC. No details, but I can find you the one.
**\<i2p-relay> {-anonimal}** Thank you moneromooo.
**\<i2p-relay> {-anonimal}** * would navigate but you know MRL better than I
**\<i2p-relay> {-anonimal}** Ok, moving on
**\<i2p-relay> {-anonimal}** 4. logo
**\<i2p-relay> {-anonimal}** pero: all you if you're here!
**\<pero>** yes hi
**\<pero>** ok so we're down to 2 fonts
**\<i2p-relay> {-anonimal}** Let's decide now then
**\<pero>** each came with 6-8 weights and i've cut that down to 2 for exo2 and 3 for lato
**\<pero>** https://a.pomf.cat/gyzaxi.png
**\<pero>** 1b and 1c are the same weight with different kerning
**\<pero>** the 'garlic-integrated' variants are interesting but will require rework of the garlic
**\<pero>** for record keeping purposes this is v8
**\<i2p-relay> {-anonimal}** Ok, we're throwing out the garlic as 'o' idea because: 1. doesn't look like garlic 2. doesn't look like an 'o' 3. not intended for that purpose
**\<i2p-relay> {-anonimal}** Any objections?
**\<moneromooo>** My subjective opinion is that the "garlic as dot in the i" is too small to not feel weird.
**\<i2p-relay> {-anonimal}** \* agreeing with moneromooo, it looks like a flame
**\<pero>** yes i agree - is viable but needs rework
**\<imans>** instead put garlic for o kovri
**\<moneromooo>** I thought the flame thing was intended :P
**\<i2p-relay> {-anonimal}** imans: see my comment above
**\<_Slack> {dadude}** just a small question. wait, so are we 1. pushing kovri as a 'project' on its own (apart from geti2p.net) or 2. just an alternative router to the java i2p one. Because if it is 2, shouldn't it way only 'garlic router'? and not add the project?
**\<imans>** okay
**\<i2p-relay> {-anonimal}** dadude: 1.
**\<pero>** imans - the problem with that is that the garlic wasn't intended for such usage
**\<pero>** and makes the text imbalanced
**\<i2p-relay> {-anonimal}** Alright, everyone pick their favorite font now please (we need to decide on logo today, final decision this week - not waiting until next meeting)
**\<imans>** fine. pero
**\<pero>** e.g., the space between the upper portion of the K and the black part of the garlic is smaller than the whitespace on the right side
**\<pero>** and the small lines at the bottom and top of garlic aren't optimal
**\<imans>** I see it there
**\<imans>** My choice is the 6th one
**\<imans>** for font
**\<moneromooo>** I'd pick one of the ones on the right, just because they're fatter, and so easier to read.
**\<imans>** and bold
**\<i2p-relay> {-EinMByte}** I'd go for lato
**\<i2p-relay> {-EinMByte}** (b1?)
**\<pero>** yea i'm in the lato camp as well
**\<i2p-relay> {-anonimal}** pero: I like lato, X coord 1, Y coord b
**\<imans>** seems everyone picks up the second
**\<i2p-relay> {-anonimal}** Ok, 3 votes for b1, 1 vore for 'the 6th one' (I have no idea what that is)
**\<_Slack> {dadude}** yep b1
**\<pero>** i'm either b2 or b3
**\<pero>** 6th one was b3
**\<i2p-relay> {-anonimal}** Alright, 4 votes b1, 2 for b3, 1 for b2
**\<moneromooo>** If I had to choose one, I'd say bottom right, but there's really not much difference and I might pick another one tomorrow :)
**\<i2p-relay> {-anonimal}** b1 one is the winner, any objections?
**\<i2p-relay> {-anonimal}** lol
**\<pero>** well that's for b3 now ;p
**\<pero>** 3
**\<moneromooo>** Ignore me :)
**\<i2p-relay> {-anonimal}** \* looks different depending on mood
**\<i2p-relay> {-EinMByte}** 3/3, let's toss a coin
**\<i2p-relay> {-anonimal}** pero: also, let's try steching that subtext all the way to the left
**\<i2p-relay> {-anonimal}** to the end of the garlic
**\<i2p-relay> {-anonimal}** Does that effect your decision?
**\<pero>** yea that variant was included before - it was just a time saving consideration to not include it
**\<i2p-relay> {-anonimal}** \* wonders how to coin toss over IRC
**\<moneromooo>** There were some with that system on one of the previous images. It looked odd. Maybe instead scale the garlic up to go tho the bottonm of the subtext.
**\<pero>** as a rule of thumb you want heavier type for the logo
**\<pero>** moneromooo that looked even weirder :)
**\<moneromooo>** So there's no hole, but it doesn't also feel like the subtext is running away from the main text.
**\<i2p-relay> {-anonimal}** b2 b3 looks overpowering compared to that logo IMHO
**\<moneromooo>** Hmm, ok.
**\<i2p-relay> {-anonimal}** We have 7 minutes to decide, I'd like to save room for other topics.
**\<i2p-relay> {-anonimal}** 6 minutes now
**\<imans>** I stick with the last one on the right
**\<pero>** i think you should be focusing on the largest variant
**\<pero>** and the variant with only the garlic on the left
**\<pero>** when deciding
**\<endogenic>** lol you valuable guys/gals are spending too much time on it imo and may end up getting sucked down a depth first search rather than seeing the whole picture. this is just my humble opinion but it's better to find a designer to own it (and prevent design by committee)
**\<pero>** don't worry about the others
**\<endogenic>** but i might regret having opened my mouth :P
**\<pero>** endogenic - this is how the 'design process' works
**\<i2p-relay> {-anonimal}** pero: 5 minutes, why?
**\<moneromooo>** They all look so similar anyway.
**\<pero>** this is 'client feedback'
**\<i2p-relay> {-anonimal}** I like the balance of b1
**\<pero>** you don't just present a finished logo to a client and say 'here, take this'
**\<i2p-relay> {-anonimal}** b2 b3 are too strong
**\<imans>** okay
**\<i2p-relay> {-EinMByte}** I though we were going to toin coss
**\<endogenic>** http://www.logodesignlove.com/next-logo-paul-rand
**\<i2p-relay> {-EinMByte}** \*thought
**\<moneromooo>** I vote for toin coss.
**\<i2p-relay> {-anonimal}** Who has the coin?
**\<endogenic>** but i'm not disagreeing that market research is important
**\<endogenic>** talking to users is basically #1 next to building
**\<i2p-relay> {-anonimal}** And is that coin CSPRNG, lol
**\<i2p-relay> {-EinMByte}** Let's do this right and use a bit commitment scheme
**\<i2p-relay> {-anonimal}** 3 minutes
**\<i2p-relay> {-EinMByte}** (unfortunately we don't have secure timestamping available for the commitment scheme)
**\<pero>** yea ok pay someone 100k and after 6 months they'll narrow it down to 1 almost scientifically
**\<i2p-relay> {-anonimal}** 2 minutes
**\<moneromooo>** OK, so, if the number of letters in "anonimal" is even, b1, if it's odd then b3. OK ?
**\<pero>** i'm in the not b1 camp
**\<i2p-relay> {-anonimal}** \* bribes moneromooo behind closed doors
**\<pero>** mostly because it looks close to just regular text
**\<i2p-relay> {-anonimal}** I think b2 b3 are ugly, I don't want to see this everytime I look at the readme
**\<i2p-relay> {-anonimal}** \* don't forget the devs
**\<moneromooo>** A graphical README ?
**\<i2p-relay> {-anonimal}** 1 minute to flip coin
**\<pero>** just bigger and with tighter kerning
**\<i2p-relay> {-anonimal}** \* will pull executive order if someone can't flip a coin
**\<i2p-relay> {-iDunk}** we can pick anything as long as it's b1 :)
**\<moneromooo>** SOLD!
**\<i2p-relay> {-anonimal}** pero: will b2 look better when subtext is streched across to the left
**\<i2p-relay> {-anonimal}** \* trusted pero so far, no reason to stop trusting
**\<i2p-relay> {-iDunk}** btw, i'm also for b3
**\<pero>** well i'd show you but i'm in wayland atm with no screenshot support
**\<i2p-relay> {-anonimal}** I'd like EinMByte to be the tie-breaker if he's up for it
**\<i2p-relay> {-EinMByte}** With iDunk's vote, let's say the choice is b3
**\<pero>** but no it doesn't look any better than it does now
**\<i2p-relay> {-anonimal}** b3 it is!
**\<i2p-relay> {-anonimal}** Congrats to b3
**\<i2p-relay> {-iDunk}** \* hides from anonimal
**\<i2p-relay> {-anonimal}** \* says eww but oh well
**\<i2p-relay> {-anonimal}** lol iDunk
**\<moneromooo>** eww well
**\<i2p-relay> {-anonimal}** \* looking forward to a kovri PR from iDunk some day
**\<i2p-relay> {-iDunk}** :D
**\<i2p-relay> {-anonimal}** Moving on,
**\<imans>** congrats
**\<i2p-relay> {-anonimal}** 5. Code + ticket discussion / Q & A
**\<imans>** ask
**\<i2p-relay> {-anonimal}** 8 minutes left, I want to actually move to 6.
**\<i2p-relay> {-anonimal}** Any objections?
**\<imans>** no
**\<i2p-relay> {-EinMByte}** No objections
**\<i2p-relay> {-anonimal}** 6. Any additional meeting items
**\<i2p-relay> {-anonimal}** {-imans} seems codebase is very weak at this time. Needs of lot of testing I think
**\<i2p-relay> {-anonimal}** imans: have you spent time with this codebase?
**\<imans>** Just trying to install
**\<imans>** My ubuntu is hanging. I have to try another time.
**\<i2p-relay> {-EinMByte}** \* afk
**\<i2p-relay> {-anonimal}** Ok, so you haven't then.
**\<i2p-relay> {-anonimal}** {-sdgsdug9sd} lol is this real? i hardly believe those target dates
**\<imans>** yes
**\<i2p-relay> {-iDunk}** i installed it yesterday and it seemed to run just fine until a few hours ago
**\<moneromooo>** That's for "kovri runs and does things", not "monero uses kovri", fwiw.
**\<i2p-relay> {-anonimal}** sdgsdug9sd: then you probably wouldn't believe that what we forked from actually had a release and you should be thankful we've not repeated that same mistake
**\<moneromooo>** What was the mistake ?
**\<i2p-relay> {-anonimal}** sdgsdug9sd: also, see pre-alpha https://en.wikipedia.org/wiki/Pre-alpha
**\<i2p-relay> {-anonimal}** moneromooo: calling that router a year ago "releaseable"
**\<moneromooo>** Ah...
**\<i2p-relay> {-iDunk}** i got disconnected from irc, couldn't connect any more, tried to exit from kovri but had to kill it
**\<i2p-relay> {-iDunk}** restarted and it runs fine again
**\<i2p-relay> {-anonimal}** 2 minutes. Any questions/comments/new items?
**\<i2p-relay> {-anonimal}** imans sdgsdug9sd: ^
**\<imans>** I will ask more in next meeting. I need to brainstorm myself
**\<moneromooo>** anonimal: https://lab.getmonero.org/pubs/MRL-0004.pdf -- the torrent suggestion was not about initial sync actually, but about sending new txes.
**\<moneromooo>** (I had misremembered)
**\<i2p-relay> {-anonimal}** I'm available for tech support after the meeting
**\<i2p-relay> {-anonimal}** 2 weeks, same time?
**\<i2p-relay> {-anonimal}** moneromooo: ah, ok, thanks I'll give it a read
**\<i2p-relay> {-anonimal}** imans: if you need help just ask in #kovri or #kovri-dev after the meeting
**\<i2p-relay> {-anonimal}** 7. Confirm next meeting date/time
**\<i2p-relay> {-anonimal}** \* moving on
**\<i2p-relay> {-anonimal}** No objections? 2 weeks same time then.
**\<imans>** Okay anonimal. I'm in another stuff I will get in technical touch tomorrow
**\<i2p-relay> {-iDunk}** yep
**\<imans>** so, the date and time is?
**\<i2p-relay> {-anonimal}** Thank you everybody. Thank you dEBRUYNE for logging these meetings :)
\ No newline at end of file
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-10-16
summary: Review and discussion of Open PRs, contribution guidelines, and official GUI
tags: [dev diaries, core, crypto, 0mq]
author: dEBRUYNE / fluffypony
---
*October 16th, 2016*
# Overview
An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-dev-meeting-note-highlights-2016-10-16).
# Logs
**\<moneromooo>** So, fluffypony asked if I could talk. I have no relay bot, so #kovri-dev will have to be here to listen.
**\<moneromooo>** He suggested I talk about guidelines for submitting patches. So we'll see if everyone mostly agrees.
**\<+hyc>** cool
**\<moneromooo>** I would like to encourage people to make clean changes, which mean:
**\<moneromooo>** - try to keep patches self contained where appropriate
**\<moneromooo>** - no random whitespace changes interspersed with other changes
**\<moneromooo>** - sensible commit message (ie, no "update wallet.cpp")
**\<moneromooo>** - properly rebased patches (ie, if you authored three patches in a PR, don't send 20 patches from someone else at the same time, so "git rebase master" first)
**\<+hyc>** that all makes sense
**\<moneromooo>** If you make a buggy patch and then fix it in a second patch, squash those (see git rebase -i, but that starts being a bit complex)
**\<moneromooo>** Does anyone disagree ?
**\<_Slack> \<nanoakron>** Nope
**\<Jaquee_>** nope
**\<tompole>** nope
**\<+hyc>** no disagreement here. that's standard stuff.
**\<_Slack> \<nanoakron>** Can I ask a little more about what you mean by ‘self contained'
**\<moneromooo>** (We'll make an exception for tewinget who's got a massive non rebased patchset for 0mq though)
**\<+hyc>** sure, patches of such large scope are going to have their exceptions
**\<moneromooo>** I mean, if you've got two changes, make them two patches. I like small patches, one per "logical change".
**\<_Slack> \<nanoakron>** Makes sense. Single-issue patches.
**\<moneromooo>** It's easier to review, to debug, to revert it necessary.
**\<+hyc>** but usually PRs should be one issue per patch, one patch per issue
**\<moneromooo>** Yes. However, when in the middle of a large thing, you sometimes see something that needs fixing and would otherwise conflict. That can go (as a separate patch) in that PR, depends on the circumstances.
**\<moneromooo>** especially for those PRs that can take weeks to be merged.
**\<+hyc>** sure
**\<_Slack> \<nanoakron>** OK
**\<moneromooo>** But yes, 1/1 in general.
**\<moneromooo>** So, nobody seems to disagree, I'll write a little thingie about this for the repo. Thanks.
**\<moneromooo>** So, I guess... anyone has anything to say about progress, or other dev related stuff ? :)
**\<Fireice>** I've got a question to the devs - do you think Monero is mature enough for applications improving usability? I'm an independent software dev, and I'm thinking of committing about 6 months of full-time work on Monero. First application that I'm thinking of is a lightweight Windows GUI wallet for Monero.
**\<moneromooo>** Another one, yay! :)
**\<moneromooo>** First, read up on what lightweight may involve for monero.
**\<_Slack> \<nanoakron>** Do we have a common wiki or other info page for devs to describe things like prefixes e.g. m_ and others
**\<TedTheFicus>** Yes, this is needed
**\<_Slack> \<nanoakron>** stuff
**\<moneromooo>** And mature enough is pretty subjective. It can be used, for sure.
**\<Fireice>** lol, bazaar project usually have a lot of traffic
**\<moneromooo>** There is none. Some people use m_ for class data members.
**\<hiall>** hi all
**\<_Slack> \<nanoakron>** What would you think about standardising that aspect of development? Variable/class/etc. nomenclature?
**\<moneromooo>** Fireice: also, ask athan (or ethan), he's got a wallte in development which you might want to have a look at.
**\<hiall>** when is meeting starting?
**\<dEBRUYNE>** it already started
**\<+hyc>** nanoakron: that sounds like a lot of busywork
**\<hiall>** where is it?
**\<moneromooo>** Well, my opinion on that is to follow the existing, but I'm not super bothered about it. I certaonly don't subscribe to the minutiae crap. But I know many disagree :)
**\<Fireice>** ok will do, how do i get hold of him?
**\<_Slack> \<nanoakron>** Fireice: Take a look at how the existing GUI wallet is coming along at https://github.com/monero-project/monero-core - maybe integration into an existing service such as open bazaar would be cool
**\<moneromooo>** Fireice: he's around on IRC pretty often.
**\<_Slack> \<nanoakron>** hyc: I know :( But standards can be good too
**\<moneromooo>** integration would need th plugin system first. That is yet to be design.
**\<moneromooo>** designed.
**\<dEBRUYNE>** Fireice: His contact details are on Github too: https://github.com/athanclark
**\<imans>** There is no instruction for windows compilation in the github
**\<endogenic>** I tend to agree with nanoakron in the sense that changes to the API, especially w/o corresponding documentation updates, makes integration pretty darn tough and not necessarily viable for third parties
**\<moneromooo>** Well, that's true. It's not API stable, that's certain.
**\<dEBRUYNE>** imans: https://monero.stackexchange.com/questions/2346/compiling-gui-from-source-differences-by-os
**\<+hyc>** not at the binary level, and not even at the RPC level
**\<moneromooo>** The RPC is *mostly* backward compatible though.
**\<endogenic>** Fireice: that may be your answer then :)
**\<imans>** ty dEBRUYNE
**\<_Slack> \<nanoakron>** @hyc or @moneromooo on a similar note, is there a list of all available functions? E.g. call tools::simplewallet::is_it_true() to clean true/false user inputs
**\<+hyc>** I think it's OK to establish guidelines now for future development
**\<Fireice>** ty for your help, do you know if the qt wallet targets win and linux systems or just linux?
**\<+hyc>** but it's too early to make hard rules
**\<hiall>** is this the meeting?
**\<pero>** conference, dev conference
**\<moneromooo>** A list of all available functions, beyond the source ?
**\<jaquee>** Fireice: the official targets linux, osx and windows
**\<dEBRUYNE>** Fireice: The official GUI will be available for Linux, os x, and windows
**\<moneromooo>** That sounds like it'd go stale pretty fast.
**\<moneromooo>** But no, there is none.
**\<endogenic>** perhaps the API documentation stuff should wait until the 0mq changes have been made?
**\<+hyc>** at least that, yes
**\<+hyc>** (endogenic)
**\<_Slack> \<nanoakron>** @moneromooo yes. I don’t think you’re going to find key functions going stale that fast, so long as you require people who update or add functions to make corresponding changes to the documentation before their PR gets accepted.
**\<moneromooo>** I think tewinget is doing doc as he codes.
**\<imans>** IMO third party integrations must be made simple and easy to plug with any kind of party or platform
**\<moneromooo>** I'm not sure holding PRs for documentation is best, but I'm a bit on the fence tbh.
**\<moneromooo>** What do people think ?
**\<+hyc>** sounds like a Would Be Nice when there is a larger developer base
**\<+hyc>** and the dev base is certainly growing now
**\<_Slack> \<nanoakron>** Documentation is boring bullshit but necessary to make it easier for new devs to get involved. We don’t want to get into a situation like a certain other coin where only an inner cabal actually knows the code without deep reading
**\<TedTheFicus>** If documentation is going to make it easier to attract API + other users than I think we need it up to date always
**\<endogenic>** moneromooo: documentation should be done by particularly able people IMHO
**\<gingeropolous>** so, not accepting a pull request because of poor documentation?
**\<xmrcoma>** tewinget practice of documenting while coding is a best practice
**\<endogenic>** and it can degrade in quality if an owner or class of developer is not designated
**\<imans>** I do agree with that. good documentation can seemlessly help new devs get involved easily
**\<_Slack> \<nanoakron>** @gingeropoulos I mean something like ‘I’ve written this new function to calculate X but haven’t given any documentation’ and then 2 months later someone new comes along, never realised that function existed because there was no documentation, and then just trying to rewrite their own version.
**\<moneromooo>** But how would you find it in the doc, if you don't find it in the source ?
**\<_Slack> \<nanoakron>** What we need is a common documentation site and to pay someone to do about a week’s work to pore over the code and fully document every function
**\<+hyc>** exactly
**\<+hyc>** new devs must search, regardless.
**\<moneromooo>** (not saying it's a bad idea here, mind)
**\<gingeropolous>** nanoakron, i think thats what tewinget was up to at one point :)
**\<+hyc>** on the other hand, I like tools like doxygen, document as you code is always a good approach
**\<_Slack> \<nanoakron>** Would be easier to search a wiki for ‘check hard fork version’ and get a bunch of matching functions from which you can pick
**\<moneromooo>** I do: git grep check.*hard.*fork :)
**\<moneromooo>** But ok, fair enough.
**\<moneromooo>** I think encouraging doc is good, ust not sure it should be enforced, at least for now.
**\<_Slack> \<nanoakron>** But again, it’s a bit chicken and egg - good documentation begets good documentation. It’s getting over that original hurdle to actually make it happen
**\<gingeropolous>** yeah I think its a "Would Be Nice" thing, and during a PR review, it would be noted - like "hey, you should totally comment this up"
**\<gingeropolous>** and then if the dev doesn't comment it up, then its a judgement call over how important the feature is
**\<_Slack> \<nanoakron>** I agree moneromooo, we can’t enforce without a good standard or common place to record the documentation
**\<endogenic>** nanoakron: +1
**\<+hyc>** I'm cool with mandating Doxygen comments, moving forward.
**\<moneromooo>** I agree than modifying a function with a doxygen doc thing should also change to doc thing to match. That's a NAK offense :)
**\<endogenic>** another thing to consider is that git commit messages are a kind of documentation. maybe we need to codify the standards in a public official place
**\<moneromooo>** So I'll add language to encourage documenting stuff.
**\<_Slack> \<nanoakron>** Starting off a forum funding goal for someone to pull together all the function, variable and class lists would be worthwhile
**\<+hyc>** nanoakron: I disagree.
**\<_Slack> \<nanoakron>** Could you also add language telling us how to do the documentation - I’ve never used doxygen
**\<+hyc>** lots of effort to maintain a moving target.
**\<moneromooo>** I just copy/paste an existing one and adapt.
**\<TedTheFicus>** Yes, I'd contribute funding to that
**\<+hyc>** but that's the sort of thing doxygen already takes care of
**\<moneromooo>** And I agree with hyc here. An inventory now would be wasted, mostly.
**\<+hyc>** so if we start using it now, then over time it will build itself
**\<_Slack> \<nanoakron>** The target won’t move though. Let me choose a random example. Do you really think cryptonote_core::blockchain::pop_block_from_blockchain is going to be deprecated any time soon?
**\<_Slack> \<nanoakron>** Someone had to write the domesday book...
**\<imans>** But, this is going to be a big sub project if you document everything. You need lot of time and effort
**\<moneromooo>** Unlikely. I would look suspiciously at a patch using it though :P
**\<_Slack> \<nanoakron>** In which case the person patching could just fix up the doc at the same time :slightly_smiling_face:
**\<+hyc>** indeed, most of the existing functions only have legitimate use internally, not by 3rd parties
**\<imans>** If you add use cases it would be very much helpful
**\<moneromooo>** But hey, if you want to do that, feel free. Maybe it will turn out to be a great idea in retrospect.
**\<endogenic>** what are the problems for which we need to provide documentation at this moment? if we categorize the instances of those problems we might find that it can work quite well to have task- or case-based documentation as a distinct project from going through the source and applying doxygen comments to everything for a whole-API reference
**\<_Slack> \<nanoakron>** Do we have anywhere common where I can read about doxygen or using doxygen wrt monero now?
**\<moneromooo>** Well, applying doxygen comments is, by itself, pointless (even worse, as it makes it harder to read the API). Semantics in the doxygen comments are what's good, and that needs understanding of the code.
**\<imans>** An errata list is good which will help people to trace out the errors they meet
**\<+hyc>** what errata list? the github issues list?
**\<imans>** Also, a stackexchange like documentation system which will enable users to post their comments and also raise issues they face.
**\<imans>** Yes, hyc similar to that
**\<moneromooo>** endogenic: I think nanoakron originally wanted a map from "I want to do that" to "use this". I think.
**\<_Slack> \<nanoakron>** @moneromooo yes
**\<_Slack> \<nanoakron>** @imans Not entirely sure how that would be different from the existing github
**\<imans>** It will not be different. But it aids new comers and users to interact more closely
**\<_Slack> \<nanoakron>** @imans ...
**\<endogenic>** imans: thought we already have a SE?
**\<imans>** I mean it for API + third party integrations
**\<endogenic>** why not just create a new category?
**\<+hyc>** yes, at a certain point, new devs are just going to have to learn to use the tools that already exist
**\<imans>** yes, the same I say
**\<+hyc>** otherwise we spin our wheels adding infrastructure instead of functionality
**\<_Slack> \<nanoakron>** @hyc That’s absolutely fine…so long as those tools themselves are well documented :slightly_smiling_face:
**\<gingeropolous>** well the github wiki was requested for (i think) something related to this purpose, and it hasn't received any attention
**\<_Slack> \<nanoakron>** afk 10 mins
**\<moneromooo>** That sounds like a good idea. Start with a "list of useful functions someone may need" in that wiki. See how it goes.
**\<moneromooo>** And it doesn't seem like a huge waste of time.
**\<gingeropolous>** yeah, i mean if a random dev stumbles into monero, presumably they goto the github for code, so that wiki is probably where they'll go first
**\<+hyc>** I've never seen it... :P
**\<moneromooo>** I've only seen it because I was given alink to it :D
**\<gingeropolous>** hehehe. at the minimu, I can dump the rpc documentation thats on getmonero.org into it via the power of copy and paste
**\<+hyc>** sounds like a good start
**\<+hyc>** most 3rd party integrations should be RPC anyway
**\<gingeropolous>** so i missed the beginning. is this the general topic of "where's the docs?"
**\<imans>** If development work for API is finished and you want it to take to third parties. Create illustrations about integration for every industry you want to focus or you think monero should be a partner with. Attach it to the wiki
**\<moneromooo>** And that's going to totally change soon.
**\<gingeropolous>** right.
**\<moneromooo>** Anyway, any other arguments/ideas about documentation ?
**\<gingeropolous>** well the 2 will co-exist for a while, right?
**\<moneromooo>** Yes.
**\<imans>** I think documentation is not the main focus for this meeting? What is aimed to discuss today?
**\<moneromooo>** Whatever development related stuff people want to talk about.
**\<pero>** the documentary i think
**\<imans>** nice
**\<moneromooo>** hyc: have you had some more thoughts about how to make a lmdb based wallet data file ?
**\<medusa_>** i have nothing to say about documentation, but i want to encourage everybody to build and try the gui :-)
**\<dEBRUYNE>** **\<moneromooo>** Whatever development related stuff people want to talk about. \<= jaquee and I can give a few GUI updates soon^tm
**\<+hyc>** I've been thinking about how to integrate encryption, yes
**\<+hyc>** but no new code written yet
**\<pero>** soon is a little ambiguous - closer to 10min or 10weeks?
**\<dEBRUYNE>** pero: whenever the current topic of the meeting is finished :P
**\<moneromooo>** Well, let's have dEBRUYNE and jaquee then.
**\<dEBRUYNE>** So right now
**\<dEBRUYNE>** Ok so, fluffypony is in the process of building beta binaries
**\<dEBRUYNE>** Building went fine, but there is a little issue on windows with hardware acceleration, i.e., the GUI won't run if that is disabled
**\<dEBRUYNE>** However, we suspect that on "normal" systems it won't be an issue, because it's enabled by default there
**\<moneromooo>** Mesa might help ?
**\<dEBRUYNE>** luigi and Articmine are going to test this tomorrow when Fluffypony returns
**\<moneromooo>** Cool, thanks all :)
**\<+hyc>** sheesh, it's a wallet nota videogame. what acceleration does it want...
**\<xmrcoma>** lets waive a magic want that will cause all windows users worldwide to swtich to linux overnight. issue solved
**\<moneromooo>** It's using OpenGL for its widget set apparently.
**\<dEBRUYNE>** It's fairly trivial to enable too on windows systems
**\<moneromooo>** Got had by this when I tried it a few days back.
**\<dEBRUYNE>** Fluffypony ran into the issue because he was building on a windows server
**\<@ArticMine>** Basically Windows computers with really ancient graphics and certain virtual machine implementations of Windows have this hardware acceleration issue
**\<eyejay>** a clear deal breaker. it's ded
**\<jaquee>** exactly. so it's not a really big issue imo
**\<+hyc>** QT is requiring this dependency?
**\<@ArticMine>** Windows server is the other case since it uses very minimal graphics by design
**\<jaquee>** yes some QT widgets requires it
**\<@ArticMine>** Yes the dependency is from QT on Windows
**\<moneromooo>** http://stackoverflow.com/questions/18794201/using-qt-without-opengl seems to imply Qt can be built without opengl.
**\<+hyc>** nuts... I mean, OpenGL isn't even intended for 2D graphics. It's 3D gaming stuff.
**\<gingeropolous>** based on my statistical analysis of the clouds I'm sure 95% of people requiring windows GUI are running windows 10 because they upgrade because it told them to
**\<gingeropolous>** that said, the remaining 5% will be the loudest
**\<medusa_>** i bet its that truning thing when refreshing
**\<moneromooo>** AFAICT, 2D acceleration in new GPUs is a bit shit, and using 3D with orthonormal projection is actually faster.
**\<imans>** isn't it designed to support all windows version?
**\<@ArticMine>** Windows 10 is not an issue unless some very special customization's are made
**\<iDunk>** but all windows versions are not designed to support it
**\<imans>** Haha, iDunk clever
**\<iDunk>** ;)
**\<imans>** Enable switches or options to turn on/off opengl support and its related stuff in the wallet.
**\<dEBRUYNE>** I think realistically speaking, only a negligible percentage of users will run into the issue
**\<@ArticMine>** Well XP will support it on most later XP computers
**\<dEBRUYNE>** And they can turn it on fairly easy
**\<dEBRUYNE>** (in the rare case it's disabled by default)
**\<moneromooo>** Anything else about the GUI ?
**\<pero>** i was hoping the default file path -related issues on linux would be fixed before any binaries got into the wild - the github issues are still open so i take it that hasn't happened?
**\<dEBRUYNE>** **\<moneromooo>** Anything else about the GUI ? \<= I think jaquee wanted to tell a bit on what he is working on and what he'll be working on in the future
**\<jaquee>** yes
**\<moneromooo>** jaquee: please do :)
**\<imans>** Well, I would also like to add another option. Add an option to sync from the local blockchain or simply act as a light wallet. This will help the gui to both work as light or core wallet.
**\<moneromooo>** (14 minutes till kovri meeting)
**\<imans>** okay, waiting
**\<TedTheFicus>** Yes, that is a good idea
**\<jaquee>** i'm currently working on the wallet selector issue
**\<jaquee>** open wallet form file... switch wallet etc
**\<imans>** good to hear
**\<jaquee>** and i will also fix the default path on linux
**\<imans>** fine.
**\<jaquee>** hower i won't be finished today
**\<pero>** o/
**\<jaquee>** so it has ot wait until next release
**\<imans>** It won't be an issue
**\<xmrcoma>** no neeed to finish today jaquee. thanks for your hard work. From a strategic point of view GUI release before Oct 28 (zcash release) would be helpful
**\<jaquee>** if the windows binaries gets built tomorrow
**\<jaquee>** and after that i'm gonna work on whatever the commuity feels most prioritized
**\<moneromooo>** That's cool, thanks jaquee.
**\<jaquee>** like the plugin system or better integration with daemon
**\<TedTheFicus>** Can anyone in the know comment on (xmrcomas) statement?
**\<moneromooo>** If we're going to have binaries flying around, I think things like validation, avoiding user being dumb, etc, are a good thing to focus on.
**\<jaquee>** yes. we could improve the ux with better validation
**\<moneromooo>** About what ? Wanting binaries before 28 ?
**\<imans>** Create use cases
**\<medusa_>** yes personally i think all the dangerous stuff is fixed, at least im not aware of any
**\<endogenic>** i was also concerned to see that someone attempting to run a macos binary of the gui wallet the other day got a crash about a dynamic library not having been able to be loaded -- and i believe we found out that it was boost which wasn't installed -- for the gui release, will there be an installer for mac os to take care of such dependencies?
**\<medusa_>** the mian thing is that the "open from keys file" usecase is missing and windows suers chan not easily switch wallets
**\<moneromooo>** Niece. Thanks for testing medusa_ :)
**\<moneromooo>** Probably just build boost statically.
**\<jaquee>** endogenic: I think that's a build issue. Won't affect the binaries afaik
**\<+hyc>** shouldn't we be building this with statically linked libboost?
**\<endogenic>** jaquee: ok, excellent
**\<hiall>** when official gui wallet out?
**\<gingeropolous>** about 2 weeks
**\<moneromooo>** Anything else you want to add, jaquee ?
**\<jaquee>** nope
**\<TedTheFicus>** There is no date, it was just discussed now and testing is being done.
**\<moneromooo>** Anyone else want to talk about dev stuff for 6 minutes ?
**\<dEBRUYNE>** hiall: Read the backlogs :P
**\<_Slack> \<nanoakron>** Thanks @jaquee for all the GUI work. Two other issues I wanted to raise during this meeting were (a) killing dead issues on github and (b) formalising the log levels. WRT log levels, I don’t mind going through the code and changing all log outputs to the correct level if we can agree what those should be, in advance of a better programmer changing the logging subsystem itself. Please see and comment on https://github.com/monero-project/monero
**\<tompole>** Can someone confirm that the languages page has been scrubbed from the GUI?
**\<endogenic>** i do want to mention i don't think any normal user would install boost on their own -- and the crash itself wouldn't be acceptable as a graceful failure fmpov as a product guy
**\<moneromooo>** I'd leave any level change till after the log system change, let's not waste work.
**\<hiall>** so GUI release this month? :O
**\<_Slack> \<nanoakron>** @moneromooo OK makes sense
**\<moneromooo>** tompole: it's here as of today, just with only en_US IIRC.
**\<dEBRUYNE>** \<tompole>** Can someone confirm that the languages page has been scrubbed from the GUI? **\<= Yeah, translations aren't done yet
**\<jaquee>** tompole: yes we've removed all languages except english for now until translations are finsihed
**\<sdgsdug9sd>** if the issues with hardware acceleration get fixed in time, the gui should come out before oct 28 right?
**\<_Slack> \<nanoakron>** Still inviting comments on the discussion though
**\<tompole>** Okay cool, thanks.
**\<dEBRUYNE>** I'll put the strings on transifex next week
**\<dEBRUYNE>** Such that the community can help translating
**\<dEBRUYNE>** then we can enable them again
**\<moneromooo>** As for killing closed bugs, that'll happen, once the pony gets a minute. He has logs with issues list.
**\<imans>** I just started to compile one for my ubuntu 15.10
**\<endogenic>** i'm curious to know how qt was chosen as the gui lib, if anyone can comment
**\<moneromooo>** For people wanting to read the kovri meeting a 3 minutes, that'll be on #kovri-dev
**\<+hyc>** qt is multi-platform, seems a reasonable choice
**\<_Slack> \<nanoakron>** Thanks all. See you around!
**\<moneromooo>** The other main one is GTK. Or.. custom :D
**\<moneromooo>** WxWidgets maybe.
**\<i2p-relay>** {-anonimal} #kovri-dev topics today will be API and resolving the logo.
**\<+hyc>** gtk is atrocious. yeah mebbe wxwidgets
**\<moneromooo>** Java :o
**\<_Slack> \<dadude>** libgui?
**\<hiall>** so there is a possibility that we see gui before end of october?
**\<sdgsdug9sd>** expected date for release of the gui?
**\<_Slack> \<dadude>** libui sorry https://github.com/andlabs/libui
**\<gingeropolous>** there's always a possibility
**\<moneromooo>** Oh my. Maybe in november.
**\<TedTheFicus>** It is possible yes. Have a look on GitHub under project MonerCore to gauge the status
**\<moneromooo>** December, otherwise.
**\<medusa_>** next year guys
**\<sdgsdug9sd>** lol