Handshake over transport channels

Just some minutes ago got to be enough mature one of the piece of cake that I've been working on the last two weeks: clean-up of the handshake signaling code and adapted the handshake servers interface to be more like Message Channels. This way it can be used with regular channels like the ones from PeerConnection DataChannels so this way a peer can work like a regular handshake server enabling a signaling channel to connect two peers thorough it, and as a collateral damage, peers can be found over all the network mesh without requiring a handshake server on the cloud at all.

Wait, has you developed a distributed discovering routing protocol for browsers?!?!

Yes :-)

Since using a cloud service like PubNub is not the best idea regarding to the future of the network being the biggest point-of-failure of all the platform, the best idea is to move the peers routing to the webp2p network as soon as possible. To do this, when a peer get connected to one of the handshake server it keeps waiting until some more have been connected after it, giving them an offer to be connected to the network through them just like "reverse-proxies" (in the same way they were connected before), and when they get enough peers connected through them, they get disconnected. This way we can be sure that the network is sufficiently dense but also increase the mesh entropy not being all the peers connected through the same peers, making it more difficult to break down.

Also, since I have changed the signaling code to be a transport interface now the handshake servers code are as minimal as possible so it's easy to interchange with another one. Being the signaling (now routing) code a transport interface it can be used over DataChannels, so the next step was to know how to find the peers on the mesh. The easiest way it's just with a flooding protocol. It's not the most optimal regarding network resources, but since KadOH it's not currently ready (it mainly seems it's dead... :-/ ) at least it's easy to develop and a good starting point to start investigating from here, and it can find a peer over all the network if it exist (I need to think what to do if it doesn't exists... maybe using a timeout?) that's the interesting point. Now to know how a peer can get back connected I've done the easiest way to achieve it: just to append a list of all the peers where the "packet" have been routed, that can also be used to stop the propagation of the flood, so I get two birds with just one shoot :-D

Now the single-point-of-failure that's the handshake server still exists there (I hate you >:-( ), but at least  it will be pass so little time that a peer will be connected there before routing only over the webp2p network that trying to catch one of them will be almost be an homenaje to Christina Rosenvinge... :-P