invite.create TypeError: cannot read property 'split' of null

[christianbundy]

$ sbot invite.create 1                                                                                                                                                                                    

/home/christianbundy/.node_modules/lib/node_modules/scuttlebot/node_modules/muxrpcli/index.js:68
      throw err
      ^
TypeError: Cannot read property 'split' of null
    at Object.<anonymous> (/home/christianbundy/.node_modules/lib/node_modules/scuttlebot/plugins/invite.js:84:38)
    at apply (/home/christianbundy/.node_modules/lib/node_modules/scuttlebot/node_modules/muxrpc-validation/index.js:173:15)
    at Object.<anonymous> (/home/christianbundy/.node_modules/lib/node_modules/scuttlebot/node_modules/muxrpc-validation/index.js:82:14)
    at Object.hooked (/home/christianbundy/.node_modules/lib/node_modules/scuttlebot/node_modules/hoox/index.js:10:15)
    at Object.localCall (/home/christianbundy/.node_modules/lib/node_modules/scuttlebot/node_modules/muxrpc/local-api.js:31:29)
    at Object.<anonymous> (/home/christianbundy/.node_modules/lib/node_modules/scuttlebot/node_modules/muxrpc/local-api.js:37:22)
    at Object.request (/home/christianbundy/.node_modules/lib/node_modules/scuttlebot/node_modules/muxrpc/stream.js:46:17)
    at PacketStream._onrequest (/home/christianbundy/.node_modules/lib/node_modules/scuttlebot/node_modules/packet-stream/index.js:161:17)
    at PacketStream.write (/home/christianbundy/.node_modules/lib/node_modules/scuttlebot/node_modules/packet-stream/index.js:134:41)
    at /home/christianbundy/.node_modules/lib/node_modules/scuttlebot/node_modules/muxrpc/pull-weird.js:56:15

All vanilla everything, no ~/.ssb/config. My guess is that this code expects some interface(s) in the config file but that it doesn't exist so it throws an error (?).

[mk270]

I have tried a few times to get scuttebot installed (source, npm install -g scuttlebot-release, docker, etc), and am coming up agains this too, both with scuttlebot-release and from source. I have never managed to get it up and running.

Is there any documentation (or could anyone tell me) what the config is supposed to look like, where it is, how it is supposed to be set up, etc?

[christianbundy]

@mk270

I know that ~/.ssb/config should be a JSON file, and I think that it should look something like the ssb-config readme. For example, yours could look like this:

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

The important bit for invites is that you have connections.incoming.net[].external, which defines the hostname to use (and fixes this error). Still, I think this should have a human-friendly error message rather than what we currently have.

Please let me know if there's anything else I can do to help you!

[mk270]

@christianbundy thanks - I don't have a ~/.ssb/config file, though there is a ~/.ssb directory, created by bin.js on first exection.

I'll have a look at this - but is there any documentation on what is supposed to put a file of the right format in that location?

[christianbundy]

Unfortunately I think you'll have to just create it by hand, I'm not aware of any ssb-config-wizard or anything like that that automates the configuration. I'd start by copying and pasting my example above, just switch out "example.com" for your preferred hostname.

[mk270]

@christianbundy thanks very much - I can now create invites, and certain other operations seem to be returning more realistic results (e.g., getAddress)

out of spite, I am going to go and hunt down the repos with the docs for the various installation/tutorial material I've been following, and submit pull requests to include the vital information about ~/.ssb/config

[christianbundy]

Thank you! Your time spent on that would be super valuable, I'd love to see some more documentation around these parts.

[mk270]

@christianbundy weirdly, the docs linked from https://ssbc.github.io/ have just disappeared in the last hour or two

[mmckegg]

I think that is a side affect of renaming scuttlebot to ssb-server.

The docs are now here: https://ssbc.github.io/ssb-server

Might need to update the link.

[christianbundy]

@mmckegg Do you know which docs site is kept up-to-date? My go-to has been http://scuttlebot.io/, but I know there are a handful of others as well with questionable up-to-date-ness.

[mmckegg]

As far as I know, the only site actively updated these days is scuttlebutt.nz. @ahdinosaur would know better than me.

[jfr3000]

~@mk270 it'd be great if you could document this. I was having the same issue and wasn't aware you could set an external address. The connections property in the config really needs explaining/docs - which properties can it have, what do they do and which ones should you set under which circumstances.~ my bad, I had somehow missed this https://github.com/ssbc/ssb-config#connections

[mk270]

yes, but https://github.com/ssbc/ssb-config#connections is out-of-date / incomplete.

there's a chicken-and-egg problem here: you can't get the thing up and running with docs, and you can't fix the docs without a running system

[dropmeaword]

Hi everyone,

I'm trying to setup a container to run ssb-server on a raspberry pi. I am hitting the exact same problem described in this issue. To install I ran npm install -g ssb-server and it seemed to install successfully.

bash-4.4# ssb-server invite.create 2

/usr/local/lib/node_modules/ssb-server/node_modules/muxrpcli/index.js:68
      throw err
      ^
TypeError: Cannot read property 'split' of null

I tried copying the contents of the post by @christianbundy into ~/.ssb/config but I am still getting the same error.

update: it seems to work fine after a ssb-server restart.

[dominictarr]

in ssb-server@13.5.2 the error message says you need to configure the server instead of just doing a null did not have split.

[mk270]

@dominictarr thanks - that will be very helpful to those not in the know

[christianbundy]

@dominictarr

Thanks for the fix! I've updated but it looks like it's just timing out now -- this is all vanilla, no ~/.ssb/config file at all:

$ ssb-server start
ssb-server 13.5.2 /home/christianbundy/.ssb logging.level:notice
my key ID: +oaWWDs8g73EZFUMfW37R/ULtFEjwKN/DczvdYihjbU=.ed25519
WARNING-DEPRECATION: ssb-links not installed as a plugin. If you are using git-ssb, ssb-npm or patchfoo please consider installing it
Listening on undefined:8008 (multiserver net plugin)
Listening on :8989 (multiserver ws plugin)
ssb-friends: stream legacy api used
******************................................ (ebt:34.8%)

$ ssb-server invite.create 1
Error: Could not connect to ssb-server localhost:8008
Use the "start" command to start it.

[dominictarr]

@christianbundy it seems to work for me, on latest.

Sometimes I get that behaviour (on my pub) if lots of peers are trying to connect (and do legacy replication). Does it also timeout on a simpler command (use sbot getAddress or sbot whoami to test)? try restarting the server then trying several times immediately.

I have legacy replication disabled on my pub:

  "gossip": {
    "global": false
  },
  "replicate": {
    "legacy": false
  }

patchwork has ebt now, so time pretty safe to disable legacy replication I think!

[pbuyle]

yes, but https://github.com/ssbc/ssb-config#connections is out-of-date / incomplete.

there's a chicken-and-egg problem here: you can't get the thing up and running with docs, and you can't fix the docs without a running system

If https://github.com/ssbc/ssb-config#connections (and the rest of the README.md there?) is incomplete, is there some more complete documentation somewhere. Or should one dig into the source code to find/understand what missing from there. What is needed to complete/update the documentation and where should it happen (I'm guessing a PR) ?

[cryptix]

patchwork has ebt now, so time pretty safe to disable legacy replication I think!

Personally I'd like to -1 on that. Feels to early. Our Go port only barely scratched supporting it and is still really far away from EBT. I'm not sure how far sunrise is in that regard. I also had problems in the past which I'm not even sure how to formulate an issue about because I don't understand what is going on AND it's terribly hard to (re)produce but it's a bit beside the point. What I'm really trying to say: deprecating a protocol that we just barely got documented feels really insane to me, looking at the state of the projects and the kind of problems we had in the past. As a cross-implementer this feels like a slap in the face, to be frank. (Edit: I feel sorry about lashing out like that. That was a bit too much and from the heat of the moment the gist of it stands. I think changes like that shouldn't come over night and should be discussed more.)

try restarting the server then trying several times immediately.

is this really the only thing nodejs can do to deal with these transient errors? They happen from time to time, sure but Is there no way to un-stress the event loop? I've also seen this multiple time in patchwork where it wouldn't load and be stuck in scuttling because sbot is to busy replicating.... It feels like terrible advice to just retry. How do you know when to stop without getting into client development and knowing all these terrible half-truths and maybes. Put differently: If the probability of this happening is 50% then the chance of stopping normal operations is 100%. This is just a workaround not a solution to the underlying problem.

[dominictarr]

@cryptix oh good point. we should continue responding to legacy replication, but try ebt first. The reason node.js behaves like that is because it's single threaded. I think what is happening, is that once the server is up, if it connects to a peer and starts doing legacy replication, that involves sending thousands of requests, which queues up a lot of CPU usage. It doesn't get around to handling the incoming client request, and the sbot client connection times out. hmm, it just says "failed to connect" but doesn't give the error message. My bet it that it's just a time out, though. If you restart and do the command quickly, you can get in before the replication starts, but after the server is actually listening (which might take a little while, so it's a race)

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?