Mastodon’s weaknesses and how to fix them

[2024-11-20] computers, decentralized, mastodon
(Ad, please don’t block)

As a web developer, I love Mastodon:

  • Since Twitter became X, there are enough web dev people here.
  • I’m happy with the web app – it even has several nice touches where it is better than Twitter.
  • I’m not locked into an ecosystem that is controlled by a single company.

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.

Disclaimer: I tried to be thorough in my research but my knowledge of Mastodon and Bluesky is limited. Thus, I may get things wrong. I appreciate corrections where I do.

Glossary  

  • 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.

Why doesn’t Mastodon improve more quickly?  

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.

Mastodon’s architecture  

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).

Bluesky: Relay services contain global snapshots  

Among others, the core of Bluesky is made up of the following services (source):

  • Personal Data Server: hosts accounts
  • Relay: “crawls” accounts, much like a search engine. It provides other services with a global view of the social network (a “firehose”).
  • AppView: indexes the content in Relay in various ways, so that apps can access it efficiently.
  • Labeler: associates “labels” with the items returned by AppView – metadata that describes those items: Is its content sensitive? Is its content misleading? Etc.
    • One interesting aspect of Labelers is that you can subscribe to zero or more of them. How to react to labels (hide, blur, drop) is up to client apps.

Mastodon: instances contain local snapshots  

In Mastodon, the core unit is the server (the “instance”):

  • It defines a community: Its language(s), its rules, etc.
  • Moderation is handled at this level.

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.

Shorter-term improvements (certain or likely)  

Problem: You can’t quote posts  

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 [...]

Problem: You don’t see all replies  

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:

Problem: On other servers, you only see part of a profile’s data  

This weakness is related to the previous one: If you look at a profile from another server through your server:

  1. You only see the posts that your server has stored locally.
  1. You only see followers and followees that your server is aware of.
  • Discussion about this issue is ongoing (e.g. here). It’s unclear if and when this will be fixed.

Problem: no global search and algorithms  

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.

Problem: You can’t schedule posts  

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.

Longer-term improvements (uncertain)  

Problem: Your identity is tied to your server  

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.

Draft Report: Data Portability in ActivityPub  

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.

Approach 1: ActivityPub 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.

  • Downside: Moving posts is tricky (maybe even impossible) because you’d have to update all of the old posts (replies etc.) and the notifications they caused.
  • Downside: You have to prepare for the move in advance. If the old server goes down unexpectedly then you lose your identity.
Approach 2: Domain portability  

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.

  • Missing piece: standard backup format for ActivityPub accounts
  • Missing piece: support for domain names as user IDs
  • Downside: Creating an ID requires more work for users.
  • Upside: No need to prepare for the move in advance (apart from keeping backups of your data).
Bluesky uses decentralized IDs for users  

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:

  • The handle of the user
  • The URL of their Personal Data Server (PDS)
  • The public key that is used to sign their account data

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.

Other ideas and projects  

Servers as web apps vs. databases of posts  

The Mastodon web app has one interesting usability issue:

  1. On one hand, a server is a web app.
  2. On the other hand, it also hosts profiles and posts.

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.

Approach 1: never leave the web app  

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:

  • Then going to a post (or a profile) in the web app gives you all information you need and you don’t have to go to the server of the post (or profile).
  • Because Mastodon currently doesn’t support quote posts, people include links to other posts in posts. Some apps display those as quoted but the Mastodon web app doesn’t and sends you to the post’s server. Once it supports quote posts, that issue goes away.

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.:

  • Original post: https://fosstodon.org/@rauschma/112728257468727280
  • Post viewed from another server: 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).

Approach 2: single sign-on  

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:

Which approach to choose?  

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:

  • The programmer in me prefers approach 1 because it’s clean and we’re almost there anyway.
  • Approach 2 makes Mastodon’s API more complex but also has usability benefits.

Other kinds of issues  

Moderating servers  

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:

    • With automation, false positives (wrong measures) become an issue.
    • Some threat actors distribute their attacks (malicious accounts, spam, etc.) across servers. Sharing moderation work between servers can help.

  • 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:

    • If someone creates a server for a rare human language, it’s more likely that there are moderators who speak that language.
    • You can pick a server whose rules work for you.

  • “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:

More control over replies  

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 delete 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 GitHub issues:

Miscellaneous improvements and ideas  

  • Important for preventing compatibility issues in the Fediverse – a test suite for ActivityPub: FediTest
  • Some ActivityPub feeds are very simple. I’m wondering if it would help if you could follow simpler feed formats from Mastodon – e.g.: RSS, Atom and JSON Feed.
  • Support for incremental backups seems useful – especially given that servers don’t make any guarantees about how long they are going to store posts and attachments. Such backups could be provided by external tools or services.
  • Bluesky provides Starter Packs with custom feeds and recommended follows. Work to bring the latter part to Mastodon is ongoing: thread on Mastodon.

Conclusion  

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.