search

ssbc / multiserver

A single interface that can work with multiple protocols, and multiple transforms of those protocols (eg, security layer)
MIT License
104 stars 28 forks source link

IPv6 addresses are not escaped inside net: addresses #24

Open regular opened 5 years ago

regular commented 5 years ago

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] commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

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 commented 5 years ago

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 commented 5 years ago

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.