Protocols that have not changed in the last 30 years(dmitryelj.medium.com)
dmitryelj.medium.com
Protocols that have not changed in the last 30 years
https://dmitryelj.medium.com/tired-of-the-modern-web-discover-some-retro-protocols-you-still-can-use-today-30bbca48d3f2
170 comments
https://archive.is/eGqxU
An even more noteworthy protocol is MIDI[1], which has been virtually unchanged since its introduction in 1981, and is still the way that electronic musical instruments and software talk to each other.
MIDI-over-USB has been popular for a while, but we're seeing a resurgence of "classical" MIDI over serial with the current synthesizer renaissance.
And of course it's all the same on the software side.
Note on:
[1] https://en.wikipedia.org/wiki/MIDI
MIDI-over-USB has been popular for a while, but we're seeing a resurgence of "classical" MIDI over serial with the current synthesizer renaissance.
And of course it's all the same on the software side.
Note on:
[1] https://en.wikipedia.org/wiki/MIDI
Actually, this kind of a collective lie perpetrated in the synth community. MIDI's version number never changed from 1.0, but it has had numerous revisions, including LSB+MSB CC values, NRPN and RPN, General MIDI definitions, MIDI Show control, MIDI Machine control, MTC, MIDI file formats, etc. etc. And of course recently MPE. The original version was quite primitive.
I'm looking at the so-called "1.0 Specification" circa 1995, and it's document version 4.2.
I'm looking at the so-called "1.0 Specification" circa 1995, and it's document version 4.2.
Bad timing, MIDI 2.0 has been officially published (almost exactly) 2 years ago.
https://www.midi.org/specifications/midi-2-0-specifications
https://www.midi.org/specifications/midi-2-0-specifications
I'm not sure this counts. Their similarity in name notwithstanding, MIDI 2.0 is explicitly a different protocol from MIDI 1.0. It's not meant to replace it, but to exist in parallel with it. Which is good because I suspect it's doomed. Anyway, MIDI 1.0 is still a standard protocol.
MIDI 2.0 is the IPv6 of synths. The installed base of original MIDI is huge and the advantages of 2.0 are not immediately obvious, unless you have very specific needs such as microtonality. It might take 10 years for 2.0 to reach critical mass, if all vendors adopt it _en masse_, but there is no reason for it to "fail" outright.
I can think of many reasons why MIDI 2.0 might be advantageous. But microtonality? Why? MIDI 1.0's MTS supports everything Scala can throw at it, doesn't it?
I used microtonality as an example. Yes, it can be done with MIDI 1.0 but it's a hack whereas with MIDI 2 it's built-in. Actually, you could probably emulate much of MIDI 2 functionality using MIDI 1 but it would just become a new protocol over an old one at some point.
I'm confused. MTS is quite exhaustive on MIDI 1.0. How is microtonality in 1.0 a hack compared to what's being provided in 2.0?
There are obviously a number of 2.0 features that are much more advanced than 1.0 (MIDI is primitive). But MTS is actually pretty good and not a hack.
There are obviously a number of 2.0 features that are much more advanced than 1.0 (MIDI is primitive). But MTS is actually pretty good and not a hack.
2.0 is already supported by Logic and I suspect that Midi 2.0 support will be a good marketing item for midi controllers. So we’ll see but I think its prospects better than IPv6
It will take some years. As of now no bigger DAW supports MIDI 2.0 AFAIK, which is also because almost no 2.0 devices exist (Roland's A 88 MKII is the only one I know of).
"noteworthy", ha. I see what you did there :)
Happy to see Gopher listed! We even have a HN portal on Gopher which is pretty well suited for the folder listing format.
https://github.com/michael-lazar/hn-gopher
https://github.com/michael-lazar/hn-gopher
so happy to see that michael lazar wrote this. he also wrote rtv, a terminal reddit viewer, whose fork (tuir) i still use today.
Anyone interested in using old protocols should check out Project Gemini.
https://gemini.circumlunar.space/
It's still obviously very small, but Gemini space is growing.
https://gemini.circumlunar.space/
It's still obviously very small, but Gemini space is growing.
For years I wondered about the insanity of the FTP protocol. Why take random ports at both sides? Did they hate firewalls?
Some day, someone explained this allows for a client(with low bandwith) to setup a transfer between 2 servers(high bandwith) with the data not moving through the client. I've never seen this usage and don't know any ftp package supporting this, but it's pretty neat nevertheless.
Some day, someone explained this allows for a client(with low bandwith) to setup a transfer between 2 servers(high bandwith) with the data not moving through the client. I've never seen this usage and don't know any ftp package supporting this, but it's pretty neat nevertheless.
FTP predates full-duplex. You simply could not receive and transfer on the same port, so two were opened for each task. FTP is a protocol from the 1970s before TCP/IP existed. It has a lot of warts and really shouldn't be used on the internet anymore. :)
"Before TCP/IP" = NCP.
> The original specification for the File Transfer Protocol was written by Abhay Bhushan and published as RFC 114 on 16 April 1971. Until 1980, FTP ran on NCP, the predecessor of TCP/IP.[2] The protocol was later replaced by a TCP/IP version, RFC 765 (June 1980) and RFC 959 (October 1985), the current specification.
* https://en.wikipedia.org/wiki/File_Transfer_Protocol
Unlike TCP or UDP, NCP was not duplex:
> NCP preceded the Transmission Control Protocol (TCP) as a transport layer protocol used during the early ARPANET. NCP was a simplex protocol that utilized two port addresses, establishing two connections, for two-way communications. An odd and an even port were reserved for each application layer application or protocol. The standardization of TCP and UDP reduced the need for the use of two simplex ports for each application down to one duplex port.[1]
* https://en.wikipedia.org/wiki/Network_Control_Program
So the original transport layer that FTP relied on necessitated two ports, and when the move to a newer transport layer occurred the use of two ports was carried over for simplicity's sake. And several decades later that design still exists.
> FTP needs two ports (one for sending and one for receiving) because it was originally designed to operate on Network Control Program (NCP), which was a simplex protocol that utilized two port addresses, establishing two connections, for two-way communications. An odd and an even port were reserved for each application layer application or protocol.
* https://en.wikipedia.org/wiki/File_Transfer_Protocol
Per RFC 114, responses from the server are considered a data type: when a user sends a command to the server, sometimes the response is a status update ('MKDIR successful'†) and sometimes the response is the requested file.
The data structure of the response has fields to say what's coming back on the data channel for the requested transaction.
† MKDIR was not a command, just using it as an modern example.
> The original specification for the File Transfer Protocol was written by Abhay Bhushan and published as RFC 114 on 16 April 1971. Until 1980, FTP ran on NCP, the predecessor of TCP/IP.[2] The protocol was later replaced by a TCP/IP version, RFC 765 (June 1980) and RFC 959 (October 1985), the current specification.
* https://en.wikipedia.org/wiki/File_Transfer_Protocol
Unlike TCP or UDP, NCP was not duplex:
> NCP preceded the Transmission Control Protocol (TCP) as a transport layer protocol used during the early ARPANET. NCP was a simplex protocol that utilized two port addresses, establishing two connections, for two-way communications. An odd and an even port were reserved for each application layer application or protocol. The standardization of TCP and UDP reduced the need for the use of two simplex ports for each application down to one duplex port.[1]
* https://en.wikipedia.org/wiki/Network_Control_Program
So the original transport layer that FTP relied on necessitated two ports, and when the move to a newer transport layer occurred the use of two ports was carried over for simplicity's sake. And several decades later that design still exists.
> FTP needs two ports (one for sending and one for receiving) because it was originally designed to operate on Network Control Program (NCP), which was a simplex protocol that utilized two port addresses, establishing two connections, for two-way communications. An odd and an even port were reserved for each application layer application or protocol.
* https://en.wikipedia.org/wiki/File_Transfer_Protocol
Per RFC 114, responses from the server are considered a data type: when a user sends a command to the server, sometimes the response is a status update ('MKDIR successful'†) and sometimes the response is the requested file.
The data structure of the response has fields to say what's coming back on the data channel for the requested transaction.
† MKDIR was not a command, just using it as an modern example.
Funnily enough, the even/odd sendr/receiver reservation, and duplex optionality, have both made a comeback in QUIC :) Albeit with stream ids rather than ports.
Many early protocols were designed under the basic assumption that any two hosts on a network could initiate connections to each other. This was, after all, the fundamental concept around which early computer networks were designed... as networks of equal peers.
Unfortunately, this assumption has failed the test of time, as the "peer to peer" nature of computer networks has been fundamentally degraded due to widespread adoption of a more strict client-server model. Today, it is mostly not true that any two internet hosts can intiate connections with each other, and while seldom phrased this way the reality is so deeply embedded in our understanding of the internet that protocols designed under this assumption, while common, seem absurd. There are numerous reasons for this that range from security concerns to IPv4 exhaustion to the simple practicalities of the way that computer networks entered widespread usage.
We should all wonder: is it a good thing that we have abandoned the peer to peer nature of networks?
Unfortunately, this assumption has failed the test of time, as the "peer to peer" nature of computer networks has been fundamentally degraded due to widespread adoption of a more strict client-server model. Today, it is mostly not true that any two internet hosts can intiate connections with each other, and while seldom phrased this way the reality is so deeply embedded in our understanding of the internet that protocols designed under this assumption, while common, seem absurd. There are numerous reasons for this that range from security concerns to IPv4 exhaustion to the simple practicalities of the way that computer networks entered widespread usage.
We should all wonder: is it a good thing that we have abandoned the peer to peer nature of networks?
> Unfortunately, this assumption has failed the test of time
I can't agree that it has failed the test of time. Peer to peer is still the superior solution to nearly every problem.
What happened is that the Internet became commercialized and now profit runs everything. Centralized solutions are better at: injecting advertising, tracking users, requiring subcriptions, ensuring lock-in and preventing interoperability. None of these are good qualities for anyone involved, except the company making the profit. But these companies now rule the internet, so they hate peer to peer.
I can't agree that it has failed the test of time. Peer to peer is still the superior solution to nearly every problem.
What happened is that the Internet became commercialized and now profit runs everything. Centralized solutions are better at: injecting advertising, tracking users, requiring subcriptions, ensuring lock-in and preventing interoperability. None of these are good qualities for anyone involved, except the company making the profit. But these companies now rule the internet, so they hate peer to peer.
There are many reasons other than commercial motive that have eroded the P2P nature of the internet. The single most prominent is security. Improved network hardening practices by OS vendors have mostly eliminated the historic problem that computers directly accessible to the internet were quickly compromised (SMB on Windows hosts used to be a huge problem this way), but for years in the late '90s to early '00s directly connecting computers to the internet was considered a very problematic practice due to the number of worms. The more durable problem has been DOS. Home networks are, for structural reasons, extremely vulnerable to denial of service attacks and it's difficult to fix that. The best way to fix it is to be extremely conservative with inbound connections by dropping all of them, and indeed that's what home networks do. For many years NAT was frequently described first as a security feature, although its security benefits were purely incidental. DOS attacks on home networks remain surprisingly common in certain circles such as multiplayer videogames, and have resulted in a climate in which multiplayer videogames are expected to actively conceal the network identity of other participants.
Yes, this is basically all an accident of history, but so is everything else about computing. There's no real sense in which the original "network of peers" IP concept has been successful since IP spread beyond the realm of the National Science Foundation. It is possible to build systems which are far more resistant to these problems but it's difficult to begin with, and on top of that adoption would require turning the battleship that is the internet around. We're sort of stuck with the situation we found ourselves in, which is that we build peer-to-peer system by piling a few hacks on top of IP to enable peer-to-peer application layer usage.
Yes, this is basically all an accident of history, but so is everything else about computing. There's no real sense in which the original "network of peers" IP concept has been successful since IP spread beyond the realm of the National Science Foundation. It is possible to build systems which are far more resistant to these problems but it's difficult to begin with, and on top of that adoption would require turning the battleship that is the internet around. We're sort of stuck with the situation we found ourselves in, which is that we build peer-to-peer system by piling a few hacks on top of IP to enable peer-to-peer application layer usage.
Totally agreed. Just hope the peer 2 peer survived for the time to come. Internet promised of decentralization is not realized. But still we can dream. As long as we can, peer2peer will come.
> Internet promised of decentralization is not realized.
Just to point out, it was realized. In the early days everyone ran their services (SMTP, NNTP, later HTTP, finger, telnet, etc, etc) locally in a 100% distributed fashion.
It's just that then the commercial interests showed up and ruined everything with centralization, ads, spam, tracking.
Just to point out, it was realized. In the early days everyone ran their services (SMTP, NNTP, later HTTP, finger, telnet, etc, etc) locally in a 100% distributed fashion.
It's just that then the commercial interests showed up and ruined everything with centralization, ads, spam, tracking.
it is mainly the web that has been commercialized.
Getting acces to the internet (AKA, getting an IP block and routes to connect to others) has always been sort of centralized, mainly because ip blocks need to be handed out from a single source of truth to prevent ip address collisions.
Still, the peer to peer nature of interconnecting still exists, there is no hierachical information source which defines routes across the internet. This is all decentralized and done by doing peering between parties with BGP (And other routing protocols).
Doing this yourself is possible, although rather hard and niche for a consumer. But getting an AS number is doable, and getting an IPV6 block is even easier. IPv4 is hard to come by though..
Getting acces to the internet (AKA, getting an IP block and routes to connect to others) has always been sort of centralized, mainly because ip blocks need to be handed out from a single source of truth to prevent ip address collisions.
Still, the peer to peer nature of interconnecting still exists, there is no hierachical information source which defines routes across the internet. This is all decentralized and done by doing peering between parties with BGP (And other routing protocols).
Doing this yourself is possible, although rather hard and niche for a consumer. But getting an AS number is doable, and getting an IPV6 block is even easier. IPv4 is hard to come by though..
Unfortunately even the peer to peer nature of BGP has proven a problem due to BGP hijacking. Most solutions to this problem such as MANRS rely in part of semi-centralization as major ISPs must coordinate with eachother through bureaucratic channels and then police the BGP behavior of their customers, creating a sort of BGP oligopoly.
It is not good. Hopefully IPv6 is adopted globally soon.
IPv6 only ensures each device has a globally unique IP address. It does not ensure there is a firewall between one of those devices and their ISP.
NAT’s might go away under IPv6 but firewall policies with “default deny inbound connections” will almost certainly not.
NAT’s might go away under IPv6 but firewall policies with “default deny inbound connections” will almost certainly not.
I think there are efforts underway to build a more p2p internet. I've been trying to find the time to build some small experiment using https://hypercore-protocol.org/ (no affiliation).
There are many protocols which are "logically" P2P, but actually using the network in a P2P fashion is a different matter and much more difficult. Hypercore, for example, uses a "distributed hole-punching" architecture in which clients that want to communicate with each other discover each other using a DHT and then preemptively send UDP traffic to each other in order to cause NAT appliances on both ends to create connection tracking entries. Unfortunately this assumes that the DHT is up and running to serve as a "meet-me" point for these nodes to know about each other in the first place. In order for this to happen a DHT member needs to "bootstrap" by... contacting a "bootstrap node" which is basically a special centralized Hyperswarm server with a conventional DNS address and capability to accept inbound connections.
This possibly surprising fact, that at the core of the P2P distributed system there is a centralized client-server service that provides the initial discovery information to begin participating, is pretty much universal to P2P systems because of the limitations the internet imposes. Removing this requirement would require a significantly more P2P-architected internet that allowed, for example, participation in arbitrary multicast groups from residential ISPs. There are both theoretical and practical (but mostly practical) challenges to doing this.
In other words, the way the internet works, the only real way to begin to participate in a P2P internet protocol is to connect to a centralized service to provide initial peer hints. This is commonly referred to as an "introducer" or "bootstrap node" or "peer helper" or other terms depending on the P2P system. Hypercore and the Hyperswarm P2P network it relies on are actually unusually advanced in how much they minimize the need for an introducer, to the extent that a Hyperswarm node can completely forget about the introducer (it could go down) after initial setup and it will probably continue to work okay although there is a probabilistically small risk of a split-brain scenario. Older P2P protocols like Bittorrent and Tor have a greater dependency on centralized introducers and cannot operate without them even after initial startup (with caveats such as Bittorrent's support for Kademlia DHT, the same underlying DHT protocol used by Hyperswarm, which is in use by some Bittorrent nodes but not all for various reasons).
For hypercore specifically the introducers are bootstrap1.hyperdht.org through bootstrap3.hyperdht.org. These are basically hardcoded into your client.
This possibly surprising fact, that at the core of the P2P distributed system there is a centralized client-server service that provides the initial discovery information to begin participating, is pretty much universal to P2P systems because of the limitations the internet imposes. Removing this requirement would require a significantly more P2P-architected internet that allowed, for example, participation in arbitrary multicast groups from residential ISPs. There are both theoretical and practical (but mostly practical) challenges to doing this.
In other words, the way the internet works, the only real way to begin to participate in a P2P internet protocol is to connect to a centralized service to provide initial peer hints. This is commonly referred to as an "introducer" or "bootstrap node" or "peer helper" or other terms depending on the P2P system. Hypercore and the Hyperswarm P2P network it relies on are actually unusually advanced in how much they minimize the need for an introducer, to the extent that a Hyperswarm node can completely forget about the introducer (it could go down) after initial setup and it will probably continue to work okay although there is a probabilistically small risk of a split-brain scenario. Older P2P protocols like Bittorrent and Tor have a greater dependency on centralized introducers and cannot operate without them even after initial startup (with caveats such as Bittorrent's support for Kademlia DHT, the same underlying DHT protocol used by Hyperswarm, which is in use by some Bittorrent nodes but not all for various reasons).
For hypercore specifically the introducers are bootstrap1.hyperdht.org through bootstrap3.hyperdht.org. These are basically hardcoded into your client.
Not totally true as peer to peer can use a decentralised protocol to find peer.
Is there a “centralised” server under Bitcoin? Or is it you can bootstrapping even manually then the peer to peer network can go ahead to find more peer …
The problem of “centralisation” is not due to the need of finding peer. It is in the edge. You control the isp you control all. See China.
How to break this edge issue … very hard.
Is there a “centralised” server under Bitcoin? Or is it you can bootstrapping even manually then the peer to peer network can go ahead to find more peer …
The problem of “centralisation” is not due to the need of finding peer. It is in the edge. You control the isp you control all. See China.
How to break this edge issue … very hard.
> Is there a “centralised” server under Bitcoin?
Yes, Bitcoin clients use a semi-hardcoded list of "seed peers" that they look up via DNS and connect to first. Peer discovery proceeds from there using P2P methods. One example is seed.bitcoin.sipa.be, there are several set in the source tree of bitcoin core. Each of these "seed" DNS names provides a list of records that are known good Bitcoin nodes. This DNS method replaced Bitcoin's original method, dating back to Nakamoto, which was to connect to a hardcoded IRC server and then join a hardcoded channel where Bitcoin nodes advertised their presence. There is no real theoretical advantage to the DNS method but it is simpler and DNS is far less likely to be blocked than IRC.
As in most distributed/P2P systems, the Bitcoin DNS seeds are somewhat integrity sensitive. Normally the Bitcoin network cannot enter a "split-brain" state (e.g. two independent and equally valid blockchains) because there are a large number of nodes which are strongly interconnected, preventing any substantial number of Bitcoin nodes being unaware of blocks that other nodes are aware of (in actuality Bitcoin enters a "split-brain" state on a regular basis, but as long as nodes are aware of both "valid" blockchains they have an agreed upon convention to select a single blockchain head as valid). But this is only true of nodes which are already participating. When a new Bitcoin node starts for the first time, it has no way to discover any other nodes besides the DNS seeds. In theory, if the DNS seeds were malicious, they could provide a list of nodes which were complicit in an attack by intentionally not forwarding any information about some blocks or advertisements of nodes which are aware of those blocks. In other words, in practice the cost of a sybil attack is actually reduced to the number of nodes directly advertised by the DNS seeds, but only for new users and only if the DNS seeds are complicit. In practice the former is a massive limitation and the Bitcoin project allows only trusted individuals to operate DNS seeds in order to mitigate the latter, so the issue is not that big.
The problem is that there actually is no decentralized way to initially discover peers on the internet. Imagine if you wanted to implement a peer-to-peer information flow over the telephone system. If you have a list of telephone numbers of participants you can come up with all kinds of schemes. But what about when you very first join? You don't know any numbers to try. Randomly calling every phone number in order isn't feasible. You need to have some kind of "point of contact" to first discover other peers or you simply have no one to call. There are various terms for this, I like "introducer" but Bitcoin uses "seed" as do some others. Every decentralized system that operates over the internet has a semi-centralized introducer mechanism somewhere deep down.
There are several theoretical mechanisms such as multicast groups, but none of these actually work across the internet. They do usually work across local networks (and are used by things like Bonjour), but in the majority of cases when a user wants to bootstrap a P2P system there is no other peer on the same local network.
Yes, Bitcoin clients use a semi-hardcoded list of "seed peers" that they look up via DNS and connect to first. Peer discovery proceeds from there using P2P methods. One example is seed.bitcoin.sipa.be, there are several set in the source tree of bitcoin core. Each of these "seed" DNS names provides a list of records that are known good Bitcoin nodes. This DNS method replaced Bitcoin's original method, dating back to Nakamoto, which was to connect to a hardcoded IRC server and then join a hardcoded channel where Bitcoin nodes advertised their presence. There is no real theoretical advantage to the DNS method but it is simpler and DNS is far less likely to be blocked than IRC.
As in most distributed/P2P systems, the Bitcoin DNS seeds are somewhat integrity sensitive. Normally the Bitcoin network cannot enter a "split-brain" state (e.g. two independent and equally valid blockchains) because there are a large number of nodes which are strongly interconnected, preventing any substantial number of Bitcoin nodes being unaware of blocks that other nodes are aware of (in actuality Bitcoin enters a "split-brain" state on a regular basis, but as long as nodes are aware of both "valid" blockchains they have an agreed upon convention to select a single blockchain head as valid). But this is only true of nodes which are already participating. When a new Bitcoin node starts for the first time, it has no way to discover any other nodes besides the DNS seeds. In theory, if the DNS seeds were malicious, they could provide a list of nodes which were complicit in an attack by intentionally not forwarding any information about some blocks or advertisements of nodes which are aware of those blocks. In other words, in practice the cost of a sybil attack is actually reduced to the number of nodes directly advertised by the DNS seeds, but only for new users and only if the DNS seeds are complicit. In practice the former is a massive limitation and the Bitcoin project allows only trusted individuals to operate DNS seeds in order to mitigate the latter, so the issue is not that big.
The problem is that there actually is no decentralized way to initially discover peers on the internet. Imagine if you wanted to implement a peer-to-peer information flow over the telephone system. If you have a list of telephone numbers of participants you can come up with all kinds of schemes. But what about when you very first join? You don't know any numbers to try. Randomly calling every phone number in order isn't feasible. You need to have some kind of "point of contact" to first discover other peers or you simply have no one to call. There are various terms for this, I like "introducer" but Bitcoin uses "seed" as do some others. Every decentralized system that operates over the internet has a semi-centralized introducer mechanism somewhere deep down.
There are several theoretical mechanisms such as multicast groups, but none of these actually work across the internet. They do usually work across local networks (and are used by things like Bonjour), but in the majority of cases when a user wants to bootstrap a P2P system there is no other peer on the same local network.
FlashFXP was the most used client in the late 90s Warez scene because of the easy implementation of fxp. Private internet was still 56k or up to 128k with ISDN. Most of the scene ftp sites were hosted in universities. You transfered files from the US to a local university went into the library and downloaded it on a drive. What a trip down memory lane.
Not sure if that is why the multiport setup, but the process you are describing is called FXP[0]. I used it quite a bit back in the late 90s.
0: https://en.m.wikipedia.org/wiki/File_eXchange_Protocol
0: https://en.m.wikipedia.org/wiki/File_eXchange_Protocol
[deleted]
Control channel and data channel makes a lot of sense. And is arguably a simpler and more efficient way to transfer data. You set up transfer via one channel and then you don't need overhead of extra headers and other stuff on the data itself. Compare to HTTP 1.1 for example where you often carry bunch of headers around.
FXP was the thing that made (and to some extent still makes) the warez scene possible.
There were specific people whose main role was that they had access to one source server and one or more target servers. Without spending more than a few kB of their own bandwidth they could transfer files between big servers easily.
There were specific people whose main role was that they had access to one source server and one or more target servers. Without spending more than a few kB of their own bandwidth they could transfer files between big servers easily.
I'm sure it played an important role, but a[n optionally restricted] telnet account could do the same, right?
I remember doing this, transferred a few large (at the time) files from one server to another. There were definitely some clients which had this feature, but I cannot remember which one I was using specifically. If I remember correctly, I did this because the servers in question were some "free" webhosting things where you'd only get ftp access (along with http, of course), but no shell.
I also remember talking to some people back in the day who regularly did that supposedly. Members of some minor warez group who uploaded new releases to one server and then used FTP to directly transfer files from one server to another to create mirrors. Then retransfer from the two servers that now had it to even more servers for some exponential growth.
I also remember talking to some people back in the day who regularly did that supposedly. Members of some minor warez group who uploaded new releases to one server and then used FTP to directly transfer files from one server to another to create mirrors. Then retransfer from the two servers that now had it to even more servers for some exponential growth.
The simpler explanation is nobody was using firewalls when it was invented.
Throughout most of the 90's, many people had unfiltered IPv4 at their desktops. I had dedicated internet at home: no firewall... at work, same thing.
100%.
When Microsoft made Windows Firewall opt-out with Windows XP SP2, it caused SOOOOOOO many headaches. On one hand, no more rogue porn pop-ups during work! On the other hand, nobody knew what a firewall was and why trying to use Skype or whatever was such a PITA.
It’s a bit of a shame that one simply cannot use the Internet without a firewall of some kind (unless you really like getting cryptoransomed in, like, 30 seconds)
When Microsoft made Windows Firewall opt-out with Windows XP SP2, it caused SOOOOOOO many headaches. On one hand, no more rogue porn pop-ups during work! On the other hand, nobody knew what a firewall was and why trying to use Skype or whatever was such a PITA.
It’s a bit of a shame that one simply cannot use the Internet without a firewall of some kind (unless you really like getting cryptoransomed in, like, 30 seconds)
Indeed. Through the 90s at $JOBS, my desktop workstation has a public IP address and was directly on the Internet without any kind of firewalling.
Sendmail ran locally and I'd send/receive email to/from the world directly on my workstation. Same for FTP, HTTP, etc. That's how the Internet was originally intended to operate.
Sendmail ran locally and I'd send/receive email to/from the world directly on my workstation. Same for FTP, HTTP, etc. That's how the Internet was originally intended to operate.
i doubt firewalls even existed in any capacity at this time.
routing packets in and of itself was already quite an CPU intensive task, analysing and blocking packets would be a whole other ballgame during the early days.
Early firewalls, like Checkpoint for example, did exist. They were, however, not widely used outside of the enterprise. I worked for several small ISPs and typically only larger enterprises even bothered. Small companies and even universities had public IP on the desktops.
Most people with 486 and Pentium used Iptables.
Iptables was the third generation of Linux firewalling: ipfwadm, ipchains, iptables, nftables, ...
ipfwadm was in Linux around 1996.
> For years I wondered about the insanity of the FTP protocol. Why take random ports at both sides? Did they hate firewalls?
Simpler answer: because Firewalls didn't exist at the time!
Simpler answer: because Firewalls didn't exist at the time!
https://en.wikipedia.org/wiki/FlashFXP supports it.
Another one of those weird Wikipedia trip articles that starts out rambling in a way that would never pass the “no original research” test today, then hits you out of the blue in the last paragraph with a matter-of-fact statement.
LFTP supports this on the CLI:
* https://en.wikipedia.org/wiki/Lftp
* http://lftp.yar.ru/features.html
See also:
* https://en.wikipedia.org/wiki/Comparison_of_FTP_client_softw...
* https://en.wikipedia.org/wiki/Lftp
* http://lftp.yar.ru/features.html
See also:
* https://en.wikipedia.org/wiki/Comparison_of_FTP_client_softw...
> Did they hate firewalls?
What's a firewall? By that I mean, firewall wasn't a thing when FTP was designed.
What's a firewall? By that I mean, firewall wasn't a thing when FTP was designed.
You don't have to use old clunky protocols to escape the commercial web. Just don't visit commercial websites designed by collectives using JS libraries. Disable JS by default and leave a site when nothing displays. There is plenty of good web buried under all the commercial crap. We don't have to abandon HTTP.
That said, eternal-september.org is a great way to get back into usenet.
That said, eternal-september.org is a great way to get back into usenet.
What groups (besides the obvious specific tech focused ones) are worth going on? I'm able to get on via sdf.org but I never actually found any engaging discussion.
I've been posting intermittently to alt.cyberpunk, alt.startrek, and alt.irc for a handful of years. It's slow, maybe a post a week, but when things happen it's a place to talk. Gotta be the change you want to see.
Is it too late to create a version of the web that is just plain text (no markup)? After 25 years on the web, I'm starting to feel format fatigue so much that I actually cherish reading man pages and internet RFCs on the terminal (and even occasionally reading web pages on lynx).
> Is it too late to create a version of the web that is just plain text (no markup)?
Just do it and post a reference implementation of a server and a client (assuming this is the architecture that you want to use), and the protocol specifications somewhere.
Just do it and post a reference implementation of a server and a client (assuming this is the architecture that you want to use), and the protocol specifications somewhere.
This was done long ago. I forget the name, but there was a browser that only rendered the text parts. It was useful on slow modems or text-only screens.
Quite coincidentally, I found an example of just the type of experience I prefer in a neighboring HN post (SPADE): https://asciinema.org/a/bG7PPKj0AaJq087ZNPxSZwcCl
I did this just as a way to put an idea to code. It's very rough.
Web for cli only.
Web 0.5 https://tilde.pt/~fimdomeio/index2.html
I would make an important note on FTP: it’s not a secure protocol. The last time I cared about FTP, the recommendation was to move toward SFTP or FTPS for production/public environments for this reason.
It is not only insecure, but not specific enough on several aspects of the protocol, leading to implementation problems. It also doesn't do any error correction beyond TCP.
It is quite fast, however, compared to SFTP/SSH.
http://mywiki.wooledge.org/FtpMustDie
It is quite fast, however, compared to SFTP/SSH.
http://mywiki.wooledge.org/FtpMustDie
It's 100% not secure. I don't know much about FTPs, but I think I only trust sftp.
My understanding is that FTP/FTPS is analogous to HTTP/HTTPS but I left FTP for ssh long ago and never looked back.
correct, SFTP uses FTP over SSH
No. This is completely wrong in two different ways
First: The parent was talking about FTPS, which is the FTP protocol spoken over TLS, similar to how HTTPS can be HTTP/1.1 spoken over TLS
Second: SFTP is not FTPS, and it also isn't FTP spoken over SSH. Instead. SFTP is a protocol specifically for SSH which, like FTP, is concerned with file transfers, but matches what its authors actually wanted from file transfers in the modern era, rather the concerns FTP had decades ago.
First: The parent was talking about FTPS, which is the FTP protocol spoken over TLS, similar to how HTTPS can be HTTP/1.1 spoken over TLS
Second: SFTP is not FTPS, and it also isn't FTP spoken over SSH. Instead. SFTP is a protocol specifically for SSH which, like FTP, is concerned with file transfers, but matches what its authors actually wanted from file transfers in the modern era, rather the concerns FTP had decades ago.
not sure I fully understand your comment, I said correct as my first statement agreeing with the parent and thus your explaination (ie FTPS is FTP over TLS)
at what point did I mention that FTPS is SFTP??
my comment regarding SFTP was in reference to the parents comment
>but I left FTP for ssh long ago and never looked back.
but you're correct that >SFTP is a protocol specifically for SSH
at what point did I mention that FTPS is SFTP??
my comment regarding SFTP was in reference to the parents comment
>but I left FTP for ssh long ago and never looked back.
but you're correct that >SFTP is a protocol specifically for SSH
> at what point did I mention that FTPS is SFTP??
I had also understood your comment to mean that SFTP is "just FTP tunneled through SSH" (i.e. FTPS) rather than a redesigned protocol.
I had also understood your comment to mean that SFTP is "just FTP tunneled through SSH" (i.e. FTPS) rather than a redesigned protocol.
bad habit of mine to explain SFTP to non technical people. at a million mile high level
What nontechnical people?
SFTP does not use FTP. It is an independent design.
The connection speed varied from 1200 bits/s in the 80s to 56600 bits/s in the 90s
As my username will attest to, 300 bps modems were very common in the 80s. I got my first one in 1985.
As my username will attest to, 300 bps modems were very common in the 80s. I got my first one in 1985.
I took a LISP class in graduate school in the late 1980s, and dialed up to their VAX on a 300 baud modem from my commodore 64. Ah 40 character lines crawling across the TV/monitor. It felt powerful!
Does anyone remember internet relay chat, IRC, with its channels? It is still here today as well.
/me slaps erwincoumans around with a large trout
/whois herodoturtle
:)
mIRC users. Pfft.
I was 11, our home PC ran “Windows 3.11 for Workgroups”, and mIRC was my gateway to a career in software.
That, and reverse engineering GORILLA.BAS :-)
These days I use irssi, so am completely out of touch with mIRC.
Why the “Pfft”?
That, and reverse engineering GORILLA.BAS :-)
These days I use irssi, so am completely out of touch with mIRC.
Why the “Pfft”?
An echo of a narrow slice of time. For a while, you could /ctcp version a channel and ircII would outnumber mIRC 10:1 (then obviously, less as time went on) and mIRC didn't have any scripting capabilities at all (mIRC < 4, I think, maybe < 3) compared to pretty good scripting capabilities for ircII!
ircII scripting felt vaguely C inspired, and mIRC's scripting definitely felt foreign to the UNIX/IRC culture it got attached to. I never got seriously into scripting mIRC, and the mental model might have changed, but draft 1 of adding scripting into mIRC definitely had that Rasmus Lerdorf "I don't know how to make a language at all, I'm just making something work" feel, whereas ircII scripting felt vaguely coherent from a C-ish background.
Very old impressions, and mIRC scripting might've gotten good in later versions. The earliest versions of mIRC scripting definitely felt very weird.
ircII scripting felt vaguely C inspired, and mIRC's scripting definitely felt foreign to the UNIX/IRC culture it got attached to. I never got seriously into scripting mIRC, and the mental model might have changed, but draft 1 of adding scripting into mIRC definitely had that Rasmus Lerdorf "I don't know how to make a language at all, I'm just making something work" feel, whereas ircII scripting felt vaguely coherent from a C-ish background.
Very old impressions, and mIRC scripting might've gotten good in later versions. The earliest versions of mIRC scripting definitely felt very weird.
That was a mightily insightful comment, and one I wasn’t expecting. Thanks for sharing your experience.
Side note: I found the Rasmus analogy particularly relatable. I’ve been building in PHP for a little over 20 years now, and despite all the hate it gets around these parts, I remain a fan.
Side note: I found the Rasmus analogy particularly relatable. I’ve been building in PHP for a little over 20 years now, and despite all the hate it gets around these parts, I remain a fan.
Funnily enough, now probably biggest licensed, paying user of mirc is US DoD for use in C4 systems, with text messages on IRC handling things like arranging supporting fire...
...most of telco. Seriously, mainstream stuff is interesting and all, but there are hundreds of protocols needing a retrofit (or actually being re-encapsulated in TCP) in that industry.
When someone starts an article with a protocol which has been among the first to be forbidden/blocked/tracked-and-shutdown-at-source, when possible/firewalled on any organization network, for the last 10 years, then I don't know what'd be the incentive to read any further :-(
That's fine: it doesn't suit their needs. No protocol is meant to be all things to all people, and every organisation has its own security posture and its own environment.
I don't think any of that entails that FTP is somehow failing to fulfil its contract. Implementing transport encryption is not within its scope. It has to be run over a secure channel, which can easily be done with FTPS.
I don't think any of that entails that FTP is somehow failing to fulfil its contract. Implementing transport encryption is not within its scope. It has to be run over a secure channel, which can easily be done with FTPS.
Misleading title I think. I assumed these were protocols in wide use that did not require changing because they were so well designed. Instead, this is about old protocols that didn't change...because nobody uses them anymore.
That said, it is an interesting retro blast from the past. As someone who cut their teeth during the BBS and early days of the web, it always brings back nostalgia. Computers were just more fun back then IMO.
That said, it is an interesting retro blast from the past. As someone who cut their teeth during the BBS and early days of the web, it always brings back nostalgia. Computers were just more fun back then IMO.
I maintain a usenet subscription because the file transfer and search mechanisms are incredibly relevant today. There is a yuge amount of data still pushed around on the usenet. Which is not-so-coincedentally related to media formats and sizes (yarr)
No one uses newsgroups anymore? Hmm, well, I guess I don’t use them for their chatting purposes, but they are very much alive for file transfer.
[deleted]
Another article which mention both FTP and Dropbox. The infamous top comment on the Dropbox HN launch back is what led me down the rabbit hole of building a Dropbox like UI for FTP: https://github.com/mickael-kerjean/filestash
FTP is amazing on so many perspective. About a month ago, I crawled the entire IPv4 range looking for anonymous FTP and found about 200k of them. As I wanted to publish the results and provide a way to get through those servers, I ended up building crawlers but quickly stopped as the sheer amount of movies, series, music I found would have been more problems than it's worth.
FTP is amazing on so many perspective. About a month ago, I crawled the entire IPv4 range looking for anonymous FTP and found about 200k of them. As I wanted to publish the results and provide a way to get through those servers, I ended up building crawlers but quickly stopped as the sheer amount of movies, series, music I found would have been more problems than it's worth.
>As I wanted to publish the results and provide a way to get through those servers,
Lists of the contents of Anonymous FTP servers have been produced since at least the 1980s.
And in fact, they still exist:
http://fy.chalmers.se/OLDUSERS/ivi/ftpsites2.html
http://www.diam.unige.it/informatica/documentazione/httpd_do...
Back in the day, you'd download updated lists to find the stuff you were looking for. Because that was how you found stuff. Although there wasn't a lot of video or music out there on the public anon FTP servers.
That was before Archie[0] and Veronica[1] and, of course, websites.
Apparently, there was a discussion[2] about this here back in 2016, as well.
I have fond memories of wuarchive.wustl.edu, simtel20.army.mil[3] and a bunch of other FTP sites I can't remember 30+ years later.
A good topic. Thanks for posting it. Perhaps you should publish your list, or stand up an Archie server for it. I'd use it.
[0] https://en.wikipedia.org/wiki/Archie_(search_engine)
[1] https://en.wikipedia.org/wiki/Veronica_(search_engine)
[2] https://news.ycombinator.com/item?id=12523455
[3] https://en.wikipedia.org/wiki/Simtel
Lists of the contents of Anonymous FTP servers have been produced since at least the 1980s.
And in fact, they still exist:
http://fy.chalmers.se/OLDUSERS/ivi/ftpsites2.html
http://www.diam.unige.it/informatica/documentazione/httpd_do...
Back in the day, you'd download updated lists to find the stuff you were looking for. Because that was how you found stuff. Although there wasn't a lot of video or music out there on the public anon FTP servers.
That was before Archie[0] and Veronica[1] and, of course, websites.
Apparently, there was a discussion[2] about this here back in 2016, as well.
I have fond memories of wuarchive.wustl.edu, simtel20.army.mil[3] and a bunch of other FTP sites I can't remember 30+ years later.
A good topic. Thanks for posting it. Perhaps you should publish your list, or stand up an Archie server for it. I'd use it.
[0] https://en.wikipedia.org/wiki/Archie_(search_engine)
[1] https://en.wikipedia.org/wiki/Veronica_(search_engine)
[2] https://news.ycombinator.com/item?id=12523455
[3] https://en.wikipedia.org/wiki/Simtel
really interesting, thanks for commenting
They left out BGP, one of my favorite routing protocols! There's still a bunch of ancient routing protocols out there. They work pretty well, so I guess you can't argue with success.
Very true! Also another omission was "finger" - although I guess that isn't used so often these days..
bgp has changed a ton however. with new additions to the protocol happening nearly yearly.
Yup, even the BGP-4 RFC 4271 is from 2006 https://datatracker.ietf.org/doc/html/rfc4271
also, BGP-MP added so many new options with regards to NLRI that it can be used for many, many different use cases.
For instance, BGP can be used as an mac learning mechanism (EVPN), It can be used to communicate MPLS LSP's, it can even be used for source routing.
For instance, BGP can be used as an mac learning mechanism (EVPN), It can be used to communicate MPLS LSP's, it can even be used for source routing.
Newsgroups got pretty crazy with some of the uuencoded files people would post. That’s definitely an improvement. For a while there were warez groups with massive files split across a lot of posts.
Telnet text based muds are one of my favorite things we used to have. You’d telnet to a host and play a text based game where you’re trying to make progress walking through a world solving puzzles.
Telnet text based muds are one of my favorite things we used to have. You’d telnet to a host and play a text based game where you’re trying to make progress walking through a world solving puzzles.
> Newsgroups got pretty crazy with some of the uuencoded files people would post. That’s definitely an improvement. For a while there were warez groups with massive files split across a lot of posts.
I worked for a major Usenet provider for 20+ years.
The mechanisms for posting large binary files essentially created a separate application layer on top of the protocol. uuencode was replaced with yEnc, and the applications built in parity checking to handle the provider problems with missing articles. Article subjects were co-opted in semi-standard ways to allow applications to combine individual articles into files, but eventually, they just started posting files of unique message IDs (NZBs) to websites or specific groups, completely bypassing the need to even look at article lists. That ended up being a requirement anyway, because some groups got so big, readers could not realistically download lists of new articles anyway.
That is still the norm. Massive files are still split across 1000s of posts, and the most popular binary groups are now "dump" groups, where the only thing common about the posts is that they are binary files of some kind. What's crazy is that even though Usenet readership has declined, Usenet posting volumes have continued a very steady increase.
I worked for a major Usenet provider for 20+ years.
The mechanisms for posting large binary files essentially created a separate application layer on top of the protocol. uuencode was replaced with yEnc, and the applications built in parity checking to handle the provider problems with missing articles. Article subjects were co-opted in semi-standard ways to allow applications to combine individual articles into files, but eventually, they just started posting files of unique message IDs (NZBs) to websites or specific groups, completely bypassing the need to even look at article lists. That ended up being a requirement anyway, because some groups got so big, readers could not realistically download lists of new articles anyway.
That is still the norm. Massive files are still split across 1000s of posts, and the most popular binary groups are now "dump" groups, where the only thing common about the posts is that they are binary files of some kind. What's crazy is that even though Usenet readership has declined, Usenet posting volumes have continued a very steady increase.
It's been years and I still angry about yEnc, lol.
It suffers from all the same problems that UUEncode did, and that MIME had already solved. Using magic words in the body text as delineators, splitting parts using the subject line, it's terrible.
It suffers from all the same problems that UUEncode did, and that MIME had already solved. Using magic words in the body text as delineators, splitting parts using the subject line, it's terrible.
One protocol I didn’t see mentioned but I still use every day is IRC.
It’s one of the best ways to get new files today and been around since 1988.
It’s one of the best ways to get new files today and been around since 1988.
SMTP(1971), ETHERNET(1973), IP(1974), UDP(1980), TCP&DNS(1983), HTTP&BGP(1989), DHCP(1993)
Those are old, but they've been modified a lot over the years, including recently. TFA is about protocols that haven't changed in decades.
This article reminds us that the web is fundamentally democratic and inclusive. The best use of the web, retro or modern, is when ordinary people share with each other in the open and on the same level.
It's the commercialism and hierarchicalism that ruins everything.
It's the commercialism and hierarchicalism that ruins everything.
> This article reminds us that the web is fundamentally democratic and inclusive.
None of the protocols discussed in TFA have anything to do with the web. In my opinion, www was created with a strong server client model, and was not as "democratic" as some of the other protocols prevalent at that time.
None of the protocols discussed in TFA have anything to do with the web. In my opinion, www was created with a strong server client model, and was not as "democratic" as some of the other protocols prevalent at that time.
My long (long) term plan of my browser (https://wapps.app) is to bring us back to something similar to Gopher.
First I want to make browsing web apps feel as good as browsing an app. Then I want to make it better. To do that I want to 'translate' the HTML into a common structure and create UI that can be similar across websites and rendered in a clean, easy to navigate way. Not sure if that makes sense. Join our Discord if you want to chat more about it (https://join.wapps.app)
First I want to make browsing web apps feel as good as browsing an app. Then I want to make it better. To do that I want to 'translate' the HTML into a common structure and create UI that can be similar across websites and rendered in a clean, easy to navigate way. Not sure if that makes sense. Join our Discord if you want to chat more about it (https://join.wapps.app)
So, basically: (mostly) dead protocols. That is precisely why they don't need to change. Protocols that are used widely are those who have no option but to change in order to adapt to real world problems
Balance is key in my opinion both for protocol and programming language standards. Decades is too long and months is too fast irrespective of use-case.
I can see javascript,python updating every few years and once or twice a decade for HTTP,SMTP,SSH,Rust,C++. But that's just my opinion, what I stand firmly on is avoidance of extremes in either end.
I can see javascript,python updating every few years and once or twice a decade for HTTP,SMTP,SSH,Rust,C++. But that's just my opinion, what I stand firmly on is avoidance of extremes in either end.
I completely agree. The one-year release cadence for JS has been amazing and it's a much-needed improvement over the one every few years model they used to follow.
More importantly though, I think JS has really benefitted from small improvement scopes: there's only a few new features that really matter ever year. That, along with clear roadmaps leading up to a release have made adopting new features easy.
More importantly though, I think JS has really benefitted from small improvement scopes: there's only a few new features that really matter ever year. That, along with clear roadmaps leading up to a release have made adopting new features easy.
I got half a page of text then "To keep reading this story, get the free app or log in."
Gopher is starting to look pretty good.
Gopher is starting to look pretty good.
I doubt gopher would be any different. It is just better now because the users aren't trying to monetize it.
I really expected to see email on that list.
Another ancient but still supported protocol is the finger protocol. For the current weather on the South Pole, try this from the command line:
finger [email protected]
Or, if you want the weather in Boston, Massachusetts, try:
finger [email protected]
finger [email protected]
Or, if you want the weather in Boston, Massachusetts, try:
finger [email protected]
https://en.m.wikipedia.org/wiki/Finger_(protocol)
I think it was Carmack who introduced me to that protocol through a dev talk, if my memory is correct.
I think it was Carmack who introduced me to that protocol through a dev talk, if my memory is correct.
I was also sad that RLE graphics never took off, it was great way to get black and white photos over a slow modem. Wonder what a unicode based rle gfx format would look like.
SMTP anyone? I mean is still very much used, though it got extended, but you can definitely use the old one and BigCo will accept your email.
Still not massively convinced HTTP needed to progress beyond 1.1. I’m sure someone at Google got a promotion out of it though.
Pretty early on it becomes apparent that you'd quite like to fetch more than one resource. In 1992 you're fetching one page of HTML markup or maybe a file somebody linked, but by 1995 you're definitely fetching a picture of the author's cat and the logo of the organisation they work for. Maybe there is a little animated GIF explaining that the page is under construction. Today obviously most documents on the web have lots of resources ("Under construction" GIFs are gone, but pictures of the author's cat are still very much a thing, now joined by audio and video, style and of course scripts).
Obviously one thing you can do is, for every resources spin up a new HTTP connection to the remote server. These connections have no relationship to each other, so that's a bunch of extra overhead but nevertheless your browser today will probably try to do this several times per server. Still that's pretty inadequate, surely we can do better?
So, OK, HTTP/1.1 also has keep-alive. We can re-use connections, ask for a resource, wait until that's delivered, then fetch another one.
But notice this is strictly sequential. If you're a Unix person it's natural to try the next idea for HTTP, pipelining. Don't wait until things are delivered, just ask for everything you want, surely the remote server will provide one at a time, reading your next request, serving that, then the next one and so on, right?
But for 1990s server programmers excited by threads this doesn't work. Their server has one thread gathering requests, and for each request it spawns a thread to provide the answer. If I try to pileline my HTTP requests I get muddled nonsense back from their server. Sometimes. Is that forbidden by the HTTP specification. Sure. Did it happen anyway? Yes. So your browser does not use pipelining in HTTP/1.1
Also, this suffers head-of-line blocking. If I request CreditCardStatement19960402.pdf and you must send a tape robot to retrieve that, too bad, even though I also wanted bankname.jpeg and hideousfont.css I can't retrieve those because I'm waiting for CreditCardStatement19960402.pdf. The network is idle while we wait for the robot.
Google's servers and Google's browser spoke SPDY back in the day, which fixes a bunch of this. That doesn't exist any more because HTTP/2 was standardised and has the same fixes plus other stuff, some of which proved very useful, other things not so much. Only one way to find out.
Obviously one thing you can do is, for every resources spin up a new HTTP connection to the remote server. These connections have no relationship to each other, so that's a bunch of extra overhead but nevertheless your browser today will probably try to do this several times per server. Still that's pretty inadequate, surely we can do better?
So, OK, HTTP/1.1 also has keep-alive. We can re-use connections, ask for a resource, wait until that's delivered, then fetch another one.
But notice this is strictly sequential. If you're a Unix person it's natural to try the next idea for HTTP, pipelining. Don't wait until things are delivered, just ask for everything you want, surely the remote server will provide one at a time, reading your next request, serving that, then the next one and so on, right?
But for 1990s server programmers excited by threads this doesn't work. Their server has one thread gathering requests, and for each request it spawns a thread to provide the answer. If I try to pileline my HTTP requests I get muddled nonsense back from their server. Sometimes. Is that forbidden by the HTTP specification. Sure. Did it happen anyway? Yes. So your browser does not use pipelining in HTTP/1.1
Also, this suffers head-of-line blocking. If I request CreditCardStatement19960402.pdf and you must send a tape robot to retrieve that, too bad, even though I also wanted bankname.jpeg and hideousfont.css I can't retrieve those because I'm waiting for CreditCardStatement19960402.pdf. The network is idle while we wait for the robot.
Google's servers and Google's browser spoke SPDY back in the day, which fixes a bunch of this. That doesn't exist any more because HTTP/2 was standardised and has the same fixes plus other stuff, some of which proved very useful, other things not so much. Only one way to find out.
Why not have the server packetize and label?
... <file1, bytes 2048-4096> <file2, bytes 0-125> ...
The server has to order critical stuff first on a pipelined connection to reduce latency but this approach can easily send stuff the client requested and will request, while collecting data serverside by any number of threads.
... <file1, bytes 2048-4096> <file2, bytes 0-125> ...
The server has to order critical stuff first on a pipelined connection to reduce latency but this approach can easily send stuff the client requested and will request, while collecting data serverside by any number of threads.
Is your question, "Why didn't we invent a better protocol than HTTP/1.1" ? Because the answer is we did, but the previous poster doesn't like newer HTTP protocols.
If you just meant, "Why didn't we ignore how the HTTP/1.1 protocol is defined and do something else?", that's not what a protocol is, you're not going to build a successful application without agreement about the protocol.
If you just meant, "Why didn't we ignore how the HTTP/1.1 protocol is defined and do something else?", that's not what a protocol is, you're not going to build a successful application without agreement about the protocol.
HTTP/2 should have been implemented over SCTP. It's silly that we're restricted to two bulk transport protocols and have to hack things on top of them. Google could have used it's influence to break the logjam.
Sure, HTTP 1.1 was a clear improvement over 1.0.
Most of those are supported by curl, just prepend e.g. telnet:// gopher:// and ftp:// to the URL!
Would be nice to see a new version of irc but it's going so slowly...
[deleted]
Speaking of being tired of the modern web: I think HTTP/HTML are fine. However medium really sucks, can't everyone start hosting their webpages somewhere else? This is slow on my mobile (even with adblocker) and this "open in app" bar doesn't want to disappear even if it's bringing no value
"Please don't complain about tangential annoyances—things like article or website formats, name collisions, or back-button breakage. They're too common to be interesting."
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
I'm sorry, but I think for this article that seemed relevant since the real article title starts with "tired of the modern web", then discuss the merits of the "old" web. I thought the article media was itself a good illustration of what was wrong with the "new" web.
HTTP and HTML are fine. It's what people (eg. Medium) do with them that we complain about.
The only things we've really lost are MIDIs, <blink> / <marquee>, and Flash. And for some reason people don't like bedazzled mouse pointers anymore.
- Monopolistic platforms
- Annoying advertising
- Creepy tracking
- Walled gardens of content
- Needless SPA-ification
- Engagement optimization
- Gamification
- Dark patterns
The only things we've really lost are MIDIs, <blink> / <marquee>, and Flash. And for some reason people don't like bedazzled mouse pointers anymore.
Fun fact -- yes <blink> is indeed lost, however <marquee> still enjoys first-class support across all major browsers!
https://caniuse.com/?search=marquee
https://caniuse.com/?search=marquee
I moved to write.as and it’s much more tailored to people who want to just share their blogs etc. like Medium was originally!
Their free tier is invite-only for now though.
It looks like they switched to invite-only this year.
A client of mine would like to start blogging, and I was hoping to recommend the write.as free tier. I'd be interested to hear what other alternatives folks here recommend, or a write.as invite link from a paid user if anyone has one to spare.
A client of mine would like to start blogging, and I was hoping to recommend the write.as free tier. I'd be interested to hear what other alternatives folks here recommend, or a write.as invite link from a paid user if anyone has one to spare.
My experience seems to be a bit different, apparently. I see a lot of interesting content hosted there. HN is my only entry point to Medium, so for me that site ist just a blog hoster, like blogspot.com is. But I do dislike the latter somehow, as well as Wordpress.
For me Medium seems to be the only acceptable blogging platform, but neither do I use it myself as I don't blog, nor do I visit any non-tech/-science content on that site.
But I do use a very strict setting in uBlock Origin, so maybe that's causing the site "to behave". And I only visit it on the desktop.
For me Medium seems to be the only acceptable blogging platform, but neither do I use it myself as I don't blog, nor do I visit any non-tech/-science content on that site.
But I do use a very strict setting in uBlock Origin, so maybe that's causing the site "to behave". And I only visit it on the desktop.
I wondered if they posted it to medium as irony.
The ux with full size images or enlarging them onclick does not quite seem up to par.
https://medium.com/interaction-reimagined/regular-expression...
https://scribe.rip/interaction-reimagined/regular-expression...
https://medium.com/interaction-reimagined/regular-expression...
https://scribe.rip/interaction-reimagined/regular-expression...
HTTP and HTML were a hot mess since day one.
I'm more tired of people writing on Medium than I am of modern web.
To authors everywhere: Stop writing on medium.
To authors everywhere: Stop writing on medium.
"Please don't complain about tangential annoyances—things like article or website formats, name collisions, or back-button breakage. They're too common to be interesting."
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
Where should they write that pays?
Not everything needs to be about money. Software engineers get pretty absurd salaries already. Most of the high quality blogs I’ve seen are pro bono.
writing is a craft. you need practice (which i'm really quite out of).
writing is a power. even though literacy seem down - you can use this to make your point. not just to convince people, but to spark discussions that allow us to try to chip away to get to the underlying truth of the matter.
face it - most of the authors on medium aren't really insightful or entertaining enough to get paid.
there is plenty of room in society for open mic nights
writing is a power. even though literacy seem down - you can use this to make your point. not just to convince people, but to spark discussions that allow us to try to chip away to get to the underlying truth of the matter.
face it - most of the authors on medium aren't really insightful or entertaining enough to get paid.
there is plenty of room in society for open mic nights
Why are you mentioning software engineers?
How much does medium pay? I didn’t even know that was an option!?
Good ole Google Ads on a WordPress blog seems fine historically.
At least substack loads fast…
Good ole Google Ads on a WordPress blog seems fine historically.
At least substack loads fast…
Substack seems to be an option, is less user-hostile.
Though I would not expect some piles of money unless you have an army of invested readers.
Though I would not expect some piles of money unless you have an army of invested readers.
My first modem was 300 baud, through I believe 150 baud preceded that. I miss BBS and the old internet.
110 baud preceded 300 baud, then 1200 baud.
Here is a list: https://en.wikipedia.org/wiki/Modem#Evolution_of_dial-up_spe...
Here is a list: https://en.wikipedia.org/wiki/Modem#Evolution_of_dial-up_spe...