The algorithm is pretty simple.
Each byte in the buffer is interpreted as a little-endian 16-bit integer, padded with zeros, and added to the result.
Note that this means that the buffer must be 16-bit, or 2-byte, aligned, or else a zero will silently be appended.

This can effectively use 2.5 digits per byte, as every such integer holds 2 bytes and takes up 5 characters.
Although this would be more efficient with 53-bit integers, 16-bit integers being 8 bit aligned makes encoding/decoding much easier to implement.
Using other 8 bit alligned sizes, like 32 or 48, is not any more efficient; for instance `(2**48).toString().length / (48 / 8)` is still 2.5.
Of course this method cannot use every combination of digits available; an even more efficient way would be using huge big integer values to store data, but implementing these is out of scope.

The originally conceived purpose for this algorithm, was for encoding IP packets into cloud variables, to network Scratch projects together and with the wider internet.
This may be impractical due to length and/or rate limits on cloud variables, however some cloud servers are more lenient than scratch.mit.edu's, and I intend to run my own.
While I'm not sure if connecting projects to the internet is allowed on scratch.mit.edu, this isn't too major of a concern considering I have my own Scratch website clone.

However, it is worth noting that this can be used to encode text if an appropriate character encoding, such as ASCII or UTF-8, is implemented.
If I remember correctly, UTF-8 over packed16 is more efficient than using _Numerical Encoding V2_, an extension written in JavaScript.

In case terms are unclear:
* a bit is a binary digit (0 or 1), a chunk is a fixed-size (16-bit here) integer used in encoding
* a byte/octet is a combination of 8 bits
* efficiency is measured in how few characters can be used to encode each byte