Designing a File Format

When it comes to decisions, I would say that the very idea of the project (to usurp Base64) was a lofty goal, and the fact that I made something that is technically a Transfer Encoding, yet features compression and encryption, makes this program a special case. Because your archiver now has to deal with an open standard that outputs TXT files in UTF-16BE with a .B3K file extension. Now, the idea itself was a bit out there, but the implementation decisions are too. I chose to use efficient compression that wouldn’t crash browsers, and the fact that this was written in JavaScript is proof of the idea being a feffadoo. Also, using a Byte Order Mark as half of the header magic number is funny. And the decisions to use a short header and footer and no AES padding due to CTR was neat. This whole project was full of decisions. Also, adding compression and encryption came later in development. Additionally, compatibility was a decision. I made many eclectic choices here, and it went well. Oh, and a really silly decision I made was to give this program (and my SoundFonts) an OS-tan, and give THOSE fursonas. This whole project was based on wild ideas and wild decisions, but that’s what makes it fun. A file compressor with encryption that outputs to TXTs and isn’t binary. A wild idea that just so happened to work, backed up by a lot of choices.

Now for process, I would say that a lot of it was selection, trying to find what would cooperate with each other, and going from there. Also, the logistics of getting it all to work together involved a TON of luck and debugging. It was an absolute feffadoo to debug (feffadoo = 0xFEFF4D00, the program’s header), but it ended up working out in the end. A 17yo creating a file format would be on the level of TempleOS. Ultimately, my process was: make it work, no matter what.

As for what I learned, I would say that I learned that JavaScript is more forgiving than compiled languages, despite its quirks. Oh, and that debugging is an absolute feffadoo. Also, compatibility is important. Additionally, sometimes silly quirks can save the whole thing. Also, teenage code can be noble in the long run. Also, sometimes what one assumes people will think of something is not at all what they actually think. Also, computers aren’t exclusively binary, and nor are files. .B3K files are nonbinary files. A base of 32768 is NOT a base of 2 (binary).