I was experiencing a weird slowdown and throttling between me and all of my VPSes at multiple different companies when doing specifically ssh transfers like rsync. Other protocols weren't getting throttled to 200KB/s but rsync was. I still have no idea why this happened. When I looked back at the slow transfer it seemed like the time estimated remaining hadn't changed at all in 10 minutes. It felt like the rate was slowing down so the time remaining was always remaining the same. I thought that would be a funny thing to intentionally do. So I asked claude 4.5 to make it. And it works and it's kind of funny. webserver-to-dynamically-throttle-file-download-so-theres-always-60s-remaining.py This vibe coded multi-threaded directory-listing python webserver will automatically reduce the data send rate so that it tries to keep the estimated time remaining at 60s. When the download first starts it kind of overshoots but if the file is large enough, or the upload speed of the line slow enough, it'll stabilize around 60s. Then as the rate tapers off to mere hundreds of bytes per second browsers will start overestimating the time remaining. http://superkuh.com/joke-webserver.jpg But the file download will never actually finish. It'll just get slower and slower and slower for hours and hours. It reminds me of the experience of dial-up file downloading in the 90s. Or as someone as described, the behavior of a live-caching proxy when that sends out the finished part of a file fast then slows down suddenly when it reaches parts which aren't finished yet. It is a very silly joke webserver but I'm having fun with it. And the idea might be somewhat useful as a bot tarpit if you have the router/edge hardware to handle lots and lots of open tcp connections. $ python webserver-to-dynamically-throttle-file-download-so-theres-always-60s-remaining.py /path/to/web/root/folder/ By default it binds to port 8000 on all interfaces. The port and target "time remaining" are just hard coded as 'port = 8000' and 'TARGET_TIME_REMAINING = 60.0'.