For comparison:<p>A sha512 hash in hex: 309ecc489c12d6eb4cc40f50c902f2b4d0ed77ee511a7c7a9bcd3ca86d4cd86f989dd35bc5ff499670da34255b45b0cfd830e81f605dcf7dc5542e93ae9cd76f<p>Same in this Base2048: ЗཟǷњϳݫЬߦՏԈ௰ڿƫ௪தͶޡഺཀވࡌੳٿ༲৩ত༥၄ঙџڸࠑحϷгଘƩƴߢய߅ϚƐγ๓ۑఞ<p>The encoding also seems to be HN-safe, using no emojis or other things HN filters. The font used here is lacking some of the characters, but that shouldn't matter if you just copy-paste.
That’s 2,598 tweets to transmit a single megabyte.<p>So, if I wanted to tweet the movie Spaceballs, encoded at 4K UHD (20MB/s), I estimate that I will need to make 20,945,455 tweets.<p>Twitter limits the posts made by nobodys (like me) to 2,400 tweets per day… so, it is going to take me just under 24 years to complete my task.<p>I’d better get started.
Related but opposite, a tool I made a couple of years ago.<p><a href="https://github.com/ctsrc/Base256" rel="nofollow">https://github.com/ctsrc/Base256</a><p>> Encode and decode data in base 256<p>> […]<p>> You might expect data encoded in base 256 to be more space efficient than data encoded in base 16, but with this particular set of symbols, that is not the case! Likewise, you have to type more, not less, than you would if you use my base 256 instead of base 16. So why?<p>> The purpose […] is to make manual input of binary data onto a computer less error-prone compared to typing in the base 16 or base 64 encoding of said data. Whereas manually typing out base 64 is painful, and base 16 makes it easy to lose track of where you are while typing, [this program] attempts to remedy both of these problems by using 256 different words from the EFF autocomplete-friendly wordlist.<p>Disclaimer: I am not using this base 256 program myself, even though I authored it. It just serves as a fun little experiment.
Hehe, this is both wonderfully useless and impressive.<p>I was experimenting with using Twitter as a CDN, here’s pong (3.5kb) in a single Tweet:<p><a href="https://twitter.com/rafalpast/status/1316836397903474688?s=21&t=cdc4cbXb_8uROEJTLiWDJw" rel="nofollow">https://twitter.com/rafalpast/status/1316836397903474688?s=2...</a>
This is something I used for the "tweet your BASIC code" functionality in atto (<a href="https://jamesl.me/atto" rel="nofollow">https://jamesl.me/atto</a>)... Trying to fit an advanced BASIC program in a single Tweet isn't too easy, but at least encoding it in Base 2048 beforehand is!<p>Example: <a href="https://twitter.com/jthecoder/status/1412848719737851905" rel="nofollow">https://twitter.com/jthecoder/status/1412848719737851905</a>
Heh, well that's one way to work around the inane Twitter character limit...!<p>My personal Musk dream is that he'll abolish that. If I never have to see tweets of pictures of text or tweets ending in `/n` again, it will be too soon.<p>Though, I sort of remember that Twitter was architected initially in a way that relied on the short tweets and it was a surprisingly complex change to even bump it up the little that they did recently, so who knows.
What about encoding data for image tweets? QR codes are limited to a few kB of storage [1] because they are designed for visual scans, but using higher resolution could get you more capacity.<p>[1]: <a href="https://en.wikipedia.org/wiki/QR_code#Storage" rel="nofollow">https://en.wikipedia.org/wiki/QR_code#Storage</a>
For those playing at home, you need at least base 4096 to equal the data density of base64, because utf8 uses two bytes for anything over 7 bits. It is only because of a somewhat arbitrary Twitter rule that this works. On Twitter.
I don't think Base-N names should be given to encodings that haven't been IETF standardized. This could lead to incompatible encodings with the same name.