This #Mastodon thing might have some legs. Here's relative
#Flickr request volume from Mastodon servers for preview photos in embeds. (We also fixed an issue, too, so #Flickr should play even more nicely with #Mastodon now 💪... we co-invented oEmbed but screwed up slightly 🤦). (x-post from https://twitter.com/DonMacAskill/status/1592997661980102656)
Don MacAskill on Twitter

“This #Mastodon thing might have some legs. Here's relative @Flickr request volume from Mastodon servers for preview photos in embeds. (We also fixed an issue, too, so #Flickr should play even more nicely with #Mastodon now 💪... we co-invented oEmbed but screwed up slightly 🤦).”

Twitter

@d0n Yes, but this also seems to reflect the bug...err...feature that's been getting attention lately, that Mastodon makes a whole lot of requests for preview photos even when they're not actually needed, when people aren't actually asking for them.

Some people have been having their webservers crash because Mastodon behaves like this, and even Mastodon developers recognize it as a problem.

A whole lot of the request volume shouldn't happen in the first place.

@crcarlin Mostly, this is just poorly coded software. If the software properly cached responses to requests (and better yet, leveraged a free CDN on top of that), this problem would largely go away.

@d0n It's not just poor coding, though. These were active choices made by the devs, as you can see in their public discussions on gethub.

They specifically considered caching, CDN, and other options like that and decided not to use them.

For example, they decided every instance needs to get preview images from source servers to avoid the possibility of passing around fakes, which is a real concern, but I don't think the solution is worth the cost.

@crcarlin Source servers is what I’m talking about. Well-engineered source servers should handle this fine. Especially if they’re using a good CDN (which can be free).

@d0n

I just don't subscribe to the philosophy that my software package will flood your system with an enormous amount of unnecessary and unexpected requests, and that's 100% your problem to deal with.

Fine, technically we might say a public server is responsible for dealing with anything the public might throw at it. Spam, DDoS, whatever.

But I'd say better practices involve not using resources wastefully in the first place.

@crcarlin Agree, but both sides should be smart. No-one seems to be talking about how poorly designed, written, or managed many of the origins are. Trivial low-hanging fruit is there for the picking.