the official one: https://joinmastodon.org/ and the alternative: https://instances.social/
Email does show us a greater need in Mastodon to emphasize trust-relationships over ill-defined "social groups" as better ways to form relationships. In the early days of email, the ISP was an easily formed trust relationship, and in today's arena a lot of people have preferred trust relationships to hosts like Google (Gmail) or Microsoft (Hotmail/Outlook), etc. The "people interested in Topic X" that most of the instance lists are focused on doesn't give you any information towards trust relationships, and is possibly in the way of forming them.
The immediate problem is that those large companies like Google or Microsoft with lots established trust relationships aren't expected to play in Mastodon/ActivityPub, so you need to bootstrap new ones. Luckily, there's a lot of room for trying to bootstrap new trust relationships. Some instances have already been playing with ownership models, and companies are easy enough to form if people want to place those ownership models into transparently accountable units/liability-protected units that are recognized by larger governing bodies than just themselves.
A friend I follow, Darius (@[email protected]), has also been ruminating on this quirk in Mastodon adoption lately and trying to find ways to establish trust relationships with instances, though so far his solution is to stick to a smaller scope and start with the idea of "you trust me, so let me host your instance" among friends. That idea might scale if there were enough folks like Darius doing that, and I've sent very simple invites to possibly add friends to my instance that I control, and have been looking to come up with governance documents based on that idea, but haven't yet had anyone take me up on that invite, so I keep procrastinating it.
If it's the former, then I don't understand the problem you're describing. Why can't trust simply be a hierarchy from the Mastodon devs-- who you have to trust anyway-- down to a small, diverse set of the largest and most performant instances (as defined by those devs themselves)? That would cover the vast majority of users and still obviously leave room for anyone who wants to run their own instance.
Even if the vast majority of users/devs think it's unethical to have a hierarchy/centralization, as you point out there isn't any known alternative at present. So the only practical alternative is to punt, which inhibits adoption and hardens the implicit social group hierarchies which you point out are problematic.
Most instances today advertise an interest in a topic, which is fine, but it doesn't answer a lot of questions. When the average person is looking for a trust relationship, they often aren't topic oriented, but reliability/stability-oriented. They want indicators of reliability: what's the governance model? How long is this instance expected to last/be stable? Etc.
Businesses in the real world already have a lot of that bootstrapping accomplished (because they are required so by governments, tax bodies, trading platforms, etc), so I made the suggestion that that's one way to make instance declarations towards governance models/stability/etc.
In that way, too, businesses as a model are still mostly decentralized in the way that users expect ("can take their business elsewhere"). Even if they are prone to monopolistic intents (when a profit model) and tend to accidentally centralize things.
A business model isn't the only approach of course, just one easy answer to how do you square the circle and solve the "which instance do I choose?" bootstrapping problem for a larger number of people more quickly. Even if formal businesses aren't the preferred option (though maybe they should be), the means of business government should still apply: what is the instance's constitution/bylaws/governing documents? Who holds the instance responsible in disputes? What is the cash flow and who holds that accountable?
A lot of these same business rules apply to so many organizations in one's life (your home owners' association, for one example) for good reasons of responsibility/accountability/stability.
Yes, almost all of these concerns are entirely orthogonal to the software itself and can't just be solved in software, as much as we might wish that to be the case as software developers. Running a community of almost any sort has these same needs. Brokering those community trust relationships is tough, but a deeper focus on that for Mastodon would help with adoption problems.
The only difference is that e-mail is "obvious" and Mastodon is new.
Not in my experience. Mastodon doesn't really have any (good) cross-instance discovery mechanisms aside from just watching the global fire-hose, so your initial experience is formed by the other users on your instance. And the experience varies wildly from "This instance is very quiet" to "This instance is full of furries".
The sign-up form during the first experience with the service is not the point to educate the newcomer about those issues, beyond maybe a friendly reminder of who is the one providing service to them at that point.
The sign-up process should be streamlined to make sure users arrive to a server that provides a good experience based on their interest; not on educating them about the technicalities of the service.
That sounds like a rather critical UX bug.
Just give me the instance I should sign up on in the "sign up" area of mastodon.social. Use what you think is the most suitable algorithm to cycle through a list of "appropriate" instances, where you-- the people with domain experience-- define "appropriate" for the potential user.
Otherwise you end up with this passive-aggressive situation where everybody does the obvious thing of signing up on mastodon.social, but your devs and fans take it on themselves to "teach" people not to do that because federation.
Case in point: the very first step of signing up is described as "very difficult" in this newbie guide.