Wonderful. I'll try this out over the weekend - I saw your conversations and was meaning to ask you what the conclusions were! Thank you.

shs and sign are the keys I'm using for a testnet. By setting sign, the network can not be linked to the mainnet. Setting sign to null means your network could 'join' or 'leak' to the mainnet, depending on how you perceive that!

I'm very new to this so apologies for the very naive questions. I'm slowly making out shapes in the fog but I'm still easily confused :)

By mainnet I presume you mean the main SSB feed that is synced with people you follow and who follow you (or to put it in ever simpler terms, the place where the posts that you make and read live). Have I understood correctly?

By testnet I presume you mean an independent feed to this that is not synced (by default) with the main feed. Is that right?

Is it possible for two testnets (both with the sign set so they cannot join the mainnet) to sync on the same LAN (and/or via a pub running a test network) with one another? In other words, is the testnet an actual network or is it just local to the machine running it?

What does it mean for a testnet to "'join' or 'leak' to the mainnet"? Do you mean an sbot server running on the testnet (with the sign set to null) might be visible to an sbot server running on the mainnet on the same LAN (or via some kind of common bridge like a pub).

Please don't hesitate to tell me to RTFM if this is clearly documented somewhere and I've missed it!

On the topic of testing, the following instructions might save someone some time if they want to set up an install in a VM. I put a clean install of Ubuntu Mate 16.04.3 (64 bit) on VirtualBox and used the following to get the easy install of patchbay (which runs an embedded sbot with all the right plugins already installed) running.

Note 1: I haven't installed the dev set up yet but the dependencies should be more or less the same
Note 2: @mix recommended using nvm to install node instead of curl + apt-get - https://github.com/creationix/nvm

With those caveats in mind, these are the basic steps that worked for me:

sudo apt-get install git m4 libtool eclipse-cdt-autotools curl 
curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -
sudo apt-get install nodejs 
sudo apt-get install -y build essential
git clone https://github.com/ssbc/patchbay.git
cd patchbay
npm install
npm run rebuild 
npm start

Thanks. This is super useful for testing

The server doesn't seem to start:-

07:29:49 (master) ~/js/ssb-minimal$ echo $ssb_appname; sbot server
ssb_test
flumelog-offset: blockSize and codec params moved into an object. https://github.com/flumedb/flumelog-offset
Log level: notice
************************************************** (indexes:100%)^C

And on another terminal:-

07:29:01 (master) ~/js/ssb-minimal$ echo $ssb_appname; npm start
ssb_test

> ssb-minimal@0.0.1 start /Users/kamal/js/ssb-minimal
> node index.js

err Error: could not connect to sbot
    at /Users/kamal/js/ssb-minimal/node_modules/ssb-client/index.js:96:23
    at /Users/kamal/js/ssb-minimal/node_modules/multiserver/compose.js:65:24
    at Socket.<anonymous> (/Users/kamal/js/ssb-minimal/node_modules/multiserver/plugins/net.js:38:11)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)
    at emitErrorNT (net.js:1281:8)
    at _combinedTickCallback (internal/process/next_tick.js:80:11)
    at process._tickCallback (internal/process/next_tick.js:104:9)
  Error: connect ECONNREFUSED 127.0.0.1:8007
    at Object.exports._errnoException (util.js:1020:11)
    at exports._exceptionWithHostPort (util.js:1043:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1090:14)

Any idea where I got it wrong ? The sbot I got from npm install -g scuttlebot.

Thanks @jolyon That really helps clarify it.

@mix said something interesting in this context about running a server with a different key which I'm guessing uses the same mechanism that you are describing.

It's possible to make your own private network using your own pubs (or running peers just locally) and running with a key which means they won't share info with anyone else not using that key. This is like running a parallel universe.

If one of the domain experts could clarify how "sign" works and that nature of leaking/joining two networks that would be really helpful :)

@jolyon Your description of how ssb altnets work seems on spec to me.

I had a look at ssb-minimal and I dig your idea to pass the network configuration in the main application.

@Josiah @jolyon I run into the same issue. Look like a bootstrapping problem. To install the plugins, you need to run sbot server, but if the plugins not there yet, sbot server will crash. I have to start with commenting the plugins first, start sbot server, install the plugins, and then copy paste back the original config.

Your ssb_appname is ssb_test whereas I was using ssb-test. Not sure if that is the problem?

You're right.

To install the plugins, you need to run sbot server, but if the plugins not there yet, sbot server will crash.

@k4ml

From memory, I think you can work around the problem of the server crashing if plugins are not there yet by doing this.

First manually install the plugins with sbot stopped:

cd ~/.ssb      
npm i ssb-about 
npm i ssb-backlinks
npm i ssb-fulltext  

Then with sbot running, enable them instead of installing them:

sbot plugins.enable ssb-about
sbot plugins.enable ssb-backlinks
sbot plugins.enable ssb-fulltext

Then restart sbot.

@jolyon @dangerousbeans Nice!

I was going to say 'make sure you change the caps and the sign in the client too!' But I think you guys got it already.

I wish there was a way to automatically discover and load the websocket remote into the client from the server.

I wish there was a way to automatically discover and load the websocket remote into the client from the server.

We could serve a http route containing this information (that was only allowed on localhost)... that would be acceptable for client UIs running locally.