Integrate with I2P-Java via libsam3

[knaccc]

I2P-Java is a relatively mature project with active developers.

A few years ago, it would have been unthinkable to have to ask people to separately install a 200 MB JVM on their machine before being able to run a Monero wallet that wanted to route connections through I2P-Java.

Things have changed since then. Java 9 implemented modularization to allow zero dependency native apps with small footprints. This brings the footprint of an app with a bundled JVM down to as low as 22 MB (11 MB with compression). The end user will have no idea they're running a JVM, and no JVM will be installed. This means no conflicts with any other JVMs they may previously have installed. Even better, we now have the open source (GPLv2) OpenJDK. See https://steveperkins.com/using-java-9-modularization-to-ship-zero-dependency-native-apps/

zab, one of the I2P developers, has noted in the Monero reddit that we could interface with I2P-Java via the SAM library https://github.com/i2p/libsam3 or via the lower level I2CP protocol https://geti2p.net/en/docs/protocol/i2cp (zab's comment here).

[fluffypony]

If we're convinced that i2p-java is going to continue then why not. We have a responsibility to maximise the protection that users have available to them.

[knaccc]

Here are some first thoughts at how this would work, as a starting point for comment by the Monero and I2P communities:

I2P provides a C library called libsam3, which makes it easy for the Monero daemon to communicate with a SAMBridge instance via tcp sockets.

SAM stands for Simple Anonymous Messaging. SAMBridge is Java code that will translate between the high level SAM protocol and the lower level I2CP "I2P Client Protocol". Therefore the Monero daemon will open tcp sockets to SAMBridge with libsam3 and communicate using the SAM protocol, and SAMBridge will open a single tcp socket to the I2P router and communicate using the I2CP protocol.

Advanced Monero daemon users should be given the option to connect via SAM to their own full I2P router installation. This will be a useful feature during development, because it means development can begin prior to the existence of an embedded I2P-Java router.

Embedded I2P-Java/SAMBridge instances

The Monero daemon will need to launch a JVM that will run the I2P Java router and a SAMBridge instance.

A tiny Java project will exist that will bundle the following I2P Java libraries: i2p.jar, router.jar, streaming.jar, mstreaming.jar and jbigi.jar.

This Java project will then have a main Java class that will do something very close to the following code, which was provided at https://geti2p.net/en/docs/applications/embedding

    Properties p = new Properties();
    p.addProperty("i2p.dir.base", baseDir);
    p.addProperty("i2p.dir.config", configDir);
    p.addProperty("i2np.inboundKBytesPerSecond", "50");
    p.addProperty("i2np.outboundKBytesPerSecond", "50");
    p.addProperty("router.sharePercentage", "80");
    p.addProperty("foo", "bar");
    Router r = new Router(p);
    r.setKillVMOnEnd(false);
    r.runRouter();

In addition, the code will instantiate and run an instance of the Java SAMBridge class. Both the I2P-Java router and the SAMBridge instance will be launched by the same Java code running inside the same JVM process.

The Java project will be built into per-OS executables using the jlink tool. This tool will, for each OS, produce a directory tree that will contain both the compiled Java code and specific JVM executables for each OS. From one build environment OS, executables can be generated for all available OSs by the jlink tool.

The jlink tool will use a module-info.java file to build these executables such that only the necessary parts of the JVM are included. This will ensure the size of the executables is kept to a minimum.

These per-OS joint Embedded I2P-Java/SAMBridge executables will be bundled with Monero builds, and used to send traffic via I2P.

End users will have no idea they are running Java code or using a JVM. The Monero daemon will handle the startup and shutdown of this Embedded I2P-Java/SAMBridge process.

[zlatinb]

Hi, zab here. You pretty much have everything figured out as far as integrating goes. The only issues I see are that using modules and jlink ties us to Java 9+, and while Java 11 is already out and is LTS, the default download for Windows on www.java.com is still 8, which means Oracle doesn't feel confident enough yet to bump it to 11.

Currently the I2P code is Java 7 compliant. The nasty bit about modules and jlink is that they are defined in .java files, which means we either force 9+ code compatibility or employ some very creative exclusion filters to make sure our code still builds on 7.

This is based on very preliminary research because I learned about jlink same time as you did :) So it's more of a strategic decision whether and how to modularise; Monero certainly doesn't need a full I2P distribution (that includes email, torrent client and a kitchen sink).

To alleviate @fluffypony 's concern Java I2P is healthier than ever and definitely going to continue. We even have a paid program to support full-time developers and are currently employing 3 core developers full-time and 2 part-time, in addition to some PR and design folk.

[anonimal]

I2P-Java is a relatively mature project with active developers.

@knaccc s/developers/developer/. And they're still technically in beta; have been for ~15 years.

If we're convinced that i2p-java is going to continue then why not

@fluffypony because your whole platform for years, even before Kovri, was to not use Java I2P. In fact, you were the first and only person to shoot down a socket based API; making everyone wait for years as a result. In fact, you were the deciding factor at that time but flaked out; leaving me to clean up your mess. And here you are now, as you conveniently appear to sway opinion on yet another decision that is beyond your technical grasping.

But, aside from that, the real reason is because there is already a better solution than hooking into java I2P directly from monero. With that said, Monero is a money project, not an anonymity project, so I don't expect most here to understand what's happening aside from the few devs who have, fortunately, reached-out and made contact. Besides, you'll certainly want "something" "now", so; have at it.

We have a responsibility to maximise the protection that users have available to them.

@fluffypony "We"? Who do you think you are? You're not an anonymity developer; you're barely technically literate. If you were truly responsible, then this wouldn't have happened. If you were truly responsible, then you would've already engaged our development in #sekreta-dev.

Besides; this entire issue has already been deprecated by Sekreta. Single-system solutions are a thing of the past. While Monero enjoys the past, other privacy coins will lead the future. I've already pointed out that danger in my post.

My only advice now is to not get too attached to this hack of a request (#5070). Also, throw salt on blockchain developers who moonlight as network anonymity developers since the technology involved is not the same.

To alleviate @fluffypony 's concern Java I2P is healthier than ever and definitely going to continue. We even have a paid program to support full-time developers and are currently employing 3 core developers full-time and 2 part-time, in addition to some PR and design folk.

@zlatinb So, there's reality, which is exposed via monotone's/git's log, and there is what you say, which is more of an illusive reality. Java I2P logs look no different than how they've looked over the years with the exception of Meeh doing some OS X work in 2018 (good to see he's back though, he MIA'd for a long time). Aside from him, there are almost no other authors besides zzz for 2018/2019 (and those other authors have very few commits); and zzz's always been the lead/full-time dev since jrandom left.

[fluffypony]

@fluffypony because your whole platform for years, even before Kovri, was to not use Java I2P.

Yes, because it would require installing Java, which adds a Java dependency to Monero. See, for instance, this post of mine from July, 2015. @knaccc is suggesting that the modularisation in Java 9 makes it self-contained, and thus doesn't install Java.

[apxs94]

Besides; this entire issue has already been deprecated by Sekreta. Single-system solutions are a thing of the past. While Monero enjoys the past, other privacy coins will lead the future. I've already pointed out that danger in my post.

It's important to remember that currently Monero runs without Kovri/i2p/Sekreta/Tor - it simply runs over clearnet - and this proposal would at least improve the status quo.

@fluffypony "We"? Who do you think you are? You're not an anonymity developer; you're barely technically literate. If you were truly responsible, then this wouldn't have happened.

@anonimal No need to resort to ad hominem attacks here. The beauty of a community effort is that we all have strengths and weaknesses.

Let your work speak for itself, and rational people will adopt it. Attacking community members will only distract people from your hard work.

[x1ddos]

Why embed anything at all at any point instead of keep communicating over an ipc such as sockets?

Maybe a better investment would be a monero binary which is ipc-agnostic to kovri, i2p-java, tor or sekreta. Then everyone can run whay they choose without dead dependencies.

Embedding seems like a too tight coupling for unclear benefits compared to ipc.

[knaccc]

@zlatinb Thanks for taking the time to comment!

using modules and jlink ties us to Java 9+

I've figured out how to automatically convert your existing JARs into modules. No code modifications will be necessary to I2P's repository.

While Java 11 is already out and is LTS, the default download for Windows on www.java.com is still 8, which means Oracle doesn't feel confident enough yet to bump it to 11.

I know a lot of people that rely heavily on Java 11 in production. so I have a good feeling about it.

Currently the I2P code is Java 7 compliant. The nasty bit about modules and jlink is that they are defined in .java files, which means we either force 9+ code compatibility or employ some very creative exclusion filters to make sure our code still builds on 7.

As above, you won't have to worry about this. Your Java 7 JARs are easily turned into modules and run perfectly on Java 11.

To alleviate @fluffypony 's concern Java I2P is healthier than ever and definitely going to continue. We even have a paid program to support full-time developers and are currently employing 3 core developers full-time and 2 part-time, in addition to some PR and design folk.

That's wonderful to hear!

[knaccc]

I've just released an embedded I2P Java router with SAM, that would be suitable for embedding into Monero.

The GitHub repo is here: https://github.com/knaccc/embedded-i2p-java-router-with-sam

It works by taking existing I2P JARs and turning them into modules. These are then used with jlink to produce an executable with a minimal JVM.

@zlatinb I'd be very interested in your thoughts, in particular on two things:

1. The way that the I2P router and the SAMBridge are launched here: https://github.com/knaccc/embedded-i2p-java-router-with-sam/blob/master/src/org/getmonero/i2p/embedded/Main.java

2. How you would recommend we go about figuring out what a minimal I2P "base dir" would be to bundle?

Thanks!

[fluffypony]

Why embed anything at all at any point instead of keep communicating over an ipc such as sockets?

Maybe a better investment would be a monero binary which is ipc-agnostic to kovri, i2p-java, tor or sekreta. Then everyone can run whay they choose without dead dependencies.

Embedding seems like a too tight coupling for unclear benefits compared to ipc.

Just to be clear, when we say embedding we actually mean bundling, but we've gotten so used to saying "embedding". Comms would absolutely go over RPC via TCP, or over IPC.

[zlatinb]

@knaccc I'm impressed, well done! Your approach to converting jars into modules will come in handy because honestly we can't wait to get rid of our dependency on Java as well. Now to your questions:

The way that the I2P router and the SAMBridge are launched here: https://github.com/knaccc/embedded-i2p-java-router-with-sam/blob/master/src/org/getmonero/i2p/embedded/Main.java

Usually the SAM bridge is launched via a "clients.config" file, but it might work the way you've done it too. What I recommend is you wait until the Router state machine reaches RUNNING state before starting the SAM bridge. Poke around the code to see exactly how to get a reference to it.

How you would recommend we go about figuring out what a minimal I2P "base dir" would be to bundle?

Trial and Error :) more specifically write a small Hello World application that uses the SAM library, enable full logging in the router and hammer it until it works. I think you don't really need to bundle anything to get it to bootstrap and join the I2P network. If you're comfortable with Python here is a nice guide - https://geti2p.net/en/blog/post/2018/10/23/application-development-basics

[knaccc]

@zlatinb Thanks, I'll make that update to the code.

Btw, I've tested the executable built with this project by setting up a Node.js client and server to talk to each other via it (using https://github.com/redhog/node-i2p). Everything seems to work great!

[knaccc]

Btw the total executable ended up as 36MB (37281943 bytes).

It was reduced to 19MB (19764972 bytes) when compressed with xz.

[jtgrassie]

@knaccc firstly, this is great.

At a high-level, are you envisioning i2p being used just for tx broadcasting (like @vtnerd's Tor PR #4988)?

[Gingeropolous]

@jtgrassie ,

At a high-level, are you envisioning i2p being used just for tx broadcasting

I think that has been the idea from the start, primarily because the latency of the i2p network and the size of the monero blocks. Though who knows - if our fluffyblocks is smart enough, block relay has effectively the same cost as tx relay. Though knaccc may have a different idea.

In general, does this bundling and modularization and lack of dependencies change the amount of resources used by java i2p? I just checked on my node server and currently java is using 50% cpu resources ... and now 64%... back to 50%... I'm just worried that bundling this with monero, and assuming its an always on situation in order to provide the most privacy, is going to create another case of people not using the monero core software because its resource intensive.

"What the heck is using 50% of my CPU? My superbloated javascript webpages don't load nearly as fast as they used to! Oh, its the monero software. DELETED."

Because of this resource use (and perhaps independent of it), users will probably start and stop The Monero Software (which now has i2p), and from what I've gathered its best to keep the router running so your tunnels get all interconnected and integrated.

Of course the flip side of this is that bundling java-i2p is better than nothing, and ultimately if the software is designed for some extreme user apathy or we wait for perfect optimizations, then we'll have a .... i dunno. Best getting in the way of good situation.

[zlatinb]

does this bundling and modularization and lack of dependencies change the amount of resources used by java i2p?

Not really, you are still running a JVM with it's bells and whistles (JIT, GC, etc.).

The main source of CPU usage are the crypto operations, which reminds me - @knaccc it is important to add jbigi.jar and the NativeBigInteger libraries to the bundle, otherwise performance will suffer.. a lot!

The number of crypto operations is proportional to the amount of I2P traffic that is routed and that can be limited through configuration, so it's a matter of choosing sane defaults.

[anonimal]

Since no one in this thread has developed I2P technology longer than I, allow me to drop some important information:

Note: for those who don't know; NTCP is the encrypted TCP transport layer for I2P. This discussion was regarding the new 2nd version. This is a mission-critical protocol, a base-layer protocol that ferries your layered messages.

#kovri-dev

2018-03-27 19:57:37     +zzz    [16:39:04] anonimal, Java I2P is going to pick up the pace on some long-dormant proposals, starting with NTCP 2 (proposal 111), would you or somebody else in kovri/monero like to
 participate?
2018-03-27 19:57:37     +i2p-relay      [16:44:41] {-oneiric_} zzz: that sounds interesting, i would like to participate
2018-03-27 19:57:37     +i2p-relay      [16:45:46] {-oneiric_} are junior-level developers welcome to join in?
2018-03-27 19:57:37     +zzz    [16:46:04] super, please review the proposal, and the long zzz.i2p thread linked on it
2018-03-27 19:57:37     +i2p-relay      [16:46:24] {-oneiric_} will do :)
2018-03-27 19:57:37     +zzz    [16:46:32] anybody is, of course
2018-03-27 19:57:37     +i2p-relay      [17:42:31] {-anonimal} zzz has anything changed since the currently published 111-ntcp-2.rst ?
2018-03-27 19:57:37     +zzz    [17:51:46] anonimal, yes, see the zzz.i2p thread for followups since then, including a possible rewrite in the Noise framework
2018-03-27 19:57:37     +zzz    [17:52:05] it's unclear if we will do that or not
2018-03-27 19:57:37     +i2p-relay      [17:55:13] {-anonimal} There's not clearnet collaboration? Is everything on zzz.i2p?
2018-03-27 19:57:37     +zzz    [17:55:49] well, there's no activity now
2018-03-27 19:57:37     +zzz    [17:56:06] we could perhaps move it to our new forum
2018-03-27 20:08:41     +i2p-relay      {-oneiric_} To any and all interested: NTCP2 design discussion in #ntcp2 on Irc2P
2018-03-27 20:10:04     &anonimal       If it's not relayed to freenode, if it's not made more public, it's not a serious discussion.
2018-03-27 20:11:14     &anonimal       zzz: monero has brilliant mathematicians but not everyone is going to fire up a router just to check a thread or use IRC.
2018-03-27 20:12:02     +zzz    anonimal, it's serious as a heart attack. If you're not happy with oneiric as your representative, let me know, otherwise we are proceeding
2018-03-27 20:12:47     +zzz    There's two proposals, one from last July (prop 111) and one from November (the Noise one in the zzz.i2p thread). We're working on a new one
2018-03-27 20:13:07     +zzz    nothing's been "fleshed out more" yet. That's what we're doing now.
2018-03-27 20:13:44     +zzz    The results will be made public in the form of updates to proposal 111, starting next week
2018-03-27 20:13:35     &anonimal       Where are the mailing list discussion? Where are the public clearnet discussions?
2018-03-27 20:13:46     +zzz    I invited your project to participate and oneiric is filling that role.
2018-03-27 20:14:21     &anonimal       There are 8+ billion humans on the planet. Must discussions be so limited to such finite channels and groups?
2018-03-27 20:14:40     +zzz    There is no mailing list. There is no clearnet discussion. If that means it is illegitimate in your eyes, I'm sorry you feel that way
2018-03-27 20:14:41     &anonimal       Has this at least made it to the modercrypto mailing list?
2018-03-27 20:15:12     &anonimal       No one said illegitimate.
2018-03-27 20:15:21     +zzz    Not familiar with that mailing list, sorry
2018-03-27 20:15:31     &anonimal       Technology can only evolve so much if it doesn't break from the shells it creates.
2018-03-27 20:16:28     oneiric right, I wasn't aware of being a representative of anything
2018-03-27 20:16:41     oneiric thought I was just participating in the discussion
2018-03-27 20:17:19     +zzz    I assumed you were representing kovri's interests. That's what I asked for, a representative.
2018-03-27 20:17:39     oneiric oh, no, I'm definitely not qualified for that role
2018-03-27 20:22:25     &anonimal       Who are the people working on this proposal, zzz?
2018-03-27 20:22:46     +zzz    me, psi, oneiric
2018-03-27 20:23:05     +zzz    see also summary at end of the NTCP2 thread on zzz.i2p
2018-03-27 20:23:07     &anonimal       What about str4d?
2018-03-27 20:23:45     +zzz    he doesn't have time. But we're using his Noise draft from November as an input
2018-03-27 20:24:36     +zzz    he may participate further, we'll see
2018-03-27 20:25:39     &anonimal       Wow, ok. The proposal needs more eyes and needs to be more public.
2018-03-27 20:25:42     &anonimal       I'll be glad to look at it.
2018-03-27 20:25:45     &anonimal       I'll be glad to contribute.
2018-03-27 20:25:51     &anonimal       I'll be glad to have more people get involved.
2018-03-27 20:26:07     &anonimal       The collaboration can improve with a more public approach though.
2018-03-27 20:26:20     &anonimal       And I only have so much time as I'm balancing a lot of different things on any given day.
2018-03-27 20:26:53     +zzz    latest 111 proposal been up there since july on our website. Noise draft been on zzz.i2p since November. Both public. New draft versions will be posted as updates to 111 on our website
2018-03-27 20:27:36     +zzz    discussions are in #ntcp2 and periodic video calls at least once a week.
2018-03-27 20:28:01     +zzz    we'd like to keep the video calls to one representative from each project
2018-03-27 20:28:13     &anonimal       But where do people submit pull requests / patches?
2018-03-27 20:28:32     +i2p-relay      {-moneromooo} What is the video supposed to show ?
2018-03-27 20:28:45     +zzz    we aren't using a pull/patch process
2018-03-27 20:28:52     &anonimal       Where?
2018-03-27 20:29:15     &anonimal       The tracker that took 2 years for my website doc error requests to be resolved? Or github?
2018-03-27 20:30:06     +zzz    the process is we're having meetings and then I'm making changes to what's on the website. That's the entire process.
2018-03-27 20:30:47     +zzz    there are no pull requests. there are no patches.
2018-03-27 20:31:58     +zzz    the meeting-and-update process we are using is working fine so far, and your maybe-representative hasn't complained about it either.

Let me repeat:

2018-03-27 20:11:14     &anonimal       zzz: monero has brilliant mathematicians but not everyone is going to fire up a router just to check a thread or use IRC.
2018-03-27 20:14:40     +zzz    There is no mailing list. There is no clearnet discussion. If that means it is illegitimate in your eyes, I'm sorry you feel that way
2018-03-27 20:30:47     +zzz    there are no pull requests. there are no patches.
2018-03-27 20:31:58     +zzz    the meeting-and-update process we are using is working fine so far, and your maybe-representative hasn't complained about it either.

Firstly, that's false: he has complained - as have many people over the years about how zzz handles (or doesn't handle) the project. From everything to the above to refusing to use git - and more. There are lots of IRC dumps to prove this. Project decisions affect code decisions: don't forget that.

Secondly, and more importantly; someone who is opposed to collaborating with the vast majority of scientists and researchers among the global human population (people that only live on clearnet) thinks that this approach is "working fine so far".

...This is Java I2P, folks. This is zzz, the lead and only developer of java I2P, and java I2P contributor for at least 13 years. Things have not changed in this area. This attitude has not changed over the years.

Don't believe me? Feel free to ask other developers such as psi about I2P development. You can find him working on LokiNet. psi had been involved with the java I2P project even longer than I (yes, I also contributed to java I2P), so I'm sure he can provide another perspective. Or even ask str4d for that matter, as he is working on Ire among other things. Sidenote: Sekreta will support LokiNet and Ire (see list of all supported networks).

But, how is this an issue now? How does this affect Monero?

Now, in January 2019, it's been almost a year later and there's still no audit of NTCP2. No official 3rd party review of anything related to NTCP2 outside of Noise (which is a completely separate component, and which received its own audit long ago). In March of 2018, java I2P's budget was around ~4 million USD in cryptocurrency and not a single penny was spent for a formal audit. Wrap that around your head. Either java I2P is still a lost cause of a project or their intentions behind such a lack of responsible development should be considered questionable at best.

This is not an isolated incident. This type of history has only been repeating throughout every aspect of java I2P development - year after year after year after year. And now, a few Monero contributors want to integrate technology that they know very little about - and that's a big problem for Monero.

So, when flakeypony pretends to not know this, despite using the exact reasons above (shall I provide logs?) as a catalyst to not use java I2P (specifically, zzz), you must question his legitimacy not only as an honest person but as any sort of anonymity consultant; as he has repeatedly proven himself to be lackluster in both of these areas.

In other words, it's time to get with the program. Archaic tools are for archaic problems. It's laughable that #5070 is even a proposal but I can smell the desperation in the air because of the 2018 bear.

Monero is better-off using a SOCKS proxy at this point, at least until Sekreta is integrated. Otherwise, deciding parties will do Monero users a massive disservice by enforcing a single implementation / single-network per-channel solution. At least with a temporary "only SOCKS proxy" solution, you'll have less blood on your hands (everyone can still use any existing I2P implementation or network of their choice so long as the implementation of choice support a SOCKS proxy).

Lastly, allowing anything Java to infiltrate the Monero implementation is literally the writing on the wall for Monero innovation. I'm so sad to see it end this way; especially since I'm one of the few who have dedicated their lives to building Monero Project since 2015.

[zlatinb]

Some fact-checking here:

no one in this thread has developed I2P technology longer than I

Pull the monotone source and search for "zab" and "zab2". If you started in 2015 I got you beat by 3 years.

Feel free to ask other developers such as psi about I2P development

Psi aka Jeff aka https://github.com/majestrate has already made his opinion known here https://i2p.rocks/blog/kovri-and-the-curious-case-of-code-rot-part-2.html and here https://i2p.rocks/blog/kovri-and-the-curious-case-of-code-rot-part-3.html but do ask him.

allowing anything Java to infiltrate the Monero implementation

If Monero hates Java that much, i2pd supports the SAM protocol as well. I don't know C++ so I can't vouch for their code, but orignal had no problem collaborating with us on NTCP2.

[knaccc]

At a high-level, are you envisioning i2p being used just for tx broadcasting (like @vtnerd's Tor PR #4988)?

I have no opinion on this. I am also not a C/C++ person, so it'd be completely up to whoever takes on the baton from here to decide how this might work. It'd be nice to be able to give people the option to hide all of their Monero related traffic.

I just checked on my node server and currently java is using 50% cpu resources ... and now 64%... back to 50%

it is important to add jbigi.jar and the NativeBigInteger libraries to the bundle, otherwise performance will suffer.. a lot!

I did not include the jbigi.jar for this first iteration, for simplicity. Some of the other CPU drain could be because the node is starting for the first time. As @zlatinb points out, calling the native crypto libraries by including jbigi.jar in the future will result in a big crypto speedup when integrated.

I've read that the RSA/ElGamal crypto is also much slower than the newer EC crypto in NTCP2. Perhaps someone can comment on this.

Lastly, allowing anything Java to infiltrate the Monero implementation is literally the writing on the wall for Monero innovation

I'm a big proponent of ending up with a well written, small footprint, security audited C/C++ I2P router with multiple collaborators from both within and outside the Monero community.

The only reason I suggested Java-I2P in the meanwhile is because that dream scenario seems to be at least 1-2 years away.

[knaccc]

it is important to add jbigi.jar and the NativeBigInteger libraries to the bundle, otherwise performance will suffer.. a lot!

@zlatinb I wasn't exactly sure what files to include to make this work, other than the jar file.

Am I correct in thinking that the I2P-Java project is currently only providing native builds of the bigint libraries for Linux, and not for Win/MacOS?

On the topic of the I2P base directory, it looks like it's possible to leave it completely empty. However, there are certificate checking errors, and so it seems like it would be best to include the certificates, hosts, blocklist and geoip content. Do you agree? How necessary do you think each of these are? I was also struggling to figure out where this content was from, since it's not in your Github repository (this data dir content is present in the Ubuntu distribution of I2P-Java).

[zlatinb]

Am I correct in thinking that the I2P-Java project is currently only providing native builds of the bigint libraries for Linux, and not for Win/MacOS?

There are libraries for Linux, Windows, MacOS and FreeBSD. The full list is here https://github.com/i2p/i2p.i2p/tree/master/installer/lib/jbigi . The libraries that start with "jbigi" are the actual implementations for platform*CPU architecture. Those that start with "jcpuid" are used to identify the CPU architecture so that the optimal implementation library can be loaded. Looking at router and wrapper logs during startup is your best bet for identifying the correct bundling.

• Certificates - you need at least the "certificates/reseed" directory in order to bootstrap into the network, but it won't hurt to include all the certificates from "installer/resources/certificates"
• blocklist - sure nice to have, it's in "installer/resources/blocklist.txt"
• geoip - this is used for identifying "bad" countries where running an I2P router can put one at risk; the router behaves differently if it detects that it's running in a "bad" country. Look at the top-level build.xml file for how geoip gets packaged.

[knaccc]

@Gingeropolous Please could you check your ~/.i2p/wrapper.log file, and see if it contains the lines:

INFO: Native CPUID library jcpuid-x86-linux loaded from file
INFO: Locally optimized native BigInteger library loaded from file

On my laptop, the I2P Java process is rarely using more than 1-2% CPU, so I'm not sure why this is happening for you. Are you running on the same machine where you installed the Ubuntu I2P package?

It looks like when you run this embedded I2P project, if you run it on the same machine where you installed the Ubuntu I2P package, then it will be using native BigInteger operations.

This is because the NativeBigInteger class that calls the native code is already contained in the i2p.jar file that this project uses, and you'll already have the libjbigi.so native library installed in your /usr/lib/jni directory.

[knaccc]

I've just released a new version that runs on Linux, and from Linux will build the Linux, MacOS and Windows zero-dependency distributions. Beware that the scripts will need to download all 3 JDKs, totalling hundreds of megabytes.

Unlike the previous version of this project, you will not need to pre-install Linux packages for Java, the Ant build tool or I2P in order to build the zero-dependency router distributions.

The native BigInteger libraries are now included in distributions for all platforms. You can check if the native libraries are being used by launching the router and checking the contents of the i2p.config/wrapper.log log file.

The final zero-dependency distribution sizes are as follows:

OS	Uncompressed size (MB)	xz Compressed size (MB)
Linux	41.6	22.5
MacOS	29.5	17.5
Windows	33.6	20.1

[Gingeropolous]

yeah, im running the ubuntu i2p package @knaccc , those were the numbers I was talking about. Does the version you are working with end up using less resources? I might try out your version... but then i gotta migrate my tunnel configurations etc...

[knaccc]

This project has been renamed I2P-zero, because it means less typing for me and less confusion when discussing it.

New github repo URL: https://github.com/knaccc/i2p-zero

[jtgrassie]

With a couple of build script tweaks I got this building and running on macos. Uses hardly any resources! Nice work @knaccc.

[zlatinb]

Few notes @knaccc :

• you should include the licenses for proper license-compliance. This is a bit tricky because we have the (bad) habit of including library source code inside the projects. For example, router.jar contains UPnP code from the cybergarage library so you need to include LICENSE-UPnP.txt
• you may want to have the option of checking out a specific tag from git for i2p
• I haven't looked at what launcher scripts get generated, is there an easy way to tune JVM params like -Xmx ?

@jtgrassie It takes quite some time for a new router to start contributing to the network, until that happens it won't be using pretty much any resources.

@Gingeropolous this distribution does not include i2ptunnel.jar, so it will not open any of your tunnels.

[x1ddos]

Just to be clear, when we say embedding we actually mean bundling, but we've gotten so used to saying "embedding". Comms would absolutely go over RPC via TCP, or over IPC.

But what if I don't want and need bundling because I'm already running my own i2p router or tor? I'd just want monero to use what I already have setup and don't bundle stuff I'll never use.

[Gingeropolous]

But what if I don't want and need bundling because I'm already running my own i2p router or tor? I'd just want monero to use what I already have setup and don't bundle stuff I'll never use.

Then there'd probably be a startup flag to tell the daemon to not run the bundled i2p , and compile flags to not bring it in... if i had to guess, and if i have an actual understanding of what bundling means.

[lessless]

Few questions here, but in the first I want to say thank you to @anonimal for being vocal with his concerns. Discussion, which raises awareness in a such sensitive field as a privacy is always appreciated, at least from the end-user perspective.

1. Do you guys think that it will be possible to put an i2p-bote in the bundle? That might be of help to the Monero MMS system which is currently using Bitmessage https://www.reddit.com/r/Monero/comments/a90b2b/multisig_and_monero_messaging_system_questions/ecv4rvk/

2. Does it make sense to consider integrating with the loki network which advertise itself as what would I2P look like if it would be made in 2018? It also supposed to have a messaging capabilities that would again help MMS (at least).

3. Are there any other good reasons except emotions/feelings to stay away from Sekreta?

Peace ✌️

[Gingeropolous]

so, I obviously don't speak for anyone but myself, but to address @lessless ,

Are there any other good reasons except emotions/feelings to stay away from Sekreta?

I think the main thing is that it does not exist yet.

And I've just heard about loki, but the same probably still applies. It looks like it exists, but how flush is the network?

My take on things,,, if we take the grand view of things perspective - I've always viewed Monero as a tool that uses the best available technology to achieve its ends. For example - ring signatures are not optimal. Surely, we could all dump resources into imagineering something that works better than ring signatures. But then we wouldn't have a functioning fungible cryptocurrency, because we're waiting for something to get developed etc. Hell, blockchains are not optimal.

Same goes for the broadcast protection layer. Sekreta sounds like it would be great. Loki too. They may be more optimal.

[knaccc]

• you should include the licenses for proper license-compliance.

I've now included the LICENSE.txt from the main I2P repository in the i2p.base dir in the distribution.

• you may want to have the option of checking out a specific tag from git for i2p

It's now checking out tags/i2p-0.9.37, and this can be modified in bin/import-packages.sh

• I haven't looked at what launcher scripts get generated, is there an easy way to tune JVM params like -Xmx ?

Yes, this and other preferences such as bandwidth usage can be tweaked in resources/launch.sh and resources/launch.bat

But what if I don't want and need bundling because I'm already running my own i2p router?

It would be easy for Monero to detect whether there is an existing I2P router running, and for Monero to use that instead of launching a new one. You would of course have the option to not use I2P at all.

Does it make sense to consider integrating with the loki network

In one of the Loki network talks, they mentioned that they would want Loki to run on top of I2P. If I understood what they were saying correctly, that means Loki does not duplicate I2P functionality. I don't know a lot about Loki (and I think it's at a very early stage).

Are there any other good reasons except emotions/feelings to stay away from Sekreta?

This project is not about staying away from Kovri or Sekreta. It's about delivering something now, instead of waiting 1-2 years to see how progress on those projects develop.

[majestrate]

I'll just chime in about really quickly

@knaccc

I'm a big proponent of ending up with a well written, small footprint, security audited C/C++ I2P router with multiple collaborators from both within and outside the Monero community.

That is what i2pd is effectively but given the past and current relations between monero and i2pd I highly doubt that collaboration will ever come to fruition. I am personally in charge of the SAM subsystem in i2pd and I have neglected that part very much so as of late because of my work with loki.

The only reason I suggested Java-I2P in the meanwhile is because that dream scenario seems to be at least 1-2 years away.

Although it would warrant an entirely separate github issue but I think it is worth mentioning that lokinet is functional and the required changes are far far less drastic vs doing i2p via sam, if there are any at all.

It may be 1-2 weeks away if you are going to use lokinet as I have already got the fork of monero lokid project uses (lokid) to sync blocks over our toy mixnet with basically no modifications made to the actual daemon, it may or may not need a bit of gluey parts but it should "just work" (at least in theory).

[lessless]

thanks for the replies guys, appreciated!

[knaccc]

@majestrate

Although it would warrant an entirely separate github issue but I think it is worth mentioning that lokinet is functional and the required changes are far far less drastic vs doing i2p via sam, if there are any at all.

It may be 1-2 weeks away if you are going to use lokinet as I have already got the fork of monero lokid project uses (lokid) to sync blocks over our toy mixnet with basically no modifications made to the actual daemon, it may or may not need a bit of gluey parts but it should "just work" (at least in theory).

@majestrate could you give us a quick overview of what Loki does please? I watched a Loki talk, where someone said that Loki may want to run on top of I2P. Can you clear up my confusion?

[lessless]

@knaccc thanks for pointing that out. Indeed LOKI seems to be a something completely standalone, based on their own protocol

https://loki-project.github.io/loki-docs/Lokinet/LLARP/

Loki proposes a new routing protocol called LLARP which is designed as a hybrid between Tor and I2P to provide additional desirable properties versus any existing routing protocol.

https://github.com/loki-project/loki-network/blob/master/docs/high-level.txt

Working on I2P has been a really big learning experience for everyone involved. After much deliberation I have decided to start making a "next generation" onion routing protocol.

[majestrate]

@knaccc what @lessless said is correct.

As it is now if you don't want to integrate java into the monero stack to get i2p support, i2pd is a good fit. I am not sure that will happen because of past tensions between the two projects. As it is now, i2pd has almost been entirely rewritten since kovri forked from it and the code quality is much better albeit still a bit lackluster. That being said it's maintained by people that seem to know how to handle themselves in C++ for the most part. The main part that is still the old jenky code style is the SAM subsystem which I have been maintaining. I have neglected that for some time and probably could be rewritten. That is my fault as I have promised for over a year to rewrite that subsystem but never got it all the way done, but I digress.

The UX of LLARP's onion router is such that you don't really need a glue layer to use it as it just provides an IP tunnel with a DNS server that triggers address mapping, but all that would probably warrant a separate issue.

[knaccc]

@majestrate

As it is now, i2pd has almost been entirely rewritten since kovri forked from it and the code quality is much better albeit still a bit lackluster. That being said it's maintained by people that seem to know how to handle themselves in C++ for the most part. The main part that is still the old jenky code style is the SAM subsystem which I have been maintaining. I have neglected that for some time and probably could be rewritten. That is my fault as I have promised for over a year to rewrite that subsystem but never got it all the way done, but I digress.

@majestrate Could you comment please on the funding situation regarding ongoing work on i2pd vs i2p-java, and therefore which of the two would be more likely to be maintained and improved?

Given that you were heavily involved in i2pd and are now working on Loki, does that mean that i2pd is not going to get as much attention in general going forward as i2p-java?

[zlatinb]

@knaccc I can shed some light on the funding situation since I'm the "compensation manager" for I2P-Java.

First, i2pd is developed independently from i2p-java. While the two teams are in close contact, they are not funded from the same pool.

I2P-java's finances are public and available for review here https://geti2p.net/en/about/hall-of-fame

Current balance: as of 2018-09-20 General fund: 50790,90 € and 466,822470802 BTC

As you can see we are heavily dependent on the price of Bitcoin; we've had paid full-time developers during 2018 and will continue during at least 1H 2019 regardless of the btc price. In the worst case scenario where bitcoin goes to zero, I2P-java will go back to operating the way it has been for 14 years prior to 2018.

[x1ddos]

i2pd vs i2p-java

it seems noone's mentioning kovri anymore. is it to be considered dead now? in the scope of monero project, that is.

[knaccc]

@zlatinb Thanks, so I2P-Java development is funded with about $1.7 million.

In contrast, i2pd have a donation address on their web site which has received an all-time total of $1600 worth of BTC at today's prices.

Do you happen to know how well funded i2pd is, and if this $1600 figure is misleading?

[zlatinb]

Do you happen to know how well funded i2pd is, and if this $1600 figure is misleading?

No idea, sorry. Other than @majestrate the following might know: "orignal", "r4sas", "l-n-s"

[paulshapiro]

i2pd vs i2p-java

it seems noone's mentioning kovri anymore. is it to be considered dead now? in the scope of monero project, that is.

Definitely not. _oneiric, sean, I, and others have been discussing a modular, minimal rewrite of Kovri. Initial design document here. More progress such as architecture diagram and planning to come. Contributors welcome in #kovri-dev. https://gist.github.com/coneiric/a26ea711ed7abc7279416a7fb38a283e#file-tini2p-design.md

[majestrate]

On Thu, Jan 17, 2019 at 07:11:46PM +0000, Zlatin Balevsky wrote:

Do you happen to know how well funded i2pd is, and if this $1600 figure is misleading?

No idea, sorry. Other than @majestrate the following might know: "orignal", "r4sas", "l-n-s"

If I recall the main contention between monero and i2pd was that there was an unofficial understanding that i2pd was going to be funded, but it ended up not being funded and was instead forked (as kovri).

All that is ancient history and best left as such.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/monero-project/monero/issues/5070#issuecomment-455294089

[jtgrassie]

@majestrate

... but given the past and current relations between monero and i2pd I highly doubt that collaboration will ever come to fruition.

Is this not a bit pessimistic? There seems to be more developers engaging now.

All that is ancient history and best left as such.

100% agree.

@paulshapiro I'd be interested to hear the pros of the tini2p approach over either using a slimmed down i2pd or using @knaccc's approach of simply packaging up the bare minimal java-i2p based stuff.

[majestrate]

irc logs from #i2pd-dev

2019-01-18 13:01:19     orignal_        but really I don't understand their point
2019-01-18 13:01:39     orignal_        either decide i2pd is shit and write new one from scratch
2019-01-18 13:02:20     orignal_        or "slimmed down i2pd" than don't call i2pd as "shit"
2019-01-18 13:05:18     orignal_        "Do you happen to know how well funded i2pd is, and if this $1600 figure is misleading?"
2019-01-18 13:05:21     orignal_        )))
2019-01-18 13:06:25     psi_    "i2pd is funded in part by users like you, and by [insert sponsored ads bytes here]"
2019-01-18 13:07:03     orignal_        my point is simplier, it's not his business
2019-01-18 13:07:23     psi_    heh
2019-01-18 13:07:36     psi_    i think they want to know if you'll stiff them like anonimal did
2019-01-18 13:08:32     orignal_        honeslt I don't care what they want to know
2019-01-18 13:08:51     orignal_        they have made a wrong decision in 2015
2019-01-18 13:08:53     psi_    i see, do you mind if that notion is relayed to them?
2019-01-18 13:09:13     orignal_        at the moment when built-in i2pd was ready and worked with ANC
2019-01-18 13:09:25     orignal_        up to you
2019-01-18 13:09:37     orignal_        and Spagni knew about it
2019-01-18 13:10:02     orignal_        I'm wondering if he has shared it with others
2019-01-18 13:10:21     psi_    okay
2019-01-18 13:10:54     orignal_        I suspect he didn't
2019-01-18 13:10:59     R4SAS   say just4lulz that i2pd already works with 2 coins inside i2p space
2019-01-18 13:11:01     R4SAS   )))
2019-01-18 13:11:22     R4SAS   in that topic
2019-01-18 13:11:31     orignal_        and there was anci2pd bundle for a long time
2019-01-18 13:12:04     orignal_        and https://bitbucket.org/orignal/anci2pd
2019-01-18 13:13:10     orignal_        R4SAS if I rememeber we have made anci2pd bundle by the end of 2017
2019-01-18 13:13:22     orignal_        anc + i2pd throughj the SAM
2019-01-18 13:13:30     R4SAS   yup
2019-01-18 13:13:40     orignal_        then SAM has been changed a lot for gostcoin
2019-01-18 13:13:42     psi_    i need to get those sam patches in
2019-01-18 13:13:46     orignal_        because it didn't work well
2019-01-18 13:13:53     R4SAS   it can be found at gh in anc releases
2019-01-18 13:14:05     orignal_        it's in the code
2019-01-18 13:14:19     orignal_        when we started gostcoin we have found some issue with SAM in i2pd

the aforementioned SAM patches for i2pd are on a branch that needs to be (non trivially) rebased atop the recent protocol improvements (namely NTCP2 and LS2).

I think that going forward you'll realistically get more done working together with us at loki using lokinet, lots of i2pd people feel really burned by the previous interactions with monero.

[coneiric]

I'd be interested to hear the pros of the tini2p approach over either using a slimmed down i2pd or using @knaccc's approach of simply packaging up the bare minimal java-i2p based stuff

Ideally, Monero should be agnostic to what anonymity router is being used. The more options the better.

The idea behind tini2p is to have a minimal, auditable router. One of the benefits is to implement as little of the home-rolled crypto present in legacy I2P protocols. The HMAC-MD5-128 stuff in SSU makes me cringe everytime I think about it. I would like to continue contributing to advancing I2P, and only implement the protocols with modern crypto.

However, what I'm working on, and hope to collaborate with others, is still a fair bit away from a complete audit, let alone functioning as a router. Monero users should have something that works now, and is flexible enough to support future innovation. Implementing SAM client code is fairly easy from a Monero standpoint, here is a C library: libsam3.

Beware that the scripts will need to download all 3 JDKs, totalling hundreds of megabytes.

Yikes! That's one big reason to opt for slimmed down i2pd or tini2p. For users that have already committed to a Java environment, Java-I2P via @knaccc's module project looks awesome.

I don't think any of the routers should be "bundled" or "embedded" into Monero other than a link on the download page, or submodule branch on the repository. Something like "here are the routers Monero is compatible with, pick one (or many)". As long as the routers support SOCKS, IPC, SAM or some other common API.

I've read that the RSA/ElGamal crypto is also much slower than the newer EC crypto in NTCP2. Perhaps someone can comment on this.

It is, much, much slower. Mostly when it comes to fresh key generation. Correct me if I'm wrong, but LS2 will partly address the need for ElGamal, like @majestrate mentioned. Here is the LS2 proposal.

ECIES using the new Noise primitives (X25519, ChaChaPoly1305) is also being proposed. It would be great to have a router option that only implemented these more secure options. At first it may come at the cost of performance if most other routers aren't updated, but it also supplies motivation to move to the new tech. Here is a link to the new crypto proposals.

[knaccc]

Beware that the scripts will need to download all 3 JDKs, totalling hundreds of megabytes.

Yikes! That's one big reason to opt for slimmed down i2pd or tini2p. For users that have already committed to a Java environment, Java-I2P via @knaccc's module project looks awesome.

Just in case it's not clear, these JDK downloads are only required on the occasions that you want to build a new I2P-zero release.

Monero devs will not be building I2P-zero releases when they are developing Monero, just like they won't be recompiling Linux when they are developing Monero. Once every few months, when there is a new I2P-Java release, someone trusted will run the I2P-zero script and build a new I2P-zero release, and everyone else will use those slimmed down 30-40MB releases for development and deployment.

I don't think any of the routers should be "bundled" or "embedded" into Monero other than a link on the download page, or submodule branch on the repository.

Why would we want to make people jump through hoops to use a network privacy layer?

[knaccc]

2019-01-18 13:08:32 orignal honeslt I don't care what they want to know 2019-01-18 13:08:51 orignal they have made a wrong decision in 2015

I don't know what happened, and I don't really want to know, but wow there is a lot of bad blood between Monero and i2pd.

Since they're separate teams, I hope this bad blood doesn't extend to the I2P-Java team.

[JustFranz]

Hello, a few questions. My knowledge of Tor and networks like it is very very basic and flawed (brace yourself). What is this privacy overlay network supposed to do for Monero?

Hide the originating node for a specific transaction?

Hide the existence of a Monero node?

What parts of the network traffic of a Monero node will go through this network, just the "mempool" additions?

What about wallets communicating with remote nodes? Do wallets communicate with a "hidden service" of sorts? Or do those transactions go over the regular internet?

If over regular internet, how are those communications encrypted? Are the different packets going between light wallets and full nodes distinguishable or uniform?

Will each full node be a "hidden service"?

If you have an IP hosting a hidden service also send corresponding traffic over the regular internet, is that good/bad/neutral for the security of this network?

Dandelion protocol, inferior or can it be used in unison with this network to improve security or will it just be not needed?