A contributor to Telegram Desktop has once said at https://github.com/telegramdesktop/tdesktop/issues/5317#issuecomment-502341782 that it's not useful to raise the quality of JPEG photoes compressed by client-side applications because “the server itself compresses the photos” and “most of the compression is performed by the server”.
Hence the suggestion that is very simple: Telegram should stop performing server-side JPEG-to-JPEG recompression because such recompression has several important demerits.
Server-side JPEG-to-JPEG recompression makes it nonsensical to improve client-side JPEG compression. Telegram Desktop's decision to use MozJPEG (see https://github.com/telegramdesktop/tdesktop/pull/8787 for details) and the same (earlier) decision of Telegram for iOS (see https://github.com/TelegramMessenger/Telegram-iOS/commit/e1432e41711f5b114e338e81522ad73a3f4f5645 for details) does not mean much if the server then uses some visibly worse JPEG encoder that cannot even generate progressive JPEG (see https://t.me/kepka_support/15058 for details).
Server-side JPEG-to-JPEG recompression results in generation loss (see https://en.wikipedia.org/wiki/Generation_loss for the definition). The most popular pictures (the pictures that are saved and sent again the most often: the memes, the spectacular photoes, the screenshots of awesome news, etc.) are the most “punished” by the quality loss.
Server-side JPEG-to-JPEG recompression is likely to incentivize unofficial clients to create JPEG files of exorbitant quality (when compressing PNG-to-JPEG, for example) and thus to lengthen the delivery in order to ensure that the only quality loss is server-side.
Server-side JPEG-to-JPEG recompression is costly. It involves the expenditure of the precious server-side CPU cycles (and these are so precious that Telegram intentionally refrains from GIF-to-MP4 recompression of files greater than 10 megabytes despite the larger filesize-related gains for them). In addition to that, and perhaps more importantly, server-side JPEG-to-JPEG recompression also generates (because of the generation loss) many files containing the same image on different stages of recompression and thus the expenditure of server-side storage for all of these files.
Telegram should get rid of all that demerits: Telegram should rely solely on client-side JPEG compression. The only server-side JPEG processing should be simple (not CPU-intensive) tasks such as removing of geotags (for the sake of better privacy) and trimming the files' tails (to prevent any RARJPEG) and the inevitable check of images' parameters to enforce the simple set of rules that are imposed on client-side JPEG compression; and these rules should be made public.
For example, compressed images in Telegram cannot exceed 1280×1280 pixels, and thus server should reject client-sent JPEG images wider or higher than this limit with an error (instead of attempting to recompress).
For example, Telegram servers can reject large JPEG files with an error if the file is larger than, say, one or two megabytes.
For example, Telegram servers can reject JPEG files based on their bytes-to-pixels ratio, requiring no more than 6 or 7 bits (of the encoded files) per pixel on average (not to be confused with https://en.wikipedia.org/wiki/8-bit_color of the decoded images).