treat images sent as files as such

[r10s]

when an image is sent as a Viewtype::File, it is sent and received as Viewtype::Image, for historical reasons ¹.

this has the disadvantage that the user is not aware of the impact - as increased size, transmitted filename. showing as file also make more clear that the file is really an original file, so may include other data.

for these reasons, other messengers, as telegram, show images sent as files as files.

for outgoing files, the conversion is removed at #8166

for incoming files, we need some flag on the wire. to stay compatible with existing versions, so that not suddenly all images are rendered as files.

the Content-Disposition: header comes into mind for that flag

current headers for (A) images sent as image:

Content-Type: image/jpeg
Content-Disposition: attachment; filename="image_2026-04-24_21-11-19.jpg"
Content-Transfer-Encoding: base64

for (B) image sent as file:

Content-Type: image/jpeg
Content-Disposition: attachment; filename="IMG_1681.jpeg"
Content-Transfer-Encoding: base64

idea is to sent (A) as Content-Disposition: inline (inline does not need a filename).

on the receiving side, images will be rendered as images if set to inline or the filename starts with image_ - the latter can be removed some versions later and is needed to not suddenly render all images as files

Footnotes

1. history: the auto-conversion comes from a time where we had few options in UI to distinguish. meanwhile, on all platforms the user can select between ↩

[Hocuri]

The effort/impact ratio doesn't seem good enough to be a "low hanging fruit". Personally, I even like that files are converted to images, because it allows me to send a file at original quality while still seeing the image directly in the chat. And while I'm not against this change overall, I'm not sure how much it improves things:

• Pro users use the "select as file" trick because they know that it sends the original file
• Non-technical users will often not even manage to select an image via the "File" selector, and if they do, then they will not be able to tell whether "10MB" is a lot or not.

As I said, I'm not against it, though I tend to say it's not worth the effort.

[link2xt]

Personally, I even like that files are converted to images, because it allows me to send a file at original quality while still seeing the image directly in the chat.

As far as I understand the idea is then also to improve the UI for file display, so if viewtype is a file, but mime type is JPEG, display file with a filename and size but also allow to see the image.

[r10s]

@Hocuri yeah, i see the point. but then we should also not merge #8166

going for "always sent files as such", may produce some follow ups and create noise. e.g. those using the existing behaviour as a hack to send images in hq, may not like that they are not rendered as files, and may request a dedicated hq-option (as others have, i am not too sure about that)

pros for "sending images as files and display them as files":

• it is visually clear that an image consume lots of data
• it is clearer, that the image is sent as file, so it is more expected that this may reveal name, phone model, location
• ppl will not use that option "just so", it looks very different from a normal image, this lowers the incentive to send images always that way (which is unwanted: images are more often received than sent, with chatmail, saving data is needed etc.)
• no more surprises: currently, when sending an image as a file, some may be sent as a file anyways (.heic), some as image (.jpg)
• this is what other messengers, e.g. whatsapp or telegram are doing as well (signal does not, but iirc signal does not really care about data anyways, eg. they did add recoding just recently)
• receiver can learn by receiving an image that way, how to send it

cons:

• ppl using that as a hack to send files in "high quality" might be unhappy and complain (however, already now we have complains in that area :)
• some adaptions needed in UI (we may want to show the thumbnail as telegram does), that seems easy, however.
• follow-up may be a "high quality" option or discussions around that - i am not a big fan of that, esp. as long as there are options to get away without, as recent screenshot adaptions. ideally, core should decide on larger resolution, by some probing and checking level of image detail
• images sent as files will not show up in gallery or needs special treatment (this is true for whatsapp/telegram as well, but still quesionable)

EDIT: k, this will cause too much noise just now. we can reconsider at a later point, but it is good to figure out what not to do :) thanks all for helping on figuring that out