ssbc/ssb-invite

"followbot" style invite codes for ssb

ssb-invite's Issues

possible caps are ignored

Just has a situation where two machines were running different caps.shs and caps.sign ... but I was able to use an invite code to stimulate a connection + follow.

No subsequent replication happened, but I'm not sure what would happen if it was only caps.shs?
Need some tests around this

Blocked users can redeem invites

Steps to reproduce:

1. Run ssb-server as a pub
2. Generate an invite with many uses
3. Block user Alice
4. From Alice's client, redeem the generated invite
   Expected: ssb-server sees that it has blocked Alice, and returns an error without following her.
   Actual: ssb-server allows Alice to redeem the invitation and follows her.

It looks like ssb-invite never tries to check for this case. I'm going to take a crack at fixing it myself.

Missing dependencies

cc: @dominictarr

Spent about 30 minutes trying to work on ssbc/patchbay#333 until I realized that ssb-invite changes had been pushed to master and published in a broken state.

bl package is vulnerable

npm audit reports the following vulnerability.

Moderate	Memory Exposure
Package	bl
Patched in	>=0.9.5 <1.0.0 || >=1.0.1
Dependency of	ssb-invite
Path	ssb-invite > level-sublevel > levelup > bl
More info	https://npmjs.com/advisories/596

level-sublevel is no longer maintained. It uses an old version of levelup ~0.19.0 where the latest version of levelup is 4.3.2.

It might be replaced with subleveldown, but I don't sure.

Invite can not be accepted when using a different app key

While experimenting with ssb I have been using custom app key when configuring the server, like for example:

        caps: {
            shs: 'fjZnztSijc/aoGDhCvkFoqoR7JHHOmSXJvKmOP58IrM='
        }

This works fine, and peers connect etc. But when I try to create and use an invite I get the following problems:

Hub side error:

Error: shs.server: client sent invalid challenge (phase 1), possibly they tried to speak a different protocol or had wrong application cap
    at Object.cb (/root/ssb-node/node_modules/secret-handshake/protocol.js:88:30)

Client side error:

Error: could not connect to server
    at /root/ssb-node/node_modules/ssb-invite/index.js:251:29
...
  Error: could not connect to sbot
    at /root/ssb-node/node_modules/ssb-client/index.js:100:23
...
  Error: shs.client: error when expecting server to accept challenge (phase 1).
possibly the server is busy, does not speak shs or uses a different application cap
    at abort (/root/ssb-node/node_modules/secret-handshake/protocol.js:37:45)
...
  Error: stream ended with:0 but wanted:64
    at drain (/root/ssb-node/node_modules/pull-reader/index.js:43:26)

When switching back to the default ssb app key (i.e not providing my own), invites work fine again.

I have tried to figure out where the old key gets picked up (if that is the actual problem), but so far I've been unsuccessful.

If @dominictarr could give me a pointer I would be happy to dig deeper and provide a PR for this.

Leveldown 5 upgrade causing problems on Windows

I got a whole lot of red errors trying to npm i patchbay with the latest ssb-invite on windows (v2.1.3).

Falling back to v2.0.4 where leveldown@4 is used instead saw the build working again

TypeError: Cannot read property 'remote' of null

Tests failing

TypeError: Cannot read property 'remote' of null
    at Object.<anonymous> (/home/christianbundy/src/ssbc/ssb-invite/index.js:223:56)
    at apply (/home/christianbundy/src/ssbc/ssb-invite/node_modules/muxrpc-validation/index.js:197:15)
    at Object.<anonymous> (/home/christianbundy/src/ssbc/ssb-invite/node_modules/muxrpc-validation/index.js:86:14)
    at Object.hooked [as accept] (/home/christianbundy/src/ssbc/ssb-invite/node_modules/hoox/index.js:10:15)
    at /home/christianbundy/src/ssbc/ssb-invite/test/invite.js:298:16
    at /home/christianbundy/src/ssbc/ssb-invite/index.js:139:13
    at /home/christianbundy/src/ssbc/ssb-invite/node_modules/level-sublevel/shell.js:53:51
    at /home/christianbundy/src/ssbc/ssb-invite/node_modules/level-sublevel/nut.js:109:13

Possible to see how many invites remaining?

Curious on if, after generating a 100 use invite code, it is possible to check how many uses of the invite remain available.

"Error replicating with @xxxxx" after calling invite.accept

scenario:

• alice creates and invite with invite.create, passes it to bob
• bob calls invite.accpet with that invite, then we see this erorr:

Error replicating wit

h @i91sIVrJDopSsqFUCmdDjcgZeWASXfZHE5QXN1Nn6eE=.ed25519:
   Error: no source:createHistoryStream
    at Object.localCall (/home/mix/projects/SSBC/ssb-invite/node_modules/muxrpc/local-api.js:29:13)
    at Object.<anonymous> (/home/mix/projects/SSBC/ssb-invite/node_modules/muxrpc/local-api.js:37:22)
    at PacketStreamSubstream.stream.read (/home/mix/projects/SSBC/ssb-invite/node_modules/muxrpc/stream.js:69:23)
    at PacketStream._onstream (/home/mix/projects/SSBC/ssb-invite/node_modules/packet-stream/index.js:228:11)
    at PacketStream.write (/home/mix/projects/SSBC/ssb-invite/node_modules/packet-stream/index.js:135:41)
    at /home/mix/projects/SSBC/ssb-invite/node_modules/muxrpc/pull-weird.js:56:15
    at /home/mix/projects/SSBC/ssb-invite/node_modules/pull-stream/sinks/drain.js:24:37
    at /home/mix/projects/SSBC/ssb-invite/node_modules/pull-goodbye/node_modules/pull-stream/throughs/filter.js:17:11
    at Object.cb (/home/mix/projects/SSBC/ssb-invite/node_modules/packet-stream-codec/index.js:111:11)
    at drain (/home/mix/projects/SSBC/ssb-invite/node_modules/pull-reader/index.js:39:14)

What' appears strange is that "feedId" is not for alice or bob. It is the id of a one-off keypair used in the invite, which is used to initiate a remote connection during the accept.

Basically a connection is formed where and we have RPC rights to call invite.use.
BUT ssb-replicate has a hook on ssb.on('rpc:connect') so when we connect with out invite code, it's a bit different to a "normal" connection .. but ssb-replicate doesn't know that and tries to call createHistoryStream nonetheless.

As far as I can tell, this is a safe error, and should not cause problems with the peers replicating ...