libp2p-websocket-star - Githubissues

mkg20001 commented 7 years ago

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 commented 7 years ago

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

mkg20001 commented 7 years ago

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 commented 7 years ago

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

daviddias commented 7 years ago

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 commented 7 years ago

What does it do?

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

mkg20001 commented 7 years ago

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 commented 7 years ago

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

ghost commented 7 years ago

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 commented 7 years ago

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

mkg20001 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

daviddias commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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

daviddias commented 7 years ago

Done! Thank you @mkg20001 :):)

daviddias commented 7 years ago

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

libp2p / js-libp2p

libp2p-websocket-star #117