Technology

37716 readers

444 users here now

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.

founded 2 years ago

MODERATORS

alyaza@beehaw.org

TheRtRevKaiser@beehaw.org

gyrfalcon@beehaw.org

rs5th@beehaw.org

SemioticStandard@beehaw.org

TheRtRevKaiser@kbin.social

Los@beehaw.org

coldredlight@beehaw.org

remington@beehaw.org

Hypothetical: What would happen if every user in the fediverse hosted their own server? (beehaw.org)

submitted 1 year ago by lucien@beehaw.org to c/technology@beehaw.org

22 comments fedilink hide all child comments

What would happen if instead of users swarming existing servers when a fediverse service was put in the spotlight, each user spun up their own micro-instance and tried to federate with existing servers?

There's always the odd person who decides to host a personal fediverse service in their homelab for themselves, but would the fediverse work if that was actually the primary mode of interaction? Or would it fail in a similar way to now where the servers which receive the most federation requests need to scale up?

Presumably the failure modes for federation are easier to scale than browser requests since it's an async process.

you are viewing a single comment's thread
view the rest of the comments

[–] pe1uca@lemmy.pe1uca.dev 0 points 1 year ago (2 children)

I'm running my personal instance, I haven't had any issue interacting.
AFAIK it would help spread the load since my instance just asks/receives the activity once from other instances and then aggregates everything locally.

So each time I access a post I need to ask: How many upvotes does it have? How many comments? Which ones are new? From those comments how many upvotes each one has? Which ones are replays to others? Also, get me pfp of each user.
I just changed the sorting, either main feed or comments in a post, well I need to ask in what order they should be displayed.

All of these queries are done only in my own instance with my instance's DB.

In this case beehaw.org just sends "Hey this post got an upvote", and my instance figures out how it would affect the rest of the posts in my feed.

Also, right now lemmy.ml is taking a toll with all the new users, it takes a while to refresh the page and get any update, but with my instance I can keep scrolling and reading the data my instance already got from lemmy.ml or any other instance.

[–] mrmanager@lemmy.today 1 points 1 year ago* (last edited 1 year ago)

I'm also running my own instance, very few users and everything is really fast. Because I'm not on the same instance as all those users.

I guess with time, people will understand what I'm talking about. There are no downsides to using an instance with a low amount of users when you have federated technology.

I would love to get more users actually, just to help spread the load and to provide a good experience.

[–] towerful@beehaw.org 1 points 1 year ago (1 children)

I think there is a tipping point somewhere.

I think the connection calc is n * (n - 1) / 2 (at least, that's what it is for mesh networks) so 1000 servers would be handling ~500k connections each.
That would be for 1000 users.
Those connections might be more lightweight, but there are significantly more of them (might even run into OS issues with that many open connections)

If each server was handling 50 users, the mesh connections would then be 1.2k.
50 users should be a blip wrt server load, and 1.2k mesh connections is more manageable.

[–] lucien@beehaw.org 1 points 1 year ago

At the same time, those graph connections don't need to be persistent network connections. You could easily cycle through connected nodes and batch update events without issue, and in that case, the primary constraint is bandwidth to the connected graph, not network connections.