I decided since I don't understand how all of this works, I will just simply ask Jerry personally about all of this data and technical details, so that people will no longer be confused about all of this.
Includes an exclusive interview with Jerry.
Very interesting article! I have immense respect for jerry@infosec.exchange, he was one of the first people I found on the fediverse, and it’s no wonder why, he’s revered quite highly by others as being a generous and kind admin.
I do want to point out one thing, and that is that Mastodon has some design decisions that make it rather resource and storage intensive.
There are oodles of lighter software out there, some with even more features than Mastodon, and some with less. For example, snac.bsd.cafe (https://snac.bsd.cafe/) runs on Snac, which is fast as hell.
I am going to guess that a not insignificant portion of Jerry’s bill is caching assets. Mastodon likes to save everything it encounters, videos, images, avatars, everything… forever (though I imagine this is customisable). Most likely the assets are viewed a handful of times in one day and never seen again… but you’ll pay to store it forever!
One of the ways that this could improve in the future is that we’re working on a notional caching service as a future Fediverse Auxiliary Service Provider, so that this kind of content could be shared between small groups of instances that chose to use it.
It doesn’t store media forever that is routinely cleaned and configurable in the administration settings for the instance.
The content cache, which is database storage used for the text and meta-data of posts is more typically an issue over time because this requires commands to be run on the server to free up space, which many people do not do.
https://fedihost.co/blog/slug/managing-mastodon-storage
Most likely the assets are viewed a handful of times in one day and never seen again… but you’ll pay to store it forever!
This is exactly the thing that should optimized immediately. Store relevant content. Delete after it is not relevant. Fetch it back if it is relevant again.
Very interesting article! I have immense respect for jerry@infosec.exchange, he was one of the first people I found on the fediverse, and it’s no wonder why, he’s revered quite highly by others as being a generous and kind admin.
I do want to point out one thing, and that is that Mastodon has some design decisions that make it rather resource and storage intensive.
There are oodles of lighter software out there, some with even more features than Mastodon, and some with less. For example, snac.bsd.cafe (https://snac.bsd.cafe/) runs on Snac, which is fast as hell.
I am going to guess that a not insignificant portion of Jerry’s bill is caching assets. Mastodon likes to save everything it encounters, videos, images, avatars, everything… forever (though I imagine this is customisable). Most likely the assets are viewed a handful of times in one day and never seen again… but you’ll pay to store it forever!
One of the ways that this could improve in the future is that we’re working on a notional caching service as a future Fediverse Auxiliary Service Provider, so that this kind of content could be shared between small groups of instances that chose to use it.
It doesn’t store media forever that is routinely cleaned and configurable in the administration settings for the instance. The content cache, which is database storage used for the text and meta-data of posts is more typically an issue over time because this requires commands to be run on the server to free up space, which many people do not do. https://fedihost.co/blog/slug/managing-mastodon-storage
This is exactly the thing that should optimized immediately. Store relevant content. Delete after it is not relevant. Fetch it back if it is relevant again.
If there’s a word that does not go well with Mastodon, it’s “immediately”
lol
Happy cake day btw!
Things would improve by a lot in Mastodon if they implemented separate storage engines between local and remote resources. Then instance admins could have a way to host, e.g, local resources on their own infrastructure but push all remote instances to some “shared cache”, based on IPFS/torrent/TahoeLAFS.