Tech Talk: The Dingus and the Gooberizer

If you want to think of this as a PocketBible 3 for Windows progress update, you wouldn’t be entirely wrong. You will surely be disappointed, but you won’t technically be wrong.

The Dingus

We’re experimenting with giving you access to AI-generated commentary and other tools in the Autostudy feature in PocketBible 3 using the ChatGPT API. You won’t have to have a ChatGPT account to use it; we’ll create the prompts and automatically submit them and get responses for you to include (if you’d like) in your Autostudy output.

ChatGPT uses Markdown in its responses. Markdown is an easy way to create formatted text with a plain text editor. PocketBible use HTML for this purpose, which is a very different and more difficult way to create formatted text. So we have to convert from Markdown to HTML to display ChatGPT results in PocketBible. This is not straightforward, as Markdown wasn’t “designed” so much as it was pieced together as needed.

When the nerds who power our tech economy were asked to come up with a “standard” for Markdown, they discovered that even its most formal definition was ambiguous. If someone asked, “What happens if you overlap bold and italic markers in the text?” the only way to find out was to try it and see what happened. In order to make it easy for users to experiment and deduce the rules, they produced what is known simply as “the CommonMark Dingus” — as in “that whatchamacallit on their website”. The Dingus lets you enter text using CommonMark syntax and it shows you how it will render and what HTML tags are required to get the same result.

The Laridian Dingus

After laughing about the CommonMark Dingus every time I used it, I realized the only way I was going to be able to interactively test my server-based Markdown to HTML converter was to write my own “dingus”. Turns out it’s actually not a bad idea. I see now why they created it.

The Gooberizer

While writing this, I (Craig) was reminded of some PocketBible code. Back around 2002, my programming partner, Jeff Wheeler, was working on the DailyReader app. At the time, daily devotional books and Bible reading plans were not a part of PocketBible, but rather, you needed a separate app called DailyReader.

Since DailyReader didn’t know how to read PocketBible books, and since Palm OS, the hot mobile operating system at the time, didn’t have a file system (!!!), we had to come up with a way to store the text of reading plans and devotionals in a way that would be compatible with a Palm OS database, would be quick and easy to decode, and wouldn’t be readable by humans.

Of the two of us, I was the guy who had experience with encryption. I had implemented a simple encryption algorithm that we were able to use on our website and in our apps when we needed something “secure enough” — not something you’d trust your credit card number to, but good enough to obscure other sensitive information that we don’t want you messing with. So Jeff came to me to figure out how to obfuscate his DailyReader data.

“I don’t need some kind of unbreakable encryption. I just want to goober up the text enough that it can’t be read by the average user,” he said. I picked up on Jeff’s goofy terminology and created the skeleton of code called “The Gooberizer“. I created a simple encryption algorithm with a symmetric key — as long as the producer of the encrypted file (his little program that created DailyReader books) and the consumer of it (the DailyReader app itself) use the same key, one can encrypt and the other can decrypt the data. In order to make it slightly more secure, the secret key is not something stored in the program, but rather is computed based on the data in the book. This made it harder for a nefarious (or curious) user to break the code and ungooberize the text for himself.

Jeff fleshed out the code from my design and DailyReader soon had fully gooberized text.

PocketBible and the Gooberizer

Three years later I was adding some code to PocketBible and needed a way to authenticate an LBK (Laridian Book) file. We had decided to release our BookBuilder app as a commercial product but didn’t want a rogue competitor to use it to reproduce our entire library and put us out of business. So we put information into the LBK file that tells us that the file was built by the consumer version of BookBuilder. We needed a way to verify that these imaginary rogue competitors (who were growing more vile and contemptible the more we thought about them) weren’t tampering with the info to convince PocketBible that their books came from Laridian.

Then I remembered the Gooberizer. I rejiggered the Gooberizer code so it could produce a one-way hash of any string you gave it. The idea is that BookBuilder would build a string based on critical values in the LBK file, then store the gooberized string in the LBK itself. When PocketBible opens the file, it builds its own copy of the critical-values string and produces its own gooberized representation of it. If the stored goober and the runtime goober match, you get to read the book.

But seriously…

It can be embarrassing when the terminology you use around the office to describe something makes its way into public. You casually refer to your experimental test page on the website as “that dingus” and the next thing you know it becomes the most important part of your project.

Fortunately, we don’t foresee any need to give the public access to the Gooberizer. So for now it’s our little inside joke. Until somebody decides to write a blog article about it.