It's so exciting to see #mastodon community and the #fediverse absolutely shine these past days—it is genuinely liberating.
I've taken front seat on the struggles of mastodon.social (and its unstoppable force @Gargron). It's a natural thing, and, don't take me wrong, it's something of a beauty to witness—the organic growth of a decentralized and federated social medium. (The hiccups didn't bothered me at all, instead filled me with excitement. I think they are signs of great things to come.)
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?
But, if I may add a few lines on #FlatFederation, I also feel that sometimes Mastodon might be (still) too server-centric at times.
Sometimes it almost feel we've embraced #federation but not fully (perhaps because we've been living in a server-client world for too long and only now trends like Web3, whatever that means, are becoming more mainstream/common).
An example of this is I still today find it weird that I cannot assemble a curated network of preferred servers public timelines, or, at least, filter the federated timeline, without having to resort to setting up my own #mastodon server to be able to fine tune that.
But then again, the way #mastodon #ux is set up, it still feels a bit weird having a #SingleTenant server. I feel it still brings a lot of server-centric baggage. (Curious to know more about diaspora pod model.)
As a closing point, I can see a point where the protocol evolves to seamlessly include #UX wise #SingleTenant instances without bringing all the server-centric baggage, thus promoting an inclusive leveled playing field for all sorts of federation scaling strategies: #VerticalFederation, #HorizontalFederation and #FlatFederation. (And as a plus, improve #mastodon #onboarding #friction issue too.)
As for I, intend to engage in that discussion and contribute to this extraordinary #foss project.
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.
Yeah. My current personal dilemma is: Loving mastodon.social, but my curiosity about the experience of a more interest-based instance is there. It would be nice to be able to try one out, without losing stuff.
Even with the current export/import setup, it seems one can't migrate posts, and that's a downer, tbh.
Pedro Machado Santa
Mi Go (teno)
Daniel Schildt