I was there was a workaround for the Mastodon DDoS by link preview issue.
Small publications can’t have their links posted here because it can take their entire site down.
The fact that I could kill a small site for a few minutes just by posting a link, really really sucks.
#Mastodon #Fedi #Fediverse
@FandaSin@social.linux.pizza the issue is, every server that the link lands on, requests a link preview. My instance is federated with 15,000+ instances.
There’s not really a way, that I know of, to cache something like that cause each link is different and could be new to the instance or just a new link altogether.
Can’t cache something that hasn’t existed before.
@BeAware@social.beaware.live
Thank you for explanation.👍
As I said before I don’t know anything from internal working of Mastodon.
(I might be completely wrong and saying something stupid, as I do most of the time 😆)
Could it be possible to transfer “link preview” inside the toot?
What I mean - server on which toot was created would also create “link preview” and distribute it with toot.
@FandaSin@social.linux.pizza that’s a good question I didn’t think of, when you mentioned caching. I was under the impression you meant caching in a traditional sense. Because normal caching is done on a per server basis.
My cache doesn’t interact with anyone else’s cache.
@FandaSin@social.linux.pizza @BeAware@social.beaware.live Yes this is possible and I think it’s been discussed as a solution. The concern, last time I was reading about it, is that malevolent servers could poison a link preview and send fake images along with the url (the argument against this is you’re already ‘trusting’ the server if you’re federating with them, so that trust should extend to link previews)
Another proposed solution was just having servers wait a random amount of time before fetching the link preview so not every server is requesting the preview at the same time