+
+ # There are compressed messages that legitimately end with the
+ # byte 0x00. The message "scott" is an example; compressed it is
+ # 0x98df4a00. It's 5 characters long which means there are 5 x 5
+ # bits of compressed info (25 bits, just over 3 bytes). The last
+ # (25th) bit in the steam happens to be a zero. The compress code
+ # padded out the compressed message by adding seven more zeros to
+ # complete the partial 4th byte. In the 4th byte, however, one
+ # bit is information and seven are padding.
+ #
+ # It's likely that this API's client code may treat a zero byte as
+ # a termination character and not regard it as a legitimate part
+ # of the message. This is a bug in that client code, to be clear.
+ #
+ # However, it's a bug we can work around:
+ #
+ # Here, I'm appending an extra 0x00 byte to the compressed message
+ # passed in. If the client code dropped the last 0x00 byte (and,
+ # with it, some of the legitimate message bits) by treating it as
+ # a termination mark, this 0x00 will replace it (and the missing
+ # message bits). If the client code didn't drop the last 0x00 (or
+ # if the compressed message didn't end in 0x00), adding an extra
+ # 0x00 is a no op because the codepoint 0b00000 is a "stop" message
+ # so we'll ignore the extras.
+ compressed.append("uint:8=0")
+