Add go-interop tests

[dignifiedquire]

[daviddias]

Currently, it is not interoperable because it is using varint prefix instead of 4 byte prefix like in go (which uses msgio) jbenet/go-msgio#13

[daviddias]

What do you need to automate these tests? Probably just a go-libp2p script that opens a pipe over a TCP socket? @whyrusleeping refactored go-libp2p a bunch to enable that :D

[dignifiedquire]

Yep a pipe, so I can send back and forth stuff, ideally with some debug flag so it prints out all the things for debugging sessions.

[daviddias]

@whyrusleeping can you make that happen?

[JustinDrake]

Just FYI, at Duo Search we want a browser-based IPFS bridge for OpenBazaar (built on go-ipfs). We want to use js-secio client-side and interoperability with go-ipfs is necessary for us.

[daviddias]

@JustinDrake js-libp2p-secio interops with go-libp2p-secio (used in js-ipfs and go-ipfs respectively)

What about https://github.com/ipfs/js-ipfs directly?

[JustinDrake]

Thanks for clarifying the interoperability with go-libp2p-secio @diasdavid. Tests for that would be awesome.

What about https://github.com/ipfs/js-ipfs directly?

We want to build an OpenBazaar gateway in the browser for buyers. The objective is that any buyer can do business with vendors privately, without possibility for Duo Search to snoop.

OpenBazaar has quite a bit of complexity with a lot of that complexity in IPFS. Maybe we can put the whole thing in a browser. The good news is that we can have support from the Duo Search servers, and a client/server hybrid approach (similar to Blockchain.info's hybrid approach for their Bitcoin wallet) could help a lot. In particular, I think we should avoid using js-libp2p client-side and instead use go-libp2p server-side, where the Duo Search servers relay encrypted messages between buyers and sellers using Ajax over TCP.

My reasons for avoiding js-libp2p on the browser are listed below. Those may be totally false preconceptions, so please correct me where wrong.

1. js-libp2p-ipfs-browser uses WebRTC as a transport, which has only 60% browser penetration. (Pure crypto, on the other hand, can be shimmed for wide browser support.) Browsers without WebRTC would have to fallback to using IPFS gateways for p2p communication anyway.
2. In the case where the buyer's browser supports WebRTC, there can be complexities and edge cases (e.g. STUN not being able to establish a connection). These truly p2p communications (without a TCP relay) have a high complexity footprint with possible corresponding degradations in quality (reliability, latency, etc.).
3. js-libp2p is experimental compared to go-libp2p.