To technical users, federation is an easy sell. I find it surprisingly hard to explain the benefits to non-technical users, though. And that’s because centralized services are usually easier to use: It’s easier to get started as a new user and easier to find things (users, data, etc.) – simply because everything exists within a single system.

Let’s quickly review the differences between centralized and federated services:

Centralized (Twitter, Facebook): a single service manages the data of all users and their communications.

Freedom: No single company controls server and client. You can choose both.

Competition: between multiple implementations of servers and clients is good for innovation. For example, many important parts of Twitter originated in third-party clients (which have since seen their freedom reduced by Twitter). [source 1, source 2]

Within a toot, you refer to accounts on the local server via @local_user. Accounts on other servers can be mentioned via @remote_user@other.server.com. When a toot is displayed, only local names (e.g. @local_user and @remote_user) are shown, which reduces visual clutter.

Two formats are common for writing down account IDs:

remote_user@other.server.com

https://other.server.com/@remote_user

I’m not sure #1 is a good idea, because it is easily confused with email addresses. If you use that format, you should prefix an @, like Mastodon does in profiles.

Home: works much like timelines on Twitter and Facebook. Here you see all toots from people you follow.

Local timeline: all toots from people hosted by the current server.

Federated timeline: the local timeline plus toots from other – federated – servers that are seen by users on the current server. That is, if you follow someone on another server, their public tweets appear in the federated timeline.

The local and federated timelines tend to get really busy. I’m ignoring them and using Mastodon like Twitter.

Many Mastodon servers form communities and thus bring back a sense of location to social networking. The administrators of servers also serve as moderators. Therefore, picking a server enables you to choose levels and ways of protection and filtering. It also lets you choose what people you want to be “surrounded with”.

But you also have the option of mostly ignoring the community aspect of servers and to use Mastodon like Twitter.

Unlisted: everyone sees it, but it doesn’t show up in local and federated timelines.

Public: it shows up everywhere.

This kind of per-toot privacy setting is nice, because you don’t need separate accounts, like on Twitter. However, it comes with several big caveats:

The administrators of servers can see everything – all your toots even the direct ones. This sounds scary, but is not much different from services such as Twitter and Facebook that don’t provide end-to-end encryption. Administrators even have complete access to your account and could impersonate you (etc.). So you should really trust them.

Any server who accesses your account can see all your toots.

You can’t delete toots that were federated to other servers.

It is best to assume that all your toots can be read by everyone, forever.

Search engines could play an important role for federated social networks and help with two of their weaknesses:

Searching content

Finding users

They would simply crawl Mastodon servers the way they crawl the web. It may even be a kind of social network that Google is willing to support: They are not in control, but neither is Facebook. And the data is openly accessible.

Pick a local user name that is as unique as possible. This makes it easier to keep the name when moving to a different server.

To follow someone, use the search function to find them. Searching for a user’s real name will only work if they are on the same server or cached on that server. Otherwise, you need a user’s URI or global ID.

Do write a biography. Surprisingly few people do so, but it helps to give you a rough image of who someone is. For example, you could just mention stuff you are interested in and where you are located.

Use the Mastodon bridge: On this site, you log in via Twitter and via Mastodon and then see which of the people you follow are also on Mastodon. Obviously, they only appear in that list if they have used the bridge.

Like on Twitter, you can start with a few people and then find more, over time, via boosted toots.

Having a federated service is awesome. I’ve waited years for an open alternative to Twitter. And Mastodon could really be it.

It’s amazing how well federation works. I am following several people from other servers and I am not able to tell that they are hosted somewhere else. Let’s hope federation will scale to millions of followers.

Posts on Mastodon can be up to 500 characters long. It’s good to have more room to express your thoughts. The limit ensures that posts don’t become too verbose.

The web app is responsive and works well on desktops, tablets and phones. Once again, the web excels as an app platform.

Automatic posting, either from Twitter to Mastodon or from Mastodon to Twitter. That would it make easer to fill Mastodon with content, while still taking care of one’s Twitter audience (which most people can’t afford to abandon).

Notifications don’t scale as well as they do on Twitter, where they are more aggregated. I’d like to have an extra view for mentions (which are the most important kind of notification).

For now, the Mastodon bridge works for finding users. In the long run, there should be a centralized service that helps here. This could be achieved via a registry and by crawling web sites for embedded microdata.

It’d be great if toots could be commented like you can on Twitter. An embedded toot URL should:

Send a notification to the author of the referenced toot.

Show the content of the embedded toot inside the embedding toot.

Advanced features:

I’m missing features provided by TweetDeck: scheduling tweets and teams (a single account being shared by several people).

There could be automated support for migrating to a different server.

End-to-end encryption would be nice to have. But I’m not sure how compatible it is with its approach to networking. Before that, we’ll probably get tools for encrypting single toots.

PubSubHubbub: lets you subscribe to feeds. Whenever a feed is updated, you get notified. This means updates reach you much faster. Wordpress and others also support this protocol.

Salmon: sends items from Atom feeds to parties that are affected by them. For example: a user mentioned in a post is sent that post; a reply to a post is sent to the author of that post; a user is told if they have a new follower. The notifications “swim upstream”; hence the name “Salmon”. Salmon is based on Activity Streams.

Webfinger: lets you look up information about people via URIs. The information is encoded as JSON and can provide data such as homepage, telephone number or avatar image.

Mastodon being compatible with OStatus means that you can seamlessly follow users from other OStatus-based social networks.

Mastodon is the first federated social network that feels viable to me. On one hand, it’s UX is decent – all previous federated social network I’ve tried were awkward to use. On the other hand, the recent increase in popularity helps, too.

Three critical issues will be:

Will Mastodon scale as its popularity grows?

Will Mastodon remain financially viable?

Will anti-harassment measures work?

In all three cases, things will evolve and lessons will be learned. But it’s great that we are making progress in the area of federated social networks.

Monetization is interesting, because there are no ads in Mastodon, nor will there ever be. If you want to support its development, you should donate to its author Gargron: via Patreon, PayPal or Bitcoin. Some people running Mastodon servers are also accepting donations. Some are promising to pass on money to Mastodon, once their costs are covered.

I’d also be OK with servers charging for hosting accounts. I think corporate support can coexist with the open source nature of Mastodon. It may even be beneficial to its long-term survival.