[feature] Hotlink uncached media files in status

[AkazaRenn]

Is your feature request related to a problem ?

In the current implementation, status with uncached medias will be appended a long warning and the link to the media file, that caused me some frustration because it's not very pleasant getting interrupted by things like that. And I feel like it's not a good practice to present a federated status in a way that it wasn't made to be originally, as that would break the "trusts" in federation.

ℹ️ Note from <domain>: 1 attachment in this status was not downloaded. Treat the following external link with care:

Describe the solution you'd like.

Hotlink the medias that is beyond remote-media-max-size limit. I understand that it was considered rude to hotlink a media that doesn't belong to me, but I feel things have changed enough now. Many object storage service providers don't charge anything for egress (Wasabi, Backblaze, Cloudflare R2), so hotlinking is much more harmless than years ago, at least for me I don't mind people hotlinking to my media because I'm running on one of those services. We can probably add some more explanations in config.yaml and allow the admins to choose, without sacrificing modifying people's status.

Describe alternatives you've considered.

There's no alternative that has come to my mind for now.

Additional context.

Related discussions:
#2713
#1405

[NyaaaWhatsUpDoc]

i think is one us devs will need to have a think about both in whether to and how best to do this, both from the standpoint of the code this might produce and the potential outcomes of this.

[tsmethurst]

Mm, in my view I don't think hotlinking is the way to go here for a few reasons:

1. The media might just not be available because the remote instance is down, in which case the hotlink would break anyway and leave an even more confusing gap than the little notice we currently serve.
2. Remote instances might not have CORS set up properly to allow browser-based clients to download the media, again leading to a gap / warning messages / less signposted breakage.
3. I think (have to check this) that some android + ios clients will sanitize hotlinks out of statuses, so even if we hotlink and the media is there, and CORS is OK, users might not see the media anyway depending on client, which is a pain in the arse for us as devs :P
4. We might end up hotlinking to malformed media.
5. Hotlinked media won't have exif tags removed by our sanitizer, potentially leaking stuff like GPS location etc if it wasn't properly sanitized by the instance it was uploaded on.

Personally for now I'd rather leave it as-is because I think it's basically fine to show a link with a warning, and I don't think introducing hotlinking provides enough benefit to compensate for the potential difficulties.

[AkazaRenn]

Mm, in my view I don't think hotlinking is the way to go here for a few reasons:

1. The media might just not be available because the remote instance is down, in which case the hotlink would break anyway and leave an even more confusing gap than the little notice we currently serve.
2. Remote instances might not have CORS set up properly to allow browser-based clients to download the media, again leading to a gap / warning messages / less signposted breakage.
3. I think (have to check this) that some android + ios clients will sanitize hotlinks out of statuses, so even if we hotlink and the media is there, and CORS is OK, users might not see the media anyway depending on client, which is a pain in the arse for us as devs :P
4. We might end up hotlinking to malformed media.
5. Hotlinked media won't have exif tags removed by our sanitizer, potentially leaking stuff like GPS location etc if it wasn't properly sanitized by the instance it was uploaded on.

Personally for now I'd rather leave it as-is because I think it's basically fine to show a link with a warning, and I don't think introducing hotlinking provides enough benefit to compensate for the potential difficulties.

Thank you for sharing your thoughts, but I feel that most of your points are not in a better situation in the current implementation:

1/2. If the remote server is down or blocks browser access to the media, the added URL in the status cannot lead to anything either.
3. It's the problem for the client to deal with, no? And there are other implementations allowing hotlinking on even all medias (Pleroma) so it won't only be the issue after GTS makes the change.
4. Same as 1/2, accessing via browser would lead to the same result. And wouldn't that be worse if we cache malformed media to the server?
5. It's the original servers' choice to sanitize the media or not, they may choose to share that on purpose. I don't feel like hotlinking a media would cause any more trouble when the media has been shared in that way already. Also same as 1/2/4 EXIF information is still available via the link anyways.

I just want to say we are talking about hotlinking medias that are not cached, not all of them, so it's actually only about appending warning and URL to the status texts vs embedding URL naturally into the status, instead of caching vs hotlinking.

[tsmethurst]

Re: 2, CORS doesn't apply if the user is accessing the media directly in the browser rather than having it load as one of the resources on the page.

Re: 3, yes sort of but not really. Most of the clients GtS is compatible with expect statuses that look somewhat like Mastodon or Glitch statuses, neither of which (I think?) use hotlinking. So we can't predict how those clients will render hotlinked media in status HTML, and people may well open issues assuming that something is a GoToSocial bug rather than a client bug, which is a pain for us.

Re: 4, we don't cache malformed media (ie., media that fails to be run through our exif terminator + embedded ffmpeg) -- that's why we add the "treat the remote link with care" warning.

Re: 5, yeah fair point.

Just to clarify I don't think hotlinking is like, the ultimate evil or anything like that :') I'm just wary of introducing more potential complications and states into the software which might make our lives difficult for relatively small benefits.

[AkazaRenn]

@tsmethurst yeah I totally understand your thoughts, and thank you for clarifying up things! I just want to make one more point about clients, if a client is ignoring all other implementations already I don't feel like it's good that we take them too seriously, since that would do nothing but add fuel to the dominance of Mastodon in Fediverse. However, I agree it is a pain to explain to people that the problem is the client not server every once a while, just hope things can get better in both ways!