Remote Instance Actions

The userscript in action, suspending badfaith.instance.
Quickly suspend or silence remote instances from the Mastodon frontend

Prerequisites

Ensure Tampermonkey is installed: Tampermonkey Home Page Chrome Extension Firefox Add-On


Installation Form

Why?

Enter each instance you wish to use the script on. This should be just "domain.tld", no extra formatting. One domain per line.



FAQ

What's this?

Remote Instance Actions is a userscript I've written to aid in Mastodon moderation.

(That really is just "Mastodon", not "fediverse". Sorry, Misskey admins).

It's as simple as the image at the top makes it look! Just highlight the URL of an instance you want to silence or suspend, and select the new context option. It does a little bit of simple sanitizing and validation to make sure you highlighted what you wanted to highlight. Then, it checks to see if the instance is already limited. Finally, it opens a new tab to your instance's "New Domain Block" form.

The checks to ensure that the highlighted text is a domain and that it's not already limited on the instance are imperfect. For example, if the instance "domain.tld" is blocked, the latter check will give a false positive on "mydomain.tld". For this reason, the checks can be overridden manually.

What is a userscript?

A userscript is sort of like a browser extension, but smaller! Just a little bit of Javascript code that gets run on certain pages to enhance the experience.

Of course, most browsers do actually need a browser extension to run userscripts. The most popular and feature-complete one by far (as well as the one this userscript was tested with!) is Tampermonkey.

It's just a userscript? Why the complex installation process?

When writing a userscript, you have to hardcode in the URL of websites it will work on*. That's fine for, say, Twitter, where it's always found at "twitter.com" (for the time being, anyway). Mastodon instances are a lot harder to write for. If I wrote it to, for example, check if the current page is a Mastodon instance and conditionally add the context menu item, it would have to run on every page you visit to make that check.

The usual way to solve this problem is to just tell the user to modify the userscript to add the pages you'd like it to run on. That sucks for a number of reasons. The most obvious are that users don't want to have to go in and mess with the code, and that it breaks with Tampermonkey's update functionality. This page here is my overengineered solution.

The userscript itself, in a usable state, isn't exactly stored anywhere on my server. There is a version that's very similar, but with a little bit of PHP where you would expect the @match directives to be. That PHP code fills in the match directives with domains provided via GET parameters before sending it to your browser. Since the script was installed from a URL with those parameters in it, Tampermonkey will include those same parameters when checking for updates.

The slightly less technical answer is that using this install page generates the userscript with the proper domains set on the fly, and does so in a way such that Tampermonkey will fetch updates that are generated with the same domains.

*This is not technically true, you can also match URLs with regular expressions. But anything that would match any Mastodon instance is going to have a lot of false positives, and I believe Tampermonkey throws up a big scary warning if you do this anyway.

Can I see the source code?

Well, your browser will show you the code before installing, but if you want to inspect it it's available on my gitea instance.

How can I contact you?

If you're on the fediverse, I can be found at @monorail@glaceon.social.

If you aren't... How exactly did you get here?


Note For Firefox Users

This script used to be broken in Firefox, and this part of the page details a workaround. A Tampermonkey update has fixed the bug, so this is no longer required unless you're on an old version of Tampermonkey for some reason.

There's currently an extremely weird bug somewhere in the intersection of Tampermonkey and Firefox. I've managed to find a few reports of it occuring for other people, but only in the context of other issues that have since been closed. I have no idea what causes it, but there is a workaround.

Simply, your web browser has some security features built in to prevent any code that's not "supposed to be there" from executing. Tampermonkey is supposed to still be able to execute despite this, but something super weird and beyond my understanding is getting in its way. But for whatever reason, reloading the page without your cache fixes it. I can't explain why, but I can explain how to do it.

At any point before using the script, press Ctrl+F5 to "hard refresh", reloading the page without using the cache. When you do, the script will work until the next time the page is loaded.

Hopefully this issue is solved in the future, and this workaround stops being needed.

There is a way to work around the bug in a more permanent way, but it comes with some security risks. In fact, it's dangerous enough that I don't feel comfortable explaining how to do it here. But if you know what you're doing: Disabling CSP enforcement should allow the script to work.


Back to top