Quick Note: This article is a response to Tim Chambers' recent writeup, titled The Seven Deadly UX Sins of the Fediverse Web Experience (To Fix). It's a pretty great read, and I'm writing this not as a rebuttal, but to analyze and expand on the points made.
Preface
I sometimes say this too much, and maybe it's a bad habit, but: I've been on the Fediverse in some meaningful capacity since 2008. That's 17 years. A lot has changed and evolved over time, and it's amazing to see the network carrying about 12.5 million accounts (of the ones that could be accounted for). It often feels as though we're just on the cusp of mass adoption, if we could just fix enough usability problems.
Some of these issues can be fixed through iterative design. However, I think some problems go much deeper than what they appear to be on the surface. I want to go through some of Tim's observations, and adjust the context to account for root causes and possible solutions. To be clear: I think some of Tim's criticisms are actually more specific to Mastodon itself, but I think we can extrapolate some larger patterns from what's being said.
Sin #1: The First-Move Problem
The Sin of Overwhelming Complexity: Instance Selection Paralysis
Imagine the moment you decide to join the Fediverse. You’re feeling a tad noble. Brave. Ready to reclaim your digital life from Big Tech’s clutches. Then… boom. You’re confronted with a cryptic list of servers, each with a name that sounds like a cross between a startup pitch and a medieval tavern.
I made this a while back, and love finding excuses to post it.
This is one of the biggest problems with the Fediverse today. While I wholeheartedly believe that having a diverse network of different servers and platforms to choose from is a good thing, the process of picking one server and finding your friends is incredibly rocky. You basically have to learn how to navigate several key parts of the Fediverse before ever connecting with friends on another server.
To make matters worse, there's a lot of unknown elements regarding any server you might potentially join:
- Some communities outright block one another.
- Some servers are poorly moderated, or not moderated at all.
- A lot of servers struggle to make enough user donations every month to cover operational costs.
- Often, server discovery requires you to first go to a given platform's website, then read a directory, then pick your options based on what's available.
This can create a lot of friction, even in the best of circumstances.
My Proposal
This is something that I don't think can be solved by one simple UX fix. However, I think it could be supported with better infrastructure across instances. In fact, it's possible that we're approaching onboarding and migrating at the wrong level.
First: Identity, Content, Connections
What if, instead of simply making a person choose a server, we first focused on setting up an identity and porting over content and connections from other networks? I find myself regularly thinking about Bounce by A New Social, which already kind of sets some groundwork to make this possible.
What if we built a utility that could import your profile and posts into your new Fediverse profile automatically, before you even bothered to sign up on a Fediverse server?
Don't get too excited, this isn't a real product. (Yet)
Basically, this utility would almost act as a "pre-identity", acting as a conduit where all of your social data could be hooked in prior to creating your Fediverse account. From here, you could pick and choose what to pull over. Do you want everything you've ever posted on Facebook? Great. Would you rather filter it down to stuff that has the most replies and interactions? No problem.
The importer could be customized for each platform, which could also help recommend what Fediverse platform a user might choose.
From here, we could do some interesting things with providing recommendations. Maybe we could include a survey portion, or even parse a bunch of likes from the import to make a recommendation on what kind of community they should join.
I'm not totally happy with this design, but this is the general idea. Service picks for the user, while allowing them to manually override it.
Second: Joining with Friends, Discovery, and Sync
I have a couple of ideas about this, but don't currently have the energy to make full mockups. Firstly, I believe we could really ramp up the momentum of user migrations if people could join together at the same time. There are a myriad of considerations to make, but here's how I think it could work.
- Joining With Friends: Through their social connections in the app, users could easily invite their friends to join them. The invite wouldn't put those friends on the Fediverse yet, but they could all get accounts on the SocialImport app to get set up. Maybe a threshold would be set where the actual migration action only happens after a threshold has been set? One careful consideration to make: check server blocks, and do some logic to make sure they all end up on servers that don't block each other.
- Discovery: It might be possible to do friend discovery in the background, by containing some kind of reference to other connected accounts. Oh, you have a Facebook integration, and 12 of your friends also used it with this tool? Cool, here's their details, which are only available to mutuals. You'll automatically connect when you do the final move action.
- Sync: Maybe you're the first-mover, and your friends haven't moved over yet. No problem! Keep the connection with the SocialImport tool alive, and your friends will automatically find you over time. A sync utility could also help with the import of very large data archives, by gradually pulling bits and pieces in over time instead of importing everything all at once.
Sin #2: Navigation Inconsistency
The Sin of Inconsistent Navigation: Timeline Turmoil
You’re finally ready to explore your new digital neighborhood. And then—bam. Three timelines. Not one. Not two. Three. Home, Local, Federated—each more enigmatic than the last. The Fediverse’s multiple timelines are a beautiful idea in theory, but in practice?
Yeah, that's...one way to use the Social Web, I guess.
To be fair, this one is more of a Mastodon criticism specifically, and it's kind of a vestige of some of the platform's earlier design decisions. The Federated timeline was actually kind of useful in the days where the network was a lot smaller, and Local is great on small servers, but the relevance of each is questionable at best these days.
The main problem here is that most people are really interested in their Home timeline. It's nice to leave the Local timeline available to people as an option, but Federated is next to useless these days.
My Proposal
Rethink the Home timeline to give people powerful ways to sort and filter their feeds. Yeah, 90% of the time I'm mostly just using a reverse-chronological feed to scroll through statuses made by my friends, but being able to do everything from one timeline interface is really ideal.
The "Open Social Web" custom timeline in Bluesky
Bluesky is already innovating in this area a lot with custom feeds and search, but more can be done. Some of this is being experimented with on the Fediverse right now, with projects like Channel.org and FediAlgo exploring different ways to make this work. My point is that we don't necessarily need more timelines, we need better ones.
Sin #3: Remote Interaction Hell
The Sin of Remote Interaction Purgatory: Federation Gymnastics
One of the Fediverse’s great promises is universal interaction—no matter which server someone calls home, you can still follow them, reply, boost, interact. In theory? Utopian. In practice—for web users—it’s an absolute effing mystery.
Look, this is a blind spot for a lot of long-time Fediverse users, myself included. If you've been on the network for more than a few years, you've gotten used to the mechanism of throwing a URL into the Search form to pull in remote statuses and profiles to interact with them.
This is so much better than what Mastodon used to provide for us. It used to just tell you to copy and paste text.
It's not a bad workaround for pulling in stuff your server doesn't know about, but it's not always reliable. Worse, it's become the main way a lot of us deal with remote interaction. The solution Mastodon uses now, depicted above, is miles better than what we used to have. However, it's notable that Mastodon's own improved solution typically only works with Mastodon.
My Proposal
The biggest shortcoming here is a lack of standardization. We really need to come up with some standard mechanisms. There's a few efforts worth mentioning, because I believe they are partial solutions: MagicAuth, and Activity Intents.
How MagicAuth Works
MagicAuth is one of the standout features of the Hubzilla project, and it's basically been around forever. In a nutshell, it's a novel approach where credentials are handled in a browser cookie to determine access.
I'm visiting a friend's page on a different server. The page checks my home server from a cookie, signs me in from my remote credentials, and I can interact with the page as if we were on the same site.
When you visit a page on a remote server, Hubzilla has a way to use MagicAuth to determine who you are, and provide access accordingly. It works seamlessly, and lets you see and interact with elements on the page as though you're actually logged in. MagicAuth is an incredible concept, and could potentially solve a lot of problems.
How Activity Intents Work
Activity Intents are a concept spearheaded by the Emissary project, and it works in a slightly different way. Instead of handling stuff through cookies in a browser session, Activity Intents allow you to connect an account to a given page through an OAuth connection, and almost use it as a very-limited client for sending activities back to your server.
When I click "Like" on a Bandwagon track, the above interface pops up to ask me which account I want to use for this interaction. I can use the Bandwagon account I already have, or I can use my main social account to do that instead.
You can almost think of Activity Intents to be a Web equivalent to the Share interface on iOS or Android, except that you can plug your own social platform and services into it instead.
Sin #4: Private Mentions Aren't Really DM's
The Sin of DM Disasters Waiting to Happen
And yet here we are - as on most Fediverse platforms, “Direct Messages” live right alongside public posts in the same composer, the same timeline view, sometimes even with mostly the same visual styling. You can toggle visibility to “Direct”… but will you notice you didn’t? Will you check? Will the UI save you? Spoiler: It will not.
It's no secret that Private Mentions on Mastodon kind of suck. The main problem is that they're a half-measure solution that combines Direct Messages with private posts, and certain unexpected behaviors are inherited.
A private mention in Akkoma, which works the exact same way that Mastodon does.
In a Twitter-style Direct Message, mentions only act as a shorthand for linking to a person's profile. If you're talking to Alice and mention @bob in a DM, Bob isn't going to receive any kind of notification that he was mentioned.
In Mastodon-style Private Mentions, Bob would get included into the conversation the moment he got mentioned. This mix of expectations on how a feature should work is pretty horrible.
My Proposal
Stop calling them Private Mentions, and instead call them what they are: private statuses. Build in real support for private Direct Messages where message-addressing is done outside of the post body, and just replace any Private Mention part of the interface with matching DM functionality.
Sin #5: The Phantom Social Graph
The Sin of Ghost Conversations and Phantom Follower Counts
Federation is the Fediverse’s secret sauce—and as implemented, its spectral curse. What should be lively, multi-user conversations often arrive with limbs missing. Replies that clearly should be there are gone. Half the participants never materialize. You’re reading a thread and suddenly think: Wait… who is this person even talking to?
This is a tough one. Part of the way conversations on the Fediverse works is that your own server fills in only the parts it knows about to the conversation tree. It's possible to change your server's behavior on how deep in the conversation it ought to pull statuses, but it's an inefficient approach at best.
My Proposal
Mastodon has been working on an improvement where it's possible to fetch all replies in a conversation tree. It's disabled by default, presumably because of the side effects of trying to pull in dozens, hundreds, or even thousands of replies from a public conversation.
I actually have mixed feelings on this. I'm all for improved methods for filling out missing bits of the social graph. My fear is that this might effectively DDOS many instances, as people attempt to fill out extremely large conversation trees from thousands of different places. Yeah, your beefy server might be able to handle this, but what about every server that's getting these requests over and over?
I think a partial solution for this may be to leverage some kind of distributed cache, where multiple servers can pitch in to help fill out the details for whoever is doing the fetching. That being said, that could be a huge can of worms.
Sin #6: The Discovery Problem
The Sin of Invisible Discovery: The Content Mirage
So what you get instead is discovery by divine accident: No algorithmic curation. No fediverse-wide trending topics. No “here’s what’s buzzing. Just you and The Void. So new users end up wandering along, stumbling across interesting people and conversations only by sheer luck. It’s charming - but only in a 19th-century explorer way.
I've written about this problem before, and yeah, it's rough. I think it's relatively easy to discover interesting posts from people across the network, but the more complex the media is, the more muddled discovery efforts become. Building small, intentional communities helps work around the signal-to-noise problem somewhat, but it's not a real solution for discovery itself.
My Proposal
Mastodon has been doing some interesting work with Fediverse Discovery Providers, but there aren't a lot of useful public details that describe how they're supposed to work, or what they even do in a practical sense.
I think there's two components needed to solve this problem: federated relays for boosting content, and custom feeds that can be used to filter these relay streams enough to make sense of them. I think relays can be extremely useful for projecting one part of a network across a wider portion of the rest of the network. If we could make the process of subscribing to a relay easier for instances across different platforms, this might help.
Sin #7:
The Sin of User Discovery Hell
Search is one thing. But finding people to follow—especially if you’re new—is where the UX - beyond just search - really starts to melt down. User discovery in the Fediverse is so decentralized, it’s basically unusable. No global directory. No “you might like.” No obvious trails to follow. Just vibes. And maybe a dusty wiki from 2022.
I'm of the mindset that sins #6 and #7 are one and the same, just in different capacities. What's interesting is that the Friendica family tree of platforms has had a shared universal directory concept for ages now. Separate instances can opt-in to bridging their directories with one another, which actually helps improve user discovery between those that choose to share.
My Proposal
I think a combination of discovery providers, user directories, custom feeds, and a configurable timeline could go a long way towards solving this problem. If we include the SocialImport idea, we might actually have a lot of good methods to help people find their friends and stuff they're interested in.
In Conclusion
💡
It actually took me so long to write this that I missed Tim's follow-up, where he also proposes a path to redemption for most of these problems. It should be interesting to see how our lines of thinking match up!
This ended up being a really long blog post that took me nearly a month to write, due to real-life obligations and much-needed time to think about things. I wrote this response, not because I want to invoke gloom and doom, but because I think a lot of this stuff is actually solvable. It's just that producing viable solutions requires a lot of cross-project collaboration, and also getting buy-in from the largest projects in the space, such as Mastodon.
With the Fediverse, nothing is ever perfect. However, we should never settle for less-than-good. If we can work together to overcome our biggest obstacles, it makes our network that much more viable as an alternative for millions of people in the future.
