I've also followed with curiosity the talk (mostly) lead by @aral on #smallWeb #federation #decentralization #centralization #singleTenant and how better scale the #fediverse (technological, but also community-wise and signal/conversation-wise), picking up on the recent mastodon.social struggles.

I have the belief that #mastodon , from an #onboarding perspective, will require a core set of popular (generalist) servers. But, I may be wrong. There are a few generic routes I think it can go IMO.

To tackle this I see three generic scaling strategies emerging from the discussion:

#VerticalFederation akin to @Gargron/mastodon.social, scaling 'up' the most popular servers to keep up with demand.

#HorizontalFederation advocating a more fragmented/decentralized ecosystem with servers breaking up into smaller instances, and solutions like account count limits.

#FlatFederation advocating mostly for a greater #SingleTenant approach, where everyone should set up their own mastodon server.

From an #onboarding friction perspective—and as you've seen with all the new #TwitterMigration users coming from mainstream social media and scrambling to grasp the server concept, lost and looking for the usual 'damned' #Mastodon sign-up form—the #VerticalFederation seems to work well:

A mastodon.social could act as a prime server where those people first land, an intermediate step per se, before considering venturing further into the #fediverse and #decentralization.

But I believe, with the appropriate #UI #UX tweaks on the #Mastodon onboarding experience, the same role could easily be accomplished with a core group of (generalist) servers acting up as those #PrimeServers (accompanied by open registration/saturation info for each server) which would, in its case, support a good #decentralization level to maintain a good network and platform health.

With the appropriate #UX in place, #HorizontalFederation also seems a viable solution for #fediverse growth.

Another aspect of this (which comes up often to me) is, what kind of scaling strategy would fit better considering the #Mastodon system *and* protocol architecture?

Would from a network perspective (and overall) be less expensive (computationally) to apply #VerticalFederation to servers?

Or would it be better/would ease the load if we decentralize into smaller instances through #HorizontalFederation and pay the network #federation overhead price?

@Gargron any thoughts on this?

@pedrosanta @Gargron

Curious to hear your thoughts.

https://mastodon.social/@tenorune/109281217215671752

I'm just getting my feet wet, and need to look deeper at the architectural hurdles, when I'm less busy, next month

It seems a big hurdle to this proposal is the lack of true portability of user data; a set of "onramp instances" would imply it's easy to later transfer an account to a new instance. Currently, it seems, that's not really possible.

@tenorune @Gargron I believe portability is more or less worked out (not perfect, but I feel the basics are in place, check https://blog.joinmastodon.org/2019/06/how-to-migrate-from-one-server-to-another). It can certainly improve, but I don't see a huge hindrance in there at this point.

I agree with your proposal, it's the same as the #PrimeServers I mentioned before. It's all about the #UX I feel. (Will lend a hand if I can on this, also.)

@pedrosanta @Gargron Nice, thank you, I'll have a look.

Certainly thinking about a long-term UX evolution of this that would automate all that, for much less technically-minded people. It's still too complicated.

@tenorune @Gargron Yes, you got a point in there. I've tried somewhat unsuccessfully to explain this and share this blog article with people less technically-savvy and a few times simply ended up with two accounts. 🤷

But, again, I feel we're still in the infancy of federative mediums, so... lot of road to walk here.