daenney
commented
6 months ago I think this would be a nice change to implement. It indeed seems a bit unnecessary to go out and fetch things that may never get displayed and it avoids the associated bandwidth and compute costs for both sides.
However, I think there's a few problems with what's being described here that we'll want to look at solving differently.
I'm not keen on overloading the meaning of "sensitive". It has a clear and understood meaning currently, and changing that to mean "or maybe it's just media we haven't fetched yet" under certain operating conditions is likely to cause confusion. We may be able to do something else, like a static placeholder image that we replace on-demand. That needs some thought to also make sure we don't run afoul of any caching of media the clients may do. When we fail get remote media attachments we already include a notice in the timeline, which may be another way of doing this.
Fetching the attachments on demand as we serve a timeline risks resulting in blocking the timeline endpoint. There's potentially tens of attachments we need to fetch, which could be reasonably big, from servers reasonably far away that are in that moment bandwidth or resource constrained. We probably want to do this in an asynchronous manner, and instead use something like the streaming endpoint to update statuses as media got fetched (assuming that's something we can do with the streaming endpoint in the first place). Here again we need to be mindful of any caching of the timeline the clients themselves may do, or it'll result in a very confusing experience.
SmallPatatas
Is your feature request related to a problem ?
One of the most appealing things about GTS (to me at least) is how light on resources it can be.
However I haven't seen many people mention total transfer volume. Based on the current average tx rate, my single-user glitch-soc instance will transfer a total of ~150GB/month. Nowadays, that's fine where I live, but might make running an instance very costly in other parts of the world, or in rural/remote places.
Now, I definitely recognize that simply not caching any media is rude, and that it's bad for the network overall.
But I also think it's unfair to expect every other server to use up bandwidth to receive images that no one explicitly asked for, and might never even be seen by their users at all!
Describe the solution you'd like.
So, a proposal:
A server-level setting where remote attachments are not cached when the remote post is made, but are cached as soon as any local account chooses to view the attachment.
(I'll be honest, I don't know if it's possible to create the 'click-to-cache' function that I'm imagining, because I don't have expertise when it comes to APIs or compatibility considerations etc. So, apologies if this is all very naive!)
Perhaps it could be done a bit like akkoma's strategy, where attachments are fetched when a local account is actively loading their feed.
But unlike akkoma's method, where remote attachments are fetched directly to a user's browser/app, I'm proposing that the gts server would fetch the attachment from the remote server, forward it to the local user, and cache the media.
Describe alternatives you've considered.
Another hypothetical solution: could a 'click to cache' feature be done by using the 'view sensitive media' button on existing apps and front ends?
So,
(the local gts server would obviously need to add an additional warning for attachments that are actually 'sensitive media').
Additional context.
Thanks very much for all your work :)