Steven Allen

Ok, after https://github.com/libp2p/go-libp2p-testing/pull/34, everything but windows is passing, and windows is failing consistently. This _looks_ like it might be a QUIC bug.

Hm. I take that back? I'm getting: > stream_suite.go:241: timeout: no recent network activity On ubuntu as well, but not as reliably. Also, after a quite a few runs, I'm...

> Also, after a quite a few runs, I'm getting "open sockets", even though I'm cleaning them up. Clearly we're something is failing to garbage collect (could be the test?)....

"retired connections"

> We don't want to run around injecting the connection gater into all handshakes. Why not? This seems pretty reasonable to me. If double checking is expensive, something is probably...

I will let you two sort this out, I have no strong opinions either way. However, libp2p/go-libp2p-quic-transport#157 fixes the bug while libp2p/go-libp2p-quic-transport#156 is an optimization. I've merged it so we...

This probably shouldn't be done on a format-by-format basis. Instead, I'd write some form of wrapping IPLDResolver. That is: ``` let resolver = new RestrictedIPLDResolver(resolver, authService, peer) resolver.get(...) ``` The...

@xavivives It only requires *one* call to `resolver.get(...)` which will make multiple `format.resolve(...)` invocations. That is, it performs the access check for *each* node it encounters on the path. @vmx...

> Though in this case it might start as format specific, e.g. where within the node to find the authorization information, but that could later on be parameterized. Ideally, it...

Actually, looking at how IPLDResolver is implemented, you may need to implement a new IPLDResolver instead of wrapping it (unless we make it pluggable). I was relying on two facts:...