Comment by guerrilla
5 years ago
You didn't make an argument for why it's a silly protocol. You didn't make an argument for why it is worse in every possible way than HTTP. You didn't make an argument for why we're better off having replaced everything with HTTP. You didn't make any arguments about they they are "pretty dumb."
Your entire post amounts to "I like HTTP" and "old stuff bad."
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.
> 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.
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.
[1] https://news.ycombinator.com/item?id=27980192
The "decentralization" of SMTP comes from the high level architecture of store-and-forward. It has very little to do with the protocol, which could be expressed more effectively and cleanly on HTTP2 or HTTP3 (it won't be, but should) without risking any of its "openness".
6 replies →
I've done POP3 and SMTP and they didn't seem TOO bad but those were just toy implementations which didn't have to work in the real world and I gather things have gotten pretty complex and ugly since then. What would you suggest to replace e-mail while retaining its flexibility?
SMTP doesn’t really have a universally agreed way of handling authentication, error handling nor even encryption. There are several standards floating about, many of which are little more than pseudo-standards.
> 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.
6 replies →
You might like TMTP from the mnm open source project (my work).
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.
The way I read it - finger protocol is a small rusty bike; whereas http by now is a fancy sports car. (Heck if we are talking http/2 or 3 it’s a damn flying car at that)
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...
I don't think that analogy holds. Let's assume you can still publish a perfectly fine (for 2021) web page with strict HTTP/1.1 - I think you can. It's very flexible and unchanged since its publication.
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).
3 replies →
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.
The burden of proof is always on the person making a claim. I've made no claim on this subject. I haven't even entirely formed my opinion on this and am not even playing Devil's advocate. The point of my post was to try to improve the quality of the discussion here. Unsupported random opinions aren't generally relevant to strangers.
Unsupported random opinions are the lifeblood of internet forums, not that the comment was really that much of an unsupported random opinion. Strangers do not owe you presentation of their views to your exacting specifications. It's perfectly fine to be confused by things they say and it's perfectly fine to ask them what they meant.
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.
Completely agree. Also dismissing a post as 'stupid' does not quite sound good to me. I mean, probably we have better arguments to dismiss a particular post!
This has become a meta-debate, but I'd argue that the burden of proof is on anyone who wants something. If the thing you want is to get to the bottom of a question, then it's your own desire which has imposed that burden on you.
If you want something, it would be a shame if you didn't get it because an internet proponent failed to detail their arguments.
6 replies →