The moral of my story is: those old protocols were bad, practically all of them.
That's not really why it failed though, since those binaries are in separate newsgroups that most servers simply don't carry.
The issue is more about spam and lack of moderation, which makes it somewhat unfriendly to newcomers, since one has to do the spam/troll filtering locally. This over time lead to most newsgroups slowly dying out.
I consider binary newsgroups and the rest to be two almost unrelated things. Plenty of non-binary usenet servers were doing just fine, but of course no one would really pay for them.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
I'm not saying I can refute what you're saying, just that I think my claim about "binary vs. plaintext" being problematic with respect to NNTP is well-founded.
(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.)
HTTP is the universal protocol because the mental model of "verb-metadata-payload" fits almost everything you can imagine, and the socket handshake/framing parts are obvious and very performant. This is why HTTP is used everywhere from pushing stock quotes to industrial automation.
HTTP 2 and 3 aren't universal protocols, they solve a very specific problem of serving static content to browsers for Google-scale websites.
In effect, HTTP 2 and 3 are exactly the kind of niche one-problem protocol that HTTP was supposed to replace.
HTTP3, more the same! The performance wins of HTTP3 won't matter at all for most typical web applications. But typical web applications aren't the point of HTTP3.
No.
> ...more flexible,
No.
> ...and more reliable than HTTP1
No.
Like I said in another comment - I'd wager the majority of HTTP use cases have nothing to do with a browser or HTML/CSS/JS.
HTTP2 might be nicer when you're serving static content to a browser; debatable, but I'll give the benefit of the doubt.
In all the other vast domains of HTTP usage HTTP2 does nothing good.
Your entire post amounts to "I like HTTP" and "old stuff bad."
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.
SMTP is one of last of decentralized open communication protocols that is still widely used by business. It evolved over time, gained some additions and stayed alive. The biggest issue I have with e-mail nowadays is companies like Microsoft and Google acting like they go out of their way to break protocols and deliver less and less messages from perfectly well working but decentralized sources.
Microsoft is especially bad of the two, with years-long tradition of acting against standards (Outlook Express connecting to recipients' MX, cloud offering accepting messages for delivery and never delivering them [1] etc). Google, I believe, as soon as they find a better way to get hold on user's invoices and receipts, will teach their users that they should use something else instead.
Stating that standard barely functions just because anti-privacy corporations only pretend to use standards in way there were intended, but concentrate on breaking them, is not how I would describe current state of e-mail-related stuff.
It started "not being anymore" with corporations - and once again I bow before Microsoft and Google - using less and less lube over time when telling their own clients what their role is at the ecosystem.
I will absolutely fight any attempt at calling e-mail protocols broken just because a corporations can't figure out their revenue around it.
And this isn’t even touching on the problems with IMAP and the insanity that POP3 is even still a thing.
Last time I attempted setting up messaging accounts with beforementioned companies, it wasn't possible to use Mutt or bare Thunderbird - one had to use client software allowing some kind of RCE to set up access to those services. Add Google's bubbling[0] and Microsoft's repeated mail losing, and we no longer really have globally functional e-mail based on standards.
When some of the biggest actors don't follow rules describing delivery without proposing changes - yes - e-mail is being broken but not because protocols underneath are broken. It's because people trust these companies and possibly don't know that they may be victims of careful information filtering.
I have done some e-mail - related work for hosting companies in the past. For some years now, POP3 is not really a thing. It exists, it is being set up by mistake from time to time but the number of POP3 users compared to IMAP users was barely noticeable and I don't think it grew. I'm afraid to ask what your issues with IMAP are...
[0] I suspect that Google bubbles its e-mail customers just like its search users. Most non-technical people I know treat "spam" folder like it would literally burn their fingers upon touching. They act similarly, like trained to only look inside there when not seeing awaited messages in the inbox. Google delivering perfectly fine messages straight into "spam" folder has comparable results to Microsoft losing/destroying their customers' mail.
Email dates from an era when it was safe to trust people connecting to your server because everyone knew those individuals personally.
That methodology hasn’t scaled in 30 years.
I see arguments for "non-modern" not "broken". Some wines aging better doesn't necessarily mean that others deteriorate.
> What would you suggest to replace e-mail while retaining its flexibility?
There’s no reason why we cannot redesign the email paradigm around a totally new protocol. The problem isn’t that’s it’s technically difficult, it’s that SMTP is too prevalent now. It would take someone like Google abusing their market share so bring in a successor.
Also any replacement would need to be at a protocol level. A lot of the attempts I’ve seen have also tried to modernise the experience as well (like Google Wave) but the reason email is successful is because it is familiar.
Granted it's already nicer for clients not to need to configure SMTP to begin with.
Acessing port 25 of server is usually blocked by ISPs as a way to prevent spam.
Authentication with mail is separate, usually to allow for relaying whilst anyone can usually drop emails IFF your server is the destination.
Confusing and needlessly complex? Yep. Natural result as of uncontrolled evolution? Yep.
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.
We now all go about our daily bakery shopping in the fancy sports car instead of a small rusty bike.
And people have differing opinions whether this is the best timeline to have...
Finger on the other hand is would be a very narrow API to for a certain service without ANY of the flexibility of HTTP. No custom headers, no Basic Auth, not even the difference between GET and POST.
So yeah, maybe the original comparison between finger and http is already flawed, but unless HTTP/2 gives you something that HTTP/1.1 can't do then HTTP/1.1 is still perfectly valid, and probably will be in 10 years, at least for low-traffic situations. (finger should be reaaally low-traffic in comparison).
That is the point. The flexibility is not free. Every conditional doubles the number of possible execution flows. This brings complexity. To some extent it is mitigated by the economies of scale because now everyone uses HTTP for something, so collectively we get that more complex code more polished. But there is no such thing as the bug free code - so every participant will have to deal with patch cycle and generally preventing bitrot.
For a small well bounded custom protocol which solves a well defined specific use case, one can hope to write a dependency-free implementation that can be tested and work well enough and left alone.
I recently was at an event with a few thousand wifi devices.
About a third of the internet traffic was updates..
I think I like the idea of a "spec" inside the same "protocol" more. For example if you understand HTTP you can quickly reason about any spec of a REST API that's done with JSON payloads without caring for the HTTP wrapper layer, just as you don't care for TCP around it.
Yeah, reusability and layering of engineering knowledge is useful - it makes dealing with complexity easier.
But it also makes it easier to build complexity without spending thinking of a simpler solutions. Because time to market.
And thus we have exhibits at https://mobile.twitter.com/internetofshit
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.
What's lame and actually damages discussion is haranguing people over things they've said you can't make good sense of. That's not curious conversation, it's not really much of a conversation at all.
If you want something, it would be a shame if you didn't get it because an internet proponent failed to detail their arguments.
What do you think is uncivil about accurately characterizing your post?
I have no interest in challenging what you said. As I said, I don't necessarily disagree. I just think throwing out unjustified opinions isn't useful or interesting and it would be better if you had said why you think what you do.
But I still would like to see efforts happening in applications like Nokia's mobile web server. Another such effort from a decade ago was Opera Unite https://linkdekho.in/1e2vAy
Outside of the tech world, it pretty much did.
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.
Finger on the other hand does one thing, and does it well.
I would argue that we need more smaller protocols and less kitchen sink protocols.
The drivers for kitchen sink protocols are not necessarily technical, they could be financial. As a bigger protocol gets more name recognition it becomes a less risky pitch in the eyes of management to adapt the protocol instead of going with a smaller one, or inventing your own. This adaptation sometimes leads to the bigger protocol getting extensions and growing even larger. The other reason HTTP is often used is security policies - the port is open, so no additional ports are needed, and security is already set up to scan HTTP traffic.
[0] Not a compliment
Most recently, HTTP/2 has become a concern that HTTP servers and clients have required substantial work to implement, but it is easy to say this is a separate protocol from HTTP, because even though it shares the same ports, a client that doesn't speak HTTP/2 when speaking to an HTTP server will not have to deal with them.
HTTP/1.1 wasn't like that, and neither was HTTP/1.0.
The original HTTP "0.9" was really a lot like finger: You would open a port, send a single line identifying the resource you wanted, and then the content would come back, and the connection would close. HTTP/1.0 added headers and some (text-based) framing to this, and fortunately there weren't many clients to upgrade.
Sometime in HTTP/1.0 people started talking about "pipelining" and the need to change the protocol to support this. The "Connection" header was introduced to identify this change - no other header had ever before meant anything to the web server (except when acting in some capacity as an application header), and misunderstanding the Connection header led to hung clients and slow response. This was made more annoying when the defaults changed for HTTP/1.1 -- now the "new" protocol was the default, and thus hung even more clients. I personally find this very funny because there is absolutely no need for a "pipelining" protocol- sockets are actually quite cheap, but most of the http server implementations and most of the http client implementations were badly written, and it may have been difficult to do better (assuming they knew how to do better) -- and so regardless, what was once an HTTP-compliant implementation was suddenly not.
HTTP/1.1 also introduced an "Upgrade" header, which was a kind of "trap door" to add extensions-- hopefully to avoid this kind of problem in the future, but it is complex, and many HTTP implementations simply added support for the "Connection" header and were find for a couple decades where today we are still shaking out clients that don't support Upgrade properly (and never noticed because servers vary on when they use it).
These "extensions" are the sort that everyone had to cope with- and because the protocol was carelessly defined, it was easy for implementations to get it wrong in a subtle way. Most of the other extensions (e.g. DAV, CONNECT, etc) are much easier to ignore simply because they're more "obviously" an extension.
> I think HTTP only really won because of those (HTML/CSS/JS).
HTTP won for a lot of reasons, and being easy to implement "mostly (or sufficiently) right" is a huge factor that I don't think should be ignored: Yes, many clients got it wrong and noticed years later, but "fixing" those broken clients was pretty easy, and the fact that people don't have to start over to gain increased compatibility or features is attractive in a way that should be studied by protocol designers trying to invent the next amazing thing.
this can't be stressed enough. Even many well known sites have a setup where their internet facing sever talks HTTP/2 but the backend is HTTP/1.1.
This protocal downgrade into the backend opens you up to a world of pain like cache poisoning and request smuggling which are also really hard to detect unless you know what you're looking for. And seeing how common it is, I wonder if it wouldn't have been safer to not call it HTTP/2 but a totally different name, just so people understand the danger they are in by thinking that there is any kind of safe interoperability between them.
https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
Only a few of those existed in the 1.0 spec. The rest evolved in practice. You can add your own without asking anyone else. Libraries don't have to be changed. Your payloads are your business. Encodings are flexible and negotiable.
> i think HTTP only really won because of those.
It's proven to be a predictable, stable, extensible, compatible, generic information exchange protocol. If it's won, it's because of that.
For example, WebDAV is a set of extensions to HTTP.
And in my opinion cross origin resource sharing headers could be considered an extension too maybe.
it is a protocol for a specific purpose, and because it has that specific purpose, it was used for that, and desired for that. http can do it, but without the constraints, of course nobody will use it for reinventing finger.
From an earlier post:
https://news.ycombinator.com/item?id=13519489
NBS TIP: 301-948-3850
I dialed it enough times that I still remember it. Much thanks to Bruce of "Bruce's NorthStar" BBS in Virginia for that phone number. [1]
MIT-MC: @L 236
MIT-AI: @L 134
MIT-DM: @L 70
MIT-ML: @L 198
Anyone remember how to do a TIP-to-TIP link, as documented on page 5-4 of the "Users Guide to the Terminal IMP" [2], by connecting an input and output socket of one TIP to an input and output socket of another TIP, through an unsuspecting host, so you could chat back and forth directly between two TIP dial-ups, without actually logging into the host?
It went something like @HOST #, @SEND TO SOCKET #, @RECEIVE FROM SOCKET #, @PROTOCOL BOTH, making sure the sockets were different parity so as not to violate the Anita Bryant clause with homosocketuality. [3]
You could also add the octal device port number of any other TIP user on your same TIP after the @ and before the command, to execute those commands on their session. (See page 5-7, "Setting Another Terminal's Parameters".) BBN wrote such great documentation and would mail copies of it for free to anyone who asked (that's how I got mine), you couldn't even call it security by obscurity!
The "ARPANET" episode of "The Americans" really missed the boat about how easy it was to break into the ARPANET. I didn't even have to kill anyone! [3] [4] Makes me wonder about the part about squeezing your anus... [5]
What was your uname?
-A2DEH
[1] https://games.slashdot.org/comments.pl?sid=242967&cid=196819...
[2] https://archive.org/details/bitsavers_bbntipADA0eTerminalIMP...
[3] https://news.ycombinator.com/item?id=12422813
[4] https://en.wikipedia.org/wiki/Arpanet_(The_Americans)
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.
I remember when I was earlier in my career and more specialized on implementing weirdo protocols hearing that HTTP was going to replace all the existing protocols. I was appalled; it seemed absurd, like suggesting Word .DOC was going to replace all text files.
But for the most part, the people saying that were right, and we are better off for it. The thing about a lot of those purpose-built protocols, even the "important" ones like DNS and most especially infrastructure stuff like SNMP, is that they are pretty dumb, the product of their time and thus, by construction, deprived of several decades of systems learning.