- cross-posted to:
- lemmy
- cross-posted to:
- lemmy
https://github.com/LemmyNet/lemmy/issues/3245
I posted far more details on the issue then I am putting here-
But, just to bring some math in- with the current full-mesh federation model, assuming 10,000 instances-
That will require nearly 50 million connections.
Each comment. Each vote. Each post, will have to be sent 50 million seperate times.
In the purposed hub-spoke model, We can reduce that by over 99%, so that each post/vote/comment/etc, only has to be sent 10,000 times (plus n*(n-1)/2 times, where n = number of hub servers).
The current full mesh architecture will not scale. I predict, exponential growth will continue to occur.
Let’s work on a solution to this problem together.
In your proposal, who would run these hub servers?
Theoretically, anyone could run a hub server.
A hub server, would work just like an instance does in the current state, and to keep things decentralized, I would recommend it stay that way.
However, I do believe some controls would be needed to prevent EVERYONE from creating their own hub server, leading to the current issue of instantly large federation loads.
Perhaps, just a simple check to prevent a hub from running with less than adequate resources. Or, perhaps, we as a community, can collectively decide who/where/what the hub servers are.
I don’t have all of the answers to my question/proposal- I just know the full mesh topology is NOT going to scale, and we do need to work together to find a better solution to this problem.
What if each instance had a message broker distribute updates in a pub/sub topics oriented fashion? Does the activitypub spec specify that instance X must http post updates to instance Y or is there room for implementations to get creative?
For my initial idea, my proposal is to allow servers to have the option to choose to go through a hub, or to function as-is.
That would help the current implementation pretty drastically- although, I am not 100% sure how it is done currently.