The Paradox Terminal

Genesis of the Terminal

Don't ever lock yourself down.

I don't actually like Discord bots. Interfacing with Discord's API, even through a Python wrapper library, is annoying and provides an extra layer of errors that could potentially happen. Discord thinks you're taking too long? Say goodbye to your request. The response isn't delivered to Discord in chunks of 2000 characters? Who needs auto-splitting? I already removed one layer of lockdown by using LangChain as an AI library rather than any provider-specific package, but I tied myself to Discord from the start inadvertently.

There's plenty of criticism of the locked-down web out there already. Enshittification, "five giant websites filled with screenshots of the other four", the "techlash". We can spin our wheels all day about it and lament the situation, or we can actually do something about it. Here's my contribution: turning my Discord bot into an API.

An Application Programming Interface (API) at its core is a black box with a list of functions you can call as a user and a description of what each function does. I always imagine APIs as large, grotesque organisms, with skin stretched taut over a misshapen, vaguely rectangular body, and various orifices dotting its surface. Stuff goes in, stuff comes out, and you don't necessarily want to know more.

When developers refer to APIs, they're usually referring to web APIs, which are APIs served on the web. Websites are APIs! You ask for a page, you get the page. You send them your login info, you get your user data. You send them your posts, your posts show up on the screen. The web is just APIs with stuff on your screen to make them look pretty.

The first grand step was to split the codebase into the engine and a Discord bot "terminal". I moved all the files that actually do things into an "engine" folder and moved the Discord interface into a "terminal" folder. I severed the link for good by defining an API schema, which is just a list of functions, what they do, and what they return. "How they do it" was already taken care of. My new entry point for the engine would be an API that calls the functions I already wrote, and my new functionality in the Discord bot would just call the API and return it. This was a routine enough task for Copilot to take care of, with some prodding. It was time to move on.

Vibe design

I don't know how to build frontends. I kind of refuse to learn.

For those of you who aren't software engineers, modern web development is usually split into "frontend" and "backend". For example, on a social media site, the "backend" of the site is what happens between when the user clicks the "OK" button and submits their post, and when the user sees their post on screen. That data has to be processed and transformed somehow on some remote server, the "back end", in order to make the site work and know what to display to the user. The "frontend" is everything that gets done on the user's computer, which can be a whole lot with modern JavaScript, but the posts still need a place to be stored and listed somewhere so they can be retrieved later.

I'm a backend engineer. I build APIs that take in data and spit out more data. I got a math degree, and this is the part of web dev that allows me to be closest to just transforming data like functions transform objects in sets to members of some other set. Frontend code is a lot more like painting, especially with the modern abominations of CSS and JavaScript that have taken over the web. Everything's a flexbox, everything's a series of nested divs that no longer contains meaning. We used to have tags for "semantic HTML", boxes and buttons with meaning, but now HTML5 is merely a vehicle to execute the sickening whims of designers! Nothing matters anymore. Just put it in another div. The next JavaScript framework will fix it.

If you were lucky enough to be a software engineer during the zero interest-rate policy period of 2010-2022, you could have impressed a whole lot of people and made a decent amount of money spinning up frontends at caffeine-and-junk-food-fueled hackathons, with 10 lines of Python to return data that may or may not be real. That's why AI coding agents are great at making frontends; they were trained that way, because it impresses people. They replaced and fully commoditized the exact type of coder that was already a dime a dozen anyway, thanks to a myriad of bootcamps and get-rich-quick schemes sold toward people looking to reskill. All I had to do to get a frontend was ask Copilot for one, so ask I did.

#new I want to build a project that's a frontend for an API. The theme of this website will be "terminal"; user will interact with the website by looking at a fake computer screen with green text and dark green scanlines, and a faint CRT "bulge" effect. The user will type commands into a command line, namely "alchemy", "fraymotif", or "title". once they type that in, the display on the screen will change to different interfaces they can click on.

And it was good.

The full process

Actually, it was OK. Good enough. It didn't match with my API, and had zero functionality, but I sat there and waited for a few minutes and clicked the "OK" button sometimes and I got something that basically matched what I had in mind. It was time for further prodding.

#codebase here's the python code for the endpoints. make sure to follow the proper response format for each endpoint and integrate it into the interface in a fun and engaging manner

[Python code snippet, you can view the codebase on my Github]

I supplied this instruction and my API schema, and it reorganized the entire site around the "brain" I already built. My website was coming to life before my eyes, a computer that performs arithmetic on souls and concepts, a library of crystals of memory! I conjured this intrepid fantasyscape with tears bled from the wisdom-weary eyes of 50,000 robots brought to life!¹ And when I changed the schema based on my own whims, even more sickening than any designer, the frontend bent to my will!

#codebase [another python code snippet]

New schema. Take this into account and start editing anything relating to the title system

It took a bit to decide what "my will" was on this one.

make the title display some blank value instead of "knight of time" when the user first gets to this page. it should be mysterious

rather than blue and orange, make it just white and white for the class and aspect. also the blinking is too smooth for the rest of the interface, use the flicker effect instead

Fraymotif page needed iteration too.

alright great job on the title interface. this page nees work now. first of all, players aren't "player names", they are "player titles", and they're a comma-separated list of valid titles like "Heir of Doom, Seer of Time, Page of Blood". backend handles splitting and validation and all that

a valid title is "[Class] of [Aspect]"

valid classes: Heir, Seer, Witch, Mage, Knight, Page, Sylph, Prince, Bard, Maid, Thief, Rogue
valid aspects: Time, Space, Blood, Breath, Mind, Heart, Light, Void, Doom, Life, Hope, Rage

maybe consider dropdowns? or something cooler

And then alchemy.

fraymotif and title pages are awesome. now for this

inventory system is overcomplicated. streamline this whole page immensely. redo it from scratch if needed. the captchalogue endpoint is for retrieving items by captchalogue code (8 letters/numbers/?!), but users should be able to directly input names of items (or codes) and alchemize directly from the names or codes.
the operations for alchemy are && (which gets sent to the API as "and") and || (which gets sent to the API as "or")

And finally, the credits.

one more thing: credits

when the user types "credits", it should show this text: "THIS IS THE PLACEHOLDER TEXT FOR THE CREDITS"
i want this to be extensible, because [REDACTED]

This obviously involved dropping in and making sure things were correct. For a minor example, I just told it to put down a placeholder text for the credits because I didn't want it to copy over the block of text incorrectly. Not one iota out of place. I also changed any mention of "fraymotif" to "motif" outside of the generation prompt, because I thought it would make more sense with the theme of the rest of the interface. Finding the text to edit is simple enough with Ctrl+F, not everything needs an LLM to be done.

After vibe-coding, it was time for vibe-devops. I searched for how to build a static site with Vite on a traditional search engine (remember those?), got another VPS instance to host my site, connected it to a spare domain name I had that sounded sufficiently cool, and went back and forth to make the CORS headers and HTTPS happy so users could actually use the site with the API. Finally, at 4 AM on a weeknight, it was complete. I somehow showed up to work in one piece the next morning.

Reflections, again

My opinion on AI is that it enables a bunch of people with no skills whatsoever to pump out tasteless junk that occasionally looks decent on first glance. I also think that it enables people with skills to pump out tasteful junk that looks and feels great on second glance. People should aim to develop skills, with or without AI in the picture, so they can build things that add meaning to their life and the lives of others. This is my diary of how I chose to build something new.

I think many future creative projects on the web are going to be built by dynamic duos of one designer and one engineer. The designer serves as a "product manager" as well, collaborating with the engineer on the look and feel of the site, deciding together what it will do, as the engineer thinks about how it will do it, pulling and pushing against the designer as necessary. The designer would work in an interface design tool such as Penpot, while the engineer sticks to a code IDE such as Visual Studio Code. With the plethora of tools available to do the heavy lifting of boilerplate code and devops make it happen guys please, the engineer will be free to focus on implementation from the top-down, starting with system diagrams and schemas, and ending with a product the designer can interface with. The designer will dip their toes into what is today "frontend development", either writing or auto-generating code for their components that they and the engineer snap together.

This site would be so much better with an experienced designer. I spent a brief amount of time trying to find one, before deciding that it couldn't wait. Whatever I had in my head to build was too important to put off until tomorrow; it had to be done now, and not a moment later. A redesign can wait until after I add even more to it.

https://asgard.host

Enjoy.