Steven Allen

> I'm more worried about the security properties of this. The TLS security analysis doesn't include session tickets sent from client to server (and the specification doesn't even define how...

I agree this library is annoying, but it's all we have for large integration tests with many nodes. If we just "remove" it here and tell upstream to "deal" with...

> I’d argue that it shouldn’t live within libp2p then (or at least not go-libp2p). How about moving it to a separate repo? That seems reasonable. Can we just move...

This would likely have to live as a module that plugs into go-libp2p-swarm and translates addresses. A general purpose "connection transformer" (takes a connection, returns a wrapped connection) may do...

I see... this seems like a bad fit for libp2p: 1. Our crypto transports have libp2p-specific requirements/features so we can't really offload this work without a custom proxy. 2. We...

Ok, so it looks like I misunderstood how this protocol worked. I assumed every proxied connection would get a new source port and you'd ask the proxy "what's the real...

1. Is there a single case where this is better (technically) than NATs/routing (for libp2p)? From what I can see: 1. It requires per-connection overhead. I can make a stateless...

Can't an attacker just tell us the _wrong_ addresses? This may help, a little, in some cases, but I want to make sure it's worth the extra complexity. Also note:...

> It wouldn't be cheap though and I haven't thought of the things that can go wrong here. That's my concern. --- Note: If we can ensure that AutoNAT peer...

Note: My point here is that that solution would also help protect us (somewhat) against sibyls because we'd be choosing the nodes to test instead of just using the first...