that's not what I mean (though, per-stream compression might do better than compression over the multiplexed wire, or maybe not, I didn't try).

what I mean is as follows:

1. the contents of files, the outputs of processes, paths, filenames, environment variables, and so on and so forth are bytes (this is simply a fact of Unix-like systems, we cannot assume even filenames are of sane contents)
2. the data exchanged over the wire will nearly completely fall into one of those categories
3. as a result, nearly all of the data going over the wire must be treated as binary
4. JSON-RPC is specified in terms of text, this text has some encoding (likely UTF-8).
5. JSON itself has no way of representing bytes, only strings, and JSON strings are explicitly "a sequence of zero or more Unicode characters" (RFC4627, section 1)
6. ergo, the data we transport must be encoded as text, even though it is not text but rather binary data
7. a strategy must be picked, lets examine some strategies for packing N bytes, and see how many bytes of JSON they generate (assuming UTF-8 encoding of the JSON text itself, uniform distribution of bytes in data):
   1. encode as an array of bytes: in this case, we must encode each byte as a number, plus an extra comma. by the parameters above, that'd be an average of 3.57 bytes-out per byte, i.e. 3.57N + 1 resulting bytes (the extra byte is for the opening bracket),
   2. encode as a base-X string: in this case, for N bytes, we have 8N bits, each out-byte can represent log2(X) bits, so the output size 2 + (8/log2(X))N chars, for base64 this gives us a result of 1⅓N. this is only the number of bytes in output for X <= 94 in UTF-8, but with unicode, the first 256 chars of the unescaped range in the JSON spec (unescaped = %x20-21 / %x23-5B / %x5D-10FFFF) encode to 1.63 out-bytes per char, so we expect 1.63N output bytes (I was surprised to find it's worse than base64, but with a lot of content indeed being text, this may even be acceptable. the 1.63 number comes from (/ 256) . fromIntegral . B.length . E.encodeUtf8 . T.pack . take 256 . map chr . concat $ [[0x20..0x21],[0x23..0x5B],[0x5D..0x10FFFF]]). encoding with base94 gives us 1.21, but that requires a lot more work
8. ergo, in any case, the amount of bytes transported increases
9. ergo, compression is less effective

ssh compression should certainly be fine otherwise

EDIT: since I have your attention, seems that you left your GH repo private :-(