search

multiformats / rust-multiaddr

multiaddr implementation in rust
https://crates.io/crates/multiaddr
Other
86 stars 45 forks source link

Added Onion address support #35

Closed sdbondi closed 4 years ago

sdbondi commented 4 years ago

Support for parsing /onion and /onion3 addresses.

Unfortunately I had to make data-encoding a dependency because multibase added an extra (padding?) byte to the byte representation when decoding from BASE32.

This go implementation uses go std lib base32 encoding, not multibase so perhaps this is fine.

There are probably a few issues such as whether it's acceptable to have the onion encoding code in this repo. If so, suggestions welcome :)

Progress on #3

sdbondi commented 4 years ago

@dignifiedquire @Stebalien @tomaka Hey :) Any comments on this PR?

mark-stopka commented 4 years ago

So I guess this was not merged in? Is this project still alive?

Stebalien commented 4 years ago

There's nobody actively maintaining it, unfortunately. cc @vmx if you have some time to revive this.

mark-stopka commented 4 years ago

@vmx, would it be possible to add a community maintainer who would perhaps be more active on this?

vmx commented 4 years ago

@mark-stopka an actively maintained version of multiaddr is part of the libp2p project: https://github.com/libp2p/rust-libp2p/tree/68587ee180c076e6b83a4d3bb3193dcc9a656b59/misc/multiaddr that one even has onion address support already merge (https://github.com/libp2p/rust-libp2p/pull/1354).

mark-stopka commented 4 years ago

I am aware of that, but I was under the impression that it was a fork of necessity to accelerate development and the idea was to backport the features back into this upstream library...

See https://github.com/libp2p/rust-libp2p/issues/758 for reference...

I would be willing to commit the required resources by hiring a 3rd party developer to work on it, but I need to be sure, that upstream will accept the backports or transfer the maintenance...

vmx commented 4 years ago

I am aware of that, but I was under the impression that it was a fork of necessity to accelerate development and the idea was to backport the features back into this upstream library...

That's also my impression and we did that with multihash already.

I currently maintain most of the rust multiformats repos as most of them are tightly related to IPLD (which is what I actually work on). Though multiaddr is kind of separate and I currently don't have the bandwidth to maintain it properly.

I would be willing to commit the required resources by hiring a 3rd party developer to work on it, but I need to be sure, that upstream will accept the backports or transfer the maintenance...

Thanks for the offer. I think next steps would be to talk to the libp2p maintainers to see if there is interest to have an upstream version of multiaddr which isn't under their full control, but under shared control.

@tomaka How does it sound to you to move multiaddr out of libp2p again? I can help on the initial work and make sure that things are smooth, so that there is as little additional work for the libp2p team (there will of course be some work, like testing for regression, but I hope to make this as smooth as possible, as I did with rust-multihash).

As I know little about multiaddr details, it would be great if someone from the libp2p could then overlook the future developments (the way you would if someone would open an PR on the libp2p version of multiaddr today).