On Mastodon, communication, and transparency.

On Mastodon, communication, and transparency.

Posted on: Tue, 11/15/2022 - 11:07 By: Matt

For a long time now I have been unhappy with the current state of social media.  Not because it is inherently toxic, unwelcoming to people of color or others with opinions or concerns that not fit expected norms, or that it commodifies our social relationships—although all of those things are a part of it. My unhappiness has instead stemmed largely from the fact that we were in a death pact with each other, all upset about the nature of social media but not willing to leave it because to do so would mean leaving communities that still mean something to us despite the platform.

The rise of decentralized social media—the “fediverse” of platforms like Friendica and Mastodon—has long interested me for this reason.  I saw it as a harkening back to the early web days when you would roll your own blog or chatroom and connect with each other without a corporate entity attempting to algorithmically control your speech either through ineffectual moderation or through delivering content you didn’t ask for and didn’t care about to your feed, often to the detriment of things you actually did care about. What was lacking, though, was critical mass; enough people needed to leave at once to make shifting to a new platform viable, and it needed to be a platform that I did not have familial or real-world friendship ties within (or where those ties were secondary), because while I hate the death pact I recognize I’m still a part of it.

Elon Musk’s spectacular mismanagement of Twitter since his acquisition of the platform afforded a perfect chance. My family either doesn’t use Twitter or I am blissfully unaware of their existence on it, meaning the thing that keeps me in the death pact that is Facebook wasn’t there; similarly, many of the academics that I would periodically brave Twitter to check up on were leaving the platform, providing the critical mass I was looking for. The fact that you could roll your own platform (or "instance" in their parlance) made it attractive to me as well because it meant I could control the platform in ways that simply haven’t been possible for fifteen years. So I deleted my Twitter account, with glee, and switched.

What I did is use Digital Ocean’s already extant prebuilt server "droplet," following their instructions to get it set up.  This is largely because I don't have a virtualization server of my own and likely will not for another year or two (it has become more of a goal recently, though). Setup was surprisingly intuitive, and for two weeks I trundled along, happily following people on other servers and getting what I felt was the best of both worlds.  I noticed there was a new version today and so I went to update my Mastodon instance and immediately broke the web interface. All I would get, instead of useful information, is an (admittedly cute) animation of an elephant pounding on a keyboard.  The logfiles, in turn, suggested that one package was not finding a particular file it needed.  I tried recompiling things based on the update instructions again, and it remained broken.

Thus began an hour-long search of old bug reports, issues with other pieces of software using the package in question, and often-truncated Reddit threads that finally resulted in a fix for my problem: in my particular case the Webpacker module (or “gem”) in the Ruby-on-rails platform Mastodon is built upon wasn’t compiling correctly and thus was either not providing needed information or simply not changing files that needed to be changed.  Since the purpose of Webpacker (or more accurately the Webpack system of bundling and turning into “apps” stacks of Javascript code) is to help generate the frontend the web version of Mastodon wouldn’t work correctly. Since it didn’t work correctly, it threw an error—hence the elephant. This happens, in part, because while the majority of Mastodon appears to use one tool (bundler) to bundle itself up the Webpacker stuff uses another (yarn) to do so.  And it wasn’t working right even though the necessary command had been entered.

I resolved this, for anyone who cares, by totally removing the webpacker module entirely (“yarn remove @rails/webpacker”), deleting node.js (“rm -rf ./node_modules”), and then readding the webpacker module (“yarn add @rails/webpacker@^5.2.1”). After doing all this when I tried the installation instructions again it found the missing Javascript file and all was well.

I mention all of this, though, because one of the problems in the continual push to turn technology into appliances is that we’ve now built systems that are interdependent and which rely of specific environments to run, but documented those interdependencies incredibly poorly. And the people who do understand those interdependencies are making assumptions regarding the systems they’re operating on that are intended to deobfuscate the process, but do so based on their own sets of assumptions regarding the stack of applications they’re using to work with.  So for the average user little is understood and thus when somebody like Facebook or Twitter comes along and promises you all of the benefit with none of the need to wrangle with the underlying problems it becomes an incredibly attractive proposition. And, as is typical with large-scale systems, the moving parts stay under the hood (and in a lot of cases do things you don’t want them to do) until something breaks—like Musk is doing with Twitter because of his incredibly incomplete understanding—and the myriad complexities of the tool become apparent.

My suggestion to people who are developing these tools is to treat users like they’re five and to include steps that don’t relate directly to your code. For the end user my suggestion is to accept that this is a necessary step to full transparency and not let yourself feel insulted. And, if you can, to make the process easier for others, as well.

Add new comment

The content of this field is kept private and will not be shown publicly.

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.
Article Type