Steven Allen

> For QUIC addresses, the only (non-hacky) way to check for connectivity is by completing the handshake anyway. Really? Isn't it possible to connect to a QUIC endpoint, receive their...

Note: your proposal sounds reasonable, and I guess my previous comment might fall under "hacky". > Possible attack: There's no way to actually prove that the receiver actually dialed the...

Yes, I think we'd need to bump the protocol version.

I'm leaning towards just encrypting each packet with a format: ``. That's what we do in go-libp2p-pnet (well, minus the MAC; we're relying on the actual transport for authentication in...

Having some form of private network (symmetric key) support in QUIC is needed before we can switch over to it by default. What's the status here? Can we mix in...

> Is there a third option here? Can we do the encryption on a stream level? Not really. We'd leak the peer IDs at that point. We can probably find...

That would definitely hide the peers. However: * That won't hide libp2p as the extension is well known. * That won't protect against, e.g., crypto breaks in the asymmetric crypto....

Maybe? Where do we reconnect to peers on disconnect? We obviously do it but I don't think we're doing it intentionally. I think this is mostly a symptom of how...

(email backlog) So, I've been leaning more and more towards many tiny protocols. Really, I'd just define an entirely new connection "management" protocol.

> those feel juxtaposed. By "connection management", I meant connman stuff. That is, telling users that we're overloaded, telling users to disconnect, etc. Although, really, we could just have one...