monero-project/monero-site
monero-project/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2025-01-10 21:05:04 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Logs for the Kovri and Dev meetings held on 2017-05-07

Browse source
This commit is contained in:
dEBRUYNE-1 2017-05-08 20:33:43 +02:00
parent eed3c0dd73
commit 84cb56e599
No known key found for this signature in database
GPG key ID: B9145F6EBFA81C32
2 changed files with 492 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

201
_posts/2017-05-07-logs-for-the-Kovri-dev-meeting-held-on-2017-05-07.md Normal file
View file

@ -0,0 +1,201 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2017-05-07
summary: Brief review of what has been completed since last meeting, Monero HackerOne Bounty, 96boards OpenHours showcase, website discussion, and code & open tickets discussion
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*May 7th, 2017*
# Logs
**\<anonimal>** 1. Greetings
**\<anonimal>** 2. Brief review of what's been completed since the previous meeting
**\<anonimal>** 3. More preparation for [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46) (@fluffypony @danrmiller location status)
**\<anonimal>** 4. Status (again) of [Monero HackerOne umbrella and bounty](https://github.com/monero-project/meta/issues/39). [hackerone.com/monero](https://hackerone.com/monero) is online but we need to resolve FFS funding before inviting researchers. VRP status for all projects + bounty status
**\<anonimal>** 5. Open forum for https://github.com/monero-project/kovri/issues/630
**\<anonimal>** 6. Website status (@rehrar @bigreddmachine @alvinjoelsantos @danrmiller)
**\<anonimal>** 7. @EinMByte ...where is he? Github repo privilege discussion
**\<anonimal>** 8. Code + ticket discussion / Q & A
**\<anonimal>** 9. Any additional meeting items
**\<anonimal>** 10. Confirm next meeting date/time
**\<anonimal>** Hello
**\<moroccanmalinois>** hi
**\<sgp>** hey!
**\<endogenic>** o/
**\<ajs>** Here
**\<iDunk>** \o
**\<i2p-relay> {-fluffypony}** hi!
**\<rehrar>** Here for a bit, then gone, then back.
**\<anonimal>** Yay, enough people for a party.
**\<Heretoobserve>** Hello
**\<anonimal>** 2. Brief review of what's been completed since the previous meeting
**\<rehrar>** 3...2...1... KOVRI!!!
**\<ArticMine>** hello
**\<anonimal>** For me, see http://forum.getmonero.org/9/work-in-progress/86967/anonimal-s-kovri-full-time-development-funding-thread?page=&noscroll=1#post-90900
**\<anonimal>** moroccanmalinois can fill us in on his work.
**\<moroccanmalinois>** i've been playing with fuzz testing
**\<i2p-relay> {-fluffypony}** nice
**\<anonimal>** I've looked through the PR's, looks like fun.
**\<moroccanmalinois>** it's the beginning. More tests to come
**\<anonimal>** Any questions/comments on point 2?
**\<i2p-relay> {-fluffypony}** and guzzi ?
**\<anonimal>** guzzi is not here, ...again...
**\<anonimal>** He says he's doing work but I haven't seen a commit or question from him in over 7 weeks, AFAICT.
**\<anonimal>** I think he's trying to separate the contexts from the singleton. At least that's the end goal.
**\<i2p-relay> {-fluffypony}** guzzi: when you read this, please make an effort to attend meetings
**\<i2p-relay> {-fluffypony}** I know you're around at other times, but meetings are important
**\<anonimal>** Yes, please.
**\<anonimal>** Ok, anything else on 2.?
**\<i2p-relay> {-fluffypony}** no
**\<anonimal>** 3. More preparation for [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46) (@fluffypony @danrmiller location status)
**\<anonimal>** Is pigeons still in Africa? This point was moved from last meeting.
**\<i2p-relay> {-pigeons}** i returned yesterday
**\<moneromooo>** Are you suggesting pigeons migrate ?
**\<i2p-relay> {-pigeons}** i saw rock doves
**\<anonimal>** fluffypony? How's it going?
**\<i2p-relay> {-fluffypony}** anonimal: it's a podcast, right?
**\<anonimal>** https://www.96boards.org/openhours/, there are videos too.
**\<i2p-relay> {-fluffypony}** ok well I'm ready whenever
**\<i2p-relay> {-fluffypony}** I don't really prepare for stuff like this
**\<bigreddmachine>** sorry i'm late!
**\<anonimal>** Ok well what time/date works for you?
**\<anonimal>** fluffypony ^
**\<i2p-relay> {-fluffypony}** anonimal: my PA would have to schedule it - probably best to get my PA to schedule myself and pigeons and them
**\<i2p-relay> {-fluffypony}** she's good at that
**\<i2p-relay> {-fluffypony}** it's literally her job :-P
**\<i2p-relay> {-pigeons}** I was thinking ask hyc if he's interested, he's been playing with arm and monero i think
**\<i2p-relay> {-fluffypony}** cool
**\<i2p-relay> {-fluffypony}** hyc is a beautiful man
**\<bigreddmachine>** +1 Ric's PA. She was great when i wanted to schedule a podcast
**\* anonimal** pinged him in #monero-dev
**\<anonimal>** Ok well at this point, IMHO, fluffypony I think it would be good for you to touch base / introduce yourself to sdrobertw in #OpenHours on freenode.
**\<anonimal>** I think I can only play the middleman for so long.
**\<i2p-relay> {-fluffypony}** email is better for Shay, I don't think I can teach her IRC :-P
**\<anonimal>** Contact info? I have none.
**\<i2p-relay> {-fluffypony}** for them?
**\<i2p-relay> {-fluffypony}** didn't we reach out to them via email first?
**\<i2p-relay> {-fluffypony}** \* can't remember
**\<anonimal>** For Shay
**\<anonimal>** No, not via email, all IRC.
**\<i2p-relay> {-fluffypony}** oh lol
**\<i2p-relay> {-fluffypony}** pa@spagni.net
**\<anonimal>** Alright, anything else on this point before moving on?
**\<anonimal>** 4. Status (again) of [Monero HackerOne umbrella and bounty](https://github.com/monero-project/meta/issues/39). [hackerone.com/monero](https://hackerone.com/monero) is online but we need to resolve FFS funding before inviting researchers. VRP status for all projects + bounty status
**\<anonimal>** I've sent a VRP to monero, it's been merged. I believe we're funded at ~500 XMR, which is great.
**\<anonimal>** Any questions?
**\<anonimal>** We just need to launch after submitting VRP to the GUI (and site?)
**\<anonimal>** Sound good?
**\<bigreddmachine>** Is the bounty held in xmr or something else?
**\<anonimal>** Yes. Link to FFS in the meta issue.
**\<ArticMine>** https://forum.getmonero.org/8/funding-required/87597/monero-bounty-for-hackerone It was funded to 500 XMR and then increased to 1000 XMR for further funding
**\<bigreddmachine>** ty
**\<anonimal>** I think we can start now before funding is at 1000.
**\<anonimal>** (it won't mean we'll find researchers immediately anyway)
**\<anonimal>** Any questions/comments before moving onto next point?
**\<i2p-relay> {-fluffypony}** yrah
**\<i2p-relay> {-fluffypony}** agreed
**\<i2p-relay> {-fluffypony}** we can continue to increase it as necessary
**\<anonimal>** Ok. Moving on,
**\<anonimal>** 5. Open forum for https://github.com/monero-project/kovri/issues/630
**\<anonimal>** Comments needed before we move on this.
**\<i2p-relay> {-fluffypony}** I agree with MoroccanMalinois, but I think it's manageable if we set a severity
**\<i2p-relay> {-fluffypony}** and some caveats
**\<moneromooo>** Maybe a strict validity domain definition would do good (ie, "we only accept vulns in the following categories").
**\<moneromooo>** And then expand the list as stuff matures.
**\<bigreddmachine>** moneromooo - why would we restrict?
**\<moneromooo>** To prevent known problems from being reported, or problems in stuff that is known to be unfinished.
**\<i2p-relay> {-pigeons}** because the code has a bunch of legacy mess and is early state with low hanging fruit that is just later on the to fix when that section gets refactored
**\<anonimal>** Yes. So, with that said, I don't know what categories we could even have.
**\<anonimal>** *at this stage*
**\<anonimal>** moneromooo: did you have any ideas on categories for this stage?
**\<moneromooo>** No. I've not really looked at kovri yet, despite saying I would (sorry).
**\<i2p-relay> {-pigeons}** i2p consensus related issues
**\<i2p-relay> {-pigeons}** if we implement like X we might cause incompatibility
**\<i2p-relay> {-pigeons}** maybe those but again maybe those are known and will be fixed when those sections are given love
**\<moneromooo>** Anything which can leak keymat. Good starting point.
**\<moneromooo>** Ideally you'd start giving bounties when you know you've done what you could, and the bounty to find bugs is less than what your time is worth looking at it :)
**\<anonimal>** pigeons: Well, then I think that's java I2P's problem because they would then have to keep up with us. What we could do now though is start with a research-related category for general specifications?
**\<moneromooo>** So it's a bit subjective.
**\<anonimal>** moneromooo: indeed, and this is border-lining on simply hiring a new dev too with the funds available.
**\<moneromooo>** Well, the draw is that the bounty ensures results for the money.
**\<moneromooo>** So expert time.
**\<anonimal>** What if we opened bounty for non-implementation research? I know this is an MRL area though.
**\<anonimal>** Or we could open more categories for implementation but the payout is smaller because code is Alpha?
**\<moneromooo>** For finding bugs in the theory, definitely worth doing so (for monero anyway, I expect kovri's following established research already).
**\<anonimal>** (then they would risk waiting to beta to 0day to get bigger payout?)
**\<rehrar>** what up kids? I'm here.
**\<anonimal>** I think monero's research is more vetted than I2P's, even though I2P has been around longer. Simply because there are less moving parts.
**\<moroccanmalinois>** +1 for bounty for non-implementation research
**\<moneromooo>** Interesting.
**\<anonimal>** Just my opinion. I've read the I2P papers available, I'm not blown away but it's better than nothing.
**\<anonimal>** And not like I'm in a position to drop everything to do purely research so...
**\<anonimal>** We'll add categories for bounty? One obvious one being research. Maybe crypto implementation sooner than later since that's a big one.
**\<anonimal>** Sound fair?
**\<moneromooo>** From a relative outsider, it seems like a sensible start.
**\<bigreddmachine>** yes. is "leaked info" too broad of a category?
**\<moroccanmalinois>** yes for me
**\<anonimal>** Yes because a leak would cover too much code that hasn't been vetted.
**\<anonimal>** \* could cover
**\<anonimal>** Ok, I'll get that going then.
**\<anonimal>** Moving on. 6. Website status (@rehrar @bigreddmachine @alvinjoelsantos @danrmiller)
**\<i2p-relay> {-pigeons}** I need to talk with fluffypony about a potential dns thing
**\<rehrar>** aight, so just in case somebody hasn't seen the Kovri web design here it is: http://imgur.com/a/An8K8
**\<rehrar>** it's the top one
**\<i2p-relay> {-pigeons}** then the demo of ajs' site should be up
**\<i2p-relay> {-fluffypony}** I got msgs about it
**\<i2p-relay> {-fluffypony}** will look at it tomorrow
**\<rehrar>** it's based on the same framework as the getmonero.org website, so once the custom framework is made for one, it is easy to make pages for the other
**\<rehrar>** my update is that we're making the framework even now, and it's coming along well, I should be able to make a few experimental Kovri pages soon
**\<rehrar>** The question is content.
**\<anonimal>** I think the "It's I2P, but in C++" phrase should go; we should use our standard "A secure, private, untraceable C++ implementation of the [I2P anonymous network](https://getmonero.org/knowledge-base/moneropedia/i2p)"
**\<ajs>** I will work with rehrar to write up some content, but need direction on what should be included.
**\<rehrar>** that's fine. Copy is not indicative. :)
**\<bigreddmachine>** My past month has been packed getting ready for my phd comprehensive exam (1 step before the defense). So I haven't looked at the site yet, but talked briefly with ajs about it and plan to get more involved now that that's done.
**\<anonimal>** Other than that, can we move this item to the website meeting in #monero in 10 minutes?
**\<rehrar>** sure, that sounds alright.
**\<moneromooo>** It looks nice (says the cow who's got no clue about design).
**\<ajs>** K
**\<anonimal>** bigreddmachine ajs: will you be around in 10 minutes in #monero?
**\<ajs>** Yes
**\<bigreddmachine>** yeah, i'm also editing tonight's podcast episode so i may take a minute to reply
**\<anonimal>** rehrar: yes, what moneromooo said, looks nice
**\<rehrar>** cool. If people have ideas for content that are not on the demo site
**\<anonimal>** Ok, moving on. 7. @EinMByte ...where is he? Github repo privilege discussion
**\<rehrar>** let me know
**\<rehrar>** I'd like to have a simple website for alpha release :)
**\<anonimal>** fluffypony: so... his last commit was from Septemeber 19th, he's not responded to 99% of my pings since then...
**\<bigreddmachine>** i haven't seen him since i started getting involved in Jan
**\<anonimal>** I speak highly of him and his work, I think he's a great contributor and wish he was around more.
**\<bigreddmachine>** could be a legal issue?
**\<anonimal>** The problem is he's not around anymore, he has assigned issues of which I've had to assign myself since he's not around to do them.
**\<anonimal>** And he has repository push access. If something happened to him and his account is compromised, we could be left in an embarrassing trolling situation where someone deletes the repo.
**\<anonimal>** I don't want to send any wrong signals but I also think access privileges should be on an as-needed basis.
**\<bigreddmachine>** i think that's fair. can always be re-established if he comes back and he can be verified
**\<bigreddmachine>** in that vein, should things like Salti tracking be moved to another place?
**\<anonimal>** I don't know, we'll have to bring that up at the next meeting I think since we're running out of time.
**\<anonimal>** fluffypony: any thoughts about this? Will you remove EinMByte's github push access privileges?
**\<moneromooo>** I think it's fair to revoke for inactivity and failure to reply to pings. Reinstate when back.
**\<bigreddmachine>** okay, can we add #619 to next meeting's agenda?
**\<moneromooo>** I'd also want to remove warptangent's key (unlikely to be back to use it) and a few others.
**\<anonimal>** bigreddmachine: oh, sure I guess, more research/info needed.
**\<bigreddmachine>** k i'll just reply to the issue and talk about it there for now. sorry to jump into other discussion about that.
**\<anonimal>** No problem
**\<anonimal>** Since we're running out of time, 8. Code + ticket discussion / Q & A
**\<bigreddmachine>** last update from me — mozilla work continues with the proxy stuff, but not ready yet. i don't have a good feel for how long
**\<anonimal>** Anything pressing? Questions/comments that can't be answered on github or after the meeting?
**\<anonimal>** Ok, thanks bigreddmachine
**\<rehrar>** not from me, I'll be in contact :(
**\<rehrar>** :)
**\<anonimal>** 9. Any additional meeting items
**\<bigreddmachine>** none. thanks anonimal!
**\<anonimal>** Nothing from me, other than I need to AFK rehrar so, bigreddmachine ajs pigeons if you want to talk more about kovri-site then I'll have to read backlog
**\<rehrar>** aight, thanks.
**\<sgp>** Now over to monero!
**\<ajs>** K
**\<anonimal>** Thank you all if you keep the torch burning for the site, awesome.
**\<anonimal>** 10. Confirm next meeting date/time
**\<anonimal>** 2 weeks, same time?
**\<rehrar>** indeed
**\<anonimal>** Ok. Thanks everyone :)

291
_posts/2017-05-07-overview-and-logs-for-the-dev-meeting-held-on-2017-05-07.md Normal file
View file

@ -0,0 +1,291 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2017-05-07
summary: Sub / disposable addresses, smart mining GUI, 0MQ, and MyMonero-in-tree discussion
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---
*May 7th, 2017*
# Overview
An overview [can be found on MoneroBase](https://monerobase.com/wiki/DevMeeting_2017-05-07).
# Logs
**\<fluffypony>** 1. Greetings
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting
**\<fluffypony>** 3. Code + ticket discussion / Q & A
**\<fluffypony>** 4. MyMonero-in-tree discussion
**\<fluffypony>** 5. Any additional meeting items
**\<fluffypony>** 6. Confirm next meeting date/time
**\<fluffypony>** so let's start with 1. Greetings (aka roll call)
**\<fluffypony>** hi
**\<johnalan>** hi
**\<vtnerd>** present
**\<sgp>** hello!
**\<fluffypony>** tewinget apologises, he'll be late
**\<ajs>** Sup
**\<endogenic>** o/
**\<rehrar>** Yo
**\<fluffypony>** hyc / luigi1111 / ArticMine / othe / smooth / anonimal / binaryFate / dEBRUYNE / dnaleor / gingeropolous / iDunk / IPGlider / Jaquee / jwinterm / kenshi84 / knaccc / luigi1112 / luigi1115 / NoodleDoodle / papalazzarou / pigeons / RedLion[m] / redlion
**\<Jaquee>** hhelo
**\<pigeons>** :)
**\<vtnerd>** also me
**\<Jaquee>** medusa
**\<fluffypony>** anyone I forgot
**\<iDunk>** o/
**\<vtnerd>** oh those are not present whoops
**\<fluffypony>** lol vtnerd
**\<fluffypony>** ok so
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting
**\<fluffypony>** merged a bunch PRs
**\<fluffypony>** kenshi84's GPG key changed
**\<fluffypony>** I've confirmed it via sidechannel
**\<fluffypony>** we have a new sweepbelow function in the CLI, which you may find useful
**\<fluffypony>** we also have a new heavier bias in output selection towards newer outputs
**\<fluffypony>** moneromooo can fill us in on that
**\<ArticMine>** Hi
**\<othe>** oi
**\<fluffypony>** smart mining is enabled in the GUI
**\<fluffypony>** as in the selection box
**\<moneromooo>** Hmm, I just twiddled the settings for the recent output selection, really. To match some data in the Miller et al paper.
**\<fluffypony>** which is pretty cool
**\<sgp>** indeed
**\<fluffypony>** also Jaquee has done some work on getting iOS back on track after it borked (visually)
**\<fluffypony>** well iOS / mobile
**\<fluffypony>** which brings us to
**\<fluffypony>** 3. Code + ticket discussion / Q & A
**\<Jaquee>** yes. and there's some new translations added to gui
**\<fluffypony>** we have a number of open PRs
**\<fluffypony>** when tewinget is off his bus he can update us on 0MQ
**\<fluffypony>** which I'd REALLY like to move forward with ASAP
**\<fluffypony>** it's been sitting in a holding pattern for ages
**\<fluffypony>** Snipa: also if you're around maybe you can update us on the testing on that ?
**\<moneromooo>** I'd like it to be optional, so it can be merged (and thus tested), without causing massive breakage if it does break.
**\<fluffypony>** afaik that was the case
**\<Jaquee>** sounds like a good idea
**\<fluffypony>** also disposable addresses is still hanging around - I think that's pending a review from one of the luigis?
**\<moneromooo>** AFAIK yes. Also RandomRun had an idea to make it better.
**\<fluffypony>** I don't think there's a problem with that hanging around and being improved
**\<fluffypony>** as long as the parallel MRL write-up is there
**\<fluffypony>** I'd like to discuss 1998
**\<fluffypony>** the PR, not the year
**\<fluffypony>** https://github.com/monero-project/monero/pull/1998
**\<fluffypony>** at this point in time I'm still swaying towards prevent-user-stupidity-by-default
**\<fluffypony>** at the slight inconvenience for a power user / sysadmin who might go "omg really" and then add the flag
**\<fluffypony>** I know vtnerd feels the same way, which is why he added it in the first place
**\<fluffypony>** I'd be interested in strong arguments for removing the flag
**\<Jaquee>** wouldnt a text disclaimer be enough?
**\<Jaquee>** i don't have a strong opinion
**\<fluffypony>** Jaquee: if you try bind externally and start it without the --confirm-external-bind flag then it refuses to start
**\<fluffypony>** and it tells you why
**\<Jaquee>** ok. apparently hyc started the discussion. Are you around?
**\<fluffypony>** I know hyc doesn't like it
**\<fluffypony>** vtnerd: has anyone else expressed disdain for it?
**\<vtnerd>** AFAIK, just the people on that PR and the one referenced
**\<vtnerd>** and possibly one person in IRC, but they seemed to be questioning why it was necessary (I think)
**\<vtnerd>** its somewhat low effort to get around it, so most people just add the flag I thnk
**\<vtnerd>** no one has privately contacted me about it for any reason if that was the question
**\<fluffypony>** ok
**\<fluffypony>** unless hyc comes in I move to close the PR, we can always re-open it later
**\<Jaquee>** ok with me
**\<fluffypony>** ok next PR for discussion is 2011
**\<fluffypony>** moneromooo had concerns that it was touching consensus critical issues
**\<fluffypony>** so/issues/part of the code
**\<moneromooo>** Yes, but it turns out it's actually bypassed when a tx comes from a block. The patch is fine.
**\<moneromooo>** I OK'd it since.
**\<fluffypony>** ah ok'
**\<moneromooo>** Well, wait.
**\* fluffypony** stops...hammer time
**\<moneromooo>** It's really uneeded (only the wallet bit was wanted). But it's not forkworthy. That said...
**\<moneromooo>** Older wallets *might* create txes which aren't relayed by newer daemons.
**\<moneromooo>** That's fairly unlikely, since my code targets 2/3 of max size, but the size approximation is not very precise.
**\<moneromooo>** That said, I think it's fine to merge.
**\<hyc>** hey. just popped in. reading history
**\<fluffypony>** hi hyc !
**\<dEBRUYNE>** Re: 2011, perhaps it also should be dependent on the fee priority level used
**\* fluffypony** plays elevator hold music
**\<hyc>** ok, if n0b0dy else cares about that external bind thing then whatever. to me it's redundant
**\<fluffypony>** ok
**\<hyc>** since you had to explicitly request a non-localhost address already
**\<fluffypony>** sure, but you'd be surprised how few people know that 0.0.0.0 exposes everything :-P
**\<endogenic>** ^
**\<hyc>** it d0esn't protect against typos/accidents. it only pisses off people who expect the computer to do as it's told
**\<fluffypony>** hyc: view it like a weak password warning
**\<fluffypony>** you can't just expect the computer to accept 1234 as a password
**\<hyc>** yeah, ok...
**\<moneromooo>** Well, I would...
**\<fluffypony>** lol
**\<fluffypony>** moneromooo is the exception to every rule :-P
**\<fluffypony>** now on the GUI side, the only thing I wanted to bounce around is 688
**\<fluffypony>** tooltips are fine, but if we're going to do some sort of unified help then I would veer towards an overlay that shows once the first time you enter a screen, and can be re-called by clicking the [?] button on the taskbar
**\<fluffypony>** https://s-media-cache-ak0.pinimg.com/originals/c1/e1/bf/c1e1bfd7fb2770f6745d95af8bf89865.jpg
**\<johnalan>** like that style
**\<fluffypony>** https://s-media-cache-ak0.pinimg.com/originals/43/6e/74/436e746b35142f41d5f9bb8e765963e4.jpg
**\<fluffypony>** http://eyeviewportal.com/filecache/b38/73d/85-cropped-w545-h409-of-1-FFFFFF-evappguiguidecontentimage002.jpg
**\<fluffypony>** like that
**\<hyc>** sounds good
**\<johnalan>** :+1:
**\<Jaquee>** problem is [?] is not around if you use native title bar
**\<fluffypony>** Jaquee: where else could we add a help button? bottom left?
**\<endogenic>** one suggestion i'd make for that is to make it c lear to the user they can recall it easily by doing "X" so that they don't fret about having to memorize everything before it's closed
**\<endogenic>** recall it -> the help screen
**\<Jaquee>** i think ^ is good as a start
**\<moneromooo>** Where is it on the title bar then, since it's not a WM thing ?
**\<fluffypony>** endogenic: agreed
**\<moneromooo>** s/Where/Why/
**\<Jaquee>** but some buttons could need longer desriptions
**\<Jaquee>** like sweepunmixable and paymentid for example
**\<fluffypony>** Jaquee: there's enough space in the help overlay, we can use a smaller font to explain them
**\<redlion>** how breadwallet on ios handles it when setting up is quite good
**\<fluffypony>** or move the help to somewhere where there's space
**\<fluffypony>** and use an arrow
**\<Jaquee>** yeah. we could find a place for that help button
**\<fluffypony>** ok - any other PRs that need discussion or can we move on? there's general Q&A shortly
**\<sgp>** I'd like to merge 261 on monero-site
**\<fluffypony>** sgp: there's a website meeting after the Kovri one
**\<fluffypony>** so we can discuss it then
**\<sgp>** ok
**\<fluffypony>** ok so
**\<fluffypony>** 4. MyMonero-in-tree discussion
**\<fluffypony>** so basically this is about nose-covering and making sure I'm not abusing my position as a maintainer and member of the Monero Core Team
**\<fluffypony>** currently MyMonero has a working API (largely unspecced to be sure), two client implementations (website and app), two server implementations (the live backend and OpenMonero), with a third one coming
**\<fluffypony>** I'd like to make sure there is general acceptance and buy-in that the API can be implemented as the general API for lightweight wallets (ie. wallet that use remote viewkey scanning)
**\<hyc>** is it carved in stone now
**\<hyc>** if we need to tweak it we can still do that?
**\<redlion>** is the license unrestricted?
**\<fluffypony>** and that MyMonero-written or MyMonero-derived code is generally acceptable to be merged into the source tree (ie. the open-source backend implementation that vtnerd is working on)
**\<fluffypony>** redlion: BSD 3-clause
**\<fluffypony>** hyc: as long as mWo12 changes it, and we match the changes in the live backend and the new backend then yse
**\<fluffypony>** yes
**\<fluffypony>** we can make any changes, and we WILL make changes to make it smarter
**\<moneromooo>** If it's beneficial to monero and it works fully by itself without needing proprietary gunk, then I'm OK with it.
**\<fluffypony>** eg. tx history comes in raw, instead of paginated
**\<fluffypony>** so that needs to change
**\<hyc>** +1 moneromooo
**\<fluffypony>** moneromooo: yeah the new backend will use LMDB instead of mysql
**\<fluffypony>** so it will be unencumbered in the source
**\<ArticMine>** As long as there are no proprietary dependencies I am fine
**\<hyc>** I like it even more now ;)
**\<johnalan>** I think it beneficial too
**\<moneromooo>** Maybe a separate repo (similar to monero-core) might be best, but that's details.
**\<johnalan>** \*its
**\<moneromooo>** it's
**\<iDunk>** it's
**\<jollymort>** can't wait to run a mymonero node myself!
**\<vtnerd>** also the current "primary" wrapper around the DB is actually C, so theres that for you guys
**\<fluffypony>** moneromooo: I thought about that, but it's a single daemon that *should* exist in the repo alongside the wallet RPC etc.
**\<hyc>** doesn't it supersede wallet-rpc?
**\<fluffypony>** now
**\<fluffypony>** hyc: no
**\<fluffypony>** wallet-rpc is good for integration, this isn't
**\<johnalan>** there is obviously an element of centralisation, but it’s nearly impossible to avoid
**\<fluffypony>** also on this topic
**\<fluffypony>** Jaquee has begun working on client integration in the CLI and GUI
**\<moneromooo>** "client integration" ?
**\<vtnerd>** you mean for light-wallets?
**\<fluffypony>** that will mean that both CLI and GUI will be able to run in lightweight / remote-scanner / MyMonero mode
**\<fluffypony>** moneromooo: as opposed to implementing the server protocol
**\<hyc>** sounds good
**\<moneromooo>** Oh, mymonero client integration ?
**\<fluffypony>** moneromooo: let's call it something else
**\<moneromooo>** That went pretty damn fast :D
**\<fluffypony>** "lightweight wallet"
**\<jollymort>** it's not really centralization if any `monerod` acts as a server
**\<hyc>** but I'm still missing why we need old wallet-rpc if this mymonero api exists
**\<jollymort>** it's literally my monero :)
**\<fluffypony>** hyc: wallet-rpc is completely different
**\<johnalan>** so the core GUI will be able to interact with MyMonero backend too?
**\<vtnerd>** for people that want to run VPS node but keep their viewkey ?
**\<moneromooo>** Yes, would be nice to see what bits are needed where, and the actual API (even if roughly).
**\<fluffypony>** it provides an API for integrators
**\<fluffypony>** @johnalan yes
**\<fluffypony>** so basically
**\<johnalan>** is this needed with the MyMonero Desktop wallet?
**\<ArticMine>** With what as the backed / server
**\<moneromooo>** That can be posted later though, :49 now.
**\<ArticMine>** monerod?
**\<fluffypony>** lightweight wallets will have 3 server options:
**\<fluffypony>** 1. OpenMonero
**\<fluffypony>** 2. the new in-source backend that vtnerd is working on
**\<fluffypony>** 3. the live MyMonero backend
**\<fluffypony>** it will also have multiple client options:
**\<hyc>** afaik the main difference btw an ordinary wallet and mymomero is you tell mymonero your viewkey
**\<fluffypony>** 1. OpenMonero's web wallet (clone of the current MyMonero web wallet)
**\<hyc>** and the ordinary wallet has all your keys
**\<fluffypony>** 2. the MyMonero applications
**\<fluffypony>** 3. monero-wallet-cli
**\<fluffypony>** 4. monero-wallet-rpc
**\<fluffypony>** 5. the Monero GUI
**\<fluffypony>** hyc: monero-wallet-rpc can still use this on the backend
**\<fluffypony>** so it's unrelated
**\<hyc>** ok
**\<ArticMine>** ok
**\<jollymort>** about #2011 - you could modify it to (median)+0.6% for it to be mine-worthy, or even have the wallet check for fee setting and then it would be matched like 1: +0.6%, 2: +2.4%, 3: +12%, 4:+100%
**\<fluffypony>** also this will mean that the GUI / CLI may end up supporting the MyMonero 13-word seed derivation by virtue of the integration effort
**\<fluffypony>** does anyone have a fundamental issue with that ?
**\<ArticMine>** no
**\<fluffypony>** I mean, I do, because I don't want to be abusing my position, but it is what it is :-P
**\<jollymort>** didn't you deprecate 13-word?
**\<moneromooo>** Did you not say the 13 word seed was going to be obsoleted ?
**\<endogenic>** jollymort: working on it
**\<johnalan>** no
**\<endogenic>** but client still needs to be able to read 'em
**\<redlion>** electrum/mycelium support a few different seed lengths iirc
**\<redlion>** works well
**\<jollymort>** also luigi was playing around with an idea for 17-word, integrating creation height in it etc
**\<fluffypony>** moneromooo: it's import only
**\<fluffypony>** not create
**\<endogenic>** https://github.com/mymonero/mymonero-app-js/issues/77
**\<knaccc>** doesn't it put a huge load on mymonero when someone asks it to scan the blockchain from zero with their view key? How long does mymonero take to scan the entire blockchain?
**\<moneromooo>** Anyway, I'm fine with that as presented.
**\<hyc>** that all sounds like a win to me. people have been whining about not being able to import their 13-word seed into regular CLI wallet
**\<shuannelson>** so monero-wallet-cli/monero GUI will not be able to create light-wallets?
**\<fluffypony>** knaccc: yes it does - about 10 minutes
**\<jollymort>** yeah import only sounds lovely
**\<ArticMine>** If we are setting the stage for a competitive market based upon FLOSS then I am fine with it
**\<vtnerd>** I do have the ASM code working, so hopefully that will tighten up some too (altough there is something else blocking that)
**\<fluffypony>** shuannelson: yes they will
**\<fluffypony>** but with 25 word seed, not 13
**\<fluffypony>** we have 7 minutes left - so I'd like to move on to the last item
**\<shuannelson>** awesome!
**\<fluffypony>** we can discuss MyMonero more after the meeting
**\<redlion>** @shaunnelson, I think it's just that the CLI/GUI won't create 13-word seeds, but will accept already created ones
**\<hyc>** yeah sounds fine
**\<fluffypony>** 5. Any additional meeting items
**\<knaccc>** 10 mins is quite a speedup vs downloading the entire blockchain, so sounds awesome.
**\<jollymort>** any thoughts on future of penalty/blocksize? i kind of left the research open-ended
**\<hyc>** ^^ get a faster CPU and it'll be quicker ')
**\<redlion>** Does anyone have a working monero-core or mymonero build on ios currently? I've been fiddling around and I can't seem to get either properly functional on the sim/device, though I may be missing something
**\<fluffypony>** lol hyc
**\<endogenic>** redlion: pls come join #mymonero but yes i do :)
**\<Jaquee>** redlion: i have. it has some nasty bugs but it's running
**\<redlion>** ok thanks, I'll talk to you after this
**\<hyc>** btw iOS still limits process VM size to 4GB so we won't be running monerod native on iOS any time soon
**\<fluffypony>** @jollymort let's discuss it after the meeting, or maybe next week - there are 2 more meetings to go tonight :)
**\<fluffypony>** and that's a large topic
**\<jollymort>** sure, another time
**\<redlion>** thanks jaquee, are there any build instructions or a (sort of) working build posted somewhere?
**\<fluffypony>** 6. Confirm next meeting date/time
**\<fluffypony>** May 21
**\<fluffypony>** day before Consensus
**\<hyc>** cool
**\<hyc>** oh. this week I expect to have wolf miner fully ported to Android, with GPU support too
**\<fluffypony>** endogenic can come to my hotel and we can do the meeting together :-P
**\<endogenic>** oooh
**\<tewinget>** anyway, I have the daemon's side of the code rebased and *nearly* ready to PR and merge. I mean, it could be merged now, but I should clean it up a little/address a few more of the comments on the existing PR first.
**\<tewinget>** the wallet side of things will be based on that, and won't take too long. I just thought it made sense to separate it into two PRs (and rebase while I'm at it because why not?)
**\<fluffypony>** suweet
**\<fluffypony>** just check the meeting logs for the bit from moneromooo about it
**\<tewinget>** (the wallet stuff is still "done already", but as with the daemon side there are comments/suggestions to address as I rebase it as well.)
**\<tewinget>** at any rate, I plan today to finish with the cleanup of the daemon side of things, close the existing PR, and open a new one for the daemon that should be mergeable.
**\<fluffypony>** great stuff
**\<fluffypony>** pigeons: did you see the 96boards thing?
**\<tewinget>** fluffypony: sorry I didn't respond right away to your pinging on the github PR, but when I said it was already rebased I meant on a different branch, as I'm leaving that branch up (and separate) until I finish rebasing.
**\<fluffypony>** ok cool
**\<moneromooo>** tewinget: is the 0MQ stuff deselectable if needed (so if it somehow breaks, you can run the wallet with the existing JSON comms) ?
**\<moneromooo>** wallet/daemon
**\<tewinget>** moneromooo: I'll make it so when I rebase the wallet side of things.
**\<moneromooo>** Excellent, thank you :)