On Yellbot Dot Online
Over on @lazardotsocial I’ve gotten into the habit of writing essays about each generation, discussing generally thoughts on the project. I've been enjoying it, so now I’m going to do that for Yellbot.
Yellbot obviously was inspired by the classic Endless Screaming bot, but also because I had an ActivityPub idea and the yelling was an easy way to try it out. A neat technical detail of Yellbot is that there aren't any accounts or users. I have database tables for posts and follows but nothing for each individual bot. When someone looks at an account, all the information is created on the fly. When I’m making new posts, I look at all the letters people have followed and make posts for them. Until someone looks at or follows a letter, it doesn’t exist and it doesn’t need to exist.
This enables behaviors that wouldn’t be possible otherwise. You couldn’t make Yellbot on twitter - you’d have to create over a billion accounts or get permission to create as many accounts as you wanted, whenever you wanted. Neither option is realistic. But by having my own server and connecting to the larger ActivityPub network, it’s easy. A centralized service could never.
Now, yelling isn’t very valuable but I think this basic structure here could be applied elsewhere. You need two things:
1. Something that can be reference just through a username, like a name, definition of behavior, a start state, etc.
2. A behavior that happens occasionally – those are the posts.
So, you could have
Each account is a zipcode that posts whenever there’s a dangerous weather alert.
Each account is a wikipedia page that posts whenever the page is edited.
An account for every book on Project Gutenberg. When someone follows one it starts posting the book, sentence by sentence (in the style of Bedtime Story Bot). When it finishes, everyone gets unfollowed and the account is deleted, until someone follows again and it restarts.
Something like Sam Lavigne and Tega Brain’s project The Good Life – an account for each e-mail address and it posts each e-mail in real time.
Each account's username defines the rules for a cellular automata and each post is a generation.
Thinking up examples and possible applications lead me to thinking about what kinds of information ActivityPub is suited for. For example, here in Chicago every bus station has a 5 digit code on the sign. You can text to a number to receive schedule updates. So you could make a server with an account for each bus station.
Like this. Image from the Chicago Transit Authority
But what would it post? Nobody wants to know every time a bus arrives at a station. That’s too many posts cluttering up your timeline and all but the most recent one are irrelevant. Similarly, you wouldn’t want to receive the temperature through ActivityPub, because you only care about the current temperature, not all the past temperatures.
When you make a post on Mastodon, your server sends the messages to all the servers of accounts who follow you and they’re responsible for storing and displaying them. That’s the “publish” in ActivityPub. This makes it suited for activities where having the entire history is desirable - you don’t want to know just what your friends said most recently, you want to know everything they said. For cases where only the most recent version counts (like temperatures or buses), you’re better of letting the client request the data when they want it.
(I have loose thoughts here about Robin Sloan’s Spring ‘83 protocol, which is a person-to-person social communication system that doesn’t maintain any kind of history and (if I’m understanding the protocol correctly) doesn’t guarantee that you see every board from the people you follow. You couldn’t build Yellbot (or something equivalent) in Spring ‘83 due to key limitations, but the board format would be well suited for a dashboard type application.)
If your behavior doesn’t happen too often, you could still use ActivityPub and it wouldn’t be too annoying even if you don’t care about history. And it would have the benefit of putting the information someplace you’re already checking. If you’re already checking your the timeline daily, if a piece of info is added in there, you’re guaranteed to see it. That’s a big advantage and in many cases it'll be worth the clutter. I think daily is infrequent enough but exact amount of time would vary by person.
This project was an extension of the ActivityPub implementation I did for Lazar gen 7 and it takes the implementation a couple steps closer to totality. I have another project, which I put on hold to make Yellbot, which requires a complete implementation and it seems a lot more manageable now. So there may be more ActivityPub in the future, although no guarantees about how far in the future.












