Embedding Strategies for the Meantime

[eyedeekay]

For discussing embedding strategies

[eyedeekay]

The purpose of this thread is to go over embedding strategies now and for the future. Obviously when go-i2p is ready, go-i2p will be the embedding strategy. But for now, it might be useful to do something else in the meantime to deal with I2P when it is a dependency of a third-party app.

Our options are:

1. We distribute I2P or i2pd with the installer itself, as an installer. Tell third-party app installer to check for I2P, and if it isn't present, install it. I2P-Zero used to have something like this.

• https://github.com/i2p-zero/i2p-zero/blob/master/bin/i2p-zero.nsi (Yes, apparently I was using NSIS to invoke compilation of I2P-Zero. What was I thinking?)
• https://github.com/i2p-zero/i2p-zero/blob/master/bin/nsis-example.nsi

3. We link i2pd using the existing SWIG binding
4. We copy the embedded router parts of emissary-cli into a new library, emissary-c, export C functions, wrap them in Go, and bind to that instead(still better than C++). This is actually not half as difficult as it sounds and I was thinking about doing it anyway.
5. Others?

Our constraints are:

1. Mostly SAMv3 Related. Currently only Java I2P supports SAMv3.3, but it is also the hardest to embed in non-Java applications. This is what I2P-Zero was supposed to be an answer for. I can probably take a whack at a replacement in easy-install for the 2.11.0 cycle.
2. Some users will want to cross-compile and multi-language codebases with cross-compilation are a big pain.
3. Others?

That's my brain dump on the topic today.

[eyedeekay]

I think the thing that has the most long-term appeal is going to be creating a C binding to the emissary Rust router. My experience of binding C++ to Go has been that it's a huge hassle. There are languages where talking to C++ is a better idea, like Python. Go is not one of those language. Rust on the other hand has similarities with Go that make this process much more intuitive to build, cross-compile etc. Just avoiding name-mangling makes things way easier.

The other part that appeals is the ability to produce a C library from the Rust library more generally. In the end, we'll export a C library from the Go library as well, but I think this is a team effort and I want people to have choices, a choice between an embedded Rust router and an embedded Go router is a healthy choice to offer the I2P community.

So yeah, what I would do is try to derive a "lifecycle" from the emissary-cli app. Figure out where and how the router is instantiated, configured, started, shutdown, and de-instantiated. Then create a new library, emisssary-c encapsulating that logic. Then I would refactor emissary-cli to use the emissary-c router lifecycle and test for regressions. Then I would set up [export] comments on the emissary-c components and update the build process to generate the object file and the C header.

[fxrstor]

I think this is a team effort and I want people to have choices, a choice between an embedded Rust router and an embedded Go router is a healthy choice to offer the I2P community.

@eyedeekay What do you mean by this?
Also as for creating emissary-c, how long will this take? When are you going to start?

[eyedeekay]

Re: team effort, I''m speaking on goals. I have 2 big goals here, the success of the Invisible Internet, and the success of go-i2p. Multiple implementations of the I2P protocols support the success of the Invisible Internet. Modern, embedded, memory-safe I2P routers are a benefit to I2P applications. It is a goal of both go-i2p and emissary to fit the embedded use case. I think we both should.

Re: emissary-c, not this week. Maybe the week after. It's not a big job, but I don't think in Rust yet so it might take some time and I have other priorities.

[fxrstor]

I see that you wrote some code at this repo. I suggest adding a todo list for emissary-c, for now it's basic and usable enough. Will test it myself when I have time

[eyedeekay]

There's actually quite a lot there to help you get started, in particular the emissary-c/README.md file and the emissary-c/examples/simple_usage.c should be adequate to get things going in C. For Go I have somewhat bigger plans, I'm going to take the whole emissary-c generate/compile process and express it in go:generate so you can just go get the library, which will be called go-emissary. This will be at least another 2 weeks.

[eyedeekay]

Notes: This is only really sensible for Windows installers and Linux packages intended to be run portably, which are not written in Java, C++, or Rust. For .deb or .rpm packages the obvious thing to do is specify an I2P router as a dependency. The only thing on that list above that is generally more useful than it is hard work is the Rust binding IMO.