Centralisation caused by peerjs-server

[robinpaulson]

I see the project uses peerjs for peer to peer communication, it's a great tool, but i wonder about the centralisation issues peerjs-server creates. If the project is aiming for a true distributed hash table, I think peerjs-server prevents that. Is there any aim to replace it with something else at any point?

[tsujio]

I agree with your opinion that peerjs-server prevents decentralization. I want to exclude it from the system.

But one of the points which make it difficult is that in WebRTC each peer has multiple addresses/ports as ICE Candidates. Moreover, ICE Candidates can change or increase dynamically. So something which forwards ICE Candidates to other peers like peerjs-server is needed at this time.

I am finding a good solution.

[tsujio]

The description I mentioned above is not the true nature of the problem.

The most significant problem is that in WebRTC we cannot start communication until exchanging SDP messages, but we need to communicate in order to exchange SDP messages.

peerjs-server helps us to exchange SDP messages to start communication.

[robinpaulson]

As you suggest it's rather a chicken-and-egg situation, making the first connections very difficult. I've done a fair bit of research over the last few days, the problem of locating a peer seems unsolvable using only pure JS, at some point one needs probably one or more STUN servers, at least until IP6 is dominant and there are no problems with NAT traversal. The folks working on https://github.com/feross/webtorrent claim they can solve it, but i've not seen anything concrete yet.

[tsujio]

NAT traversal is also a problem.

If we could start communication only by knowing remote address like IP network, DHT over WebRTC would be a true distributed system.

[jure]

The signaling part of WebRTC can't be avoided and for practical purposes, that means a server. But I think a very good middle ground would be to use PeerJS's server for the initial node, and use the Chord network for all other connections.

1. Peer 1 connects to Peer 2 via PeerJS server (and then disconnects from PeerJS server)
2. Peer 1 uses Peer 2 and the Chord network to find other peers and connect to them as needed, without involving the signaling server again.

You still need STUN/TURN for NAT traversal, but I think those are way less costly to run compared to a signaling server which serves N * WebSocket connections. The dependency on PeerJS server also limits your scalability to a degree, at least at first, because providing that many WebSockets is not that easy/cheap.

This team is trying to do something similar: boplish/core#10

P.S.: I've ported webrtc-chord to a browserified npm package, for easier use in my projects: https://github.com/jure/webrtc-chord/commit/0990c957e62ed28023e3222d4fbfea6fd2c92059 I want to take this opportunity and thank you for your wonderful work! Thank you!

[robinpaulson]

Unfortunately, this is still not decentralised (and that after all is the aim here) - there's not a middle-ground to this, the network is either truly decentralised, that is no peer is more important than any other, or it's not. Running a STUN/TURN server is technically beyond a lot of people, requires two public IP addresses, and can't be done in the browser.

[jure]

There are public STUN/TURN servers available, a lot of people just use stun.l.google.com:19302 for STUN. For example, http://numb.viagenie.ca/ can provide TURN for free and there are many other alternatives.

To avoid the requirement for a signaling server, you can do something like http://blog.printf.net/articles/2013/05/17/webrtc-without-a-signaling-server/ where you paste the offer generated by peer 1 to the other peer, and then copy the answer back to peer 1. You personally act as the signaling server then. I know this is not what you have in mind.

Another option would be to use a different kind of server, for example send offer/answer using Gmail via https://github.com/whiteout-io/smtpclient/blob/master/src/smtpclient.js. You need TCPSocket support for that though, and it doesn't look like this will be available outside of Chrome Apps, etc.

If you want to escape NAT traversal requirement however, you need to change WebRTC itself.

I'm open to other ideas though, but I can't see anything practical while still using WebRTC.

[robinpaulson]

Hmm, all interesting, but as you and others imply, they all require some centralisation at some point in the chain - e.g. the first link requires chat/phone/email, all of which run through someone else's services. They may not be STUN, but they are only run by a minority of nodes on the internet.

You mention you can't see anything "practical" in this are, do you see anything "impractical"?

[jure]

If all of your nodes have a public ip address and are not behind a NAT and their IPs are known, perhaps there is a way to use a patched client (I'm sure mainstream WebRTC clients prevent this) to accept predefined SDP offers/answers. I'd have to look at the actual implementation of WebRTC's SDP in Chromium to see if that's feasible: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjingle/source/talk/app/webrtc/webrtcsdp.cc&q=%20sdp%20webrtc&sq=package:chromium&type=cs&l=28

[tsujio]

Hi, @jure.

Thank you for using my webrtc-chord and your BOPlish project is very interesting. I am also interested in open pub/sub platform (I am developing tsujio/webrtc-bbs, an anonymous BBS using WebRTC).

By the way, the centralization problem of WebRTC-based P2P systems is difficult to avoid. But other non-WebRTC-based P2P systems also require something which performs as a server and users discover bootstrap node from it. To realize a true distributed system, network routers may need to implement new discover protocols.

[jure]

Just to clear up any misunderstandings, BOPlish is not my project, it's being worked on by @makkes and @chris--. And I agree about centralization being practically unavoidable. I still think that using the existing WebRTC network as the signaling "server" would be a good idea, to try and partially decentralize formation of WebRTC connections. Limit the actual signaling server's task to only bootstrapping, and other SDP offer/answer exchanges happen over WebRTC.