Hacker News Reader

Comment by grumbel | Hacker News Reader

Lack of BitTorrent support in browsers is big thing that is missing. Brave and Opera have it, but all the mainstream browsers don't. Thus torrent downloads never got out of its specific niche.

That said, I don't think piracy is to blame here, but more the murky nature of copyright in general, with BitTorrent you automatically become redistributor of everything you download and that's just a huge liability and privacy risk that I can easily see browser developers wanting to avoid.

Also browser developers have gotten lazy, they couldn't even find the resources to keep FTP alive, so I doubt BitTorrent would have survived for long even if they tried adding it.

View on HN

Why should they keep FTP or Gopher alive, or support Gemini, when they're just worse HTTP? I think they should make it possible to write a new protocol handler though.

Is FTP really worse HTTP? If you try to enumerate directories over HTTP alarms start going off because you look like an attacker.

> Is FTP really worse HTTP?

I don't think I'd even call it that. FTP had one purpose: it was an early protocol for remotely managing files. It never had any intent to support dynamically generated or otherwise "virtual" content (as supported by e.g. CGI scripts and mod_rewrite in Apache), and I don't think anyone has ever made a serious attempt to implement that. There's no practical use case for it.

Even as a file management protocol, though, FTP sucks. Its connection management is primitive in the extreme - one TCP connection per transfer - and that ruins performance for transfers involving many files, and is difficult to pass through firewalls and load balancers. FTPS encryption is an afterthought, and makes small-file performance even worse (as each connection requires separate TLS negotiation). There's no standard format for directory listings, just ad-hoc parsing of "ls -l" output. Support for modern filesystem features like extended attributes is largely nonexistent. Need I continue? :)

The strange way FTP manages connections goes back to FTP being older than TCP/IP itself, and thus using older circuit-switched networks. It wouldn't have been unusual for a server to dial up the receiving machine on-demand, which didn't have to be the machine running the command session. Before SMTP came around, email was commonly implemented on top of FTP.

FTP was written for an early version of TCP/IP (which wasn't called that). Maybe you're thinking of UUCP, which did often run over dial-up circuits and was used for email, but didn't require two connections.

No, I was thinking of FTP, but I was probably off the mark anyway: I'd noticed that FTP was mentioned in the RFCs and surrounding discussions long before RFC 793, and that it seemed to be behaving like a point-to-point network, but it hadn't occurred to me that it might have just been using an ancestor of TCP/IP -- some variant of the "Host protocol" perhaps?

Hard to get the full context, it was before my time: my beard may be grey now, but I'm not that old.

The original version of TCP/IP was (is currently thought to have been) called Network Control Program/Protocol or NCP. There's a reason current legacy IP is version number 4.

Yes, in every way except that servers and clients normally support upload while HTTP ones don't. This is the main reason to use it.

But you should use SFTP instead. This is SSH's replacement for FTP. It's not the same as FTPS which is useless.

We don't have to keep old protocols that offer nothing alive. Maybe a couple of clients and servers to demonstrate with, but it's a museum piece, not useful code. That's not an insult - museums are important. But we don't run Network Control Protocol (IPv1) on the internet, either.

Reply on news.ycombinator.com