monero-project/monero-site
monero-project/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2024-11-16 15:58:16 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

fix meeting logs

Browse source
This commit is contained in:
Riccardo Spagni 2016-11-02 18:06:08 +02:00
parent 291beb4d1c
commit 5a141b9aac
No known key found for this signature in database
GPG key ID: 55432DF31CCD4FCD
2 changed files with 645 additions and 645 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

864
_posts/2016-10-02-logs-for-the-Kovri-dev-meeting-held-on-2016-10-02.md
View file

@ -6,442 +6,442 @@ tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*October 2nd, 2016*
# Overview
An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-and-kovri-dev-meeting-note-highlights-2016-10-02)
*October 2nd, 2016*
# Logs
**\<fluffypony>** anonimal: all yours :)
**\<meeting-bot> [anonimal]** 1. Greetings
**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** 3. ∫alti https://github.com/EinMByte/salti
**\<meeting-bot> [anonimal]** 4. "Kovri Garlic Router Project" + logo
**\<meeting-bot> [anonimal]** 5. #46
**\<meeting-bot> [anonimal]** 6. #337 https://geti2p.net/en/docs/naming
**\<meeting-bot> [anonimal]** 7. API discussion with `#monero-dev` (#350 #351)
**\<meeting-bot> [anonimal]** 8. Code + ticket discussion / Q & A
**\<meeting-bot> [anonimal]** 9. Any additional meeting items
**\<meeting-bot> [anonimal]** 10. Confirm next meeting date/time
**\<meeting-bot> [anonimal]** 1. Greetings
**\<meeting-bot> [i2p-relay] {-moneromooo}** UDP meeting
**\<meeting-bot> [anonimal]** Hi
**\<meeting-bot> [EinMByte]** Hi
**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** Areas of work done or completed since last meeting 3 weeks ago:
**\<meeting-bot> [anonimal]** - Transports improvements/fixes and EinMByte's SSU branch was merged!
**\<meeting-bot> [anonimal]** - Client/app improvements/fixes and client-crypto related (client signing type, https ciphers, etc.)
**\<meeting-bot> [anonimal]** - Almost all Coverity issues resolved, still a handful left
**\<meeting-bot> [anonimal]** - Fixes/enhancements and more
**\<meeting-bot> [anonimal]** - pero's fantastic work with the logo
**\<meeting-bot> [anonimal]** Oh, .ny new open issues - that's a good thing though, right? ;)
**\<fluffypony>** lol
**\<meeting-bot> [anonimal]** Anything else did I miss for 2. or move onto 3.?
**\<meeting-bot> [EinMByte]** No, go ahead. I have only limited time so let's be productive
**\<fluffypony>** 3 plz
**\<meeting-bot> * anonimal** having hard time keeping track of all the work that passes over several weeks; its usually a very broad range of areas
**\<meeting-bot> [anonimal]** 3. ∫alti https://github.com/EinMByte/salti
**\<meeting-bot> [anonimal]** So, EinMByte and I are starting preliminary work on a firefox extension that will tremendously help Kovri and I2P
**\<meeting-bot> [anonimal]** I just want to mention this here in case there are any interested webdevs
**\<meeting-bot> [anonimal]** Anything you want to add EinMByte?
**\<fluffypony>** Salti is basically like the Kovri GUI :-P
**\<meeting-bot> [EinMByte]** fluffypony: No it isn't
**\<meeting-bot> [EinMByte]** The kovri GUI is called qtoopie
**\<meeting-bot> [anonimal]** EinMByte: no, the GUI does not exist yet.
**\<meeting-bot> [anonimal]** qtoopie is an i2pcontrol client.
**\<meeting-bot> [EinMByte]** Salti is a firefox add-on similar to Tor browser bundle
**\<fluffypony>** lol
**\<meeting-bot> [EinMByte]** anonimal: Yes (but see also the relevant zzz.i2p thread from long ago)
**\* fluffypony** was making a joke
**\<meeting-bot> * anonimal** doesn't have time to search zzz.i2p, link appreciated
**\<meeting-bot> [anonimal]** Any webdevs present?
**\<meeting-bot> * EinMByte** doesn't have time to find zzz.i2p topic
**\<patthehuman>** i could technically be a webdev
**\<patthehuman>** im c/c++ swift/obj-c nodejs/MEAN stack
**\<meeting-bot> [anonimal]** Hi patthehuman. Have you done any work with firefox add-ons?
**\<patthehuman>** no, however, i dont think it would be very difficult
**\<meeting-bot> [EinMByte]** We won't be needing very complex stuff by the way, just using the webextensions API
**\<patthehuman>** would it be chrome and firefox..?
**\<meeting-bot> [anonimal]** patthehuman: webext I believe could support both? but we're aiming for firefox.
**\<meeting-bot> [EinMByte]** (we'll be setting a few settings and intercepting a few requests)
**\<meeting-bot> [EinMByte]** patthehuman: yes
**\<patthehuman>** mk
**\<meeting-bot> [anonimal]** patthehuman: we can give more details after the meeting if you idle #kovri-dev
**\<meeting-bot> [EinMByte]** (although initially firefox, but the API should be mostly the same)
**\<patthehuman>** ok
**\<meeting-bot> [anonimal]** Anything else on 3.?
**\<patthehuman>** ill stick around, interested in hearing full scale
**\<meeting-bot> [EinMByte]** Let's move to 4
**\<meeting-bot> [anonimal]** 4. "Kovri Garlic Router Project" + logo
**\<meeting-bot> [anonimal]** pero: you there?
**\<pero>** yep
**\<pero>** want me to take over?
**\<meeting-bot> [anonimal]** What do you have for us today?
**\<meeting-bot> [anonimal]** Let's spend very little time with the visual aspect, we have bigger issues to tackle with kovri
**\<meeting-bot> [anonimal]** Just a run down so everyone knows where we are
**\<meeting-bot> [anonimal]** And links if possible
**\<pero>** http://imgur.com/a/ptOHb
**\<pero>** after a 'long' process we're down to 3 fonts
**\<pero>** the idea is to pick the font with the best looking letters that comprise the word kovri
**\<meeting-bot> [anonimal]** And what about https://i.imgur.com/UDsSuTg.png
**\<pero>** and/or eliminate some concepts
**\<meeting-bot> [anonimal]** I guess Coral is out of the question
**\<patthehuman>** lato second from bottom
**\<pero>** yea coral was cut
**\<pero>** work sans is largely similar and coral seemed inferior on some letters as well as less versatile at smaller font sizes iirc
**\<meeting-bot> [EinMByte]** I'd also drop open sans
**\<pero>** in the 'a' system
**\<pero>** exo 2 is the logo font - but it doesn't work as well for text
**\<pero>** so i chose open sans to complement it
**\<meeting-bot> [EinMByte]** Sorry, I mean the exp 2 / open sans combination
**\<pero>** a5 features exo2 as subtext so you can see how that would look like
**\<meeting-bot> [EinMByte]** But overall, the differences are really minor. Just trying to reduce the search space
**\<pero>** i personally think not going with A or B would be a mistake
**\<pero>** their K is really nice and adds a subtle touch of personality
**\<meeting-bot> [anonimal]** pero: its unfair because I can't accurately compare c4 because of orange subtext
**\<pero>** hmm
**\<meeting-bot> [anonimal]** I prefer work sans because the k contracts with the orange curve in the garlic
**\<meeting-bot> [anonimal]** So is our next step font?
**\<pero>** http://imgur.com/a/DOcyy
**\<meeting-bot> [anonimal]** Is subtext really that thick with work sans? Eww
**\* fluffypony** isn't wild about the orange subtext
**\<pero>** yea the orange subtext sucks imo
**\<meeting-bot> [EinMByte]** Ok, let's handle this another time
**\<meeting-bot> [EinMByte]** (or use a random number generator)
**\<pero>** no it could be thinner
**\<meeting-bot> [EinMByte]** Let's go with column b then
**\<meeting-bot> [anonimal]** lol no way on the random gen
**\<fluffypony>** lol random number gen could be fun
**\<pero>** imgur is also 'optimizing' the png
**\<fluffypony>** "best of 3?"
**\<pero>** keep in mind ^^^
**\<endogenic>** just my two cents - you probably want the text to be relatively heavier than the logo so it jumps out because it's not an english or otherwise generally known word, and so the logo imo should be visually secondary when composed with the name. think about readability, especially if the user doesn't have 20/20 vision or is in a hurry
**\<endogenic>** the actual face itself is not a huge issue imo
**\<meeting-bot> [anonimal]** pero: let's narrow down our options to rows 2, 4, and 6
**\<meeting-bot> [anonimal]** Can you throw those onto a page?
**\<pero>** there probably will be instances where the 'router project' text is unnecessary
**\<fluffypony>** I think rows 3 and 4 won't work because, as endogenic pointed out, kovri is not an English word
**\<fluffypony>** looks like kavri
**\<pero>** and just the logo and kovri would suffice
**\<meeting-bot> [anonimal]** Are we all talking about https://i.imgur.com/Ge1FZTp.png ?
**\<pero>** ideally as a brand it should be able to stand out on its own
**\<meeting-bot> [EinMByte]** Yes, the garlic as an "o" could be confusing
**\<fluffypony>** anonimal no, I'm looking at http://imgur.com/a/DOcyy
**\<meeting-bot> [anonimal]** Same thing
**\<endogenic>** pero: for that reason consider favoring options with tighter kerning
**\<fluffypony>** oh
**\<fluffypony>** lol
**\<meeting-bot> [anonimal]** Who in their right mind things that garlic is an 'A'?
**\<pero>** another thing to add
**\<meeting-bot> [EinMByte]** So let's narrow it down to 2 and 6
**\<meeting-bot> [i2p-relay] {-ArticMine}** 2 in Open Sans is the most readable
**\<pero>** the garlic wasn't designed with this use in mind
**\<pero>** the garlic could be optimized down the road
**\<meeting-bot> [EinMByte]** anonimal: Remember that the spectator potentially doesn't know "kovri"
**\<pero>** ideally after a font has been chosen
**\<pero>** to more resemble an o and to slide seamlessly into the font
**\<meeting-bot> [EinMByte]** At least it might add additional confusion, which is bad
**\<endogenic>** EinMByte: exactly. the question is how it could be confirmed it's not an A
**\<meeting-bot> [anonimal]** Ok, all in favor of exo2
**\<pero>** i'm however not qualified to do that
**\<meeting-bot> [anonimal]** Any votes for exo2/open sans?
**\<meeting-bot> [i2p-relay] {-ArticMine}** Yes
**\<meeting-bot> [EinMByte]** exo2 is fine for me, but I also agree that the "Garlic Routing Project" text should be optional
**\<meeting-bot> [i2p-relay] {-ArticMine}** exo2 is fine
**\<meeting-bot> [EinMByte]** (So on the website, for example, we should have the text. But potentially not everywhere)
**\<meeting-bot> [EinMByte]** Any objections against exo2?
**\<meeting-bot> [anonimal]** I count 2 votes for exo2/open sans.
**\<meeting-bot> [anonimal]** Any votes for Lato?
**\<pero>** i vote lato
**\<meeting-bot> [EinMByte]** Any votes for work sans?
**\<endogenic>** i also like lato
**\<fluffypony>** lato from my side
**\<meeting-bot> [EinMByte]** Ok, let's eliminate work sans.
**\<meeting-bot> [anonimal]** 3 votes for Lato.
**\<meeting-bot> [anonimal]** Any votes for Work Sans?
**\<meeting-bot> [anonimal]** 0 votes for Work Sans
**\<meeting-bot> [anonimal]** I haven't voted
**\<meeting-bot> * anonimal** looks
**\<patthehuman>** i vote for Lato
**\<meeting-bot> [EinMByte]** Are we going to decide on the logo today or not? If so, we should hurry (if we want to discuss API still)
**\<meeting-bot> [anonimal]** pero: why does a6 look so fat?
**\<pero>** shouldn't be that difficult to throw up exo2 versions of lato variants in the future
**\<pero>** in case that's still up for debatable
**\<meeting-bot> [anonimal]** EinMByte that's up to moneromooo because I really don't think anyone else there is interested in API chat (afaict)
**\<pero>** because it is fat :P
**\<patthehuman>** yb
**\<meeting-bot> [i2p-relay] {-ArticMine}** I have to leave
**\<patthehuman> im interested in api cha
**\<endogenic>** maybe we should have a #monero-design? :)
**\<meeting-bot> [anonimal]** EinMByte if we don't decide soon, website doesn't get done
**\<pero>** i went with a heavier weight for that variant arbitrarily
**\<meeting-bot> [i2p-relay] {-moneromooo}** I have no particular wish about that, don't mind me.
**\<fluffypony>** let's move ahead
**\<fluffypony>** the logo already took up the entire last meeting
**\<meeting-bot> [anonimal]** 3 minutes
**\<meeting-bot> [anonimal]** Let me vote please!
**\<meeting-bot> [EinMByte]** We should at least plan when to discuss the API, so let's decide quickly on the logo :)
**\<patthehuman>** LATO
**\<meeting-bot> [anonimal]** pero: why should I choose exo2
**\<pero>** its advantage seems to be technological look
**\<meeting-bot> [EinMByte]** anonimal: Please decide, we're moving too slowly here
**\<pero>** a secondary adv is that we can pair with open sans which is extremely versatile
**\<meeting-bot> [anonimal]** EinMByte, we have 30 minutes, please be patient.
**\<pero>** can be used at extremely small sizes for things like massive tables of data
**\<pero>** whereas using open sans to complement a lato branding scheme wouldn't make much sense
**\<meeting-bot> [anonimal]** pero: how about this: can you whip up another sample for after the meeting but *only* exo2 and lato and doing various sizes that you think are appropriate?
**\<pero>** i think that makes the most sense as a next step
**\<meeting-bot> [anonimal]** We can probably come to a final conclusion post-meeting or sometime this week.
**\<meeting-bot> [anonimal]** Ok, thanks pero.
**\<meeting-bot> [anonimal]** Moving on,
**\<meeting-bot> [anonimal]** 5. #46
**\<meeting-bot> [anonimal]** fluffypony: ^
**\<meeting-bot> [EinMByte]** fluffypony...
**\<pero>** did you skip over the 'garlic router' discussion?
**\<fluffypony>** ok - got a first draft to push up, but need to finish fixing the forum first
**\<meeting-bot> [anonimal]** pero: just go with it for now but also do without subtext too please
**\<meeting-bot> [EinMByte]** ETA?
**\<patthehuman>** whats wrong with the forum?
**\<pero>** ok
**\<fluffypony>** EinMByte: no clue
**\<fluffypony>** patthehuman: PHP7 broke a bunch of stuff
**\<meeting-bot> [anonimal]** patthehuman: fluffypony is fixing it
**\<patthehuman> ok
**\<fluffypony>** some of it was non-obvious until we had a new dep and composer wrecked everything
**\<patthehuman>** ill be around if you need help
**\<meeting-bot> [EinMByte]** Let's not discuss the monero forum here
**\<patthehuman>** php7 wrecked a lot of my shit at work so ive been down this path
**\<patthehuman>** sure
**\<meeting-bot> [anonimal]** fluffypony: should EinMByte and I not ask for ETA for website?
**\<fluffypony>** anonimal: I'll push my changes once the forum is back up, since all static objects are served off that repo anyway
**\<meeting-bot> [anonimal]** Worst case scenario, we release with just a repo and wiki.
**\<meeting-bot> [anonimal]** Ok, moving on
**\<meeting-bot> [anonimal]** 6. #337 https://geti2p.net/en/docs/naming
**\<meeting-bot> [anonimal]** What happens is that any addresses that are saved with an addresshelper are simply inserted into ./addressbook but not user_hosts.txt (or similar)
**\<meeting-bot> [anonimal]** There are also various other issues, let me pull up the ticket
**\<meeting-bot> [anonimal]** "For this ticket, we should discuss if we're to have separate subscription files because we currently only use hosts.txt. Also, if we hand edit the file, it will be overridden upon next fetch from a any publisher.
**\<meeting-bot> [anonimal]** With a little design work, we can easily implement other files that won't be overridden. There's also the question of whether we want to have separate files for separate publishers."
**\<meeting-bot> [EinMByte]** Easiest would be to add an additional file that's user-configurable, but maybe it's nicer to just update incrementally
**\<meeting-bot> [anonimal]** hosts.txt is updated every 12 hours. I think we should have user-configurable too.
**\<meeting-bot> [EinMByte]** (although that prings additonal problems)
**\<meeting-bot> [EinMByte]** *brings additional
**\<meeting-bot> [Zenified]** >prings?
**\<meeting-bot> [EinMByte]** So lets have "hosts.txt" and several other files for the different subscriptions?
**\<meeting-bot> [anonimal]** Yes, that was the idea. I guess the question was how many:
**\<meeting-bot> [EinMByte]** one for each subscription
**\<meeting-bot> [EinMByte]** If there's conflicts, they would ideally be reported to the user
**\<meeting-bot> [anonimal]** That'll be tricky if each publisher calls their subscription hosts.txt, we can rename/adjust as needed or concatenate it into on user_hosts.txt
**\<meeting-bot> [anonimal]** *a user_hosts.txt
**\<meeting-bot> [anonimal]** And duplicates would be wasteful
**\<meeting-bot> [anonimal]** (this whole I2P naming scheme is annoying)
**\<meeting-bot> [EinMByte]** We should rename the files locally
**\<meeting-bot> [anonimal]** You mean expect the user to call it whatever they want?
**\<meeting-bot> [EinMByte]** The only hosts.txt file would be the one that the user can change?
**\<meeting-bot> [anonimal]** No, hosts.txt would always be static and provided upstream, always overridden every 12 hours
**\<meeting-bot> [EinMByte]** No, when downloading a subscription, put it in a dedicated file?
**\<meeting-bot> [anonimal]** I'm not sure what you're getting at
**\<meeting-bot> [EinMByte]** Ok, so you want "user_hosts.txt" to be a wile with custom hosts?
**\<meeting-bot> [EinMByte]** *file
**\<meeting-bot> [EinMByte]** That would also work, sure.
**\<meeting-bot> [anonimal]** We only need 2: one that's always clobbered every 12 hours, and one that's never clobbered
**\<meeting-bot> [anonimal]** The one that's never clobbered needs a name. It's "custom" and "private" though.
**\<meeting-bot> [anonimal]** Also, should every address added with i2paddresshelper *also* be inserted into said custom file.
**\<meeting-bot> [EinMByte]** Yes, but we want multiple subscriptions right?
**\<meeting-bot> [anonimal]** I don't even think java i2p does that, but I think it should be done.
**\<meeting-bot> [EinMByte]** But not all publishers provide the same set of hosts
**\<meeting-bot> [EinMByte]** Hence, the need for several hosts.txt files that care clobbered every 12 hours
**\<meeting-bot> [EinMByte]** *are
**\<meeting-bot> [anonimal]** Ok, we'll just have to name subscriptions by uri.host()
**\<meeting-bot> [EinMByte]** Yes, I guess so
**\<meeting-bot> [anonimal]** and make a private_hosts.txt that is *never* clobbered
**\<meeting-bot> [anonimal]** That actually makes the most sense now, imho.
**\<meeting-bot> [EinMByte]** Yes, that or have an actual database of hosts rather than a bunch of files
**\<meeting-bot> [anonimal]** We can deal with duplicates and effiency later unless it becomes a massively huge issue.
**\<meeting-bot> [anonimal]** Yeah, a *real* Db
**\<meeting-bot> [anonimal]** While we're at it we can consider that for ./NetDb
**\<meeting-bot> [EinMByte]** But if we get a real database, it should also be used for profiles etc
**\<meeting-bot> [anonimal]** Didn't i2pcpp do something like that?
**\<meeting-bot> [EinMByte]** Yes, it used sqlite
**\<meeting-bot> [anonimal]** Why was that not continued/exploited?
**\<meeting-bot> [anonimal]** Was it not 'efficient' enough for the magician?
**\<meeting-bot> [EinMByte]** For the same reason that i2pcpp was not continued
**\<fluffypony>** you can always use LMDB
**\<meeting-bot> [EinMByte]** i2pd isn't based on i2pcpp at all
**\<meeting-bot> [anonimal]** I know, but he obviously looked at it.
**\<meeting-bot> [anonimal]** I don't like how one can't use network filesystems with LMDB
**\<meeting-bot> [EinMByte]** Yes, but decided not add the dependency or so
**\<meeting-bot> [EinMByte]** So let's create an issue for using an actual database?
**\<meeting-bot> [anonimal]** EinMByte then I think we should research sqlite or LMDB or some other option for a longterm database solution. Sound reasonable?
**\<meeting-bot> [EinMByte]** Yes
**\<meeting-bot> [anonimal]** Ok, anything else on addressbook?
**\<fluffypony>** I think it's all been addressed
**\<meeting-bot> [EinMByte]** Can you create the issue? If so, let's move on to 7
**\<meeting-bot> [anonimal]** Done, #385
**\<meeting-bot> [anonimal]** 7. API discussion with #monero-dev (#350 #351)
**\<meeting-bot> [EinMByte]** Monero developers here?
**\<meeting-bot> [i2p-relay] {-moneromooo}** Yes
**\<meeting-bot> [EinMByte]** What I mainly want is a clear set of requirements for the API
**\<meeting-bot> [i2p-relay] {-moneromooo}** Oh I see. Oh. Hmm.
**\<fluffypony>** yes
**\<meeting-bot> [i2p-relay] {-moneromooo}** Well, I'm not very much acquainted with the way CN P2P works in the first place...
**\<meeting-bot> [EinMByte]** e.g. do you want to use streaming, I2NP directly, datagrams...?
**\<meeting-bot> [i2p-relay] {-moneromooo}** It's all TCP, with a simple HTTP server at hte moment.
**\<meeting-bot> [Zenified]** LMDB is the the real deal
**\<meeting-bot> [i2p-relay] {-moneromooo}** Doesn't mean it has to stay that way though.
**\<meeting-bot> [EinMByte]** So you need connections? Probably streaming then
**\<meeting-bot> [anonimal]** Question: how is monero-core currently talking with monerod?
**\<meeting-bot> [EinMByte]** The main question to ask is whether you need 1) reliability 2) connections
**\<meeting-bot> [i2p-relay] {-moneromooo}** fluffypony: did you intend to replace the P2P stuff with 0MQ ?
**\<meeting-bot> [anonimal]** EinMByte I thought we discussed not doing network-based API
**\<meeting-bot> [i2p-relay] {-moneromooo}** anonimal: JSON RPC AFAIK.
**\<fluffypony>** anonimal: JSON RPC API, but we're replacing that with 0MQ
**\<fluffypony>** but Kovri will serve the p2p layer
**\<fluffypony>** not the RPC layer
**\<fluffypony>** moneromooo: yes with ZMTP
**\<fluffypony>** http://zmtp.org
**\<fluffypony>** maybe we bundle the ZMTP change and Kovri integration together ?
**\<meeting-bot> [EinMByte]** anonimal: No, but we need to know what aspects of the API are most important
**\<meeting-bot> [EinMByte]** e.g. do we need to focus on making I2NP accessible, or on making streaming accessible
**\<meeting-bot> [EinMByte]** Or does monero want to be able to create tunnels, etc.
**\<meeting-bot> [anonimal]** I think monero wants something as simple as a SOCKS proxy
**\<meeting-bot> [i2p-relay] {-moneromooo}** We need to be able to find peers without knowing their address in advance.
**\<meeting-bot> [anonimal]** If connection isn't made, tough luck and try again later
**\<meeting-bot> [anonimal]** Oh, nevermind then
**\<meeting-bot> [i2p-relay] {-moneromooo}** At the moment, this is done by bootstrapping from a seed server.
**\<fluffypony>** moneromooo: DNS seeds
**\<meeting-bot> [EinMByte]** So 0MQ would be TCP-based, so would use streaming
**\<fluffypony>** yeah so we can do the same
**\<meeting-bot> [i2p-relay] {-moneromooo}** That... might be DNS ? I'm not sure.
**\<fluffypony>** we get seed nodes from DNS seeds with hardcoded fallbacks
**\<fluffypony>** and then we connect to their .i2p address on the appropriate port
**\<meeting-bot> [i2p-relay] {-moneromooo}** And all the DNSSEC or DNScrypt that fluffypony knows about.
**\<fluffypony>** and request peers
**\<fluffypony>** and we get a list of .i2p addresses and ports
**\<meeting-bot> [EinMByte]** Do you want to create a tunnel and then connect to that, or do you want to have a C++ API to also send messages?
**\<meeting-bot> [anonimal]** Has monero-side drawn up any diagrams for these ideas?
**\<fluffypony>** anonimal: that's how it currently works, not ideas
**\<meeting-bot> [i2p-relay] {-moneromooo}** Is there a concept of "multicast", where we could send a query to "whomever it may concern" ?
**\<meeting-bot> [anonimal]** fluffypony: you currently get a list of .i2p address and ports?
**\<fluffypony>** EinMByte: we can do either
**\<meeting-bot> [EinMByte]** moneromooo: No, don't think so
**\<fluffypony>** anonimal: we currently get ipv4 addresses, but we'd perform exactly the same function to get i2p-based peers
**\<meeting-bot> [EinMByte]** moneromooo: But I can think about multicast in future I2P and even get a proposal going, but it would take years before we actually get it
**\<meeting-bot> [i2p-relay] {-moneromooo}** The intent, in this case, would be to request replies from peers that run monero.
**\<meeting-bot> [i2p-relay] {-moneromooo}** (without having to rely on centralized seeds)
**\<meeting-bot> [EinMByte]** So for DNS, you could use repliable datagrams or streaming.
**\<meeting-bot> [anonimal]** EinMByte moneromooo: multicast is mentioned in future work https://geti2p.net/en/docs/how/garlic-routing
**\<fluffypony>** DNS seed nodes work, I really don't think we need to replace that
**\<fluffypony>** but what we would do on first sync is get both ipv4 *and* i2p peers
**\<meeting-bot> [EinMByte]** anonimal: Yes, but there's no decent proposal right now. I also need to check out the LS2 proposal, it somewhat relates
**\<meeting-bot> [EinMByte]** fluffypony: Ok, assuming you can store I2P addresses in DNS records
**\<meeting-bot> [anonimal]** moneromooo: proposals also sit there for years so I wouldn't expect anything to happen anytime soon
**\<fluffypony>** after that a node maintains its own white / black / gray lists, and gets a peerlist every time it connects to a new peer
**\<fluffypony>** EinMByte: TXT records :)
**\<meeting-bot> [EinMByte]** fluffypony: Ok.
**\<meeting-bot> [i2p-relay] {-moneromooo}** It's something that seems fairly self contained anyway, so could be changed at a later date.
**\<meeting-bot> [EinMByte]** So you need to decide between 1) use I2P direcly with a C++ API 2) create tunnels using a C++ API and then connect to them with SOCKS or so
**\<meeting-bot> [i2p-relay] {-moneromooo}** I don't know the difference between these options.
**\<meeting-bot> [anonimal]** I don't think they need to care about creating tunnels
**\<meeting-bot> [EinMByte]** In any case kovri wants to provide the API to do 1
**\<fluffypony>** yes - and I'd probably lean towards the C++ API
**\<meeting-bot> [anonimal]** They need to know if they can get through or not, that's a given though.
**\<meeting-bot> [EinMByte]** So it looks like monero would be using esentially use the streaming API?
**\<meeting-bot> [i2p-relay] {-moneromooo}** I'd imagine something that looks like a socket API, just using I2P addresses instead of IP:port :)
**\<meeting-bot> [EinMByte]** s/use//
**\<meeting-bot> [i2p-relay] {-moneromooo}** By streaming, do you mean TCP ?
**\<meeting-bot> [EinMByte]** But maybe for DNS you'd also want repliable datagrams
**\<meeting-bot> [anonimal]** I can't answer for them until one of them sits down and reads the spec
**\<meeting-bot> [EinMByte]** moneromooo: streaming is something that looks a lot like TCP but over I2P
**\<meeting-bot> [i2p-relay] {-moneromooo}** Then that's what we'd use in a straight port, modulo the seed stuff.
**\<meeting-bot> [EinMByte]** Most applications use streaming one way or another
**\<meeting-bot> [EinMByte]** I don't know your architecture, but it may be simpler to create a tunnel if you want to route everything to I2P
**\<meeting-bot> [EinMByte]** *through
**\<meeting-bot> [anonimal]** fluffypony moneromooo: what were the arugments against using SOCKS proxy?
**\<meeting-bot> [i2p-relay] {-moneromooo}** By creating a tunnel, do you mean selecting the hoops directly ?
**\<fluffypony>** no arguments - we have no idea what you'd recommend :)
**\<meeting-bot> [anonimal]** EinMByte: KISS
**\<meeting-bot> [EinMByte]** moneromooo: using tunnel in the client-like context here, like a local SOCKS proxy which delivers to a dedicated I2P endpoint
**\<meeting-bot> [anonimal]** monero: we have to meet half-way somehow. I'll try to dig into more monero if you guys can dig into more kovri.
**\<meeting-bot> [EinMByte]** SOCKS seems overly complicaed
**\<meeting-bot> [EinMByte]** *complicated
**\<meeting-bot> [anonimal]** IMHO, we should be more on a level playing field at least term wise by now.
**\<fluffypony>** anonimal: we'll implement whatever you guys recommend
**\<meeting-bot> [EinMByte]** If you need many connections, you can't use the "create a local SOCKS proxy" or so
**\<meeting-bot> [anonimal]** EinMByte: how so? In terms of providing useful feedback and control, yes.
**\<meeting-bot> [i2p-relay] {-moneromooo}** We need several, yes. They're fairly long term. Some will go down, and will be replaced.
**\<meeting-bot> [EinMByte]** Then it would be a lot easier to create tunnels (which use e.g. the streaming protocol) using the C++ API
**\<meeting-bot> [i2p-relay] {-moneromooo}** Both directions, btw. No client/server.
**\<meeting-bot> [EinMByte]** Streaming is both ways, sure
**\<meeting-bot> [EinMByte]** datagrams can also be (if repliable)
**\<meeting-bot> [anonimal]** Ok, so easiest for us is C++ API but is ZMTP worth the extra work?
**\<meeting-bot> [EinMByte]** anonimal: I don't think ZMTP matters to us.
**\<meeting-bot> [i2p-relay] {-moneromooo}** I'd imagine ZMTP is a layer above, and kovri would be oblivious to it.
**\<meeting-bot> [anonimal]** Good.
**\<meeting-bot> [anonimal]** So streaming or datagrams or both?
**\<meeting-bot> [EinMByte]** Question is whether using ZMTP would actually be useful when used above I2P, but I'll leave that to monero devs
**\<meeting-bot> [i2p-relay] {-moneromooo}** Both, please :)
**\<meeting-bot> [EinMByte]** But let's focus on streaming
**\<meeting-bot> [EinMByte]** (since most I2P applications currently use streaming)
**\<meeting-bot> [i2p-relay] {-moneromooo}** But streaming first, yes. We can hardcode peer ids to start with.
**\<fluffypony>** I guess parts of ZMTP would be useless (eg. end-to-end encryption)
**\<meeting-bot> [anonimal]** Ok, C++ API for streaming. That's entirely on us then, for starters.
**\<meeting-bot> [anonimal]** Is this written in stone now EinMByte moneromooo fluffypony?
**\<meeting-bot> [EinMByte]** Let's say it is and move to 8
**\<meeting-bot> [i2p-relay] {-moneromooo}** To the extent I know of how CN uses the network... -_- :D
**\<fluffypony>** yes
**\<meeting-bot> [anonimal]** Yay, big decision step done.
**\<yardman>** whats set in stone?
**\<meeting-bot> [anonimal]** Anything else on 7.?
**\<meeting-bot> [anonimal]** I have one question:
**\<fluffypony>** nope
**\<fluffypony>** yardman: using the i2p C++ API for streaming
**\<meeting-bot> [anonimal]** What homework can we all do so our next API meeting is more productive?
**\<meeting-bot> [anonimal]** kovri c++ API
**\<meeting-bot> [EinMByte]** Design it
**\<meeting-bot> [i2p-relay] {-moneromooo}** Well, I have that feeling that the next month or two will be spent on rct performance from my side...
**\<fluffypony>** anonimal: we haven't really focused on our current p2p layer because of the ZMTP plan
**\<meeting-bot> [anonimal]** moneromooo: you mentioned I should look at networking code?
**\<yardman>** thanks
**\<meeting-bot> [i2p-relay] {-moneromooo}** I didn't, I think. I mentioned I should :D
**\<meeting-bot> [anonimal]** Oh, lol ok
**\<meeting-bot> [i2p-relay] {-moneromooo}** IIRC that p2p code is also kinda new and unfinished.
**\<fluffypony>** so I don't know if we should waste much time on analysis of it, or rather look at i2p as a ZMTP transport
**\<fluffypony>** which could be a VERY nice generalised solution
**\<fluffypony>** that isn't Monero-specific
**\<meeting-bot> [anonimal]** Ok, I'll add API for first thing next meeting.
**\<meeting-bot> [anonimal]** Anything else for 7.?
**\<fluffypony>** nope
**\<meeting-bot> [EinMByte]** Nope, 8 please (need to leave soon)
**\<meeting-bot> [anonimal]** 8. Code + ticket discussion / Q & A
**\<meeting-bot> [anonimal]** We're in overtime, I have nothing to say at the moment really.
**\<meeting-bot> [anonimal]** fluffypony I think there's an assigned ticket you can easily close
**\<meeting-bot> [EinMByte]** Me neither, let's discuss when appropriate
**\<meeting-bot> [anonimal]** (the codedocs one)
**\<meeting-bot> [EinMByte]** Will see how much time I get to do v6 peer testing
**\<fluffypony>** ok will do
**\<meeting-bot> [anonimal]** I'll get to more assigned tickets as well.
**\<meeting-bot> [anonimal]** Ok, moving on.
**\<meeting-bot> [EinMByte]** Also not sure if #187 should still be open
**\<meeting-bot> [anonimal]** 9. Any additional meeting items
**\<meeting-bot> [anonimal]** EinMByte, ok I'll take a look after the meeting.
**\<meeting-bot> [EinMByte]** Ok, no additional meeting items from me
**\<meeting-bot> [anonimal]** Nor I. fluffypony?
**\<meeting-bot> [anonimal]** moneromooo?
**\<fluffypony>** nope
**\<meeting-bot> [anonimal]** #monero-dev?
**\<meeting-bot> [i2p-relay] {-moneromooo}** No
**\<meeting-bot> [anonimal]** 10. Confirm next meeting date/time
**\<meeting-bot> [anonimal]** Next week or two weeks?
**\<meeting-bot> [EinMByte]** 2
**\<meeting-bot> [EinMByte]** (if we want the API on the list of topics)
**\<fluffypony>** 2 weeks
**\<fluffypony>** Oct 16
**\<meeting-bot> [anonimal]** Same for #monero-dev?
**\<meeting-bot> [anonimal]** I'd like to coincide
**\<meeting-bot> [anonimal]** fluffypony: ^
**\<fluffypony>** yes
**\<meeting-bot> [anonimal]** Ok, 2 weeks works for me.
**\<meeting-bot> [anonimal]** THANKS EVERYONE!
**\<fluffypony>** anonimal: all yours :)
**\<meeting-bot> [anonimal]** 1. Greetings
**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** 3. ∫alti https://github.com/EinMByte/salti
**\<meeting-bot> [anonimal]** 4. "Kovri Garlic Router Project" + logo
**\<meeting-bot> [anonimal]** 5. #46
**\<meeting-bot> [anonimal]** 6. #337 https://geti2p.net/en/docs/naming
**\<meeting-bot> [anonimal]** 7. API discussion with `#monero-dev` (#350 #351)
**\<meeting-bot> [anonimal]** 8. Code + ticket discussion / Q & A
**\<meeting-bot> [anonimal]** 9. Any additional meeting items
**\<meeting-bot> [anonimal]** 10. Confirm next meeting date/time
**\<meeting-bot> [anonimal]** 1. Greetings
**\<meeting-bot> [i2p-relay] {-moneromooo}** UDP meeting
**\<meeting-bot> [anonimal]** Hi
**\<meeting-bot> [EinMByte]** Hi
**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** Areas of work done or completed since last meeting 3 weeks ago:
**\<meeting-bot> [anonimal]** - Transports improvements/fixes and EinMByte's SSU branch was merged!
**\<meeting-bot> [anonimal]** - Client/app improvements/fixes and client-crypto related (client signing type, https ciphers, etc.)
**\<meeting-bot> [anonimal]** - Almost all Coverity issues resolved, still a handful left
**\<meeting-bot> [anonimal]** - Fixes/enhancements and more
**\<meeting-bot> [anonimal]** - pero's fantastic work with the logo
**\<meeting-bot> [anonimal]** Oh, .ny new open issues - that's a good thing though, right? ;)
**\<fluffypony>** lol
**\<meeting-bot> [anonimal]** Anything else did I miss for 2. or move onto 3.?
**\<meeting-bot> [EinMByte]** No, go ahead. I have only limited time so let's be productive
**\<fluffypony>** 3 plz
**\<meeting-bot> * anonimal** having hard time keeping track of all the work that passes over several weeks; its usually a very broad range of areas
**\<meeting-bot> [anonimal]** 3. ∫alti https://github.com/EinMByte/salti
**\<meeting-bot> [anonimal]** So, EinMByte and I are starting preliminary work on a firefox extension that will tremendously help Kovri and I2P
**\<meeting-bot> [anonimal]** I just want to mention this here in case there are any interested webdevs
**\<meeting-bot> [anonimal]** Anything you want to add EinMByte?
**\<fluffypony>** Salti is basically like the Kovri GUI :-P
**\<meeting-bot> [EinMByte]** fluffypony: No it isn't
**\<meeting-bot> [EinMByte]** The kovri GUI is called qtoopie
**\<meeting-bot> [anonimal]** EinMByte: no, the GUI does not exist yet.
**\<meeting-bot> [anonimal]** qtoopie is an i2pcontrol client.
**\<meeting-bot> [EinMByte]** Salti is a firefox add-on similar to Tor browser bundle
**\<fluffypony>** lol
**\<meeting-bot> [EinMByte]** anonimal: Yes (but see also the relevant zzz.i2p thread from long ago)
**\* fluffypony** was making a joke
**\<meeting-bot> * anonimal** doesn't have time to search zzz.i2p, link appreciated
**\<meeting-bot> [anonimal]** Any webdevs present?
**\<meeting-bot> * EinMByte** doesn't have time to find zzz.i2p topic
**\<patthehuman>** i could technically be a webdev
**\<patthehuman>** im c/c++ swift/obj-c nodejs/MEAN stack
**\<meeting-bot> [anonimal]** Hi patthehuman. Have you done any work with firefox add-ons?
**\<patthehuman>** no, however, i dont think it would be very difficult
**\<meeting-bot> [EinMByte]** We won't be needing very complex stuff by the way, just using the webextensions API
**\<patthehuman>** would it be chrome and firefox..?
**\<meeting-bot> [anonimal]** patthehuman: webext I believe could support both? but we're aiming for firefox.
**\<meeting-bot> [EinMByte]** (we'll be setting a few settings and intercepting a few requests)
**\<meeting-bot> [EinMByte]** patthehuman: yes
**\<patthehuman>** mk
**\<meeting-bot> [anonimal]** patthehuman: we can give more details after the meeting if you idle #kovri-dev
**\<meeting-bot> [EinMByte]** (although initially firefox, but the API should be mostly the same)
**\<patthehuman>** ok
**\<meeting-bot> [anonimal]** Anything else on 3.?
**\<patthehuman>** ill stick around, interested in hearing full scale
**\<meeting-bot> [EinMByte]** Let's move to 4
**\<meeting-bot> [anonimal]** 4. "Kovri Garlic Router Project" + logo
**\<meeting-bot> [anonimal]** pero: you there?
**\<pero>** yep
**\<pero>** want me to take over?
**\<meeting-bot> [anonimal]** What do you have for us today?
**\<meeting-bot> [anonimal]** Let's spend very little time with the visual aspect, we have bigger issues to tackle with kovri
**\<meeting-bot> [anonimal]** Just a run down so everyone knows where we are
**\<meeting-bot> [anonimal]** And links if possible
**\<pero>** http://imgur.com/a/ptOHb
**\<pero>** after a 'long' process we're down to 3 fonts
**\<pero>** the idea is to pick the font with the best looking letters that comprise the word kovri
**\<meeting-bot> [anonimal]** And what about https://i.imgur.com/UDsSuTg.png
**\<pero>** and/or eliminate some concepts
**\<meeting-bot> [anonimal]** I guess Coral is out of the question
**\<patthehuman>** lato second from bottom
**\<pero>** yea coral was cut
**\<pero>** work sans is largely similar and coral seemed inferior on some letters as well as less versatile at smaller font sizes iirc
**\<meeting-bot> [EinMByte]** I'd also drop open sans
**\<pero>** in the 'a' system
**\<pero>** exo 2 is the logo font - but it doesn't work as well for text
**\<pero>** so i chose open sans to complement it
**\<meeting-bot> [EinMByte]** Sorry, I mean the exp 2 / open sans combination
**\<pero>** a5 features exo2 as subtext so you can see how that would look like
**\<meeting-bot> [EinMByte]** But overall, the differences are really minor. Just trying to reduce the search space
**\<pero>** i personally think not going with A or B would be a mistake
**\<pero>** their K is really nice and adds a subtle touch of personality
**\<meeting-bot> [anonimal]** pero: its unfair because I can't accurately compare c4 because of orange subtext
**\<pero>** hmm
**\<meeting-bot> [anonimal]** I prefer work sans because the k contracts with the orange curve in the garlic
**\<meeting-bot> [anonimal]** So is our next step font?
**\<pero>** http://imgur.com/a/DOcyy
**\<meeting-bot> [anonimal]** Is subtext really that thick with work sans? Eww
**\* fluffypony** isn't wild about the orange subtext
**\<pero>** yea the orange subtext sucks imo
**\<meeting-bot> [EinMByte]** Ok, let's handle this another time
**\<meeting-bot> [EinMByte]** (or use a random number generator)
**\<pero>** no it could be thinner
**\<meeting-bot> [EinMByte]** Let's go with column b then
**\<meeting-bot> [anonimal]** lol no way on the random gen
**\<fluffypony>** lol random number gen could be fun
**\<pero>** imgur is also 'optimizing' the png
**\<fluffypony>** "best of 3?"
**\<pero>** keep in mind ^^^
**\<endogenic>** just my two cents - you probably want the text to be relatively heavier than the logo so it jumps out because it's not an english or otherwise generally known word, and so the logo imo should be visually secondary when composed with the name. think about readability, especially if the user doesn't have 20/20 vision or is in a hurry
**\<endogenic>** the actual face itself is not a huge issue imo
**\<meeting-bot> [anonimal]** pero: let's narrow down our options to rows 2, 4, and 6
**\<meeting-bot> [anonimal]** Can you throw those onto a page?
**\<pero>** there probably will be instances where the 'router project' text is unnecessary
**\<fluffypony>** I think rows 3 and 4 won't work because, as endogenic pointed out, kovri is not an English word
**\<fluffypony>** looks like kavri
**\<pero>** and just the logo and kovri would suffice
**\<meeting-bot> [anonimal]** Are we all talking about https://i.imgur.com/Ge1FZTp.png ?
**\<pero>** ideally as a brand it should be able to stand out on its own
**\<meeting-bot> [EinMByte]** Yes, the garlic as an "o" could be confusing
**\<fluffypony>** anonimal no, I'm looking at http://imgur.com/a/DOcyy
**\<meeting-bot> [anonimal]** Same thing
**\<endogenic>** pero: for that reason consider favoring options with tighter kerning
**\<fluffypony>** oh
**\<fluffypony>** lol
**\<meeting-bot> [anonimal]** Who in their right mind things that garlic is an 'A'?
**\<pero>** another thing to add
**\<meeting-bot> [EinMByte]** So let's narrow it down to 2 and 6
**\<meeting-bot> [i2p-relay] {-ArticMine}** 2 in Open Sans is the most readable
**\<pero>** the garlic wasn't designed with this use in mind
**\<pero>** the garlic could be optimized down the road
**\<meeting-bot> [EinMByte]** anonimal: Remember that the spectator potentially doesn't know "kovri"
**\<pero>** ideally after a font has been chosen
**\<pero>** to more resemble an o and to slide seamlessly into the font
**\<meeting-bot> [EinMByte]** At least it might add additional confusion, which is bad
**\<endogenic>** EinMByte: exactly. the question is how it could be confirmed it's not an A
**\<meeting-bot> [anonimal]** Ok, all in favor of exo2
**\<pero>** i'm however not qualified to do that
**\<meeting-bot> [anonimal]** Any votes for exo2/open sans?
**\<meeting-bot> [i2p-relay] {-ArticMine}** Yes
**\<meeting-bot> [EinMByte]** exo2 is fine for me, but I also agree that the "Garlic Routing Project" text should be optional
**\<meeting-bot> [i2p-relay] {-ArticMine}** exo2 is fine
**\<meeting-bot> [EinMByte]** (So on the website, for example, we should have the text. But potentially not everywhere)
**\<meeting-bot> [EinMByte]** Any objections against exo2?
**\<meeting-bot> [anonimal]** I count 2 votes for exo2/open sans.
**\<meeting-bot> [anonimal]** Any votes for Lato?
**\<pero>** i vote lato
**\<meeting-bot> [EinMByte]** Any votes for work sans?
**\<endogenic>** i also like lato
**\<fluffypony>** lato from my side
**\<meeting-bot> [EinMByte]** Ok, let's eliminate work sans.
**\<meeting-bot> [anonimal]** 3 votes for Lato.
**\<meeting-bot> [anonimal]** Any votes for Work Sans?
**\<meeting-bot> [anonimal]** 0 votes for Work Sans
**\<meeting-bot> [anonimal]** I haven't voted
**\<meeting-bot> * anonimal** looks
**\<patthehuman>** i vote for Lato
**\<meeting-bot> [EinMByte]** Are we going to decide on the logo today or not? If so, we should hurry (if we want to discuss API still)
**\<meeting-bot> [anonimal]** pero: why does a6 look so fat?
**\<pero>** shouldn't be that difficult to throw up exo2 versions of lato variants in the future
**\<pero>** in case that's still up for debatable
**\<meeting-bot> [anonimal]** EinMByte that's up to moneromooo because I really don't think anyone else there is interested in API chat (afaict)
**\<pero>** because it is fat :P
**\<patthehuman>** yb
**\<meeting-bot> [i2p-relay] {-ArticMine}** I have to leave
**\<patthehuman> im interested in api cha
**\<endogenic>** maybe we should have a #monero-design? :)
**\<meeting-bot> [anonimal]** EinMByte if we don't decide soon, website doesn't get done
**\<pero>** i went with a heavier weight for that variant arbitrarily
**\<meeting-bot> [i2p-relay] {-moneromooo}** I have no particular wish about that, don't mind me.
**\<fluffypony>** let's move ahead
**\<fluffypony>** the logo already took up the entire last meeting
**\<meeting-bot> [anonimal]** 3 minutes
**\<meeting-bot> [anonimal]** Let me vote please!
**\<meeting-bot> [EinMByte]** We should at least plan when to discuss the API, so let's decide quickly on the logo :)
**\<patthehuman>** LATO
**\<meeting-bot> [anonimal]** pero: why should I choose exo2
**\<pero>** its advantage seems to be technological look
**\<meeting-bot> [EinMByte]** anonimal: Please decide, we're moving too slowly here
**\<pero>** a secondary adv is that we can pair with open sans which is extremely versatile
**\<meeting-bot> [anonimal]** EinMByte, we have 30 minutes, please be patient.
**\<pero>** can be used at extremely small sizes for things like massive tables of data
**\<pero>** whereas using open sans to complement a lato branding scheme wouldn't make much sense
**\<meeting-bot> [anonimal]** pero: how about this: can you whip up another sample for after the meeting but *only* exo2 and lato and doing various sizes that you think are appropriate?
**\<pero>** i think that makes the most sense as a next step
**\<meeting-bot> [anonimal]** We can probably come to a final conclusion post-meeting or sometime this week.
**\<meeting-bot> [anonimal]** Ok, thanks pero.
**\<meeting-bot> [anonimal]** Moving on,
**\<meeting-bot> [anonimal]** 5. #46
**\<meeting-bot> [anonimal]** fluffypony: ^
**\<meeting-bot> [EinMByte]** fluffypony...
**\<pero>** did you skip over the 'garlic router' discussion?
**\<fluffypony>** ok - got a first draft to push up, but need to finish fixing the forum first
**\<meeting-bot> [anonimal]** pero: just go with it for now but also do without subtext too please
**\<meeting-bot> [EinMByte]** ETA?
**\<patthehuman>** whats wrong with the forum?
**\<pero>** ok
**\<fluffypony>** EinMByte: no clue
**\<fluffypony>** patthehuman: PHP7 broke a bunch of stuff
**\<meeting-bot> [anonimal]** patthehuman: fluffypony is fixing it
**\<patthehuman> ok
**\<fluffypony>** some of it was non-obvious until we had a new dep and composer wrecked everything
**\<patthehuman>** ill be around if you need help
**\<meeting-bot> [EinMByte]** Let's not discuss the monero forum here
**\<patthehuman>** php7 wrecked a lot of my shit at work so ive been down this path
**\<patthehuman>** sure
**\<meeting-bot> [anonimal]** fluffypony: should EinMByte and I not ask for ETA for website?
**\<fluffypony>** anonimal: I'll push my changes once the forum is back up, since all static objects are served off that repo anyway
**\<meeting-bot> [anonimal]** Worst case scenario, we release with just a repo and wiki.
**\<meeting-bot> [anonimal]** Ok, moving on
**\<meeting-bot> [anonimal]** 6. #337 https://geti2p.net/en/docs/naming
**\<meeting-bot> [anonimal]** What happens is that any addresses that are saved with an addresshelper are simply inserted into ./addressbook but not user_hosts.txt (or similar)
**\<meeting-bot> [anonimal]** There are also various other issues, let me pull up the ticket
**\<meeting-bot> [anonimal]** "For this ticket, we should discuss if we're to have separate subscription files because we currently only use hosts.txt. Also, if we hand edit the file, it will be overridden upon next fetch from a any publisher.
**\<meeting-bot> [anonimal]** With a little design work, we can easily implement other files that won't be overridden. There's also the question of whether we want to have separate files for separate publishers."
**\<meeting-bot> [EinMByte]** Easiest would be to add an additional file that's user-configurable, but maybe it's nicer to just update incrementally
**\<meeting-bot> [anonimal]** hosts.txt is updated every 12 hours. I think we should have user-configurable too.
**\<meeting-bot> [EinMByte]** (although that prings additonal problems)
**\<meeting-bot> [EinMByte]** \*brings additional
**\<meeting-bot> [Zenified]** >prings?
**\<meeting-bot> [EinMByte]** So lets have "hosts.txt" and several other files for the different subscriptions?
**\<meeting-bot> [anonimal]** Yes, that was the idea. I guess the question was how many:
**\<meeting-bot> [EinMByte]** one for each subscription
**\<meeting-bot> [EinMByte]** If there's conflicts, they would ideally be reported to the user
**\<meeting-bot> [anonimal]** That'll be tricky if each publisher calls their subscription hosts.txt, we can rename/adjust as needed or concatenate it into on user_hosts.txt
**\<meeting-bot> [anonimal]** \*a user_hosts.txt
**\<meeting-bot> [anonimal]** And duplicates would be wasteful
**\<meeting-bot> [anonimal]** (this whole I2P naming scheme is annoying)
**\<meeting-bot> [EinMByte]** We should rename the files locally
**\<meeting-bot> [anonimal]** You mean expect the user to call it whatever they want?
**\<meeting-bot> [EinMByte]** The only hosts.txt file would be the one that the user can change?
**\<meeting-bot> [anonimal]** No, hosts.txt would always be static and provided upstream, always overridden every 12 hours
**\<meeting-bot> [EinMByte]** No, when downloading a subscription, put it in a dedicated file?
**\<meeting-bot> [anonimal]** I'm not sure what you're getting at
**\<meeting-bot> [EinMByte]** Ok, so you want "user_hosts.txt" to be a wile with custom hosts?
**\<meeting-bot> [EinMByte]** \*file
**\<meeting-bot> [EinMByte]** That would also work, sure.
**\<meeting-bot> [anonimal]** We only need 2: one that's always clobbered every 12 hours, and one that's never clobbered
**\<meeting-bot> [anonimal]** The one that's never clobbered needs a name. It's "custom" and "private" though.
**\<meeting-bot> [anonimal]** Also, should every address added with i2paddresshelper \*also\* be inserted into said custom file.
**\<meeting-bot> [EinMByte]** Yes, but we want multiple subscriptions right?
**\<meeting-bot> [anonimal]** I don't even think java i2p does that, but I think it should be done.
**\<meeting-bot> [EinMByte]** But not all publishers provide the same set of hosts
**\<meeting-bot> [EinMByte]** Hence, the need for several hosts.txt files that care clobbered every 12 hours
**\<meeting-bot> [EinMByte]** \*are
**\<meeting-bot> [anonimal]** Ok, we'll just have to name subscriptions by uri.host()
**\<meeting-bot> [EinMByte]** Yes, I guess so
**\<meeting-bot> [anonimal]** and make a private_hosts.txt that is *never* clobbered
**\<meeting-bot> [anonimal]** That actually makes the most sense now, imho.
**\<meeting-bot> [EinMByte]** Yes, that or have an actual database of hosts rather than a bunch of files
**\<meeting-bot> [anonimal]** We can deal with duplicates and effiency later unless it becomes a massively huge issue.
**\<meeting-bot> [anonimal]** Yeah, a *real* Db
**\<meeting-bot> [anonimal]** While we're at it we can consider that for ./NetDb
**\<meeting-bot> [EinMByte]** But if we get a real database, it should also be used for profiles etc
**\<meeting-bot> [anonimal]** Didn't i2pcpp do something like that?
**\<meeting-bot> [EinMByte]** Yes, it used sqlite
**\<meeting-bot> [anonimal]** Why was that not continued/exploited?
**\<meeting-bot> [anonimal]** Was it not 'efficient' enough for the magician?
**\<meeting-bot> [EinMByte]** For the same reason that i2pcpp was not continued
**\<fluffypony>** you can always use LMDB
**\<meeting-bot> [EinMByte]** i2pd isn't based on i2pcpp at all
**\<meeting-bot> [anonimal]** I know, but he obviously looked at it.
**\<meeting-bot> [anonimal]** I don't like how one can't use network filesystems with LMDB
**\<meeting-bot> [EinMByte]** Yes, but decided not add the dependency or so
**\<meeting-bot> [EinMByte]** So let's create an issue for using an actual database?
**\<meeting-bot> [anonimal]** EinMByte then I think we should research sqlite or LMDB or some other option for a longterm database solution. Sound reasonable?
**\<meeting-bot> [EinMByte]** Yes
**\<meeting-bot> [anonimal]** Ok, anything else on addressbook?
**\<fluffypony>** I think it's all been addressed
**\<meeting-bot> [EinMByte]** Can you create the issue? If so, let's move on to 7
**\<meeting-bot> [anonimal]** Done, #385
**\<meeting-bot> [anonimal]** 7. API discussion with #monero-dev (#350 #351)
**\<meeting-bot> [EinMByte]** Monero developers here?
**\<meeting-bot> [i2p-relay] {-moneromooo}** Yes
**\<meeting-bot> [EinMByte]** What I mainly want is a clear set of requirements for the API
**\<meeting-bot> [i2p-relay] {-moneromooo}** Oh I see. Oh. Hmm.
**\<fluffypony>** yes
**\<meeting-bot> [i2p-relay] {-moneromooo}** Well, I'm not very much acquainted with the way CN P2P works in the first place...
**\<meeting-bot> [EinMByte]** e.g. do you want to use streaming, I2NP directly, datagrams...?
**\<meeting-bot> [i2p-relay] {-moneromooo}** It's all TCP, with a simple HTTP server at hte moment.
**\<meeting-bot> [Zenified]** LMDB is the the real deal
**\<meeting-bot> [i2p-relay] {-moneromooo}** Doesn't mean it has to stay that way though.
**\<meeting-bot> [EinMByte]** So you need connections? Probably streaming then
**\<meeting-bot> [anonimal]** Question: how is monero-core currently talking with monerod?
**\<meeting-bot> [EinMByte]** The main question to ask is whether you need 1) reliability 2) connections
**\<meeting-bot> [i2p-relay] {-moneromooo}** fluffypony: did you intend to replace the P2P stuff with 0MQ ?
**\<meeting-bot> [anonimal]** EinMByte I thought we discussed not doing network-based API
**\<meeting-bot> [i2p-relay] {-moneromooo}** anonimal: JSON RPC AFAIK.
**\<fluffypony>** anonimal: JSON RPC API, but we're replacing that with 0MQ
**\<fluffypony>** but Kovri will serve the p2p layer
**\<fluffypony>** not the RPC layer
**\<fluffypony>** moneromooo: yes with ZMTP
**\<fluffypony>** http://zmtp.org
**\<fluffypony>** maybe we bundle the ZMTP change and Kovri integration together ?
**\<meeting-bot> [EinMByte]** anonimal: No, but we need to know what aspects of the API are most important
**\<meeting-bot> [EinMByte]** e.g. do we need to focus on making I2NP accessible, or on making streaming accessible
**\<meeting-bot> [EinMByte]** Or does monero want to be able to create tunnels, etc.
**\<meeting-bot> [anonimal]** I think monero wants something as simple as a SOCKS proxy
**\<meeting-bot> [i2p-relay] {-moneromooo}** We need to be able to find peers without knowing their address in advance.
**\<meeting-bot> [anonimal]** If connection isn't made, tough luck and try again later
**\<meeting-bot> [anonimal]** Oh, nevermind then
**\<meeting-bot> [i2p-relay] {-moneromooo}** At the moment, this is done by bootstrapping from a seed server.
**\<fluffypony>** moneromooo: DNS seeds
**\<meeting-bot> [EinMByte]** So 0MQ would be TCP-based, so would use streaming
**\<fluffypony>** yeah so we can do the same
**\<meeting-bot> [i2p-relay] {-moneromooo}** That... might be DNS ? I'm not sure.
**\<fluffypony>** we get seed nodes from DNS seeds with hardcoded fallbacks
**\<fluffypony>** and then we connect to their .i2p address on the appropriate port
**\<meeting-bot> [i2p-relay] {-moneromooo}** And all the DNSSEC or DNScrypt that fluffypony knows about.
**\<fluffypony>** and request peers
**\<fluffypony>** and we get a list of .i2p addresses and ports
**\<meeting-bot> [EinMByte]** Do you want to create a tunnel and then connect to that, or do you want to have a C++ API to also send messages?
**\<meeting-bot> [anonimal]** Has monero-side drawn up any diagrams for these ideas?
**\<fluffypony>** anonimal: that's how it currently works, not ideas
**\<meeting-bot> [i2p-relay] {-moneromooo}** Is there a concept of "multicast", where we could send a query to "whomever it may concern" ?
**\<meeting-bot> [anonimal]** fluffypony: you currently get a list of .i2p address and ports?
**\<fluffypony>** EinMByte: we can do either
**\<meeting-bot> [EinMByte]** moneromooo: No, don't think so
**\<fluffypony>** anonimal: we currently get ipv4 addresses, but we'd perform exactly the same function to get i2p-based peers
**\<meeting-bot> [EinMByte]** moneromooo: But I can think about multicast in future I2P and even get a proposal going, but it would take years before we actually get it
**\<meeting-bot> [i2p-relay] {-moneromooo}** The intent, in this case, would be to request replies from peers that run monero.
**\<meeting-bot> [i2p-relay] {-moneromooo}** (without having to rely on centralized seeds)
**\<meeting-bot> [EinMByte]** So for DNS, you could use repliable datagrams or streaming.
**\<meeting-bot> [anonimal]** EinMByte moneromooo: multicast is mentioned in future work https://geti2p.net/en/docs/how/garlic-routing
**\<fluffypony>** DNS seed nodes work, I really don't think we need to replace that
**\<fluffypony>** but what we would do on first sync is get both ipv4 *and* i2p peers
**\<meeting-bot> [EinMByte]** anonimal: Yes, but there's no decent proposal right now. I also need to check out the LS2 proposal, it somewhat relates
**\<meeting-bot> [EinMByte]** fluffypony: Ok, assuming you can store I2P addresses in DNS records
**\<meeting-bot> [anonimal]** moneromooo: proposals also sit there for years so I wouldn't expect anything to happen anytime soon
**\<fluffypony>** after that a node maintains its own white / black / gray lists, and gets a peerlist every time it connects to a new peer
**\<fluffypony>** EinMByte: TXT records :)
**\<meeting-bot> [EinMByte]** fluffypony: Ok.
**\<meeting-bot> [i2p-relay] {-moneromooo}** It's something that seems fairly self contained anyway, so could be changed at a later date.
**\<meeting-bot> [EinMByte]** So you need to decide between 1) use I2P direcly with a C++ API 2) create tunnels using a C++ API and then connect to them with SOCKS or so
**\<meeting-bot> [i2p-relay] {-moneromooo}** I don't know the difference between these options.
**\<meeting-bot> [anonimal]** I don't think they need to care about creating tunnels
**\<meeting-bot> [EinMByte]** In any case kovri wants to provide the API to do 1
**\<fluffypony>** yes - and I'd probably lean towards the C++ API
**\<meeting-bot> [anonimal]** They need to know if they can get through or not, that's a given though.
**\<meeting-bot> [EinMByte]** So it looks like monero would be using esentially use the streaming API?
**\<meeting-bot> [i2p-relay] {-moneromooo}** I'd imagine something that looks like a socket API, just using I2P addresses instead of IP:port :)
**\<meeting-bot> [EinMByte]** s/use//
**\<meeting-bot> [i2p-relay] {-moneromooo}** By streaming, do you mean TCP ?
**\<meeting-bot> [EinMByte]** But maybe for DNS you'd also want repliable datagrams
**\<meeting-bot> [anonimal]** I can't answer for them until one of them sits down and reads the spec
**\<meeting-bot> [EinMByte]** moneromooo: streaming is something that looks a lot like TCP but over I2P
**\<meeting-bot> [i2p-relay] {-moneromooo}** Then that's what we'd use in a straight port, modulo the seed stuff.
**\<meeting-bot> [EinMByte]** Most applications use streaming one way or another
**\<meeting-bot> [EinMByte]** I don't know your architecture, but it may be simpler to create a tunnel if you want to route everything to I2P
**\<meeting-bot> [EinMByte]** \*through
**\<meeting-bot> [anonimal]** fluffypony moneromooo: what were the arugments against using SOCKS proxy?
**\<meeting-bot> [i2p-relay] {-moneromooo}** By creating a tunnel, do you mean selecting the hoops directly ?
**\<fluffypony>** no arguments - we have no idea what you'd recommend :)
**\<meeting-bot> [anonimal]** EinMByte: KISS
**\<meeting-bot> [EinMByte]** moneromooo: using tunnel in the client-like context here, like a local SOCKS proxy which delivers to a dedicated I2P endpoint
**\<meeting-bot> [anonimal]** monero: we have to meet half-way somehow. I'll try to dig into more monero if you guys can dig into more kovri.
**\<meeting-bot> [EinMByte]** SOCKS seems overly complicaed
**\<meeting-bot> [EinMByte]** \*complicated
**\<meeting-bot> [anonimal]** IMHO, we should be more on a level playing field at least term wise by now.
**\<fluffypony>** anonimal: we'll implement whatever you guys recommend
**\<meeting-bot> [EinMByte]** If you need many connections, you can't use the "create a local SOCKS proxy" or so
**\<meeting-bot> [anonimal]** EinMByte: how so? In terms of providing useful feedback and control, yes.
**\<meeting-bot> [i2p-relay] {-moneromooo}** We need several, yes. They're fairly long term. Some will go down, and will be replaced.
**\<meeting-bot> [EinMByte]** Then it would be a lot easier to create tunnels (which use e.g. the streaming protocol) using the C++ API
**\<meeting-bot> [i2p-relay] {-moneromooo}** Both directions, btw. No client/server.
**\<meeting-bot> [EinMByte]** Streaming is both ways, sure
**\<meeting-bot> [EinMByte]** datagrams can also be (if repliable)
**\<meeting-bot> [anonimal]** Ok, so easiest for us is C++ API but is ZMTP worth the extra work?
**\<meeting-bot> [EinMByte]** anonimal: I don't think ZMTP matters to us.
**\<meeting-bot> [i2p-relay] {-moneromooo}** I'd imagine ZMTP is a layer above, and kovri would be oblivious to it.
**\<meeting-bot> [anonimal]** Good.
**\<meeting-bot> [anonimal]** So streaming or datagrams or both?
**\<meeting-bot> [EinMByte]** Question is whether using ZMTP would actually be useful when used above I2P, but I'll leave that to monero devs
**\<meeting-bot> [i2p-relay] {-moneromooo}** Both, please :)
**\<meeting-bot> [EinMByte]** But let's focus on streaming
**\<meeting-bot> [EinMByte]** (since most I2P applications currently use streaming)
**\<meeting-bot> [i2p-relay] {-moneromooo}** But streaming first, yes. We can hardcode peer ids to start with.
**\<fluffypony>** I guess parts of ZMTP would be useless (eg. end-to-end encryption)
**\<meeting-bot> [anonimal]** Ok, C++ API for streaming. That's entirely on us then, for starters.
**\<meeting-bot> [anonimal]** Is this written in stone now EinMByte moneromooo fluffypony?
**\<meeting-bot> [EinMByte]** Let's say it is and move to 8
**\<meeting-bot> [i2p-relay] {-moneromooo}** To the extent I know of how CN uses the network... -_- :D
**\<fluffypony>** yes
**\<meeting-bot> [anonimal]** Yay, big decision step done.
**\<yardman>** whats set in stone?
**\<meeting-bot> [anonimal]** Anything else on 7.?
**\<meeting-bot> [anonimal]** I have one question:
**\<fluffypony>** nope
**\<fluffypony>** yardman: using the i2p C++ API for streaming
**\<meeting-bot> [anonimal]** What homework can we all do so our next API meeting is more productive?
**\<meeting-bot> [anonimal]** kovri c++ API
**\<meeting-bot> [EinMByte]** Design it
**\<meeting-bot> [i2p-relay] {-moneromooo}** Well, I have that feeling that the next month or two will be spent on rct performance from my side...
**\<fluffypony>** anonimal: we haven't really focused on our current p2p layer because of the ZMTP plan
**\<meeting-bot> [anonimal]** moneromooo: you mentioned I should look at networking code?
**\<yardman>** thanks
**\<meeting-bot> [i2p-relay] {-moneromooo}** I didn't, I think. I mentioned I should :D
**\<meeting-bot> [anonimal]** Oh, lol ok
**\<meeting-bot> [i2p-relay] {-moneromooo}** IIRC that p2p code is also kinda new and unfinished.
**\<fluffypony>** so I don't know if we should waste much time on analysis of it, or rather look at i2p as a ZMTP transport
**\<fluffypony>** which could be a VERY nice generalised solution
**\<fluffypony>** that isn't Monero-specific
**\<meeting-bot> [anonimal]** Ok, I'll add API for first thing next meeting.
**\<meeting-bot> [anonimal]** Anything else for 7.?
**\<fluffypony>** nope
**\<meeting-bot> [EinMByte]** Nope, 8 please (need to leave soon)
**\<meeting-bot> [anonimal]** 8. Code + ticket discussion / Q & A
**\<meeting-bot> [anonimal]** We're in overtime, I have nothing to say at the moment really.
**\<meeting-bot> [anonimal]** fluffypony I think there's an assigned ticket you can easily close
**\<meeting-bot> [EinMByte]** Me neither, let's discuss when appropriate
**\<meeting-bot> [anonimal]** (the codedocs one)
**\<meeting-bot> [EinMByte]** Will see how much time I get to do v6 peer testing
**\<fluffypony>** ok will do
**\<meeting-bot> [anonimal]** I'll get to more assigned tickets as well.
**\<meeting-bot> [anonimal]** Ok, moving on.
**\<meeting-bot> [EinMByte]** Also not sure if #187 should still be open
**\<meeting-bot> [anonimal]** 9. Any additional meeting items
**\<meeting-bot> [anonimal]** EinMByte, ok I'll take a look after the meeting.
**\<meeting-bot> [EinMByte]** Ok, no additional meeting items from me
**\<meeting-bot> [anonimal]** Nor I. fluffypony?
**\<meeting-bot> [anonimal]** moneromooo?
**\<fluffypony>** nope
**\<meeting-bot> [anonimal]** #monero-dev?
**\<meeting-bot> [i2p-relay] {-moneromooo}** No
**\<meeting-bot> [anonimal]** 10. Confirm next meeting date/time
**\<meeting-bot> [anonimal]** Next week or two weeks?
**\<meeting-bot> [EinMByte]** 2
**\<meeting-bot> [EinMByte]** (if we want the API on the list of topics)
**\<fluffypony>** 2 weeks
**\<fluffypony>** Oct 16
**\<meeting-bot> [anonimal]** Same for #monero-dev?
**\<meeting-bot> [anonimal]** I'd like to coincide
**\<meeting-bot> [anonimal]** fluffypony: ^
**\<fluffypony>** yes
**\<meeting-bot> [anonimal]** Ok, 2 weeks works for me.
**\<meeting-bot> [anonimal]** THANKS EVERYONE!
**\<fluffypony>** shutting meeting bot down

426
_posts/2016-10-02-overview-and-logs-for-the-dev-meeting-held-on-2016-10-02.md
View file

@ -14,216 +14,216 @@ An overview [can be found on Hello Monero](https://hellomonero.com/article/moner
# Logs
**\<fluffypony>** Hi all
**\<fluffypony>** starting meeting bot
**\<moneromooo>** I'm none of them.
**\<dEBRUYNE>** I am here
**\<fluffypony>** moneromooo: I know you're here :)
**\<fluffypony>** ok meeting bot is up
**\<dnaleor>** watching
**\<fluffypony>** so
**\<meeting-bot> [anonimal]** #kovri-dev too?
**\<fluffypony>** kovri-dev is roped in too
**\<othe>** k
**\<meeting-bot> [i2p-relay] {-moneromooo}** o
**\<fluffypony>** this is our first post-0.10.0 meeting
**\<fluffypony>** the 0.10.0 release went fairly smoothly
**\<fluffypony>** apart from the boost oddities
**\<fluffypony>** on the Boost serialisation stuff
**\<fluffypony>** it's not really feasible to do a point release just for that just yet - in a few weeks I'll have local build infrastructure that will make releases a lot easier on me
**\<fluffypony>** since I can secure local machines far more easily than Internet-facing machines at a DC
**\<fluffypony>** in the interim, if anyone is struggling with it the easiest thing for them to do is recover their wallet from the seed / keys
**\<moneromooo>** And keep the old cache if they have tx keys they want to keep.
**\<fluffypony>** ^^
**\<fluffypony>** I'd also like to welcome all the new contributors
**\<fluffypony>** even if it's just correcting a spelling error, all contributions are valuable
**\<fluffypony>** and very much appreciated
**\<fluffypony>** one thing I would like to encourage with the new contributors is to submit your GPG key via PR
**\<fluffypony>** and side-channel it to myself or moneromooo or someone so we can independently verify the correct key goes in
**\<fluffypony>** they live in utils/gpg_keys/
**\<meeting-bot> [anonimal]** and if moneromooo says "ok" in your PR, that's a GOOD thing!
**\<fluffypony>** and then once you've done that you can GPG sign your commits with -S
**\<fluffypony>** eg. git commit -S -am "meaningful commit message"
**\<moneromooo>** Only if it's at the start.
**\<patthehuman>** Is there anything that needs to be made for iOS
**\<fluffypony>** lol anonimal
**\<fluffypony>** patthehuman: it's an open-source project, so if you want to build something for iOS then please do
**\<fluffypony>** no need to ask permission or anyway
**\<fluffypony>** I'd be interested to see if we could package a full node for iOS (without the wallet, lest it get removed from the app store)
**\<patthehuman>** sure, i guess i'm wondering more along the lines of what needs to be built
**\<patthehuman>** can you outline how that would work?
**\<fluffypony>** and then an old iPhone or iPod Touch would work as a full node on wifi
**\<fluffypony>** well we have native ARMv8 builds
**\<fluffypony>** and interacting with the daemon over RPC isn't hard
**\<ArticMine>** Why not just go with Cydia on jailbroken iOS?
**\<fluffypony>** but I have no idea if an iOS app would let you arbitrarily launch a process
**\<endogenic>** ArticMine: too few jailbreak their devices, no?
**\<fluffypony>** ArticMine: absolutely - would be nice to be able to launch it as an app tho
**\<patthehuman>** generally apps get removed from the app store if they are simple "remotes"
**\<endogenic>** fluffypony: iOS does not allow you to spawn processes... no NSTask etc equivalent
**\<fluffypony>** ah
**\<TedTheFicus>** ArcticMine: I think Cydia is a good plan B. Not many non tech people are going to have jail broken phones
**\<patthehuman>** right, they have a list of closed API's that will get you banned
**\<fluffypony>** does Objective-C let you also run native C / C++ code?
**\<endogenic>** fluffypony: yep as long as you can compile for an ARM target
**\<endogenic>** compile it*
**\<MK__>** ArticMine : A good idea and a lot of IOS devices have Jailbreak , Remember that XMR are used in the DNM as well
**\<fluffypony>** yeah we have ARMv8 support across the board
**\<endogenic>** Objective-C is a strict superset of C, so any C is good, and C++ can be compiled too
**\<ArticMine>** Net applications Android 69.18% IOS 25.02% market share
**\<fluffypony>** anyway we're getting side-tracked a little - patthehuman feel free to play around with it, if you feel like it
**\<patthehuman>** sure
**\<fluffypony>** so
**\<fluffypony>** ringCT is live in testnet, and more testing would be appreciated
**\<fluffypony>** mWo12's testnet block explorer is helpful
**\<fluffypony>** but performance testing is also immensely useful
**\<fluffypony>** see what cracks under pressure
**\<fluffypony>** we have a short window until the January hard fork, so we need to hammer testnet as much as possible
**\<trustedsetup>** is there a testnet faucet somewhere? or is mining or irc begging for testnet xmr recommended?
**\<fluffypony>** just ask me and I'll send testnet XMR your way
**\<patthehuman>** are there any automation processes that can hammer on testnet?
**\<patthehuman>** i have access to a lot of r510 servers that i could potentially mirror some script to hammer on it
**\<fluffypony>** patthehuman: you could pretty much just write a bash script to send to yourself once a second
**\<fluffypony>** and cycle it that way
**\<patthehuman>** cool
**\<fluffypony>** and then see how your testnet node(s) handle catch ups, and if they keep up with testnet when blocks are bigger
**\<fluffypony>** we also have our new buildbots ticking along nicely
**\<fluffypony>** so we'll be killing off Travis at some point in the coming weeks
**\<fluffypony>** build bot output has been relegated to #monero-bots
**\<fluffypony>** and that channel is relayed to irc2p
**\<meeting-bot> [anonimal]** Thanks pigeons
**\<meeting-bot> [anonimal]** monero-build.i2p is also online
**\<fluffypony>** yeah pigeons has done great work
**\<fluffypony>** at the moment we're building for a ton of platforms
**\<fluffypony>** including macOS 10.9, 10.10, 10.11
**\<fluffypony>** so we should pick up PRs that break compilation more rapidly
**\<fluffypony>** how we handle testing is a bit harder
**\<fluffypony>** especially since some of the tests take several hours to run
**\<fluffypony>** my current leaning is towards nightly builds + tests
**\<fluffypony>** (of master)
**\<fluffypony>** that way we'll catch tests that are broken by any merged PRs
**\<moneromooo>** Daily core_tests would be useful.
**\<fluffypony>** performance_tests would also be useful
**\<fluffypony>** that way we can track anything that has a huge impact on performance
**\<moneromooo>** As long as the outcome can be seen without too many hoops (ie, javacrsipt)
**\<fluffypony>** moneromooo: we'll probably just grab the output, parse it, and shove it in a database
**\<fluffypony>** then we can create a profiler for the site without too many issues
**\<fluffypony>** on the PR side
**\<fluffypony>** has anyone looked at 1082?
**\<patthehuman>** no my apologies for being new but can you elaborate on what 1082 is
**\<fluffypony>** or actually moneromooo: can you give everyone a brief overview of what 1082 does
**\<fluffypony>** oh sorry patthehuman - PR = pull request
**\<fluffypony>** so PR 1082 = https://github.com/monero-project/monero/pull/1082
**\<patthehuman>** yeah im familiar with PR's (worst part of my work day lol)
**\<moneromooo>** Ah, as the comment says, really.
**\<moneromooo>** It just tries to avoid the case where someone sends money just after receiving it.
**\<moneromooo>** That's a common enough case.
**\<fluffypony>** "25% of the outputs are selected from the last 5 days (if possible), in order to avoid the common case of sending recently received outputs again. 25% and 5 days are subject to review later, since it's just a wallet level change."
**\<trustedsetup>** where did the 25% come from? 25% seems somewhat arbitrary. did MRL have input on this number?
**\<moneromooo>** They're aribtrary.
**\<fluffypony>** trustedsetup: the MRL is of the opinion that we're never going to find a "perfect" distribution, and that distribution should be re-evaluated regularly
**\<luigi1112>** Will look at it
**\<fluffypony>** 25% would only be a single output at minimum mixin
**\<trustedsetup>** ok thanks
**\<moneromooo>** It's actually 25%, except if that gives 0, in which case it uses 1.
**\<fluffypony>** moneromooo: and it's 25% including the "real" output, right?
**\<moneromooo>** Yes.
**\<moneromooo>** See line 2744 in wallet2.cpp
**\<fluffypony>** kk
**\<fluffypony>** as to the other open PRs
**\<fluffypony>** most of them are not merged yet due to their being unreviewed
**\<fluffypony>** I try give PRs a little while before reviewing them myself, otherwise I end up being the only reviewer, which is bad for security obvs
**\<fluffypony>** bear in mind that a review is *not* in-depth line-by-line analysis
**\<patthehuman>** pr is just a quick overview
**\<moneromooo>** I'd hope the review does look at all lines.
**\<fluffypony>** yup
**\<fluffypony>** it's a sanity check, and a check for obvious screw-ups, and a check for snuck-in backdoors
**\<fluffypony>** moneromooo: the key there was in-depth, not line-by-line ;)
**\<moneromooo>** OK, that's fine.
**\<fluffypony>** medusa_: are you around?
**\<fluffypony>** ok in the absence of medusa_ being around, dEBRUYNE have you been following Ilya's progress on medusa_'s issues?
**\<dEBRUYNE>** Yeah, he has fixed all issues opened by medusa_ as far as I know
**\<fluffypony>** ok great
**\<medusa_>** yes im here
**\<dEBRUYNE>** Except -> https://github.com/monero-project/monero-core/issues/29
**\<dEBRUYNE>** but that's more of a feature, which should be implemented later
**\<fluffypony>** oh cool - medusa_ how are you finding it now that most of the issues have been fixed?
**\<dEBRUYNE>** could*
**\<TedTheFicus>** MK_ + Others who are wondering, the monero-core project that is being discussed now is the GUI
**\<medusa_>** i think we need more feedback regarding the performance difference between gui wallet creation time and CLI wallet creation time
**\<medusa_>** and i dont know of any major bugs that would be dangerous
**\<fluffypony>** medusa_: there's a PR that's supposed to fix that
**\<fluffypony>** I haven't merged it yet, but it's gone through review
**\<dEBRUYNE>** Ilya merged jacquee's PR as well
**\<dEBRUYNE>** he noticed a significant improvement
**\<medusa_>** so my opinion is merge all to monero-core project master, test there again and if its good we build the bins
**\<dEBRUYNE>** ^ +1
**\<dEBRUYNE>** Beta binaries will also bring more testers, who possibly could notice something we might have overlooked
**\<fluffypony>** ok
**\<TedTheFicus>** Im down to test once the Betas are out
**\<fluffypony>** we'll need a point release of 0.10 to go with it
**\<fluffypony>** so we should at least get through the current group of pending PRs before we do that
**\<medusa_>** but we must communicate its for testing, since the seed is nowhere displayed after creation we dont want people to lose money
**\<moneromooo>** It creates a keys file, right ?
**\<fluffypony>** medusa_: well that's a pretty big issue :-P
**\<medusa_>** yes
**\<fluffypony>** ah ok
**\<fluffypony>** so monero-wallet-cli could be shipped with it for recovery
**\<TedTheFicus>** Good idea
**\<moneromooo>** Well, you do need the daemon anyway, don't you.
**\<medusa_>** yes
**\<dEBRUYNE>** \<fluffypony> so monero-wallet-cli could be shipped with it for recovery <= It's able to recover seeds
**\<dEBRUYNE>** It's just that only in the wizard the seed is shown once
**\<dEBRUYNE>** oh wait, you mean restore with the .keys file?
**\<fluffypony>** yes I meant recovery as in "recover my seed from the .keys file"
**\<ArticMine>** Recovery from seed is the issue with the GUI?
**\<dEBRUYNE>** ah gotcha
**\<dEBRUYNE>** No ArticMine, there isn't a window yet to see your seed
**\<dEBRUYNE>** after the initial wizard
**\<fluffypony>** ArticMine: no - it just doesn't display the seed again after the wizard
**\<fluffypony>** and given how many MyMonero support emails I get where people didn't write down their seed...
**\<dEBRUYNE>** Should be fairly trivial to add though
**\<fluffypony>** ok so that's about it from my side - tewinget isn't around to give us a 0MQ update
**\<fluffypony>** hyc I don't think has started tinkering with the walletDB stuff
**\<fluffypony>** also the forum - I know, I'm working on it, moved all broken deps into monero-project repos to better manage them and am fixing the last few niggly issues
**\<dEBRUYNE>** fluffypony: re: GUI, preferably we would have a tab that displays viewkey/seed/spendkey, the tab could be named Private Keys or something, with a big fat warning label :P
**\<dEBRUYNE>** Like I said, should be fairly trivial to add
**\<fluffypony>** dEBRUYNE: good idea - open an issue for it and let Ilya do it asap :)
**\<fluffypony>** ok so we have 7 minutes before the Kovri meeting, any other things to discuss?
**\<dEBRUYNE>** fluffypony: will do
**\<dEBRUYNE>** NoodleDoodle isn't here right?
**\<moneromooo>** Who wants to volunteer to review some patches from time to time ? :)
**\<dEBRUYNE>** moneromooo: Similiarly, would you be able to glance over / review the trezor XMR code?
**\<moneromooo>** Where is it ?
**\<fluffypony>** on NoodleDoodle's computer
**\<dEBRUYNE>** https://github.com/NoodleDoodleNoodleDoodleNoodleDoodleNoo
**\<dEBRUYNE>** ^ moneromooo
**\<dEBRUYNE>** he has some commits in his monero repository and in trezor-xmr
**\<fluffypony>** :-P
**\<i2p-relay> {-anonimal}** moneromooo: I review many of them but I don't spend enough time with the codebase to ack/nack
**\<moneromooo>** anonimal, thanks :)
**\<moneromooo>** dEBRUYNE: Do you know which one of the three repos is the right one ?
**\<moneromooo>** xmr, common, mcu. xmr seems likely to be one at least.
**\<dEBRUYNE>** oh trezor-xmr
**\<dEBRUYNE>** and monero
**\<dEBRUYNE>** So his commits here -> https://github.com/NoodleDoodleNoodleDoodleNoodleDoodleNoo/monero/commits/master?author=NoodleDoodleNoodleDoodleNoodleDoodleNoo
**\<moneromooo>** OK, I'll keep that in mind then.
**\<dEBRUYNE>** & here -> https://github.com/NoodleDoodleNoodleDoodleNoodleDoodleNoo/trezor-xmr
**\<medusa_>** i can not review the code, but i can test specific pull requests if you guys explain me what you changed
**\<dEBRUYNE>** trezor-mcu / trezor-common has no commits from NoodleDoodle moneromooo
**\<moneromooo>** medusa_: 1082 and 1121 could do with some testing if you feel like it.
**\<moneromooo>** And 1140 :)
**\<moneromooo>** 1082 changes the way fake outs are selected
**\<cryptotekk>** wow in this pace i see GUI by tonight lol
**\<moneromooo>** 1121 replaces the sweep_unmixable code to be more stable and, well, better
**\<moneromooo>** 1141 adds cold wallet signing
**\<medusa_>** oh i can test 1141
**\<medusa_>** i still have the setip from the --offline thing
**\<moneromooo>** 1140, sorry. Off by one...
**\<fluffypony>** oh no off by one bug!
**\<medusa_>** will have a look, thanks
**\<moneromooo>** Mac, Linux, and Plan9.
**\<cryptotekk>** android please
**\<liberte>** lol
**\<fluffypony>** hokay
**\<fluffypony>** that's the end of that
**\<fluffypony>** Hi all
**\<fluffypony>** starting meeting bot
**\<moneromooo>** I'm none of them.
**\<dEBRUYNE>** I am here
**\<fluffypony>** moneromooo: I know you're here :)
**\<fluffypony>** ok meeting bot is up
**\<dnaleor>** watching
**\<fluffypony>** so
**\<meeting-bot> [anonimal]** #kovri-dev too?
**\<fluffypony>** kovri-dev is roped in too
**\<othe>** k
**\<meeting-bot> [i2p-relay] {-moneromooo}** o
**\<fluffypony>** this is our first post-0.10.0 meeting
**\<fluffypony>** the 0.10.0 release went fairly smoothly
**\<fluffypony>** apart from the boost oddities
**\<fluffypony>** on the Boost serialisation stuff
**\<fluffypony>** it's not really feasible to do a point release just for that just yet - in a few weeks I'll have local build infrastructure that will make releases a lot easier on me
**\<fluffypony>** since I can secure local machines far more easily than Internet-facing machines at a DC
**\<fluffypony>** in the interim, if anyone is struggling with it the easiest thing for them to do is recover their wallet from the seed / keys
**\<moneromooo>** And keep the old cache if they have tx keys they want to keep.
**\<fluffypony>** ^^
**\<fluffypony>** I'd also like to welcome all the new contributors
**\<fluffypony>** even if it's just correcting a spelling error, all contributions are valuable
**\<fluffypony>** and very much appreciated
**\<fluffypony>** one thing I would like to encourage with the new contributors is to submit your GPG key via PR
**\<fluffypony>** and side-channel it to myself or moneromooo or someone so we can independently verify the correct key goes in
**\<fluffypony>** they live in utils/gpg_keys/
**\<meeting-bot> [anonimal]** and if moneromooo says "ok" in your PR, that's a GOOD thing!
**\<fluffypony>** and then once you've done that you can GPG sign your commits with -S
**\<fluffypony>** eg. git commit -S -am "meaningful commit message"
**\<moneromooo>** Only if it's at the start.
**\<patthehuman>** Is there anything that needs to be made for iOS
**\<fluffypony>** lol anonimal
**\<fluffypony>** patthehuman: it's an open-source project, so if you want to build something for iOS then please do
**\<fluffypony>** no need to ask permission or anyway
**\<fluffypony>** I'd be interested to see if we could package a full node for iOS (without the wallet, lest it get removed from the app store)
**\<patthehuman>** sure, i guess i'm wondering more along the lines of what needs to be built
**\<patthehuman>** can you outline how that would work?
**\<fluffypony>** and then an old iPhone or iPod Touch would work as a full node on wifi
**\<fluffypony>** well we have native ARMv8 builds
**\<fluffypony>** and interacting with the daemon over RPC isn't hard
**\<ArticMine>** Why not just go with Cydia on jailbroken iOS?
**\<fluffypony>** but I have no idea if an iOS app would let you arbitrarily launch a process
**\<endogenic>** ArticMine: too few jailbreak their devices, no?
**\<fluffypony>** ArticMine: absolutely - would be nice to be able to launch it as an app tho
**\<patthehuman>** generally apps get removed from the app store if they are simple "remotes"
**\<endogenic>** fluffypony: iOS does not allow you to spawn processes... no NSTask etc equivalent
**\<fluffypony>** ah
**\<TedTheFicus>** ArcticMine: I think Cydia is a good plan B. Not many non tech people are going to have jail broken phones
**\<patthehuman>** right, they have a list of closed API's that will get you banned
**\<fluffypony>** does Objective-C let you also run native C / C++ code?
**\<endogenic>** fluffypony: yep as long as you can compile for an ARM target
**\<endogenic>** compile it*
**\<MK__>** ArticMine : A good idea and a lot of IOS devices have Jailbreak , Remember that XMR are used in the DNM as well
**\<fluffypony>** yeah we have ARMv8 support across the board
**\<endogenic>** Objective-C is a strict superset of C, so any C is good, and C++ can be compiled too
**\<ArticMine>** Net applications Android 69.18% IOS 25.02% market share
**\<fluffypony>** anyway we're getting side-tracked a little - patthehuman feel free to play around with it, if you feel like it
**\<patthehuman>** sure
**\<fluffypony>** so
**\<fluffypony>** ringCT is live in testnet, and more testing would be appreciated
**\<fluffypony>** mWo12's testnet block explorer is helpful
**\<fluffypony>** but performance testing is also immensely useful
**\<fluffypony>** see what cracks under pressure
**\<fluffypony>** we have a short window until the January hard fork, so we need to hammer testnet as much as possible
**\<trustedsetup>** is there a testnet faucet somewhere? or is mining or irc begging for testnet xmr recommended?
**\<fluffypony>** just ask me and I'll send testnet XMR your way
**\<patthehuman>** are there any automation processes that can hammer on testnet?
**\<patthehuman>** i have access to a lot of r510 servers that i could potentially mirror some script to hammer on it
**\<fluffypony>** patthehuman: you could pretty much just write a bash script to send to yourself once a second
**\<fluffypony>** and cycle it that way
**\<patthehuman>** cool
**\<fluffypony>** and then see how your testnet node(s) handle catch ups, and if they keep up with testnet when blocks are bigger
**\<fluffypony>** we also have our new buildbots ticking along nicely
**\<fluffypony>** so we'll be killing off Travis at some point in the coming weeks
**\<fluffypony>** build bot output has been relegated to #monero-bots
**\<fluffypony>** and that channel is relayed to irc2p
**\<meeting-bot> [anonimal]** Thanks pigeons
**\<meeting-bot> [anonimal]** monero-build.i2p is also online
**\<fluffypony>** yeah pigeons has done great work
**\<fluffypony>** at the moment we're building for a ton of platforms
**\<fluffypony>** including macOS 10.9, 10.10, 10.11
**\<fluffypony>** so we should pick up PRs that break compilation more rapidly
**\<fluffypony>** how we handle testing is a bit harder
**\<fluffypony>** especially since some of the tests take several hours to run
**\<fluffypony>** my current leaning is towards nightly builds + tests
**\<fluffypony>** (of master)
**\<fluffypony>** that way we'll catch tests that are broken by any merged PRs
**\<moneromooo>** Daily core_tests would be useful.
**\<fluffypony>** performance_tests would also be useful
**\<fluffypony>** that way we can track anything that has a huge impact on performance
**\<moneromooo>** As long as the outcome can be seen without too many hoops (ie, javacrsipt)
**\<fluffypony>** moneromooo: we'll probably just grab the output, parse it, and shove it in a database
**\<fluffypony>** then we can create a profiler for the site without too many issues
**\<fluffypony>** on the PR side
**\<fluffypony>** has anyone looked at 1082?
**\<patthehuman>** no my apologies for being new but can you elaborate on what 1082 is
**\<fluffypony>** or actually moneromooo: can you give everyone a brief overview of what 1082 does
**\<fluffypony>** oh sorry patthehuman - PR = pull request
**\<fluffypony>** so PR 1082 = https://github.com/monero-project/monero/pull/1082
**\<patthehuman>** yeah im familiar with PR's (worst part of my work day lol)
**\<moneromooo>** Ah, as the comment says, really.
**\<moneromooo>** It just tries to avoid the case where someone sends money just after receiving it.
**\<moneromooo>** That's a common enough case.
**\<fluffypony>** "25% of the outputs are selected from the last 5 days (if possible), in order to avoid the common case of sending recently received outputs again. 25% and 5 days are subject to review later, since it's just a wallet level change."
**\<trustedsetup>** where did the 25% come from? 25% seems somewhat arbitrary. did MRL have input on this number?
**\<moneromooo>** They're aribtrary.
**\<fluffypony>** trustedsetup: the MRL is of the opinion that we're never going to find a "perfect" distribution, and that distribution should be re-evaluated regularly
**\<luigi1112>** Will look at it
**\<fluffypony>** 25% would only be a single output at minimum mixin
**\<trustedsetup>** ok thanks
**\<moneromooo>** It's actually 25%, except if that gives 0, in which case it uses 1.
**\<fluffypony>** moneromooo: and it's 25% including the "real" output, right?
**\<moneromooo>** Yes.
**\<moneromooo>** See line 2744 in wallet2.cpp
**\<fluffypony>** kk
**\<fluffypony>** as to the other open PRs
**\<fluffypony>** most of them are not merged yet due to their being unreviewed
**\<fluffypony>** I try give PRs a little while before reviewing them myself, otherwise I end up being the only reviewer, which is bad for security obvs
**\<fluffypony>** bear in mind that a review is *not* in-depth line-by-line analysis
**\<patthehuman>** pr is just a quick overview
**\<moneromooo>** I'd hope the review does look at all lines.
**\<fluffypony>** yup
**\<fluffypony>** it's a sanity check, and a check for obvious screw-ups, and a check for snuck-in backdoors
**\<fluffypony>** moneromooo: the key there was in-depth, not line-by-line ;)
**\<moneromooo>** OK, that's fine.
**\<fluffypony>** medusa_: are you around?
**\<fluffypony>** ok in the absence of medusa_ being around, dEBRUYNE have you been following Ilya's progress on medusa_'s issues?
**\<dEBRUYNE>** Yeah, he has fixed all issues opened by medusa_ as far as I know
**\<fluffypony>** ok great
**\<medusa_>** yes im here
**\<dEBRUYNE>** Except -> https://github.com/monero-project/monero-core/issues/29
**\<dEBRUYNE>** but that's more of a feature, which should be implemented later
**\<fluffypony>** oh cool - medusa_ how are you finding it now that most of the issues have been fixed?
**\<dEBRUYNE>** could*
**\<TedTheFicus>** MK_ + Others who are wondering, the monero-core project that is being discussed now is the GUI
**\<medusa_>** i think we need more feedback regarding the performance difference between gui wallet creation time and CLI wallet creation time
**\<medusa_>** and i dont know of any major bugs that would be dangerous
**\<fluffypony>** medusa_: there's a PR that's supposed to fix that
**\<fluffypony>** I haven't merged it yet, but it's gone through review
**\<dEBRUYNE>** Ilya merged jacquee's PR as well
**\<dEBRUYNE>** he noticed a significant improvement
**\<medusa_>** so my opinion is merge all to monero-core project master, test there again and if its good we build the bins
**\<dEBRUYNE>** ^ +1
**\<dEBRUYNE>** Beta binaries will also bring more testers, who possibly could notice something we might have overlooked
**\<fluffypony>** ok
**\<TedTheFicus>** Im down to test once the Betas are out
**\<fluffypony>** we'll need a point release of 0.10 to go with it
**\<fluffypony>** so we should at least get through the current group of pending PRs before we do that
**\<medusa_>** but we must communicate its for testing, since the seed is nowhere displayed after creation we dont want people to lose money
**\<moneromooo>** It creates a keys file, right ?
**\<fluffypony>** medusa_: well that's a pretty big issue :-P
**\<medusa_>** yes
**\<fluffypony>** ah ok
**\<fluffypony>** so monero-wallet-cli could be shipped with it for recovery
**\<TedTheFicus>** Good idea
**\<moneromooo>** Well, you do need the daemon anyway, don't you.
**\<medusa_>** yes
**\<dEBRUYNE>** \<fluffypony> so monero-wallet-cli could be shipped with it for recovery <= It's able to recover seeds
**\<dEBRUYNE>** It's just that only in the wizard the seed is shown once
**\<dEBRUYNE>** oh wait, you mean restore with the .keys file?
**\<fluffypony>** yes I meant recovery as in "recover my seed from the .keys file"
**\<ArticMine>** Recovery from seed is the issue with the GUI?
**\<dEBRUYNE>** ah gotcha
**\<dEBRUYNE>** No ArticMine, there isn't a window yet to see your seed
**\<dEBRUYNE>** after the initial wizard
**\<fluffypony>** ArticMine: no - it just doesn't display the seed again after the wizard
**\<fluffypony>** and given how many MyMonero support emails I get where people didn't write down their seed...
**\<dEBRUYNE>** Should be fairly trivial to add though
**\<fluffypony>** ok so that's about it from my side - tewinget isn't around to give us a 0MQ update
**\<fluffypony>** hyc I don't think has started tinkering with the walletDB stuff
**\<fluffypony>** also the forum - I know, I'm working on it, moved all broken deps into monero-project repos to better manage them and am fixing the last few niggly issues
**\<dEBRUYNE>** fluffypony: re: GUI, preferably we would have a tab that displays viewkey/seed/spendkey, the tab could be named Private Keys or something, with a big fat warning label :P
**\<dEBRUYNE>** Like I said, should be fairly trivial to add
**\<fluffypony>** dEBRUYNE: good idea - open an issue for it and let Ilya do it asap :)
**\<fluffypony>** ok so we have 7 minutes before the Kovri meeting, any other things to discuss?
**\<dEBRUYNE>** fluffypony: will do
**\<dEBRUYNE>** NoodleDoodle isn't here right?
**\<moneromooo>** Who wants to volunteer to review some patches from time to time ? :)
**\<dEBRUYNE>** moneromooo: Similiarly, would you be able to glance over / review the trezor XMR code?
**\<moneromooo>** Where is it ?
**\<fluffypony>** on NoodleDoodle's computer
**\<dEBRUYNE>** https://github.com/NoodleDoodleNoodleDoodleNoodleDoodleNoo
**\<dEBRUYNE>** ^ moneromooo
**\<dEBRUYNE>** he has some commits in his monero repository and in trezor-xmr
**\<fluffypony>** :-P
**\<i2p-relay> {-anonimal}** moneromooo: I review many of them but I don't spend enough time with the codebase to ack/nack
**\<moneromooo>** anonimal, thanks :)
**\<moneromooo>** dEBRUYNE: Do you know which one of the three repos is the right one ?
**\<moneromooo>** xmr, common, mcu. xmr seems likely to be one at least.
**\<dEBRUYNE>** oh trezor-xmr
**\<dEBRUYNE>** and monero
**\<dEBRUYNE>** So his commits here -> https://github.com/NoodleDoodleNoodleDoodleNoodleDoodleNoo/monero/commits/master?author=NoodleDoodleNoodleDoodleNoodleDoodleNoo
**\<moneromooo>** OK, I'll keep that in mind then.
**\<dEBRUYNE>** & here -> https://github.com/NoodleDoodleNoodleDoodleNoodleDoodleNoo/trezor-xmr
**\<medusa_>** i can not review the code, but i can test specific pull requests if you guys explain me what you changed
**\<dEBRUYNE>** trezor-mcu / trezor-common has no commits from NoodleDoodle moneromooo
**\<moneromooo>** medusa_: 1082 and 1121 could do with some testing if you feel like it.
**\<moneromooo>** And 1140 :)
**\<moneromooo>** 1082 changes the way fake outs are selected
**\<cryptotekk>** wow in this pace i see GUI by tonight lol
**\<moneromooo>** 1121 replaces the sweep_unmixable code to be more stable and, well, better
**\<moneromooo>** 1141 adds cold wallet signing
**\<medusa_>** oh i can test 1141
**\<medusa_>** i still have the setip from the --offline thing
**\<moneromooo>** 1140, sorry. Off by one...
**\<fluffypony>** oh no off by one bug!
**\<medusa_>** will have a look, thanks
**\<moneromooo>** Mac, Linux, and Plan9.
**\<cryptotekk>** android please
**\<liberte>** lol
**\<fluffypony>** hokay
**\<fluffypony>** that's the end of that