RE: https://mastodon.online/@mastodonmigration/116122817979484928
Oh boy, here we go again. The claims in this thread have been debunked a *lot*.
Yes, if you want to run a full-network appview as Bluesky scale, then that means you're run a social platform for 42 million users, processing billions of events.
HOWEVER, there are smart was to scale down what the Bluesky AppView does, to smaller scales which make sense for your community.
A fantastic example of this is RedDwarf, which skips all the relays, and interacts directly with PDSes. That does come with some trade-offs, but shows that you can do things at a different scale with different trade-offs.
All ActivityPub servers *can* rely on expensive network resources: hosting an entire copy of the Mastodon networks' data for a large instance is complicated, as is storage a copy of (in a cache) of all the posts and media attachments. (for instance, mstdn.ca said today that their database is 450GB, and they're the 53 most active server on the network).
It's been a long pain point that operating Mastodon requires storing a copy of all remote media attachments, which has lead to proposals for shared media infrastructure. Having to provide CDN infrastructure for all that media is also really expensive.
Scaling compute to handle sudden influxes of activity, especially in mastodon, often means significantly over provisioning infrastructure. It's not super easy to auto-scale sidekiq workers (possible, but requires engineering).
Depending on who's on your server, you can also have some truly horrifically expensive write paths: one post published by Mastodon Migration *could* result in up to 34,000 outbound HTTP requests. Sure we have sharedInbox that can get that number down to unique shared inboxes across all a users' followers. This is even called out in the spec: https://www.w3.org/TR/activitypub/#shared-inbox-delivery
So does Mastodon scale up? If Bluesky doesn't scale down, we can certainly ask the same questions of Mastodon in the inverse direction.
I don't know about Mastodon Migration, but I've been on the infrastructure team for a large mastodon server (Hachyderm), and the amount of stuff we needed to do to ensure up time and low response times, and quick processing of inbound activities was a *lot*.