Earlier quoted context omitted.
Just as I've tried to do with my email for a long time now, I decided to have my own Mastodon instance on a domain I control. 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 relations…
Broadly speaking, is Mastodon a healthy, non-addictive, non-abusive Twitter alternative that happens to leverage federation to achieve its aims? Or is Mastodon a FLOSS celebration of federation applied to the domain of social networking? 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 sma…
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.