What Actually Happens When You Follow a Mastodon Account on Another Server

“Decentralized social media” is one of those phrases that sounds explanatory until you ask what the software is actually doing. The usual email analogy helps with account names, but it hides most of the interesting machinery.

The Fediverse finally clicked for me when I stopped picturing a giant social network and looked at one Follow button.

Say my account is @cj@design.example and I follow @Mastodon@mastodon.social. The interface makes that feel like one database write. It is actually a conversation between two servers that do not share a database, an owner, or necessarily the same opinion of each other.

That is the interesting part.

First, find the real account

The handle @Mastodon@mastodon.social is useful to a person, but it is not the account's canonical ActivityPub ID. My server needs to turn that handle into a URL.

It starts with WebFinger. You can see the public response yourself:

curl 'https://mastodon.social/.well-known/webfinger?resource=acct:Mastodon@mastodon.social'

Buried in the JSON is a self link with the media type application/activity+json. For Mastodon's official account, that link currently points to https://mastodon.social/users/Mastodon.

This is where the email comparison starts to fall apart in a useful way. The handle looks email-ish because it combines a user and a domain. Nothing here is using SMTP. WebFinger is simply telling my server, “The machine-readable identity you want lives over there.”

My server then requests that URL with an ActivityPub-compatible Accept header. Instead of an HTML profile, it gets an actor document. The actor has a globally unique id, a type such as Person, and URLs for an inbox, outbox, and followers collection. Mastodon also publishes a public key on the actor.

An ActivityPub profile is not just a profile. It is an addressable object that tells other servers where to send things.

Following is a message, not a row

Once design.example knows the remote actor ID and inbox, it creates a Follow activity. The important fields are simple: the type is Follow, the actor is my account URL, and the object is the Mastodon account URL.

My browser does not usually send that activity straight to Mastodon.social. It asks my home server to follow the account. My server handles delivery, signing, and retries. This distinction matters because closing the tab does not stop federation work already queued on the server.

Mastodon signs the HTTP request used for delivery. The receiving server can fetch my actor document, find the public key, and verify that the request came from the matching private key. A digest also protects the body from being changed in transit.

This does not mean ActivityPub has one universal authentication system. The W3C ActivityPub Recommendation tells servers to authenticate and verify content, but it does not require every implementation to use exactly the same signature mechanism. HTTP signatures are part of how Mastodon federates. Other ActivityPub software may make different choices.

That little distinction is easy to lose when people say a platform “supports ActivityPub.” The standard gives products a shared vocabulary and delivery model. It does not make them identical.

A valid signature is not an invitation

After the Follow reaches the remote inbox, Mastodon.social still gets to say no.

The account may require manual approval. The user may have blocked me. The server may have suspended my whole domain. A server running limited federation may refuse traffic from everyone except an allowlist. The payload may also be malformed or impossible to verify.

Cryptography answers “who sent this?” Local policy answers “do we want it?”

If the follow is allowed, the remote server sends an Accept activity back to my inbox. It references the original Follow, so both servers know which request was accepted. Only then should my server treat the relationship as complete.

There is no database transaction wrapping both machines. One server can update its state while the response to the other is delayed. The software has to expect that. Queues retry. Activity IDs prevent the same delivery from being applied twice. Reconciliation fixes relationships that drift out of sync.

This is ordinary distributed-systems work hiding underneath a very friendly button.

Your home feed is a local view of a larger network

After the relationship exists, new posts can flow back to my server. A public Mastodon post is usually represented as a Create activity containing a Note. The origin server delivers it to remote inboxes for followers and other addressed recipients.

If ten people on design.example follow the same remote account, Mastodon.social does not necessarily need to send ten copies. ActivityPub actors can advertise a shared inbox for the server. One delivery arrives, then design.example fans the post out to the local followers who should receive it.

That detail changed how I thought about the Fediverse. My home feed is not querying every server on the network in real time. It is assembled from objects my server has received and stored. A server learns about remote posts through follows, mentions, boosts, exact-URL searches, relays, and whatever other federation traffic reaches it.

Two Mastodon servers can therefore have different views of “public” activity. They have encountered different accounts and cached different objects. There is no secret global timeline that every instance is reading from.

It also means outages are weird in a very distributed-systems way. If a remote server disappears for an hour, deliveries can be retried and arrive late. If its domain disappears forever, the actor IDs under that domain disappear with it. Other servers may still have cached copies, but a cache is not ownership of the identity.

Account migration has to work through the protocol too. The old actor can point to a new actor and initiate moving followers, but old post IDs do not magically change domains. Every remote server has to receive and process enough of the move to update its local graph.

Where privacy and algorithm claims get slippery

Independently operated instances do not mean user data is automatically protected from harvesting or sale. ActivityPub cannot promise that.

Your home-server operator stores your account data. Remote servers receive whatever profile data and posts are necessary for federation. Those operators choose their own logging, retention, backup, and moderation policies. A community-run server may have incentives I prefer over a giant advertising company, but “smaller” is not a cryptographic privacy feature.

Post visibility is also not encryption. A followers-only post is addressed to a smaller audience, but copies still travel to the servers hosting those followers. Mastodon's own posting documentation warns that server administrators may be able to read private mentions. If something needs Signal-level secrecy, Mastodon is the wrong tool.

The Fediverse is not algorithm-free either. Mastodon's home feed is generally chronological, but Mastodon still has search, trends, suggested accounts, and discovery features. Other ActivityPub software can rank a feed however it wants. ActivityPub describes how activities move between systems. It does not dictate the interface built on top of them.

The part worth defending is choice, not purity. Different operators can make different moderation and discovery decisions while still exchanging recognizable social objects. Developers can build another interface or server without one platform owner granting access to the social graph.

That freedom comes with real mess. Servers block each other. Implementations disagree about optional behavior. A post can arrive while one interaction attached to it does not. Moving servers does not preserve every bit of history and context. Decentralization replaces one company's hard boundary with a pile of smaller boundaries that have to negotiate.

I find that more compelling now that I understand it as engineering instead of philosophy.

One click starts discovery, signed delivery, local moderation, an acceptance message, and eventually a stream of copied objects moving through queues. Two servers have agreed to maintain one little edge in a social graph, for as long as they both keep agreeing.

That is much stranger, and much cooler, than “Twitter but decentralized.”