Implement `FromStr` for `NetAddress`

[tnull]

It would be nice to allow for the parsing of NetAddresses from String, as it's likely needed by users of NetAddress, and currently they'd have to create a newtype to do it.

It's really straightforward as we can lean on to_socket_addrs and, in case this fails, on Hostname::try_from.

[tnull]

May also be nice to impl TryFrom/TryInto for SocketAddr.

[jbesraa]

hey
I can try to implement this

[jbesraa]

@tnull how would you identify the input string(to which enum property it should be assigned)?

we can do something like this where key is one of the enum props

fn from_str(s: &str) -> Result<Self, Self::Err> {
  let key = s.split(":")[0]
  let value = s.split(":")[1]
}

we can then use match statement

match key {
 "ipv4": ...,
 "ipv6": ...,
 "hostname": ...,
}

[ayeankit]

hey @tnull , I would like to do it. Please assign me this issue.

[tnull]

hey @tnull , I would like to do it. Please assign me this issue.

Sorry to say, but @jbesraa just picked it up a few days ago. Feel free to pick another issue. :)

[tnull]

@tnull how would you identify the input string(to which enum property it should be assigned)?

we can do something like this where key is one of the enum props

fn from_str(s: &str) -> Result<Self, Self::Err> {
  let key = s.split(":")[0]
  let value = s.split(":")[1]
}

we can then use match statement

match key {
 "ipv4": ...,
 "ipv6": ...,
 "hostname": ...,
}

I think we should first try to parse the IPv4/IPv6 cases and then fall back on Hostname and fail otherwise. I think the onion variants are not really parseable from string unfortunately.

[TheBlueMatt]

It's really straightforward as we can lean on to_socket_addrs and, in case this fails, on Hostname::try_from.

I'm not sure its that straightforward? If you have a hostname, we probably just want to include the singular hostname variant, but that may be a bit surprising to users (which is a more general criticism of FromStr and From - they give you no context about how the conversion is happening, so really only belong for things that are trivially mapped).

[TheBlueMatt]

Can you elaborate on what the specific use-cases is here - are we trying to convert some user-provided configfile-read value to a NetAddress?

[tnull]

Can you elaborate on what the specific use-cases is here - are we trying to convert some user-provided configfile-read value to a NetAddress?

Basically, yes. I want to enable name resolution support in LDK Node and would love to reuse NetAddress for that, since we already have it exposed. Sure I could do a newtype and implement the same parsing logic downstream, but I assume other users of NetAddress might find parsing from String useful.

[tnull]

@jbesraa Still interested in picking this up?

[jbesraa]

yes. I was just waiting for the discussion to come into a conclusion.. can u please review the comment above with the code snippet to validate my thoughts..?

[tnull]

yes. I was just waiting for the discussion to come into a conclusion.. can u please review the comment above with the code snippet to validate my thoughts..?

Great! Yes, as said above the approach basically seems valid. You probably first want to try parse the string into a SocketAddr (see ToSocketAddrs), and if this fails (i.e., returns an Err) try to split it on : and parse the first part it into a Hostname. If this is successful we should finally check if the hostname contains a .onion suffix and in this case reconsider it to be an OnionV3 variant and parse the bytes accordingly, which is probably the trickiest part due to the base32 encoding etc.

[TheBlueMatt]

I don't think we want to try to parse into a socket address at all - if we get a hostname, generally we want to store/announce/etc that hostname and only do the resolution when we actually go to connect. Thus, maybe instead we consider implementing ToSocketAddrs on NetAddress in addition to FromStr?