IPv6 addresses are not escaped inside net: addresses

[regular]

If I do

sbot server --host=:: --port=8100 --ws.port=8101&
sbot getAddress -- --host=::1 --port=8100

I get:

net::::8100~ ... ;ws://[::]:8101

Is that desired behaviour because the square brackets are needed because the ws address is actually a URL and the net: address is not? Or is it a bug and it should be net:[::]:8100? cc @dominictarr

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cryptix]

yup. the v6 addresses on peerInvites are not correctly recognized either.

/Users/cryptix/ssb/scuttle-shell/node_modules/ssb-server/node_modules/muxrpcli/index.js:68
      throw err
      ^
Error: could not connect to sbot
    at /Users/cryptix/ssb/scuttle-shell/node_modules/ssb-client/index.js:100:23
    at Object.client (/Users/cryptix/ssb/scuttle-shell/node_modules/multiserver/index.js:25:12)
  Error: could not connect to:net:fc2d:4733:219f:c0dc:8809:1bb9:e1ab:2f94~shs:N7jw0alZkW7Id+vLUjcf0Zs/xwff8z4BT6bCpq99EKw=, only know:net~shs;onion~shs;ws~shs;unix~noauth;net~noauth
    at Object.client (/Users/cryptix/ssb/scuttle-shell/node_modules/multiserver/index.js:25:15)
    at module.exports (/Users/cryptix/ssb/scuttle-shell/node_modules/ssb-client/index.js:99:6)
    at /Users/cryptix/ssb/scuttle-shell/node_modules/ssb-peer-invites/index.js:385:7
    at Array.forEach (<anonymous>)
    at connectFirst (/Users/cryptix/ssb/scuttle-shell/node_modules/ssb-peer-invites/index.js:381:17)
    at /Users/cryptix/ssb/scuttle-shell/node_modules/ssb-peer-invites/index.js:414:9
    at /Users/cryptix/ssb/scuttle-shell/node_modules/ssb-peer-invites/index.js:170:9
    at get (/Users/cryptix/ssb/scuttle-shell/node_modules/flumeview-reduce/inject.js:115:11)
    at /Users/cryptix/ssb/scuttle-shell/node_modules/ssb-server/node_modules/flumedb/wrap.js:52:11
    at ready (/Users/cryptix/ssb/scuttle-shell/node_modules/ssb-server/node_modules/flumedb/wrap.js:29:80)

[christianbundy]

I'd absolutely love to have this resolved. If we make breaking changes I think it might be wise to use URIs as components rather than our own schema. For example:

Before

net:192.168.0.1:8008~shs:abc;ws:192.168.0.1:8989~shs:abc

After

• Use a space to denote transforms
• Use a newline to denote multiple addresses

tcp://192.168.0.1 shs:abc
ws://192.168.0.1 shs:abc

Or, more generally:

<uri> <uri> ...
<uri> <uri> ...
...

This way we wouldn't need to write our own protocol / host / port parsers and we could just reuse all of the already existing tooling (in every language).

[dominictarr]

a transform isn't a URI. shs doesn't have a domain, port, etc. agree it makes sense for transports to be uris sometimes, but there are also transports that are not uris, such as bluetooth: https://github.com/Happy0/multiserver-bluetooth/pull/6/files#diff-04c6e90faac2675aa89e2176d2eec7d8R21

[christianbundy]

a transform isn't a URI

It could be -- shs:abc is a valid URI, the host + port thing is specific to URL (because they contain a location). And bluetooth could also be a URI if we used the MM-MM-MM-SS-SS-SS representation for MAC addresses.

I suppose my point is that there's already a standard syntax for specifying resources (with an optional location aspect), so if we make a backward-incompatible change I think it might be nice to reuse the standard.