The mediarepo should support transcoding image thumbnails

[Half-Shot]

Slightly related to https://github.com/matrix-org/matrix-doc/issues/1938

This came up as part of https://github.com/matrix-org/matrix-appservice-slack/issues/578. We realised that Discord supports (and may even exclusively use) webps for avatars but Slack only allows jpgs/pngs, which means there needs to be transcoding at some point to make Discord avatars show up on Slack.

To that end, it's difficult to say where the transcoding should lie. Should the Discord bridge convert to PNG to aid older Matrix clients / operating environments and bridges, or should the Slack bridge embed the converting logic for any non-supported image. An argument could be made for either, but I'd like to suggest that the media repo should support this behaviour.

The reasons are:

• The media repo is likely to already be concerned with the converting and processing of media for thumbnails, so the inclusion of transcoding logic is unlikely to increase the dependency footprint of the software.
• Supporting it at the repo end means that other bridges / clients can also benefit.
• We could instead try to campaign clients/protocols to support more formats rather than transcoding at all, but typically this is harder to do if you are on an older device / non-cooperative protocol.
• Importantly media repos can cache a transcoding job for other clients/bridges to benefit too, so less duplication of work.

However the drawbacks are that are by making the media repo do this, it does mean there is more opportunity to cause DoS attacks by making the media repo complete difficult work (especially if the work is not limited to images).

It's clear that at some level, we will eventually need to transcode media to support certain usecases and I'd argue that the media repo is probably the best home for it.

[kevincox]

This is related to https://github.com/matrix-org/matrix-doc/issues/1938. However that issue focuses mostly on downloading whereas this is mostly about uploading. I think the best solution is roughly the same though. Define some minimum supported list of formats that we require the media repo to accept, then the client can offer other formats (like whatever the source image is) and the media repo may or may not accept it. Then we are back to the downloading problem that was discussed there.

Of course E2EE always throws a wrench in things. It would be interesting if you could ask the sender (or anyone else with access) to convert for you. You could even use smart heuristics to figure out what formats are supported in a room. (For example if you send a WebP and the client asks for [JPEG, GIF] then you may just want to send a JPEG next time, of course if there are multiple recipients with non-overlapping lists it gets weird).