diff --git a/_data/merchants.yml b/_data/merchants.yml index 74237320..0aaf027d 100644 --- a/_data/merchants.yml +++ b/_data/merchants.yml @@ -52,8 +52,8 @@ url: https://github.com/PsychicCat/monero-php - category: Tools merchants: -+ - name: nestorgames -+ url: http://www.nestorgames.com + - name: nestorgames + url: http://www.nestorgames.com - name: ForkGuard Network Monitoring url: http://forkguard.com - name: MoneroBase Price Charts and Tools diff --git a/_posts/2016-09-11-logs-for-the-Kovri-dev-meeting-held-on-2016-09-11.md b/_posts/2016-09-11-logs-for-the-Kovri-dev-meeting-held-on-2016-09-11.md index eeadd6e0..8f03835d 100644 --- a/_posts/2016-09-11-logs-for-the-Kovri-dev-meeting-held-on-2016-09-11.md +++ b/_posts/2016-09-11-logs-for-the-Kovri-dev-meeting-held-on-2016-09-11.md @@ -1,8 +1,8 @@ --- layout: post title: Logs for the Kovri Dev Meeting Held on 2016-09-11 -summary: Brief review of what has been completed since last meeting, Kovri Logo, code & open tickets discussion -tags: [dev diaries, i2p, crypto]** +summary: Kovri Logo, code & open tickets discussion +tags: [dev diaries, i2p, crypto] author: dEBRUYNE / fluffypony --- @@ -10,367 +10,367 @@ author: dEBRUYNE / fluffypony # Logs -**\** anonimal: all yours :) -**\ [anonimal]** 1. Community input for kovri logo https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/entries -**\ [anonimal]** 2. Greetings -**\ [anonimal]** 3. Brief review of what's been completed since the previous meeting -**\ [anonimal]** 4. Code + ticket discussion / Q & A -**\ [anonimal]** 5. Any additional meeting items -**\ [anonimal]** 6. Confirm next meeting date/time -**\ [anonimal]** Everyone quick, before you leave, give your opinion on the logo! -**\ [anonimal]** fluffypony: I think we narrowed it down to #239 and #146 -**\ [anonimal]** Maybe others are of interest? -**\** well, I am checking the bitcoin rcp and they use wordwordword, I think i like word_word_word better -**\** https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/entries/146 -**\** https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/entries/239 -**\** the onion/garlic thing ... I guess it's descriptive, but I can't take it seriously -**\** 146 -**\** hyc: it's coz of Garlic Routing -**\** 88 -**\** for example "getthis" would bedificuld to understund with no "get_this", but i like "getThis" too, I think I got that from javascript -**\** yes, I see that, but ... -**\** MalMen: can you take it to PM with tewinget, or wait till after the Kovri meeting? -**\** MalMen: if you want to discuss that, PM me, otherwise try to wait until the Kovri meeting concludes. -**\ [anonimal]** MalMen, we are in the kovri meeting. Please wait for monero chat until afterward. -**\** dammit fluffypony -**\** lol -**\** lo -**\** please continue :D -**\** I think the stylized Ks are more preofessional -**\** As a designer 146 it also brand recognition with xmr -**\** #146 is more in the spirit of the Monero logo, I'll definitely agree with that -**\** and yeah, the brand recognition aspect is +1 -**\ {-guzzi}** #239 -**\** #146 -**\ [i2p-relay] {-moneromooo}** I kinda like https://images-contests.99static.com/wYofliD7HjSVmkBoYhGS4CyMeNc=/188x0:1464x1276/500x500/top/smart/99designs-contests-attachments/75/75384/attachment_75384769, the variants of https://images-contests.99static.com/Gs4VClupDwKJEGKvaX7I40TLckg=/0x0:1156x1156/500x500/top/smart/99designs-contests- -**\ attachments/75/75381/attachment_75381142 -**\** wait, isn't 99designs basically spec-work? -**\ [i2p-relay] {-ArticMine}** Kovri logo Do we want a variant of the Monero logo or something entirely different? -**\ [anonimal]** But why get washed in with more corporatism? We're at a juncture to break some molds here. -**\** tewinget: yes -**\** eww -**\** on the other hand 239 is catchy... ppl may recognize that... while 146 goes in and goes out of mind -**\* fluffypony** ponders -**\** that said, 146 is nice. -**\** I kinda like 254 / 253 but they're so abstract I dunno what they represent -**\** anonimal: I don't think it's "corporate" per se -**\** "professional" sure -**\** my vote is 236 -**\** i mean 239 -**\ [anonimal]** moneromooo: can you tiny that url? weechat sucks -**\** 239 - ok, that's still understated, I could respect that -**\** my concern is that if we're too playful it eventually ends up like this: https://upload.wikimedia.org/wikipedia/commons/thumb/8/84/Itoopie.svg/2000px-Itoopie.svg.png -**\** :-P -**\** i like the font squarepoint is using -**\ [anonimal]** hyc: 254/253, the person was probably drinking pepsi at the time. -**\** in 25x and 99 -**\** 24{7,8} aren't half bad. -**\** lol. 219 has that Monero tie-in with the garlic -**\** i like #239 but the kerning is awful from a typography perspective -**\ [guzzi]** why the halloween colors anyway? -**\** bear in mind, too, that we can change it later on -**\ [i2p-relay] {-moneromooo}** anonimal: https://paste.fedoraproject.org/426683/14736136/ -**\ [anonimal]** moneromooo: thanks -**\** guzzi: the orange? coz of the Monero logo's colours, I'd guess -**\** 246 is a nice mix of both 146 and 239 imo -**\ [anonimal]** fluffypony: how much *can* we change after we pick one? -**\** anonimal: we can always pay them more to make more changes -**\** we also made changes to the Monero logo after delivery -**\** to fix the kerning -**\ [guzzi]** got it -**\ [i2p-relay] {-moneromooo}** Not sure what numbers these map to, no numbers in the URLs -**\** I like 239 btw -**\** if between 239 and 146 then 239 -**\** wouldnt logo selection work better (more efficiently) by filtering out the ones no one likes -**\** moneromooo: your first link is #239 -**\ [anonimal]** moneromooo: the garlic one was top choice #239, the other one I don't know -**\** and then having an in depth look at a smaller selection -**\** pero: no this is much more fun, the entire dev meeting will be "but I like this logo" :-P -**\ [i2p-relay] {-moneromooo}** THanks :) -**\** in that 223 series, is that a Tau, for Tor? -**\ [anonimal]** moneromooo: I like the mask idea but the artist took the easy way out and just plastered it next to text. -**\** between 146 and 239 for me -**\** 236-237 I have to exclude, there's a Circle-K convenience store chain in California that looks like that -**\** why not make it 146 and just go a different color, it would still feel monero-ish -**\** is this where the meeting for Monero is? -**\** 239 is nice because it bring the "onion" that is easly recognised by tor users -**\** i think keep it simple whilst linking to monero and its a winner 239 is good but if at anypoint the logo is just to be used it is not always instantly recognisable whereas the 146 is -**\** Flyfree10: finished -**\** how did it go? -**\ [anonimal]** hyc: re: tau, that's a bold stretch, I think only you and a few others would have pointed that out -**\ [anonimal]** e.g., artist probably wasn't thinking on that level -**\** Hmm. Wordy I guess. There will be logs from dEBRUYNE, most likely. -**\** I'm gonna go with 239 -**\** Flyfree10: Kovri meeting in-progress, wait a bit and Monero dev meeting minutes will be on reddit I'm sure. -**\** if you think the typography needs to be touched up, cool, but overall it looks classy and it still has the garlic without being over the top -**\** ok -**\ [anonimal]** Alright, I'm seeing a lot of #239 (also my top pick) -**\ [i2p-relay] {-moneromooo}** People are going to be confused between garlic/onion, I'm sure. -**\ [anonimal]** They should be, they are very similar in terms of routing -**\** they are, moneromooo, but I don't think they'll be confused enough to care -**\** it's not like people make privacy decisions based on routing models :-P -**\** yeah i think the garlic just looks confusing. -**\ [anonimal]** So should we do a vote of "anything *not* 239"? -**\** yeah. it's close enough. several of the others leave me wondering WTH they are. -**\<_Slack> ** The one option I'm not seeing is a direct copy of the Monero (M). I did a quick mockup: https://i.imgur.com/8wIh8Hb.png -**\ [anonimal]** Strong opinions on *not* 239? -**\ [i2p-relay] {-moneromooo}** Well... "I use kovri, that's a privacy program for that onion type thing" -**\ [anonimal]** How can we improve #239? -**\** otoh I don't think I've ever heard a non-technical person talk about onion routing, moneromooo -**\** personally i also like 245, the green symbols strong roots -**\** 239 needs a different font and some kerning -**\** we can allways tell "we use garlic instead of union to keep vampires away from the network" -**\** xmr_eric: there were a bunch of those, like hundreds of them, we rejected them in favour of #239 -**\ [i2p-relay] {-ArticMine}** 239 Possible confusion with Tor. Could be dicey from a trademark perspective -**\<_Slack> ** cool -**\ [EinMByte]** #239 looks nice -**\ [EinMByte]** Don't think there would be trademark issues -**\ [anonimal]** medusa_ I like the logo but not so much the colour. -**\** if you took the word kovri from 254 and stuck it into 239 it would look significantly better -**\** ArticMine: I don't know if there's much risk there, since they're just terms that describe the routing (and Tor don't own a trademark on the routing term afaik) -**\** definitely if we were claiming something like that in text -**\ [anonimal]** pero: good point -**\** anonimal at the begining I didnt like the colors of monero too, but grown on me -**\** yeh that's why I don't like 246. the tuft at the top of the logo reminds me too much of the tor onion -**\** 239 isnt horrible, but it definitely doesn't feel like it has a connection to Monero -**\** other than the color, it doesn't really feel like it's closely bound to the Monero project. -**\** agree ferretinjapan -**\ [i2p-relay] {-ArticMine}** There are common law trademarks by "use in commerce" in both cases -**\** If that's intentional then awesome, but otherwise, people may not even connect monero and kovri together as being sister projects. -**\ [i2p-relay] {-moneromooo}** Then... we could superimpose: 239 with added arms on top of the monero M, trying to hide it :D -**\** i think my the minimal pacmans from 88 and 81 arent bad either -**\** anonimal: what are your thoughts on the "connection to Monero" thing - do we want it to be more tightly coupled or not? -**\** then xmr_eric's would be fine -**\ [anonimal]** fluffypony ferretinjapan lurker: if the artists can somehow come up with a better idea other than slapping a big K in the style of monero onto the garlic, then I'm open to new ideas -**\ [guzzi]** fluffypony i agree if there needs to be aconnection to monero that is important to discussion on 239 -**\** or at least a starting point. maybe turn the circle background into the garlic -**\** 139 and 138 too -**\ [guzzi]** anonimal, aggreed on the K statement. -**\** 138 is a more subtle variant of 239 -**\ [anonimal]** Realistically, at kovri's future apex, it will still be an independent router; so I'm not sure why there's so much concern about "connection" -**\** hm, yeah, so subtle I didn't notice it before ;) -**\** a fusing of the two whould be nice -**\* tewinget** (tentatively) casts his vote for 247, or some iteration upon it. -**\** anonimal: I guess because it's like Apache projects, that all fold into the Apache structure / governance etc. -**\ [EinMByte]** the color by itself should be a sufficient connection -**\ [anonimal]** #247 looks so terribly awkward -**\** that's why I liked #246, but maybe it's a bit too plain -**\** 138 reminds me more of saturn's rings than a garlic -**\ [anonimal]** #246: the flaming egg -**\** I'm still going with 239, final answer. -**\** lol -**\** or the tennisball with fuzz on top :) -**\ [i2p-relay] {-ArticMine}** Possibly 251 No onion / garlic -**\** well, If it was to be something completly distinct from monero I would vote 249 -**\ [anonimal]** Let's decide on 1 and see how we can improve it. -**\** I think maybe since there are so many opinions we shelf this for now, make a shortlist of 10 or so, and discuss among just those at a later time. -**\ [anonimal]** I'm voting #239 -**\ [guzzi] we ef have two camps here. use a letter like Monero logo or -- somethinge else00 -**\** we have 8 days to make a decision, tewinget -**\** shrink them down to 16x16 favicons, most of them will look like garbage -**\** tbh I kinda like #239 too -**\** and I think the colour is indeed enough of a connection -**\ [EinMByte]** #239 should do -**\** fluffypony: that later time could be an hour from now, I just figured maybe get to the rest of the Kovri meeting, then circle back. -**\** also we can ALWAYS change it later -**\** hyc except for 135 and 134 -**\** not like we have a branding department to report to -**\** i think tus_99 definitely has the best handle on the design -**\** ok, 135 isn't bad. -**\** and squarepoint the best typography -**\** anonimal: as the CEO of Kovri (kidding) you get to decide, I think you've heard enough opinions, and we'll defer to you -**\ [anonimal]** fluffypony: thank you -**\ [anonimal]** #239 it is *but* we should work out font and see if artist can improve the idea. -**\** absolutely -**\** I'll finalise the 99designs competition in the next couple of days, and give the artist final direction -**\ [anonimal]** Who here had thoughts about kerning, etc.? -**\ [anonimal]** (backlog too big to read) -**\** that was i -**\** pero did -**\ [anonimal]** pero could you give specifics so fluffypony can relay to artist? -**\** sure i'll pm him something in a little bit -**\ [anonimal]** Thanks pero -**\ [anonimal]** fluffypony: will we ever have a one-on-one with tus_99? -**\** I don't think so -**\ [anonimal]** As in, ever speak directly with him? -**\ [anonimal]** Oh -**\** I think we send him direction and then he's like "ok here" and that's it -**\** but we will have the source -**\ [anonimal]** Odd world we live in. -**\** and we can modify it from there -**\ [anonimal]** Ok great -**\ [anonimal]** So, resolved with #239? -**\ [i2p-relay] {-ArticMine} I have to leave now -**\ [anonimal]** Thanks ArticMine -**\ [EinMByte]** anonimal: Yes, let's move on -**\** indeed -**\** rubber stamp of approval and all that -**\ [anonimal]** Sold, to #239! -**\ [anonimal]** Alright next -**\ [anonimal]** 2. Greetings -**\ [anonimal]** 3. Brief review of what's been completed since the previous meeting -**\ [anonimal]** Hi -**\ [anonimal]** (lol) -**\** lol -**\ [EinMByte]** Hi -**\ [guzzi]** hi -**\** EinMByte thanks for taking the time to join the meeting, I know you're busy -**\ [anonimal]** git log --pretty=oneline --since=2weeks --no-merges | wc -l -**\ [anonimal]** 30 -**\ [anonimal]** Fixes, features, improvements. -**\ [anonimal]** Highlights include: -**\ [anonimal]** - The infamous transports "5 - 6 = 18446744073709551615" diffie-hellman keypair supplier bug, now fixed -**\ [anonimal]** - AddressBook fixes/enhancements -**\ [anonimal]** - HTTP fixes/enhancements -**\ [anonimal]** - Clearnet / in-net download impl -**\ [anonimal]** - Coverity resolutions -**\ [anonimal]** - More in log -**\ [anonimal]** Please pipe-in if I missed something we should note -**\ [anonimal]** Oh yes, more NTCP fixes thanks to EinMByte -**\ [anonimal]** And more on the way (not yet merged) -**\ [anonimal]** Anything else on 3.? -**\** i'd like to point out that the Kovri instance that runs i2p-relay -**\** no longer suffers from memory leaks (although they were only occasional before) -**\** thank you for fixing :) -**\ [EinMByte]** There's a few more leaks that need fixing -**\** (that server has 128gb of RAM, so a memory leak is kinda humorous) -**\ [anonimal]** Hard to pin down. One would think they would have checked that 5 - 6 != 0 -**\ [anonimal]** s/they/the mathematical magician/ -**\ [EinMByte]** fluffypony: Please tell us when you see inbound NTCP happening :) -**\ [anonimal]** EinMByte that'll probably never happen until we fix it, lol -**\** will do lol -**\ [EinMByte]** If we even need to fix it -**\ [anonimal]** Something needs fixed somewhere -**\ [EinMByte]** Probably, yes -**\ [anonimal]** 4. Code + ticket discussion / Q & A -**\ [anonimal]** So latest hot topic was release planning for 33C3 -**\ [EinMByte]** Is that done? Wiki still looks empty -**\ [anonimal]** I'd rather not repeat the tons of work EinMByte and I have done this week. If anyone is interested they can start idling #kovri-dev -**\** whoop whoop -**\ [anonimal]** No, wiki not done -**\ [anonimal]** I've sorted out open issues, -**\ [anonimal]** will open a few more directly related to first release, -**\ [anonimal]** will do more roadmap work once release cycle is codified, -**\** and now that we're closer to logo I can get back on the website / email bandwagon -**\ [anonimal]** we sill need a solid answer on CI -**\** anonimal: which CI question? -**\ [anonimal]** Mr. build bot, the devops guy who was supposed to be at the monero meeting today -**\** hello -**\ [anonimal]** Maybe I missed the discussion, I don't know -**\** pigeons it is :D -**\ [anonimal]** Hi pigeons -**\** oh -**\** lol -**\** anonimal sorry, it was at the beginning of the Monero meeting -**\ [anonimal]** My fault then, I came in late -**\ [anonimal]** When are we throwing out travis? -**\** Hi. Im just getting everything started, but feel free to chat with me anytime and ill show you what were doing and yuo can tellme about the needs -**\** anonimal: we'll probably break the chassis on Monero first -**\** and setup IRC hooks etc. -**\** and then adding Kovri will be a snap -**\ [anonimal]** Awesome and awesome, thanks pigeons and fluffypony -**\** luckiy buildbot irc hooks are vey automactice and easy -**\** hashtag excite -**\ [anonimal]** Ok great, so we'll keep in touch then overtime. -**\** cool. -**\ [anonimal]** Next issue, fluffypony did you want me to bring-up/add something to the agenda? -**\ [anonimal]** fluffypony: was it for website or email or both? -**\** anonimal: both -**\** can't think of anything else -**\** re: 33C3 I'll be putting a post up on the forum in the next little while so everyone knows what's potting -**\ * anonimal checking issues -**\ [anonimal]** Ok, they've been milestone'd -**\** awesomesauce -**\** when shall we three meeting again? (to quote Macbeth) -**\ [anonimal]** Alright, open issues should be organized enough / milestone'd where appropriate -**\ [anonimal]** Anything else on 4.? -**\ [anonimal]** (4. Code + ticket discussion / Q & A) -**\** nothing from my side -**\ [EinMByte]** So what I'm currently working (of the milestoned issues): #191, #312, #342 -**\ [guzzi] i will keep working on coverety isues -**\ [EinMByte]** Will do #213 later -**\ [EinMByte]** For the memory leaks (and other memory problems): the ntcp branch has a couple of fixes -**\ [EinMByte]** Currently working on a (partial) fix of #342 -**\ [anonimal]** You're not assigned to #342, I can add you unless you wanted to add yourself -**\ [EinMByte]** I'll assign -**\ [anonimal]** https://github.com/monero-project/kovri/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.1.0-alpha+assignee%3AEinMByte -**\ [anonimal]** Ok -**\ [EinMByte]** So to be clear, the backtrace you posted 4 hours ago is what I fixed -**\ [EinMByte]** (but not yet pushed because unforseen issues) -**\ [anonimal]** I posted two. I imagine you're talking about the NTCP one -**\ [EinMByte]** Yes -**\ [EinMByte]** Won't touch the client issue for now -**\ [anonimal]** Yay client -**\ [anonimal]** https://github.com/monero-project/kovri/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.1.0-alpha+assignee%3Aanonimal -**\ [anonimal]** That covers a small fraction of what I'll end up fixing / working on -**\ [EinMByte]** For #187 (NTCP core issues), the main thing left to fix is the inbound NTCP -**\ [anonimal]** I just don't assign myself in case someone else wants to grab something -**\ [anonimal]** EinMByte: yeah, running tcpdump against kovri --log-to-console 0 --v6 1 --enable-ssu 0 -**\ * anonimal pasting -**\ [EinMByte]** Yes, and I'd ask everyone else wanting to help out to do the same -**\ [anonimal]** 19:42:20.974119 IP6 2001:0:9d38:6ab8:2c92:2e09:b8ee:e2d.59823 > me.11552: Flags [S], seq 1067814148, win 8192, options [mss 1220,nop,wscale 8,nop,nop,sackOK], length 0 -**\ [anonimal]** 19:42:28.017709 IP6 2001:0:9d38:6ab8:2c92:2e09:b8ee:e2d.59823 > me.11552: Flags [S], seq 1067814148, win 8192, options [mss 1220,nop,nop,sackOK], length 0 -**\ [EinMByte]** guzzi: Try this if you get bored with coverity issues -**\ [anonimal]** Let's take mroe NTCP chat outside of the meeting since this is being logged -**\ [EinMByte]** (--v6 not necessary, just see if you get inbound traffic, and paste logs when you do) -**\ [anonimal]** *more -**\ [anonimal]** Yes, I know, just happens to be the instance that is running -**\ [EinMByte]** ok -**\ [anonimal]** guzzi any questions about tickets, etc.? -**\ [anonimal]** I'll be around after meeting, moving on. -**\ [anonimal]** 5. Any additional meeting items -**\ [guzzi]** no you have given me good tips lately -**\ [guzzi]** i appreciate it. -**\ [anonimal]** Ok good, glad to help. -**\** that's it from me -**\ [anonimal]** Glad to have you onboard. -**\ [anonimal]** Nothing from me on 5. -**\ [anonimal]** Last call for 5. -**\** going once, going twice, sold! -**\ [anonimal]** 6. Confirm next meeting date/time -**\ [EinMByte]** What about the website, though? -**\ * anonimal backtracks to 5. -**\ [EinMByte]** (or did I just miss that) -**\ [anonimal]** fluffypony: do you have any details yet? -**\** EinMByte: I said that now that we're wrapping up the logo I can get back on the bandwagon with that -**\ [anonimal]** And it *will* be online by first release fluffypony, yes? -**\** absolutely -**\ [EinMByte]** Well, it was supposed to be done by today -**\ [anonimal]** lol, EinMByte cracking the whip -**\ [EinMByte]** So, what's the real deadline? -**\** oh - there must've been a miscommunication; when we decided on the logo finalists I said I was shelving it till we'd completed the logo decision -**\ [anonimal]** I think deadline should be at the very least a week before 33C3. -**\** anonimal: long before then -**\** we're keeping it simple initially, remember -**\ [anonimal]** As long as it works and doesn't look terrible, I'm happy. -**\ [anonimal]** Should we make a concrete date for website like we are for kovri release? -**\** let's see where we get before the next meeting and re-address it then -**\ [EinMByte]** ok -**\ [EinMByte]** Let's put that on the roadmap -**\ [anonimal]** One thing for 5., -**\ [anonimal]** questioning if we should move build instructions to wiki -**\ [anonimal]** (github wiki) -**\ [anonimal]** A) easier, doesn't pollute git log B) makes us reliant on github -**\ [anonimal]** A good, B bad. -**\ [anonimal]** Any thoughts? or we can move this to next meeting -**\** I think that's a bad idea -**\** if someone clones the repo they should have everything they need right there -**\ [anonimal]** But if they don't have network connectivity, kovri is useless -**\ [EinMByte]** I tend to agree with fluffypony -**\ [anonimal]** And if they can clone from github, they have access to the website -**\** anonimal: what if Github blocks Tor access after they've cloned it? -**\ [anonimal]** And if they have access to either, they can read build instructions. -**\** not everyone will be able to checkout an old commit to get build instructions -**\ [EinMByte]** There could be a tutorial of some sort in the wiki -**\ [EinMByte]** But basic build instructions should be in the repo -**\ [anonimal]** Alright, no arguments from me, just questioning -**\ [anonimal]** Anything else on 5.? -**\ [anonimal]** We're out of time -**\ [anonimal]** 6. Confirm next meeting date/time -**\ [anonimal]** 2 weeks from now, works best I think. -**\** 2 weeks from now plz -**\ [anonimal]** Ok, sept. 25th, same time -**\** ok -**\ [EinMByte]** ok -**\ [anonimal]** Thanks everyone. Thanks #monero-dev for the logo input too +**\** anonimal: all yours :) +**\ [anonimal]** 1. Community input for kovri logo https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/entries +**\ [anonimal]** 2. Greetings +**\ [anonimal]** 3. Brief review of what's been completed since the previous meeting +**\ [anonimal]** 4. Code + ticket discussion / Q & A +**\ [anonimal]** 5. Any additional meeting items +**\ [anonimal]** 6. Confirm next meeting date/time +**\ [anonimal]** Everyone quick, before you leave, give your opinion on the logo! +**\ [anonimal]** fluffypony: I think we narrowed it down to #239 and #146 +**\ [anonimal]** Maybe others are of interest? +**\** well, I am checking the bitcoin rcp and they use wordwordword, I think i like word_word_word better +**\** https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/entries/146 +**\** https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/entries/239 +**\** the onion/garlic thing ... I guess it's descriptive, but I can't take it seriously +**\** 146 +**\** hyc: it's coz of Garlic Routing +**\** 88 +**\** for example "getthis" would bedificuld to understund with no "get\_this", but i like "getThis" too, I think I got that from javascript +**\** yes, I see that, but ... +**\** MalMen: can you take it to PM with tewinget, or wait till after the Kovri meeting? +**\** MalMen: if you want to discuss that, PM me, otherwise try to wait until the Kovri meeting concludes. +**\ [anonimal]** MalMen, we are in the kovri meeting. Please wait for monero chat until afterward. +**\** dammit fluffypony +**\** lol +**\** lo +**\** please continue :D +**\** I think the stylized Ks are more preofessional +**\** As a designer 146 it also brand recognition with xmr +**\** #146 is more in the spirit of the Monero logo, I'll definitely agree with that +**\** and yeah, the brand recognition aspect is +1 +**\ {-guzzi}** #239 +**\** #146 +**\ [i2p-relay] {-moneromooo}** I kinda like https://images-contests.99static.com/wYofliD7HjSVmkBoYhGS4CyMeNc=/188x0:1464x1276/500x500/top/smart/99designs-contests-attachments/75/75384/attachment\_75384769, the variants of https://images-contests.99static.com/Gs4VClupDwKJEGKvaX7I40TLckg=/0x0:1156x1156/500x500/top/smart/99designs-contests- +**\** attachments/75/75381/attachment\_75381142 +**\** wait, isn't 99designs basically spec-work? +**\ [i2p-relay] {-ArticMine}** Kovri logo Do we want a variant of the Monero logo or something entirely different? +**\ [anonimal]** But why get washed in with more corporatism? We're at a juncture to break some molds here. +**\** tewinget: yes +**\** eww +**\** on the other hand 239 is catchy... ppl may recognize that... while 146 goes in and goes out of mind +**\* fluffypony** ponders +**\** that said, 146 is nice. +**\** I kinda like 254 / 253 but they're so abstract I dunno what they represent +**\** anonimal: I don't think it's "corporate" per se +**\** "professional" sure +**\** my vote is 236 +**\** i mean 239 +**\ [anonimal]** moneromooo: can you tiny that url? weechat sucks +**\** 239 - ok, that's still understated, I could respect that +**\** my concern is that if we're too playful it eventually ends up like this: https://upload.wikimedia.org/wikipedia/commons/thumb/8/84/Itoopie.svg/2000px-Itoopie.svg.png +**\** :-P +**\** i like the font squarepoint is using +**\ [anonimal]** hyc: 254/253, the person was probably drinking pepsi at the time. +**\** in 25x and 99 +**\** 24{7,8} aren't half bad. +**\** lol. 219 has that Monero tie-in with the garlic +**\** i like #239 but the kerning is awful from a typography perspective +**\ [guzzi]** why the halloween colors anyway? +**\** bear in mind, too, that we can change it later on +**\ [i2p-relay] {-moneromooo}** anonimal: https://paste.fedoraproject.org/426683/14736136/ +**\ [anonimal]** moneromooo: thanks +**\** guzzi: the orange? coz of the Monero logo's colours, I'd guess +**\** 246 is a nice mix of both 146 and 239 imo +**\ [anonimal]** fluffypony: how much *can* we change after we pick one? +**\** anonimal: we can always pay them more to make more changes +**\** we also made changes to the Monero logo after delivery +**\** to fix the kerning +**\ [guzzi]** got it +**\ [i2p-relay] {-moneromooo}** Not sure what numbers these map to, no numbers in the URLs +**\** I like 239 btw +**\** if between 239 and 146 then 239 +**\** wouldnt logo selection work better (more efficiently) by filtering out the ones no one likes +**\** moneromooo: your first link is #239 +**\ [anonimal]** moneromooo: the garlic one was top choice #239, the other one I don't know +**\** and then having an in depth look at a smaller selection +**\** pero: no this is much more fun, the entire dev meeting will be "but I like this logo" :-P +**\ [i2p-relay] {-moneromooo}** THanks :) +**\** in that 223 series, is that a Tau, for Tor? +**\ [anonimal]** moneromooo: I like the mask idea but the artist took the easy way out and just plastered it next to text. +**\** between 146 and 239 for me +**\** 236-237 I have to exclude, there's a Circle-K convenience store chain in California that looks like that +**\** why not make it 146 and just go a different color, it would still feel monero-ish +**\** is this where the meeting for Monero is? +**\** 239 is nice because it bring the "onion" that is easly recognised by tor users +**\** i think keep it simple whilst linking to monero and its a winner 239 is good but if at anypoint the logo is just to be used it is not always instantly recognisable whereas the 146 is +**\** Flyfree10: finished +**\** how did it go? +**\ [anonimal]** hyc: re: tau, that's a bold stretch, I think only you and a few others would have pointed that out +**\ [anonimal]** e.g., artist probably wasn't thinking on that level +**\** Hmm. Wordy I guess. There will be logs from dEBRUYNE, most likely. +**\** I'm gonna go with 239 +**\** Flyfree10: Kovri meeting in-progress, wait a bit and Monero dev meeting minutes will be on reddit I'm sure. +**\** if you think the typography needs to be touched up, cool, but overall it looks classy and it still has the garlic without being over the top +**\** ok +**\ [anonimal]** Alright, I'm seeing a lot of #239 (also my top pick) +**\ [i2p-relay] {-moneromooo}** People are going to be confused between garlic/onion, I'm sure. +**\ [anonimal]** They should be, they are very similar in terms of routing +**\** they are, moneromooo, but I don't think they'll be confused enough to care +**\** it's not like people make privacy decisions based on routing models :-P +**\** yeah i think the garlic just looks confusing. +**\ [anonimal]** So should we do a vote of "anything \*not* 239"? +**\** yeah. it's close enough. several of the others leave me wondering WTH they are. +**\<\_Slack> ** The one option I'm not seeing is a direct copy of the Monero (M). I did a quick mockup: https://i.imgur.com/8wIh8Hb.png +**\ [anonimal]** Strong opinions on \*not* 239? +**\ [i2p-relay] {-moneromooo}** Well... "I use kovri, that's a privacy program for that onion type thing" +**\ [anonimal]** How can we improve #239? +**\** otoh I don't think I've ever heard a non-technical person talk about onion routing, moneromooo +**\** personally i also like 245, the green symbols strong roots +**\** 239 needs a different font and some kerning +**\** we can allways tell "we use garlic instead of union to keep vampires away from the network" +**\** xmr\_eric: there were a bunch of those, like hundreds of them, we rejected them in favour of #239 +**\ [i2p-relay] {-ArticMine}** 239 Possible confusion with Tor. Could be dicey from a trademark perspective +**\<\_Slack> ** cool +**\ [EinMByte]** #239 looks nice +**\ [EinMByte]** Don't think there would be trademark issues +**\ [anonimal]** medusa_ I like the logo but not so much the colour. +**\** if you took the word kovri from 254 and stuck it into 239 it would look significantly better +**\** ArticMine: I don't know if there's much risk there, since they're just terms that describe the routing (and Tor don't own a trademark on the routing term afaik) +**\** definitely if we were claiming something like that in text +**\ [anonimal]** pero: good point +**\** anonimal at the begining I didnt like the colors of monero too, but grown on me +**\** yeh that's why I don't like 246. the tuft at the top of the logo reminds me too much of the tor onion +**\** 239 isnt horrible, but it definitely doesn't feel like it has a connection to Monero +**\** other than the color, it doesn't really feel like it's closely bound to the Monero project. +**\** agree ferretinjapan +**\ [i2p-relay] {-ArticMine}** There are common law trademarks by "use in commerce" in both cases +**\** If that's intentional then awesome, but otherwise, people may not even connect monero and kovri together as being sister projects. +**\ [i2p-relay] {-moneromooo}** Then... we could superimpose: 239 with added arms on top of the monero M, trying to hide it :D +**\** i think my the minimal pacmans from 88 and 81 arent bad either +**\** anonimal: what are your thoughts on the "connection to Monero" thing - do we want it to be more tightly coupled or not? +**\** then xmr\_eric's would be fine +**\ [anonimal]** fluffypony ferretinjapan lurker: if the artists can somehow come up with a better idea other than slapping a big K in the style of monero onto the garlic, then I'm open to new ideas +**\ [guzzi]** fluffypony i agree if there needs to be aconnection to monero that is important to discussion on 239 +**\** or at least a starting point. maybe turn the circle background into the garlic +**\** 139 and 138 too +**\ [guzzi]** anonimal, aggreed on the K statement. +**\** 138 is a more subtle variant of 239 +**\ [anonimal]** Realistically, at kovri's future apex, it will still be an independent router; so I'm not sure why there's so much concern about "connection" +**\** hm, yeah, so subtle I didn't notice it before ;) +**\** a fusing of the two whould be nice +**\* tewinget** (tentatively) casts his vote for 247, or some iteration upon it. +**\** anonimal: I guess because it's like Apache projects, that all fold into the Apache structure / governance etc. +**\ [EinMByte]** the color by itself should be a sufficient connection +**\ [anonimal]** #247 looks so terribly awkward +**\** that's why I liked #246, but maybe it's a bit too plain +**\** 138 reminds me more of saturn's rings than a garlic +**\ [anonimal]** #246: the flaming egg +**\** I'm still going with 239, final answer. +**\** lol +**\** or the tennisball with fuzz on top :) +**\ [i2p-relay] {-ArticMine}** Possibly 251 No onion / garlic +**\** well, If it was to be something completly distinct from monero I would vote 249 +**\ [anonimal]** Let's decide on 1 and see how we can improve it. +**\** I think maybe since there are so many opinions we shelf this for now, make a shortlist of 10 or so, and discuss among just those at a later time. +**\ [anonimal]** I'm voting #239 +**\ [guzzi]** we ef have two camps here. use a letter like Monero logo or -- somethinge else00 +**\** we have 8 days to make a decision, tewinget +**\** shrink them down to 16x16 favicons, most of them will look like garbage +**\** tbh I kinda like #239 too +**\** and I think the colour is indeed enough of a connection +**\ [EinMByte]** #239 should do +**\** fluffypony: that later time could be an hour from now, I just figured maybe get to the rest of the Kovri meeting, then circle back. +**\** also we can ALWAYS change it later +**\** hyc except for 135 and 134 +**\** not like we have a branding department to report to +**\** i think tus\_99 definitely has the best handle on the design +**\** ok, 135 isn't bad. +**\** and squarepoint the best typography +**\** anonimal: as the CEO of Kovri (kidding) you get to decide, I think you've heard enough opinions, and we'll defer to you +**\ [anonimal]** fluffypony: thank you +**\ [anonimal]** #239 it is \*but* we should work out font and see if artist can improve the idea. +**\** absolutely +**\** I'll finalise the 99designs competition in the next couple of days, and give the artist final direction +**\ [anonimal]** Who here had thoughts about kerning, etc.? +**\ [anonimal]** (backlog too big to read) +**\** that was i +**\** pero did +**\ [anonimal]** pero could you give specifics so fluffypony can relay to artist? +**\** sure i'll pm him something in a little bit +**\ [anonimal]** Thanks pero +**\ [anonimal]** fluffypony: will we ever have a one-on-one with tus_99? +**\** I don't think so +**\ [anonimal]** As in, ever speak directly with him? +**\ [anonimal]** Oh +**\** I think we send him direction and then he's like "ok here" and that's it +**\** but we will have the source +**\ [anonimal]** Odd world we live in. +**\** and we can modify it from there +**\ [anonimal]** Ok great +**\ [anonimal]** So, resolved with #239? +**\ [i2p-relay] {-ArticMine}** I have to leave now +**\ [anonimal]** Thanks ArticMine +**\ [EinMByte]** anonimal: Yes, let's move on +**\** indeed +**\** rubber stamp of approval and all that +**\ [anonimal]** Sold, to #239! +**\ [anonimal]** Alright next +**\ [anonimal]** 2. Greetings +**\ [anonimal]** 3. Brief review of what's been completed since the previous meeting +**\ [anonimal]** Hi +**\ [anonimal]** (lol) +**\** lol +**\ [EinMByte]** Hi +**\ [guzzi]** hi +**\** EinMByte thanks for taking the time to join the meeting, I know you're busy +**\ [anonimal]** git log --pretty=oneline --since=2weeks --no-merges | wc -l +**\ [anonimal]** 30 +**\ [anonimal]** Fixes, features, improvements. +**\ [anonimal]** Highlights include: +**\ [anonimal]** - The infamous transports "5 - 6 = 18446744073709551615" diffie-hellman keypair supplier bug, now fixed +**\ [anonimal]** - AddressBook fixes/enhancements +**\ [anonimal]** - HTTP fixes/enhancements +**\ [anonimal]** - Clearnet / in-net download impl +**\ [anonimal]** - Coverity resolutions +**\ [anonimal]** - More in log +**\ [anonimal]** Please pipe-in if I missed something we should note +**\ [anonimal]** Oh yes, more NTCP fixes thanks to EinMByte +**\ [anonimal]** And more on the way (not yet merged) +**\ [anonimal]** Anything else on 3.? +**\** i'd like to point out that the Kovri instance that runs i2p-relay +**\** no longer suffers from memory leaks (although they were only occasional before) +**\** thank you for fixing :) +**\ [EinMByte]** There's a few more leaks that need fixing +**\** (that server has 128gb of RAM, so a memory leak is kinda humorous) +**\ [anonimal]** Hard to pin down. One would think they would have checked that 5 - 6 != 0 +**\ [anonimal]** s/they/the mathematical magician/ +**\ [EinMByte]** fluffypony: Please tell us when you see inbound NTCP happening :) +**\ [anonimal]** EinMByte that'll probably never happen until we fix it, lol +**\** will do lol +**\ [EinMByte]** If we even need to fix it +**\ [anonimal]** Something needs fixed somewhere +**\ [EinMByte]** Probably, yes +**\ [anonimal]** 4. Code + ticket discussion / Q & A +**\ [anonimal]** So latest hot topic was release planning for 33C3 +**\ [EinMByte]** Is that done? Wiki still looks empty +**\ [anonimal]** I'd rather not repeat the tons of work EinMByte and I have done this week. If anyone is interested they can start idling #kovri-dev +**\** whoop whoop +**\ [anonimal]** No, wiki not done +**\ [anonimal]** I've sorted out open issues, +**\ [anonimal]** will open a few more directly related to first release, +**\ [anonimal]** will do more roadmap work once release cycle is codified, +**\** and now that we're closer to logo I can get back on the website / email bandwagon +**\ [anonimal]** we sill need a solid answer on CI +**\** anonimal: which CI question? +**\ [anonimal]** Mr. build bot, the devops guy who was supposed to be at the monero meeting today +**\** hello +**\ [anonimal]** Maybe I missed the discussion, I don't know +**\** pigeons it is :D +**\ [anonimal]** Hi pigeons +**\** oh +**\** lol +**\** anonimal sorry, it was at the beginning of the Monero meeting +**\ [anonimal]** My fault then, I came in late +**\ [anonimal]** When are we throwing out travis? +**\** Hi. Im just getting everything started, but feel free to chat with me anytime and ill show you what were doing and yuo can tellme about the needs +**\** anonimal: we'll probably break the chassis on Monero first +**\** and setup IRC hooks etc. +**\** and then adding Kovri will be a snap +**\ [anonimal]** Awesome and awesome, thanks pigeons and fluffypony +**\** luckiy buildbot irc hooks are vey automactice and easy +**\** hashtag excite +**\ [anonimal]** Ok great, so we'll keep in touch then overtime. +**\** cool. +**\ [anonimal]** Next issue, fluffypony did you want me to bring-up/add something to the agenda? +**\ [anonimal]** fluffypony: was it for website or email or both? +**\** anonimal: both +**\** can't think of anything else +**\** re: 33C3 I'll be putting a post up on the forum in the next little while so everyone knows what's potting +**\** anonimal checking issues +**\ [anonimal]** Ok, they've been milestone'd +**\** awesomesauce +**\** when shall we three meeting again? (to quote Macbeth) +**\ [anonimal]** Alright, open issues should be organized enough / milestone'd where appropriate +**\ [anonimal]** Anything else on 4.? +**\ [anonimal]** (4. Code + ticket discussion / Q & A) +**\** nothing from my side +**\ [EinMByte]** So what I'm currently working (of the milestoned issues): #191, #312, #342 +**\** [guzzi] i will keep working on coverety isues +**\ [EinMByte]** Will do #213 later +**\ [EinMByte]** For the memory leaks (and other memory problems): the ntcp branch has a couple of fixes +**\ [EinMByte]** Currently working on a (partial) fix of #342 +**\ [anonimal]** You're not assigned to #342, I can add you unless you wanted to add yourself +**\ [EinMByte]** I'll assign +**\ [anonimal]** https://github.com/monero-project/kovri/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.1.0-alpha+assignee%3AEinMByte +**\ [anonimal]** Ok +**\ [EinMByte]** So to be clear, the backtrace you posted 4 hours ago is what I fixed +**\ [EinMByte]** (but not yet pushed because unforseen issues) +**\ [anonimal]** I posted two. I imagine you're talking about the NTCP one +**\ [EinMByte]** Yes +**\ [EinMByte]** Won't touch the client issue for now +**\ [anonimal]** Yay client +**\ [anonimal]** https://github.com/monero-project/kovri/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.1.0-alpha+assignee%3Aanonimal +**\ [anonimal]** That covers a small fraction of what I'll end up fixing / working on +**\ [EinMByte]** For #187 (NTCP core issues), the main thing left to fix is the inbound NTCP +**\ [anonimal]** I just don't assign myself in case someone else wants to grab something +**\ [anonimal]** EinMByte: yeah, running tcpdump against kovri --log-to-console 0 --v6 1 --enable-ssu 0 +**\** \* anonimal pasting +**\ [EinMByte]** Yes, and I'd ask everyone else wanting to help out to do the same +**\ [anonimal]** 19:42:20.974119 IP6 2001:0:9d38:6ab8:2c92:2e09:b8ee:e2d.59823 > me.11552: Flags [S], seq 1067814148, win 8192, options [mss 1220,nop,wscale 8,nop,nop,sackOK], length 0 +**\ [anonimal]** 19:42:28.017709 IP6 2001:0:9d38:6ab8:2c92:2e09:b8ee:e2d.59823 > me.11552: Flags [S], seq 1067814148, win 8192, options [mss 1220,nop,nop,sackOK], length 0 +**\ [EinMByte]** guzzi: Try this if you get bored with coverity issues +**\ [anonimal]** Let's take mroe NTCP chat outside of the meeting since this is being logged +**\ [EinMByte]** (--v6 not necessary, just see if you get inbound traffic, and paste logs when you do) +**\ [anonimal]** \*more +**\ [anonimal]** Yes, I know, just happens to be the instance that is running +**\ [EinMByte]** ok +**\ [anonimal]** guzzi any questions about tickets, etc.? +**\ [anonimal]** I'll be around after meeting, moving on. +**\ [anonimal]** 5. Any additional meeting items +**\ [guzzi]** no you have given me good tips lately +**\ [guzzi]** i appreciate it. +**\ [anonimal]** Ok good, glad to help. +**\** that's it from me +**\ [anonimal]** Glad to have you onboard. +**\ [anonimal]** Nothing from me on 5. +**\ [anonimal]** Last call for 5. +**\** going once, going twice, sold! +**\ [anonimal]** 6. Confirm next meeting date/time +**\ [EinMByte]** What about the website, though? +**\** * anonimal backtracks to 5. +**\ [EinMByte]** (or did I just miss that) +**\ [anonimal]** fluffypony: do you have any details yet? +**\** EinMByte: I said that now that we're wrapping up the logo I can get back on the bandwagon with that +**\ [anonimal]** And it \*will\* be online by first release fluffypony, yes? +**\** absolutely +**\ [EinMByte]** Well, it was supposed to be done by today +**\ [anonimal]** lol, EinMByte cracking the whip +**\ [EinMByte]** So, what's the real deadline? +**\** oh - there must've been a miscommunication; when we decided on the logo finalists I said I was shelving it till we'd completed the logo decision +**\ [anonimal]** I think deadline should be at the very least a week before 33C3. +**\** anonimal: long before then +**\** we're keeping it simple initially, remember +**\ [anonimal]** As long as it works and doesn't look terrible, I'm happy. +**\ [anonimal]** Should we make a concrete date for website like we are for kovri release? +**\** let's see where we get before the next meeting and re-address it then +**\ [EinMByte]** ok +**\ [EinMByte]** Let's put that on the roadmap +**\ [anonimal]** One thing for 5., +**\ [anonimal]** questioning if we should move build instructions to wiki +**\ [anonimal]** (github wiki) +**\ [anonimal]** A) easier, doesn't pollute git log B) makes us reliant on github +**\ [anonimal]** A good, B bad. +**\ [anonimal]** Any thoughts? or we can move this to next meeting +**\** I think that's a bad idea +**\** if someone clones the repo they should have everything they need right there +**\ [anonimal]** But if they don't have network connectivity, kovri is useless +**\ [EinMByte]** I tend to agree with fluffypony +**\ [anonimal]** And if they can clone from github, they have access to the website +**\** anonimal: what if Github blocks Tor access after they've cloned it? +**\ [anonimal]** And if they have access to either, they can read build instructions. +**\** not everyone will be able to checkout an old commit to get build instructions +**\ [EinMByte]** There could be a tutorial of some sort in the wiki +**\ [EinMByte]** But basic build instructions should be in the repo +**\ [anonimal]** Alright, no arguments from me, just questioning +**\ [anonimal]** Anything else on 5.? +**\ [anonimal]** We're out of time +**\ [anonimal]** 6. Confirm next meeting date/time +**\ [anonimal]** 2 weeks from now, works best I think. +**\** 2 weeks from now plz +**\ [anonimal]** Ok, sept. 25th, same time +**\** ok +**\ [EinMByte]** ok +**\ [anonimal]** Thanks everyone. Thanks #monero-dev for the logo input too **\ [guzzi]** ok \ No newline at end of file diff --git a/_posts/2016-09-11-overview-and-logs-for-the-dev-meeting-held-on-2016-09-11.md b/_posts/2016-09-11-overview-and-logs-for-the-dev-meeting-held-on-2016-09-11.md index cc7d995e..1fc914c3 100644 --- a/_posts/2016-09-11-overview-and-logs-for-the-dev-meeting-held-on-2016-09-11.md +++ b/_posts/2016-09-11-overview-and-logs-for-the-dev-meeting-held-on-2016-09-11.md @@ -10,296 +10,296 @@ author: dEBRUYNE / fluffypony # Logs -**\** Hi all -**\** I'm on my phone -**\** Hi all -**\** hello -**\** NoodleDoodle, TheKoziTwo, -**\** anyone else? -**\** hola -**\** luigi1112, listening or cruising ;) -**\** jwinterm -**\** lol -**\** hyc and moneromooo are around afaik -**\** fluffypony: if you wanna just give a list of things to cover, one of us can conduct the meeting. (assuming you don't wanna have to type a shitload on your phone) -**\** Well I think let's start with 0MQ, tewinget -**\** Then you can talk and I don't have to -**\** :-P -**\** well, I wanted to have more news, but I'm having to do a full distro upgrade to get a newer boost on this craptop, and the internet is slow as balls...so I don't really have much in the way of updates. Soon™. Need to merge RingCT stuff into my zmq branch, then make the new RingCT-related RPC calls (as well as updating any others as needed), then should be golden for basic implementation. -**\** will try to get most of that done today or tomorrow. -**\** This is daemon only right now right? -**\** daemon RPC, and a lib to use it that libwallet will call into. -**\** ok - and then next thing after daemon is buttoned up is a wallet 0MQ endpoint right? -**\** but yes, for right now I'm working on the daemon's RPC. Once that's in a good spot I can move onto wallet RPC. Oh, and I think since the last dev meeting I redid the formatting of the RPC commands to get JSON-RPC 2.0 compliant. -**\** Ok so tewinget let me ask about the backwards-compatible stub -**\** Coz obviously we still need a stub for those that insist on touching the daemon using old RPC -**\** Is that just a matter of refactoring it out of the daemon? -**\** well...so *my* plan was to leave the old RPC in place until we decide "yea, that's for sure deprecated and gonna be removed now" -**\** That's fine - I meant as a later exercise -**\** Just trying to gauge the amount of effort it's going to take -**\** hmm, well, a wrapper around the old RPC to hook into the new wouldn't be *too* hard... -**\** just tedious -**\** I know it's tedious -**\** What if we made it generic -**\** Like it translated the RPC call directly -**\** If it fails pass the error back -**\** Oh wait that won't work -**\** The 0MQ calls are different -**\** not hugely different, but different in some cases, yes. with good reason... -**\** Ok so tedious because it requires everything implemented as a 0MQ client, got it -**\** As a practical matter -**\** We need to consider something like cppnetlib for TLS and auth -**\** I'm trying to make switching costs as low as possible, but I can't make it nonzero. -**\** And implement that as a matter of some urgency, since the entire net_skeleton thing was a colossal waste of time -**\** Ok tks tewinget - anything else from your side? -**\** yea, I might make TLS and auth a priority ahead of wallet RPC (since it will need auth anyway) -**\** other than that, not really. -**\** carry on. -**\** "I can't make it nonzero" <-- excellent! -**\** Hokay -**\** LOL -**\** Nice catch -**\** lol -**\** breaking: Monero contributor works for free! -**\** just tuning in, was teaking my ARM code -**\** god dammit. -**\** Instant delivery! -**\** well, moneromooo, I can't -**\** because it has to use ZERO MQ -**\** Hah hah -**\** #SavedIt -**\** :P -**\** #dadjokes -**\** At any rate -**\** I'd like to introduce pigeons -**\** He's recently started doing some stuff with me -**\** and he's kindly going to help us redo our sysops / devops -**\** For all projects, including Kovri -**\** nice -**\** Hi guys. :) -**\** Hi -**\** hey there -**\** pigeons: tell us a bit about yourself or whatever -**\** "Long walks on the beach" and all that -**\** I guess the population explosion kinda demanded more ops -**\** I see what a sysop is, but not a devop. -**\** I like pina coladas and getting lost in te rain. Ive been syadmin type stuff forever. -**\** Hi pigeons -**\** moneromooo: devops is like CI and build boxes and that -**\** devops is the new term for brogrammers who use docker and jenkins CI etc -**\** Oh nice :) -**\** Hah hah -**\** I think a devop is a developer with rootpw on all production machines. sysaop's worst nightmare :P -**\** Devops-as-a-Service -**\** lol -**\** but yeah im gonna try and get buildbot ci going the system chromium and some others use -**\** get builds and tests for arm, windows, mac, freebsd, linux 32 64 -**\** Also the immediate aim is to be able to push nightlies to the site -**\** nice -**\** #1047 did this -**\** oops -**\ {-guzzi}** hi pigeons -**\** So the broader community can test without waiting for fluffypony to build -**\** eventually look at gitian style reproducible builds -**\** ARM is gonna be 3 distinct builds, ARMv6, ARMv7, ARMv8 -**\** rapidly proliferating... -**\** ok cool -**\** hyc: I think we'll have to drop ARMv6 for performance concerns -**\** If not now then soon -**\** ok, fair enough -**\** Also on that note -**\** yeah, the perf/watt just isn't there on ARMv6 -**\** Am I correct in saying that QEMU is about the only way we're going to get arm7/8 build boxes? -**\** Or does anyone know of hosted native arm boxes? -**\** there's an ARM VPS provider out there -**\** yeah what are they called again, there is one -**\** someone recommended one to me just the other day, oddly enough...can't remember the name. -**\** lol -**\** awww. i still use my pi zero nodes -**\** which are arm v6 -**\** bitjedi: they'll choke on RingCT -**\** scaleway.com ? -**\** scaleways? -**\** yeah -**\** are u sure it's cpu and not io? -**\** Awesome -**\** Isn't scaleways native and not virtualised? -**\** I seem to vaguely recall -**\** I think it was Scaleway -**\** hm, they claim bare metal, yeah -**\** theres one ovhi or somone in scandanavia -**\** Ok -**\** Also the implication is that anyone relying on the Mac / 32-bit test boxes should expect an impending change -**\** I think anonimal primarily uses them -**\** Also we'll hopefully be able to provide broader access to test hardware in future -**\ {-anonimal}** * has yet to use 32-bit boxes -**\** Ok then FreeBSD -**\** Has anyone tried the WIP boost 1.60 port on BSD? -**\** haven't touched BSD in years -**\ {-anonimal}** Last I checked, build failed hard on freebsd for monero. -**\ {-anonimal}** Works with kovri. -**\** xmj is our resident BSD expert and even he hasn't touched boost 1.60 -**\** If anyone wants to volunteer to play with that great -**\** We also need to start thinking about packaging -**\** lol relevant PR is relevant -**\** hyc how do you guys handle packaging for like Debian / Ubuntu? -**\** eh, OpenLDAP Project is source-code only, distros do their own packaging -**\** Coz my concern with farming it out is that we end up with old versions on old distros -**\ {-anonimal}** fluffypony: I was planning to work with the monero bsd build (only freebsd though) once we get kovri releases going -**\** yes, that's a pervasive problem with distros -**\** Tks anonimal - I'll also fiddle -**\** When I have time, so never :-P -**\** Ok next thing -**\** moneromooo: want to talk about the rct serialisation changes? -**\** And the impact on testnet -**\** It's finished. It's on github ready to merge. And it will need reorganizing on testnet, yes. -**\** So, I guess someone with hash power will have to pop N blocks till before v4, and mine. -**\** After a few daysm it'll reorg for everyone :) -**\** And we'll get to test deep reogs. -**\** so anyone mining testnet right now should stop -**\** Unless you want to test stuff. -**\** i exported the raw blockchain up to 800499. that's before v3, right? -**\** well that's not entirely necessary >**_>** -**\** Yes. -**\** and v4 is... ? -**\** 802000 or so iirc ? -**\** 801220 -**\** XMR up or down -**\** ah, k -**\** I think my miner is off atm -**\** it had that hiccup and I never fixed it coz stuff -**\** rct soon! -**\** ok so moneromooo -**\** It had to be done -**\** are you guys forking the testnet ? -**\** when it loads the blockchain on the new code -**\** im gonnad do a testnet classic -**\** it *should* freak out -**\ {-anonimal}** Is this the meeting where we can discusses CI for CD? -**\** and rollback? -**\** anonimal: CD? like compact discs? -**\ {-anonimal}** Laser-only releases -**\** It'll probably moan a bit, but not overly. -**\** :-P -**\** ok but what I mean is -**\** when we load a blockchain off disk we don't re-verify -**\** the dev meeting is still going on or to late ? -**\** so will we have to manually pop blocks? -**\** still going on MalMen -**\** Yes. -**\** ok so I'll merge tomorrow afternoon, gives us a day for review -**\** Just the miner. Others will just reorg when the miner passes the old chain's diff. -**\** (hopefully) -**\** and then I'll do some block-popping tomorrow night -**\** and hopefully deep reorgs -**\** luigi1112: btw, you'll want to read the latest get_transaction_hash and comment. It's still 3 parts. -**\** ok -**\** then the next thing is our hard fork date and the next release -**\** we're planning on finalising final bits and releasing 0.10 shortly -**\** but obviously RingCT (ie. v4 blocks) is not ready for even a final inclusion in this code freeze -**\** given that we're still making changes -**\** so I'd like some input from contributors and those present as to how to handle the v4 fork, since we have a couple of options -**\** either: -**\** 1. we leave v4 till March 2016 -**\** 2017 -**\** tks 2017 -**\** 2. we change the "complain about a fork" date to like end-of-November, with an aim to forking to v4 end of December -**\** so coded freeze beginning of December -**\** (this would make RCT transactions potentially available on mainnet from Jan 1) -**\** but obviously there's the risk of breakage -**\** maybe December is too soon, how about January? -**\** so if we had to do Jan, then when do we do v5? -**\** March is too close to Jan for v5, imho -**\** fluffypony My preference is 2, but my biggest concern is the amount of time left for finalization of development and testing -**\** We don't necessarily have to decide the exact dates now, but I think option 2 would be best -**\** ok so what if we did 2, but then pushed the v5 fork to September next year -**\** if we have v4 in January then June/July would be OK -**\** that way RCT is available on mainnet early on, but if anything breaks we have 9 months to fix it -**\** hyc: I don't want to go too far away from our schedule -**\** ok -**\** \ if we have v4 in January then June/July would be OK <= Fine with that too -**\** sounds reasonable to me -**\** Like I said, we can always decide on the exact dates later -**\** like this is major enough to warrant a change, but we should aim for a singular change -**\** so march/september is the cadence we're aiming for? -**\** Yes I like the idea of advancing V4 fork but keeping the v5 fork on schedule -**\** I agree, singular deviation from the schedule is preferable. -**\** ok -**\** hyc: yep -**\** fluffypony: most people will use Ring CT transactions anyway -**\** so we bring v4 a bit forward, and leave v5 as scheduled -**\** yes -**\** dEBRUYNE: we can always make it the non-default, like we did with transfer_new -**\** sounds good -**\** yeah agree -**\** agree -**\** ok so we'll move the freak-out to early December, and actual fork block height will be decided at that code freeze -**\** but likely late Dec / early Jan or so -**\** and v5 stays for September 2017 -**\** consensus: reached! -**\** \o/ -**\** (it's so easy when you're tiny and only like 5 people have to agree, lol) -**\** I think that's about it from my side, there's something else but I completely can't remember -**\** is there anything else that anyone wants to bring up? -**\** I dunno multisig for bitcoin was a bitch... -**\** current freeze, release date? -**\** since Ilya's not here... -**\ {-anonimal}** I moved kovri logo decision agenda to the beginning of kovri meeting in 10'ish minutes so we can catch everyone before they leave -**\** that only had 8 guys -**\** ferretinjapan: lol -**\** a quick update on multisig preferably -**\** Do you want to wait for the fee change before binaries ? -**\** lurker: https://shnoe.wordpress.com/2016/03/22/ring-multisignature/ -**\** it's whitepaper-only right now -**\** fluffpony - the GUI wallet. Languages and regional variations. -**\** oh -**\** Hi guys can I ask about public wallet build release dates -**\** yes moneromooo thanks for reminding me -**\** tag->release->binaries will be in the coming week, hopefully -**\** there are two things still remaining -**\** 1. fee changes (lower min-fee, bind it to the inverse of the block median as suggested by ArticMine) -**\** 2. ideally, if anyone is up for it, we seriously need our DNSSEC check expanded to *actually* check from the root cert down, at the moment it's relying on the DNS server to send back a "secure" flag, which is breaking it on lots of routers -**\** tewinget can you point me to the list of 0qm commands that you have already? -**\** and we rely on DNSSEC for MoneroSeeds and MoneroPulse -**\** I have some sugestion -**\** moneromooo is coding the fee changes -**\** there's some time pressure on that, but it's not a huge piece of work, so if anyone is up for it then that would be appreciated -**\** if not it'll have to hold off till the next release -**\** Yes, I started looking at it this afternoon. Not a simple change, since it'll require a new RPC, and access to median block size calc in misc places. -**\** ok -**\** fluffypony: would it be feasible to provide trezor binaries? -**\** dEBRUYNE: I haven't actually looked at it properly, and NoodleDoodle isn't around to give his opinion -**\** I see, he's still working on the Ring CT bit, so probably better to wait until that is finished to provide them -**\** kintaji: re: languages / variants, I think we'll hold off on that a bit as there are large parts of the GUI that are non-functional right now -**\** Kermit_: do you mean the GUI wallet, or the next tagged release? -**\** Yes gui -**\** fluffypony - Okay. Just to say there are some oddities with the current flag page. Can expand at a later time. -**\** Kermit_: not certain yet - I'll look at building beta binaries in the next week or so -**\** Thanks -**\** kintaji: yeah maybe best thing to do is drop it out the wizard initially -**\** and add it back in later on -**\** MalMen: have a look at https://www.github.com/tewinget/bitmonero/tree/zmq-dev, file src/rpc/daemon_messages.h. I need to do a bit of write-up, but that's a good place to start. -**\** fluffypony - yep. sounds like a good idea. -**\** ok anything else or can we start the Kovri meeting? -**\** any other volunteers to test ARMv8 builds? -**\** oooh I will hyc -**\** yea i can -**\** cool, I'll have atarball ready later tonight -**\** tewinget you are writing your rcp calls with up letters right ? -**\** fluffy i have centos 64bit on my rpi3 fyi -**\** hyc: is an R8 ARM processor an armv8? -**\** coz if so then I have a bunch of C.H.I.Ps lying around that I can test on -**\** I don't know what R8 is. what box is that? -**\** MalMen: the class names are CamelCase, but the methods (currently) are "word_word_word". No reason that can't change, of course. -**\** ahhhh, nice -**\** AllWinner R8 -**\** I was in mind that you where using WordWordWord -**\** ok I see it -**\** would sugest wordWordWord -**\** "Allwinner R8 is SoC designed based on A13 featuring one core Cortex-A8 ARM CPU with Cedar Engine VPU and Mali 400 GPU" -**\** nope . Cortex-A8 is ARMv7 -**\** ah ok -**\** well that sucks -**\** hi meeting-bot! -**\** MalMen: the method names (as in, the method field in the RPC call on the wire) are "word_word_word" to conform with the previous RPC, but I have no particular attachment to that format. +**\** Hi all +**\** I'm on my phone +**\** Hi all +**\** hello +**\** NoodleDoodle, TheKoziTwo, +**\** anyone else? +**\** hola +**\** luigi1112, listening or cruising ;) +**\** jwinterm +**\** lol +**\** hyc and moneromooo are around afaik +**\** fluffypony: if you wanna just give a list of things to cover, one of us can conduct the meeting. (assuming you don't wanna have to type a shitload on your phone) +**\** Well I think let's start with 0MQ, tewinget +**\** Then you can talk and I don't have to +**\** :-P +**\** well, I wanted to have more news, but I'm having to do a full distro upgrade to get a newer boost on this craptop, and the internet is slow as balls...so I don't really have much in the way of updates. Soon™. Need to merge RingCT stuff into my zmq branch, then make the new RingCT-related RPC calls (as well as updating any others as needed), then should be golden for basic implementation. +**\** will try to get most of that done today or tomorrow. +**\** This is daemon only right now right? +**\** daemon RPC, and a lib to use it that libwallet will call into. +**\** ok - and then next thing after daemon is buttoned up is a wallet 0MQ endpoint right? +**\** but yes, for right now I'm working on the daemon's RPC. Once that's in a good spot I can move onto wallet RPC. Oh, and I think since the last dev meeting I redid the formatting of the RPC commands to get JSON-RPC 2.0 compliant. +**\** Ok so tewinget let me ask about the backwards-compatible stub +**\** Coz obviously we still need a stub for those that insist on touching the daemon using old RPC +**\** Is that just a matter of refactoring it out of the daemon? +**\** well...so \*my* plan was to leave the old RPC in place until we decide "yea, that's for sure deprecated and gonna be removed now" +**\** That's fine - I meant as a later exercise +**\** Just trying to gauge the amount of effort it's going to take +**\** hmm, well, a wrapper around the old RPC to hook into the new wouldn't be *too* hard... +**\** just tedious +**\** I know it's tedious +**\** What if we made it generic +**\** Like it translated the RPC call directly +**\** If it fails pass the error back +**\** Oh wait that won't work +**\** The 0MQ calls are different +**\** not hugely different, but different in some cases, yes. with good reason... +**\** Ok so tedious because it requires everything implemented as a 0MQ client, got it +**\** As a practical matter +**\** We need to consider something like cppnetlib for TLS and auth +**\** I'm trying to make switching costs as low as possible, but I can't make it nonzero. +**\** And implement that as a matter of some urgency, since the entire net_skeleton thing was a colossal waste of time +**\** Ok tks tewinget - anything else from your side? +**\** yea, I might make TLS and auth a priority ahead of wallet RPC (since it will need auth anyway) +**\** other than that, not really. +**\** carry on. +**\** "I can't make it nonzero" <-- excellent! +**\** Hokay +**\** LOL +**\** Nice catch +**\** lol +**\** breaking: Monero contributor works for free! +**\** just tuning in, was teaking my ARM code +**\** god dammit. +**\** Instant delivery! +**\** well, moneromooo, I can't +**\** because it has to use ZERO MQ +**\** Hah hah +**\** #SavedIt +**\** :P +**\** #dadjokes +**\** At any rate +**\** I'd like to introduce pigeons +**\** He's recently started doing some stuff with me +**\** and he's kindly going to help us redo our sysops / devops +**\** For all projects, including Kovri +**\** nice +**\** Hi guys. :) +**\** Hi +**\** hey there +**\** pigeons: tell us a bit about yourself or whatever +**\** "Long walks on the beach" and all that +**\** I guess the population explosion kinda demanded more ops +**\** I see what a sysop is, but not a devop. +**\** I like pina coladas and getting lost in te rain. Ive been syadmin type stuff forever. +**\** Hi pigeons +**\** moneromooo: devops is like CI and build boxes and that +**\** devops is the new term for brogrammers who use docker and jenkins CI etc +**\** Oh nice :) +**\** Hah hah +**\** I think a devop is a developer with rootpw on all production machines. sysaop's worst nightmare :P +**\** Devops-as-a-Service +**\** lol +**\** but yeah im gonna try and get buildbot ci going the system chromium and some others use +**\** get builds and tests for arm, windows, mac, freebsd, linux 32 64 +**\** Also the immediate aim is to be able to push nightlies to the site +**\** nice +**\** #1047 did this +**\** oops +**\ {-guzzi}** hi pigeons +**\** So the broader community can test without waiting for fluffypony to build +**\** eventually look at gitian style reproducible builds +**\** ARM is gonna be 3 distinct builds, ARMv6, ARMv7, ARMv8 +**\** rapidly proliferating... +**\** ok cool +**\** hyc: I think we'll have to drop ARMv6 for performance concerns +**\** If not now then soon +**\** ok, fair enough +**\** Also on that note +**\** yeah, the perf/watt just isn't there on ARMv6 +**\** Am I correct in saying that QEMU is about the only way we're going to get arm7/8 build boxes? +**\** Or does anyone know of hosted native arm boxes? +**\** there's an ARM VPS provider out there +**\** yeah what are they called again, there is one +**\** someone recommended one to me just the other day, oddly enough...can't remember the name. +**\** lol +**\** awww. i still use my pi zero nodes +**\** which are arm v6 +**\** bitjedi: they'll choke on RingCT +**\** scaleway.com ? +**\** scaleways? +**\** yeah +**\** are u sure it's cpu and not io? +**\** Awesome +**\** Isn't scaleways native and not virtualised? +**\** I seem to vaguely recall +**\** I think it was Scaleway +**\** hm, they claim bare metal, yeah +**\** theres one ovhi or somone in scandanavia +**\** Ok +**\** Also the implication is that anyone relying on the Mac / 32-bit test boxes should expect an impending change +**\** I think anonimal primarily uses them +**\** Also we'll hopefully be able to provide broader access to test hardware in future +**\ {-anonimal}** * has yet to use 32-bit boxes +**\** Ok then FreeBSD +**\** Has anyone tried the WIP boost 1.60 port on BSD? +**\** haven't touched BSD in years +**\ {-anonimal}** Last I checked, build failed hard on freebsd for monero. +**\ {-anonimal}** Works with kovri. +**\** xmj is our resident BSD expert and even he hasn't touched boost 1.60 +**\** If anyone wants to volunteer to play with that great +**\** We also need to start thinking about packaging +**\** lol relevant PR is relevant +**\** hyc how do you guys handle packaging for like Debian / Ubuntu? +**\** eh, OpenLDAP Project is source-code only, distros do their own packaging +**\** Coz my concern with farming it out is that we end up with old versions on old distros +**\ {-anonimal}** fluffypony: I was planning to work with the monero bsd build (only freebsd though) once we get kovri releases going +**\** yes, that's a pervasive problem with distros +**\** Tks anonimal - I'll also fiddle +**\** When I have time, so never :-P +**\** Ok next thing +**\** moneromooo: want to talk about the rct serialisation changes? +**\** And the impact on testnet +**\** It's finished. It's on github ready to merge. And it will need reorganizing on testnet, yes. +**\** So, I guess someone with hash power will have to pop N blocks till before v4, and mine. +**\** After a few daysm it'll reorg for everyone :) +**\** And we'll get to test deep reogs. +**\** so anyone mining testnet right now should stop +**\** Unless you want to test stuff. +**\** i exported the raw blockchain up to 800499. that's before v3, right? +**\** well that's not entirely necessary >\*\*\_>\*\* +**\** Yes. +**\** and v4 is... ? +**\** 802000 or so iirc ? +**\** 801220 +**\** XMR up or down +**\** ah, k +**\** I think my miner is off atm +**\** it had that hiccup and I never fixed it coz stuff +**\** rct soon! +**\** ok so moneromooo +**\** It had to be done +**\** are you guys forking the testnet ? +**\** when it loads the blockchain on the new code +**\** im gonnad do a testnet classic +**\** it *should* freak out +**\ {-anonimal}** Is this the meeting where we can discusses CI for CD? +**\** and rollback? +**\** anonimal: CD? like compact discs? +**\ {-anonimal}** Laser-only releases +**\** It'll probably moan a bit, but not overly. +**\** :-P +**\** ok but what I mean is +**\** when we load a blockchain off disk we don't re-verify +**\** the dev meeting is still going on or to late ? +**\** so will we have to manually pop blocks? +**\** still going on MalMen +**\** Yes. +**\** ok so I'll merge tomorrow afternoon, gives us a day for review +**\** Just the miner. Others will just reorg when the miner passes the old chain's diff. +**\** (hopefully) +**\** and then I'll do some block-popping tomorrow night +**\** and hopefully deep reorgs +**\** luigi1112: btw, you'll want to read the latest get_transaction_hash and comment. It's still 3 parts. +**\** ok +**\** then the next thing is our hard fork date and the next release +**\** we're planning on finalising final bits and releasing 0.10 shortly +**\** but obviously RingCT (ie. v4 blocks) is not ready for even a final inclusion in this code freeze +**\** given that we're still making changes +**\** so I'd like some input from contributors and those present as to how to handle the v4 fork, since we have a couple of options +**\** either: +**\** 1. we leave v4 till March 2016 +**\** 2017 +**\** tks 2017 +**\** 2. we change the "complain about a fork" date to like end-of-November, with an aim to forking to v4 end of December +**\** so coded freeze beginning of December +**\** (this would make RCT transactions potentially available on mainnet from Jan 1) +**\** but obviously there's the risk of breakage +**\** maybe December is too soon, how about January? +**\** so if we had to do Jan, then when do we do v5? +**\** March is too close to Jan for v5, imho +**\** fluffypony My preference is 2, but my biggest concern is the amount of time left for finalization of development and testing +**\** We don't necessarily have to decide the exact dates now, but I think option 2 would be best +**\** ok so what if we did 2, but then pushed the v5 fork to September next year +**\** if we have v4 in January then June/July would be OK +**\** that way RCT is available on mainnet early on, but if anything breaks we have 9 months to fix it +**\** hyc: I don't want to go too far away from our schedule +**\** ok +**\** \ if we have v4 in January then June/July would be OK <= Fine with that too +**\** sounds reasonable to me +**\** Like I said, we can always decide on the exact dates later +**\** like this is major enough to warrant a change, but we should aim for a singular change +**\** so march/september is the cadence we're aiming for? +**\** Yes I like the idea of advancing V4 fork but keeping the v5 fork on schedule +**\** I agree, singular deviation from the schedule is preferable. +**\** ok +**\** hyc: yep +**\** fluffypony: most people will use Ring CT transactions anyway +**\** so we bring v4 a bit forward, and leave v5 as scheduled +**\** yes +**\** dEBRUYNE: we can always make it the non-default, like we did with transfer_new +**\** sounds good +**\** yeah agree +**\** agree +**\** ok so we'll move the freak-out to early December, and actual fork block height will be decided at that code freeze +**\** but likely late Dec / early Jan or so +**\** and v5 stays for September 2017 +**\** consensus: reached! +**\** \o/ +**\** (it's so easy when you're tiny and only like 5 people have to agree, lol) +**\** I think that's about it from my side, there's something else but I completely can't remember +**\** is there anything else that anyone wants to bring up? +**\** I dunno multisig for bitcoin was a bitch... +**\** current freeze, release date? +**\** since Ilya's not here... +**\ {-anonimal}** I moved kovri logo decision agenda to the beginning of kovri meeting in 10'ish minutes so we can catch everyone before they leave +**\** that only had 8 guys +**\** ferretinjapan: lol +**\** a quick update on multisig preferably +**\** Do you want to wait for the fee change before binaries ? +**\** lurker: https://shnoe.wordpress.com/2016/03/22/ring-multisignature/ +**\** it's whitepaper-only right now +**\** fluffpony - the GUI wallet. Languages and regional variations. +**\** oh +**\** Hi guys can I ask about public wallet build release dates +**\** yes moneromooo thanks for reminding me +**\** tag->release->binaries will be in the coming week, hopefully +**\** there are two things still remaining +**\** 1. fee changes (lower min-fee, bind it to the inverse of the block median as suggested by ArticMine) +**\** 2. ideally, if anyone is up for it, we seriously need our DNSSEC check expanded to *actually* check from the root cert down, at the moment it's relying on the DNS server to send back a "secure" flag, which is breaking it on lots of routers +**\** tewinget can you point me to the list of 0qm commands that you have already? +**\** and we rely on DNSSEC for MoneroSeeds and MoneroPulse +**\** I have some sugestion +**\** moneromooo is coding the fee changes +**\** there's some time pressure on that, but it's not a huge piece of work, so if anyone is up for it then that would be appreciated +**\** if not it'll have to hold off till the next release +**\** Yes, I started looking at it this afternoon. Not a simple change, since it'll require a new RPC, and access to median block size calc in misc places. +**\** ok +**\** fluffypony: would it be feasible to provide trezor binaries? +**\** dEBRUYNE: I haven't actually looked at it properly, and NoodleDoodle isn't around to give his opinion +**\** I see, he's still working on the Ring CT bit, so probably better to wait until that is finished to provide them +**\** kintaji: re: languages / variants, I think we'll hold off on that a bit as there are large parts of the GUI that are non-functional right now +**\** Kermit_: do you mean the GUI wallet, or the next tagged release? +**\** Yes gui +**\** fluffypony - Okay. Just to say there are some oddities with the current flag page. Can expand at a later time. +**\** Kermit_: not certain yet - I'll look at building beta binaries in the next week or so +**\** Thanks +**\** kintaji: yeah maybe best thing to do is drop it out the wizard initially +**\** and add it back in later on +**\** MalMen: have a look at https://www.github.com/tewinget/bitmonero/tree/zmq-dev, file src/rpc/daemon_messages.h. I need to do a bit of write-up, but that's a good place to start. +**\** fluffypony - yep. sounds like a good idea. +**\** ok anything else or can we start the Kovri meeting? +**\** any other volunteers to test ARMv8 builds? +**\** oooh I will hyc +**\** yea i can +**\** cool, I'll have atarball ready later tonight +**\** tewinget you are writing your rcp calls with up letters right ? +**\** fluffy i have centos 64bit on my rpi3 fyi +**\** hyc: is an R8 ARM processor an armv8? +**\** coz if so then I have a bunch of C.H.I.Ps lying around that I can test on +**\** I don't know what R8 is. what box is that? +**\** MalMen: the class names are CamelCase, but the methods (currently) are "word_word_word". No reason that can't change, of course. +**\** ahhhh, nice +**\** AllWinner R8 +**\** I was in mind that you where using WordWordWord +**\** ok I see it +**\** would sugest wordWordWord +**\** "Allwinner R8 is SoC designed based on A13 featuring one core Cortex-A8 ARM CPU with Cedar Engine VPU and Mali 400 GPU" +**\** nope . Cortex-A8 is ARMv7 +**\** ah ok +**\** well that sucks +**\** hi meeting-bot! +**\** MalMen: the method names (as in, the method field in the RPC call on the wire) are "word_word_word" to conform with the previous RPC, but I have no particular attachment to that format. **\** well, I am checking the bitcoin rcp and they use wordwordword, I think i like word_word_word better \ No newline at end of file