This is a question that comes to mind every time I spend a few days focusing on the fediverse. Normally I’m on the microblogging side, but now I have a Lemmy account it might start a proper discussion.
So, to the point, pretty much every fedi platform has similar problems with small servers taking a beating whenever a post goes viral. This ends up costing the server owner a bunch of money trying to keep their server alive while thousands of instances attempt to pull large static files from the original host’s post. This recently instigated this call to action on this forum.
I’ve never seen the question of torrents answered and it feels like a lot of effort and a bit self entitled to get the ear of fedi software devs to implement torrents as a solution, so I’m putting this here.
If media files were made into torrents when a post was being created, an extra object could be added to post objects like
'torrentcdn': {
'https://imagePathAsKey.jpg': {
'infohash': 'ba618eab...',
'torrentLocation': 'https://directlinkto.torrent',
'webseed': 'https://imagePathAsKey.jpg',
...
}
}
This would not break compatibility as it would just be ignored by anything not looking for a ‘torrentcdn’ object, yet up to date instances could use this instead of directly pulling the static files.
This would benefit instances as when a post goes viral, the load would be distributed amongst all instances attempting to download the file.
This could also benefit clients and instances as larger files like short videos could be distributed using webtorrent, massively reducing the load on server when many people are watching the same video.
Thoughts?
Mastodon and lemmy handle this in slightly different ways. Mastodon (according to the link) replicates media on every instance while lemmy (mostly) only replicates thumbnails. That means a popular post doesn’t cause load for one server on mastodon but does on lemmy. But Mastodon has a higher aggregate cost due to all the replicated data, which is what the linked proposal solves by making it sublinear.
If the torrent is instance to instance I don’t see any real benefit (and instance to client is infeasible). On Mastodon side you still have data duplication driving storage costs and bandwidth usage regardless of whether it’s delivered via direct http or torrent. On the lemmy side it wouldn’t gain much (asymmetric load is based on subscription count and so not very bursty) but would add a lot of non-determinism and complexity to the already fragile federation process.
Conventional solutions like cache/CDN/Object Storage or switching to a shared hosting solution (decoupled from instances like your link proposes) seems like a more feasible way to address things.
I just put a caching layer in front of my
/pictrspath. Problem solved.I use Nginx for that, but some instances use Cloudflare which can be configured similarly.
Bit torrent is optimized for “lots of users downloading large files over low-bandwidth connections” which is sorta the opposite of this scenario.
My understanding of the bit torrent protocol is that it’s not very efficient for “small” files or low latency. The overhead of connecting could add latency that effects the end user experience.
I’m thinking in terms of what happens when someone on a $5 VPS hosting plan uploads a large image or small video and a thousand other instances want to grab it. The latency of a torrent isn’t as much of a problem as the server falling over. This is for propogation between servers rather than when a user requests a file.
