As a web developer, I love Mastodon:
That being said, Mastodon still has several major weaknesses. In this blog post, I collect those and explain what’s being done to fix them. It is not meant to be exhaustive: If there is a weakness that affects you and isn’t mentioned here, then please let us know in the comments.
Disclaimers:
Social network vs. social network platform: These two terms are closely related. The social network platform is the software and the social network is the people and programs using that software. You could also argue that a social network includes its platform. In this blog post, both terms are often used interchangeably.
Federated vs. centralized: Defining this difference for social networks is tricky because there are always some centralized aspects. For myself, I ask one question of a social network: What happens if the server/service I’m using disappears? If that means that I lose my followers and followees then the network is centralized. Note that Mastodon still has weaknesses in this regard. We’ll cover those later.
ActivityPub: the protocol on which Mastodon is based.
Fediverse: All social networks that support ActivityPub are compatible with each other and therefore form one big (meta) social network – which is called the Fediverse. Mastodon is part of the Fediverse. This blog post is about Mastodon, but many things also apply to the Fediverse at large.
World Wide Web Consortium (W3C): The standards organization that manages the ActivityPub standard. It also manages many other web standards.
On one hand, the Mastodon team is small, progress is slow and money is tight.
On the other hand, things are getting better all the time. And Mastodon is financed sustainably, mostly through donations. That ensures, e.g., that Mastodon will never have ads – which would be tricky to implement in a distributed setting, anyway. Thus: If you want to see Mastodon succeed and can afford it: Donate to Mastodon gGmbH and to your server (unless it’s managed by Mastodon gGmbH)!
Another factor slowing down improvements is that ActivityPub is a W3C standard. And evolving standards takes time. The upside of a standard is that no single party dictates where things are going. The Fediverse has become quite diverse.
To understand Mastodon’s weaknesses, it helps to have a rough idea of its architecture. To clarify the compromises that are involved in its design, I’ll contrast Mastodon’s architecture with Bluesky’s (another social network with a different protocol that also supports decentralization).
Among others, the core of Bluesky is made up of the following services (source):
In Mastodon, the core unit is the server (the “instance”):
A Mastodon server deliberately has a more local view of the whole social network (the Fediverse): It contains the posts of its users, the posts they boost, and the posts of the accounts they follow.
Mastodon’s approach helps with distribution: It’s easier to host an independent (sub)ecosystem because a server doesn’t have to store and moderate the whole network. But it also limits search and algorithms – more on that later.
Solution: The Mastodon team is working on quote posts – announcement on 2024-10-08:
Now that 4.3 is done, our focus for the next release will be on implementing the highly requested features of quote posts [...]
This is one of Mastodon’s biggest weaknesses at the moment: When you are on your server and visit a post from another server, you only see the replies that your server is aware of. To get a full picture of a conversation, you have to go to the other server. Thankfully, help is on the way:
This weakness is related to the previous one: If you look at a profile from another server through your server:
Mastodon now does have full-text search and an algorithm (the “Explore” section of the user interface) but those only have a local perspective of the Fediverse and are therefore limited – especially on small servers.
How do we fix that? We need search engines for the Fediverse. Those can provide global search and algorithms for global discovery. In a way, that’s what Bluesky’s Relays are: They crawl all Bluesky accounts, as hosted by Personal Data Servers.
The project “Fediverse Discovery Providers” is working on the foundations for Fediverse search engines: “This project explores the possibilities for better search and discovery on the Fediverse in the form of an optional, pluggable service. This service should be decentralized, independent of any one specific Fediverse service and respect user choice and privacy.”
On Bluesky, you can create and share custom algorithms. That would be a neat feature to have for Discovery Providers.
Mastodon servers can already schedule posts but that functionality is currently not exposed in the web app and Mastodon’s official native apps. I don’t know what Mastodon’s plans are but it seems like user interface support would be added eventually(?)
Fedi.Tips has more information on scheduling posts.
Problem: Your account on your server is also your identity on the whole social network. If your server disappears (where the cause can be technical, financial, legal, etc.) then you lose your identity.
Solution: Nomadic identity, an idea first implemented in 2011 by Mike Macgirvin. Your identity is independent and points to an account on a server. If the server disappears, you can point your identity to a different server.
Some protocols that support nomadic identities, such as Zot (Hubzilla servers) and Nomad ((streams) servers), also support cloning – multiple accounts that stay in sync and have the same identity. If someone follows an identity, all associated accounts are considered equal and the identity’s owner can post, reply, etc. from any of those accounts.
Work in this area is ongoing. It’s not yet clear if and when Mastodon will support nomadic identity.
The W3C Social Web Incubator Community Group has published a draft report titled “Data Portability in ActivityPub”. Data portability is related to nomadic identity – quoting the introduction: “Data portability is the ability of a user to move their data from one system to another system. This includes moving between ActivityPub implementations, moving to different installations of the same software, or changing domains.”
The report sketches two approaches.
Move
activity That is how Mastodon currently works. A user’s ID is tied to a server. When moving servers, followers are automatically unsubscribed from the old ID and subscribed to the new ID.
Domain portability: A user’s ID is a domain name. The domain can link to an account on a server (e.g.) via a DNS record or via a file stored in a well-known location on a server at that domain. When moving servers, the user creates and archive of the data on the old server and imports that archive on the new server.
On Bluesky you can use a domain as your handle (user-facing global account ID). But the actual internal ID for an account is a so-called decentralized ID (DID). The mapping between a domain and its DID is done via a DID document, which is hosted at the domain (DNS record or file on server). It contains:
What does that additional indirection give you? It makes your identity even independent of the domain. However, for my personal needs, the domain being the ID would be enough, I don’t need DIDs.
The Mastodon web app has one interesting usability issue:
That becomes an issue if you go to a post (functionality #2) on another server and can’t do anything with it (functionality #1). There are two approaches for solving this issue.
Currently, users are often going back and forth between the web app and the non-app web (posts and profiles on other servers). Usability could be improved if users could stay in the web app. Then the web app would be much like a native Mastodon app. Thankfully, that will be the case once some of the aforementioned improvements are implemented:
The original URL of posts (and profiles) is still needed for sharing, though. Unfortunately, URLs of posts inside the web app exist too and their IDs (the digits in the URL) are different from the original IDs – e.g.:
https://fosstodon.org/@rauschma/112728257468727280
https://mastodon.green/@rauschma@fosstodon.org/112728257779798650
But maybe that slight confusion is unavoidable. In native apps apps that isn’t an issue but you pay for that by them feeling more restrictive (at least to me).
People are also working on single sign-on for the Fediverse. Once implemented, you’d log into your server and all Fediverse servers would be aware of that and operations such as replying and boosting could be performed as if you were on your server.
Important consideration: Currently, you can switch to a different account by going to a different server URL. With single sign-on, the Mastodon web app would have to support switching between multiple accounts. A side benefit of such functionality is that it also helps with switching between accounts on the same server (which is currently a bit of a hassle).
Relevant Fediverse Enhancement Proposal:
The two approaches are not mutually exclusive. There are many tricky usability issues in this area and I’m not sure what the best solution looks like:
Content moderation is the responsibility of the people running a server and it is a thankless, unpleasant, labor-intensive and important job. Moderation teams are often understaffed. It’s a difficult field because it involves people, not just tech. Improvements are ongoing. Random thoughts of mine:
Moderators can be helped by more tooling, more automation and more sharing of work across servers:
Being explicit about moderation issues is a double-edged sword: On one hand, it exposes moderators to attacks. On the other hand, it makes users aware of what happens on their server – e.g., actual moderation decisions may be quite different from what a server proclaims in their principles. Currently, accountability relies on anecdotal evidence.
Option for blocking: Tell the blocked account why they were blocked.
Mastodon’s “a server is a community” idea helps with moderation:
“Moderation as a service” can also be useful – for administrators who would like to pay someone else to moderate their servers.
Because no algorithm rewards engagement, it’s more difficult to spread disinformation on Mastodon.
Resources:
The Dot Social Podcast has an insightful episode on this topic: “Rethinking Trust and Safety in the Fediverse, with Samantha Lai and Jaz-Michael King”
IFTAS Connect is a portal for Fediverse moderators.
If you block a user, they are only prevented from replying to your posts from now on. Existing replies remain. You can’t see those replies but others can.
What functionality would be useful?
Ideally, the author of a post would be able to hide replies anywhere in the tree whose root the post is. However, even the ability to do so with direct replies would be helpful.
More control over who can reply also seems useful. Conceivable options are: accounts mentioned in the post, only followers, everyone.
Quoting a post by Mastodon contributor Emilia with interesting context: “In Mastodon we don’t currently manage the replies collection on each post, and instead just fetch everything that says it’s ‘in reply to’ that post. Fixing that would be a big lift, but would solve many problems around replies.”
Relevant on GitHub:
When I started my research about what’s being done to fix Mastodon’s weaknesses, I wasn’t sure what I was going to find out. I’m happy that most of my complaints are already in the process of being remedied.
Among those issues where it isn’t certain what Mastodon is going to do, the optional separation of identity and server stands out to me: It eliminates the risk of losing one’s social identity when its server disappears. And it reduces the pressure of picking the “right” server because it’s easy to move.
Unexpectedly, my research also renewed my faith in Mastodon’s architecture, even when compared to Bluesky’s – e.g., all of the downsides of Mastodon mentioned in a paper about Bluesky are relatively easy to fix (and not caused by Mastodon’s architecture per se). However, that doesn’t mean that Mastodon shouldn’t steal some of Bluesky’s ideas, such as custom algorithms.