More "Breakout" refactorings of other libraries?

[eyedeekay]

A few weeks ago I got tired of scrolling around in my IDE and opening up the wrong file because there is a tunnel library for building tunnels and there's a tunnel library for tunnel crypto operations and elected to move common and crypto into their own namespaces at https://github.com/go-i2p/common and https://go-i2p/crypto and then extensively refactor them. The result was highly successful, I would venture to say that our common and crypto libraries are downright robust after this effort. At least, sigificant parts of them are. This begs the question to me, should we break out more non-router-ish functionality from the go-i2p/go-i2p namespace and put it someplace else?

Pros:

 - Smaller, more focused codebases, so you can:
  - Work on "one thing at a time"
  - Library consumers have to learn less, they can focus on one thing at a time too
  - Allow packages to become "production ready" at different rates

Cons:

 - Potentially confusing to consumers of the code
 - More release management tasks
 - More separate CI tasks
 - More issue/pull request trackers to check

Non-Issues:

 - It does not significantly complicate go-i2p to move an internal package to an external package with a different namespace
 - We don't care about following patterns established by other implemented routers unless there's a good reason we should
 - We don't care that moving big directories of actively used libraries confuses LLMs

If I were to do another library like this, it would be the lib/su3 library. su3 functionality in Go is duplicated in at least 3 locations and 2 of them aren't very good and I wrote 1 of the not very good ones and the only good one. This is confusing and unnecessary, so I'm pretty much convinced.

Interestingly, from reading emissary it is suggested that reseed operations could be done freestanding of the router, in fact they obviously can, but I wonder if that's actually better? Is it better for us? I don't know but I'm not convinced.

keys might be ill-concieved anyway but hypothetically if we want to do our own "robust secure key management system" then it may want a separate package.

OTOH, things that are obviously "router-ish" should probably stay in. netdb transports tunnel and i2np could be broken out into separate libraries but shouldn't. config should stay in too.

So, anybody care? Thoughts? Opinions?

[altonen]

I can comment on the design choice to decouple reseeding from the core implementation. emissary-core is a library that only implements the core protocol stack, i.e., NTCP2 and SSU2(ish) and everything built on top of them. Reseeding is an integral part of I2P but in my mind it's not part of the core because there are multiple ways to reseed (HTTPS, from zip file, Yggdrasil, etc.) and the application that embeds emissary-core should choose the strategy which makes the most sense for it. If there are no special requirements for reseeding, a default reseeder can pulled from emissary-util.

I'm not saying this is the right design choice for every or any I2P router but at least currently it's in line with my long-term embedding design. Might change in the future though

[eyedeekay]

The closer I get to an operational router the more I agree with the design choice, I think reseeding should be a separate package, which means I probably should make it part of reseed-tools, which already is the main reseed server. I also moved the base Noise subsystem out into it's own package which doesn't depend on the common library and am also breaking out the su3 subsystem. I guess that ultimately means that go-i2p becomes a place where we connect all the component into a cohesive application.

[urgentquest]

In general splitting stuff has more pros than cons, so yes I think this is the right move.
There might be some complications when some lib has a major version update requiring all of its users to keep up. But normally this can be worked around by deprecating stuff and giving time to migrate instead of dropping legacy parts of the code right away.

[eyedeekay]

Yeah, also, as far as library consumers of go-i2p libraries right now, those are basically just a few people participating in this very discussion. There really isn't any guarantee of stability in go-i2p/go-i2p at this point. I promise some stability in some of the higher-level libraries, and go-i2p/common and go-i2p/crypto aren't likely to change too much now, but in between the really high-level client stuff and the really-low-level common components I think we expect to be in flux. At this stage, stuff is still going to break.