Commit 6e4fea1b authored by dEBRUYNE-1's avatar dEBRUYNE-1

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

parent 1415d6af
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-11-13
summary: Brief review of what has been completed since last meeting, prepration of Alpha release, and code & open tickets discussion
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*November 13th, 2016*
# Logs
**\<i2p-relay> {-anonimal}** Proposed meeting items:
**\<i2p-relay> {-anonimal}** 1. Greetings
**\<i2p-relay> {-anonimal}** 2. Brief review of what's been completed since the previous meeting
**\<i2p-relay> {-anonimal}** 5. Code + ticket discussion / Q & A
**\<i2p-relay> {-anonimal}** 3. Preparing for alpha release
**\<i2p-relay> {-anonimal}** 4. Moving meeting agenda issues from monero-project/kovri to monero-project/meta
**\<i2p-relay> {-anonimal}** 6. Any additional meeting items
**\<i2p-relay> {-anonimal}** Hi
**\<i2p-relay> {-anonimal}** 7. Confirm next meeting date/time
**\<i2p-relay> {-anonimal}** JFTR for the log: people think the meeting is at 19:00 when it is actually at 17:00 so we may be a bit shorthanded today
**\<i2p-relay> {-anonimal}** 2. Brief review of what's been completed since the previous meeting
**\<i2p-relay> {-anonimal}** The general focus of the past two weeks has been "escaping comfort zone" work:
**\<i2p-relay> {-anonimal}** i.e., pursuing a few long-standing issues that I've avoided because they weren't fun:
**\<i2p-relay> {-anonimal}** Build:
**\<i2p-relay> {-anonimal}** - Builds builds builds! All builds are now in the GREEN!
**\<i2p-relay> {-anonimal}** - ARMv7/8 and Win32/64 builds are now online! Static builds online!
**\<i2p-relay> {-anonimal}** - Win32/64 run-time is now available after patching an upstream issue
**\<i2p-relay> {-anonimal}** - ARMv7 has a non-Kovri runtime issue, ARMv8 box still needs testing
**\<i2p-relay> {-anonimal}** - Much build-related work with pigeons, partly noted in monero-project/meta
**\<i2p-relay> {-anonimal}** - Setup kovri per-platform IRC clients for testing, say hi to them in #kovri-dev
**\<i2p-relay> {-anonimal}** Code:
**\<i2p-relay> {-anonimal}** - Resolved all Coverity defects (details in #263)!
**\<i2p-relay> {-anonimal}** - Bug fixes in addressbook + shutdown, https on windows
**\<i2p-relay> {-anonimal}** - Design and planning: global refactoring, study, and testing
**\<i2p-relay> {-anonimal}** - SSU Server testing (nothing merge-able at the moment)
**\<i2p-relay> {-anonimal}** - Debugging, attending to open milestone issues
**\<i2p-relay> {-anonimal}** - Mentoring: working with other contributors to "Make Kovri Great Again"
**\<i2p-relay> {-anonimal}** - guzzi doing his civic duty while also working on http proxy (WIP)
**\<i2p-relay> {-anonimal}** - olark providing great netdb/socks proxy documentation and refactoring
**\<i2p-relay> {-anonimal}** Misc:
**\<i2p-relay> {-anonimal}** - 7z/installer research for platform-agnostic bundling of data-dir with static binary
**\<i2p-relay> {-anonimal}** - README/Doc updates, misc. project maintenance
**\<i2p-relay> {-anonimal}** - Too many other things to mention here or things that I've simply forgotten
**\<i2p-relay> {-anonimal}** Note: confirmed earlier: run-time is online on ARMv8!
**\<i2p-relay> {-anonimal}** Anything else on point 2.?
**\<i2p-relay> {-olark}** Sums up the past 2 weeks well.
**\<i2p-relay> {-anonimal}** Side-note, JFTR: slack relay is not working and fluffypony isn't running meeting relay to #monero-dev
**\<i2p-relay> {-anonimal}** Ok, moving on,
**\<i2p-relay> {-anonimal}** 3. Preparing for alpha release
**\<guzzi>** Here fyi
**\<i2p-relay> {-anonimal}** Oh good, hi guzzi (I PM'd you earlier)
**\<guzzi>** Ok
**\<i2p-relay> {-anonimal}** So, 3. looking at https://github.com/monero-project/kovri/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.1.0-alpha
**\<i2p-relay> {-anonimal}** A few of these can be moved to next milestone (they aren't urgent),
**\<i2p-relay> {-anonimal}** If I can't resolve the rest by Dec 1st. in addition to everything else that needs attention, then maybe Dec. 14th at the latest.
**\<i2p-relay> {-anonimal}** Really there are only a few key issues that *must* be resolved for an alpha release and they are, IMHO:
**\<i2p-relay> {-anonimal}** #375 and #119 <-- at an absolute bare minimum
**\<i2p-relay> {-anonimal}** because they *really* can get in the way.
**\<i2p-relay> {-anonimal}** But that's a bare-minimum not-ideal scenario and I know we can get more done by then.
**\<i2p-relay> {-anonimal}** Any thoughts?
**\<i2p-relay> {-olark}** Yeah those are the big ones. I'll go over the addressbook and add/remove the destinations that don't work.
**\<guzzi>** 119 looks easy for u. I dont disagree
**\<guzzi>** Sorry i meant 375
**\<i2p-relay> {-anonimal}** Well, it looks straightforward, we'll see what it really looks like when the time comes :)
**\<i2p-relay> {-anonimal}** olark: re: destinations, which issue # is this?
**\<i2p-relay> {-olark}** Keep it a small list.
**\<i2p-relay> {-olark}** Some are just dead.
**\<i2p-relay> {-olark}** So we have a small list of eepsites that do work and may be useful for a new user.
**\<i2p-relay> {-olark}** Not in the milestone I believe.
**\<guzzi>** Agree on the eepsite list actually containing valid sites
**\<guzzi>** 119 looks like a critical fix for sure.
**\<i2p-relay> {-olark}** re: subscription file
**\<i2p-relay> {-olark}** Not high priority but maybe something nice to have for the first release.
**\<i2p-relay> {-anonimal}** olark: oh that, well that's very low priority but if it's an issue than ok, but how can you confirm if they are dead? Were some removed in the .27 java i2p release?
**\<i2p-relay> {-olark}** Just some of them never connect ever.
**\<i2p-relay> {-olark}** I'll go over them again in the coming days.
**\<i2p-relay> {-anonimal}** Ok, sounds good.
**\<i2p-relay> {-anonimal}** guzzi: well, I wouldn't say critical because it doesn't effect all routers and it certainly hasn't effect the OSX instances
**\<guzzi>** Ok understood
**\<i2p-relay> {-anonimal}** And there's always the option to disable ssu at run-time, but yes I think it should be resolved.
**\<i2p-relay> {-anonimal}** fluffypony hinted at *not* having a release before 33C3 but he may be trying to get out of https://github.com/monero-project/kovri/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.1.0-alpha+assignee%3Afluffypony
**\* guzzi** needs to find out what ssu is before i
**\<i2p-relay> {-anonimal}** ;)
**\* guzzi** open my mouth
**\<i2p-relay> {-olark}** Semi-Secure UDP
**\<guzzi>** Thanks
**\<i2p-relay> {-anonimal}** guzzi: checkout the new Moneropedia entries I made that are now live on the website
**\<i2p-relay> {-anonimal}** guzzi: link is in README.md
**\<i2p-relay> {-anonimal}** (on current HEAD)
**\<guzzi>** Awesome
**\* guzzi** Todo tonight
**\<i2p-relay> {-anonimal}** So, re: release,
**\<i2p-relay> {-anonimal}** Let's keep hacking away for the next two weeks and see where we stand.
**\<i2p-relay> {-anonimal}** Any objections?
**\<guzzi>** Ok i will read your pm when i get back
**\<i2p-relay> {-olark}** Keep on hacking away ;)
**\<guzzi>** On phone now
**\<i2p-relay> {-anonimal}** The difference between a Dec. 1st alpha release and Dec. 14th alpha release IMHO will be noticeable to an end-user. Neither is useful without package resolution nor more monero input/participation; so I want to wait for a final decision until fluffypony speaks up. We can talk more this coming week.
**\<guzzi>** I agree boss.
**\<i2p-relay> {-anonimal}** lol guzzi
**\<i2p-relay> {-anonimal}** My biggest concern is that for reasons not of my doing, a release doesn't happen before 33c3, and I really hate having to change dates like this.
**\<i2p-relay> {-anonimal}** But I'll have to be flexible for now because there are many moving parts.
**\<i2p-relay> {-anonimal}** Anything else on point 3.?
**\<guzzi>** No
**\<i2p-relay> {-anonimal}** olark: ?
**\<i2p-relay> {-olark}** We can keep moving along.
**\<i2p-relay> {-anonimal}** 4. Moving meeting agenda issues from monero-project/kovri to monero-project/meta
**\<i2p-relay> {-anonimal}** So, as this meeting has proven, no one else in Monero looks at the meeting agendas I prepare for every meeting :)
**\<i2p-relay> {-anonimal}** With the creation of monero-project/meta, I think it would be better to not clutter the kovri repo with meeting agendas.
**\<guzzi>** Agree 100%
**\<i2p-relay> {-anonimal}** I would hope that more monero people get inolved with meeting agenda preparation and start using the meta repo too.
**\<i2p-relay> {-anonimal}** I'd like to move agendas to meta from now on. guzzi is on board. Anyone else?
**\<i2p-relay> {-olark}** Sounds good to me.
**\<i2p-relay> {-anonimal}** Alright, I'll start doing that.
**\<i2p-relay> {-anonimal}** Moving on,
**\<i2p-relay> {-anonimal}** 5. Code + ticket discussion / Q & A
**\<i2p-relay> {-iDunk}** i built kovri on win64 successfully but the build failed on linking for win32
**\<i2p-relay> {-anonimal}** We've basically covered this in point 3, but I did add some new notes to #187
**\<i2p-relay> {-iDunk-kovri-win64}** hiii
**\<i2p-relay> {-anonimal}** For #187 not sure if EinMByte is around.
**\<i2p-relay> {-anonimal}** Yay, hi iDunk-kovri-win64 :)
**\<i2p-relay> {-iDunk-kovri-win64}** :)
**\<guzzi>** Do we care about 32
**\<i2p-relay> {-anonimal}** iDunk: can you paste error after the meeting?
**\<i2p-relay> {-iDunk}** will do
**\<i2p-relay> {-anonimal}** iDunk guzzi: our win32 build is working with buildbot https://build.getmonero.org/waterfall
**\<guzzi>** Ok so it is isolated
**\<i2p-relay> {-anonimal}** Yep, most likely, we'll see.
**\<i2p-relay> {-anonimal}** Anyone have any questions/comments on open/closed issues?
**\<guzzi>** Nice work idunk thank you
**\<guzzi>** None here. You know where i am at
**\<i2p-relay> {-iDunk}** np
**\<i2p-relay> {-anonimal}** lol, sipping up a pina colada I imagine
**\<guzzi>** Lol yes.
**\<i2p-relay> {-anonimal}** olark: any questions/comments on open/closed issues?
**\<guzzi>** I also had meant you know where i am at code wise
**\<i2p-relay> {-olark}** All good ;D
**\<i2p-relay> {-anonimal}** Oh, haha!
**\<i2p-relay> {-anonimal}** * glances over issues
**\<i2p-relay> {-olark}** re: APIs
**\<i2p-relay> {-olark}** How is that coming along?
**\<i2p-relay> {-olark}** #351 and #350
**\<i2p-relay> {-anonimal}** Once more client/router work is completed, they will be easier to implement.
**\<i2p-relay> {-anonimal}** So that first, API second.
**\<i2p-relay> {-olark}** Ya, still got a little ways to go. Haven't written APIs in a while so could be a good place to refresh myself ;)
**\<i2p-relay> {-anonimal}** I'm getting a better idea of how I'd like to implement but I'd like to compare notes with EinMByte when he returns before moving on anything.
**\<i2p-relay> {-anonimal}** (because he has strong opinions on the matter and he has great experience)
**\<i2p-relay> {-olark}** Yeah his input is very valuable.
**\<i2p-relay> {-olark}** Well known in the i2p community.
**\<_Slack> \<nanoakron>** Lol
**\<i2p-relay> {-anonimal}** I'll continue to comment in those tickets as other work progresses.
**\<i2p-relay> {-anonimal}** I always keep the APIs in mind when doing other work,
**\<i2p-relay> {-anonimal}** which always leads to more work that needs to be resolved before returning to APIs
**\<i2p-relay> {-olark}** Yep
**\<i2p-relay> {-anonimal}** (etc. etc.)
**\<i2p-relay> {-anonimal}** Ok, anything else on this point?
**\<i2p-relay> {-anonimal}** If not we can talk more about it later this week.
**\<i2p-relay> {-olark}** That is all on my side.
**\<i2p-relay> {-olark}** Ok.
**\<guzzi>** None here
**\<i2p-relay> {-anonimal}** 6. Any additional meeting items
**\<i2p-relay> {-anonimal}** Nothing from me. We have a clear plan, we're executing the plan as planned.
**\<guzzi>** None here. You will be busy. I will try to correspond efficiently s possible the next two weeks
**\<_Slack> \<nanoakron>** Slight general question about i2p - if I'm running kovri in the future, would a malicious agency be able to detect that?
**\<i2p-relay> {-olark}** ISPs can figure out you are using i2p.
**\<i2p-relay> {-anonimal}** nanoakron: that depends on the agency
**\<moneromooo>** A malicious one.
**\* moneromooo** runs
**\<_Slack> \<nanoakron>** Lol
**\<i2p-relay> {-anonimal}** nanoakron: good question, I think that was one of the SE questions I bookmarked to answer
**\<_Slack> \<nanoakron>** Are there any loose thoughts on the step beyond kovri? Steganographic encoding within normal router traffic?
**\<i2p-relay> {-anonimal}** Now that moneropedia is merged, I'll answer them.
**\<i2p-relay> {-olark}** I would like to explore better ways to obscure i2p traffic in with regular clearnet traffic, but that is for future research.
**\<_Slack> \<nanoakron>** Of course
**\<i2p-relay> {-olark}** SSU is pretty resistant to DPI and kovri already takes some countermeasure to hide the fact i2p is being used.
**\<i2p-relay> {-anonimal}** Stego obfuscation within encryption? That makes as much sense as encrypting the encryption more than it is already encrypted.
**\<i2p-relay> {-olark}** But there are lots of avenues to explore.
**\<i2p-relay> {-olark}** Packet size I believe is the biggest giveaway among others.
**\<i2p-relay> {-anonimal}** nanoakron: do you have any research on that?
**\<i2p-relay> {-anonimal}** (proving any effectiveness?)
**\<_Slack> \<nanoakron>** Sadly not :(
**\<_Slack> \<nanoakron>** It's just something I heard being discussed between two more technical people where I work a while ago.
**\<i2p-relay> {-anonimal}** nanoakron: it would probably me more effective to simply add another layer of encryption (but that isn't really necessary)
**\<_Slack> \<nanoakron>** Stego to hide bitcoin
**\<i2p-relay> {-anonimal}** (but maybe I'm not understanding your point exactly)
**\<i2p-relay> {-anonimal}** Oh, well that makes sense.
**\<i2p-relay> {-anonimal}** They're not dealing with layered encryption like we do.
**\<_Slack> \<nanoakron>** At the router level
**\<i2p-relay> {-anonimal}** (afaik)
**\<i2p-relay> {-anonimal}** I'm not sure how effective that would be for us, but nanoakron if you get more info please feel free to send to #kovri-dev
**\<_Slack> \<nanoakron>** How easy would it be for the North Korean government to shut down all i2p traffic for example. Anyway...it's highly theoretical stuff right now.
**\<_Slack> \<nanoakron>** Of course!
**\<i2p-relay> {-anonimal}** nanoakron: and olark pointed out important overlay-network facts
**\<_Slack> \<nanoakron>** Yep
**\<i2p-relay> {-anonimal}** North Korea? Can't they basically do whatever they want whenever they want to on any network level?
**\<i2p-relay> {-olark}** North Korea has no internet infrastructure aside from government use afaik.
**\<_Slack> \<nanoakron>** That would be the worst case scenario. For example if our governments decided to ban all non-fiat currencies.
**\<i2p-relay> {-olark}** But if it is any indication, I2P can be run in China.
**\<i2p-relay> {-anonimal}** Doesn't their "internet" exist entirely in a class C subnet?
**\<_Slack> \<nanoakron>** Anyway, I'm just spitballing
**\<i2p-relay> {-olark}** It is important to keep those things in mind though.
**\<i2p-relay> {-anonimal}** Spitball all you want, we have 7 minutes left :)
**\<_Slack> \<nanoakron>** ;)
**\<guzzi>** Lol. True
**\<_Slack> \<nanoakron>** Something for the monero research lab
**\<guzzi>** We should at least worry about packet sizes.
**\<guzzi>** In the future
**\<guzzi>** We are going to add user agent options
**\<_Slack> \<nanoakron>** Deterministic packet sizes to prevent fingerprinting and sniffing
**\<_Slack> \<nanoakron>** ?
**\<i2p-relay> {-olark}** Blending in with SSL traffic is the ideal scenario.
**\<_Slack> \<nanoakron>** Ah yes
**\<_Slack> \<nanoakron>** Will my little Odroid C2 node (ARMv8) be able to run kovri alongside monero in its final embodiment?
**\<i2p-relay> {-anonimal}** NTCP2 is addresses TCP packet length obfuscation.
**\<i2p-relay> {-anonimal}** olark: blending in with SSL, I don't see how that would be ideal, what do you mean?
**\<i2p-relay> {-olark}** To fly under the radar more.
**\<i2p-relay> {-anonimal}** nanoakron: I'm running kovri on ARMv8 linaro right now
**\<_Slack> \<nanoakron>** Neat
**\<i2p-relay> {-olark}** If I am a mouse my best bet is to sneak in with all the other rats into the kitchen right? ;)
**\<i2p-relay> {-olark}** Hoping no one realizes I am a mouse.
**\<i2p-relay> {-anonimal}** olark: they'll tend to shutdown SSL connections before detecting NTCP/UDP signatures, I'm pretty sure of that.
**\<_Slack> \<nanoakron>** Yes, not true stego but mimickry.
**\<guzzi>** Agree.
**\<guzzi>** Any other doomsday senerios?
**\<_Slack> \<nanoakron>** Lol
**\<guzzi>** 1 min?
**\<i2p-relay> {-anonimal}** Btw: a TLS transport is still an open draft proposal from 2009 https://geti2p.net/spec/proposals
**\<i2p-relay> {-anonimal}** TLS/SSL makes it's case but I'm not strongly in favor. We can talk more about that at the next meeting if anyone wants to, just add a note in the agenda.
**\<i2p-relay> {-anonimal}** Moving on,
**\<i2p-relay> {-anonimal}** 7. Confirm next meeting date/time
**\<i2p-relay> {-anonimal}** moneromooo: will next meeting be 18:00 for #monero-dev?
**\<i2p-relay> {-olark}** Hmmm
**\<i2p-relay> {-anonimal}** Or 17:00?
**\<i2p-relay> {-fluffypony}** oh
**\<i2p-relay> {-fluffypony}** sorry anonimal
**\<i2p-relay> {-anonimal}** Thanks for understanding fluffypony.
**\<i2p-relay> {-fluffypony}** my apologies
**\<i2p-relay> {-fluffypony}** I must've misunderstood the timing discussion
**\<i2p-relay> {-anonimal}** fluffypony: apologies accepted! Are #monero-dev meetings now at 17:00 or 18:00
**\<i2p-relay> {-anonimal}** (fluffypony: we're idling on 7. Confirm next meeting date/time)
**\<i2p-relay> {-fluffypony}** anonimal: let's update after the Monero meeting
**\<i2p-relay> {-anonimal}** Alright, I'll start with 17:00
**\<i2p-relay> {-anonimal}** Meeting in two weeks.
**\<i2p-relay> {-anonimal}** Thanks everyone!
**\<i2p-relay> {-olark}** Good talk everyone :D
\ No newline at end of file
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-11-13
summary: Meta repository, Fluffy Blocks, and official GUI
tags: [dev diaries, core, crypto, 0mq]
author: dEBRUYNE / fluffypony
---
*November 13th, 2016*
# Overview
An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-dev-meeting-note-highlights-2016-11-13).
# Logs
**\<@ArticMine>** Hi
**\<+moneromooo>** Oh hi
**\<@fluffypony>** oh and pigeons
**\<Softich>** allright boys, get it started :P
**\<@fluffypony>** and tewinget
**\<medusa_>** Jaquee ping too
**\<pigeons>** hi
**\<@fluffypony>** ok so let's start with an infrastructure update
**\<Jaquee>** hi!
**\<@fluffypony>** pigeons: how goes it
**\<pigeons>** good
**\<@fluffypony>** pigeons: do you want to tell people about the new repo we're using for issues?
**\<pigeons>** github.com/monero-project/meta
**\<Softich>** https://github.com/monero-project/meta
**\<_Slack> \<nanoakron>** Please explain?
**\<Softich>** for the lazy
**\<pigeons>** for stuff realted to build machines, build infrastructure, etc
**\<pigeons>** anonimal has been using it some to get things setup for kovri needs
**\<pigeons>** so feel free
**\<luigi1112>** I got some emails about issues
**\<luigi1112>** I was like cool
**\<@fluffypony>** ok so
**\<@fluffypony>** please use /meta for organisational issues
**\<@fluffypony>** "organisational" as in something that isn't project specific
**\<_Slack> \<nanoakron>** Roger
**\<pigeons>** there is also an empty repo there now, i'll check in some build infrastructure settings there and vm templates
**\<i2p-relay> {-anonimal}** pigeons: can I PM you on Irc2p or are you AFK from that instance?
**\<pigeons>** yes i'm online there
**\<i2p-relay> {-anonimal}** \* has to leave soon
**\<@fluffypony>** ok so
**\<_Slack> \<nanoakron>** Ha
**\<_Slack> \<nanoakron>** Ja
**\<@fluffypony>** we've had quite a few PRs merged in the last 2 weeks
**\<@fluffypony>** some big things like "fluffy blocks" that need testing and fiddling to check for edge cases
**\<_Slack> \<nanoakron>** Can I run a testnet client in parallel with my main net one from the same box?
**\<@fluffypony>** yes I do
**\<@fluffypony>** on my laptop
**\<iDunk>** i also do
**\<_Slack> \<nanoakron>** Could you make some details public, maybe in the readme?
**\<_Slack> \<nanoakron>** I mean instructions
**\<iDunk>** what details?
**\<@fluffypony>** @NanoAkron for running testnet and mainnet?
**\<_Slack> \<nanoakron>** Yes please
**\<@fluffypony>** ./monerod --testnet
**\<@fluffypony>** ./monerod
**\<iDunk>** start moderod normally for mainnet
**\<@fluffypony>** in two different windows
**\<_Slack> \<nanoakron>** And they're happy to play together?
**\<iDunk>** and monerod --testnet for testnet
**\<medusa_>** yes very happy
**\<pero>** needs annotated screenshots imho
**\<luigi1112>** they play separately
**\<medusa_>** like 2 small pupies
**\<_Slack> \<nanoakron>** Ok cool.
**\<_Slack> \<nanoakron>** Will get that up and running when I'm home next week.
**\<iDunk>** you also need to start monero-wallet-cli --testnet
**\<iDunk>** for a testnet wallet
**\<_Slack> \<nanoakron>** Are there any decisions on making the whole network fluffy at the next hardfork?
**\<+moneromooo>** Veto.
**\<@fluffypony>** I think they're already enabled by anyone running a node that supports it
**\<iDunk>** it is not necessary
**\<luigi1112>** not next like jan
**\<luigi1112>** and it doesn't need a fork?
**\<gingeropolous>** right. it doesn't need a fork.
**\<@fluffypony>** the fork would only have been done to avoid old nodes showing weird error messages
**\<iDunk>** client that support fluffy blocks talk fluffy
**\<@fluffypony>** but honestly it's not a big deal
**\<iDunk>** and those that don't, don't afaik
**\<_Slack> \<nanoakron>** But to make it compulsory. Reducing block sizes would also help obfuscation.
**\<+moneromooo>** It kind of is. If there's a nasty bug once close to 100% of the nodes switched, boom.
**\<iDunk>** there is no block size reduction
**\<dEBRUYNE>** \<pero> #58 is not fixed \<= apologies, should be reopened then
**\<_Slack> \<nanoakron>** There's no block size reduction? I think you're mistaken
**\<@fluffypony>** @NanoAkron it doesn't reduce block size, just reduces traffic
**\<+moneromooo>** He is not.
**\<iDunk>** nonaoakron: i am nitz
**\<iDunk>** not*
**\<iDunk>** lol
**\<@fluffypony>** ie. you have the transactions already in the mempool, so no need to re-send them
**\<@fluffypony>** but the block size stays the same
**\<+moneromooo>** Hi nitz.
**\<_Slack> \<nanoakron>** Yes ok I wasn't precise enough
**\<iDunk>** :)
**\<+moneromooo>** hi
**\<_Slack> \<nanoakron>** It reduces block transmission and reduplication, reducing overall network traffic and 'burstiness'
**\<@fluffypony>** yes
**\<_Slack> \<nanoakron>** Thereby improving obfuscation efforts ;)
**\<@fluffypony>** ok
**\<_Slack> \<nanoakron>** And kovri
**\<_Slack> \<nanoakron>** Should also benefit
**\<+moneromooo>** Can we leave that till after we're done with the meeting though ?
**\<_Slack> \<nanoakron>** Due to packet size reduction and traffic reduction. Good reasons to make it compulsory at some point in the future.
**\<gingeropolous>** ^^
**\<_Slack> \<nanoakron>** Ok will leave it now.
**\<@fluffypony>** @NanoAkron it *is* compulsory
**\<@fluffypony>** ok so
**\<_Slack> \<nanoakron>** Ja
**\<@fluffypony>** Jaquee / medusa_ could you give us a GUI update, based on the stuff that's been done in the past 2 weeks ?
**\<Jaquee>** yeah
**\<Jaquee>** We've made great progress last couple of weeks. A lot of great contributions and inputs from new people. Great to see!
**\<Jaquee>** All critical issues i know of are fixed and we have a very good looking, working gui with all basic functionality in place.
**\<Jaquee>** I believe next step is building binaries to make it possible for more people to test it
**\<@fluffypony>** ok
**\<Jaquee>** Since the 0.10 daemon isnt compatible with gui we also need to make sure we have a working monerod build to release with the gui.
**\<@fluffypony>** we'll try couple that with a new 0.10 point release
**\<Softich>** nice, can you give us an ETA for the download? :)
**\<Jaquee>** sounds good
**\<@fluffypony>** so it will take a couple of days to wrap up a point release too
**\<Jaquee>** ok. makes sense
**\<_Slack> \<nanoakron>** Can I ask about translations/localisation?
**\<Jaquee>** yes
**\<@fluffypony>** sure
**\<Jaquee>** i haven't worked on those parts very much though. but i can try to answer your questions.
**\<_Slack> \<nanoakron>** Is there an easy way I could try to translate some stuff for you - I speak a bit of Malay. Is there a transifex or maybe a way to scan the transifex of another coin (ahem) and pull in their translations?
**\<Jaquee>** i think dEBRUYNE is planning to publish the translation files somewhere.
**\<dEBRUYNE>** I've been intending to put the strings up on transifex, but I have spent the time that I had on testing in the last few weeks
**\<dEBRUYNE>** And it's a bit of a pita to get the strings out
**\<_Slack> \<nanoakron>** Makes more sense to test right now anyway
**\<maitscha>** today I tried to update german translations, but there seems to be a bug choosing the language (at least under macos)
**\<Jaquee>** maitscha: i'm not sure if translations are fully implemented yet
**\<medusa_>** yes we took them out basically
**\<_Slack> \<nanoakron>** Some wizard could probably whip up a way to pull translations from another coin... ;)
**\<medusa_>** to get it as stable a spossible for now
**\<maitscha>** ok, I think the translation stuff needs some fixes to get it working. should we open a ticket?
**\<Jaquee>** maitscha: yes please
**\<Jaquee>** speaking of issues...
**\<Jaquee>** the issue page is hard to grasp sometimes. Labels would help out alot. is that possible somehow?
**\<@fluffypony>** yes
**\<@fluffypony>** we have a small issue with that in that only collaborators can add labels
**\<@fluffypony>** and GitHub aren't adding fine-grained permissions for non-collaborators
**\<Jaquee>** ok. and collaborator = write access right?
**\<@fluffypony>** yes
**\<@fluffypony>** so it's too much of a security risk to hand out
**\<Jaquee>** yes. ofc
**\<@fluffypony>** my suggestion is that we have a Google Docs spreadsheet
**\<@fluffypony>** with a column for each label
**\<@fluffypony>** and then issue number -> mark the appropriate columns
**\<@fluffypony>** and I'll go and add labels
**\<medusa_>** personally i think we should increase the circel of caloborators by at least 1
**\<@fluffypony>** medusa_: the entire Core Team have access
**\<medusa_>** it seemed to me it is hard to keep track, at least this week
**\<medusa_>** also for core?
**\<@fluffypony>** the issue is that the people that can manage issues != the people that can be responsible for merging code
**\<Jaquee>** yeah. how is your work load currently fluffypony? would it make sense to have more ppl doing merges in the future?
**\<@fluffypony>** (most of the time anyway)
**\<medusa_>** im fine with that, just make sure those people capable can also merge to monero-core in case we have a small "merge jam"
**\<@fluffypony>** Jaquee: my work load is fine when the in-laws aren't visiting
**\<medusa_>** haha
**\<Jaquee>** fluffypony: lol ok
**\<_Slack> \<nanoakron>** I think it would be reasonable to give mooo merge access as a paid major contributor who has demonstrated talents
**\<_Slack> \<nanoakron>** Lol FP...I know the feeling
**\<@fluffypony>** I'm trying to let PRs sit for a while so that other people review them besides me
**\<medusa_>** yes but sometimes if we are active that causes issues
**\<Jaquee>** makes sense. there were a lot of code conflicts last week that could have been avoided
**\<medusa_>** or can cause issues
**\<@fluffypony>** medusa_: merging stuff rapidly is a bad idea, we need eyes on code
**\<Jaquee>** \*merge conflicts
**\<+moneromooo>** I asked for PRs to stay open for a while so I have a change to see htem and review (monero repo anyway).
**\<@fluffypony>** which means small PRs, that multiple people have looked at
**\<@fluffypony>** I know it means that some PRs have to be rebased 3 times (sorry moneromooo)
**\<medusa_>** i agree the right balance isnt easy, im sure we get the balance again
**\<@fluffypony>** but it's better than stuff slipping in to the code
**\<medusa_>** normally it also wroks well
**\<+moneromooo>** No worries, it's less work than making them in the first place usually :)
**\<medusa_>** this week was pretty extreme in all forms
**\<@fluffypony>** medusa_: the QML stuff is pretty rough in terms of merge conflicts too
**\<endogenic>** maybe there can be a structure where the required reviewers are identified by the master maintainer, notified, and must sign off before the thing can be merged ?
**\<_Slack> \<nanoakron>** I agree that issues should sit and ferment for a while, but sometimes there are hotfixes required like with fluffy blocks
**\<@fluffypony>** endogenic: too structured; has a bus factor
**\<gingeropolous>** is dev branch happening?
**\<@fluffypony>** gingeropolous: no not atm
**\<Jaquee>** ok. security first. i'm sure it works ok most of the time. 2 last weeks was extreme.
**\<@fluffypony>** indeed
**\<Jaquee>** but we could keep this in mind and evaluate further on?
**\<medusa_>** yes you stay on watch ;-)
**\<Jaquee>** :D
**\<@fluffypony>** Jaquee: yes absolutely
**\<gingeropolous>** would the dev branch approach be a way to get around the merge "bottleneck" ? i assume its still complicated b/c of zeromq..
**\<gingeropolous>** or are u talking about core. (i will shut up now)
**\<_Slack> \<nanoakron>** What's the plan if something horrible happens to you FP, like going on holiday for a month without internet access?
**\<proxmr>** Hello guys
**\<@fluffypony>** gingeropolous: no, you still can't have fine-grained collaborators on a per-branch basis
**\<endogenic>** nanoakron: dead pony switch?
**\<_Slack> \<nanoakron>** Lol. Yeah :) (also :( )
**\<endogenic>** yeah
**\<endogenic>** :’(
**\<Jaquee>** but you can have branch specific permissions right?
**\<Jaquee>** not sure if it would help though.
**\<maitscha>** "protected branches"
**\<@fluffypony>** Jaquee: you can, and it might be worth fiddling with later on
**\<Jaquee>** all right
**\<Jaquee>** imo we can leave this subject for now.
**\<Jaquee>** any more questions regarding the gui?
**\<asdef>** irc logs anywhere? for people who came too late
**\<proxmr>** Is the gui coming in 2 days ?
**\<maitscha>** Jaquee: how can I start the GUI under MacOS and get the console output?
**\<@fluffypony>** proxmr: no, that's not how software development works
**\<Jaquee>** maitscha: one sec
**\<maitscha>** Jaquee: that would help debugging ...
**\<Jaquee>** maitscha: build/release/bin/monero-core.app/Contents/MacOS/monero-core
**\<asdef>** any screenshots already existing? so we can see an be happy?
**\<Jaquee>** in monero-core dir
**\<proxmr>** Sorry, some guy just told me on some forum, so i came to check. i appologize
**\<maitscha>** ah ok
**\<iDunk>** maitscha: doesn't it give outout when started from the command line like on linux?
**\<medusa_>** asdef: check reddit
**\<_Slack> \<nanoakron>** No worries.
**\<maitscha>** I always started it with the finder
**\<dEBRUYNE>** Please don't interrupt the dev meeting
**\<Jaquee>** iDunk: yes. but it's not that easy to find the binary
**\<Jaquee>** it's in the .app package
**\<iDunk>** ok
**\<maitscha>** Jaquee: works, thanks
**\<Jaquee>** yw
**\<Jaquee>** all right.
**\<Jaquee>** more gui related?
**\<_Slack> \<nanoakron>** None here
**\<maitscha>** there are at least 2 people who would like to make a style guide
**\<_Slack> \<nanoakron>** That's a good idea
**\<maitscha>** should this be coordinated?
**\<medusa_>** i think the best place to discuss specific stuff is either on github or here in the channel
**\<Jaquee>** yes. that would be good. not sure how. but i can ask them to get in contact with each other to start
**\<vertp>** Can we discuss an issue freeze for the beta release? I think we have all the features we need for an "MVP" and there doesnt seem to be any major outstanding bugs.
**\<maitscha>** or at least a place where people can post design/ux-related improvements?
**\<@fluffypony>** github
**\<Guest5849>** Confused ... ? Quote: \<@fluffypony> so it will take a couple of days to wrap up a point release too. Does that not relate to the GUI being released?
**\<_Slack>** **\<tfi_charmers>** Yes, styleguide, one was me. I’m still able to help.
**\<@fluffypony>** Guest5849: a beta, yes
**\<medusa_>** vertp: the features are basically freezed, we just change what we think is worth changing (and the treshold for that goes up each day)
**\<@fluffypony>** vertp: "freezing" things doesn't really work for a fluid open-source project
**\<_Slack> \<nanoakron>** Where's the best place to coordinate a style guide? A new Git repo or a wiki?
**\<medusa_>** always considering risk reward ofc
**\<@fluffypony>** people open issues, they get fixed, eventually you hit enough milestones / new features for a new release
**\<vertp>** I mean freeze in the sense that of course you allow new issues to be open, but the work is prioritized based on existing issues and bugs
**\<@fluffypony>** vertp: can't really force someone to work on anything
**\<maitscha>** vertp: you can't stop people from working on features ;)
**\<@fluffypony>** so if people want to work on new features instead of tackling bugs that's their prerogative
**\<vertp>** I agree, I mean more for illya and jaquee
**\<pero>** generally an 'issue freeze' is a bad idea
**\<@fluffypony>** can't force them either ;)
**\<medusa_>** vertp: we have to always allow people opening issues. their feedback is very valuable
**\<pero>** a feature freeze is an entirely different thing and is already somewhat implemented
**\<vertp>** I agree medusa_
**\<Jaquee>** vertp: me and ilya are more or less frozen for the moment. :P
**\<@fluffypony>** yes
**\<Jaquee>** as in agreed on that current version can be released as beta
**\<_Slack> \<nanoakron>** Vertp: we just follow a simple alpha -> beta -> release methodology, keeping in mind that even point releases are beta software under constant development
**\<vertp>** Awesome, thats what I was going for Jaquee
**\<vertp>** I just feel that its stable enough at this point to justify a beta without doing any additional feature dev. Thats what I meant by issue freeze
**\<vertp>** Which I think we all agree on
**\<Jaquee>** yes
**\<vertp>** great!
**\<medusa_>** yes wa try to be very pragmatic
**\<_Slack> \<nanoakron>** This has side tracked us slightly. Where's the best place to coordinate a style document?
• moneromooo: eyes this suspiciously
**\<@fluffypony>** Github has this new thing called Projects
**\<iDunk>** wat
**\<Jaquee>** nanoakron. not sure. github best place for the moment
**\<@fluffypony>** aI want to play with it and see if it's suitable for that
**\<_Slack> \<nanoakron>** Cool
**\<Jaquee>** fluffypony: sounds interesting.
**\<Jaquee>** tfi_charmers: can you sync with that other ux guy?
**\<_Slack> \<nanoakron>** Does sound interesting
**\<Jaquee>** so you don't end up working on the same issues
**\<@fluffypony>** ok - can we call this meeting done?
**\<_Slack>** **\<tfi_charmers>** @jaquee can do.
**\<Jaquee>** great
**\<Jaquee>** fluffypony: yes
**\<@fluffypony>** ok tks
**\<+moneromooo>** Just one thing before: when does someone else do the builds ?
**\<_Slack> \<nanoakron>** I was going to raise the issue of databases if hyc, fp and mooo are in the same room
**\<iDunk>** hyc is roaming belfast
**\<_Slack> \<nanoakron>** A veritable vipers nest of opinions ;)
**\<iDunk>** anyway, i'm with fluffypony and moneromooo on the db issue
**\<_Slack> \<nanoakron>** Why do we need the ability to iterate and test the database back end in production code?
**\<_Slack> \<nanoakron>** And aren't we effectively overruling our resident database expert, hyc?
• moneromooo: facepalms
**\<iDunk>** ^
**\<gingeropolous>** where's this discussion? i totally missed this one. not that I can do anything.
**\<_Slack> \<nanoakron>** It's a PR of mine
**\<_Slack> \<nanoakron>** Mooo, why the facepalm? When or where are we going to need to change the database away from LMDB in the future in such a way that we need the selection code?
**\<_Slack> \<nanoakron>** As it stands we're shipping code thats never run, with requirements that are never used.
**\<+moneromooo>** Because being an expert in databases does not extend to having an expert opinion on whether a selection system in a particular project is best or not.
**\<+moneromooo>** And not knowing the particulars of a future db implementation does not by itself imply any groundworks should be dismantled at once.
**\<gingeropolous>** and the prebuild binaries are all LMDB, right? so its not like anything's being shipped...
**\<gingeropolous>** \*prebuilt
**\<+moneromooo>** The current ones all are, yes.
**\<dogecoinsarefun>** fluffyblocks still LMDB too right?
**\<+moneromooo>** Unrelated.
**\<dogecoinsarefun>** ok sorry
**\<+moneromooo>** I mean, this was an obvious appeal to authority, in a context where the authority is only tangential.
**\<+moneromooo>** I find it counterproductive to remove a useful thing, if its removal will make it a lot easier to break the ability to add another db. It's not like it's a lot of code I think.
**\<iDunk>** agreed
**\<+moneromooo>** There was a all RAM db being worked on, though I'm not sure it still is.
**\<_Slack> \<nanoakron>** So has the compiler been smart enough to strip the selection stuff or is there still bloat and overhead that could be trimmed?
**\<_Slack> \<nanoakron>** Appeal to authority is only a fallacy when the authority is not relevant to the issue at hand
**\<@ArticMine>** There was at one point the idea that Monero could use different databases in the future.
**\<+moneromooo>** You actually might make a good argument by removing it all and see whether performance figures support you bloat claim.
**\<_Slack> \<nanoakron>** I'll try that
**\<+moneromooo>** Now, the threshold where an improvement becomes larger than the loss of generality is pretty subjective too.
**\<_Slack> \<nanoakron>** As for the PR - would you reject it for stripping out the Berkeley DB selection in CMakeLists.txt, or is that acceptable because we're not going back to BDB?
**\<gingeropolous>** is it just for compiling performance?
**\<+moneromooo>** IIRC, I said keep the selcetion code, just remove the bdb option.
**\<_Slack> \<nanoakron>** I'm happy to keep the selection code in the main body, but are you happy with the structure of the current PR wrt stripping BDB from CMakelists.txt? There wasn't a selector in there afaik
**\<+moneromooo>** Basically, you should be able to add another db by duplicating the lmdb bits. Anything that's shared needs to stay for this to be useful.
**\<_Slack> \<nanoakron>** I'm happy to leave the selector alone in the main code
**\<+moneromooo>** In the details ? I'll have to go read the code to know for sure.
**\<+moneromooo>** And I'm busy debugging some cold signing stuff now, so that'll be later.
**\<_Slack> \<nanoakron>** Understood. Please have a look at the PR and what's been stripped wrt BDB when you can. If that's still to much then I'll close and amend. By the time we get to using additional databases the CMakeLists file will have been changed many more times anyway.
**\<_Slack> \<nanoakron>** And the final thing I wanted to ask today was whether FP could keep killing cold issues ;)
**\<_Slack> \<nanoakron>** Tis all from me
\ No newline at end of file
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-11-27
summary: Brief review of what has been completed since last meeting, Alpha release, and code & open tickets discussion
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*November 27th, 2016*
# Logs
**\<i2p-relay> {-fluffypony}** ok anonimal
**\<i2p-relay> {-fluffypony}** Kovri meeting start, all yours
**\<i2p-relay> {-meeting-bot} [anonimal]** 1. Greetings
**\<i2p-relay> {-meeting-bot} [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<i2p-relay> {-meeting-bot} [anonimal]** 3. Status of alpha release preparations - https://github.com/monero-project/kovri/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20milestone%3A0.1.0-alpha%20
**\<i2p-relay> {-meeting-bot} [anonimal]** 4. Code + ticket discussion / Q & A
**\<i2p-relay> {-meeting-bot} [anonimal]** 5. Any additional meeting items
**\<i2p-relay> {-meeting-bot} [anonimal]** 6. Confirm next meeting date/time
**\<i2p-relay> {-meeting-bot} [anonimal]** Hi
**\<i2p-relay> {-meeting-bot} [anonimal]** 1.
**\<i2p-relay> {-fluffypony}** hi
**\<i2p-relay> {-guzzi}** hi
**\<i2p-relay> {-fluffypony}** asl?
**\<ArticMine>** Hi
**\<i2p-relay> {-iDunk}** hi
**\<i2p-relay> {-olark}** Greetings
**\<moneromooo>** Hi
**\<i2p-relay> {-meeting-bot} [anonimal]** Hi fluffypony guzzi olark iDunk ArticMine moneromooo
**\<i2p-relay> {-meeting-bot} [anonimal]** EinMByte is idling as are the others, afaict.
**\<i2p-relay> {-meeting-bot} [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<binaryFate>** late greetings. watching.
**\<i2p-relay> {-meeting-bot} [anonimal]** I'll keep it generic: bug fixes (many were difficult bugs) + refactoring, mentoring, and research.
**\<i2p-relay> {-meeting-bot} [anonimal]** *Poof!* done.
**\<i2p-relay> {-meeting-bot} [anonimal]** Anything else on 2? :)
**\<i2p-relay> {-fluffypony}** can I add to 2?
**\<i2p-relay> {-meeting-bot} [anonimal]** git log and github are available for details.
**\<i2p-relay> {-meeting-bot} [anonimal]** Of course fluffypony
**\<i2p-relay> {-fluffypony}** I'd like to congratulate anonimal on completing his first milestone, even if he won't admit to it yet :-P
**\<i2p-relay> {-fluffypony}** first full-time FFS "employee", first milestone :)
**\<i2p-relay> {-meeting-bot} [anonimal]** Grr! Well, thank you fluffypony.
**\<i2p-relay> {-guzzi}** and thanks for mentoring.
**\<i2p-relay> {-fluffypony}** and we didn't even need to blockchain it!
**\<i2p-relay> {-olark}** Good work. ;)
**\<i2p-relay> {-meeting-bot} [anonimal]** Because of the large amount of non-code work, I hadn't felt comfortable with a payout yet. I'll get to that this week.
**\<i2p-relay> {-fluffypony}** I think everyone here will attest to the amount of work you do
**\<i2p-relay> {-guzzi}** no doubt.
**\<i2p-relay> {-meeting-bot} [anonimal]** No problem guzzi, thank *you* for your great progress.
**\<i2p-relay> {-fluffypony}** "anonimal made me the man I am today" - fluffypony, 2016
**\<i2p-relay> {-olark}** He's called anonimal for a reason haha
**\<i2p-relay> {-fluffypony}** olark: coupled with my quote I think that's one for the history books
**\<i2p-relay> {-meeting-bot} [anonimal]** lol oh you guys, thanks for acknowledgements. I'm glad to be here with you all.
**\<i2p-relay> {-meeting-bot} [anonimal]** I'd love to dwell on the work accomplished over the past two weeks but I think we can move on, any objections?
**\<i2p-relay> {-guzzi}** onward
**\<i2p-relay> {-fluffypony}** let's move on
**\<i2p-relay> {-meeting-bot} [anonimal]** 3. Status of alpha release preparations - https://github.com/monero-project/kovri/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20milestone%3A0.1.0-alpha%20
**\<i2p-relay> {-meeting-bot} \* anonimal** clicks
**\<i2p-relay> {-meeting-bot} [anonimal]** Ok, don't be alarmed, but it's actually not a lot if you look carefully.
**\<i2p-relay> {-meeting-bot} [anonimal]** Some of these can even be moved to next milestone if needed.
**\<i2p-relay> {-meeting-bot} [anonimal]** fluffypony: can you give a status on 33c3 and your thoughts on a release (like we spoke about earlier)?
**\<i2p-relay> {-fluffypony}** yes
**\<i2p-relay> {-fluffypony}** so our original plan was to co-host an assembly with i2p at 33C3
**\<i2p-relay> {-fluffypony}** basically hosting an i2p + Monero table
**\<i2p-relay> {-fluffypony}** and then have the Kovri alpha ready by then
**\<i2p-relay> {-fluffypony}** unfortunately this year's congress ticketing setup has been a mess
**\<i2p-relay> {-fluffypony}** through no fault of their own, this is the most popular CCC ever
**\<i2p-relay> {-fluffypony}** we tried to book 10+ tickets at all 3 of the public booking dates
**\<i2p-relay> {-fluffypony}** and got nothing
**\<i2p-relay> {-meeting-bot} [anonimal]** Wow, that's insane.
**\<i2p-relay> {-fluffypony}** I managed to get tickets for myself and othe, after the fact
**\<i2p-relay> {-fluffypony}** but it's not enough to man a table - we'd have needed 8+ community members for htat
**\<i2p-relay> {-fluffypony}** that
**\<i2p-relay> {-fluffypony}** in view of the foregoing, we're no longer obligated to hit our alpha release date
**\<i2p-relay> {-meeting-bot} [anonimal]** Ok, well that's great to hear you at least got two tickets.
**\<i2p-relay> {-fluffypony}** this doesn't mean we won't stick to it, but it means we can choose how we want to plan it
**\<i2p-relay> {-meeting-bot} [anonimal]** Ok, well here are my thoughts on the reality of the situation, I'll try to choose my words wisely:
**\<i2p-relay> {-meeting-bot} [Jake__]** Is their any news on the GUI beta binaries.
**\<i2p-relay> {-meeting-bot} [fluffypony]** Jake__: this is the Kovri meeting
**\<i2p-relay> {-meeting-bot} [fluffypony]** you can ask later
**\<i2p-relay> {-meeting-bot} [Jake__]** Nvm
**\<i2p-relay> {-meeting-bot} [Jake__]** My mistake
**\<i2p-relay> {-meeting-bot} [anonimal]** even with all milestone issues resolved, the release wouldn't be a spectacular one, and frankly may have more negative consequences than positive.
**\<i2p-relay> {-meeting-bot} [anonimal]** I mean, sure, I can most likely get everything done in time, but is it really worth it?
**\<i2p-relay> {-fluffypony}** anonimal: that's fair
**\<i2p-relay> {-meeting-bot} [anonimal]** The packaging aspect alone will be 'fun' to deal with, *especially* come upgrade time.
**\<i2p-relay> {-fluffypony}** are we auto-upgrading ala Java i2p?
**\<i2p-relay> {-meeting-bot} [anonimal]** And really, an auto-updater would be great on that front - and that's not terribly hard to do now that more work has been done elsewhere.
**\<i2p-relay> {-meeting-bot} [anonimal]** We wouldn't if we released this month unless I dropped other higher priority issues.
**\<i2p-relay> {-meeting-bot} \* anonimal** thinking
**\<i2p-relay> {-fluffypony}** look
**\<i2p-relay> {-fluffypony}** zzz2 will attest to the fact that part of i2p's network stability is due to the auto-updater
**\<i2p-relay> {-fluffypony}** so let's not rush something out that doesn't have that
**\<moneromooo>** Do I understand code that will fetch more code and run it on the user's machine ? Unprompted ?
**\<moneromooo>** Or merely tell the user there's an update to install at their earliest convenience ?
**\<i2p-relay> {-fluffypony}** moneromooo: it's opt-out, yes
**\<moneromooo>** That;s not nice.
**\<i2p-relay> {-fluffypony}** moneromooo: you could do a decaying prompt
**\<moneromooo>** What is this ?
**\<i2p-relay> {-fluffypony}** prompt the user, if after 15 days they haven't installed it, then install it for them
**\<i2p-relay> {-meeting-bot} [anonimal]** The current UI does not provide any useful control to an end-user.
**\<moneromooo>** I suppose that's less nasty.
**\<i2p-relay> {-fluffypony}** moneromooo: there's just been a spate of bannings on the network, of old clients that aren't updated
**\<i2p-relay> {-fluffypony}** if there's data leakage on older clients it can compromise newer ones
**\<i2p-relay> {-fluffypony}** so it's not something to be taken lightly
**\<i2p-relay> {-meeting-bot} [anonimal]** So, we could fix that first and then focus on release imho. Really who benefits from a release? Will it be developers? Will developers suddenly become more interested in kovri? Or is it purely for the end-user's benefit?
**\<i2p-relay> {-fluffypony}** end users
**\<i2p-relay> {-fluffypony}** do we even have a stable API for devs?
**\<i2p-relay> {-guzzi}** realease implies end users imo.
**\<i2p-relay> {-meeting-bot} [anonimal]** Nope, more router issues to fix first.
**\<i2p-relay> {-fluffypony}** ok so then end users :)
**\<i2p-relay> {-meeting-bot} [anonimal]** I agree with guzzi, but I still like the idea of feeling accomplished with a release by the end of the year.
**\<i2p-relay> {-meeting-bot} [anonimal]** I guess anything called "release" will hold a certain weight,
**\<i2p-relay> {-meeting-bot} [anonimal]** Maybe we can compromise, find a middle-ground somehow.
**\<i2p-relay> {-fluffypony}** true
**\<i2p-relay> {-meeting-bot} [anonimal]** I'd like to work with pigeons on nightly releases, that could be a start.
**\<i2p-relay> {-meeting-bot} [anonimal]** I don't think we'll have the website done in time (will we?)