Comment by quaintdev

Counterexamples: DNS and it's silly, idiosyncratic compression; FTP and its absolutely batshit control/data channel connections; the ASN.1/BER nightmare of SNMP. Also consider the "simple, plaintext protocols" that should not have been: the r-utils, for instance, had to be supplanted by encrypted binary protocols; NNTP failed, and ultimately ended up centralizing Internet discussion on sites like this, because it was doggedly optimized for text and inevitably abused for binary sharing.

The moral of my story is: those old protocols were bad, practically all of them.

HTTP is a simple, plaintext protocol.

(I've implemented producton-grade HTTP libraries many times. HTTP being a one-size-fits-all protocol means the existing libraries are ridiculously specialized and overspecced.)

We also used to put jokes and ASCII art in there. I spent way too much time getting an ASCII Kilroy to look just right.

FTP is an absolutely bonkers protocol. I’ve written lengthy posts in here in the past detailing why that protocol needs to die.

Email is another clusterfuck of a protocol (well, several protocols) that barely functions despite dozens of modern pseudo-standards plastered over it. I’ve written extensively about that too.

DNS is frequently the source of amplification DDoS attacks. It’s another protocol that made sense once upon a time but has struggled to keep pace with modern advancements in technology

IRC is probably the best of the bunch here but even that has struggled to keep pace and can be subject to undocumented behaviours (like line length).

…and these are the protocols still in use. The ones replaced by HTTP were either crazier or over simplistic that they offered nothing over HTTP.

I’ve written my own clients for every one of those examples and had to deal with the pains of their protocols. I’ve also written my own web browser. And while HTTP has some warts too, I’d take that over FTP and SMTP any day of the week.

OK, I'll bite.

finger was conceived in a time and environment where you would reasonably assume a lot of things which stopped being true a long time ago.

many users per machine/users actually logged in to that machine/users being in walkable distance or in the same building/no compartmentalization, i.e. your demon has access to every users' home directory

and that's just the top of my head.

if you see finger as "everyone has a place to store a message and people can read it" then yes, you might say it wasn't worse than HTTP - but I think the plan feature wasn't even the original intention, it was more "is person X at their desk right now?".

So all features aside, it has so many assumptions baked in, I'd have to think hard how to replicate it in a modern way for a company and still fit the protocol.

I'm not sure I 100% agree with the protocol being silly (merely not great, BUT it's been years since I read the RFC - it's short, you should), it's kinda simply plain text with some wonky hostname shenanigans, but the whole concept hasn't aged well. But that is if you completely ignore anything about security (see what I wrote above) and privacy.

Imagine if we were stuck in a world with a large bloc of users running MSIE6 regularly accessed web servers running 40-bit SSL2. Neither clients nor servers ever bother updating, because it still works for them.

That's essentially where every other protocol is. HTTP gets all the energy, active development, updates regularly rolled out. Meanwhile if you tried to make, say, FTP more rational by transmitting data over the control connection, nobody would be able to use it since all the servers are still running 25 year old wuftpd with the minimal patches to not get pwned and they have no interest in updating (if they even remember the servers exist).

Personally I think we've lost something valuable when only one protocol exists, but I'm one of those Luddites who still reads email with Thunderbird so what do I know.

You didn't make an argument why it isn't a silly protocol. You didn't make an argument for why it is better in any way than HTTP. You didn't make an argument why we are worse off having replaced everything with HTTP.

Your entire post was stupid and had no point other than trying to be a gotcha.

And in my eyes, that's pretty terrible - we're stuck with a number of proprietary formats for commercial software, the adoption and more widespread support for which has been an uphill battle every single step of the way, since MS isn't incentivized to do that properly.

Honestly, i avoid .doc and .docx as well as most of MS Office formats whenever possible, at this point i just have LibreOffice installed and use all of those native formats: https://en.wikipedia.org/wiki/OpenDocument

Not only that, but most of these formats are problematic on a technical level - when compared with something like simpler Markdown files or any other text based format, looking things up is needlessly hard, so you can forget about easily searching for some text within a directory of 100s of such files on a server without some niche tool.

HTTP is like the PC: its main quality, and its worse defect, is extensibility.

For a long time, the university I worked for had multiple big Solaris boxes that were used as shell boxes for faculty and students. After I left, I would still use the finger protocol to see what my old coworkers were up to!

The Morris worm spread through a bug in finger(d). Turned out doing one thing only could still be a vector for a system compromise.

Is it?

True, most finger implementations are trivial. But there is nothing stopping to create a finger daemon which does something dynamic based on the query the user sends. The same set of vulnerabilities is possible. It is also possible to write a simple web server for a single purpose without scripting, which is similarly secure to a finger daemon. Also finger clients are relatively secure as they don't do any interpretation of the data, (which might mean that they don't do any validation, which would allow console injections with escape sequences....) but there isn't anything stopping to send the response in HTML. Also you can write an as secure HTTP client for that tight use case.

In addition we have tons of tools to work with HTTP for debugging, proxying, caching, filtering, ... none of those for finger (which of course is a responds to nobody using finger and everybody using HTTP) which allow better handling.

"Scripting" isn't part of HTTP.

https://en.wikipedia.org/wiki/Quic#Source_code

I see at least 2 here which have commits from 2021.

To be blunt though, I don't like C. It does low-level better than many languages, but C's idea of high-level is too low.

If I had to use QUIC from C, I would pick a Rust or C++ library, write a wrapper that makes it basically into a single-threaded epoll knock-off, and then call that. If I had to do it in pure C, I'd give up.

For my pet projects, I want to use the tools that make me most comfortable, where I can slide between low and high exactly when I want. Web browsers struggle to go low, and C struggles to go high.

https://github.com/microsoft/msquic

msquic would be a good start, which is the protocol implementation from Microsoft. I used it for a project of mine which used Quic for something not HTTP/3 related.

I tried to bring some nuance to this. 10 years ago I would have said something more like "Fuck web browsers". I've toned back on the hate, but I still think they have serious shortcomings. (Not that native doesn't - Notice I said nothing about permissions and untrusted code)

tl;dr: I think web browsers have a Pareto problem. Building inside a web browser is pretty all-or-nothing. Their interfaces make the most common 90% of cases easy but the other 10% of interesting niche stuff totally impossible, or too slow to be useful. Just like how old PC games would play music by triggering the CD drive's "Just play this track" feature, browsers are fine for doing super-high-level stuff exactly the way most people want to do it. But if you want to do anything with that audio other than stream it unmodified straight to the speakers, suddenly the APIs let you down. And the whole time, you're taking on some of the biggest dependencies in history. There are two companies that make full-sized web browsers. One is a non-profit constantly struggling for funding while making awful PR gaffs and being hypocrites about privacy. The other is an openly evil advertising company.

Full:

I've done really basic stuff, like I learned how HTTP works, I wrote a few web apps with Rust, I made a game with TypeScript and WebGL. But it just never clicked for me.

My comment is missing a little context. There's basically two different niches:

1. If I want more than 2 or 3 people to use it, it has to run in a web browser. I don't mind doing WebGL and putting it on a static site. I can always do a native port if I feel like it. All the games I've made can be modelled as "Read keyboard input and run OpenGL commands", and browsers are enough for that.

2. If I want to really have fun with something, just for myself, web browsers are too big of a dependency and the restrictions are too tight. Sure, they'll get QUIC as WebTransport soon (IIRC), but I'm always gonna be limited by the dependencies.

I don't like Electron out of principle. It's just so big. Native development can be awful - Big C projects are not fun to build. But Rust is striving for "Just clone and `cargo build`". What's the `cargo build` for web stuff? I have to set up TypeScript or something else to shield me from JavaScript... If I were using Electron I'd have to learn all that...

I actually like local web UIs. I think because that offers flexibility. If I want to send a video stream from a browser, sure I "just" have to use WebRTC. But how do the WebRTC servers work? I haven't found satisfying documentation. What if I want to start with a webcam stream and then compose graphics into it before encoding? I know browsers have Skia, but is that exposed to me? Or is it like so many bad "Play an audio file" APIs where it breaks down as soon as I want to play a _remote_ audio file or _stream_ an audio file or _transcode_ an audio file.

So (sorry for the meandering) back to my toy IRC idea.

I can do that with HTTP and long-polling and it would kinda work. But it would just be a crappy Matrix clone. What I really want is to show off "Look, I think QUIC is going to bring back custom protocols, QUIC has not to come to abolish the word of TCP but to fulfill it, and here's how it looks."

And I could do that with Electron, but like the "Let me do everything for you and make the 10% of niche cases impossible" API that can only play audio or send a webcam stream without any compositing, Electron presumes I'm going to have a GUI, and I'm also going to run it on the same computer.

Whereas if I make the first prototype UI with curses or a local web UI, I can forward it over SSH easily or run it when a GUI isn't available.

It sounds a lot like Gemini, but I think Gemini is a little misguided. It sounds like most of its proponents think that you can control a protocol by just having very noble goals. And it sounds like they are opposed to HTTP and QUIC not because the protocols are bad or even hard to implement (In the case of HTTP. QUIC actually is hard to implement), but just because bad entities use them. I think it's dangerous to believe that powerful tools are only for bad purposes. It will leave good people de-powered.

Yeah, 4.2 BSD fingerd was calling "gets" to read the name of who you were fingering into a small fixed size buffer on the stack.

https://man7.org/linux/man-pages/man3/gets.3.html

Chris Torek had hacked our version of fingerd (running on mimsy.umd.edu and its other Vax friends brillig, tove, and gyre) to implement logging, and while he was doing that, he noticed the fixed size buffer, and thoughtfully increased the size of the buffer a bit. Still a fixed size buffer using gets, but at least it was a big enough buffer to mitigate the attack, although the worm got in via sendmail anyway. And we had a nice log of all the attempted fingerd attacks!

The sendmail attack simply sent the "DEBUG" command to sendmail, which, being enabled by default, let you right in to where you could escape to a shell.

Immediately after the attack, "some random guy on the internet" suggested mitigating the sendmail DEBUG attack by editing your sendmail binary (Emacs hackers can do that easily of course, but vi losers had to suck eggs!), searching for the string "DEBUG", and replacing the "D" with a null character, thus disabling the "DEBUG" command.

But unfortunately that cute little hack didn't actually disable the "DEBUG" command: it just renamed the "DEBUG" command to the "" command! Which stopped the Morris worm on purpose, but not me by accident:

I found that out the day after the worm hit, when I routinely needed to check some bouncing email addresses on a mailing list I ran, so I went "telnet sun.com 80" and hit return a couple times like I usually do to clear out the telnet protocol negotiation characters, before sending an "EXPN" command. And the response to the "EXPN" command was a whole flurry of debugging information, since the second newline I sent activated debug mode by entering a blank line!

So I sent a friendly email to postmaster@sun.com reporting the enormous security hole they had introduced by patching the other enormous security hole.

You'd think that the Long Haired Dope Smoking Unix Wizards running the email system at sun.com wouldn't just apply random security patches from "some random guy on the internet" without thinking about the implications, but they did!

From Wikipedia [0]: "Robert Tappan Morris is an American computer scientist and entrepreneur. He is best known for creating the Morris worm in 1988, considered the first computer worm on the Internet.

1988 – Released the Morris worm (when he was a graduate student at Cornell University)

2005 – Cofounded Y Combinator"

[0] https://en.wikipedia.org/wiki/Robert_Tappan_Morris

Yeah, tunneling everything over HTTP did really solve buffer overflows.

Thanks for the feedback. I'll add it.

Yes you are correct: It's the nature of pub-sub that all subscribers are notified if a messages arrives on a topic.

The most important difference a Usenet-like clients brings is per-message read/unread status, which is what enables long-running threads and discussions. Without most clients (most users) supporting such read/unread tracking, you won’t have long-running discussions, which changes the whole character of the medium.

Per-message read/unread status in practice requires keyboard navigation (or as an inferior alternative, paging with read/unread tracking like in web forums), which doesn’t work for mobile.

The lack of read/unread tracking is also why we don’t have long-running discussions on HN.

The only remaining medium with per-message read/unread tracking we currently have is mailing lists.

That's not true. Everyone had a voice on Usenet. The same cannot be said for Reddit unfortunately.

https://www.w3.org/TR/social-web-protocols/

That makes little sense to me. Each post contains a pointer to its parent post in the thread. That's how the client side can construct the thread.