[\#lemmy](https://mas.to/tags/lemmy)/#kbin has a problem that [#mastodon](https://mas.to/tags/mastodon) hasn't even attempted to solve; groups and what happens when they get popular.
🍄🌈🎮💻🚲🥓🎃💀🏴🛻🇺🇸@mas.to to 
#lemmy/#kbin has a problem that #mastodon hasn't even attempted to solve; groups and what happens when they get popular.
#Communities, #groups, #magazines, whatever they are called are implemented as #Actors in #ActivityPub. They are basically just *very* popular users who boost a *lot*.
You can't just distribute them across instances the way normal actors do. Whichever server hosts @technology@lemmy.ml or @technology@beehaw.org is going to get HOSED on the regular.
You are viewing a single comment
While it's true that the hosts of popular communities will get more traffic, it's actually not as bad as it first seems.
Every Lemmy instance with at least one subscriber in that popular community will act as a mirror. That means that users who are just reading posts and comments will not cause any additional load on the home-instance of the popular community, because they are consuming local copies of the posts and comments.
This will actually help scaling a lot, and is in fact exactly how many centralized platforms scale (by creating a bunch of read-only copies of content).
As long as we can distribute the Lemmy userbase between different instances (and avoid creating one or two centralized super-instances), we can take a lot of advantage of this mirroring and the scaling will be quite good!
@sunaurus what about when those users like/boost/reply?
In those cases, the action will need to propagate back to the home server (that's where the "hosts of popular communities will get more traffic" comes from), but keep in mind - people usually read at least one or two orders of magnitude more than they write.
@sunaurus there's a lot of upvoting happening on popular subreddits
Absolutely, but a user will only upvote a post once, while they will read it on every reload of their page.
Hmm, you could probably extend the protocol to do eventual consistency across instances if that ever becomes a problem, remote instances could keep their own counts and only send aggregated updates.