Steven Allen

Agree with vyzo. Otherwise, lgtm.

I think the right way to think of this is as follows: go-libp2p is now a "subproject" within the libp2p org, comprised of many _separate_ packages that happen to be...

So, I think the only way to sanely do this is to write something like: https://github.com/ipfs/go-bitswap/pull/565/files. We probably don't want to block some global queue while sending events. That is:...

So, @rklaehn pointed out a simple solution for dialing: use the websocket transport. It should work just fine over *any* HTTP(s) proxy. All we need to do is expose this...

Yes, it's a full transport. I assumed it wouldn't work because we don't explicitly tell it to use the proxy from the environment. However, it looks like it does this...

So, I've tested this and dialing does actually work. You just need to correctly configure your environment to use a proxy: https://wiki.archlinux.org/index.php/Proxy_settings#Environment_variables For example, if you're using SSH, you can...

Ah. Sorry, I forgot. While we can *dial* websocket addresses, go-ipfs doesn't listen on them by default. That's probably the problem here. Note: we haven't enabled listening by default as...

Damn. It looks like the bootstrappers only listen on `wss` (websocket over https) and go can't dial that. Unfortunately, the [PR](https://github.com/libp2p/go-ws-transport/pull/15) to implement that is stale.

Also: https://github.com/libp2p/go-libp2p/issues/1554

I'm not sure if this will work: 1. Due to our backoff logic in go-libp2p-swarm, I'm kind of surprised the tests work. If we fail a dial, we should refuse...