-
-
Notifications
You must be signed in to change notification settings - Fork 348
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feature] Option to disable media caching #1405
Comments
I definitely think there should be a shorter time period, but no caching grabs the media anew every time and it's considered rude to hotlink like that. |
I find myself slightly resisting this, despite this being exactly how my instance was set up when I ran Pleroma. Allowing posts to hotlink remote media would be "fine" 98% of the time in a solo instance. Either the user pulls or the instance pulls; one hit. However its use wouldn't be limited to solo/single-user instances and I feel this is one of the things that shouldn't be easy to just turn on and start using other instance's resources. There's also issues on the table regarding hotly boosted posts hitting an instance multiple times and whatnot. I think what I'd rather opt for is a split media repository. The durable media uploaded by users optionally stored somewhere different than the volatile cache. At that point you could put a cache on a one day retention in tmpfs or something. No disk churn, no permanent footprint. It's be an advanced configuration but I think people like you and I who want to downplay the size and churn of media cache would find it useful. |
I understand your concerns. I had a look in the code, and it seems like bypassing the cache would be a complicated endeavour anyways.
Your split cache idea sounds good, but I'd like to add one more thing to that idea: It would be great if local media, remote media, and interacted media would be treated differently. If you're someone who likes to look through their own favourites often, it would be good to keep media of favourited/bookmarked posts around for longer (or indefinitely).
|
This is soooooort of what we have already if you set your |
I'm actually not sure if it's a good idea to include avatars and headers in If I set that to 1, then all avatars and headers of all users I follow will be redownloaded daily, essentially creating more load on other instances than without any cache. (due to lack of browser caching) Or will it be a separate option? |
Currently no, it's included alongside post/status attachments. But three days or so is also a reasonable setting, you're still not gonna be keeping that much media on disk, and I think making one GET request for a couple images to an instance every 3 days is reasonable. |
I'm going to close this now. It's not possible to turn the media cache off entirely, but as of 0.13.0, it will be possible to tune it very aggressively so that you're only holding media locally for ~24hrs, and that includes avatars, headers, and emojis, so you can keep your storage size very small indeed. |
Is your feature request related to a problem ?
GoToSocial is designed to run well on affordable hardware, but the media cache quickly fills up any storage space.
I'm running a single user instance with only myself in it, so the cache has little benefit compared to downloading media directly from the remote URL.
Describe the solution you'd like.
I'd like to have an option in
config.yaml
that lets me completely disable the media cache. Media is then never downloaded, and the client API returns only external URLs.Describe alternatives you've considered.
I have considered setting the media cache period to 1 day, but it still creates a lot of uneccessary read/write activity that I believe can be avoided.
Additional context.
With an option to disable the media cache, GoToSocial could be extremely lightweight and run on a tiny SD card.
The text was updated successfully, but these errors were encountered: