Barhandar 
(twi|pony)booru.org
I agree with posters up there; also, I want the image saved on right-click be the one with tags, not just the number.
Site Development Notification and Feedback Thread
DJDavid98 
Disy
The main reason for this change as far as I’m aware was the fact that the links with tags were merely “aliases” of the base URL without tags. You can put almost anything after the image number in the URL and it will point to the same image, e.g. https://derpicdn.net/img/view/2018/8/4/1798029-akjulgfklhganqz4gvtuzaifngvfbuta4gnfuzh4nbgvu4iaaa.png
This basically creates a situation where there could be infinitely many versions of an image floating around, especially if tags changed a lot, and this makes caching the images difficult due to all the file name variations. Defaulting to the file with the numbers means that it’s the “canonical” file for any upload and we won’t have a dozen versions of it with different tags in the name linger in the site’s (and users’) caches.
The download button was changed to also download the file with just the number ID, but there’s some code magic that changes the destination file name before the save dialog is displayed.
This basically creates a situation where there could be infinitely many versions of an image floating around, especially if tags changed a lot, and this makes caching the images difficult due to all the file name variations. Defaulting to the file with the numbers means that it’s the “canonical” file for any upload and we won’t have a dozen versions of it with different tags in the name linger in the site’s (and users’) caches.
The download button was changed to also download the file with just the number ID, but there’s some code magic that changes the destination file name before the save dialog is displayed.
PonyGhosts
#metoo
What I don’t get, then, is why this isn’t a problem with other booru software like Shimmie and Danbooru. Images with tags in them is basic booru functionality, and enormous Shimmie-based sites like Paheal are ticking along fine with a literal million more uploads than here.
Barhandar
(twi|pony)booru.org
@DJDavid98
Does said blob magic work on the right click - save as (clicking on the button doesn’t let me choose destination and I can’t be bothered to fix that or sort the results of unspecified download)?
Sadly it’s probably not applicable to the much larger and easier to hit actual image because images need to be images, not whatever interception bullshit image sites are doing.
@HumanGhosts
It’s not really an obstacle to function. It’s just an inconvenience for caching.
Does said blob magic work on the right click - save as (clicking on the button doesn’t let me choose destination and I can’t be bothered to fix that or sort the results of unspecified download)?
Sadly it’s probably not applicable to the much larger and easier to hit actual image because images need to be images, not whatever interception bullshit image sites are doing.
@HumanGhosts
It’s not really an obstacle to function. It’s just an inconvenience for caching.
Officer Hotpants 
Literally3HitlersInACoat
Unfortunate that the tags were removed from image names (helped me sort them on my end). I suppose this’ll result in fewer broken links, though.
sgdragon 
@Barhandar
Except the scaled image only fits the width of your screen, so you still have to scroll to see the whole image for the vast majority of posts.
Except the scaled image only fits the width of your screen, so you still have to scroll to see the whole image for the vast majority of posts.
PonyGhosts
#metoo
@Barhandar
What’s a minor inconvenience, the broken link issue? It sounds like the cure is worse than the disease. Anyway, my point was more that other booru software seemingly avoids the issue without having to butcher basic functionality like tags in file names. I suppose we’ll be getting rid of thumbnails next.
What’s a minor inconvenience, the broken link issue? It sounds like the cure is worse than the disease. Anyway, my point was more that other booru software seemingly avoids the issue without having to butcher basic functionality like tags in file names. I suppose we’ll be getting rid of thumbnails next.
Barhandar
(twi|pony)booru.org
@HumanGhosts
Nah, replace them with four pixels of color that the dedupe code uses. After all, that’s the caching part relevant to the oh so struggling hardware!
Also, the broken link issue is not even existent as evidenced by DJDavid’s message - it ignores anything that comes between the number and the extension anyway.
P.S. Neither would the caching issue exist (nothing different to cache) if you’d keep View button and remove the tags from enlarged image only.
Nah, replace them with four pixels of color that the dedupe code uses. After all, that’s the caching part relevant to the oh so struggling hardware!
Also, the broken link issue is not even existent as evidenced by DJDavid’s message - it ignores anything that comes between the number and the extension anyway.
P.S. Neither would the caching issue exist (nothing different to cache) if you’d keep View button and remove the tags from enlarged image only.
byte[] 
Philomena Contributor
There are a few reasons for the change to the download links which are worth explaining here, but I guess were not adequately explained before:
- It’s not very easy to support this. In our early iterations as a site, we used Dragonfly for image processing, and it worked fine. This allowed us to basically have a programmable URL endpoint to fetch images with the current tags and/or get thumbnails, and from that Dragonfly would copy the file into the stream. The problem with that was of course generating images on the fly is a really bad idea from a scalability perspective, so when we eventually as a site outgrew our ability to do that, we switched over to serving files statically from the filesystem.
After the changeover to use static files, we used nginx as our file server, and made a lot of corresponding changes to the application code. We settled on making a file and a separate symlink of the file with the current tags in it, and then just renaming it as we saw necessary. This sort-of worked, though often times people on Cloudflare nodes who did not yet have an image cached would see 404s due to the file moving around.
Finally, around the time of introducing multiple CDN subdomains (img0-img5), Clover fixed this by adding a regex alias for all tagged links to an image to the file in the image directory named full.png/full.jpg/full.gif/full.svg. This more or less solved the problem for the time being, and allowed us to remove dozens of lines of sketchy code necessary to handle generating tagged filenames, though it did expose a new problem with cacheability.
- As David already mentioned, there are infinitely many URLs for any given filename. This is a problem, because we’d like to keep as much traffic as possible away from our origin server. This both decreases load on our backend and also helps to significantly increase edge performance for users. Having infinite URLs for every filename is a great way to destroy cache performance, as even mere users can easily push out the LRU for lesser-used files on the edge by requesting larger image files with unique filenames, all by modifying the tags.
- I’m thinking of moving hosts, which further complicates this issue. I would like to move us to Backblaze B2 sometime in the future, as it costs significantly less to store and host files with Backblaze now than it ever has before due to the Cloudflare Bandwidth Alliance. than on our current setup. It also has the serious advantage of using a host whose business is in object storage and content delivery, which we are not. We just want to host ponies. Moving to B2 would greatly reduce computational and connectivity requirements on our host side. On Backblaze, it is indeed possible to set the Content-Disposition header to allow downloading attachments, but it is definitely not possible to allow arbitrary aliases of a file in this way.
Before anyone mentions Cloudflare Workers, I would like to remind them Cloudflare Workers is billed on usage, $5.00 base fee, and $0.50 per million requests. derpicdn had 760,925,579 requests made to it last month, so if you do the math, it comes out to $385.462 per month, which is almost as expensive as the server itself, and adds no additional value beyond the download link hack. So that is not really an option.
So please, before you come to this thread to post something like “please stop breaking my workflow!” or “every other booru lets you do this!”, know we’re not doing this arbitrarily. It actually pains me to have to do this in the first place, since having the tag URLs is kind of a cool hack.
We are one of the biggest boorus on the internet and being so means we have to shoulder costs no smaller booru has likely ever had to. We still are suffering effects on our bad schema organization since the time we used MongoDB, and we haven’t even used Mongo since 2015. It is difficult to operate and scale this site in a computationally and cost efficient manner at our current scale, and we still have lots of work ahead of us to keep things running smoothly for the foreseeable future.
Thank you for your patience and understanding, and I’m sorry I didn’t provide an adequate explanation before deploying this change.
GyroTech 
The Prettiest Catbird
Then I want to echo the other users here in being able to at the very least download with tag namees, even if it’s a client side JavaScript generation for it. Having tags in names is super important for me for organization, especially so that I can ensure all my images have an artist attached to them for proper credits.
As an artist myself, I’m also kind of irritated about it stripping away default attribution that saving with tag names gives.
As an artist myself, I’m also kind of irritated about it stripping away default attribution that saving with tag names gives.
Background Pony #C83F
@byte[]
If this is a cacheability thing, may I suggest instead limiting filename tags to rating/artist/characters? I’ve no site statistics to work from, but I’d guess those change much less often, and they’re already at the front of the filename. You’d get most of your cacheability with most of the utility of the tagged filenames.
If this is a cacheability thing, may I suggest instead limiting filename tags to rating/artist/characters? I’ve no site statistics to work from, but I’d guess those change much less often, and they’re already at the front of the filename. You’d get most of your cacheability with most of the utility of the tagged filenames.
byte[]
Philomena Contributor
@Background Pony #8398
That would help in the short run, but remember that those fields are still mutable, and because of that it’s not good UX to limit the view/download endpoints to only the files that are currently being displayed; we’d either have to keep track of every filename that an image has had (would slow down image serving a lot) or continue to keep it possible that any image URL with the ID can access the image (as we currently have).
And of course neither of these would work at all if we moved to Backblaze.
That would help in the short run, but remember that those fields are still mutable, and because of that it’s not good UX to limit the view/download endpoints to only the files that are currently being displayed; we’d either have to keep track of every filename that an image has had (would slow down image serving a lot) or continue to keep it possible that any image URL with the ID can access the image (as we currently have).
And of course neither of these would work at all if we moved to Backblaze.
TexasUberAlles 
Not having the tags in the filename is annoying, but not as annoying as having the site break because of it. We’ll live.
Background Pony #C83F
@byte[]
I’m not understanding your problem. Unless you’re serving hotlinking/embedding use cases[1], your CDN URL’s don’t have to be permanent, just stable enough to be usefully cached[2]. Rating/artist/character tags are technically mutable but in practice I’m guessing probably settle down fairly quickly in almost all cases, if they aren’t simply correct up-front[3]. A slightly variable image URL with a meaningful filename vs. a perfectly consistent URL without one seems like a pretty reasonable tradeoff, but I don’t have the data to actually calculate costs. And that would work just fine in practice with B2 or any other simple-minded object host.
[1] If there’s a use case that requires actually permanent URL’s, that’s a bit harder, and maybe what you’re getting at, but I think still solvable, especially since your proposed B2 future sounds like it would break current URL’s anyway.
[2] Especially vs. what I’m assuming is currently a pretty bad cache rate due to churn in tags that begin with “a” and “b” and aren’t “applejack”, which I don’t really care about anyway.
[3] How often does someone actually e.g. misidentify a main character? I can imagine weird edge cases like renaming an artist tag, but there are reasonable solutions here.
I’m not understanding your problem. Unless you’re serving hotlinking/embedding use cases[1], your CDN URL’s don’t have to be permanent, just stable enough to be usefully cached[2]. Rating/artist/character tags are technically mutable but in practice I’m guessing probably settle down fairly quickly in almost all cases, if they aren’t simply correct up-front[3]. A slightly variable image URL with a meaningful filename vs. a perfectly consistent URL without one seems like a pretty reasonable tradeoff, but I don’t have the data to actually calculate costs. And that would work just fine in practice with B2 or any other simple-minded object host.
[1] If there’s a use case that requires actually permanent URL’s, that’s a bit harder, and maybe what you’re getting at, but I think still solvable, especially since your proposed B2 future sounds like it would break current URL’s anyway.
[2] Especially vs. what I’m assuming is currently a pretty bad cache rate due to churn in tags that begin with “a” and “b” and aren’t “applejack”, which I don’t really care about anyway.
[3] How often does someone actually e.g. misidentify a main character? I can imagine weird edge cases like renaming an artist tag, but there are reasonable solutions here.
RaCCa
@byte[]
Thanks for the very detailed explanation, man! I appreciate it :)
And maybe just to make it clear, I wasn’t blaming you for breaking any of my workflows. If I would have been, I would have asked you to revert the change, which I didn’t do. I just asked for a workaround. But ultimately, it’s a tiny issue, so I’m in support of you doing what you have to do to keep the service alive!
Thanks for the very detailed explanation, man! I appreciate it :)
And maybe just to make it clear, I wasn’t blaming you for breaking any of my workflows. If I would have been, I would have asked you to revert the change, which I didn’t do. I just asked for a workaround. But ultimately, it’s a tiny issue, so I’m in support of you doing what you have to do to keep the service alive!
Barhandar
(twi|pony)booru.org
By the way, if you want better attribution, it would be good to get rid of “large” and “medium” filenames and replace them with actual IDs. A ton of people save these, and then upload the results to, say, Discord instead of linking the original image.
evan555alpha 
PSA: R0 was changed!
@Barhandar
Or link to these “medium”, “large”, and “full” images as well, rather than use the VS link.
It’s so damn irritating.
Or link to these “medium”, “large”, and “full” images as well, rather than use the VS link.
It’s so damn irritating.
Lead Pie 
This is a box.
@Barhandar
I would suggest not to make them the exact same as the full res files. Otherwise you wouldn’t have any indication if you actually got the full version or something scaled without looking it up.
Also, reverse image search is a thing. And Derpi images are indexed by Google.
I would suggest not to make them the exact same as the full res files. Otherwise you wouldn’t have any indication if you actually got the full version or something scaled without looking it up.
Also, reverse image search is a thing. And Derpi images are indexed by Google.
Brokedownandmadeone 
BigThirsty ponybooru.org
But is there any way the auto-tag adding can happen at least on client-side when using the download button?
@Barhandar
I would suggest not to make them the exact same as the full res files. Otherwise you wouldn’t have any indication if you actually got the full version or something scaled without looking it up.
Also, reverse image search is a thing. And Derpi images are indexed by Google.
Bingo.
@Barhandar, don’t be lazy.
@Barhandar, don’t be lazy.
evan555alpha
would become
That way, when they’re saved the wrong way, and later uploaded elsewhere, such as Discord, they’re not just called ‘medium.jpeg’ or full.jpeg’, and at the same time, their filenames aren’t identical, so one can tell whether or not they’re saving the fullest res possible.
That, and knowing the image ID is far faster and easier than reverse-searching for it, too.
PSA: R0 was changed!
@Lead Pie
@Barhandar
@Brokedownandmadeone
Something like
@Barhandar
@Brokedownandmadeone
Something like
ID_Full could be compromise between the two. Sohttps://derpicdn.net/img/view/2016/8/27/1234567/medium.jpeg
would become
https://derpicdn.net/img/view/2016/8/27/1234567_medium.jpeg
That way, when they’re saved the wrong way, and later uploaded elsewhere, such as Discord, they’re not just called ‘medium.jpeg’ or full.jpeg’, and at the same time, their filenames aren’t identical, so one can tell whether or not they’re saving the fullest res possible.
That, and knowing the image ID is far faster and easier than reverse-searching for it, too.
Marker
That’s what the site is already doing after the update. When you click the download button, you are actually downloading the version with just the id, and the renaming happens on your browser.
Misanthrope
But is there any way the auto-tag adding can happen at least on client-side when using the download button?
That’s what the site is already doing after the update. When you click the download button, you are actually downloading the version with just the id, and the renaming happens on your browser.
Interested in advertising on Derpibooru? Click here for information!
Help fund the $15 daily operational cost of Derpibooru - support us financially!