upvote
> But we'd still end up with server-client cloud architectures, even if we had started with IPv6 in the beginning.

Skype was originally peer-to-peer for comms, but ended up with "super-nodes" because of NAT limitations (not sure if STUN/TURN/ICE had been invented by that point). BitTorrent is still peer-to-peer. A number of folks ran Mincecraft servers at home, but you'd only be able to have one on the default port.

But this doesn't only hurt server-y stuff: you may not notice it if you're with a legacy MegaISP with lots of money to throw at IPv4 allocations, but if you're with a younger or smaller ISP, then there's a good chance you're behind CG-NAT, so many console games won't work.

reply
Yeah I feel like a lot of the people criticizing this are still being client-server brained. There's a lot of use cases that "everyone is a server" would open up without turning everyone into a sysadmin and they'd likely get turned into user-friendly software like BitTorrent or Skype or early Spotify.
reply
"Client-server" thinking may in general be a 'hobbled' way of thinking of things.
reply
There's DC++, Tox.
reply
> A lot of this feels like a requiem for the days when the only people on the Internet were "high-computer-skill" type folks.

FWIW I (writer of blog post) am 21 years old and just a bitch lol

reply
But you are a "high-computer-skill" person.

Also, the lazy sysadmin forgot to set a quote for today.

reply
Not saying this is what’s going on, but you can ABSOLUTELY have nostalgia for a time that wasn’t your own, too.
reply
Oh yeah absolutely
reply
I suppose I could ask elsewhere but do you (or does anyone else) have a word/term for this?
reply
That's fine. Based on my recollection I don't agree with your thesis (or think it's at least greatly exaggerated) but reading source documents from the past and advancing an argument is solid history scholarship.
reply
There was a point in time in the mid-2000s when P2P networking had briefly made running your own server attractive to end-users again. And then the iPhone came out and completely killed any hope of that becoming the norm.

The thing about smartphones is that they are both completely dependent on wireless connections to central servers in order to function and completely unsuitable to operate as servers. If you forced your phone to serve files anyway, your battery would drain quickly and the CPU would be drowning in its own waste heat. You might argue that you could still do non-server things on the phone, but practically speaking, a node that can't handle server tasks is just a leech. P2P networks work on a mutual aid basis; they require the majority of nodes be capable of shouldering traffic or sharing files in order to be a net benefit. If you add, say, tens of millions of new mobile phones to the network, the network will become unusable as any desktop machine gets DDoSed by hordes of phones asking for a babysitter.

So even in the world where IPv6 did to v4 what v4 did to NCP, we'd still ultimately end up with "my files go in the cloud", because clouds are coinventions of smartphones, in the same way that cars are coinventions of suburbs. You can't have one without the other, and once you do have both, they become so economically dominant that others get socially coerced into using them.

reply
Nokia were experimenting with using their smartphones as web servers in the mid-2000s. You were able to write blog posts and share photos, and if you logged in to the site you could look up your contacts or download your camera roll. There's an article on this here: https://allaboutsymbian.com/features/item/Previewing_Nokias_... .

Obviously it's all very basic, but with a few years of development and polish (and probably someone besides Nokia copying the idea) I think this would be a compelling product. You could basically have the same feature set as something like iCloud but without the subscription or your files going elsewhere.

reply
> Running a server used to be trivial: run an executable, tell people your address, done...

This works, until you have more than one person accessing your server. Then you need to worry about accounts, credentials, data isolation, etc. And then if a couple of people connect to your server and start using it, you have to worry about staying online, staying updated, backing up the data. But other than that... yes, trivial.

And just to be really explicit, you always have more than one person accessing your server, and most of the time they are unwanted users trying to break in.

reply
> most of the time they are unwanted users trying to break in.

Exactly. Of all the reasons why the average person doesn't have an Internet-visible server, NAT, I would say, is pretty far down on the list.

reply
1. NAT and a firewall are 2 different things 2. With IPV6 you can have so many IPS that unwanted users can't guess your IP. This isn't true security but see 1 for that.
reply
> 2. With IPV6 you can have so many IPS that unwanted users can't guess your IP.

In fact you could have an IPv6 address for each user, and if one starts becoming troublesome both revoke account and stop using that address.

You could create a new IPv6 address every millisecond, and it'd take 584,868,233 years to exhaust a IPv6 subnet (/64).

reply
> most of the time they are unwanted users trying to break in

Thankfully, we have wireguard now. It drops all packets by default. From the perspective of people who don't have the requisite cryptographic keys, it's like the computer is not even there to begin with.

I've always found it strange how people just put computers out there on the internet and just allow them to interact with total internet randoms. Why are we allowing our computers to talk to strangers? No wonder people are getting hacked.

reply
If the utility and functionality of the server requires those things, then they're required regardless of whether or not that server is internet-facing.

Jill from Elbonia may be always be a threat, but this doesn't mean that Joe from Accounting is not a threat or cannot ever provide a vector for Jill. :)

reply
I mean, no, you don't have to worry about all that stuff unless the business logic demands it. The OP is entirely correct for eg just serving a static file.
reply