> There are entire categories of network software that haven't even been invented yet, because they require being able to receive calls (incoming TCP SYN packets)

> I did that with very early PGP-encrypted VOIP software that let you simply dial whomever you wanted by their IP address

This is a cute demo but ultimately a red herring. I think the crux of our disagreement comes down to whether we see IP addresses as sufficient user-facing/user-identity addresses. I do not believe them to be so.

By "DNS" above, I really meant DNS+IP - a namespace that assumes the ability to contact an authoritative server, talking directly to it to accomplish a task. As I said, there is no ability to retrieve the latest version of a given object from an untrusted peer - talking to the authoritative server is the only way to obtain updates!

A real communication service needs things like presence information, roaming, multiple endpoints, asynchronous notifications, etc. Which in your example (phone number == IP address) ultimately requires having a bona fide server sitting there to answer for those requests. You called this "discovery", but it's much heavier than that. This is the technical burden that is straightforwardly solved by the software-as-surveillance companies - set up a well-known server, and simply pay a bunch of people to make sure it is always up.

A thought experiment: Say I have a neighbor who is also DIY-technical. What can we actually gain by running a network link between us? I can give him an NFS export (or the like) to access my collection, but he's got to explicitly use of it (ie incorporate my hierarchy into his own mental hierarchy). For wider use with HTTP(s), the best I can do is give him transit to contact the server himself, but that is just becoming his ISP.

However if we're on the same torrent, and the torrent client knows how to discover his client, we can both cooperate without explicit coordination. Because Bittorrent addresses chunks by the hash of their content, I can verify whatever I receive from him without needing to contact the original publisher! Contrast when an object identity relies on an IP or DNS name, the only way to verify it is to contact its server yourself.

> even if you have globally routable addresses, you can still proxy your HTTP requests through your router if you want to

So, L4 address translation instead of L3... And I agree, to scrub fingerprints it makes sense to proxy at the highest protocol layer possible. So sure, maybe the future will be a nice flat v6 namespace for incoming connections, and a household HTML proxy to scrub access to legacy HTTP(s).

Don't get me wrong - I'm certainly not arguing against adopting v6. I just don't think it is wise to wait for it to usher in the peer paradise that people were imagining 20 years ago. AJAX and surveillance as a service didn't get adopted simply due to a shortage of v4 addresses.

> This is already impossible in some areas (e.g. parts of China) that are behind multiple (5+) layers of NAT

At a basic level, I do agree this development path is worrying. But IMO the real way to push back against this is to create a demand for something else. Unless the net result looks immediately different to a significant number of end users, the demand isn't there. And right now, even in the US/EU there isn't a widely-compelling advantage to having a routable v4 address.