libp2p-websocket-star

[mkg20001]

I have created a module called libp2p-websocket-star that works similar to libp2p-webrtc-star just without webrtc.

What do you guys think?

[daviddias]

Interesting! Have you tried deploying it to an app and see how it works?

[mkg20001]

I've now added it to mkg-tool and created a public signaling server at /libp2p-webrtc-star/ip4/148.251.206.162/tcp/9090/ws/. It works great

[daviddias]

That's pretty cool, you probably want to add a specific multiaddr for it to not be confused with the webrtc-star transport :)

[daviddias]

This is going to enable a lot of people that want to use js-ipfs P2P like but are having troubles with WebRTC.

@lgierth can we get one of the servers running hosted by us?

What does it do?

Can we just make it part of the regular websockets transport?

[mkg20001]

It's a rewritten version of the libp2p-webrtc-star transport that creates the streams over the signaling server (socket.io) directly instead of over webrtc.
I doubt it's a good idea to merge the websocket transport with that.

[daviddias]

I agree with @mkg20001. It has a different mechanism.

I'm all for it -- but let's make sure this multiaddr scheme is correct, @diasdavid you mentioned in the past the webrtc-star scheme needs an overhaul because it doesn't correctly represent encapsulation.

[daviddias]

Yeah, here libp2p/js-libp2p-webrtc-star#110. Let's figure out this tomorrow over coffee ☕️ as proposed :)

[mkg20001]

I've written a small solution (currently not on github) (in the rewrite branch) to how to make the listening process more secure:
Before listening a ~4kb pseudo random string is generated and a hash is created using b58encode(sha5(sha5(key))) that is then added to the address as another ipfs id with .encapsulate("ipfs/"+hash). (This should later be changed to use it's own multiaddr like /instance/<hash> or /id/<hash>)

For the client to listen on the multiaddr it has to provide the key (the random string). This way there can be multiple instances of the same peer-id online without having conflicts.

The problem is when somebody tries to dial /libp2p-websocket-star/dns4/localhost/ws/ipfs/<some-id> it would return an error. Should it stay that way? Should it allow dialing without an instance-id if there is only one peer online with that address? Any other thoughts on that?

[daviddias]

I've written a small solution (currently not on github) to how to make the listening process more secure:
Before listening a ~4kb pseudo random string is generated and a hash is created using b58encode(sha5(sha5(key))) that is then added to the address as another ipfs id with .encapsulate("ipfs/"+hash). (This should later be changed to use it's own multiaddr like /instance/ or /id/)

Worry not, secio handles authenticating the peer before hand.

For the client to listen on the multiaddr it has to provide the key (the random string). This way there can be multiple instances of the same peer-id online without having conflicts.

This is not an expected behavior. Only one PeerId per process, otherwise the feature of "process addressing" would be broken.

The problem is when somebody tries to dial /libp2p-websocket-star/dns4/localhost/ws/ipfs/ it would return an error. Should it stay that way? Should it allow dialing without an instance-id if there is only one peer online with that address? Any other thoughts on that?

Given the following scenario:

• PeerA with IdA
• PeerB with IdB
• Rendezvous point with DNS RendezvousLocation

The following dials should be valid and successful

• PeerA.dial(/libp2p-websocket-star/dns4/RendezvousLocation/ws/ipfs/IdB)
• PeerB.dial(/libp2p-websocket-star/dns4/RendezvousLocation/ws/ipfs/IdA)

The corollary being that the following dial is unsuccessful

• PeerA.dial(/libp2p-websocket-star/dns4/RendezvousLocation/ws/ipfs/IdA) as it would try to dial to itself.

[mkg20001]

This is not an expected behavior. Only one PeerId per process, otherwise the feature of "process addressing" would be broken.

So simply deny listening on the same multiaddr if something is already listening on it?

Edit:

Worry not, secio handles authenticating the peer before hand.

Someone could still listen on an address with an id that does not belong to him and (depending on whether we allow or disallow another peer to overtake that multiaddr while it's in use) the real peer couldn't listen on that addr or someone could overwrite/claim his listening address.

[daviddias]

The rendezvous point should not deny. It should just update the table. Nodes might roam from place to place. The verification is end to end

[mkg20001]

The rendezvous point should not deny. It should just update the table. Nodes might roam from place to place. The verification is end to end

My main issue is that with this simple patch (on libp2p-websocket-star, current master):

diff --git a/src/index.js b/src/index.js
index dec40af..5576250 100644
--- a/src/index.js
+++ b/src/index.js
@@ -177,6 +177,7 @@ class WebsocketStar {
   }
 
   _peerDiscovered(maStr) {
+    this.firstListen.emit("ss-join", maStr)
     log('Peer Discovered:', maStr)
     const split = maStr.split('/ipfs/')
     const peerIdStr = split[split.length - 1]

every dial to every peer on the signaling server is redirected to the current node

[mkg20001]

libp2p-webrtc-star hack: libp2p/js-libp2p-webrtc-star#116