A (minimally jargon-filled) Dive into Mastodon
in this article i will refer to every "ActivityPub" client as "Mastodon" - sorry in advance
So you just made or joined your first Mastodon instance, hopping away from some other corporate hell site (X, Bluesky), or some lovely not-for-profit site (cohost), and you're wondering how this whole thing works, but every time you look at a guide it's mired in Jargon that you can't quite parse without spending the whole evening figuring it out.
This guide is an attempt to make things easier, so you can access the benefits Mastodon has over every other social media options.
Put simply - Mastodon's power is in You owning your own portion of a social network. Mastodon offers the widest breadth of moderation tools to its Instance Owners. This is why i encourage everyone to start their own instance. But if you start your own instance, there's some information that's going to be necessary. Here's what you need to know.
Mastodon's Network
Mastodon is a federated network centered around your "Instance." An "Instance" is a server running the Mastodon server software. Instances have Users - Users follow other users on other instances - making connections between those instances. When a User, logged in to their Home Instance, follows another user on another instance the original Home Instance begins to receive updates from that second user's instance.
But! you might ask "how does an instance see posts from other instances before it's interacted with those other instances?" Unfortunately, it doesn't. Fresh instances of Mastodon don't see anything but the posts generated by users who have an account on the same instance. This means a completely fresh instance of yours will have you seeing no other instance's posts upon creation until you, or another user on your instance finds another instance and follows a user from that instance. This is a key weak point for findability with Mastodon BUT there are ways to solve this easily:
- Way #1 - 3rd party lists
Some people maintain lists of Instances, and by looking through the list, you can visit different those different Instances and see the public timelines of the users there, and when you see a user that looks interesting you can shoot them a follow. Here's a few lists to get you started:
Lists of Instances
https://fediverse.party/en/portal/servers/
https://monoskop.org/Fediverse
https://joinmastodon.org/servers
https://www.fediverse.to/
https://fedidb.org/network
https://fediverse.observer/list
https://fedi.garden/ (This one is framed as a way to "Pick an instance to join" but it still functions well for finding categories of instances)
(Non-Exhaustive) Lists of Users
https://fediverse.info/explore/people
https://fedi.directory/
By default when you attempt to follow a user or interact with a user's post on an instance that you're not logged in on, Mastodon will prompt you asking "what's your Instance's domain name" and will then send your instance a copy of that user's account information or post that you intended to interact with. This is a rather slow way to begin to federate your instance with other instances, and it favors the more personal connections, in which someone, outside of mastodon, shares their @ with you.
- Way #2 - Groups
There are "Groups" on Mastodon which function well for introducing your Instance to new, other instances. They work simply enough, as explained by one third party group maker, Guppe.
Like above, if your server is brand new you need to access lists of groups through third party sites.
https://a.gup.pe/
https://fedi.directory/tag/fediverse-groups/
- Way #3 - Relays
Relays have the greatest potential for overcoming Mastodon's discoverability problem, but they haven't had the most work put into them yet, and finding a good one is harder than finding a good instance to join.
A relay is a two way street. You get the posts from everyone else on the relay, they get your posts. This way your instance will be instantly populated with the posts from everyone else who has signed on with that relay. Notably relays do not crawl the network - they only display posts from instances that have also signed on with that relay. Mastodon's findability would truly rival that of networks like Bluesky if there was a relay method that did crawl the network. But until then... This is the fastest way to get federated at large, and as such it requires that you pay attention to what other instances are on the relay before you join.
Here's a few third party lists of Mastodon Relays
https://joinfediverse.wiki/Relays
https://relaylist.com/
https://github.com/brodi1/activitypub-relays
In your Mastodon Instance's Administration tools is a "Relay" section. Signing your instance on to a relay is as simple as copying a link from one of the lists above and pasting it in here.
Mastodon's Privacy Controls
Mastodon separates its privacy controls into three types. Instance-Level, User-Level, and Post-Level controls.
Instance Owners have the ability to defederate their instance from any other instance. This is a severe way to prevent bad instances from ever seeing any of your posts, and to prevent your instance from accepting any posts or interactions from that other instance.
Users of any given instance have the ability to Block any user on any other instance and they also have the ability to Block any other instance. Blocked users will not be able to interact with the Blocker's account nor will they see your posts. Users can pick between having a Public account and a Locked account. Locked accounts require follow requests to be approved. Unlike Twitter, Locked accounts on Mastodon can still post publicly. The account being locked doesn't mean every post has to be.
Posts can be Public, Unlisted (meaning opted-out of discovery features like searches), Locked (followers only), and Direct (meaning only users @'d can see). Some instances also have the ability to set posts to "local-only" (meaning only others logged on to Your Instance can see your post).
How Does This Compare To Bluesky
If you're coming from Bluesky, some of this might sound familiar to you - Bluesky is also a "federated" system, but the federation functions differently. Almost everyone on Bluesky was on the bsky.social domain - Bluesky's default Hosting Provider - and individual accounts are established as their own mini-server, as a subdomain of the hosting provider (username.bsky.social).
These mini-servers are called PDSs (Personal Data Servers) - and the PDSs are linked together via a "relay" which functions by crawling through and aggregating all of the Other PDSs it can find and what they post. These relays, crawling through the network and collecting what they find, make the user experience more seamless than in other federated networks. By my estimation, relays - crawling and aggregating posts before you look for them - are the one clear advantage Bluesky has over Mastodon.
Where Bluesky's federation is centered around PDSs and relays, Mastodon's is centered around Instances (akin to Bsky's Hosting Provider). On Bluesky, so long as a relay has seen and aggregated a PDS and its posts, your PDS can access it. Whereas on Mastodon there is no equivalent relay crawling, instead, instances can only see posts that they've been told to see by a user on their own instance following someone on another instance.
Bluesky is an entirely Public system, meaning that they functionally have no true moderation tools, and the Trust and Safety Team have also shown themselves to be unwilling to hold harassers accountable. There are no locked accounts on Bluesky, there are no private posts on Bluesky, and even if you block someone they can easily gather everything you've ever posted with simple tools.
For a more detailed comparison:
wander