For RUM providers, there’s a clear need for native compression APIs. Demonstration of such use-cases are User timing compression and ResourceTiming compression.
While gzip can be implemented in JS, there are performance costs to both downloading the script as well as runtime efficiency.
Other compression types (e.g. brotli) as well as inflate support could be interesting to expose as well.
Sounds good to me, As you mention supporting other formats would be interesting so making the API as such would be a lot more future proof.
let gzipFile = await navigator.compress(file, {format: 'gzip'});
Where the compress method returns a promise and accepts options on format etc.
Encoders/decoders such as this should be built as transform streams.
Yup, totally forgot the streams spec even mentions it in example uses. 
This would actually be very useful. I’ve changed my view a bit since my comments in the other thread: zip.js works pretty nicely, but can often end up janking on synchronous manipulation of blobs (copying/slicing/creating etc). It also does not seem to be able to take advantage of multiple cores, only offloading work in to a single web worker (although I don’t know how many compression algorithms can be effectively loaded across multiple cores). I think moving this in to the browser would make it easier to take advantage of in a fully asynchronous way.
I’d also point out I think the ability to compress and decompress data should be treated separately to the support for archive file formats, such as the .zip format. Both are useful and they are of course related, but compression of raw data doesn’t obligate support for an archive format.
I certainly would love to see some progress on this!