Here’s the short version: I’ve made a new thing, and it’s a unified home for my bots on the Discord platform. Discord is a chat server similar to IRC or Slack with a nice web-based client and desktop & mobile apps. With this new set up, anyone can log into Scrumwave, the “server” that hosts these bots, and see what they’ve posted over time. There’s a guestbook where you can write your thoughts, just like at a museum or art gallery, and that’s it.

You can check it out at https://scrumwave.com, or stick around for a bit of thinking around all this as well as some technical details.

Why do this?

In the wake of Twitter’s API changes last year, among a number of other technical and political events of various magnitudes, a number of people I know cooled on the idea of putting generative art, and more broadly automated processes we’ve referred to as “bots”, on Twitter.

I’ve done a minimal amount of work to keep them running, although a couple have gotten suspended due to more heavily automated tooling for copyright holders to issue DMCA takedowns on items that are clearly fair use and it’s absurd to think otherwise.

I also tried porting my bots to Mastodon, but honestly, the impact they have on that platform is much smaller and (this might be harsh but) it kind of feels like a waste of my time. I’m glad that there are some people who see my work there, but to convince someone I know that they should go look at my bots on Mastodon is a whole thing. I don’t think that Mastodon is, or should be, a drop-in replacement for Twitter, so I don’t think it’s reasonable to think that directly moving work originally intended for one place to another should necessarily make sense.

I had had in mind for a while now this idea of unifying my bots into one “place” online, where people could see this work passively or follow it using simple open web standards like RSS or Atom; where particularly good output could be flagged in some way and archived. Unfortunately, this is a lot of work for a hobby project and so it’s been languishing in my to do list application for years.

It occurred to me, though, that a platform like Discord provides just the right number of features to provide a sort of low-fidelity version of this. Using Discord’s webhooks, I was able to add posting to a Discord server with 5 lines of code. In the near future, I plan to add the ability for a channel to consolidate the best posts across all the bots based on “reaction emojis” people can assign to individual outputs—something else the Discord API should make pretty easy. If someone approached me and said that they wanted my bot to post in their Discord server (I doubt this would happen, but who knows?), it would be a pretty simple change to process an arbitrary number of webhook URLs each time a bot runs. Discord has the ability to set permissions on individual channels, so I can have spaces where bots can post but no visiting humans can. It’s like an automatically-enforced “quiet please” sign in a museum.

Putting the bots on Discord does mean that seeing their work requires a Discord login, but I’ve decided I’m okay with that, because Discord uses a single account to manage your access to any number of chat “servers”. It’s likely that a large number of people I know already have a Discord account, and if they don’t, the sign up process is simple and could be useful to them at some point in the future. It’s still a proprietary platform, but there’s some indication that they’re doing the bare minimum (1, 2) to address the problem of hosting hate speech on their service, something I have a hard time saying Twitter has done.

How does this work?

In the process of setting this all up, I finally accomplished a task I’ve been meaning to tackle for quite some time: merging my bots into a “monorepo”, a trendy concept in programming that I have a feeling is overapplied in a lot of companies, but seems fine here. All of my bots to date have been written in Ruby and I’ve generally relied on a lot of copy-and-pasted code to perform common tasks like managing command-line parameters, posting to Twitter and Mastodon, and doing similar operations in A/V manipulation libraries like imagemagick and ffmpeg. Over time that copy/paste has become kind of unmanageable, and trying to coordinate Ruby versions, gem versions, and installed binary dependencies (like imagemagick) has also been the source of a lot of unnecessary downtime for my bots. Since each bot is also its own git repo, I’ve been fairly neglectful in keeping the source code of my bots available on Github, even though some people have told me they’ve found that code useful in thinking about how to do similar work.

So with this I’ve started a new project, botter-heaven (with apologies to Hideo Kojima), to manage running all my bots. For the time being, the only thing that’s really unified beyond some code to handle command line parameter parsing is one set of Docker and Ruby Gem configurations, which makes the whole thing portable from one computer to another much more easily. Now that it’s all in one repo, though, I do aim to finally go back and clean up the code a bit, using the same methods for common needs like posting to Discord or adding text on top of images. This approach makes that work far, far easier than my original plan, which involved pulling code out into a Ruby gem and then adding another dependency to all my bots.

So far botter-heaven is running nicely on my ancient Mac Mini (“urza“), managing nine bots posting multiple times per day, but another benefit of this project is that I’ll soon be able to move this whole operation into the cloud and retire urza now that it can’t even install new versions of macOS.

Both Scrumwave as a Discord server, and botter-heaven as a piece of software, are absolutely works in progress. I’m not fully satisfied with either, but I’m excited to see where thinking about this work takes me over time.