> 1. Everything being 'free' by default drives us to ad-supported centralized services. Economics aren't a separable concern.

I hate this argument. I've been online for a long time and the internet existed just fine without, for example, facebook. We don't have to accept ads but we do have to be willing to not use certain things out there.

Indeed, on the surface the argument is sound, but when you look back into past, it's clear it is not how things have to work. Web can exist even without pervasive surveillance. It would be different, no huge ad companies growing like cancer, but that would probably be good for information quality/communication freedom on the web.

Blockchains right now mostly are trying to do exactly this - bring economics into computation and network space. This is of course a higher level solution, but the one that is quite achievable now. Protocols like NEAR and Internet Computer can be good examples of this.

I know this is a holywar topic and many would disagree simply by seeing `blockchain` word used here. But to my mind this exactly the place where this technology is beneficial. We need automated algorithm controlled currency to have this type of smart internet subscription.

Yes, I only left this out because it was over the horizon at the time. I did find these papers inspiring in the 90s, and as with the Digital Silk Road paper I linked above, the ideas could have been thought of earlier (e.g. capability security goes back to the 60s): http://www.erights.org/talks/agoric/index.html

I think this is a problem with the World Wide Web, not the Internet. At the network level, per-user cost accounting and quality of service is implemented quite well, to the point of being able to pay per byte if you really want to. And access to any network beyond your own LAN is not free.

The problem of how to fund actual web application development is not much different from the problem of how to fund media development in general. Newspapers, television, and magazines alike long ago settled on some mix of premium-tier subscription services augmenting a more open, ad-funded free tier.

This is so much more of an issue today than 30 years ago not because of anything specifically about ads to fund media, but because ad profitably has been driven sky-high by individual consumer profiling that relies upon privacy invasion and surveillance of your customers. Ads back in the day would improve via voluntary focus groups and that was fine. Today, they improve by tracking every digital action a person ever takes in order to more accurately correlate interacting with an ad with making a future purchase. Volunteers for focus groups are pretty much okay with giving their opinions in return for cash. Every person on the planet is not nearly as okay with having every digital action they ever take recorded and analyzed.

In the alternate history I'm imagining, with network-layer accounting and payments from the beginning, flooding and spam were never much of a problem -- they were at most a "nice problem to have". Endpoint security became a priority from the beginning, because failures that cost money (even if not much per computer) get treated that way. Participating in the network as a full peer, e.g. running the equivalent of a webserver on your home PC, was considerably more practical and normalized. (The bigger address space of course went into this too.) And this history made other peer-to-peer software easier to develop and more practical and economically sustainable, in a virtuous cycle.

This doesn't mean it'd kill advertising. It wouldn't even kill all of the forces encouraging me to put my 'content' on centralized services even though I'm nothing like a media corp. But I suspect the right changes could've helped a lot towards a healthier computational ecosystem now.

This early architectural decision that costs are out of band didn't fundamentally make anything impossible. But when you see a lower-level problem addressed by higher-level workarounds, and you're getting to redesign the system, isn't that exactly what constitutes an opportunity?

I might have read somewhere that the original design of HTTP allowed for transactions to occur. This free point is a big one. Once Apple set the price of 0.99 for an app it really dropped the market price for software. It's funny that there is so little different between enterprise software and consumer apps except for a monstrous difference in price point. Funny thing is, consumer apps are sometimes better.

The 402 HTTP status code is "Payment Required". At one time people envisioned micropayments etc but it never went anywhere.

Transaction fees are what kill this. That and moral police / "fraud" charge-backs caused by insufficient user authentication.

I also don't want to be nickle and dimed to death, given the transaction fees there's a huge push to subscriptions and other models. Where if I could instead just pay exactly what a generic ad I'd _never_ click on anyway pays to get placed (like 0.00001 dollars for all the ads on a webpage stuffed with them) I might actually pay instead of using adblock for all of the security, usability, and bandwidth saving reasons.

There have been many micropayments schemes over the years. IIRC, there was a decent one slightly cleverly called "Millicent" developed by DEC and pushed in the early Internet days... (Then there were the various pre-bitcoin internet banks/e-cash outfits - First Virtual, eGold, etc....)

IPv4 adresses fit in a standard 4byte integer, that might be a reason.

Quite frankly, if they didn't allocate full /24 to single entities (including localhost...), we might still have enough addresses left.

Nah, if you sort by date here you can see how quickly IANA was doling out /8's to the RIRs up until they ran out: https://www.iana.org/assignments/ipv4-address-space/ipv4-add...

Even if we hadn't wasted /8s on huge allocations to single companies, and things like 240.0.0.0/4, we'd still be basically where we are today, with v4 address space being scarce and traded as a commodity.

What's wrong with it being traded as a commodity?

>we might still have enough addresses left.

For how long?

Isnt it "127.0.0.1/8" which is allocated, not "127.0.0.1/24"?

yes, according to wikipedia[1]

IPv4 is just inefficiently allocated in general. Why does the world need 10.0.0.0/8 in addition to 192.168.0.0/16? Isn't 65k addresses enough? Is there a private organization in need of 16 million addresses?

Not to mention AMPRNet (amateur radio) owned the entire 44.0.0.0/8 up until 2019 (a portion was sold off to Amazon). That may have seemed reasonable in 1980 but now it's just plain crazy.

[1] https://en.wikipedia.org/wiki/Reserved_IP_addresses

> Is there a private organization in need of 16 million addresses?

Plenty of mobile phone networks have well over 16 million subscribers, and they typically don't have enough public IPv4 addresses for everyone. This has led to really hacky stuff, like using DOD IP ranges as psuedo-private space, or re-using private IP addresses in different regions (which can't be fun to maintain.)

Some networks have fixed the problem by using NAT64 - forgoing IPv4 altogether internally, and translating to public v4 at the edge. (Works surprisingly well, T-Mobile US has been doing it for the better part of a decade.)

It's not about number of addresses available, it's about reflection of organization hierarchy in the octets. The 10.0.0.0/8 range is useful for breaking a distributed company's network up so each major office gets a 10.x.0.0/16, and each department a 10.x.y.0/24.

This is why 192.168.0.0/16 is often used for services like libvirtd, kubernetes and docker. And the use of the range by those services makes it even more unwieldy to try and put some other LAN in there.

You can work around these considerations if you want, but many people won't. When you're the network engineer responsible for designing a company's networks, you'll be wanting to keep things simple and robust. When you're called in at 3am on a Sunday because the network is down, you better hope your ability to recover doesn't require making a bunch of subnet calculations because you decided to try and use the pool of available IP addresses efficiently.