gemini://kwiecien.us/logarion/slow-internet.gmi

(Days of Old Alert!)

When I first got Internet it was via a 2400baud modem -- that basically was unusable for anything beyond IRC. I got bored and went back to BBSes and CompuServe, which didn't have the TCP/IP overhead. So, let's pretend my first Internet was a 14.4k; my next upgrade. That's about 1.8 kilobytes/s. I think that our MTU was kept small -- less than 600 bytes -- makes sense, otherwise you could only send one IP packet per second -- so the 40byte TCP/IP overhead was close to 10%.

Anyway, this technical divergence isn't the point -- I agree with logarion -- slow Internet is okay, unreliable Internet is the pits. Anyone who's ever used the wifi on a train (or via 3G while moving at speed) knows that -- when I used dial up things were not "that bad" because the connection was constant, even though it was slow.

That said, client devices and modern assumptions make things worse in a way that wasn't true when very slow Internet connections were normal: if you connect to a device over wifi, and you're using Windows or Mac (or you have Steam on Linux), then your laptop will start to download updates if they become available. The assumption is that if there's Internet access, it is unmetered and abundant. Some OSes will do the right thing if they can detect they're on a metered connection, but why should the default be "take what you need"?.

Also, opening a TCP socket on Windows (back in the day) used to open up your dialer software. This wasn't uncommon on Linux too, maybe Macs. Software didn't do networking requests unless you asked -- because as soon as it tried it was going to either prompt you to go online, or you'd hear the click of a relay as it started to dial up.

The oldest protocols: (telnet), IRC, SSH, SMTP, POP3/IMAP -- these are all totally usable. Gopher, obviously. The web should be: it worked that way when it was first popularized, and I bet a good few tilde.town websites will work, but on most of the net the assumption that you can download fonts in parallel with images (or video) and a chunk of markup _and_ some CSS and some Javascript -- all within some arbitrary timeout from your browser, is not compatible with either slow _or_ with unreliable Internet.

When I was a web developer my bosses boss refused to upgrade his computer and he has the slowest machine in the office. He would do final QA on our sites, and acted as check against us assuming that everyone had powerful cutting edge Macbooks to browse with.

A little part of me is distrustful of any new federated/slow protocols that can't work mostly offline, or in batch, and work with arbitrarily slow connections. Mastodon is definitely a 'nope' here -- every server is expected to be online all of the time. It's not Mastodon's issue, it's ActivityPub, but these decisions inform the kinds of people who will be able to run servers and what that experience is like.