Network config from readme does not work

[christianbundy]

"incoming": {
  "net": [
    { "scope": "public",  "external": ["cryptop.home"], "transform": "shs", "port": 8008 },
    { "scope": "private", "transform": "shs", "port": 8008, "host": "internal1.con.taine.rs" },
  ]
},

Both try to bind to the same port and it crashes ssb-server. Is this a problem with ssb-server, or should these be different ports?

[cryptix]

To restate the idea about this specific config code: It's purpose is to create invites in a NAT scenario. My assumption was, that scope:public would be used to create invites and the external: ... would replace the internal host. The host: .... on the scope:private would be the IP of the docker container or VM (or IP of a box behind a router) so that traffic from outside can be redirected to it.

I think the biggest gripe about the new connection handling is it's ambiguity and non-graceful handling. There is till host and portat the root of the object. Do these overwrite values in connections:? I don't know... Also if you want to set incoming or outgoing you have to also set the default values, otherwise you might break ssb-ws, for instance....

To reiterate what I've said on ssb before with an added bagged of history since then: I'm terribly sorry to have touched this in the first place without raising a bigger flag but it seemed functional at the time. I tried to fix (1 2) this mess after the multisever changes with scoping were merged but I still can't get the test suite of ssb-server to pass and I kinda lost the drive to work on it, to be frank. I don't get why we don't have an error callback from createSrv that tells us when listening fails. This would be blocker number one for me before I want to look into this again. Number two would be more appreciation of CI infrastructure. Ever time I get a works for me when I ask about an issue I want to hide under a stone. Apperantly OSX fails even without the new test and no one cares. There are no automated tests running on windows.

Also sorry for blowing up this issue. I wrote the examples for the readme just before they were merged even though they should have been the initial change proposal and maybe an outline for tests. To circle back with a quick fix: Make the scope:public listen on host:localhost, this way it shouldn't use 0.0.0.0 and bind twice on what ever internal1.con.taine.rs is in your case. At least that is my interpretation on why it would fail.

[christianbundy]

I think that's a good use-case, and I trust your intuition on how to solve it. I don't have any gripes with the connection handling, my only goal was to get ssb-server invites working again (https://github.com/ssbc/ssb-server/issues/583), which I think I can do with:

{
  "connections": {
    "incoming": {
      "net": [{
        "port": 8008,
        "scope": "public",
        "transform": "shs",
        "external": "example.com"
      }]
    },
    "outgoing": {
      "net": [{ "transform": "shs" }]
    }
  }
}

I think I was just running the NAT config because I didn't know how to do what I wanted a different way. Is the above JSON what I should be using?