The Fediverse Doesn’t Work the Way You (Probably) Think

tl;dr: Hashtag links, search, and visible posts and replies are all local to your home instance. If a post hasn’t been delivered to your instance, you can’t see it.

People coming to the Fediverse — that is, the decentralized network of ‘federated’ social media websites and communities running Mastodon, Misskey (or Calckey, like KPO), PixelFed, BookWyrm, PeerTube, or any number of other pieces of software — from centralized social networks often find their initial experiences confusing and frustrating. Though these websites have user interfaces that make them look very similar to the big corporate platforms, the user experience is substantially different in many ways. This can make the sites themselves feel broken, or just wrong in a way users can’t always articulate.

Or in ways they very much can.

People landing on Mastodon, in particular, famously complain about the limited search capabilities (since Mastodon only allows users to search hashtags by default, not the full body of posts) and the lack of ‘Quote-Toots’, as these are the most visible missing features from Twitter, but such omissions are really just scratching the surface of how this interconnected network of social networks — this Inter-SNet, if you will — functions differently from centralized social networking sites. In many ways, these issues with Mastodon are red herrings which distract from some fundamental differences in how things work here.

Everything is Local

On Twitter or Facebook, users generally expect to be able to search the entire social network for content. That little search bar is the window to — potentially — 15 years, and billions of user accounts worth of posts and comments. It’s supposed to search all of Twitter, or all of Facebook. And so, in kind, users expect the search bar on Mastodon (or Akkoma or Calckey or…) to search all of “Mastodon”. That is, all of this Intersnet thing.

But the thing is, Facebook is just one website. Twitter is just one other website. They’re BIG websites, that take a ton of RAM, and CPUs, and storage to operate, but they’re each only a single website. Their posts are likely stored in a single — albeit large — data warehouse (or some construct that approximates one, if nothing else). In a very real way, when you use their search features, you’re only searching a single website.

That feature is entirely local to Twitter or Facebook. It’s not like you can search Twitter’s posts from Facebook, after all.

Things, it turns out, are much the same on the Intersnet (yes, I’m much too amused by this to drop it quite yet). Just as on the big social networking platforms, everything here is local, too. That is, everything that you see on a given website is on that website, and that website is fundamentally a different website from other instances.

But unlike on Twitter and Facebook, not all of those posts originated on the website you’re viewing them on. In fact, unless you’re on the largest servers on the Intersnet, it’s very likely the majority of the posts you see originated on another website.

See, the network is made up of thousands of independent websites that are running server software that can communicate with other websites. If you have an account on, say, mastodon.social, everything you see while browsing things at that web address is located on mastodon.social (‘.social’) itself. If I post something from my account on KPO and you see it on while logged into .social, what you actually saw was a copy of my post that is being hosted on .social itself.

When someone on .social follows my account on KPO, the server at .social tells KPO that they’re interested in my ideas and that they’d like to subscribe to my newsletter on behalf of its users. As a result of this request, KPO will send any new posts I publish to .social, and .social then stores them in its database so that its users can view it, should they choose to. But, again, they are only viewing the posts that are being stored in .social’s database. They only have access to those posts.

Because everything is local.

So What?

Ok, everything is local. What does it matter?

Well, here’s the thing. While people have fixated on Mastodon’s search being limited to only hashtags — a purposeful design choice, and a somewhat interesting one, in my opinion — as a major hindrance to “discoverability”, it’s a total red herring. The real hurdle to finding others on the Intersnet is that, as with everything, search is local. That search bar on your Mastodon, or Misskey, or Friendica website only searches that website, and no others. If a post has not been delivered to the server, it doesn’t exist as far as the server’s concerned. Similarly, if a user has never been followed by someone on your instance, or they’ve not had a post of theirs boosted by someone who is followed by someone on your instance, you’re not going to be able to find them via the search bar. They’re not going to have a user record in your instance’s database.

Servers on the Intersnet are not actively web crawling each other to make sure they have complete records from everywhere else. The whole network is built on top of a subscribe then receive model of communication.

That order is important, too. Just as subscribing to National Geographic Magazine doesn’t result in them mailing you their entire catalogue of back issues, subscribing to a user’s post feed doesn’t fetch their post history. Your server will only receive and store posts published after the subscription request has been approved. And if the sever isn’t receiving those earlier posts, you’re not going to see them in a user’s profile when you view it (because, again, everything is local, including user profiles), and you’re not going to be able to search for them via the search bar.

Incidentally, this all applies to hashtags, too. The ability to follow hashtags has been spreading through the Fediverse (ok, I’m done now), but unlike user accounts, hashtags aren’t sources of posts. They’re not something your host server can subscribe to in the same way they can subscribe to a user’s output feed. It can’t call out to a hashtag’s host server and say “please send me everything posted by #cats” (as an example), because #cats doesn’t live on any given server. There’s nowhere to actually request that from. Instead, following a hashtag just searches the local database for posts with that hashtag in them and adds them to your Home timeline.

Hashtags don’t get around the locality issue. You still won’t see non-local posts by searching for a hashtag or clicking on a hashtag link.

What’s actually important for discoverability on this network of independent-websites-that-talk-to-each-other is boosting posts. When you boost a post, you’re adding it to your own output stream, which means it gets sent to all of the servers who are subscribed to you. Only then does it become ‘discoverable’ — searchable, viewable, etc. — by people on servers who do not subscribe to the original poster. Only then does the original poster become a known user to those servers.

Boosting makes remote posts, and remote users, local.

And everything is local.