Right now, Fluffle performs pretty badly when images which get reverse searched are slightly cropped. This is quite a common scenario, and therefore we should look into which algorithm offers more resiliency against cropping and other modifications.

Since this will require reindexing every image so far, we might as well add support for storing the output of a cryptographic hash function (like MD5). This would make it possible to reverse search the exact image. It should be looked into which hash function suits the best here.

DeviantArt hosts a lot of art, of which a significant chunk is furry related. From running Fluffle on some images posted to DeviantArt, it seems Fluffle is not able to find a significant amount. This makes it worth adding support for DeviantArt.

Indexing the entirety of DeviantArt would be overkill for Fluffle while also taking an unreasonably long time. Content on DeviantArt seems to be relatively well tagged and it should be possible to utilize those tags to specifically look for furry (adjacent) content and artists to index. Investigating is needed as to what would be the best approach here.

They offer an API with which DeviantArt could be relatively easily integrated.

Furbooru is a furry fandom imageboard much like e621 but it runs on a fork of the Philomena backend used by Derpibooru and accepts certain kinds of images that e621 does not, such as photographed artwork. It launched in 2020 and has over 196,000 non-deleted images in its database as of this writing.

Its API page is over here.

Fluffle currently only indexes images, not animations or videos. It would be great if it could support animations and videos as well.

Fluffle shows the total number of images it searched through.

It would be neat if it could give users a break down of how many images it searched through on every platform. It could show these stats when hovering over (desktop) or clicking on (mobile) the total count.

The comparison API uses a cache to prevent having to retrieve all indexed images from the database at every launch. Right now the cached files are directly overwritten when new data is retrieved from the database. If the comparison API shuts down unexpectedly during the write operation, then the cache could get corrupt, resulting in a long start up time.

Malwarebytes Browser Guard has been blocking Fluffle's API subdomain (api.fluffle.xyz) whenever I try to use the Fluffle add-on as of late, claiming that the website is "blocked due to phishing", thus completely stopping the search and breaking the add-on. I can't even tell it to stop blocking the site no matter how many times I tell the add-on to stop blocking it.

The false positive needs to be reported directly to Malwarebytes themselves: Link to Malwarebytes support

Fluffle has a drag and drop area which makes it easy for users to reverse search images stored locally.

Happy accident: this drag and drop area also works for images dragged into the area from another tab. This works for Chromium-based browsers, but not for Firefox for example. Fluffle will show the following error for browsers that do not support this:

This error message is not very clear because it doesn't correlate with the action the user did (the user dragged something into that field, they didn't drop a file). The same error message gets shown when, for example, an URL or some text gets dragged into the area. For the error to then mention a file is even more confusing.

The above scenarios should be handled with clearer error messages.

It would be possible to find more accounts posting furry art if we were to look for hashtags related to the furry fandom (like #furryart).

It would be neat if Fluffle could reverse search by passing an URL as a query parameter, like the following: https://fluffle.xyz/?url=https://example.xyz/image.jpg. This would allow sites to link to Fluffle to execute a reverse search request.

• Implement incoming and outgoing rate limiting to prevent Fluffle from being abused and causing trouble respectively.
• Only allow HTTP(S) URLs of which the host is whitelisted. The whitelist should consist out of all the supported platforms.
• Cache hash function output by URL.

Currently, Fluffle does nothing when it comes to rate limiting because all-in-all it is quite efficient and the hareware it runs on is fairly decent...

However, processing animations and videos will consume way more resources than images do. At that point it will be beneficial to implement some rate limiting system.

The rate limiting system should be effort-based. Meaning the more resources a request takes up, the more effort it costs. This will also reward API consumers to interact with the API in an efficient way (resizing images, animations and videos before sending them over, for example).