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.

(Also- as federation has been completely broken on this particular server for me- there is a good chance I will not be able to see, or reply to anything posted below… That is, also assuming this even posts correctly to this server.)

  • fubo@lemmy.world
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    1 year ago

    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”.