A Second Week with Mastodon: Lessons from University IT
I've been on Mastodon for two weeks (here's last week's musings), and the list of digital humanities people on Mastodon that I created a week ago has over 330 people.
This week, Mastodon has been my primary social place online. I've checked on Twitter when I see I have notifications, and there's some people I still DM there, and it's a much better place to follow updates from Ukraine. But for where I go to laugh or gripe about things, or talk with colleagues, it's been Mastodon. For the moment, I'm still cross-posting to Twitter automatically; there's plenty of people I think of as being in my communities who are mostly / only over there, and I don't want to shut them out. But I also feel like if I want to make Mastodon work as a meaningful space for DH folks, I need to invest in it, so that's what I'm doing by putting it first.
Content warnings
Apparently this week's Discourse has been around content warnings (CW), and who should have to CW what, and how norms in different corners of the Fediverse (which is to say, the set of servers and services whose content is visible to one another in this digital environment) intersect with issues of power and intersectionality. Should politics always get a CW? Whose lived experiences are expected to be CW'd -- and who is that practice protecting, and why? Responses have varied, and not only along the axis old vs. new users; one consequence of a system of federated servers is that people can all be right as they describe -- very differently -- the rules and norms "on Mastodon". It's a reminder that there is no monolithic "Mastodon".
Virality
That said, I've heard about this discourse at least as much via Twitter as Mastodon itself. I've seen some posts about it, but it hasn't taken over my feed the way that topics can on Twitter. Clive Thompson wrote a blog post about how Mastodon is designed to be "anti-viral":
"It was engineered specifically to create friction — to slow things down a bit. This is a big part of why it behaves so differently from mainstream social networks... Coming from the world of Twitter, where velocity and flocking behavior are common (and enjoyed by many people) it can seem weird to encounter a culture that finds friction useful and productive; a feature, and not a bug."
I think I've seen that at work this week, both with the content warning discourse, and with my own posts. The latest Data-Sitters Club book came out this week (on HathiTrust; I'm really proud of this one) and I posted both to Mastodon (26 reposts, 33 likes) and Twitter (42 retweets, 103 likes). Apparently that counts as going significantly viral on Mastodon! But I do wonder if in the long term, major announcements for things like the Data-Sitters Club will make sense to do on Twitter? On the other hand, maybe algorithmic changes will make it so only paid content gets meaningfully seen. It's hard to know.
Running IT services
I spent a decade working in higher-ed IT. I learned a lot about starting and running IT services over those years (and, famously with Project Bamboo, failing to launch IT services). Tl;dr even for experienced staff, doing it well is hard -- and it takes time. IT services that are DIY substitutes for social infrastructure run by large teams of professionals (at least, until Twitter laid them off) are especially tricky; users bring years of expectations with them, including expectations of speed and availability. Higher-ed IT services take months, if not years, to launch. Even once you've gotten past the questions of "what is the need" and "is our IT organization in a position to address the need" and "are we the right people to address the need (with our own staff and resources, vs. outsourcing it)", there's usually a period of comparing different software options, and once you've picked one, making sure that the behind-the-scenes tech staff are familiar enough with the system to be able to troubleshoot. But those people are almost never the ones communicating with the users; you also need to make sure the front-line staff get familiar with the system, and have answers to common problems and pitfalls for when the help tickets inevitably start pouring in. Someone needs to write documentation specific to your local context, which takes time, even if there's general-purpose documentation that you can adapt. And especially for anything you're running yourself, the infosec people would want to do their own review first, too.
Not every service involves that whole process, though certainly anything resembling a communications platform for the whole campus (or any significant subset of it) would rise to that level. I once built a digital pathophysiology textbook for students at the medical school. It was more like a digital humanities project in scope; I built it, and I was also providing front-line support, while my sysadmin friend Jinks (no, really, that was his last name) managed the server. Everything was ready to go for the first day of class, I was feeling good, ready to celebrate a job well done.
That morning, I got the kind of email that you get nightmares about as an IT person. The faculty member was panicked -- and angry. The hundred-some students simultaneously logging into the system overloaded the site. Fix it. FIX IT NOW.
My hands were shaking and I was on the brink of tears when I found Jinks. Who swung into action and in a few seconds of typing at the command line managed to throw a ton of memory at Drupal. The site came back online.
I learned something about caching that day, and we got through the rest of the quarter without another major meltdown. And a bit of Quotable Quinn made its way onto the whiteboard-wall of Jinks's cubicle.
I've been thinking about Jinks a lot this week as people spin up Mastodon (or Hometown or Pleroma) servers to create spaces for different communities. On one hand, I get and respect that urge -- I've been there, building the first version of DHCommons in one evening in response to a need articulated at THATCamp Chicago in 2010, and launching it the next day. But that was easier than spinning up Mastodon: I knew the software well, was familiar with running it at the anticipated scale (tens of users at once), and knew the usage patterns to expect (people would log in, create a profile for themselves, then maybe a couple project profiles; the rest of the activity would be browsing). From the sound of it, there's a lot of new Mastodon admins who don't know the technical stack, and are throwing the doors open for hundreds of people who may want to use the system much more intensively: uploading (potentially large) images, having active conversations, expecting immediate updates. On one hand, no one is born a sysadmin, and the way to learn those skills is through doing them. On the other hand, learning by running a service that people come to looking for a digital social hub to replace Twitter doesn't feel like doing right by those users -- at least, if you haven't been clear upfront that that's what's going on, giving them the opportunity to opt in with the knowledge what they're getting into. Digital humanities staff know only too well about the importance of managing expectations. It typically comes up in the context of covering one's own ass, and keeping a project's scope in check. But from another perspective, managing expectations is an act of care for collaborators and/or users. Being explicit about the limited resources you're working with (in terms of technical infrastructure, available labor, or your own knowledge) -- even if the result of that disclosure is that people end up going elsewhere for the service -- is the considerate thing to do for your community.
Setting up an instance without understanding the technical and social landscape has consequences beyond the inconvenience of downtime. This week I've seen references to appalling racist attacks on Black Mastodon users. I looked into some of the servers that these racist comments were coming from, and they're inaccessible from mstdn.social, the server my account is on. Those users can't see me or my posts, and I can't see them or theirs, because my server's sysadmin has implemented restrictions on a set of servers known to be a problem. (Scroll to the bottom of the mstdn.social About page to see which servers are blocked, and why.) Block lists are widely shared (search #FediBlock), but there's no list implemented by default. So if you're new to Mastodon, and have set up a server for yourself and your community, those blocks wouldn't be implemented by default and you might not know of norms around server blocking -- or the fact that allowing completely unfettered federation might put your server on a list for potential blocking, because it makes it feasible for hateful content to leak into others' systems via yours (e.g. if server A blocks server X, but one of your users on server B reposts something from server X, then it could end up visible to users on server A that is trying to keep content from server X out.) Not to mention the impact on your users if a server of racist trolls gets access to interacting with their posts. Mistakes at the intersection of technical affordances and social norms are easy to make as a new sysadmin, but that's also why it's important to be thoughtful about limiting the scope of who would be impacted by those learner-mistakes.
Staying put on mstdn.social
This week I've decided I'm staying where I am in the Fediverse, at least for a while. With the exception of scholar.social (whose rules drove me off in April), the interest-area servers that would make sense for me are too new for me to put a lot of faith in their management (both technical and moderation) or longevity (considering the reality of exhaustion from the labor needed to run such a service well).
I really appreciate what the admin, Stux, has done with the About page for mstdn.social. First, in bold, there's infosec warnings; from 10 years in IT, I can tell you that people mostly just don't read, but sticking the most crucial stuff in bold at the top increases the likelihood at least a little. There's links to information about the admin, as well as the moderators for the server. There's multiple different ways to donate to support the service, along with a link to a page with detailed information on the service's finances. There's a Tor link. There's information about the infrastructure, including where the server is located. There's multiple links to server statistics. There is -- again, in bold -- pointers to resources for people considering self-harm or suicide. There's a clear list of server rules. There's a whole section describing the policy on cross-posting. There's links to relevant related services that Stux also runs. And at the bottom, there's the list of moderated servers, the level of restriction, and the reason.
No doubt, all this documentation took time and effort to put together. But I appreciate both the results of that labor (in the form of those webpages), and the fact that Stux & collaborators thought to write it up. The end result is that I trust the service more, and I can articulate more clearly why I'm staying, and why I'm supporting it every month. This week I upped my monthly donation to $10, and I'll probably kick in with another donation at the end of the month to help with the increased costs of the new user base.
Being on a general instance means that I have to use Mastodon a bit differently than intended; I don't use the "Local" feed, but I've been following lots of people and treat my "Home" feed as if it were the "Local" feed (albeit one that spans many servers covering communities I'm interested in). I've been actively building a number of lists that functionally substitute for my "Home" feed: people I know and/or used to interact with a lot on Twitter, people whose work I find interesting, people in different relevant sub-specialties. I follow a few hashtags, too, including #DigitalHumanities. On the whole, I feel like this approach has been working really well for me.
Looking ahead
There's been a few developments this week that have left me a little uneasy -- including discussions about humanities scholars making their own decisions about whether and how to adopt existing Fediverse norms, and the response that if a community of users wants to diverge from those norms, maybe they should publish their content exclusively to their own server. My own approach to using this platform assumes widespread, reliable federation -- not content getting locked into community-oriented servers.
I also wonder how, and how quickly, things may unravel as people who started Mastodon-and-friends servers as, essentially, rapid-response DH project are faced with the reality that their DH project is actually now an IT service with all the complications that come with it, and with no foreseeable end beyond their own decision to shut down the server. It's the Directory Paradox, but much worse in multiple respects. This year I started an emergency DH project that responded to an urgent need, and since then I've realized that fateful decision in February started something that I could very well be involved in for the rest of my life. I'm okay with that being a consequence of SUCHO; I worry that the new Mastodon admins may not realize they've started down a similar path.
I would dearly love for the Fediverse to be a place that the DH community can continue conversations spanning over the last decade on Twitter -- and do so in a way (embracing the deliberate friction of Mastodon) that can bring in people that Twitter turned off. But if the servers people flocked to begin to melt down, it seems likely that the collective consensus may end up being that Mastodon was simply too unreliable -- not that inexperienced sysadmins DIY-ing it won't cut it for a scalable service, and we need to put our efforts and resources towards a better model for running infrastructure. That would be a shame, and a loss: not only of yet another possible social platform, but also of the opportunity to work together to turn a shared infrastructural need into a thoughtful, supported, long-term solution that aligns with the community's goals and values.