@crossgolf_rebel Let's be real.The fediverse is essentially Mastodon with a lot of minority contributions from about 200 - 400 other software companies at the moment. With the majority of these existing from Lemmy, Pleroma, PeerTube, Pixelft and countless more.Current max potential estimates give us a general ballpark of users ranging across all instances between 10 - 20M in total. Most automatic statistics will say the number is more conservative at 10M or slightly above this.Compare that to a centralized platform and the statistical risk of being absolutely discovered by say, 200M people, potentially, drops significantly.Now obviously this doesn't take into account Threads massive user base. Or BlueSky's entire federated list of people. I know for a fact that people on these platforms do tend to peak into the fediverse, and that's statistically true for literally anyone with a search engine and some time on their hands.But, honestly, your at most naturallly federated by say 20 - 50 relays even at max user base, that doesn't go deeper, will likely only see a fraction of these users at any one time let alone their posts, and search results. Honestly, it's quite small, when taking into consideration that the fediverse as a whole in practice, is still a young platform, and contains a very limited scope of data at the moment to work with. But it is what it is.Case in point, my own instance that does federate with 60+ relays, only brought in 100K users and about 2M potential posts maximum, that gets further broken down into partial replies, conversations and so on as time goes on. And, search results tend to decrease the older a post is, if newer time based data becomes available. So, no matter what you're working with, it's a data island.But, and this is the big caveat here. It's one with a public, indexable in traditional search engine, database that honestly doesn't get a lot of queries connected to it anyways, because the posts aren't long articles...but if you do site:instance_domain you'll figure out that users who opt in to wanting that and server admins who let that happen, can go public if they wish.Now, we're getting into why I made that huge list of descripters for Mastodon, specifically. Bare with me.Not Mastodon specifically, but Mastodon inclusively, has the widest client support for interacting with any instance of all the fediverse related apps. This is true both at the user level, and the administration level for compatibility with various server admin portals like Yunohost and other cloud deployments, to barebones do it yourself tutorials from scratch. So if you're not someone who needs a mobile app to do anything, chances are fairly decent that if you interact with a part of the fediverse that doesn't obtain one using another protocol, potentially or different API structure, your ability to interact with anyone else is statistically about the same if not lower than someone operating a Drupal, Joomla! or other site with a CMS attached.Now, why is Mastodon safer? Because of the popularity of its user base making the most developmental sense by how many sites actively stilll use it and rely on one git hub main branch for updates, if individual server instances care to use it. Then there's app specific level updates, which are almost very active by comparison, because again, the demand for familiarity is there. Even across all of the compatible forks, this is true. It also takes up 3 quarters of the fediverse that isn't threads. And you need to interact with FB infrastructure via Instagram just to use that which makes Instagram more or less a cloud implementation, and I don't consider it to be the same thing entirely. The same is true for Blue Sky. If those instances went down, their user base follows. And you can't import or export your X or TruthSocial account into new instances of that kind of software, the way you can Mastodon. Although I may be mistaken on that as bridge services exist out there to attempt data export customizations. Not the point.My point, is that users own their data. Because Mastodon at its minimal core, requires this to be true. So, if you feel uncomfortable about a particular instance and want to go somewhere else with it, your data isn't trapped on a server which encourages but never mandates that you must leave. And, you're always in control of why you stay somewhere, as opposed to why you have to make somewhere home because you're not always able to switch as easily if the platform locks you into it where you've put more investment into making it work, than effort trying not to.So with the decreased risk of a safety violation when you still own your data, your email address for instance exploited by some hacker targeting a specific mastodon instance theoretically for the purposes of data harvesting there, won't be the same email address if you move instances and keep your follower count the same to another instance anywhere else. You don't have to start from 0 to continue where you left off, if you felt like you were at risk of whatever the descripter is. Ads, spyware, scams, spam, bad server mods, shadow banning, algorithms, etc.And the best part, is that the client you use to reconnect to your new online home, remains the same. You can't do that with email as easily. You certainly can't do that unless you own your own WordPress instance very easily, especially if you lose your domain and now people have to rediscover you all over again.That's why Mastodon gets special attention here. Anything that can interact with Mastodon posts on its own, or even with specialized help through a bridge, by extension, also counts here if those bridges follow trustworthy industry practices. Even if they don't, you as a user, are in full control over what you allow a server to set as a default, and what you set as yours on top of that. So even though it's a data island, it's yours the best it can be if you need it to act as one.NOSTR, BlueSky, Matrix and other implementations of protocols have their own issues. Matrix in particular is bottlenecked by its own clients, that can't agree on what interface to use. I don't find them user friendly at all. And they're not part of the publicly available fediverse pipeline, if you didn't want them to be. The only thing they have in common with it, is their implementation of a separate protocol. Other than that, it's not the same and has more faults in its implementation for my personal taste. And so, honestly, having options is the key. But not ones so overwhelming to you, that don't make sense for the user base that takes full advantage of them at a client only level. But at a protocol level, and at a software expectation level with enough popularity to justify it, absolutely.
