Is it acceptable to have an non autonomous transport?

Hi, I use i2p all day but I can’t do it easly for ipfs,
so I want to make an i2p transport (I known someone is all ready working on but he doesn’t push his branch so I can’t help on that).
But for simplicity and security reason this is way better to use i2prouter than reimplementing.
Is it acceptable to ask user to run a i2prouter and create an account for my transport (to do autoconfig via API) or if user don’t want run or configure i2prouter can i run it via a sub-process of my transport ?
Or my transport should implement at least partialy i2p ?

Hi @Jorropo, thanks for posting.

If I understand you correctly, you want to build an i2p transport for libp2p, so that you can run IPFS over i2p. And the simplest way to implement it would be to run i2prouter as a separate process, either one that you spawn, or an existing one that you configure.

I think your idea of an out-of-process helper for a transport is potentially viable, but you’ll want to think through how you want to distribute this before you go too far. Native dependencies are difficult to package up for many language package managers, so this seems like it would add some friction to the setup. If that’s fine for your project, I think it may be doable. In my experience managing subprocess can also be a pain, especially if you want to support multiple platforms.

Anyway, this sounds interesting, and I hope you can make some progress. Have you thought about addressing? Supporting i2p addresses might require extending the multiaddr table and adding the new code to the various multiaddr implementations.