Fix compression description in readme

[Leptopoda]

Signal Android/Desktop

The file is gzip-ped plain text. The worker alters the response to indicate this; presumably, Cloudflare then picks the best compression to deliver the response to your browser (e.g. brotli). The browser uncompresses the response and provides it to the app in plain text.

So all compression work is done by Cloudflare and the browser; neither the worker itself nor the app.

IIRC CF only tries compression for a fixed amount of time. If it takes to long or the file isn't smaller the compression is aborted.
As the logs are already highly compressed CF won't touch it. The compression might still apply to the headers but I'm not to sure about that.

Also judging from the CF support article there is a list of mime-types they compress and who'd guess application/gzip isn't one of them.

This can be confirmed when having a look at the request in the networks tab as no header like content-encoding | br is applied to it.

I suggest the point 2 being unified into roughly what the ios text says

[awaitlink]

I removed the claims about Cloudflare's behavior in this section.

The behavior of Signal Android/Desktop is still different from Signal iOS, e.g. because Signal iOS's debug log archives contain multiple files and are of a different format, but in the context of this issue the relevant difference is that the web app itself doesn't perform the decompression. I'm not exactly sure, but I assume the browser (or its fetch API) performs it.