cross-posted from: https://lemm.ee/post/56496251
I’d like to add to suggest a couple of things regarding Mastodon and user onboarding/retention.
The Server Selection ProblemTM
The single biggest problem with Mastodon adoption is the fact people see talk about a server and give up. As such, servers need to be removed from the conversation and onboarding process. A server still needs to be selected for a new user, however, which raises the question: How should we select a server for a new user?
The obvious solution is to simply direct users to mastodon.social, which is actually what Mastodon already does to a certain extent. The issue with this is that the Fediverse is meant to be decentralized. As such, it’s counterproductive to funnel people towards a single server. This causes maintenance bottlenecks and privacy/data-protection concerns.
As such, there needs to be some sort of method that ranks servers based on a few factors in order to select the optimal server for any given user, while keeping the decentralized nature of the Fediverse in mind.
Why any server?
First, it’s important to answer the question of why would any given user pick any given server.
Generally speaking, the server isn’t a big deal, as in, any server allows users to interact with the whole of the network in its full capacity.
All servers are Mastodon, after all.
However, there are differences. The most significant ones are, I’d say: location, uptime, and language.
A user benefits from being registered to a server that’s geographically close to them, as that leads to a better connection. Additionally, servers with high uptime and stability are preferred, as users may have different times they use the server and nobody likes to try and access a server and see that it’s down for any number of reasons. Finally, users need to be able to understand the language the server is in (obviously).
I believe these three factors should be at the forefront of the decision-making process for deciding what server to be suggested to any given user on sign-up.
Auto-selector
With that, comes the solution: a server auto-selector. A game I play, DCSS, actually does something similar for online play.
(I have my location turned off and there are very few servers, as you can see, so listing them is trivial.)
This isn’t exactly a novel scientific breakthrough, but I think it’s a significant notion for helping the onboarding process for new Mastodon users.
A server auto-selector should filter servers to suggest by following these steps:
- Detect the user’s system language.
- Detect the user’s location.
- Calculate the server’s uptime score.
- Pseudo-rank user-count.
I believe the first two points are self-explanatory. Being that Mastodon (and the Fediverse, in general) stands firmly against data-harvesting, location data should probably not be mandatorily collected. It should be easy to either ask the user for some vague information or simply allow them to skip this step entirely, even if it might affect the user experience. Additionally, there’s the issue that many servers don’t make it known where they’re hosted. Ideally, this could change to facilitate server selection for the users, but there’s always the point that, if a server doesn’t say where it’s hosted, it gets pulled down by the algorithm, which in turn encourages divulging that kind of information; this might a problem solved by the solution, if you get my meaning.
What I mean by uptime score is simply an evaluation of the server’s uptime history. For example, it’s not good policy to direct users towards servers that are often unavailable, it might be disadvantageous to direct users to servers with too-frequent downtime for maintenance, and so on. As such, the server auto-selector should calculate a sort of “score” for any server that fits the first two points. I can’t say how this should be calculated, exactly, but I’m sure some computer-knowers out there can come up with a less-than-terrible methodology for this.
The last point is something that I think should be taken into account as well, regarding the user-count of the servers. As I mentioned, we can’t funnel users towards a single server, but another issue is that we should actually encourage user dispersion over many servers. The outlined method might already do this to a sufficient extent, but I suggest doing some sort of randomization of filtered servers based on user-count. I think it’s wrong to simply plug a new user into the least-populated server around, but I do think that over-populated servers, in a relative sense, should be discouraged by the server-selector.
Worst case scenario, a random server that passes the uptime score point can be selected for any new user.
The onboarding experience
Basically, this should be as simple as possible. The more questions need to be answered, the worse.
I think a simple “Join Mastodon” button is the best. Just a big blue button in the middle of the homepage.
Server selection should start as soon as the new user accesses the joinmastodon website, and clicking the button simply redirects the user to the sign-up process for that server.
I believe this approach would increase adoption of Mastodon by streamlining the server selection process, as well as help the continuous decentralization of the Fediverse.
The Feed Problem
Another significant issue with Mastodon is the feed and community/discovery aspects.
Creating a new Mastodon account yields… Nothing. An empty feed!
This is absolutely terrible and ruins user retention. I’ve had several people tell me that this first-experience emptiness completely turned them off from Mastodon. It’s not intuitive, and it needs to be corrected.
A simple solution
Mastodon does have feeds, but they’re all tucked away in the Explore and Live Feeds tabs.
I think the single biggest change that Mastodon can make, as far as this goes, is to shift the Explore->Posts feed to the Home tab. Just do it like Twitter or Bluesky, make the discovery feed the first thing a new user encounters.
That, by itself, should make a difference in terms of user retention.
Maybe I’m delusional and severely underestimating how doable this is, but I really believe Mastodon needs to change the way it deals with new users if we want it to actually grow into a strong social media, keyword social (it needs people).
Thoughts?
I think there’s a few other issues with server selection
Longevity. How do you know that the server you are on will be there in 1, 5 or even 10 years? For larger servers like Mastodon.social you have a general idea that it will last as long as Masto itself, but others have very little guarantees on if you’ll log in and find your entire feed gone. It only takes
That brings me to my next point: migration is currently inadequate. Migrating accounts only redirects your following/followers lists and some account settings. All of the posts, reposts and content uploaded are left on the old server and potentially wiped out if it’s shut down. Professionals or anyone who wants a lasting online profile need to stick to big instances because they risk losing everything if their server can’t continue. I also feel like there should also be an emergency “export all” button the admins can press, so the server will email all users a copy of their data in case of shutdown. That way users who can’t export their data manually before the end date will have a copy of it. And this still doesn’t solve the issue of small servers shutting down out of nowhere and wiping out every user’s profile on there. If that happens to an average user they’re probably just going quit Masto outright
Defederation is a good idea to keep bad servers isolated from the community and let servers dictate how open they want to be. But there’s not a lot of indication of what servers have blocked/restricted the one you’re signing up for, other than going to another server and seeing if the admins have manually typed up a list of that they blocked/restricted. There’s also not a great way to see if the server you’re looking at is read-only and any posts you make aren’t being seen by users on the other server. Or that you’re looking at a server that has since defederated and will no longer update posts. Also (afaik, there’s not a ton of good explanations) but if you’re newly connecting to a server it will only federate new posts going forward and not previous posts. Which again messes things up for people who want to use it as a consistent timeline. Dropping users into random small/medium servers risks preventing them from seeing their friends posts or cutting them off from their friends entirely
You mention data privacy as a risk of large servers, but how is it any better on small servers? You have no idea if the user you’re handing your data over to is trustworthy or reliable or that the server they manage is secured. And how do you know that a large company won’t come in and offer them money to sell the server, and suddenly all your data is in the hands of spammers? And direct posts are not private. Plenty of people on Twt used their real names/emails/pictures. It’s not going to be viable to have every user create a burner email and never reveal any info, even in private messages without them deciding it’s not worth it. Alternatively, they have to verify the trustworthiness of every admin on a potential server, despite them likely only having a username and posts to work off of
I think there are bigger issues than “just choose a server, they’re all like email” that causes people to gravitate towards larger platforms. It’s not just connectivity and uptime, there are logistical issues that will impact users if Masto gains more mainstream adoption. I haven’t even touched on the threat of bad actors and spam which I don’t feel like the network is ready for yet
100% percent! This needs to be taken into account.
I definitely think account migration should be improved, but I wonder how feasible that is, in a technical sense… I don’t know how that sort of data is structured at all.
That’s a good point. Once again, I really don’t know of a solution to this. I’m not too familiar with how federation works, in a technical sense. Servers should definitely make their blocked servers and whatnot public by default, though.
Of course, it’s impossible to make sure that every single server is safe. My point was that, if everyone is in the same server, then the risk of something going bad for any number of people increases, versus if everyone is in a bunch of different servers. I guess it’s a balance between the trustworthiness of many people with control over a few and the trustworthiness of a few people with control over many. Maybe it’s not so relevant. Most people don’t care about privacy anyway, I was just trying to make a point about why decentralization should be valued in a practical sense.
Yeah, there’s a lot of things that still need to be improved!
I’ve weighed in a few times on the “choose a server” thing on various federated platforms. When signing up for a Fediverse service, you’re presented with the following contradiction in terms: “Choose an instance. Your choice does not matter. The choice is yours.”
There are two ways to fix this:
We embrace “the choice doesn’t matter” and the new user gets assigned an instance automatically. I think this will require some kind of formal agreement and a badge of compliance among server admins, a kind of verified checkmark. Enforce a common set of moderation rules, maintain some technical requirements like uptime and version updates etc. and agree to accept anyone who clicks the random button, you get a checkmark and randomly assigned users. The Windows software install wizard asks you “You want to go with the default settings or you want to make some decisions for yourself here?” Operating system installers do the same thing, and the “something else” choice is often last or less prominent. Because most people just want it to do the normal thing, but sometimes people have a reason to pick something specific. “Join a random server” is a big prominent button, “or, pick a server manually” is a hyperlink just below it.
Make the choices meaningful. I see this one happening the most on Peertube where storage and bandwidth are both significant costs, so the instances there are more likely to segregate by type of content. “We host arts and crafts” “We host video game let’s plays and speedruns” “We host travel and nature videos”. Even if you have eclectic tastes, that choice has meaning and thus isn’t as paralyzing.