Hacker News Reader

Comment by ssalazar | Hacker News Reader

The barrier is from the tools, not NAT. Maintaining your own server is prohibitively difficult for pretty much anyone besides niche technology enthusiasts or IT professionals.

> Were it not for NAT, I would have expected an explosion in tiny self-hosted personal sites around the time that dialup was replaced by always-on cable connections

NAT never stopped you from port forwarding 80 to your local server and many people (myself included) do this/have done this with even e.g. DynDNS to have a decent looking host address. At the end of the day managing your own server hardware/software is a far bigger barrier than NAT.

View on HN

Some (many?) ISPs block forwarding of port 80 specifically. I have a third party router as my main router, with the ISP provided modem/router/wireless AP box in bridge mode, because I can't forward port 80 through the web interface of my ISP's router.

Also, port forwarding is _hard_. It might not seem like it to us more experienced people, but it's a problem that's not very googlable because there's a billion different admin interfaces for routers, and they all do it differently enough that you have to understand what you're doing, not just follow a guide, to port forward.

In contrast, if it was possible to make some simple software which regular people could install on their personal PC, and then they got a WYSIWYG website editor, and that software handled all hosting gave the user a link (ip address) to their website which they could send to friends, I imagine a lot more people would experiment with web publishing. Obviously, in order to run a site 24/7 on a dedicated server with its own domain would still be prohibitively hard for many people, but people would've at least been able to experiment and play with hosting their own simple website which they can share with friends.

Protocols need not always be client-server. The barrier raised by middleboxes is mainly to peer-to-peer applications, whose progress may have been systematically inhibited as a result, in favour of server-based i.e. centralized applications. If that hadn't happened, then your personal micropublishing social media tool might today be a peer-to-peer application, rather than a centralized advertising behemoth. There's no intrinsic expectation that end-users must feel like they're running a server in that user story.

Consider this: the application protocols that arose in the early days of the Internet were decentralized/federated systems such as NNTP, SMTP, IRC. But application-level protocols that are developed with a P2P or federated architecture today are niche rather than mainstream (like BitTorrent), or dead because a major company killed their adoption (like XMPP).

The canary was the loss of old-school active-mode FTP, broken by middleboxes impeding connections. Plenty of people saw this coming.

Maintaining your own server might be hard because there's no incentive to make it easy for technophobes to do. If there were software that was dead easy to use, there'd still be roadblocks: NAT, $ for a domain, ISPs blocking port 80, etc.

also the computer must always be on, it can't interfere with your ability to use your own computer (QoS, throttling), and backups.

Reply on news.ycombinator.com