# Pastebin R7wfEZA0
(2:54:13 PM) needmoney90: never a dull day in moneroland
(2:54:16 PM) jtgrassie [jtgrassie@gateway/shell/panicbnc/x-cqrpdilpftufdjxq] entered the room.
(2:54:19 PM) needmoney90: how do I say moneroland in esperanto
(2:54:21 PM) rehrar: alright, so it becomes abundantly clear to me that the future of Kovri doesn't matter in the slightest anymore for Monero
(2:54:36 PM) jtgrassie: looks that way
(2:54:36 PM) rehrar: oneiric, morrocanmalinois, anonimal, and sean can do what they wish with it
(2:54:46 PM) ***serhack is eating a pizza. A pizza is more important than kovri meeting.
(2:54:51 PM) sgp_: I ALMOST didn't say anything back
(2:54:57 PM) rehrar: it has become a project that Monero should not integrate
(2:55:07 PM) ferretinjapan: In reviewbrah's words re: that #kovri meeting, "My disappointment is immeasurable, and my day is ruined"
(2:55:08 PM) jtgrassie: honehstly ridiculous
(2:55:09 PM) anonimal: FYI this was monero "community's" doing
(2:55:09 PM) rehrar: sgp_: you're such a dork :P
(2:55:22 PM) ErCiccione: sorry guys. I really hope a meeting would have been helpful to many. It became a shit show, i apologize :(
(2:55:24 PM) pigeons: spook dork
(2:55:26 PM) rehrar: the funny thing is, I agree with anonimal
(2:55:33 PM) ***sgp_ La Justina wants pizza
(2:55:39 PM) anonimal: The loss of technical understanding here is really quite interesting.
(2:55:48 PM) anonimal: Sekreta allows you to pick and choose your underlying system.
(2:55:51 PM) anonimal: Problem solved.
(2:55:53 PM) rehrar: for the past many whiles there has been many dropping of the balls by the core team and community, not just in regards to kovri, but in regards to Monero also
(2:56:17 PM) rehrar: infrastructure, timely freezes, and more (which were planned for but not implemented)
(2:56:26 PM) rehrar: this is a result of people doing this out of their free time, and being all open source and stuff
(2:56:35 PM) ferretinjapan: ErCiccione, you tried, others were determined to derail it, c'est la vie.
(2:56:35 PM) rehrar: can all of these things improve. Yes. Drastically.
(2:56:42 PM) rehrar: But we can't change the past. We are where we are now.
(2:56:54 PM) sgp_: Inspirational!
(2:57:00 PM) sgp_: Let's continue this meeting with the third question: what options does Monero have available going forward?
(2:57:00 PM) rehrar: and the project looks very different than two years ago
(2:57:04 PM) serhack left the room (quit: Remote host closed the connection).
(2:57:15 PM) sgp_: Issue 300 has a good outline: https://github.com/monero-project/meta/issues/300
(2:57:15 PM) rehrar: fp is responsible for less and less things, which is beneficial for both him and us
(2:57:22 PM) rehrar: I'm not finished. This is important.
(2:57:27 PM) NeuroScr: anonimal: leaking metadata over multiple mixnets doesn’t sound ideal
(2:57:45 PM) sgp_: Let's talk through them one-by-one unless someone has a better idea
(2:57:50 PM) rehrar: Monero's past is messy. Decentralization tends to lead to this kind of mess more often than not.
(2:58:09 PM) anonimal: NeuroScr: leaking? metadata? Care to come to #sekreta-dev?
(2:58:09 PM) rehrar: This messy past has had a huge hand in where we are today as a project. Many good points. Many bad ones.
(2:58:10 PM) _Slack: <sean> sgp_: Here's that little write-up I did: https://paste.debian.net/hidden/3e4fe713/
(2:58:47 PM) sgp_: ping knaccc - are you here?
(2:59:12 PM) _Slack: <sean> The ETA is entirely guestimates. I tried adding in time-frames for security audits, etc.
(2:59:33 PM) sgp_: Thanks, we can go line by line through this
(2:59:33 PM) xiphon: Would like to discuss TOR as well
(2:59:41 PM) asymptotically: are we having the meeting in both channels or is this something else
(2:59:44 PM) sgp_: xiphon: remind me to add it, it's in #300
(3:00:24 PM) sgp_: asymptotically: we moved the discussion here since it's from Monero's point of view
(3:00:29 PM) sgp_: 1. Kovri: coupled, C++, monerod work=low, availability=8 months?
(3:00:42 PM) jtgrassie: knaccc and I (with help from the i2-java guys) seem to be making good progress
(3:00:55 PM) jtgrassie: sorry sgp_ paths crossed
(3:01:00 PM) ErCiccione: I just realized that "la justina" was referred to you sgp_. That's something i consider really offensive, i'm sorry it happened
(3:01:04 PM) sgp_: Kovri is in a worse state than i2pd, a comparable C++ I2P router
(3:01:08 PM) ferretinjapan: asymptotically, #kovri meeting is pretty much done it looks.
(3:01:24 PM) sgp_: jtgrassie: no worries, we'll get there
(3:01:32 PM) ErCiccione: it is, ferretinjapan. i'm about to call it off
(3:01:34 PM) jtgrassie: Kovri is not coded well - there, said it
(3:02:18 PM) rehrar: and I think that's a big issue in all this jtgrassie. I don't think a single person disagrees with you among the people coding on kovri
(3:02:18 PM) sgp_: and it will take months to get to a usable state, and more time to get integrated with mobile
(3:02:20 PM) hyc [hyc@openldap/hyc] entered the room.
(3:02:37 PM) ferretinjapan: rehrar, I agree in principal, but I think what has let kovri down the most, is transparency, and accountability.
(3:02:41 PM) sgp_: and by the time we're "done," other projects would have done more cool new things
(3:03:07 PM) anonimal: jtgrassie: i2pd, not kovri. Also, you have ZERO commits to kovri.
(3:03:26 PM) anonimal: Mind you, we're having an actually useful technical discussion in #kovri since no one here really knows how best to proceed.
(3:03:51 PM) jtgrassie: and we are having a monero i2p discussion here
(3:03:59 PM) ferretinjapan: *certain* people working on kovri have not been as commuinicable as they needed to be, and that has had severe implocations for development devisions, and progress.
(3:04:11 PM) sgp_: Is there anyone in favor of pursuing a future Kovri integration?
(3:04:23 PM) fluffypony: if I may give my opinion
(3:04:30 PM) sgp_: yes, please go ahead fluffypony
(3:04:55 PM) fluffypony: I deeply appreciate the work that anonimal has done on Kovri
(3:05:13 PM) fluffypony: I think that he was under a lot of pressure to be a good FOSS maintainer, and that is a very difficult thing to do
(3:05:30 PM) fluffypony: on the one hand you want to have lots of contributors, on the other hand you want to have excellent code
(3:05:46 PM) ferretinjapan: As an open source project, thats to be expected, but when contributors are paid, that needs to be maintained to ensure that when problems are encountered, they aren't hidden ,and that people do not get incentiviesd to sweep them under the rug in order to make it look like progress is being made when it's actually hit a wall.
(3:06:10 PM) fluffypony: unfortunately he has erred on the side of excellent code - to the point of discouraging contributors
(3:06:30 PM) fluffypony: this has left Kovri in an intermediary state
(3:06:47 PM) fluffypony: it is neither "from scratch" nor is it mature
(3:07:13 PM) fluffypony: in the meantime i2pd has progressed, but there is a lot of bad blood and I see no value in pursuing that as an option
(3:07:31 PM) fort3hlulz [~fort3hlul@173.38.117.83] entered the room.
(3:07:46 PM) fluffypony: I am of the opinion that the best thing to do is let oneiric_ pursue tini2p and let anonimal move ahead in whatever he'd like, Sekreta or whatever else
(3:08:01 PM) lurkinandlearnin: I believe the fundamental issue is that Monero's development up until now has focused on practical and effective minimalisation of on-chain analysis. This is because chain analysis has had many well publicised outcomes. IP analysis has been given an overall lower priority because there are so many ways to hide an IP if that is your threat model, and there are not many well known cases of IP tracking of
(3:08:01 PM) lurkinandlearnin: blockain projects.
(3:08:16 PM) ferretinjapan: fp, indeed, perfect is the enemy of good, shifting the focus to "good" with the aspiration to be perfect should be the goal.
(3:08:18 PM) fluffypony: and in the interim we put the slim, bundled, standalone Java runtime with the i2p Java router
(3:08:44 PM) rehrar: this begets the question of the FFS fluffypony, which the core team needs to clarify whether or not they donors entrust the money and decisions to them after donation, or whether or not the donors keep the ability to divvy out milestones and core team does their bidding
(3:08:46 PM) fluffypony: knowing that (1) it's just an interim solution, and (2) it's not a full JRE installation
(3:08:56 PM) fluffypony: rehrar: I think that's a different discussion
(3:09:04 PM) rehrar: yes, but it is very intertwined with all of this
(3:09:12 PM) rehrar: there are many many things that need clarification in order to move forward
(3:09:13 PM) sgp_: fluffypony: right, knaccc has done a ton of work to get i2p-java in a usable state
(3:09:17 PM) fluffypony: well there are two separate things, right?
(3:09:25 PM) anonimal: Yes
(3:09:40 PM) fluffypony: 1. how do we proceed with whatever we do to hide IP addresses that first-broadcast transactions
(3:09:46 PM) fluffypony: 2. what do we do with the current FFS
(3:10:00 PM) fluffypony: so maybe we focus on 1 and, once resolved, we can determine 2
(3:10:11 PM) jtgrassie: 1. we are in touching distance
(3:10:16 PM) anonimal: 1. Use kovri. I never said it wouldn't be used.
(3:10:24 PM) anonimal: 1. Or use java i2p in the meantime.
(3:11:04 PM) jtgrassie: i2p-zero with vtnerd's tor PR with my patch on top, that works
(3:11:21 PM) fluffypony: anonimal: given the state of Kovri and the trailing brokenness from the old i2pd from which it forked, do you recommend trying to salvage that or just use i2p-java as a stable intermediary?
(3:13:25 PM) sgp_: fluffypony: I think Kovri's lack of the latest ntcp2 protocol is a strong reason not to use it
(3:13:41 PM) sgp_: even if oneiric_ has been working on it, it's not done yet
(3:13:49 PM) fluffypony: that's definitely a strong point
(3:13:54 PM) anonimal: I've discussed this in detail: NTCP2 is not an audited protocol. Zero research.
(3:14:04 PM) anonimal: It's like releasing bulletproofs without having done OSTIF.
(3:14:12 PM) anonimal: Even worse, the minds involved were not MRL.
(3:14:15 PM) zlatinb: that is not true.
(3:14:19 PM) anonimal: So, that is a very lack argument sgp_
(3:14:28 PM) anonimal: Noise has been audited
(3:14:31 PM) anonimal: zlatinb: proof?
(3:14:34 PM) zlatinb: NTCP2 was presented to the Noise mailing list and the modifications have been approved.
(3:14:38 PM) oneiric_: ntcp2 is largely base on noise which has formal auditing
(3:14:49 PM) anonimal: zlatinb: link?
(3:15:04 PM) anonimal: Largely != entirely.
(3:15:10 PM) oneiric_: sgp_: i never proposed tini2p as a "right now" solution
(3:15:20 PM) ferretinjapan: anonimal, what is going to provide better protection than current practices, that is going to be provide the best trade off, is what fluffypony asked.
(3:15:22 PM) zlatinb: I will ask zzz for a link
(3:15:23 PM) Febo [Febo@89-212-17-205.static.t-2.net] entered the room.
(3:15:30 PM) sgp_: oneiric_: sorry if I claimed that, I never meant to say that was the case
(3:15:44 PM) ***anonimal responding
(3:15:49 PM) oneiric_: in fact, from the beginning, i suggested bugfixing/patching kovri, or using another router until we figure out a long term solution
(3:16:43 PM) oneiric_: also why i advocate for loose-coupling, hopefully decisions made now don't lock monero down into one tech or the other
(3:16:43 PM) sgp_: oneiric_: right, and we are in agreement short-term. Apologies if I worded things misleadingly
(3:17:02 PM) oneiric_: sure, it's fine
(3:17:23 PM) fluffypony: ideally something like Tor's pluggable transports would be good
(3:17:32 PM) fluffypony: but we can always implement that later
(3:17:40 PM) anonimal: What I don't understand is why oneiric_ is literally repeating everything I've said and proposed but not everyone is listening to what I have to say.
(3:17:53 PM) anonimal: fluffypony: that's a good question, I need a minute to think of how best to word
(3:18:32 PM) anonimal: I say we do both and all. There's no reason to limit monero's network stack. Until Sekreta is finished, we can use all of the above and give the user a run-time option.
(3:18:54 PM) anonimal: The question solution, in order:
(3:19:05 PM) anonimal: 1. merge the SOCKS proxy; can be used with Tor or Kovri
(3:19:24 PM) anonimal: 2. I2CP/SAM via java I2P if it gets done in the next couple of months
(3:19:40 PM) anonimal: 3. "baked-in" kovri, even if 2. is completed.
(3:19:55 PM) jtgrassie: 1) works now with i2p-zero
(3:20:29 PM) luigi1111w [~luigi1111@unaffiliated/luigi1111] entered the room.
(3:20:40 PM) jtgrassie: 2) would require quite a bit of monero work, not 2 months IMO
(3:21:12 PM) anonimal: Great, 3 will come before 2 then. FYI I never said I wouldn't do it.
(3:21:47 PM) sgp_: Is there any value in 3 if it uses outdated protocols? Why not just bake-in the i2p-zero solution?
(3:21:55 PM) jtgrassie: 3) would depend how ready kovri is
(3:22:10 PM) jtgrassie: sgp_: agreed 100%
(3:22:15 PM) anonimal: sgp_: it's not outdated: Java I2P supports NTCP as well.
(3:22:27 PM) anonimal: What you really need to ask yourself is, why is Java I2P using outdated crypto
(3:22:28 PM) sgp_: anonimal: right, but NTCP2 is the default
(3:22:43 PM) anonimal: Only on specific versioned routers
(3:22:52 PM) anonimal: There are plenty of routers that don't use the latest version.
(3:23:09 PM) zlatinb: that is not true either
(3:23:10 PM) sgp_: in any case: why purposefully choose the older, worse solution?
(3:23:12 PM) anonimal: Like I said, a very convoluted network. Many moving parts with various reasons for backwards compat.
(3:23:13 PM) jtgrassie: java-i2p is under much more dev, more usage etc etc
(3:23:18 PM) anonimal: zlatinb: no, look at stats.i2p
(3:23:22 PM) zlatinb: more than 80% of the network is at the latest router version
(3:23:28 PM) zlatinb: yes that’s where I get my data from
(3:23:29 PM) anonimal: 80% != 100%
(3:23:36 PM) anonimal: Or did you not learn basic math?
(3:23:52 PM) fort3hlulz: why so toxic lmao
(3:23:55 PM) sgp_: anonimal: there's no reason to use a router that uses a protocol only ~20% and decreasing use by default
(3:24:09 PM) anonimal: There's no reason to use any router that uses DSA/SHA1
(3:24:12 PM) anonimal: Then why use java I2P?
(3:24:15 PM) fort3hlulz: Everytime Kovri is discussed everyone gets their panties in a wad
(3:24:16 PM) anonimal: Or Tor for that matter?
(3:24:17 PM) sgp_: And please don't use insulting comments like those here on this channel
(3:24:18 PM) anonimal: Hmm?
(3:24:36 PM) anonimal: Please don't try to control other people. Answer the questions.
(3:24:52 PM) ***anonimal drum shot
(3:25:03 PM) anonimal: Anyway, it's simple;
(3:25:09 PM) xiphon: Is that is supposed to be time wasting meeting again?
(3:25:17 PM) xiphon: We already had one in #kovri
(3:25:29 PM) anonimal: Those are real questions
(3:25:37 PM) anonimal: Why use a network that supports DSA/SHA1 by default?
(3:25:44 PM) anonimal: Can anyone here answer that?
(3:25:53 PM) anonimal: No. So don't try to use the argument with NTCP2.
(3:25:56 PM) anonimal: Besides, easy solution:
(3:26:06 PM) anonimal: ./monero --enable-kovri  # disabled by default
(3:26:12 PM) ferretinjapan: Everyones too polite/professional to answer you right now anonimal.
(3:26:15 PM) anonimal: or replace with whatever you do like /don't like
(3:26:16 PM) ErCiccione: xiphon: At least we got the conversation going. That was basically the point
(3:27:00 PM) anonimal: Ok, so when I don't have an answer for something, I'll just use that excuse ferretinjapan
(3:27:31 PM) sgp_: Besides anonimal, is there anyone else in favor of using Kovri as a short-term solution (assuming it can be made production-ready) instead of i2p-zero?
(3:27:34 PM) anonimal: fluffypony: here's what I would've said in 2015 if java i2p was on the table,
(3:27:35 PM) xiphon: ErCiccione: it is pretty obvious that Monero won't use Kovri at the moment
(3:27:50 PM) lurkinandlearnin: I'm learning a lot from all these arguments. I just wish there was a log somewhere because I have to leave soon and my logging is about 5% reliable.
(3:28:04 PM) anonimal: fluffypony: I'd the java i2p approach until kovri is finished. SOCKS proxy for Tor support in the meantime. Make all optional/configurable.
(3:28:07 PM) rehrar: mattermost lurkinandlearnin
(3:28:12 PM) luigi1111w: ewww
(3:28:25 PM) ErCiccione: xiphon: That was obvious also before
(3:28:33 PM) rehrar: luigi1111w: to me? :P
(3:28:38 PM) luigi1111w: :)
(3:28:40 PM) lurkinandlearnin: never used it but I'll check it out pronto
(3:28:46 PM) rehrar: mattermost.getmonero.org
(3:29:23 PM) sgp_: Let's speak a little more in detail about some of the benefits and drawbacks of i2p-zero
(3:29:31 PM) sgp_: sean you still here?
(3:29:57 PM) _Slack: <sean> Yes,
(3:29:59 PM) awfulcrawler_[m] [awfulcrawl@gateway/shell/matrix.org/x-xfqdxgrscrutpnlk] entered the room.
(3:30:08 PM) sgp_: Benefit: no need for users to install Java, like they needed to in 2014
(3:30:12 PM) xiphon: In case if some of you guys don't get it right, let me clarify that i2p-zero is not a single binary, but is a bundle containing ~150 files in ~25 folders
(3:30:23 PM) xiphon: This is not critical
(3:30:26 PM) jtgrassie: benefit is it uses the production i2p-java
(3:30:30 PM) xiphon: But kind of thing we have to know about
(3:30:54 PM) hyc: that sounds like "large attack surface"
(3:31:36 PM) sgp_: I don't understand the difference between i2p-java over SOCKS (i2p-zero) and SAM3. Can someone else elaborate a little more about this? jtgrassie?
(3:31:40 PM) NeuroScr: yea do you get all the security flaws of java too?
(3:31:45 PM) jtgrassie: xiphon: right now yes. It's suited for testing/dev right now
(3:32:26 PM) xiphon: jtgrassie: is it possible to pack it as a single binary?
(3:33:00 PM) jtgrassie: could be of course
(3:33:24 PM) dEBRUYNE: I am just going to throw this in here as additional discussion point -> https://github.com/monero-project/meta/issues/300#issuecomment-455943211
(3:33:33 PM) zlatinb: sgp_: my understanding is that the SOCKS implementation is a lot less effort on monerod’s behalf.  A SAM3 implementation however would be more optimal wrt network resources.  zzz has proposed a SOCKS-BIND approach as well
(3:33:49 PM) sgp_: dEBRUYNE: we can discuss Loki later
(3:33:52 PM) NeuroScr: dEBRUYNE: did you see the reply?
(3:34:14 PM) xiphon: sgp_: iirc, implementing SAM3 protocol, we will be able to create i2p endpoint at runtime and configure it at runtime. Dunno how this is called in i2p terms, basically is  a hidden service angalog in TOR terms
(3:34:22 PM) sgp_: thanks zlatinb. Are there any client compatibility issues? We're trying to work around desktop and mobile support too
(3:34:28 PM) zlatinb: I’ll paste links to the Noise mailing list discussing NTCP2:
(3:34:37 PM) dEBRUYNE: NeuroScr: Read that just now
(3:34:45 PM) zlatinb: Noise mailing list;
(3:34:46 PM) zlatinb: https://moderncrypto.org/mail-archive/noise/2018/thread.html
(3:34:47 PM) dEBRUYNE: Valid comment, although I guess it can still be up for discussion
(3:34:47 PM) zlatinb: Threads for our three extension proposals:
(3:34:49 PM) zlatinb: https://moderncrypto.org/mail-archive/noise/2018/001609.html
(3:34:50 PM) zlatinb: https://moderncrypto.org/mail-archive/noise/2018/001610.html
(3:34:50 PM) zlatinb: https://moderncrypto.org/mail-archive/noise/2018/001611.html
(3:35:23 PM) sgp_: zlatinb: I personally have confidence NTCP2 is a large step forward
(3:35:26 PM) anonimal: lolol, I'm glad to see that. I literally yelled at zzz for not posting to moderncrypto. I noted this in the monero i2p issue.
(3:35:40 PM) anonimal: sgp_: you're not a developer; you're a mouthpiece at this point.
(3:36:19 PM) anonimal: So, if MRL posted a single post to an obscure mailing list, and then released ring sigs and bulletproofs; would everyone here be happy?
(3:36:34 PM) fort3hlulz: Why the fuck are you so toxic, anonimal?
(3:36:36 PM) sgp_: anonimal: wrong place for this discussion
(3:36:41 PM) fort3hlulz: People here are trying to have real discussions?
(3:36:43 PM) anonimal: You can honestly say you'd be happy without having ever done OSTIF or any clearnet collaboration? Honest question.
(3:36:43 PM) MoroccanMalinois [~admin@51.15.178.6] entered the room.
(3:37:03 PM) fort3hlulz: I gave to your FFS and I sincerely regret it
(3:37:09 PM) fort3hlulz: No one with your attitude should be paid to work on Monero.
(3:37:11 PM) anonimal: fort3hlulz: because he's been subversive for a while now. Someone has to call people out on their BS.
(3:37:21 PM) fort3hlulz: You've been nothing but toxic
(3:37:27 PM) anonimal: Proof that you donated?
(3:37:28 PM) fort3hlulz: In every interaction I've seen you have
(3:37:41 PM) smooth: fort3hlulz: please try not to get in the dirt even if what you are saying may be accurate
(3:37:44 PM) sgp_: fort3hlulz anonimal please stop of I'll have to kick you both. Let's keep the discussion focused for the moment
(3:37:45 PM) fort3hlulz: Would have to dig up Tx keys
(3:37:45 PM) fort3hlulz: But I can in a bit if you really want
(3:38:00 PM) fort3hlulz: kk just trying to reign in this ridiculousness
(3:38:12 PM) fort3hlulz: Just cant stand where this all has gone, looks awful on our community
(3:38:16 PM) smooth: ignoring is usually the best way, anything else makes it worse
(3:38:28 PM) fort3hlulz: But hopefully we can pick up the pieces and have a good i2p/kovri implementation soonish
(3:38:37 PM) sgp_: I have some questions with regard to android and iOS support and how routers could interact with popular Monero mobile wallets
(3:38:44 PM) fort3hlulz: Yeah you're right smooth
(3:38:50 PM) fort3hlulz: Me trying to interject has never been helpful...
(3:39:09 PM) sgp_: sean has expressed concern that these users are not being represented well enough
(3:39:28 PM) smooth: fort3hlulz: its not you, it is just how these things work
(3:39:37 PM) xiphon: zlatinb: did you take a look into SOCKS-BIND implementation in i2p-java?
(3:39:40 PM) jtgrassie: sgp_: this is indeed an issue for java-i2p - mobile
(3:39:41 PM) sgp_: And there are clear use-cases for mobile i2p connections for transaction broadcast and connecting to MyMonero-type servers
(3:39:54 PM) jtgrassie: Android should be fine, but not iOS
(3:39:55 PM) zlatinb: xiphon: that’s what zzz proposed we do for you guys
(3:40:02 PM) zlatinb: right now it’s not there
(3:40:27 PM) smooth: jtgrassie: what is the issue for ios. can't compile java to it?
(3:40:39 PM) jtgrassie: smooth: no
(3:40:40 PM) sgp_: jtgrassie: since I have no idea how this works, would Monerujo add support to work with the android i2p app, or would it have i2p functionality built-in to the Monerujo app?
(3:41:38 PM) smooth: jtgrassie: what is it i see when i google for ios java and i see all sort of pages about how to create great java apps for ios?
(3:41:44 PM) jtgrassie: sgp_: it could work either way. Though on mobile, the use case is slightly different anyway.
(3:42:04 PM) jtgrassie: Mobile wallets all use remote nodes.
(3:42:18 PM) jtgrassie: So those remote nodes would do the relaying.
(3:42:39 PM) jtgrassie: Unless you know of a mobile app that runs a full node too
(3:42:39 PM) sgp_: Right, and we still need to have design decisions about full wallet sync with remote nodes over i2p. That would be SLOW
(3:42:56 PM) ErCiccione left the room (quit: Remote host closed the connection).
(3:43:09 PM) sgp_: jtgrassie: I think we can consider mobile full nodes out of scope for now
(3:43:15 PM) jtgrassie: Well I havent tested yet but hyc suggested fluffyblocks might be ok actually
(3:43:19 PM) smooth: jtgrassie: isnt the issue of how the wallet connects to the remote node (without e.g. spying by mobile provider) relevant
(3:43:29 PM) sgp_: even pruned nodes need 25GB of storage
(3:43:46 PM) jtgrassie: smooth: yes this is true in one use case
(3:44:09 PM) smooth: im not really sure there is a use case where it isn't
(3:44:18 PM) sgp_: It's important to have mobile support for two main reasons:
(3:44:27 PM) xiphon: Does anyone have any insight on compiling libsam3 using MSYS2?
(3:44:28 PM) sgp_: 1) hiding when connecting to a MyMonero-type server
(3:44:36 PM) smooth: even if the user doesn't care, mass spying can compromise the network integrity as a whole
(3:44:53 PM) jtgrassie: for the case of hiding the source IP of transaction, if not using i2p/tor with public node, theres leakage
(3:44:57 PM) sgp_: 2) hiding some information (possibly just broadcasting the transaction, but also possibly the option for full wallet sync) from remote nodes
(3:45:56 PM) jtgrassie: smooth I'm in agreement, I just think the discussion wrt to mobile is a wider one
(3:46:01 PM) sgp_: I can't speak for endogenic, but I suspect he is generally in favor of a long-term Kovri-lite router, since it would more easily work with iOS
(3:46:03 PM) rehrar: what smooth just said is the most important thing always
(3:46:21 PM) rehrar: privacy is like driving. If you don't care about your own safety, that's fine for you, but your reckless driving will still kill other people
(3:46:23 PM) endogenic: sgp_: yes kovri or something similarly embeddable like oneiric_'s idea for a minimal router
(3:46:45 PM) sgp_: So we can pursue i2p-zero now and I think that
(3:47:07 PM) jtgrassie: but as I say, using java-i2p just wont work on iOS
(3:47:07 PM) sgp_: *think that's still the best option in the short-term, but there are mobile drawbacks to consider for the long-term
(3:47:35 PM) jtgrassie: Android and i2p is simple
(3:47:47 PM) sgp_: Yeah, I should have said "iOS concerns" :)
(3:48:02 PM) jtgrassie: iOS, whatever solution will be hard
(3:48:16 PM) jtgrassie: even a c++ i2p router
(3:48:38 PM) hyc: objective C or Swift huh
(3:48:40 PM) dEBRUYNE: <jtgrassie> So those remote nodes would do the relaying. <= Would the remote node not still see the IP of the user that is connecting then?
(3:48:45 PM) dEBRUYNE: + see the tx that it has to relay
(3:49:13 PM) jtgrassie: dEBRUYNE: yes, it would
(3:49:13 PM) sgp_: dEBRUYNE: if the user connects to the remote node over i2p, then it protects the IP of the user connecting to the remote node
(3:49:34 PM) NeuroScr: c/c++ to obj-c integration isn’t hard
(3:49:40 PM) smooth: dEBRUYNE: the remote node seeing is an issue yes but im actually more concerned about network-level spying since that see what everyone is doing
(3:49:49 PM) jtgrassie: NeuroScr: Apple store is hard
(3:50:02 PM) NeuroScr: jtgrassie: true story
(3:50:02 PM) _Slack: <sean> dEBRUYNE: long-term could aim for separating remote nodes from transaction sends. Two separate things so different networks, perhaps?
(3:50:13 PM) lurkinandlearnin left the room (quit: Quit: Leaving).
(3:50:18 PM) sgp_: smooth: yes, the main concern absolutely is still hiding the originating NODE
(3:50:29 PM) endogenic: hyc: no, you can compile a range of languages to embed within / bind to from objc/swift/objc++
(3:50:35 PM) endogenic: c++, even rust
(3:50:48 PM) jtgrassie: just not java ;)
(3:50:50 PM) endogenic: jtgrassie: why would a C++ router be hard?
(3:51:20 PM) jtgrassie: Apple store no doubt
(3:51:33 PM) dEBRUYNE: jtgrassie: How would having I2P on mobile help then?
(3:51:52 PM) zlatinb: google has an experimental java->objC converter
(3:51:57 PM) endogenic: jtgrassie: i don't see why though
(3:52:01 PM) endogenic: they approve encryption and privacy things all the time
(3:52:06 PM) zlatinb: meeh has been playing with converting i2p code to objc
(3:52:07 PM) dEBRUYNE: smooth: Would that issue be mitigated by the remote node that broadcasts the transaction running i2p?
(3:52:15 PM) jtgrassie: dEBRUYNE: i2p on Androd will absolutely help.
(3:52:17 PM) endogenic: zlatinb: probably more trouble than it's worth but maybe interesting
(3:52:26 PM) endogenic: i would not go the route of ObjC IMO - zero reason to, generally
(3:52:32 PM) anonimal: If you want rust, then use Ire
(3:52:36 PM) jtgrassie: endogenic: look at the history of Tor on iOS
(3:52:41 PM) smooth: dEBRUYNE: im talking about spying on all the users with wallets that rely on remote nodes, but both are an issue sure
(3:52:59 PM) dEBRUYNE: Ah I see
(3:52:59 PM) endogenic: jtgrassie: end-to-end encryption is allowed all the time on the app store
(3:53:09 PM) endogenic: i don't believe we can use a different context and different case to predict what apple may do
(3:53:28 PM) endogenic: apple has a strong privacy stance nowadays anyway
(3:53:32 PM) endogenic: stronger than google's
(3:54:30 PM) jtgrassie: it's not about e2e encryption and Apple, just what you can and cant do at the system level.
(3:54:31 PM) sgp_: jtgrassie: is the plan to have an opt-in version ready for desktop for the next fork?
(3:54:41 PM) jtgrassie: e.g. you cannot fork subprocesses
(3:55:53 PM) endogenic: jtgrassie: not sure how that's relevant - forgive my ignorance
(3:55:56 PM) jtgrassie: sgp_: I think the goal should be getting vtnerd's PR in, I have a patch to add the i2p bits on top.
(3:56:15 PM) smooth: endogenic: makes it hard to integrate something that is designed to run as a separate process
(3:56:27 PM) jtgrassie: Then regardless if we can get i2p-zero ready to ship at next fork or not, users will be able to use
(3:56:28 PM) endogenic: but if it's embedded, why do we need a separate process?
(3:57:01 PM) smooth: i guess it is designed to work that way. on other OSs you can hide this from the user
(3:57:18 PM) jtgrassie: endogenic: it is one type of restriction example, not meant to be a show-stopper
(3:58:39 PM) jtgrassie: but it would mean the i2p router etal would need to be in the same process as the ios app, which is not within the short-term solve
(3:59:04 PM) zlatinb: jtgrassie: it is possible and relatively easy to invoke a jvm through jni, in tthe same process
(3:59:24 PM) jtgrassie: The short-term solve is a separate process for the i2p stuff and communicated over SOCKS
(3:59:36 PM) anonimal: jvm through jni is correct
(4:00:02 PM) jtgrassie: which apple will hastily reject
(4:00:24 PM) jtgrassie: seriously
(4:02:40 PM) sgp_: Do we have any final comments here, or can we table some of these long-term discussions and move on?
(4:03:10 PM) NeuroScr: I’m hearing socks and i2p aren’t great, that’s why you need libsam
(4:03:33 PM) sgp_: Quick summary about the meeting then
(4:03:49 PM) sgp_: We discussed the state of Kovri
(4:04:06 PM) anonimal: NeuroScr: did you get any details? What's the socks issue? Where's the proof?
(4:04:13 PM) sgp_: We generally agreed an i2p-java-based approach is more desirable in the short-term
(4:04:22 PM) anonimal: monero txs work over socks, so I'm not sure what the issue is.
(4:04:26 PM) xiphon: "I’m hearing socks and i2p aren’t great, that’s why you need libsam" <- sounds like an implementation problems
(4:04:29 PM) NeuroScr: “it's a question of getting a destiantion to send to. utbound but to where? if you cannot spawn new destinations and accept inbound connections it is useless”
(4:04:36 PM) sgp_: long-term, there are iOS benefits when using a non-java option
(4:05:09 PM) xiphon: NeuroScr: were discussing SOCKS-BIND approach
(4:05:45 PM) anonimal: NeuroScr: what he's describing is a SOCKS proxy's inability to create a libclient server tunnel, which is unrelated to the inbound tunnels created with an outgoing SOCKS connection. Literally not a problem.
(4:05:47 PM) xiphon: and right now a user might configure i2p daemon and supply Monero node with .i2p address for incoming connections
(4:05:50 PM) NeuroScr: this is why I hate playing telephone :)
(4:05:59 PM) anonimal: It's not easy, but a server simply creates a libclient server tunnel and a client uses the socks proxy.
(4:06:12 PM) anonimal: Yeah, I get it. I know psi too.
(4:06:48 PM) NeuroScr: he knows this stuff really well though
(4:06:49 PM) sgp_: just two more topics before we end: 1) Dandelion, 2) Loki
(4:06:59 PM) sgp_: 1) Dandelion
(4:07:12 PM) xiphon: I believe Dandelion is unrelated to anonimity networks discussion
(4:07:13 PM) anonimal: NeuroScr: yes, I used to work with him and will be working with on on LLARP/LokiNet integration for Sekreta
(4:07:24 PM) anonimal: Dandelion is related, somewhat.
(4:07:30 PM) xiphon: how?
(4:07:33 PM) sgp_: xiphon: it's related, but Dandelion is certainly not a replacement
(4:07:46 PM) xiphon: We can implement it with and without utulizing anonimity networks
(4:07:49 PM) sgp_: Dandelion helps hide the IP addresses of nodes that send transactions
(4:07:51 PM) anonimal: It's a curve that makes blends you in a crowd.
(4:08:00 PM) anonimal: s/makes/helps/
(4:08:00 PM) monerobux: anonimal meant to say: It's a curve that helps blends you in a crowd.
(4:08:52 PM) sgp_: other solutions are more flexible, but dandelion is cool in that you don't need a different network. It works entirely with just Monero's nodes
(4:08:58 PM) sgp_: so that means there are tradeoffs
(4:09:00 PM) sarang:  There were some issues with the original paper, but it appears I may have missed an update to it
(4:09:03 PM) sarang: and wish to review it further
(4:09:34 PM) sgp_: fluffypony indicated in the i2p-java issue that he is interested in pursuing Dandelion in addition to another anonymizing layer
(4:10:04 PM) sgp_: I say keep Dandelion in mind for a medium-term partial solutions
(4:10:09 PM) sarang: Other projects' interest makes me more curious about their implementation details
(4:10:26 PM) sgp_: Does anyone else have comments on Dandelion?
(4:10:54 PM) anonimal: I spoke too briefly about during one of my defcon talks.
(4:11:05 PM) anonimal: Not much to be said.
(4:11:26 PM) anonimal: Doesn't solve the issue of global adversary.
(4:11:29 PM) sarang: anonimal: how familiar are you with its success in the field?
(4:11:52 PM) anonimal: It's a blockchain approach to anonymity. It doesn't solve the core of IP exposure.
(4:12:06 PM) sgp_: right anonimal, it's moreso for those with the "I only care slightly" use-case
(4:12:06 PM) sarang: ok
(4:12:14 PM) anonimal: It's mathematically (seems) grounded but passive surveillance is cheap and easy, doesn't need much.
(4:12:22 PM) sarang: Better wording: how familiar are you with other projects' integrations?
(4:12:26 PM) sarang: ok ty
(4:12:50 PM) anonimal: "I only care slightly" <-- yes, that's a good way to put it. Better than nothing? Maybe?
(4:13:00 PM) anonimal: Other project's integration, I can't say right now. Nothing really comes to mind.
(4:13:16 PM) sarang: OK, a few folks had heard tell of Grin (but that's not really battle tested at all)
(4:13:27 PM) sarang: I need to re-review the paper update
(4:13:43 PM) anonimal: Ah, yes, ol' grinny. Am excited about a new MW impl.
(4:13:48 PM) moneromooo: Please post a link if/when you find an update. I'll need it.
(4:13:50 PM) anonimal: same here
(4:14:01 PM) sgp_: great, on to the final topic: Loki
(4:14:07 PM) anonimal: Loki or LokiNet?
(4:14:13 PM) anonimal: Different things, somewhat.
(4:14:15 PM) ***sgp_ looks
(4:14:23 PM) sgp_: Lokinet
(4:14:35 PM) anonimal: Ok, so the impl of LLARP.
(4:14:43 PM) anonimal: Yes, psi even says it's not production ready.
(4:14:52 PM) NeuroScr: Lokinet
(4:15:02 PM) sgp_: Lokinet has been relatively aggressive in sharing their purported benefits: https://github.com/monero-project/meta/issues/300#issuecomment-455943211
(4:15:10 PM) ferretinjapan left the room (quit: Ping timeout: 250 seconds).
(4:15:29 PM) anonimal: I'm sure it provides benefits, every network does.
(4:15:35 PM) sgp_: jtgrassie has stated in the issue that Monero should prioritize a more battle-tested solution
(4:15:46 PM) moneromooo: They only said "it is usable now". Not "pros and cons vs tor/i2p".
(4:15:47 PM) sgp_: I agree with his point of view
(4:15:53 PM) jtgrassie: just my opnion
(4:15:57 PM) xiphon: moneromooo: https://arxiv.org/abs/1805.11060 isn't it?
(4:16:00 PM) moneromooo: Granted, "usable now" is pretty good given where we are :)
(4:16:04 PM) moneromooo: ty
(4:16:32 PM) NeuroScr: moneromooo: we do the pros and cons in the dev documentations
(4:16:43 PM) sgp_: I had not heard of Lokinet until the past few weeks
(4:16:46 PM) NeuroScr: here: https://github.com/loki-project/loki-network/blob/master/docs/high-level.txt
(4:16:50 PM) moneromooo: ty
(4:17:28 PM) anonimal: Notice how we have the same complaints about I2P.
(4:17:52 PM) NeuroScr: though I will admit we probably could do a better version today, that doc is about 9 months old
(4:18:22 PM) anonimal: Last reviewed/updated 6 days ago...
(4:18:23 PM) sgp_: I understand their arguments compared to i2p, but I need to read more about how they propose their solution is better
(4:18:46 PM) anonimal: There's links to the technical documentation, somewhere around there.
(4:19:07 PM) sgp_: I'll take a look
(4:19:09 PM) NeuroScr: sgp_: modular crypto, can be easily swapped out, everything is version’d so protocols can be easily upgraded
(4:19:48 PM) sgp_: Perhaps we should compare this approach to a rebuilt Kovri-lite solution for long-term implementations
(4:19:53 PM) NeuroScr: also there’s a fair amount going on with the path building which I’m less qualified to talk about
(4:20:27 PM) anonimal: Also consider that "different" can also mean "better". A different network with different controls allows for a diverse overall-all solution.
(4:20:54 PM) anonimal: NeuroScr: I haven't read the technicals yet. I'm sure I'll have comments.
(4:21:19 PM) NeuroScr: please do, I know the dev docs can stand to be improved and questions will help that greatly
(4:21:36 PM) sgp_: Does anyone have comments on a Monero-point-of-view discussion of the different network anonymity solutions available? Did we cover most of the bases in a reasonable way?
(4:21:38 PM) moneromooo: Why is "high capacity servers
(4:21:38 PM) anonimal: FYI Kovri-lite would mean a complete rewrite in C. Kovri was already aimed at trimming down i2pd while maintaining C++.
(4:21:41 PM) moneromooo: 	serving low capacity clients" a good hting ?
(4:22:12 PM) xiphon: sgp_: reminder: TOR
(4:22:16 PM) anonimal: I don't immediately see it as a good thing for anonymity. That's what Tor is doing now.
(4:22:33 PM) sgp_: oh yes xiphon! I promised you we would have that discussion. Let's have it now
(4:23:09 PM) sgp_: basic Tor integration is expected to be added to the next major Monero release, though it could be added later since it is not a consensus change
(4:23:44 PM) NeuroScr: moneromooo: I think the idea is mobile clients be serviced by service nodes
(4:23:55 PM) sgp_: xiphon: is there anything specific you want to discuss?
(4:24:06 PM) xiphon: The question is would we like to bunde Tor with Monero?
(4:24:16 PM) moneromooo: Maybe, but why is this a wanted feature, rather than have routers route within their means ?
(4:24:18 PM) xiphon: In case we will go TOR way
(4:24:56 PM) xiphon: Also TOR has multiple pros over i2p
(4:25:03 PM) moneromooo: Large/fewer nodes makes them targets for pwnage. Or to have attackers set them up in the first place.
(4:25:09 PM) sgp_: xiphon: routing the broadcast data on i2p makes a lot more sense to me than Tor, but having Tor now is still valuable
(4:25:20 PM) NeuroScr: moneromooo: the comment was made in the context of tor. I2P has a “russian dial up” problem I’m told
(4:25:26 PM) xiphon: 1. Bandwidth
(4:25:50 PM) moneromooo: The comment was made just before "I want this feature", which is why I am asking.
(4:26:06 PM) xiphon: According to knaccc: 's tests, i2p bandwidth is ... somewhat problematic
(4:26:07 PM) NeuroScr: moneromooo: yea we want bandwidth and latency closers to TOR over I2P
(4:26:38 PM) moneromooo: So the claim is that the latency/bandwidth problems are mostly due to this reason ?
(4:26:40 PM) sgp_: re bandwidth, it will scale better with i2p, since as more nodes come online, capacity will increase. We don't have that luxury with Tor
(4:26:43 PM) anonimal: Are you proposing to bundle the Tor binary and related files xiphon?
(4:27:02 PM) xiphon: trying to figure out is that is somewhat acceptable
(4:27:48 PM) sgp_: xiphon: i2p is fast enough for transaction broadcast, probably not full wallet sync with a remote node. So the performance limitations mostly hurt Monero for the second part
(4:28:02 PM) sgp_: But Tor isn't especially good for the second use-case either
(4:28:09 PM) xiphon: Which one?
(4:28:20 PM) sgp_: full wallet sync with remote node
(4:28:59 PM) xiphon: Could you point to soem specific issue due to which i2p overcomes TOR?
(4:29:04 PM) sgp_: and full node sync I suppose, but that's an atypical use-case
(4:29:12 PM) moneromooo: Technically, one could do some data preprocessing on the client, and send less stuff to the wallet.
(4:29:22 PM) moneromooo: s/the client/monerod/
(4:29:22 PM) monerobux: moneromooo meant to say: Technically, one could do some data preprocessing on monerod, and send less stuff to the wallet.
(4:29:41 PM) sgp_: moneromooo: that would be valuable. It's why view-key approaches make sense over i2p, since you only need to send the important data
(4:29:41 PM) moneromooo: Thank yuo
(4:29:47 PM) moneromooo: s,uo,ou,
(4:29:51 PM) moneromooo: Heh.
(4:29:52 PM) xiphon: General questions: are there any security/trust considerations Monero members care about against bundling/using TOR?
(4:30:38 PM) anonimal: xiphon: regarding the i2p/tor debate for any application; it's a long and old one. I can't begin to tell you how many times I've heard the same things over and over again.
(4:30:52 PM) sgp_: yeah, there are a million other discussions on this topic
(4:30:54 PM) moneromooo: I would not. I would however supply scripts in contrib that install tor and configure it. Plus a top level "monero-with-tor" that rnus it all.
(4:31:01 PM) anonimal: One way to look at it, it's like comparing monero to zcash and vice versa.
(4:31:06 PM) moneromooo: so you get your distro's tor etc etc.
(4:31:28 PM) anonimal: As for bundling, packing the tor binary along with monero in a package does not make any sense.
(4:31:39 PM) xiphon: moneromooo: but what will we do with WIndows users?
(4:31:55 PM) moneromooo: How many of those are thre ? Still majority ?
(4:32:00 PM) NeuroScr: i2p has no dirauth
(4:32:04 PM) anonimal: I discussed Tor libready functionality in my sekreta draft. It's yet another problem that sekreta will solve.
(4:32:07 PM) anonimal: xiphon: ^
(4:32:23 PM) xiphon: moneromooo: i believe so
(4:32:25 PM) anonimal: NeuroScr: yes. I think that's also mentioned in the kovri video and my FFS. It's certainly a big reason.
(4:32:32 PM) moneromooo: Those can be directed to the Tor download page I suppose. They'll want binaries anyway.
(4:32:46 PM) anonimal: FYI Tor on windows sucks
(4:32:52 PM) anonimal: Unless you're using Tor browser
(4:32:59 PM) anonimal: Which comes with its own instance
(4:33:07 PM) moneromooo: Why does it suck ?
(4:33:14 PM) xiphon: anonimal: i disagree
(4:33:37 PM) xiphon: works fine both on windows and linux
(4:33:39 PM) anonimal: The windows service functionality is abysmal
(4:33:48 PM) xiphon: is is awesome
(4:33:53 PM) xiphon: what problem did you meet?
(4:34:21 PM) xiphon: tor has a command line option to install the service and it works as intended, never seen any problem with it
(4:34:25 PM) anonimal: It's under maintained. That's empirical, you don't need my opinion.
(4:34:35 PM) xiphon: there is nothing to maintain
(4:34:42 PM) anonimal: It works to a degree, but keep that in mind. And good luck getting reliable windows service.
(4:34:44 PM) xiphon: windows provides backward compatibility
(4:34:49 PM) anonimal: ....
(4:35:02 PM) anonimal: Have you ported anything to multiple operating systems in C?...
(4:35:07 PM) sgp_: I'm going to "formally" call the meeting here, though you are welcome to continue talking about this in this channel if you want. Thanks everyone who made it through both meetings. We needed to have these discussions
(4:35:11 PM) xiphon: so the service code written for NT platform ten years ago will still work now
(4:35:33 PM) xiphon: anonimal: oh, we are going wrong way, let's stay on topic
(4:35:41 PM) ***anonimal done talking about it