std/compression

Compressed bytes: DEFLATE (RFC 1951) with Bytes.deflated and Bytes.inflated, gzip (RFC 1952) around it with Bytes.gzipped and Bytes.gunzipped, and the Bytes.crc32 gzip checks a member with; and the two byte-oriented block formats of the Snappy and LZ4 projects, Bytes.snappyCompressed with Bytes.snappyDecompressed and Bytes.lz4BlockCompressed with Bytes.lz4BlockDecompressed. All of them are methods of Bytes, imported by the name of the list they extend: use Buffer.gzipped from "std/compression". What a package archive of the registry is compressed with (docs/design/RELEASE.md section 7.2), and what an HTTP body with Content-Encoding: gzip is.

Ordinary TorbScript over Bytes, with no native. Inflating reads every stream the format allows - stored, fixed and dynamic blocks, and gzip members one after the other. Deflating is deterministic and simple: one block of the fixed codes, with a greedy match search over the last 32 KiB. It compresses text to roughly half, where zlib's dynamic codes get to a third; what it writes is the same for the same bytes on every machine, which is what a reproducible archive needs, and any inflater reads it.

Snappy and LZ4 trade ratio for speed: literals and copies of whole bytes, no entropy coding and no checksum, which is what the wire formats of MongoDB (Snappy) and Kafka (Snappy, LZ4) put around a message. Both write one block - the frame formats come beside them - and both compressors are greedy and deterministic. A Snappy block holds the length of what it decompresses to; an LZ4 block does not, so Bytes.lz4BlockDecompressed is told the largest output it accepts.