Shearing Electric Sheep

LLMs are powerful tools for processing natural language, and in their original imagining, the goals were straightforward: translation, completion, that sort of thing. However, once we'd made a system capable of handling language we realized that this lead to a wide variety of emergent behaviors. Our models couldn't just guess what word would be next, but if given the right context and training, it would tell you seemingly new things.

If you train a bot to complete the next post of a dialog (i.e. a chat bot,) you can then say "Here's a long body of text. Could you please reply back with a shortened summary of it?" and the bot will correctly complete the next message of the dialog as though it were a helpful person doing a summary. All it was asked to do was guess what came next, but in doing so it had done work beyond completing the message.

Once we realized this, we noticed that the computers could do an absolutely astonishing amount of work. They could program by doing code completions from comments. They could write news article from headlines and details. They turned out to be exceedingly capable at a wide range of tasks. They would write the next token, then ingest the new message that existed with the new token, and write one more. This iteration would lead them to make entire, coherent documents.

But initially we thought they had a shortcoming in that they didn't seem to be able to reason through things. If they couldn't arrive at the answer initially from vibes alone - if working out the exact answer took multiple steps - then they were wildly ineffective. At tasks like math and (important for later) chess, the computer would simply throw out an answer, often without any coherence to it whatsoever.

Then one day we realized that as long as we asked them to show their thinking, and be sure to think out loud, the quality of their output increased substantially. It was enough to revolutionize how AI functioned, and models were trained that would start by emitting a thinking token before noodling about the problem for a bit, then emitting an end-thinking token and going on to its normal work. Overnight the AIs went from feeling like your drunk friend who's good at trivia to being competent tools capable of complex reasoning.

Now these models already exist, but I wanted to get a better feel for all of this and how it affected things (as well as get some stick time on the Ollama API,) and based on a funny chess video I saw on the internet where AIs played against each other I decided I would do this by making a chess playing program.

▌▌▖▌▖▘▌▖▖▖▌▖▘▖▖▖▌▘▘▖▖▖▌▖▖▖▘▖▖▌▖▖▘▌▌▌

Last week I ran across an interesting project that caught my attention called dollcode by a GitHub user by the name of v01dlabs.

Of it's own, it's an exceptionally straightforward project: encode numbers and strings using a ternary code based on some simple Unicode characters ▌▖▘. I've long had a fascination with the way barcodes are read and the signal processing that goes with it, so I dug in to the working logistics.

Unfortunately, as I fiddled with it and tried to understand how one might decode it, it became increasingly clear that there were some limitations to the coding being used. For example, the encoding for "x" is "▌▌▌▌‍" and the encoding for the number 120 is also "▌▌▌▌". Similarly, the encoding p is "▘▘▘▘‍", which, if you don't know how tall the barcode is, looks exactly the same as the encoding for "(" which is "▖▖▖▖‍".

So given the seed and some knowledge about signal recovery, I decided to set out to make my own variation of the dollcode signaling method.

In my design, which I ended up calling signalbar, I added several features to constrain the coding, and improve its recovery with flexible optical media (printed paper) as the primary consideration.

Rather than encode data directly, a 4-to-3 encoding would be used; 4 bits of information using 3 trits.

The minimum unit of transfer would be a nibble. This is convenient in the 4-to-3 encoding, but also means that sending data smaller than 4 bits would require the cooperation of a higher level protocol.

Each symbol would actually come from one of three symbol tables based on the last bit of the previous symbol. This would allow for error detection and make use of the unused codes.

Two ▌ trits in a row would never appear outside of control symbols. This would make detecting control signals very easy.

Framing symbols would be added that could be used to detect the beginning and end of transmission. These symbols would be the same in all three encoding tables to simplify implementation. The start symbol would begin with a ▌▌ and the stop symbol would end with ▌▌, ensuring that the edges of the frame would always be max height and even if read backwards would immediately trigger the ▌▌ control sequence detection.

Symbols would be chosen such that no arrangement of the symbols could possibly create an infinitely long run, and symbols would be chosen in a way to minimize the maximum run length. This would aid in both clock recovery and detecting the code height on paper that wasn't flat since you could guarantee that you would see symbols of different sizes in a known and short window.

There are several things I think might be useful, such as frame length encoding and check codes, but those logistics are being left to higher level protocols. This implementation is mostly about the encoder/decoder hardware; so anything beyond what that is beyond the scope of this project for now.

With that said, the signalbar repo itself ended up being a powerful opportunity to do some work with GitHub Actions (I had been using Gitlab CI/CD up till now, and Jenkins before that) so that was interesting, and with some more time, I may add some explicit tests to verify the function of the module. But even without tests, it was a great way to bring pylint and mypy to bear, and made refining the code very nice.

However, this was largely just an amusement since I hadn't done a lot of personal programming over the last few years thanks to work. I don't know if I'll go far enough with this project to truly finish it up. dollcode, and now signalbar, are interesting, but I wouldn't particularly regard either as especially useful; just a neat way of exercising the ol' braincells. Nevertheless, I recommend you go check it out; there are some useful ways to think about signaling that are trapped up in the specific implementation that this toy example should make fairly clear (such as how 8b10b encoding solves the self-clocking issue.)

On The Matter Of Shared Assets

I’ve been working a lot on a Ren'Py visual novel (more on that at some future date, novelling takes a LOT of time, and that’s when it isn’t also a programming/art/music project.) To help me make progress, I’ve been using a lot of free assets that folks have shared on the internet for the purpose. It’s been a massive boon for me, so I wondered if there was a way I could give back to these folks.

I’m not particularly notable as an artist, so just making a sprite or a background was probably not gonna work. I’m an adequate composer, enough so that my work actually kinda doesn’t sound out of place in the context of a VN’s background music. But that work is highly specific to my own VN, so I’d rather not share any of the assets I’m actually using since it would spoil the uniqueness of my work.

However, I somewhat arrogantly regard myself as a better-than-adequate programmer. In the course of writing my game it became apparant that I was going to need some mechanism for displaying instant messaging in a believable way. To that end, I wrote a quick library that would automate 99% of that work, and moreover, allow me to be very flexible in my handling of displaying it.

So I realized that an easy way to give back would be to make this automation framework available to everyone; hopefully helping the people who do all the cool art, but do Python kwargs unpacking not-so-well, make much better games.

Game jam!

Back in June I put together a game jam (my second) to try and bring together a team of artists and developers to produce a simple game in not more than 24 work hours. I ended up getting a team with 6 folks on it. Four worked locally, and one artist worked remotely.

My primary role was project manager / team lead. However, with 6 folks and 3 business days worth of time, you can't exactly just sit back and play manager all day so I did a bunch of odds and ends for the team including programming game mechanics (I handled the victory condition testing and game controller,) sound design, devops, etc. Nevertheless, I ended up spending appreciable time doing managerial tasks. My team had a wide diversity of people on it, and keeping them happy and focused on our objectives took an appreciable amount of effort.

This wasn't surprising, and turned out to be why my role was "project manager" this time rather than "programmer". With Meat Box we had realized after the fact that we missed a number of our secondary development targets because of coordination and focus. To be precise, the issue had been too much focus. Both the art and software teams at one point or another found themselves bound up on a task, and rather than trying for a bit and then refocusing on using an easier workaround, both teams ended up digging in their heels for several hours trying to get it to work the way that it was originally planned.

Having a dedicated project manager, whose first job was to keep the team on being effective rather than being perfect, was the indended solution to that problem. As such, my goal this time around was to keep my eye on the workflow and make sure everything went smoothly. However, we ended up with a new team dynamic this time due to some new members and I found myself quickly being involved more directly with human resource management. It was definitely challenging, but we got through it and delivered more than the minimum viable product for our objectives, which is always impressive to me given how bold we are in specifying the game.

If I'm being honest, I was especially amazed with the assets provided by the art team. I know it's probably because I'm not exactly a graphic artist, but they produced a TON of assets for us in the blink of an eye, with turnarounds that were fast enough for us to see them live typically by the time we were ready to use the asset in the level.

As you may know, I've been working on Gummybot for a long time. He's monolitic, he's kludgey, and he's built to support IRC, which itself is ancient and kludgey. But much like IRC, Gummybot serves his intended purpose (teaching me PERL and filling in for the poor, dead owlbot) quite well.

Yet time moves on, and rather by accident, so to has the ATG chat. A side effect of me trying to make my IRC experience more productive and less awful was that I used a prefabed bridge bot (which is it's OWN set of problems, believe you me) to connect the ATG to a Discord server. Discord, if you haven't heard of it, is a text and chat video service hosted on the cloud. This means I can't kick it when it breaks without getting a tresspassing charge, but in exchange, it allows for push notifications to mobile and desktop clients, and it also maintains a log of all messages that are sent and organized them for review if you look away for a bit.

As a result of me building this bridge though, just about everyone moved over to the Discord end of that bridge. Though this is great for me since it means I can use Discord specific features to chat with most of them. However, this is not so great for poor Gummy. You see, the downside to the bridge is that it looks like a single user on both the IRC and Discord side. So if three people talk on Discord, on the IRC side, the nick is always the bridge's. The message body includes the end user, but anyone/anything that depends on the nick to identify the speaker has a problem. This includes some auto-reply tools, and obviously Gummy.

Well, I could retrofit Gummy to detect that the bridge is talking, and then attempt to rework the entire messaging system so that it's compatible with non-IRC nicknames (a huge undertaking with relatively little skill payout,) OR I could pick a new language (node.js) and a new communications library (Discord.js,) and re-implement the most critical functions that are nick-specific there instead.

And from that I annouce Discorded*Gummy! He's actually on his second revision already; the first was made months ago to bring the most critical function online: memos and nick-linking. Honestly what I've got currently doesn't appreciably change that. However, what it does do is something that was needed back at the very beginning with the original Gummybot that IRSSI's plugin system didn't allow for trivially: modularization.

At the heart of this project are VPN tunnels. Since this is an overlay network, the physical links for the network are through several NAT isolated links to the Internet. As such, it is critical that network tunnels be used to establish a virtual cable between the various nodes in the network.

However, tunnels are always a bit of a weird experience. I’ve done a lot of work over the year with small-scale OpenVPN tunnels for connecting my own PC to my home network while roaming, but I knew there were several other tunneling technologies out there.

DNS in DotNQIG is a bit of an interesting challenge. The reason is that we still want domain resolution to work for the Internet, but we want systems participating in DotNQIG to be aware of the .NQIG top level domain (TLD). In the real internet, this would be done by registering a new TLD with the ICANN root servers.

However, doing that is actually not possible. Although a few were added recently, like .photography, the reality of the matter is that ICANN does not add TLDs. But more than that, we wouldn’t really want them to; this is intended to be a private LAN, and none of the addresses we’re using are routable from the Internet anyway. So we had a problem: how do we overlay our domain system onto the real one?

Okay, so I said I'd cover DNS next, but I wanted to get this out first.

First, though I kinda hinted at it rather loosely, I got my friend Oni to do their bit of the network on Friday. This really helped me work out some stuff that wasn't immediately apparant with my fully private setup; DNS turned out to be a big thing I needed an external peer to see all of the problems with. So yay for having people to connect to! But that also means it was time for a new network diagram.

On that front, I did a bit of playing around with Dia, a FOSS tool for drawing diagrams. With a bit of work, I was able to get a network schematic put together. I was even able to keep my notation where hostnames are italic and bridges and networks are done in bold.

When we decided to start this project, one parameter that was defined early on was that routing tables had to be dynamic; i.e. it had to be possible for new nodes to be added to the network without every person in the network having to hand add the new nodes. On the scale we’re working it’s probably not a big issue, but if nothing this would give us a chance to learn a bit about dynamic routing protocols.

We settled on OSPF as we were making a network that most resembled an inter-office network and OSPF is well suited for internal networks. As such we needed to lay down areas and setup an OSPF server on the routers to get them to share routing tables. The first step was to determine which software to run.

So the first step in this project turned out to be both easier, and harder than I had originally expected. The reason is that initially I had expected to have a lot of trouble getting the XEN systems prototyped and built. In the end, however, it turned out that XEN-Tools made it surprisingly easy to establish a template system and the build out from there.

What was less easy was making (and routing) the necessary bridges. As you can see from the network architecture diagram, the goal was to have two bridges so that from the most distant virtual machine to my main network was at least two hops. On those same lines, the router on my main network that handles my gateway to the internet isn’t smart enough to route packets between subnets on the same LAN port.

Short update. I've modified the network topology from the one in the chart and added node1. node1 does a lot of the routing blocky used to do. Now, blocky has no ip on privbridge, and instead node1 has an interface on both the physical bridge and also on privbridge.

Presented here is the network topology for the DotNQIG project test bed. Chao is my main PC, and it played console for everything. blocky is the aforementioned XEN VM server and primary router. node2, node3, and web-server are all VMs running as DomUs under blocky. privbridge is the main virtual bridge for the VMs and has a connection to blocky to allow for traffic to be routed. leafbr is a pure virtual bridge that should (in theory) have no connection to blocky. I’ll cover why that “in theory” was necessary in a later article as that nuance cost me several hours.

Source NAT is used on all traffic routed through blocky. This is done because my wireless router will not let me create static routes pointing at anything other than the WAN interface. As such, traffic destined for the internet would not be able to return to the computer on the source network. The SNAT on blocky then allows for all traffic to appear to come from blocky’s physical ethernet port, regardless of where it actually came from inside the VM. Getting Chao to talk with web-server then was the true test as it’s only accessible via node3. I could have used DNAT to connect things, but the goal here is that I want to have full NAT-less communication with the darknet. As such, this meant I needed a more rugged solution, and I’ll cover the VPN link I used to do that in a later article.

Over 10 years ago I went through Cisco’s CCNA program and learned the (hilariously flawed) basics of how the internet worked. However, I never took the test and ended up going into electrical engineering instead. However, I’ve worked to keep the more common of those skills up, but I never really went all the way into making a fully fledged internet with proper boundary routers.

However, some conversations over the last few years with some friends suggested that we put together an overlay network and create a darknet-like network where we can play LAN games without worrying about NAT. However, over those years, the real challenge has been getting them involved and active. Making a network means having more than one node, and my friends aren’t terribly good about actually moving on projects

Well after something like 4 years, I’m finally getting around to doing the project anyway; with or without them. The secret is working around my friend’s participation using a computer I’ve called Blocky; a XEN VM server that can host a number of VMs. Using Blocky. I laid out a number of nodes and a complete network with multiple paths, some unroutable except through other nodes. This allowed for me to play with all of the pieces I needed to get things working.

The end goal is to make a network that would be isolated from my main network, be able to access the internet itself, be able to host services (namely a web server with a Wiki on it that used to be hosted on a public server), and to automatically advertise and discover new routes. 

Sometimes you just want to make better use of your tools. Sometimes you want to write neat code that does fun things. And sometimes you just want to jam out to some Daft Punk. This project does all of the above.

I recently learned about a media service called Media Player Daemon (http://www.musicpd.org/). MPD is essentially a headless, back end tool that is used to manage media files, create playlists, and then render them to an output (usually an audio playback device, but not necessarily.) This makes it excellent for installing it on small computers connected to a room stereo system. You can then connect to it from external clients on things like cell phones to control the player.

By itself that would have been pretty darn cool and a great second use for Mr. Wiggles, my Raspberry Pi based testing web server. But I have an LCD plate that I really wanted to integrate into the system. Enter  RaspberryPiMPDJukebox.

The MPD Jukebox client isn’t really a novel idea (several projects have done something similar,) but I wanted to take a crack at multi-threading in Python and working with locks and queues. So I put this together as a client for the MPD server that I have running on Mr. Wiggles.

However, I did learn a few things along the way. The older Adafruit library I was using was apparently DOG slow. The work I initially did with threading helped mitigate a bunch of that, but button responsiveness was essentially non-existent because updating the screen cost everything the CPU had and was slow enough I could watch it update. The new libraries improved that by a LOT and also allowed me to reduce the transactional costs by reducing button checks to a single call to the LCD. 

That said, something I’d really like to see is a swap from a GPIO expander, which must be polled (something that isn’t a good idea when working with a non-realtime operating system like Linux,) to a microcontroller based system. Sending commands to a microcontroller to ask if, when, and how long a button was pressed is a far better strategy than hoping a fast loop in Linux is going to get around to seeing things, especially since it’s possible to get blocked out by other bus transactions.

Back when I was in school, I was originally trained on VHDL; an IEEE backed language used for developing on FPGAs. However, as I’ve looked into what people are doing commercially, it seemed a lot of people where using Verilog. As such, it seemed prudent to study Verilog and learn how to use it.

So despite the temp ban (it was lifted after an hour or so,) I continued work on the relay and was able to prove that the GroupMe/IRC relay worked. I’d really rather have a cellphone-centric IRC server/client pair that allows a cellphone client to subscribe to an IRC channel via push rather than have to go through an intermediary, but that involves making 3 parts (IRC client, push server, phone client) and this only requires one.

Well, I knew I’d run into it eventually, but with enough tinkering you are eventually bound to run into a limit somewhere when you use other people’s equipment. To that end, some prototyping work I was doing on building a GroupMe/IRC bridge caused me to momentarily go over the ban threshold for session counts on the IRC server I normally work with.

In retrospect, it may have been wise to setup my own IRC server to run the experiments against, but at the end of the day it’s a little late for that realization.

Of it’s own right, the ban doesn’t affect me terribly as I wasn’t terribly active on the server involved and I CAN just setup a new server and continue my research, but i was running some support software for some friends that can no longer be expected to work, at least until I figure out if it’s even possible to apologize and appeal.