search

hkparker / go-i2p

A pure Go implementation of the I2P router
MIT License
111 stars 18 forks source link

Reviving go-i2p #21

Open eyedeekay opened 3 years ago

eyedeekay commented 3 years ago

With this project being dormant and the I2P crypto migration all-but complete in the Java I2P and C++ i2pd implementations, I'd like to visit the idea of reviving the go-i2p project and turning it into an I2P router which is useful for client applications.

Is this something that any of the existing/former participants have any interest in being part of? If not, would I be spoiling anyone's secret plans if I were to fork the project and start working on it independently again? I do intend to start using go modules and move it to an organization's namespace(https://github.com/go-i2p/go-i2p) in order to make use of the Github organization tooling and avoid having to rename the module in the future.

hkparker commented 3 years ago

I would love to get back to working on this again at some point, unfortunately it just hasn't been something I've been able to prioritize. Of course you're more than welcome to fork and build as you see fit, I'd be eager to merge the changes back in here. I'm sure I'll be opinionated about design choices (already a number of things I'd like to redo), but hey, if I'm not putting the time in I've got no right to complain. My secret plans only require a working golang router :wink:

eyedeekay commented 3 years ago

I like opinions :) I learned functional arguments because of somebody's opinion on variadics in Go. If there are things you would change about the existing code I might be interested in what/where they are if you remember/have the time to reference them for me. All my secret plans require a Go router too.

hkparker commented 3 years ago

Well the main thing is that all the data structures are implemented as []byte right now. This is cool in that they are all passed around as the serialized version as they'd appear on the wire, which makes it possible to ensure that you're always working with a valid object. This seems unconventional to me though, they could just be implemented as proper go structs and their attributes could be accessed as actual attributes, as opposed to functions that parse the section of the byte slice that contain the attribute. Structs should also be more efficient with memory, as each allocated object doesn't need to store unused padding. I doubt this would make a huge impact on the memory footprint in the end, and there may be some I2P types that require a custom implementation, but if I was going to do it all again I'd explore just using normal structs.

eyedeekay commented 3 years ago

Well I'm glad you said that because it tells me I'm not crazy. I was just thinking about the same thing in the much simpler address structures in the key-handling parts of the sam3 library. Since I sort of have to go back over it all to align it with the checklist I'll probably take the time to struct-ify at least a few parts of go-i2p. Thanks for the input.

oicnysa commented 2 years ago

@eyedeekay is your invitatiopn still relevant. Don't have experience with i2p, but got some experience in working with gtp protocol, dpdk, xdp and etc.

eyedeekay commented 2 years ago

@oicnysa Absolutely, I moved it to it's own namespace at https://github.com/go-i2p/go-i2p after a refactor and development is just beginning to pick back up. I would be happy for any help.

oicnysa commented 2 years ago

@eyedeekay would be great if you could give me some starter task.