Hello, in light of issue #20, I believe it's worth mentioning a reason to reject TCP support in favor of continuing QUIC support, that being the ability to efficiently open and maintain proxy connections between peers.
A proxy connection would essentially add yet another layer of privacy to the protocol, allowing peers to establish and maintain an AMS session via another peer. You might ask why this would even be advantageous, when AMS already implicitly routes all messages to arbitrary destinations.
However, there is an important privacy reason. Whenever you establish an AMS session directly with another peer, you are actually disclosing your IP address as it relates to your SubverseV2 network identity. Some people (including myself) may deem this problematic, because if we can take advantage of QUIC's multiplexing feature to implement full, strict IP-anon, why wouldn't we?
Instead of implementing TCP at all, we should keep the strict QUIC-TLS requirements. This would allow us to use the following high-level pattern for establishing proxy connections via multiplexed QUIC:
Initiating peer sends a special "proxy request" to the proxy peer, denoting the SubverseV2 identity we actually want to connect to
Proxy peer routes request to destination peer for their public key via the SubverseV2 overlay
Destination peer sends back their public key to the proxy via the SubverseV2 overlay
Proxy peer forwards destination peer's public key to initiating peer
Initiating peer sends proxy peer their public key, as encrypted using destination peer's public key
Proxy peer forwards this to destination peer
Destination peer decrypts initiating peer's public key
Proceed to establish AMS via the proxied stream
The reason why multiplexed QUIC would be advantageous in this scenario is due to the fact that multiple AMS sessions could be established and maintained between the same two UDP/IP peers asynchronously and just-in-time, without the need to renegotiate. This would even have advantages for roaming peers, whose IP addresses change quite literally all the time, and without warning.
SubverseIM
commented
3 weeks ago
Hello, in light of issue #20, I believe it's worth mentioning a reason to reject TCP support in favor of continuing QUIC support, that being the ability to efficiently open and maintain proxy connections between peers.
A proxy connection would essentially add yet another layer of privacy to the protocol, allowing peers to establish and maintain an AMS session via another peer. You might ask why this would even be advantageous, when AMS already implicitly routes all messages to arbitrary destinations.
However, there is an important privacy reason. Whenever you establish an AMS session directly with another peer, you are actually disclosing your IP address as it relates to your SubverseV2 network identity. Some people (including myself) may deem this problematic, because if we can take advantage of QUIC's multiplexing feature to implement full, strict IP-anon, why wouldn't we?
Instead of implementing TCP at all, we should keep the strict QUIC-TLS requirements. This would allow us to use the following high-level pattern for establishing proxy connections via multiplexed QUIC:
The reason why multiplexed QUIC would be advantageous in this scenario is due to the fact that multiple AMS sessions could be established and maintained between the same two UDP/IP peers asynchronously and just-in-time, without the need to renegotiate. This would even have advantages for roaming peers, whose IP addresses change quite literally all the time, and without warning.
Thank you for your consideration~