I am making more progress on automating my Mastodon world. Throughout the holidays I spent time getting to know the Mastodon API, forking and iterating upon an OpenAPI for the API, and generating a mix of capability API collections that accomplished what I was needing to do with the Mastodon API. Now I am getting to work automating my different Mastodon instances using what I have built. I am not entirely sure what I am automating, as this will vary from instance to instance. The mastodon.apievangelist.com domain will require a very different approach to API automation than mastodon.kinlane.com will. One is professional and one is personal. Adding even more complexity to the federated chaos, I will not just be automating this across domains I control, but because of the nature of my research, I will be automating some aspects of this using many of the leading Mastodon instances. While talking to people during this work I (once again) realize how much I assume of people when it comes to onboarding with APIs, with Postman, and being able to follow, let alone put to use anything I am building. In an effort to bridge this divide I am going to keep polishing how I talk about it here on the blog, producing many different narratives for how I can introduce people to this work with the federated Mastodon API. A significant portion of what I am building involves understanding what Postman does, and how Postman works with any API, including the Mastodon API. To follow along it helps to have a healthy understanding of Postman which you can get via the learning center, but beyond that it helps to understand how the Postman building blocks help automate activity across federated APIs like Mastodon, by leveraging these Postman platform capabilities.
- APIs - This is the definition for the Mastodon API. It can be for any API, but for this story, it is for the Mastodon API. There is one API for Mastodon, which I have defined using the OpenAPI specification, published to Postman, and synced to Github for wider use. This OpenAPI definition provides the “source of truth” for what the Mastodon API is capable of. One important thing to remember here, is that the Mastodon can be federated, having many instances o the API, and this OpenAPI provides a common vocabulary for what is possible across all instances of the Mastodon API—this is important.
- Collections - Next, collections are derivatives of this source of truth for a specific unit of automation value. Meaning, a collection could describe everything the Mastodon can do, but it also can just describe a single capability of the Mastodon API, a series of API requests, or scenarios involving other 3rd party APIs like Twitter, Twilio, or even the New York Times. The OpenAPI is the source of truth of what is possible with the Mastodon API, and collections are specific representations of that truth implemented as part of our day. Things like posting, searching users, or managing trends as an administrator. I am developing a public workspace of the capability collections I need to accomplish what I want.
- Environments - With a source of truth, and a workspace full of capabilities, now I need an instance of the Mastodon API to automate with. I have environments for Kin Lane and API Evangelist instances. I also have environments for a handful of the top Mastodon instances out there like Hachyderm.io and Fosstodon.org. I will now apply these environments against each of my collections, pairing each environment with the capabilities needed to automate the two domains I control in this federated conversation.
- Monitors - Lastly, I am pairing collections with environments and scheduling my automation within a workspace, separate from the public one I have setup with all of the capability collections. I am just forking each collection into another private workspace, where I’ll be doing the scheduling. I am happy with sharing all of the building blocks of my automation, but there is really no need to make my personal and professional automation public—-you’ll just have to trust me as I tell stories about wha tI am up to.
To understand what I am building I realized that you will need a baseline awareness of APIs and Postman. But, the federated nature of the Mastodon API requires that you also possess a baseline advanced understanding of how Postman workspaces, APIs, collections, environments, and monitors all work together to automate using the Mastodon API in a federated way. Now that I have abstracted away a handful of Mastodon API capability collections I’ve created in the public workspace into a separate private workspace, I can get to work bundling collections and environments into the automation cadence I am looking for across different capabilities, but also different instances-—with these being the first couple of areas I am investing:
- Notifications - I am pulling my notifications for both my API Evangelist and Kin Lane Mastodon instances—-so one collection, two environments, each running hourly as separate monitors. Each of my instances have different needs regarding how it interprets and handles the pulling of notifications, and I am using the query parameters for the Mastodon as the knobs and levers pulled to dial this in.
- Lookup - Every user who shows up in my notifications gets fingered, updating my profile of each user in my local Mastodon, utilizing the WebFinger standard to update each user engaging with my network. Ensuring that I have what I need to further engage with a user.
- Follow - Once I have evoluated each user that has engagement with me on Mastodon, I can make a decision to follow the user, automating who I am following, following anyone who engagements with me via the social network or applying specific criteria and filtering based upon different profile data point.
- Topics - Pulling topics using RSS, passing in a single keyword plus the RSS extension and pulling a list of posts, users, and topics. With each pull shining light on who’s talking about a specific subject, but also provides a nice list of other topics to consider based upon the hashtags applied to each post—producing an ever growing list of wha people are interested in.
Now, the notifications, lookup, and follow building blocks are all part of a series of capabilities I am automating in different ways for my own API Evangelist and Kin Lane instances. The topics building block is what I am running against my own instances, but also the top Mastodon instances out there. This reveals some pretty different ways in which I can use Postman, but also the collections, environments, and monitors, in a variety of workspaces, targeting a mix of Mastodon instances. This work leaned on the Postman platform, the Mastodon API, but also an API developed and hosting on Amazon Web Services. I needed a way to maintain user and topic state across my automation-—something the Mastodon API does not provide. I played around with different hacks ways I could use Postman, Mastodon, or GitHub for this, but I resorted to just delivering my own API because it was easiest and most straightforward. This post helps me gather my thoughts. Next I’ll just watch the topics and users that come in. I’ll spend a couple more weeks thinking about what I need across this federated landscape. I am looking at zeroing in on the API, and API-adjacent conversations, but also playing around with some personal interests. I am using Postman to do this because it is where I work, but also because there tis no other place to build what I need in such a modular way. Sure, I could spend countless hours writing custom code to make this happen, but Postman makes it very low-code for me, and makes it more like playing with Legos than playing with code. Plus, it makes it easier for me to share via public workspaces, showing my homework behind each story I am telling, leaving many of the Lego bricks available for anyone to fork and use. I grok that there is a cognitive load associated with this, but I am just focused on learning and building at this point. I am sure I will get to a point where I can better document and abstract away some of the complexity, but for now I am enjoying exploring the federal possibilities across this social API-driven landscape.