Maciej Krüger

What's the state of this? I got here from #2872

@song940 When will this get implemented?

https://github.com/mkg20001/fluxgui-snap But d-bus does not seem to work...

How does this look? https://github.com/mkg20001/libp2p-tls I had to add some "magic" to make the peers determine which peer is going to be the tls-server/client randomly. Currently it's using nodeJS native...

@dignifiedquire https://github.com/ipfs/specs/issues/29#issuecomment-239906315 . Here it says both will get implemented

Btw, the "magic" thing is just a 7/8 bytes protocol buffers packet with a random integer (the peer which randomly chooses the highest number is determined to be the server)

Comparison of both protocols: https://gist.github.com/mkg20001/7328e2ee1851adc2467911940983e4ec Currently the only blocking issue is [this pr](https://github.com/libp2p/js-libp2p-rendezvous/pull/1) but @VictorBjelkholm seems to be working on a [less-complicated version](https://github.com/libp2p/js-libp2p-rendezvous/compare/master...VictorBjelkholm:feat/simpler) of this module.

> If I understand correctly, by PeerPad using this protocol, we can spread the load between several rendezvous servers and this won't limit visibility of peers, as they still will...

I created a WIP PR on peer-pad-core: https://github.com/ipfs-shipyard/peer-pad-core/pull/19

@pgte The rendezvous-protocol does not handle the data transfer, that is done by circuit. For the discovery part: The discovery interval could easily be changed to 500ms (from currently 10s)...