FurAffinity thumbnail expander user script?
11 years ago
General
Sometimes, I like to write user scripts for the browser, to improve website experiences. This is strictly a hobby, usually only for my own use, and I don't do it professionally or on request.
Once upon a time I wrote one of these for FurAffinity. It was back when FurAffinity's CDN servers had similar filenames for both full submissions and for thumbnails, so it was trivial to programmatically convert from one to the other.
When FA switched to a new thumbnail filename format so that it doesn't share a naming pattern with the submission files, my script broke. To get it to work again, I would have had to prefetch every submission HTML page involved, just to parse the URL of the full submission. This seemed like overkill, as it would have not only have skewed submission statistics (adding hits for pages not visited in-person), but it would have greatly increased the bandwidth of requests by fetching the complete comments attached with each page. In the face of this, I abandoned the script and moved on to greener programming pastures.
In the light of the recent brutal DDOS attack FurAffinity sustained, I realized something funny. If I had continued to develop such a script, and distributed it online for others to install and use, and it were to become really popular, then the script itself - while not causing a full-fledged DDOS itself - would certainly not have helped FA's server bandwidth concerns in the long run.
These are some of the cost-benefit analyses we consider as user script programmers. We all love more convenient and more streamlined delivery of media on demand, but many of the arbitrary limits sites impose on our site access (at least by default), are almost certainly bandwidth-saving measures. Does this mean I'll stop trying to write useful user scripts that use relatively more bandwidth? Of course not - if the benefit is good enough. But when the bandwidth cost is higher, I am all the more reluctant to publish my user scripts.
Once upon a time I wrote one of these for FurAffinity. It was back when FurAffinity's CDN servers had similar filenames for both full submissions and for thumbnails, so it was trivial to programmatically convert from one to the other.
When FA switched to a new thumbnail filename format so that it doesn't share a naming pattern with the submission files, my script broke. To get it to work again, I would have had to prefetch every submission HTML page involved, just to parse the URL of the full submission. This seemed like overkill, as it would have not only have skewed submission statistics (adding hits for pages not visited in-person), but it would have greatly increased the bandwidth of requests by fetching the complete comments attached with each page. In the face of this, I abandoned the script and moved on to greener programming pastures.
In the light of the recent brutal DDOS attack FurAffinity sustained, I realized something funny. If I had continued to develop such a script, and distributed it online for others to install and use, and it were to become really popular, then the script itself - while not causing a full-fledged DDOS itself - would certainly not have helped FA's server bandwidth concerns in the long run.
These are some of the cost-benefit analyses we consider as user script programmers. We all love more convenient and more streamlined delivery of media on demand, but many of the arbitrary limits sites impose on our site access (at least by default), are almost certainly bandwidth-saving measures. Does this mean I'll stop trying to write useful user scripts that use relatively more bandwidth? Of course not - if the benefit is good enough. But when the bandwidth cost is higher, I am all the more reluctant to publish my user scripts.
FA+
