43
Lemmy Federation Architecture Change Proposal
(github.com)
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Subcommunities on Beehaw:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
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.