# LeucoSpex The idea began several years ago, between myself and a close friend. We wanted basically an esoteric way to keep in touch. Morse code, ham radio, something cool. The idea banged around in my head for a while, and I had daydreams of building a wood and metal device that would somehow use Arduino and the Internet to accomplish what cell phones and the Internet already do... Then I got a job at a company specializing in the Internet-of-Things, and made products in that space for commercial and industrial applications. The vision was grand, a networked mesh of devices all chattering at each other figuring out which version of software they needed and what configuration packages etc. Well, it only took getting laid-off from that job and getting a new job that had nothing to do with networked hardware or pub-sub messaging for me to realize: I could actually build a network of devices that communicate securely with one another. The final piece of the puzzle landed in November of 2020. We're about 9 months into the COVID-19 pandemic at this point (at least as far as the US is concerned). I'm spending my hobby time playing with computer keyboards, procrastinating some furniture-making and cabinetry projects, and tinkering with hardware and firmware for a stenography keyboard. I somehow find myself looking at a thermal printer on Adafruit—the kind usually seen at a cash register—and it finally clicks. Microprocessor, thermal printer, keyboard. Maybe a small display, or some LEDs to show power and status...yes. This could work! At first I get to work on the code. Whatever it ends up being, it *does* need to communicate securely over the Internet, potentially from unsecured networks. So I dust off the skills I picked up at my last job and crack open the docs for Amazon Web Services's "IoT Core" product. AWS IoT uses a "pub-sub" model (that's "publish-subscribe"), with the MQTT protocol (Message Queueing Telemetry Transport, which might tell you that it was _meant_ for communicating boring stuff like sensor readings). Well, we can use it for human-readable messages too, if they're not too long. The main idea is that a device can _publish_ to a topic, and it can _subscribe_ to a topic. The LeucoSpex LS-200 subscribes to quite a few topics, but we'll focus on just one: the operator's moniker. Once I get the device connected to my network, and authenticate myself with the central hub (what I'm calling the Comptroller), my LS-200 subscribes to `moniker/griffith`. After that time, any message published to that topic will arrive at my device, which will print it out. There are various other moving parts, but that's the core premise. It was important to me that operators be able to choose their own monikers, and even to be able to change them if they wanted to. For this reason all the LS-200s identify themselves first with a machine-friendly "client ID". Here's how the authentication challenge and moniker-selection works: 1. I have a set number of devices, and each one has a unique MAC address 2. I assign a passphrase to each device, and put this list somewhere the Comptroller can read it. 3. I send each device to a human (the "operator"). 4. I use a separate communication channel to tell each operator their device's passphrase. 5. The operator starts their device, enters the passphrase and their preferred moniker 6. The device sends this information to the Comptroller 7. The Comptroller checks that the passphrase is correct for the device, and checks that the moniker is not in use already, then reserves the moniker for that device. Easy, right? One of the early printouts of this sequence:  The text of the early printout: ``` //////////////////////////////// //////////////////////////////// tb-term version 0.2.3 booting Current system time is 16 Dec 20 21:28 -0800 initializing components thermal-analog imager.........OK organic particle-emitter......OK command input device..........OK //////////////////////////////// Linking with operator network... ...uplink established ...downlink established //////////////////////////////// Verifying operator identity... Operator identity verified. Welcome, griffith. //////////////////////////////// FROM: griffith-pc TO: moniker/griffith MESSAGE: what's up fellow youths? ``` At first I really liked the idea of the Raspberry Pi 0W. Small, full raspbian OS, with wifi, for $10? Come on. The only hitch in that plan is that vendors limit you to 1 per HOUSEHOLD. It was around this time I was also coalescing some ideas around the narrative experience, and having players/audience, so I was starting to think I was going to make 10-20 of these things to send to friends. I couldn't be bothered to set up 20 different PO boxes and email addresses just to save a few bucks on each computer, so I started looking at the other Raspberry Pi lineup. The 3 Model A+ caught my eye: still has wifi, still has the 40-pin GPIO connector and raspbian OS that I'm familiar with, and only $25. I hope that it will suffice for the LS-200. Aside from the processor, the hardware on the LS-200 will be minimal. A thermal printer (which supposedly speaks "ESCPOS", but I have yet to crack that manual open. I do really want to try some fun things with the text, to make REDACTED blocks and cursed blocks...), and some kind of prompter display. That will greatly help the operator see what they're typing. It will be up to the operator to provide power in the form of USB, input from a keyboard, and additional rolls of thermal paper for the printer. Here's a photo of one of the first times I got the pi working with a prompter interface, on an Adafruit 128x32 2.23" OLED Bonnet:  Aside from the hardware...oh gosh. So many ways this could go. For now a loose sketch of what I've been thinking [this from December 2020]. The humans attached to the LS-200s are all part of an organization together. I've been reading a lot of Laundry Files lately, and also picked up the game Control again. Very "SCP" vibes, spooky and secret and all CODENAMEy. Is there some conflict in the organization? Do the humans have to hack their way around to gain access and download the codez to stop the world from ending? Do I set up chatbots to play with the humans, and the humans have to convince the chatbots that humanity is worth saving (recently watched _Superintelligence_ with Melissa McCarthy, very good). Do the humans have to teach the chatbots how to love? Is this an edutainment device to teach people about encryption? Heck, I don't want to learn a ton about encryption, so no. Is this a sort of modern-day retelling of my epic fantasy homebrew campaign, Hyperborea? Is this a game to teach people how the blockchain works? (wtf, I thought I said no brain-benders re: encryption) Do I put the humans on separate teams from each other? Do I give some people access to some tools/assets and others different access? Do I send a bunch of "forward this to 10 friends or you will be cursed", and actually curse their devices? It's still very unclear to what extent this will just be an esoteric email machine amd how much it'll be a ~curated immersive narrative experience~. Last topic to touch on before I go to bed: another concrete decision I came to fairly early on in development was to make sure that no matter the narrative, all messages are encrypted from my own eyes. I Spencer do not want to ever be in a position to read messages between two other people when they think their communication is secure. If I design a narrative around encryption and secrecy, it will be very important to uphold this tenet. One idea for how to do this is to provide a basic "behind-the-curtain" level of security out of the box. Any messages between two devices will use PGP so that anyone else subscribing on the topic will not be able to read it. I should note at this point that even if there were no behind-the-curtain encryption, the MQTT protocol would encrypt the messages from the wider Internet. It's just they'd also be readable by me, because like the kind and benevolent DM of yore, I'd be watching over the playing field making sure everyone was having a good time with their weird cool email machine. If every device starts with behind-the-curtain encryption, and uses some public keys to do that, the Comptroller in the cloud might be able to have a sense of "this person is sending messages that are encrypted in real life, but unencrypted in the game". And then later the operator might discover some new feature of the LS-200 that lets them create their own PGP keys, at which point the comptroller thinks "oh ho, now they're sending messages encrypted both in real life *and* in-fiction, what are they trying to hide from their Big Brother Agency?". Just spit-balling on the implementation details, but it's possible to still build a narrative where trust and secrecy play mechanical parts, without making everyone's secrets public to the rest of the network. The other core tenet I knew I wanted to adopt along with "everything encrypted all the time" was around the lifespan of a message. Since this centers around secrecy, I figure it's only right to make sure messages are always ephemeral. If you send an email, it ends up on a server somewhere (or several somewheres), even after it's read by the intended recipient. Not so for this application. I wanted the ONLY extant copy of a message to be the "unhackable" paper tape that printed out of the recipient's LS-200. Now, whether they keep that device in an externally-viewable location is up to their own personal security standards...  As I close this first dev journal, I leave you with the first principles of the LeucoSpex Terminal Operating System: - Be who you are. Choose your own moniker and representation within the network - Rest assured your messages are encrypted, both in-game and out. - Your messages are ephemeral and are never stored on any software system. And a progress report of the development: - leucoterm 0.2.3 and various cloud components allow two LS-100 devices to authenticate their humans, and enable their humans to message each other! - next steps for software are the behind-the-curtain PGP encryption handshakes, as well as some helper software to provision player devices (PCs), agency devices (NPCs), and comptroller devices (so I can GM). - next steps for hardware is manifold: - do a little debugging to get the RPi 2 working again - play with the RPi 0W to determine if I can use that for one or two of the shipped units. - receive the RPi 3A+ and play with that to determine if it's suitable for the production unit. - explore the ESCPOS system for the thermal printer to get it to print some wacky stuff (redacted text, cursed text, barcodes, qr codes, bitmaps) - explore various display options at hand (OLED, TFT, eInk), to identify capabilities and set expectations around the mechanics of the finished LS-200 - breathe ## TODO - [ ] #project #LeucoSpex power distributor PCB