I think I miss something, the ActivityPub protocol is not owned or maintained by Mastodon devs. Isn't this just standard communication like an extension of HTTP? something like GraphQL (that created by Facebook itself). Quick google mentioned that ActivityPub is maintained by W3C.
So Meta can (and I think currently uses) ActivityPub, and all of your points already been possible without needing to federates with any other instances. For example, they already can say that ActivityPub doesn't work on some cases, and push W3C to do some changes on the standard
Let's say all of mastodon instances not federating Threads. What stopping Meta to do EEE on ActivityPub? That protocol is not owned by mastodon creator or other devs. It's handled by W3C afaik
Why not? I don't see the drawback to develop ability to do horizontal scaling. If the instance owner doesn't want to add additional servers, it's up to them. Obviously they paid for it if they decide to add.
Just to be clear, horizontal scaling means multiple servers handling same instance, it can be the backend service to allow handling more traffics, or multiple db to reduce database loads.
Additionally it allows high availabilities, so if one of the backend service is down (either unexpectedly or do rolling update) the other service can still active so the instance can still be accessed by users
I think I miss something, the ActivityPub protocol is not owned or maintained by Mastodon devs. Isn't this just standard communication like an extension of HTTP? something like GraphQL (that created by Facebook itself). Quick google mentioned that ActivityPub is maintained by W3C.
So Meta can (and I think currently uses) ActivityPub, and all of your points already been possible without needing to federates with any other instances. For example, they already can say that ActivityPub doesn't work on some cases, and push W3C to do some changes on the standard