>but peer to peer is essentially irrelevant now, when every communication service people actually like uses a server these days.

That's true but it's sort of a self-fulfilling prophecy the way you put it. Maybe what we lost is actually the potential to develop alternative, peer-to-peer, decentralized systems.

Take something like Dropbox, it's been very successful solving a very practical problem people are having, sharing files over the internet. Widespread NATing and publicly unreachable computers have a big role in that. Of course that's not to say that with IPv6 Dropbox would be irrelevant, there's also the problem of having the files always available, not having to worry about hardware failures and security issues. Still, I'm sure that in many cases if people could easily share files directly from their device without middle-man they would. It's just a pain to get to work reliably without going through "the cloud".

Of course nowadays that's almost an absurd concept. Everything gets uploaded on somebody's server and the decentralized web is long behind us.

> Maybe what we lost is actually the potential to develop alternative, peer-to-peer, decentralized systems.

For this to work properly one needs (a) mostly reliable addressing and routing, and (b) mostly online systems.

IPv4 and IPv6 were indeed developed for both (a) and (b). But both started to disappear when laptops overtook desktops, which would be over a decade now, and became completely irrelevant when mobiles overtook computers (laptops + desktops).

It's the world that has changed; it cannot come back in IPv4 due to address exhaustion, and won't come back in IPv6 because (a) requires stable addresses -- meaning VPNs for everyone -- and (b) requires the physically impossible "access to data when phone is out of battery and/or in a Farady cage".

The server-in-the-middle is a must for reliability; People who seriously use Syncthing or btsync instead of Dropbox have to set up at least one "constantly on" server because of both (a) and (b) above.

The last remaining use case for peer-to-peer is, I think, live (chat/voice/video) one on one conversations - and while it's an interesting and important use case, it can (and has) been solved with stable servers-in-the-middle, and I don't believe it is significant enough (or was, or will be) to stop progress; MinimalT makes much more sense than IPv6 or QUIC as a way forward, but we're unlikely to ever have that at scale.

> requires stable addresses -- meaning VPNs for everyone

The true requirement is for a stable identity, not a stable address. You just mentioned Syncthing, which is an example of this: every Syncthing node has a stable identity (which is its public key), but not necessarily a stable address. All you need is a way to map the identity to the address, which does not have to be centralized (even though the current implementation in Syncthing, outside of broadcast-based local address discovery, is centralized); bittorrent DHT manages to map a torrent's hash to a set of addresses without needing any central node.

> requires the physically impossible "access to data when phone is out of battery and/or in a Farady cage" [...] People who seriously use Syncthing or btsync instead of Dropbox have to set up at least one "constantly on" server

You stated the solution yourself: to access the data when the phone is offline, mirror it to a node which is online. Just because these particular protocols require you to set up your own always-on node doesn't mean it's a hard requirement; some older peer-to-peer protocols from over a decade ago already securely mirrored data in nodes belonging to other users.

> All you need is a way to map the identity to the address, which does not have to be centralized (even though the current implementation in Syncthing, outside of broadcast-based local address discovery, is centralized); bittorrent DHT manages to map a torrent's hash to a set of addresses without needing any central node.

That's true; but I think bittorrent DHT is the only decentralized one that seems have succeeded (I remember quite a few unsuccessful attempts two decades ago), and its success is probably related to its use case - it is of everyone's interest to have hashes well-mapped in case you'd need them.

> Some older peer-to-peer protocols from over a decade ago already securely mirrored data in nodes belonging to other users.

And for various reasons, they are all gone, whereas e.g. rfc822 email - which is properly decentralized/federated but does require a stable online node, is still going strong nearly 40 years later, despite somewhat successful attempts to re-centralize it by the likes of google.

I think it's inherent - many people now only have a phone, but no one wants a service that becomes unavailable when you lose your phone or step in a faraday cage -- there even used to be on-phone voicemails back in the dumb phone days -- as peer to peer as dumb phones can get -- and they were not popular for the same reasons.

And if it is indeed inherent, it would be better to take it into account when designing the next stage.

Where did you get the idea that we need stable addresses? This was solved with DNS, registration protocols, dhts, etc decades ago. Nobody has had stable addresses forever.

stable in the "for the next few minutes" sense, which you do need e.g. for mobile phone or video calls. With mobile phones your address can change every few seconds as you drive on a highway and get passed between cells and even carriers.

DNS never solved this, DHTs didn't either; and I'm not familiar with a DHT that is actually successful except for bittorrent despite many attempts, even for "stable for a few hours" case.

All the cases that sort of work (RTMFP flows, SIP registrations, old Skype, ...) essentially have peer-to-peer communication as a server-offload optimization (that is, peers may talk directly to each other after the server arranged everything iff the stars aligned correctly), not as their main method.

P2P will stay irrelevant insofar that we don't fix networking to make it easy again. And we really want it to be, for values of "we" that != carriers.

NAT and related IPv4 hacks hand a great deal of power to people who want to meter you by the byte, inspect your content for compliance with their business model, and generally define how you are "allowed" to use the internet.

It doesn't have to be that way.

> for values of "we" that != carriers.

It's everyone except technical end users. Google - not a carrier unless you use FI/Fiber - wants to intermediate everything. So do Facebook, Microsoft, Slack, Discord and everyone else - you can't be monetized if they don't control the flow. The government wants that too, by the way - it makes stuff like Prism realistic and so much easier.

> NAT and related IPv4 hacks hand a great deal of power to people who want to meter you by the byte, inspect your content for compliance with their business model, and generally define how you are "allowed" to use the internet.

They do no such thing; They already have all that power by virtue of your pipe going through them - even before the CGNAT days, my ISP would require extra payment to let you listen on e.g. TCP ports 25 and 80. Every packet you send or receive goes through your carrier, whether or not they fudge the IP address on it to a different space.

> It doesn't have to be that way.

And yet it can't be any other way because 99.9% of users are indeed better off if their incoming data is filtered. That doesn't have to be that way either - we just have to have secure software so being on the internet without a firewall is not a risk.

The internet is becoming a health-like thing: You need enough people around you to be vaccinated so that you don't suffer viruses/ddos attacks yourself. But most of the population is worse than antivaxers - they don't even know that they can be (or have been) infected, and there's no clinic to just go to even if they did.

... so it effectively does have to be that way, unfortunately.