git ssb

1+

Dominic / ssb-config



Tree: 012c2151344e984e9a9d4459b44d3e4c818a892f

Files: 012c2151344e984e9a9d4459b44d3e4c818a892f / README.md

4556 bytesRaw

ssb-config

Configuration module used by scuttlebot.

example

var config = require('ssb-config')

//if you want to set up a test network, that
//doesn't collide with main ssb pass the name of that network in.

var test_config = require('ssb-config/inject')('testnet', {port: 9999})
//you can also pass a second argument, which overrides the default defaults.

Configuration

There are some configuration options for the sysadmins out there. All configuration is loaded via rc. You can pass any configuration value in as cli arg, env var, or in a file.

connections

Two objects to specify incoming and outgoing transports and transformations for connections.

The default is the following. It specifies the default TCP network transport for incoming and outging connections, using secret-handshake/boxstream (shs) for authentication and encryption.

"connections": {

"incoming": {
  "net": [{ "port": 8008, "scope": "private", "transform": "shs" }]
},

"outgoing": {
  "net": [{ "transform": "shs" }]
}

},

If you want to use Tor to create outgoing connections you can specify your outgoing like this. It will use localhost:9050 as the socks server for creating this.

"connections": {
    "outgoing": {
      "onion": [{ "transform": "shs" }]
    }
  },

If you want to run a peer behind NAT or other kind of proxy but still want sbot to be able to create invites for the outside addres, you can specify a public scope as your incoming.net by defining the external paramter like this:

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

One thing to notice is that you need incoming connections for Apps (like patchwork or git-ssb) to function. By default they use the same authentication mechanism (shs) to grant access to the database, choosing access levels depending on the keypair that opens the connection. If you connect to yourself, you get full access (query and publish). If a remote peer connects, it can only replicate. So be sure to have at least one incoming connection.

That beeing said, the overhead of encryption for local applications can be very high, especially on low-powered devices. For this use-case there is a noauth transform which by-passes the authentication and grants full access to anybody that can connect to it. hint: This is risky! it might expose private messages or enables people to publish as you! Therefore be sure to bind the listener to localhost or use the unix socket. The unix file socket is creted as $HOME/.ssb/socket by default and has permissions such that only the user running sbot server can open it, just like the .ssb/secret file.

"incoming": {
  "unix": [{ "scope":"local", "transform":"noauth" }],
  "net": [{ "scope": "local", "transform": "noauth", "port": 8009, "host": "localhost" }]
},

License

MIT

Built with git-ssb-web