Skip to content
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

Closed
Fell opened this issue Jan 31, 2023 · 7 comments
Closed

[feature] Option to disable media caching #1405

Fell opened this issue Jan 31, 2023 · 7 comments
Labels
enhancement New feature or request

Comments

@Fell
Copy link

Fell commented Jan 31, 2023

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.

@Fell Fell added the enhancement New feature or request label Jan 31, 2023
@turtlegarden
Copy link
Contributor

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.

@trysdyn
Copy link

trysdyn commented Jan 31, 2023

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.

@Fell
Copy link
Author

Fell commented Jan 31, 2023 via email

@tsmethurst
Copy link
Contributor

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.

This is soooooort of what we have already if you set your media-remote-cache-days to something like 1: media you upload yourself will always be kept forever, but remote media will only be cached for a day and then dropped, minimizing disk space usage while also avoiding aggressive hotlinking. On 0.6.0 this isn't that useful because it doesn't include avatars and headers, just post attachments, but on the new version we're gonna release soon, it will also uncache avatars + headers too.

@Fell
Copy link
Author

Fell commented Feb 1, 2023

I'm actually not sure if it's a good idea to include avatars and headers in media-remote-cache-days.

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?

@tsmethurst
Copy link
Contributor

tsmethurst commented Feb 1, 2023

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.

@tsmethurst
Copy link
Contributor

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.

@tsmethurst tsmethurst closed this as not planned Won't fix, can't repro, duplicate, stale Dec 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants