Those of us on it during the early days were well acquainted with the Fail Wail.
But, with a lot of engineering work - and constant upkeep - it began to handle the load. Let it be so with Mastodon.
Nearly every point the author makes is subjective. That's fine, of course. But it doesn't help demonstrate that users do (or don't) want centralization.
Personally, I'd rather be moderated by my local community than by a faceless American company trying to appeal to advertisers. And if I don't like their stance I can go elsewhere.
The scaling requirements are also unevenly distributed. Servers hosting celebrities are going to have very different load vs servers hosting 99% of people who are mostly interacting with friends/family/interest groups. The overall resource footprint with Mastodon will surely be much bigger than a fully centralized service like Twitter that can continuously identify and engineer out inefficiencies across their whole user base, not sure this is a high ranking consideration though.
It's also not hard to solve. I've run large scale mail distribution systems, and I've run a webmail platform and been on the receiving end of large mailing list blasts.
The solution in both cases is just basic divide and conquer. Mastodon the software may not be able to scale effortlessly to the largest accounts, but that's a market opportunity. ActivityPub certainly can accommodate it.
If inbound volume is a problem, shard inbound activities, and zipper merge on lookup, likely maintaining a cache of the most recent n amount of entries, given this would mostly apply to things like the Federated feed for a large instance where "nobody" looks far back.
If outbound volume from a single account is a problem, you similarly just split the follower list into buckets and hand off delivery to a distributed set of workers for delivery; this scales just fine with the caveat that you depend on the receiving instances being able to handle the deluge. But ActivityPub allows for batched deliveries to shared inboxes [1] you can post to, to reduce the deliveries to one message per shared inbox (which would typically best case be one per instance; e.g. the "sharedInbox" property for my mastodon account is "https://mastodon.social/inbox). Assuming all current instances has a sharedinbox property (which is likely given most of them are Mastodon, and Mastodon does), currently delivering to all the ~6m Mastodon accounts requires delivering to ~1550 shared inboxes; delivering directly to 6m wouldn't have been a problem, but it's not necessary.
If handling the outbound volume from a single account arriving at your instance for delivery to a large proportion of your users is a problem, ActivityPub already has a built in solution: To find out where to deliver, you need to use WebFinger to obtain the profile urls, and get the profile urls to find the endpoints to talk to, including the inbox, which means foo@mastodon.social and bar@mastodon.social can have inboxes on different servers without even needing to do any more advanced sharding. But of course you can do the latter too and have the same inbox url mapped by your load balancer to any of a number of internal shards.
This is all stuff we had to solve literally decades ago for e-mail.
Those of us on it during the early days were well acquainted with the Fail Wail.
But, with a lot of engineering work - and constant upkeep - it began to handle the load. Let it be so with Mastodon.
Nearly every point the author makes is subjective. That's fine, of course. But it doesn't help demonstrate that users do (or don't) want centralization.
Personally, I'd rather be moderated by my local community than by a faceless American company trying to appeal to advertisers. And if I don't like their stance I can go elsewhere.