Where does the complexity from Mastodon and other Fediverse social platforms come from?
The fact that there are instances? Mastodon seems to streamline that experience pretty well.
Honestly, curious for feedback
1) Following another user because you liked one post: when that user isn't on your instance, you usually have to do a three-step dance: click on the user to get to their timeline (on another instance), click "follow," and now enter your username into a dialog box because you're on another server. That last step is weird and off-putting. It's also completely necessary, because different servers don't have a cross-domain trust to pass your username around so (we know as web devs) you must tell the other server who you are; the architecture is protecting your anonymity by design by not divulging that data. But, relative to Twitter, that's weird. I don't think it is fixable without a change to the domain-based trust model. And, of course, this is yet another example of how people say they want privacy and anonymity online, but when you implement it for them they get frustrated at the usability tradeoffs those concerns demand.
2) A defederation split between your node and another node means you could lose access to people you follow. There is an analogy in the Twitterverse... Someone you follow could get banned. But that's different than someone you follow going away because their "neighbor" was being a Nazi and your server admin axed the whole node in response. Twitter users don't have "neighbors." Everyone's a neighbor. Entirely new mental model moving to the Fediverse. This is, again, a feature... But it's a feature some people find extremely valuable and others find off-putting complexity.
(Sidebar: I actually got into running my own node for this reason: I realized a good friend of mine wasn't followable from my first account because years ago my server admin had decided on a "no furries" rule and my friend's server happened to be furry-content friendly. Twitter doesn't make you build a red-string-map of historical drama to figure out what node to join).
3) Smaller nodes change the risk model. There are tradeoffs to decentralization: if your node goes dead, the whole network hasn't gone dead. But if your node goes dead, that's hugely inconvenient... And with no money on the table and individual communities being smaller, nodes go dead more often than Twitter goes dead (the fact that Twitter is still there in spite of everything that's happened to it is a strong example of the stickiness of a corporate-backed venture with a war chest). Of the three, this is the least-concerning one... If you sign up for an account at mastodon.social, you'll probably be fine. But in general, the system working as intended asks the user to trade out the security of a large, capital-backed network for the responsibility of being aware of the ambient health of their own digital neighborhood. It's nothing more complex than the ancient BBS model, but that's the thing... A whole generation or two of computer users never used a BBS. They aren't used to having to find something else to do with their browsing habits because Frank is having a bad year and decided to shut down his server for his own mental health.
It is worth noting, of course, that (2) and (3) aren't issues if you self-host. But I don't even think I need to put down a bullet point on why "You need to administer your own Ruby on Rails, Sidekiq, postgresql, and (fourth server I can't even remember right now) service behind its own public domain name" would be a non-starter for people.
2) Choose your 'neighborhood' wisely. Some of these smaller to mid sized mastodon instances, especially those who espouse strong free speech doctrines might get you banned from federating with some other instance because of the actions of one of your neighbors when the 'HOA' (your neighborhood admin) refuses to do anything about them.
3) This goes with #2, choose your neighborhood wisely.
As you discuss in your postscript I am one of those who chose to run my own 'neighborhood', just for myself at this point but I could see opening the door to a couple of close friends. I've been running my own mail/web/etc services for many years now. I will say that the main mastodon software kinda sucks for this, it's built to scale somewhat and therefore sidekiq and redis and all the rest, and that kinda sucks. They have some docker options that make it a little less of a pain but I would love to see a more streamlined version or a fully api compatible piece of software that is cleaner to run (maybe compiled into binaries so i don't have to deal with ruby)...
Neither Twitter nor Facebook require you to choose a 'neighborhood.' It's all one tent. Having to build a red-string map of relationships to pick one is a real chore and a turn-off for potential users. Chop another N% off the projections.
That having been said... It's entirely possible that all of that is fine! We don't need every user on the planet; this isn't a VC-driven startup idea, we don't need unlimited growth to make a stock market and some money-suits happy. And the things 1, 2, and 3 give users have value (privacy and anonymity, the ability to choose who you trust with your private information while still using the service, and not being obligated to rub elbows with Nazis because either daddy Musk or papa Zuckerberg have either not noticed they're Nazis or they've chosen not to care, because, hey, Nazis are part of that X% of total possible users too).
Of all of them, (1) is the only one where I feel some change to the infrastructure of the web might be worth discussing. It would have to be done very carefully to preserve user privacy and anonymity, but I think a case can be made that the current domain-centric security model actually makes for soft incentive to centralize services (fewer auth bridges to build), which may not actually be a categorical good for the overall health and future of the web as a technology.
Maybe we should expand the client-side trust model to allow for trusting a federation (in a way better than the [related website sets](https://developer.chrome.com/docs/privacy-sandbox/related-we...) proposal, which in fact hyper-centralizes the understanding of trust behind the browser's control and is basically a way for the FAANG sites to link together their user experience across YouTube, Google, Blogger, et. al. without a lot of complicated server-side state passing).