OpenETC

by Clint Lalonde on EdTech, OpenETC

Domo Arigato EdTech Roboto

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 mastodon.social 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). Mastodon.social 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 mastodon.social 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.

 
by Clint Lalonde on Online & Blended Learning, OpenETC

Using Mattermost as class hub

Over that the OpenETC site, Tannis has posted on some interesting ways that the open tools of the OpenETC are being used to support teaching & learning. It reminded me that I am looooong overdue posting about my own use of Mattermost last fall with students in my LRNT 528 course Facilitating in Digital Learning Environments.

As I mentioned in a blog post last summer, I wanted to try an IM-like chat tool for a number of reasons. First, after using these types of IM tools myself for years, the conversations seem to be more free flowing than occur in a standard Moodle discussion forum. Conversations in chat tools feel more like conversations. A bit more spontaneous and natural, and I wanted to see if a change in technology could bring that same natural energy to class discussions. Second, chat tools blur the lines between synchronous and asynchronous communication and can make it easier to have a spontaneous chat sessions while still giving students who prefer the time and space afforded by asynchronous the opportunity to respond on their own time. Third, chat tools have better support than most LMS discussion forums for more diverse methods of communication. GIF’s and emoticons are easy reaction tools that can help people create social presence within a learning environment. Finally, IM tools are increasingly common ways of collaborating and communicating on the web, and for this particular group of learners studying digital facilitation in online learning environments it felt like an important tool for them to use at some point in their academic career as I can see these types of platforms becoming increasingly more important in digital facilitation.

Slack use in class seems to be increasingly common, but after their “mistake” last year where a number of user accounts (including academics & students located here in British Columbia) were deactivated for seemingly political reasons, I was not in a hurry to outsource my facilitation to them, especially when there was a viable open source alternative, Mattermost, being hosted here in BC by the OpenETC. This was my overarching reason to use Mattermost over Slack. So I created a team in Mattermost for my LRNT528 Digital Facilitation class in the hopes of doing a direct replacement of the Moodle discussion forums with Mattermost channels.

My cohort was small (14 students) and the facilitation class part of a larger Masters program in Learning & Technology, many with years of experience in teaching & learning roles, so I would classify the learners as tech savvy educators, which is one of the reasons I felt ok experimenting with a new technology.

That said, I wanted to be explicit with the students that Mattermost was an experiment, and provided some extra support to walk them through the account creation process, including a Q&A session specifically about using Mattermost in a course introductory synchronous session. Along the way I was able to contribute back to the OpenETC some how-to documentation that I put together for my students that others can use in the future if they would like to do something similar. Living out the “contributions, not contracts” piece of our OpenETC philosophy.

In my week 1 course activities, I asked students to create their Mattermost accounts, update their user profile to add a photo or avatar, and post an introductory message tagging me to let me know they were in. These were fairly low stakes activities that would help to get them comfortable in the environment. As they entered the space and posted their welcome message, I made a point to greet them personally. I also pinned some general guidelines to the top of the Town Square channel that spelled out some general expectations for the space.

Welcome to the LRNT 528 Mattermost chat group. This will form the discussion hub of the course. There are channels set up for each of the scheduled discussions we will have in the course (CoI, TEK-VARIETY, and Final Reflection), plus this main channel called Town Square where you can post general questions.

Some guidelines for posts.

  1. Keep your discussion posts to a single point. This will help keep your posts short.
  2. If you find your posts are getting long (over 150 words), then you likely have a lot to say about the topic we’re discussing. In that case, consider writing a blog post on your blog and then paste the link to your blog post here.
  3. Feel free to use memes, gif’s, and emoticons. These are legitimate forms of communication. That said, don’t needlessly use them, or use them as a replacement for genuine discussion.
  4. Don’t feel the need to academically cite content in your posts, but do include links to external content that is relevant to the discussion.

Above all, read carefully, reflect before sharing, challenge tactfully, question thoughtfully, forgive mistakes (yours and theirs), and have fun learning.

I structured the Mattermost discussion area to include a general Town Square channel, two channels, one for each of the facilitated discussion I wanted to have in the course, and a Final Reflection channel where we could debrief the course at the end. I also created a Sandbox channel where students could post and experiment, but it turned out not to be needed as much of the experimentation with the platform happened in the general Town Square channel.

What worked well (my perspective)

Overall, the technology worked well. The conversations did seem more spontaneous, yet still well thought out. I did see an increase in the use of emoticons and gifs, and quite often could see conversations unfolding in real time by students who happened to be on the platform at the same time discussing course content.

Being able to have students tag others in a conversation is also a nice feature common in many IM platforms and not in the Moodle forums. You can @name someone to draw attention to a post, or bring someone directly into a discussion as opposed to if someone name drops you in a discussion forum post. I am beginning to think of the @name feature also as a form of attribution as I saw it used in ways to tag other learners who made a good point or that someone wanted to build on. And by using @all I was able to message all learners and draw attention to something – a salient point made by a learner, or to provide some further clarification.

Students also used the direct messaging feature of Mattermost to communicate with me which I appreciated as all course related conversations were now central within Mattemrost and not in my email account.

This was a digital facilitation course and students do an experiential learning assignment where they become the facilitators, designing a week of facilitation for other learners in the course and I was pleasantly surprised at how many of them decided to use Mattermost themselves for their own facilitation weeks, which said to me that they were feeling comfortable enough in the space to use it on their own.

What didn’t work well (my perspective)

On the downside, threaded conversations are a not quite as straightforward as in a discussion forum and sometimes it could feel overwhelming to figure out how to view and respond to specific threaded discussions. But once learners figured out how to use the threading feature it seemed to lessen the cognitive load of being presented with a wall of seemingly unstructured conversation when entering a channel.

What the students thought

I ran a short informal survey with the students at the end of the term to get their feedback on using Mattermost as compared to Moodle discussion forums, and overall they were quite happy with the tool comparing it favorably to Slack in terms of functionality. But more importantly, there was overwhelming consensus from the learners that Mattermost did change the way they participated in the class, and the technology did make them feel more engaged with both the course material and their classmates.

I can’t release the details of the feedback as it was an informal summary of students that was meant just for my own information. But the results were promising enough, and gave me enough information to show that there is something about the way that tools like Slack and Mattermost works that changes the way students participate and engage. I am planning on using Mattermost again this fall with a larger cohort and am going to pitch doing a SOTL focused piece of research on using it, this time with ethics approval so I can publish some findings next year.

 
by Clint Lalonde on EdTech, OpenETC

On the network effect and PLN’s

As I work more with Mastodon, I am noticing more and more feature parity with Twitter, and a few features that I wish Twitter had (content warnings, for example). I’ll be writing more about specific features of the platform in coming weeks, part of my master plan to build a good, compelling reason to convince people in my network to begin using the service more (yes, I am looking at you).

I get it. Building networks is hard work. That has always been the Achilles heel of whatever new service gets introduced. Even Twitter. In the early days of Twitter many people came and went and it took a long time for Twitter to become a service that was of value to many people. Until the network effect began to kick in.

It is not the platform. It is the people on the platform that make the platform useful. It’s classic chicken and egg. Not enough users and you end up with a platform that is….

Tumbleweed blowing across and empty desert landscape

Which Mastodon can feel like, especially when compared to what you are currently experiencing in Twitter. So, there is little incentive for users to participate.

But it doesn’t have to be all or none. I’m not completely giving up on Twitter just yet, and neither do you. I am going into this with the realization that building networks takes time, and this is a long game, not a quick win. Which is why I am working hard to figure out a way to do little things like cross-post from Mastodon to Twitter. I want to continue to maintain a presence in Twitter as I begin to slowly cultivate a network in Mastodon. But I also want to work on ways which make me think Mastodon the default and Twitter the platform I only check once or twice a day. And then once or twice a week. And then once or twice a month.

I am looking at this as a long term project. A slow weaning from one platform to another. Yeah, it means working in both for awhile. But I am ok with the trade-off as I know that building networks takes time. I’ve been around this block before. It takes effort. It takes time. But most importantly, it takes people. So, I am willing to put in the work as I want to provide some value to others who put in the effort. As Digenti (1999) notes, building PLN’s is a reciprocal affair.

To have a truly valuable PLN, investments in time and resources are essential. This requires an extension of the typical transactional business mind-set. If, as a business manager or change agent, we “do the deal” and fail to consider building our PLN, we have lost much of the value of our interactions. This is particularly true in the activities of collaborative learning, where each project we engage in should enhance and broaden the PLN of each member.

Where each project we engage in should enhance and broaden the PLN of each member.

I know better people than me have tried and failed to convince people to start using Mastodon

And I know that there are many valid reasons to keep with the status quo. But I feel like I have to start somewhere. We have to start somewhere. If we are concerned about the effects of the commercialization and monetization of our personal data, we need to start making efforts to move away from platforms that use us as the product. For me, that means decentralized federated services that are controlled by people and not corporations.

I see my main role in the network right now is to try and provide value-added information to my network in the hopes that someday others may be convinced to begin doing the same. This is how PLN’s are built, one person at a time adding value with intent. Participating. Contributing.

How do you build a PLN? First, it is important to overcome the hesitation around “using” people. If you are building a PLN, you will always be in a reciprocating relationship with the others in the network. Ideally, you should feel that your main job in the network is to provide value-added information to those who can, in turn, increase your learning (Digenti, 1999).

This will be a long process. But then again, relationship building always is.

Source: Digenti, D. (1999). Collaborative Learning: A Core Capability for Organizations in the New Economy. Reflections, 1(2), 45–57.

 
by Clint Lalonde on EdTech, OpenETC

Trying another way to cross post from Mastodon to Twitter

I wrote last week of using IFTTT to cross post my Mastodon posts from Mastodon to Twitter. After playing around with the IFTTT for a week, there were some limitations that I discovered, including the inability to cross post photos from Mastodon to Twitter, leaving a lot of my tweets this week looking like this:

When they should have actually looked like this:

Fortunately, Wayne Mackintosh from the OERu (who have been running their own Mastodon instance as part of the open source OERu tech stack Dave Lane administers) suggested another Mastodon to Twitter cross posting tool that has been built by @renatolond@masto.donte.com.br specifically for this task. My first cross post test a few minutes ago looks like this new tool may work better than IFTTT for cross posting, at least as far as the images are concerned.

Original Mastodon toot:

Cross posted tweet on Twitter:

And it looks like this application also has the ability to gracefully truncate longer Mastodon posts to fit with Twitter’s shorter length requirements (Mastodon gives you 500 characters vs Twitter’s 280). So, I’m going to test this cross-poster out this week.