[feature] S3 browser caching

[LittleFox94]

Current S3 handling prevents any caching of media attachments, because we have a new URL every time we request a piece of media (as it includes a signature for auth/authz). This is especially problematic with browsers.

There is at least one way to work around this problem: instead of generating a URL that is valid "for $x minutes starting now", we could generate one that is valid until a semi-fixed timestamp. That semi-fixed timestamp could be something like "next hour from now, minute 42 second 23", giving us an URL that is valid for one hour and does not change, regardless of the time when you get it. See here for some more: https://stackoverflow.com/a/56543573/2537210

Proposal

When media is requested by a local, authenticated user, we hand out signed URLs for a semi-fixed timestamp of "$tomorrow $fixed-time". This URL is stored in database and every local authenticated user requesting that media gets redirected to this URL.

With this we would have a up-to-24h cache, much better than no cache at all.

[tsmethurst]

That seems sensible!

[NyaaaWhatsUpDoc]

I started brainstorming this and i don't think we even need it to be handled by the database. just a ttl cache of presigned fetch urls would do the trick

[LittleFox94]

Where would that cache be stored?

[NyaaaWhatsUpDoc]

In memory. We don't support running as a cluster so it's not an issue. Worst case it gets restarted, lose the cache and regenerate them again when necessary.

Or is there something I'm not seeing here?

[LittleFox94]

We don't support running as a cluster so it's not an issue.

Oh, we don't? What's preventing that if I have the database and media storage external (postgresql and S3)?

[NyaaaWhatsUpDoc]

A few things: mainly caching, and the way the go-fed/activity library is designed and how we have then implemented ourselves around it. We'd have to rearchitect a lot of things to support it

[tsmethurst]

closed by #1194