Also this post from GitHub explaining why this entire premise is wrong:

Great presentation and write up - but this is just not how any of this works. The whole thing is based on a premise that just isn’t true.

Reposting my reply from lemmy:

The way federation actually works:

A user on lemmy.ml subscribes to a community on lemmy.world. Say, [email protected]

Assume that this user is the first lemmy.ml user to do so - basically what happens is the lemmy.world community sees that a member of a never before seen instance just subscribed. [email protected] then adds lemmy.ml to its list of instances it needs to tell whenever something happens in the community.

No matter how many users of lemmy.ml subscribe, this only happens once.

Now when a user of sh.itjust.works upvotes a post on [email protected], the sh.itjust.works instance then tells [email protected] of this change. It accepts the change, then tells everyone on its list of instances that have subscribers on them.

So essentially, sh.itjust.works talks to lemmy.world, lemmy.world tells everyone else. There is no “full mesh”. The instance hosting the community is the “hub”, everything else is a spoke.

So if there’s 10,000 instances, and they all just so happen to have at least one subscriber to some community, each change will be sent out 9,999 times. Your “50 million” premise is just completely wrong and I’m not sure where it’s coming from.

Is your logic faulty?

Yes, there are 50M total connections between 10k nodes, but when one server sees one comment/updootmwhatever, then that server “only” needs to send it to the 10k peers.

Those peers do not need to pass it on to all other peers; that would mean 50M messages total, but again, not from each peer.

It might be useful to make reference in your proposal to other federated services that have adopted similar models, as well as ones that have not.

SMTP email, for example, does not have a hub/spoke model for servers. Any SMTP mail server can connect to any MX (mail exchanger) to deliver messages to recipients in that MX’s domain. SMTP is capable of batching messages, though: if foo.com has several messages to send to bar.edu, it can send them all in a single session.

(An SMTP MX only accepts messages for its own users, though: operating an “open mail relay” is a good way to get your server added to spam blocklists.)

NNTP (Usenet News) has servers explicitly configured to peer with other servers. Back when Usenet was more of a thing, there were large “backbone” servers that had a lot of power over the network as a whole. (Look up “backbone cabal”.) So it kinda has a hub/spoke model that arises from the peering agreements between servers.

IRC also has explicit peering relationships among servers. IRC operators had a controversy about open federation early in its history. On the original IRC network, the host eris.berkeley.edu allowed open federation, which became an abuse problem — leading to the formation of EFNet, the “eris-free network”.

I would say no to this immediately In its current form. Because those big expensive hub servers are going to become gatekeeping tech companies like Facebook and Reddit (well not specifically them most likely, but someone like them). You’re handing the keys to our new castle straight back to the corporate overlords.

Perhaps something can be done using message routing similar to this that is separate from federation; or maybe it’s up to large instances to host CDNs.

What is being proposed here is turning the fediverse into a Reddit CDN, and I’m not on board for that.

Implement it. Be that guy

A really important concern, we will need to adress, but i’m not sure if the proposed hub-servers really are the solution, they kind of kill many benefits of the decentralized architecture of federation, but definitely a good idea

A valid concern for sure. An issue we needed to overcome when the internet was still young and an issue that will absolutely affect Lemmy as it continues to grow.