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

Merge pull request #191

Browse source 
1415d6a Dev meeting and Kovri meeting logs for meetings held on 2016-10-16 & 2016-10-30 (dEBRUYNE-1)
This commit is contained in:
Riccardo Spagni 2016-11-02 22:00:47 +02:00
commit 6011f8bb53
No known key found for this signature in database
GPG key ID: 55432DF31CCD4FCD
4 changed files with 1172 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

302
_posts/2016-10-16-logs-for-the-Kovri-dev-meeting-held-on-2016-10-16.md Normal file
View file

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

369
_posts/2016-10-16-overview-and-logs-for-the-dev-meeting-held-on-2016-10-16.md Normal file
View file

@ -0,0 +1,369 @@
---
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
**\<tompole>** 2018
**\<@ArticMine>** hiall A possibility Yes; Promises: No
**\<gingeropolous>** now the probability of that possibility is a different story
**\<xmrcoma>** 2018 sounds like fud. I say 2017 at the latest
**\<TedTheFicus>** Thanks for all your hard work everyone!
**\<moneromooo>** For people wanting to read the kovri meeting 1 a minute, that'll be on #kovri-dev
**\<moneromooo>** Thanks all
**\<tompole>** Monero doesn't need to be concerned with tending to deadlines that relate to other projects.
**\<gingeropolous>** ONWARD MONERO!
**\<kali_>** Thanks guys!
**\<+hyc>** bye all
**\<@ArticMine>** I am going there now.
**\<medusa_>** thaks people, good luck and rock on
**\<sdgsdug9sd>** on a serious note though, can someone just tell whats the anticipated date for gui release?
**\<gingeropolous>** no
**\<kkhugs>** @moneromoo thanks for that address verification wallet API pr
**\<sdgsdug9sd>** why?
**\<gingeropolous>** because development
**\<notyomomma>** monero should be concerned with the needs of the user - which is the gui. I think the questions on timing are relevant
**\<_Slack> \<xmr_eric>** lol
**\<xmrcoma>** gui will be done when it is done. not 1 day before or after
**\<moneromooo>** sdgsdug9sd: apparently tomorrow
**\<xmrcoma>** soon. tm
**\<moneromooo>** (or so I read above)
**\<gingeropolous>** well, its been 2.5 years
**\<pero>** before the documentary
**\<pero>** i think everyone can commit to that?
**\<dEBRUYNE>** Like I said above, luigi & ArticMine will test on windows systems tomorrow
**\<moneromooo>** it's a bit rickety still though
**\<dEBRUYNE>** if there is no issue there, I see no reason to not put the beta release out
**\<endogenic>** exciting
**\<dEBRUYNE>** there can be a subsequent release when the linux path issue, wallet choosing issue, are fixed
**\<xmrcoma>** I saw forget windows. just release for linux and make everyone convert:)
**\<sdgsdug9sd>** hmmm, not sure im getting this clear. so, its expected to be released tomorrow but no later than oct 28?
**\<xmrcoma>** f miscrosoft
**\<moneromooo>** Unless tomorrow forgets to end, I guess.
**\<xmrcoma>** sdg 2017 at the latest
**\<pero>** the reason behind the prioritizing the file paths is that we'll see an influx of 'noobs' asking if this or that directory can be safely deleted
**\<xmrcoma>** but maybe tomorrow:)
**\<gingeropolous>** moneromooo, lulz
**\<dEBRUYNE>** No testing is tomorrow, if that is fine the bins can be put out
**\<dEBRUYNE>** but that isn't necesarily tomorrow too
**\<dEBRUYNE>** :P
**\<hiall>** gui testing tomorrow?
**\<moneromooo>** Oh, multi day testing. Fair enough. Ignore me.
**\<ontario>** noob question here , when the gui is released can we mine directly to gui wallet?
**\<moneromooo>** Later, yes. Not yet.
**\<sdgsdug9sd>** alrighty, what about kovri release? shouldnt it be december 2016?
**\<dEBRUYNE>** moneromooo: you could put your GUI wallet address in the daemon though
**\<xmrcoma>** can someone comment on this? https://www.youtube.com/watch?v=dQw4w9WgXcQ
**\<moneromooo>** dEBRUYNE: what do you mean ?
**\<_Slack> \<dadude>** rickrooool!
**\<dEBRUYNE>** moneromooo: just start_mining in the daemon
**\<_Slack> \<dadude>** it ends in XcQ
**\<dEBRUYNE>** and then your GUI address
**\<dEBRUYNE>** you need a daemon running to use the GUi anyway
**\<moneromooo>** Hmm, yes. That was not the question though I think.
**\<dEBRUYNE>** But that's more of a way around :P I think the guy meant mining directly in the GUI
**\<moneromooo>** Oh, *to*, actually you're right.
**\<tompole>** You mean you still need a terminal window open in order for the GUI to work?

236
_posts/2016-10-30-logs-for-the-Kovri-dev-meeting-held-on-2016-10-30.md Normal file
View file

@ -0,0 +1,236 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-10-30
summary: Brief review of what has been completed since last meeting, Kovri Logo, Salti, and code & open tickets discussion
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*October 30th, 2016*
# Logs
**\<fluffypony>** alright anonimal, the floor is yours
**\<meeting-bot> [anonimal]** Proposed meeting items:
**\<meeting-bot> [anonimal]** 1. Greetings
**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** 3. @fluffypony's request for finished logo
**\<meeting-bot> [anonimal]** 4. ∫alti as Monero project
**\<meeting-bot> [anonimal]** 5. [libqtoopie](https://github.com/EinMByte/qtoopie/issues/1)
**\<meeting-bot> [anonimal]** 6. Preparing for pre-alpha release
**\<meeting-bot> [anonimal]** 7. Code + ticket discussion / Q & A
**\<meeting-bot> [anonimal]** 8. Any additional meeting items
**\<meeting-bot> [anonimal]** 9. Confirm next meeting date/time
**\<meeting-bot> [anonimal]** Hi
**\<meeting-bot> [EinMByte]** Hi
**\<meeting-bot> [i2p-relay] {-moneromooo}** Hi
**\<meeting-bot> [i2p-relay] {-pero}** hi
**\<meeting-bot> [olark]** Greetings.
**\<boomlol23>** hi
**\<fluffypony>** ola
**\<meeting-bot> [i2p-relay] {-ArticMine}** hi
**\<maoam>** hi
**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** Lots of refactoring, some fixes.
**\<meeting-bot> [anonimal]** New contributor olark/olarks!
**\<meeting-bot> [anonimal]** Welcome olark!
**\<meeting-bot> [olark]** o/
**\<fluffypony>** welcome olark
**\<meeting-bot> [anonimal]** Anything else on 2.?
**\<meeting-bot> [anonimal]** (olark has been doing great work + tackling a huge learning curve. very cool)
**\<fluffypony>** olark
**\<meeting-bot> [olark]** lots of refactoring ;)
**\<fluffypony>** maybe you can give us a brief background on you
**\<meeting-bot> [i2p-relay] {-_Slack} \<nanoakron>** How’s the documentation looking to make that learning curve more shallow for future developers?
**\<meeting-bot> [anonimal]** (e.g., favourite book, long walks on the beach, etc.)
**\<meeting-bot> [anonimal]** nanoakron: moneropedia. We can talk more about that at the end of the meeting too.
**\<meeting-bot> [olark]** Have been programming for the last 3-4 years on and off. Just getting back into C++ have followed Monero and Kovri for the last year or so and figured I should stop procrastinating and help move things forward.
**\<fluffypony>** olark: http://i.imgur.com/9AQYqBr.png
**\<meeting-bot> [olark]** Also long time i2p user, so I know what's up.
**\<meeting-bot> [anonimal]** lol, badge of honor.
**\<meeting-bot> [anonimal]** Alright, well we're glad to have more hands on deck.
**\<meeting-bot> [anonimal]** Anything else before moving onto 3.?
**\<meeting-bot> [olark]** Haha thanks fluffypony
**\<meeting-bot> [anonimal]** 3. fluffypony's request for finished logo
**\<meeting-bot> [anonimal]** fluffypony: ^
**\<fluffypony>** yes
**\<fluffypony>** ok this logo has taken WAY too much time
**\<fluffypony>** I know that logos are kinda-permanent, but it's holding other stuff up
**\<boomlol23>** why are all msgs going through meetingbot..
**\<fluffypony>** boomlol23: because we're spread out over multiple networks
**\<meeting-bot> [anonimal]** fluffypony: what's the best solution for now?
**\<boomlol23>** ok
**\<fluffypony>** I'd like to have the logo by the end of the meeting
**\<fluffypony>** if colours are an issue let's just stick with the original colours
**\<fluffypony>** we can ALWAYS change it later
**\<meeting-bot> [EinMByte]** Wait, we still haven't decided on the logo?
**\<fluffypony>** EinMByte: we have
**\<fluffypony>** but then there were font and kerning and colour changes
**\<ontario>** new monero logo?
**\<meeting-bot> [anonimal]** ontario: kovri logo
**\<fluffypony>** ontario: no Kovri logo, we're in the Kovri meeting now
**\<ontario>** k sry
**\<meeting-bot> [anonimal]** Ok, can pero send you the finished work then?
**\<fluffypony>** np :)
**\<fluffypony>** yes please
**\<sornros>** may I ask if I understood correctly that the i2p code will be rewritten in c++?
**\<meeting-bot> \* anonimal** has to move onto next item....
**\<fluffypony>** either uploading somewhere or ric@getmonero.org
**\<pero>** i thought i 'submitted' the final one last weekend - i'd like to make one tiny half pixel change if i can
**\<meeting-bot> [anonimal]** sornros: we can answer more after the meeting
**\<fluffypony>** sornros: it already is being - https://github.com/monero-project/kovri
**\<pero>** i'll email it to both fluffypony and anonimal shortly
**\<meeting-bot> [anonimal]** Anything else on 3.?
**\<sornros>** thanks
**\<pero>** with the monero colors
**\<fluffypony>** no that's anonimal, tks
**\<pero>** http://imgur.com/a/xCaZV fyi
**\<fluffypony>** that's it
**\<meeting-bot> [anonimal]** 4. ∫alti as Monero project
**\<fluffypony>** pero: ok perfect - if you can send it to me after the pixel change
**\<meeting-bot> [EinMByte]** sure
**\<pero>** half-pixel :P
**\<meeting-bot> [anonimal]** EinMByte: I had some thoughts unless you wanted to dive into anything first
**\<sornros>** thats a nice logo, I like the font too
**\<meeting-bot> [EinMByte]** anonimal: No go ahead
**\<meeting-bot> [anonimal]** We've moved on sornros.
**\<meeting-bot> [anonimal]** EinMByte: since I haven't spent any time researching webextensions, can we *for sure* do what we want to achieve with XUL/XPCOM?
**\<meeting-bot> [anonimal]** I'm thinking we consider brushing aside the deprecation issue for now and someone can pick it up in the future?
**\<PowerFlower>** hi sorry for being late -_- I hope its not too late. Simple question: Will be the GUI released before the next XMR core release in ?Januaray?
**\<meeting-bot> [EinMByte]** It depends what exactly we want to achieve
**\<meeting-bot> [anonimal]** If we *can* do that now, we could move it into monero-project and it will gain more attention.
**\<fluffypony>** PowerFlower: this is the Kovri meeting, you'll have to hold that question for later
**\<PowerFlower>** okay :)
**\<meeting-bot> [anonimal]** EinMByte: well, the easy stuff for starters re: profile. We can do that, right?
**\<meeting-bot> [EinMByte]** anonimal: If we accept that the user will have to use the plugin with a separate profile, then we can do everything we need with webextensions I guess
**\<meeting-bot> [EinMByte]** Can we create the profile using webextensions? Probably not
**\<meeting-bot> [EinMByte]** Then again, people are apparently smart enough to run TBB, so if necessary we can create a script to create the firefox profile
**\<meeting-bot> [anonimal]** I think that was what we were going for
**\<meeting-bot> [EinMByte]** Problem with XUL is that 1) it's deprecated so development will only get worse for us 2) harder to port to other browsers (contrary to webextensions)
**\<meeting-bot> [EinMByte]** It seems like a bad idea to start creating a plugin with deprecated technology
**\<meeting-bot> [anonimal]** Where's the definite deprecation date though?
**\<meeting-bot> [EinMByte]** There is none (very vague, IIRC)
**\<meeting-bot> [EinMByte]** It's also not clear if e.g. it will be deprecated for firebird
**\<meeting-bot> [EinMByte]** (in fact, does anyone know if firebird itself is (going to be) deprecated?)
**\<meeting-bot> \* anonimal** doesn't know
**\<meeting-bot> [anonimal]** So, we are in a good position to influence webext development: they are still taking feature requests, etc. If we get *something* going now, there is a far better likely hood of a webdev coming along to contribute than if we have a mostly empty repo.
**\<meeting-bot> [anonimal]** And I can't find a date for deprecation, should we really base a great idea on what-if's?
**\<meeting-bot> [EinMByte]** Yes, I agree. My spare time does not though
**\<meeting-bot> [anonimal]** I know, nor mine, but I've semi-frequently seen people popping in and out of #monero-dev wanting to contribute to non-c++ projects.
**\<meeting-bot> [EinMByte]** Well, we know for sure it will be deprecated. Just not when. That sounds bad to me, so better try and do it with webext imho
**\<meeting-bot> [anonimal]** Ok, so maybe what we should do now then is write a definite roadmap/readme that will give others a better understanding of wth we are talking about.
**\<meeting-bot> [i2p-relay] {-ArticMine}** I have to leave
**\<meeting-bot> [anonimal]** s/definite/definitive/
**\<meeting-bot> [anonimal]** EinMByte: I think we can easily do that for now. Then, once we are more certain about our webext strategy, bring up this topic at another meeting?
**\<meeting-bot> [anonimal]** If roadmap is too much, at least improve our readme.
**\<meeting-bot> [EinMByte]** anonimal: That's probably a good idea.
**\<meeting-bot> [EinMByte]** Sure.
**\<meeting-bot> [EinMByte]** I agree that we should first see if we can actually do what we want to do, so for example: can we change all of the necessary settings
**\<meeting-bot> [anonimal]** Ok, sounds great. Anything else on 4.?
**\<maoam>** a short readme would be nice
**\<realsony>** EinMbyte may i ask for your GIT repository name i couldn't find it
**\<meeting-bot> [EinMByte]** realsony: EinMByte/salti
**\<meeting-bot> [anonimal]** 5. [libqtoopie](https://github.com/EinMByte/qtoopie/issues/1)
**\<realsony>** ty
**\<meeting-bot> [anonimal]** EinMByte: did you get a chance to review #1?
**\<meeting-bot> [EinMByte]** I read it
**\<meeting-bot> [EinMByte]** Not sure if I can agree with converting it to a library
**\<meeting-bot> [EinMByte]** It should be the other way around, IMHO
**\<meeting-bot> [EinMByte]** qtoopie is based on I2PControl, with the idea of making it router-agnostic
**\<meeting-bot> [anonimal]** As it, you don't think it's possible or don't think it *should* be done or don't want it to be done?
**\<meeting-bot> [anonimal]** So what part would you rather see as the lib?
**\<meeting-bot> [anonimal]** If monero's gui needs it's own i2pcontrol then that's fine; I'm just trying to avoid repetition.
**\<meeting-bot> [EinMByte]** It depends on what we want: if we want to build a router-agnostic GUI, I think I2PControl is the best option. In that case we could simply bundle qtoopie + kovri router and release this as an easy-to-use router package
**\<meeting-bot> [EinMByte]** If we want to build a GUI specifically for kovri, then we can rely on the (currently not existing) kovri API (libcore/libclient)
**\<meeting-bot> [EinMByte]** But in that case too, it would not really make sense for it to be a library. Instead, it would be comparable to what kovri-app currently is, except that it would be a GUI rather than CLI
**\<meeting-bot> [anonimal]** re: API, that's what the monero gui will be using, but where could we eliminate redundancy if the API and i2pcontrol would also do some of the more basic things that i2pcontrol provides?
**\<fluffypony>** I2PControl would be able to control Kovri + Java i2p etc. right?
**\<meeting-bot> [EinMByte]** My original idea for qtoopie is that it would fork for all exiting I2P routers that support I2PControl.
**\<fluffypony>** oh I missed the "based on"
**\<fluffypony>** ok makes sense
**\<meeting-bot> [EinMByte]** So the redundancy is not eliminated at the level of the kovri implementation, but instead at all implementations (no need for a specific GUI)
**\<meeting-bot> [anonimal]** EinMByte: Ok, that I understand. But there's really no way to create libqtoopie so the monero gui can use it *now* (even in it's current state)?
**\<meeting-bot> [anonimal]** Why create extra monero gui code and i2pcontrol impl when that's already done?
**\<meeting-bot> [anonimal]** This doesn't change the functionality of qtoopie. I'm just basing this off what you said when I brought up the lib idea a while ago.
**\<meeting-bot> [EinMByte]** Sure, monero can use qtoopie directly
**\<meeting-bot> [anonimal]** If it's more work than not, and adversely effects qtoopie, then I understand.
**\<meeting-bot> [EinMByte]** at least in the sense "you can display the windows defined in the qtoopie project"
**\<meeting-bot> [EinMByte]** I guess that would classify as a library.
**\<meeting-bot> [EinMByte]** The question is why you would want to bundle it like that
**\<meeting-bot> [EinMByte]** (you could also just provide the executable with the monero executables, and then open this from the monero GUI, there would be little difference to the end use)
**\<meeting-bot> [anonimal]** To save redundant code so people don't have to install qtoopie to use qtoopie; and so it's integrated with the monero gui.
**\<fluffypony>** can't we have our own controls in the GUI
**\<fluffypony>** with bindings to libqtoopie functions ?
**\<meeting-bot> [anonimal]** fluffypony: own controls to API, sure.
**\<meeting-bot> [anonimal]** fluffypony: libqtoopie, EinMByte would know; I imagined yes.
**\<meeting-bot> [EinMByte]** By the way, for reference on i2pcontrol: http://zzz.i2p/topics/2030-proposal-bundle-i2pcontrol, http://zzz.i2p/topics/1942-i2pcontrol-for-generic-user-interfaces
**\<meeting-bot> [EinMByte]** If you want to have your own controls, there's not much point in using all of qtoopie
**\<meeting-bot> [EinMByte]** then you just need to use i2pcontrol
**\<meeting-bot> [EinMByte]** (which is very simple to implement; or you could use the part of qtoopie that deals with this)
**\<meeting-bot> [anonimal]** EinMByte I think you're missing the point but I'm probably not explaining my intentions well.
**\<meeting-bot> [anonimal]** So, libqtoopie: not needed. qtoopie: agnostic but will not be in library form.
**\<meeting-bot> [anonimal]** We will create our own controls that use the API
**\<meeting-bot> [EinMByte]** qtoopie is an end-user program, hence why I'd say "not in library form"
**\<meeting-bot> [anonimal]** I know EinMByte, I'm just trying to save time and code.
**\<meeting-bot> [EinMByte]** We could take some of the code in qtoopie and put it in a library "libi2pcontrol-client"
**\<meeting-bot> [EinMByte]** This library could then be used by e.g. monero
**\<meeting-bot> [anonimal]** i2pcontrol is insanely overrated, seriously overrated in relation to as much time as we're talking about it.
**\<meeting-bot> [EinMByte]** But this is assuming that monero would be using i2pcontrol at all
**\<meeting-bot> [anonimal]** I don't see the point if there are API's in place.
**\<meeting-bot> [anonimal]** And i2pcontrol is limited in its own right.
**\<meeting-bot> [EinMByte]** Yes, i2pcontrol has severe limitations
**\<meeting-bot> [anonimal]** So, unless that entire spec is worked on, I have nothing more to say on the subject for now.
**\<meeting-bot> [EinMByte]** (even the proposed version 2)
**\<meeting-bot> [anonimal]** Ok, so we'll learn from the mistakes of others and try not to make our own.
**\<meeting-bot> [anonimal]** fluffypony: does that makes sense? anyone need a tl;dr?
**\<fluffypony>** yes it does
**\<fluffypony>** tl;dr for the log
**\<meeting-bot> [anonimal]** tl;dr qtoopie is great. We won't be using qtoopie in lib or bundled form because of severe limitations in i2pcontrol. We will be using GUI controls via the kovri API(s).
**\<meeting-bot> [EinMByte]** What is important to understand is that I2PControl is intended to create high-level control programs
**\<meeting-bot> [EinMByte]** It isn't designed to deal with lower-level configuration that monero might need
**\<meeting-bot> [anonimal]** Anything else on 5.?
**\<meeting-bot> [EinMByte]** One of the main limitations, in case anyone is wondering, is that i2pcontrol has to serialize everything and send it over the network
**\<meeting-bot> [EinMByte]** There's no possiblity of handlers or anything like that too
**\<meeting-bot> [EinMByte]** (you have to continuously request updates)
**\<meeting-bot> [anonimal]** yes.
**\<meeting-bot> [anonimal]** Ok, 8 minutes
**\<meeting-bot> [anonimal]** 6. Preparing for pre-alpha release
**\<meeting-bot> [EinMByte]** For a simple GUI, that's probably good enough but it doesn't work when you want to integrate kovri with something like monero
**\<meeting-bot> [anonimal]** Yay! Nov. 1st pre-alpha will not happen, nooo way. I've been busy this month with non-code work; only recently with more code.
**\<meeting-bot> [anonimal]** EinMByte has been very busy too.
**\<meeting-bot> [EinMByte]** :|
**\<fluffypony>** no problemo - let's get it right instead of getting it rushed :)
**\<meeting-bot> [anonimal]** EinMByte: realistically, I think we should push the date to Dec. 1st or later.
**\<meeting-bot> [anonimal]** It's never going to perfect in my eyes, but...
**\<meeting-bot> [EinMByte]** Sure
**\<meeting-bot> [EinMByte]** dont' expect more activity from me though
**\<meeting-bot> [anonimal]** You mean ever or temporary?
**\<meeting-bot> \* anonimal** hopes temporary
**\<meeting-bot> [EinMByte]** I mean before december the first
**\<meeting-bot> [anonimal]** Ok. I'll set a tentative date for dec. 1st; no later than 33c3.
**\<meeting-bot> [anonimal]** (which is not dec. 1st of course)
**\<meeting-bot> [anonimal]** I'll have to adjust the milestone date on github and roadmap etc.
**\<meeting-bot> [anonimal]** Any other thoughts on 6.?
**\<meeting-bot> [anonimal]** This coming month should be far more productive code-wise than in october.
**\<meeting-bot> [anonimal]** We'll see what we can knock-out before december.
**\<meeting-bot> [anonimal]** 2 minutes to spare
**\<meeting-bot> [anonimal]** Skipping 7. Code + ticket discussion / Q & A unless anyone wants to say something?
**\<meeting-bot> [anonimal]** 8. Any additional meeting items
**\<fluffypony>** nope that's it from my side
**\<fluffypony>** glad to see the refactoring efforts
**\<fluffypony>** will make stuff easier to work on later on
**\<meeting-bot> [iDunk]** head works now, thanks anonimal
**\<PowerFlower>** oberservers can now ask questions?
**\<meeting-bot> [anonimal]** fluffypony: yes indeedy
**\<meeting-bot> [anonimal]** iDunk: you're welcome, thanks for the notice and for actively testing :)
**\<meeting-bot> [iDunk]** np :)
**\<meeting-bot> [anonimal]** PowerFlower: kovri questions, yes
**\<fluffypony>** ok let's close up the Kovri meeting and then PowerFlower can ask their Monero question :-P
**\<meeting-bot> [anonimal]** Oh, those kinds of questions.
**\<meeting-bot> [anonimal]** Ok, 9. Confirm next meeting date/time
**\<meeting-bot> [anonimal]** Same time, two weeks?
**\<meeting-bot> [olark]** Sounds good.
**\<fluffypony>** yes
**\<meeting-bot> [anonimal]** Alright, thank you EinMByte and everyone else here for making the meeting.
**\<fluffypony>** meeting bot going down to switch back to the Monero stuf
**\<meeting-bot> [anonimal]** Thanks fluffypony

265
_posts/2016-10-30-overview-and-logs-for-the-dev-meeting-held-on-2016-10-30.md Normal file
View file

@ -0,0 +1,265 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-10-30
summary: Fluffy blocks, crypto libs
tags: [dev diaries, core, crypto, 0mq]
author: dEBRUYNE / fluffypony
---
*October 30th, 2016*
# Overview
An overview [can be found on Hello Monero](https://hellomonero.com/article/monerokovri-dev-meeting-note-highlights-2016-10-30).
# Logs
**\<Jaquee>** it takes quite long time to open/close wallets with this mempool size. Could the mempool be saved in wallet cache?
**\<Jaquee>** or is that a bad idea?
**\<Jaquee>** doesnt really affect closing wallets. my bad. but opening takes longer than normal i think?
**\<realsony>** test
**\<moneromooo>** You can test that easily by logging something before and after loading.
**\<moneromooo>** It's in src/cryptonote_core/tx_pool.cpp
**\<hyc>** is it mtg time yet?
**\<moneromooo>** Yes
**\<pero>** romero dev conference
**\<Jaquee>** all right. the gui def takes longer time top open because of mempool. And it also waits for mempool to be synced before closing.
**\<hyc>** why is that different from CLI behavior?
**\<Jaquee>** not sure yet
**\<Jaquee>** opening seems the same
**\<pero>** mooo you're a whitespace nazi
**\<Slack> \<nanoakron>** Is there a way that git PRs could be run through a common parser on the server-side to standardise any whitespace?
**\<moneromooo>** Not really, since it'll invariably try to reformat irrelevant stuff.
**\<moneromooo>** That said, if it could run on the diffs, it might work.
**\<Slack> \<nanoakron>** And WRT mempool size - would fluffy blocks as standard across the network (e.g. if included in HF4) make things better?
**\<revler1082>** i don't think so, it just helps with not sending txs again when a block is found, the mempool size is unaffected
**\<moneromooo>** So... if the pony isn't here... anyone wants to say something dev related ?
**\<Slack> \<nanoakron>** OK yes I see. But it should allow us to avoid some of the issues that bitcoin is having - if all mempools are synched and a miner wants to eat all the transactions into a single megablock, it would propagate much more quickly than without
**\<Slack> \<nanoakron>** I’m a tinkerer rather than a dev :slightly_smiling_face:
**\<revler1082>** yea so the bigger the blocks (assuming mempools are aligned), the greater the savings
**\<Slack> \<nanoakron>** Which would be an extra cool reason for making fluffy blocks compulsory in a hard fork
**\<revler1082>** hmm, I saw monero-moo's latest comments on the fluffy-block stuff, so I was going to go through those, but I don't have much else.
**\<revler1082>** if you guys would like me to change anything, etc, feel free to ask/comment
**\<Slack> \<nanoakron>** My only ‘dev issue’ is with the growing number of dead issues on github
**\<Slack> \<nanoakron>** We should probably only be at 60 or so live issues
**\<moneromooo>** I think at this point, it's testing. Especially that one about the array of txes noit in the pool but not requested again.
**\<realsony>** may i as what a dead issue is?
**\<realsony>** ask
**\<Slack> \<nanoakron>** One that’s been solved
**\<realsony>** ty
**\<dEBRUYNE>** monero-core has a lot of those too fwiw
**\<dEBRUYNE>** I can give you a list for monero-core fluffypony
**\<hyc>** typically I would not close an issue until the fix is in a tagged release
**\<hyc>** (at least, on other projects.)
**\<pero>** ^ +1
**\<Slack> \<nanoakron>** Or where the codebase has evolved onwards but the original person who has raised the issue has not tested to see if it’s still active
**\<pero>** or at the very least merged
**\<Slack> \<nanoakron>** @hyc can I ask - completely separate issue, have you considered offering your skills to port Bitcoin Unlimited to LMDB? They’ve got $500k in the bank...
**\<hyc>** I hadn't heard anything about that nanoakron
**\<Slack> \<nanoakron>** @hyc ask around - I’m sure their users would want to offer an even better reason to switch their node software away from core
**\<ArticMine>** Bitcoin unlimited will be insecure once the emission runs out
**\<Slack> \<nanoakron>** And I think the entire ecosystem will benefit
**\<Slack> \<nanoakron>** As for dead issues - there are still ones hanging around from before 0.10.0 which either haven’t been updated by their issuers or have been addressed
**\<hyc>** would definitely be a good idea to go thru and close any that havve been fixed
**\<revler1082>** @moneromooo i had left a comment in the code about whether I was double verifying since all the transactions were already in the pool, anything on that?
**\<revler1082>** could speed things up a bit
**\<moneromooo>** I'll have a look soon. String to grep for ?
**\<revler1082>** "Do I need to do this" lol
**\<moneromooo>** ok
**\<Slack> \<nanoakron>** lol
**\<Slack> \<malmen>** How is 0qm work?
**\<moneromooo>** proxmr: you'll know in ~30 min when anonimal's around for the kovri meeting.
**\<moneromooo>** tewinget: around ?
**\<Slack> \<nanoakron>** So the big themes I see in current development are: ZMQ, GUI, final touches to RingCT (?), changing the crypto library, changing the logging system and fluffy blocks. Any others?
**\<Slack> \<malmen>** What is fluffy blocks? I am missing something here
**\<iDunk>** dynamic fees
**\<revler1082>** @mailmen just a compact block implementation for monero
**\<moneromooo>** It's just sending txes from a block only if a peer doens't have them already.
**\<Slack> \<malmen>** Hmmmm, so, instead of sending all tx the block will contain only the reference of the tx that is in another block?
**\<Slack> \<nanoakron>** No, reference to the local mempool
**\<Slack> \<malmen>** Ahh
**\<revler1082>** no, it just sends the tx hashes, and since most nodes have the transactions in the mempool, it just gets the full tx from there
**\<Slack> \<nanoakron>** And if it’s not in there then you receive the missing Tx
**\<revler1082>** if it's missing any, it'll ask for those
**\<Slack> \<malmen>** Nice
**\<Slack> \<nanoakron>** Really nice :slightly_smiling_face:
**\<Slack> \<malmen>** It is implemented in any place already or we will be the first ones to have it?
**\<Slack> \<nanoakron>** Bitcoin has it
**\<revler1082>** yep, multiple implementations, xthin/compact blocks
**\<Slack> \<nanoakron>** but because they’re a dirty mix of hard and soft forked rules, and have a stupid mempool policy preventing network-wide synchronisation, they won’t see as much benefit as we will
**\<revler1082>** there's some way to save even more space based on some of the stuff you guys shared with me, where you send just some prefix of the tx_hash since there's unlikely to be collisions, but I think sacrificing some space to keep things simple is ok
**\<Slack> \<malmen>** Hmmm, nice... And about the way the db save the blocks, I was thinking in the other day
**\<Slack> \<nanoakron>** @revler1082 you should contact the original devs of XThin and ask them about those issues :slightly_smiling_face:
**\<moneromooo>** I don't know how the bitcoin ones work, but given what you wrote, I'd send the index of the tx you don't have. Possibly differential encoded.
**\<Slack> \<nanoakron>** @hyc is your db guy
**\<Slack> \<malmen>** Instead of the block on the the database save the full tx, can it be save the reference to other block with tx? It will use more disk io and cpu, but can save space
**\<revler1082>** thanks @moneromooo that's a good one
**\<moneromooo>** I'm guessing there might be a good reason why they don't do that though.
**\<Slack> \<nanoakron>** Well that’s an interesting point - if you’re pulling in other transactions to build your ring signature, do you do that from the mempool or from historic data stored in the local db? I’m not sure myself
**\<ArticMine>** The idea if I understand this is to save bandwidth
**\<revler1082>** @ArticMine correct
**\<revler1082>** not much difference now, but when monero takes over the world, savings should increase
**\<ArticMine>** You pull from the historic data not the mempool
**\<Slack> \<nanoakron>** So not many dev issues today which is good. Just really revler and moneromooo co-reviewing fluffy block code, and maybe closing old issues?
**\<moneromooo>** We can't close old issues. We can just make lists and wait for fluffypony to have time :)
**\<Slack> \<nanoakron>** True
**\<revler1082>** What's the crypto-lib replacement? I could maybe help with that, I mean my crypto skills are le garbage, but I can change function calls, lol
**\<Slack> \<nanoakron>** Would you think about the logging system in that case? The crypto currently works well enough
**\<moneromooo>** The main problem is choosing the best one. And that needs people who know them. The pony does I think.
**\<revler1082>** logging or crypto? or both?
**\<Slack> \<nanoakron>** Moneromooo, do you have any thoughts on where revler can best help after fluffy blocks are finished?
**\<moneromooo>** We'll need some crypto lib with a good PRNG, to replace the keccak construction we use now.
**\<Slack> \<nanoakron>** https://github.com/monero-project/monero/issues/1271
**\<Slack> \<nanoakron>** That’s what we’re referencing here revler - already some good discussion to review there
**\<moneromooo>** Wherever revler1082 is comfortable, really. If the previous bit changed was network stuff, then maybe more of it ?
**\<Slack> \<nanoakron>** What do you think the issues are with current network code?
**\<moneromooo>** fluffypony wanted to switch the P2P protocol to... er... something... name escapes me.
**\<Slack> \<nanoakron>** ;)
**\<moneromooo>** ZMTP.
**\<Slack> \<nanoakron>** ooh…sounds fancy. How about maybe helping with ZMQ??
**\<iDunk>** jesus
**\<moneromooo>** It's based on epee, from the CN people.
**\<Slack> \<nanoakron>** @iDunk you rang?
**\<revler1082>** all sounds good, i'll look into it and help where I can
**\<moneromooo>** The P2P code is really hard to understand, though that is subjective, mayube others like it more.
**\<iDunk>** yeah, I'm on the verge of really saying something
**\<moneromooo>** There are a few bugs, mainly that it leaks sockets.
**\<revler1082>** if i ever get my spaces and tabs passed @moneromooo
**\<Slack> \<nanoakron>** hehe
**\<Slack> \<nanoakron>** What’s up iDunk?
**\<moneromooo>** Well, it boils down to "don't change what you don't change".
**\<iDunk>** nanoakron: take it easy, man
**\<moneromooo>** But I agree I may be a bit too sold on clean diffs without extraneous stuff.
**\<moneromooo>** Those things are easy to fix though.
**\<revler1082>** lol, @moneromooo just messin, I want to kick myself when I push and see those in the diff, like mother ..
**\<Slack> \<nanoakron>** Revler wants to help with network related stuff and I’m just saying what’s in the codebase that is being worked on
**\<moneromooo>** And maybe helping with 0MQ, I guess it'll need some testing and fixing once tewinget's done with it to a point where it can be merged.
**\<fluffypony>** yes ZMTP
**\<moneromooo>** pony!
**\<Slack> \<nanoakron>** Woo!
**\<fluffypony>** apologies
**\<fluffypony>** had the meeting down for 7pm not 6pm
**\<Slack> \<nanoakron>** Do you guys change your clocks today down there in SA?
**\<Slack> \<nanoakron>** Ours went back last night. It’s now dark at 5pm. Misery.
**\<fluffypony>** no, we don't do DST
**\<fluffypony>** OH that's why
**\<fluffypony>** everything is confusing
**\<DaveyJones>** thought sth like this :p
**\<fluffypony>** re: closing issues
**\<fluffypony>** I'm happy to close them from lists
**\<fluffypony>** and I don't think we need to wait for them to be in a tagged release per se
**\<Slack> \<nanoakron>** Cool
**\<fluffypony>** have we discussed the compact blocks thing ?
**\<fluffypony>** I see there's some backlog on it
**\<Slack> \<nanoakron>** Briefly
**\<pero>** what prevents dupes then?
**\<pero>** might be better to tag issues with 'fixed in next release' or something and keep them open?
**\<revler1082>** all the verification is the asme, it's just saving from re-sending txs?
**\<fluffypony>** pero: dupe issues?
**\<revler1082>** oh
**\<pero>** yea
**\<fluffypony>** lol
**\<fluffypony>** revler1082: I was also confused
**\<pero>** sorry =/
**\<fluffypony>** np
**\<fluffypony>** pero raises a good point
**\<fluffypony>** I can flag them instead
**\<moneromooo>** If people don't search the bugs list, they'll file a dupe whether it's closed or open, no ?
**\<Slack> \<nanoakron>** Take https://github.com/monero-project/monero/issues/1256 as an example
**\<Slack> \<nanoakron>** May be a dupe, may not be...
**\<moneromooo>** I'm fine with bugs being opened when in doubt.
**\<Slack> \<nanoakron>** @moneromooo - yes they will
**\<dEBRUYNE>** \<fluffypony> everything is confusing <= Oh I didn't notice too
**\<pero>** but they likely won't experience the issue if it's in a release
**\<dEBRUYNE>** That link I posted on reddit says 17:00 Europe time lol
**\<fluffypony>** lol
**\<fluffypony>** ok so re: compact blocks
**\<revler1082>** got some fixes and ideas from @moneromooo that i'm gonna try
**\<fluffypony>** do we put it in a fork wrapper so that it only activates in Jan? or are we using the versionbits and making it available from now?
**\<revler1082>** only big thing is do we want backwards compatibility and a little messier code, or alter existing stuff/cleaner?
**\<Slack> \<nanoakron>** The good thing about hard forks is that we don’t need backwards compatibility
**\<moneromooo>** I'd rather have it in testnet first.
**\<Slack> \<nanoakron>** Yes
**\<revler1082>** definitely
**\<fluffypony>** ok let's finish the compact blocks discussion
**\<fluffypony>** PowerFlower: pleasure :)
**\<moneromooo>** I'd like to know what the changes are going to be with sodium/NaCl/cryptocpp/whatever. I don't know them, so I don't have useful input.
**\<Jaquee>** PowerFlower: Thank you. bye
**\<moneromooo>** Compact blocks: pretty good, not much to change, will need lots of testing though.
**\<revler1082>** yep
**\<fluffypony>** re: backwards compatibility, I don't think we need to support an environment where compact blocks isn't supported - a node that doesn't want to use it can just never claim to already have txs
**\<dEBRUYNE>** revler1082: Have you tested it on a personal private testnet?
**\<revler1082>** yea, and on mainnet with the backwards stuff
**\<dEBRUYNE>** oh cool
**\<fluffypony>** since we have a testnet reorg coming up we can use the opportunity to test wrapping it in a fork
**\<moneromooo>** We need to have both block types in the code at the same time though.
**\<moneromooo>** So if we do, conditional use isn't much more.
**\<moneromooo>** BTW, syncing from scratch uses a different set of messages, right ?
**\<revler1082>** yes i believe so
**\<moneromooo>** A possible optimization would be to always include txes with too low fee, since these would have been mined by the local host.
**\<realsony>** So men i read everything, didnt understand 97% :) convinces me that XMR has the best alt dev team :)
**\<moneromooo>** But that's really not needed now.
**\<revler1082>** yea, there's a few tweaks we can make, i like your send tx index instead of hash for missing
**\<moneromooo>** Yes, it sounds like a no brainer, so I'm suspicious that bitcoin is not doing it for non obvious reasons...
**\<moneromooo>** fluffypony: do you know why they use siphash hashes and not indices in the block ?
**\<moneromooo>** (since you linked to that doc, I think you might know :P)
**\<fluffypony>** moneromooo: I have no idea
**\<ontario>** noob suggestion: for the next meeting how about disabling other chat unless dev when the meeting bot started?
**\<fluffypony>** btcdrak might have an idea
**\<fluffypony>** ontario: if the room goes +m then only people with +v can speak, and then it becomes a closed meeting
**\<fluffypony>** better for it to stay open, we can handle the occasional interruption
**\<btcdrak>** yeah that's what to do
**\<ontario>** lol sry dont know much about irc things
**\<fluffypony>** btcdrak: moneromooo had a question about compact blocks, and why it uses siphash hashes instead of indices
**\<moneromooo>** (note, I know very little about bitcoin, so it could be tx indices don't make sense in bitcoin)
**\<btcdrak>** moneromooo: ask in #bitcoin-core-dev
**\<moneromooo>** OK, I will, thanks.
**\<i2p-relay> {-anonimal}** moneromooo: re: crypto, https://cryptopp.com/ has a list of all supported schemes. I know monero will have to keep supercop/ref10 impl but most others look covered (though I can't say *all* because I haven't yet looked at all monero crypto yet)
**\<fluffypony>** my thinking is that we can offload the sensitive stuff to TweetNaCl (ie. crypto_ops), as it's currently using SUPERCOP ref10
**\<fluffypony>** then we offload everything else to cryptocpp, including random
**\<fluffypony>** and then *if* we're seeing performance bottlenecking in something specific, we can use ASM implementations *only* in the places it's bottlenecking
**\<moneromooo>** Since we use part of... libsodium ? Does this not do everything we need ?
**\<fluffypony>** moneromooo: the libsodium source isn't even complete, so we'd have to make changes anyway
**\<fluffypony>** libsodium isn't as full-featured as cryptocpp anyway
**\<fluffypony>** and not as audited as TweetNaCl
**\<moneromooo>** Anything else to talk about ?
**\<fluffypony>** well
**\<i2p-relay> {-anonimal}** So there won't be a one-size-fits-all crypto solution, eh?
**\<fluffypony>** btw moneromooo
**\<fluffypony>** https://en.wikipedia.org/wiki/NaCl_(software)
**\<fluffypony>** so TweetNaCl implements all of those
**\<fluffypony>** as does libsodium
**\<fluffypony>** that libsodium can do a handful of extra things is neither here nor there
**\<fluffypony>** https://en.wikipedia.org/wiki/Comparison_of_cryptography_libraries
**\<moneromooo>** I'm curious to know why they made many versions of hte same thing.
**\<fluffypony>** the advantage is that cryptocpp can do a TON of stuff, it's FIPS 140 validates, and it uses the Boost license
**\<moneromooo>** That sounds like a recipe for pita.
**\<fluffypony>** moneromooo: of NaCl?
**\<moneromooo>** Yes.
**\<fluffypony>** they only made NaCl, and then they made TweetNaCl specifically to be extremely simple and auditable (so that it could be formally verified)
**\<fluffypony>** NaCl was forked and thus begat libsodium
**\<fluffypony>** so the original NaCl reference implementation has been replaced by libsodium, effectively
**\<moneromooo>** crypto++ is the same as cryptopp ?
**\<fluffypony>** yes
**\<fluffypony>** also has AES-NI support, which is great
**\<fluffypony>** doesn't have ARMv8 crypto support yet
**\<fluffypony>** "Unix (OpenBSD, Linux, OS X, etc.), Win32, Win64, Android, iOS, ARM"
**\<Slack> \<nanoakron>** Not may Cortex-A53 ARMv8 systems in the wild seem to have hardware crypto so far…apparently they need to pay for an extra license to enable it
**\<Slack> \<nanoakron>** Pine64 may do, but I’ve not bought one yet
**\<pero>** pine64 does
**\<moneromooo>** So if we were to switch to cryptopp, would be still keep the existing low level crypto code, or just use for new stuff ?
**\<moneromooo>** Though I guess we have a readily available test suite actually :)
**\<i2p-relay> {-anonimal}** fluffypony: I believe there is limited(?) armv8 support, or do you mean specifically aes-ni?
**\<i2p-relay> {-anonimal}** \* going off of memory, would need to confirm
**\<fluffypony>** anonimal: it's not NB right now
**\<fluffypony>** moneromooo: we'd switch
**\<fluffypony>** even if it's piecemeal
**\<Slack> \<nanoakron>** Sorry to ask about stuff that’s already been covered - what’s the final decision for integrating fluffy blocks? Implement as-is on testnet, then with version flags for 0.10.0, then with forking code for January, then finally abandon backwards compatible code at HF 5?
**\<Slack> \<nanoakron>** So that all nodes at HF5 will use compact blocks (of whatever improved flavour comes along in the interim)
**\<pigeons>** its not "forking code" though right?
**\<fluffypony>** no it's not
**\<Slack> \<nanoakron>** So it could in fact be made compulsory at HF 4 without backwards compatible code?
**\<fluffypony>** and I mistakenly forgot that we need to keep both block formats anyway for sync up
**\<fluffypony>** so not worth putting it in an HF wrapper
**\<Slack> \<nanoakron>** Unless we checkpoint at the next HF...
**\<moneromooo>** Not for 4. Seriously...