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?

[ghost]

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.

[ghost]

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

[daviddias]

Hey @mkg20001, would you move libp2p-websockets-star to the libp2p org? This will be a very useful transport for a lot of use cases and by making it part of the org just makes discoverability simpler and easier to maintain.

I'll be updating today how multiaddrs work for libp2p-webrtc star as decided in https://github.com/ipfs/pm/pull/492/files

[mkg20001]

@diasdavid Of course I can do that as long as I keep permissions for the repository.
I'm currently visiting some family members so I won't be very active for 4 days if you might got questions.

[daviddias]

absolutely, I'll add you to the team that manages the repo :)

Wanna migrate it to me so that then I can move to the libp2p org (Github doesn't allow users out of the org to move repos in), I'm looking to work on it this weekend.

Enjoy the time with the family! :)

[mkg20001]

@diasdavid I've moved the repo to your account. Can you move it to libp2p and add me as a repo admin?

[daviddias]

Done! Thank you @mkg20001 :):)

[daviddias]

Let's continue the discussion on the module itself :)