Domo Arigato EdTech Roboto

8 min read

Back in the days P.C. (Pre-COVID) I was starting to do a deeper dive into the world of Mastodon and set up an instance to play around with. One of the things I did was build a bot that automatically posts blog posts from edtech bloggers to Mastodon.

I’m going to try to CogDog walk through the process as much as I can here in this post, hazy memories and all as I did this work 6-9 months ago. But to start, in true CogDog style, the live demo or, if you prefer, a screenshot below of what the EdTech bot Mastodon account looks like if you don’t want to click away just yet.

Screenshot of a Mastodon social media account showing the home page of the EdTech bot

What you are looking at in the screenshot is the homepage of the EdTech bot built on a Mastodon instance hosted on Cloudron by the OpenETC. The bot is being fed blog posts from an aggregated list of edtech blogs from my Inoreader account which I have connected to Mastodon using an IFTTT recipe. What this bot does is watch my Inoreader blog list for a new blog post from one of the edtech bloggers on my list. When it sees a new post, it automatically posts it to Mastodon.

Holy moving parts, Batman. I’m going to do my best to break this down.

But first, some Mastodon context

Now, I do have a Mastodon user account on the server where I cross-post content from that account to Twitter as a way to begin stepping away from relying so heavily on Twitter without losing my network (you can read some of my rationale in a post I wrote for OER20). is the instance of Mastodon maintained by the developer of Mastodon.

But Mastodon is an open-source application, meaning I don’t have to rely on the instance. I can actually set up my own Mastodon server and run my own Twitter-like service. I can keep it closed to just a few people, or open it up and connect it to other Mastodon instances creating a wider social network.

I do think that federated models that can be controlled at the local level, but still connected to other instances, is a good alternative to commercial social media platforms, especially when they are hosted and controlled at the community level.

I get that people are still hesitant to take the plunge – re-creating networks are difficult. So part of my experimenting was to see if I could find ways to make Mastodon a bit more useful for others who may eventually find their way to Mastodon. One of the value adds I wanted to see if I could do was build a Mastodon bot that could provide a source of relevant, updated content for educational technologists on Mastodon.

The dark side of bots

Now, before I go further, I should acknowledge that there is a definite dark side to building bots for social media sites. Much misinformation and disinformation being spread on social media today comes from bots. Which, in itself, is a pretty good reason to learn how to build bots as a way to understand how they work and how they can be used to spread misinformation.

That said, I also think bots can be useful in a trusted network. In my case, as a way to provide a useful account for others interested in edtech to follow in order to find some usefulness on a new platform where their network is currently not at. I thought a bot that posts curated blog posts might be a way to bring an edtech network into the Mastodon world where new people using the service only had to follow an account to connect with a relevant network via their blog posts. That was the rationale behind my experiment to build a useful bot.

You might be asking yourself, “so, aren’t you worried about others building a bot that may be malicious?” Here is the great thing about running your own software – you control the environment and who you want to let into your instance. Don’t want your instance to be used to build bots? Lock it down. Restrict registration to a trusted group of people or even just yourself. Run it like you do a WordPress blog if you wish. No one else can create an account on your Mastodon instance, but you can still interact with the rest of the Mastodon world because of the federated aspect of the application. Lock it up…

Screen shot showing nobody can sign up

And only invite those on to your instance whom you trust.

Screenshot showing admin field that allows administrators of mastodon to invite select people in

Now, this does not prevent the creation of nasty bots on other Mastodon instances. But by controlling your own environment you do limit and control bot creation on your own instance, which is a heck of a lot more bot control than you get on open public platforms like Twitter.

Ok, onto the steps.

Step 1: Mastodon

So, the first step was setting up my own instance of Mastodon, which I did via the OpenETC. Grant Potter has been experimenting with an application deployment framework called Cloudron which makes deploying web-based applications fairly straightforward.

One of the applications in Cloudron is Mastodon, so with a click and a subdomain, I was able to get a sandbox instance of Mastodon up configured & running on the OpenETC.

Screenshot showing the homepage of the OpenETC test mastodon instance

I spent a few weeks of spare time poking around and figuring out the administration side of the instance and invited a few people in my network to create some test accounts to give it a try. I’m glossing over a lot of the details of the set-up and configuration here, but that is a blog post on its own and I want to get to the bot building part.

Step 2: Make the bot

Once I had a local instance of Mastodon up and running, I needed to create a new account on the instance that would be my bot. Once the account was created, I logged in to the new bot account and went into the preferences screen where I customized the bot page to make it clear to people that this was a bot and what the bot did. Within the account preferences, there is a toggle switch that designates the account as a bot.

screenshot showing the bot toggle

This toggles a notification on the bot profile page that lets others know that this is an automated bot account.

screenshot of bot profile page letting others know this account is a bot

Step 3: Feed the bot with Inoreader

Around this time I was also switching my RSS reader from Feedly to Inoreader after hearing Laura Gibbs rave about it on Twitter (it’s a very good product and I am happy I listened to Laura). One of the features of Inoreader is the ability to generate a single RSS feed from a collection of RSS feeds. It’s a wonderful way to aggregate a lot of information sources and share as a single feed. In Inoreader I set up a collection of blogs from about 20 or so ed tech bloggers I read on a regular basis and called the collection EdTech Blogs. From there I am able to get a single RSS feed for all those blogs.

animated gif showing how to access a single RSS feed from a collection

Step 4 Connect the do…um, bot using an IFTTT webhook

Ok, the bot account has been created. I have a source feed. Now I just need to connect the source RSS feed to the bot account and let it do its thing.

To do this, I turned to teh interwebs and they delivered this wonderful blog post that explained, in detail, how to set up a webhook to connect the bot to Inoreader through IFTTT. At a high level (you can read the blog post for the specific details), you log into your bot account on Mastodon and create an application via the development tab.

Once you create your new application in Mastodon, it will generate an access token that you need in order for IFTTT to send the blog posts from Inoreader to the correct account on your Mastodon instance.

Once you have that token, go over to IFTTT and create a webhook applet. Enter in the Inoreader RSS feed you want to monitor, the Mastodon instance url and access token, and set up a few parameters on what you want to be included in the Mastodon post. In this case, I have the blog title, blog author, and link back to the original post.

Which results in a Mastodon post from the EdTech bot that looks like this one from JR Dingwall

There are some things I can’t control with the bot that I wish I could, like the author names so that people can tell at a glance who wrote the blog post. However, the bot can only post the info it is given, and there are quite a few people who attribute their blog posts to a generic “admin” account so you end seeing posts attributed to admin. And if the person creating the blog post does not have an image associated with the post, you end up with a generic looking page document in the image placeholder. But if they do add an image, the bot does pick it up and adds it to the post, like Alan’s example here

I also wish that I had some more programming chops to be able to write a script that does what IFTTT does as the middleware piece and not have to rely on IFTTT. But still, a fun project that will hopefully pay off someday and make it a bit more enticing for some edtech to check in on their long-dormant Mastodon account knowing that there is a bot in the bg providing fresh relevant content for them.

If you have a Mastodon account and want to follow the bot, hit it up here, at least for the near future.


Clint Lalonde


One thought on “Domo Arigato EdTech Roboto

  1. The Ed Tech Bot on Mastodon has been around for a few months and has proven to be useful to me because it captures some posts I might miss in my feed. It helps that it’s pretty selective; it focuses on blogs that are updated once in a while rather than feeds (like this one) that will pump out five or so items a day. In this post Clint Lalonde describes the creation of Ed Tech Bot, from the installation of a private Mastodon server to the setting of of the Inoreader RSS reader, to the use of IFTTT to push the aggregated contents into the Mastodon account. He laments not being able to write code for what IFTTT does, but for other people wanting to do the same thing, being able to do it without writing code is a huge plus.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: