mastodon) hasn't even attempted to solve; groups and what happens when they get popular.

Technology@beehaw.org – 42 points – 1 years ago

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

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.

@schizanon @technology@lemmy.ml @technology@beehaw.org Yep. I expect that long-term a lot of instances will limit the ability to create groups (as Beehaw does) or place restrictions on the size a group is allowed to grow before asking that group to move to another/their own instance or ask for finances to help with the costs.

Did you post this from Mastodon? I wish I could tell where this came from.

Basically if I understand this right, if you have an instance with a very popular community on it. It is likely that it will need some massive infrastructure scaling if it wants to handle the enormous amount of world wide traffic?

Yes. If you run the server, then you are the source of truth of that community. All other servers that federate your community query your server to access the community and show it to their users.

So if you run a server and a community explodes there, you might only have 500 users on your instance, but you might have 50k users reading that community and interacting with it from other Lemmy instances, thus your server needs to scale to 50k users worth.

And ever more essential, your server is the source of truth of that community. So if your server is hacked or corrupted or deleted, that community is gone. Other instances don't mirror it (except for temporary caching), so the Lemmy network essentially is a trust network of other people maintaining servers long term (and each inventing a monetary system to pay for it). I still think the network might be better than a centralized system like reddit, but it definitely has a lot of growing and policies that need to be sorted out very soon

So are these other servers just routing requests from their users to your server's community? Or are they actually copying everything over every so often (caching) and serving up the requests themselves? How real time is it, I guess is what I'm asking?

Yeah, apparently I was wrong about this (still learning lemmy and fediverse stuff...). Text content of posts and comments are "synced" to your server and stored in your database there. Then future requests for that content are served from your instance. So its not as bad as I thought it was (the network load should be lower since you aren't acting as entirely a proxy, more like a cache), but database bloat will be a huge problem (its already a big problem in other federated things like mastodon and matrix, where every server ends up saving everything they want into their own database).

I'm not sure what happens when the original server goes down, does the federated servers discard that data? Or do we each maintain a forever copy until we want to get rid of it ourselves? There's also some notes I've seen about how servers only incrementally cache federated content (only posts and comments that are viewed by someone are fetched, and new comments may not be fetched until someone wants to see it)... so not everybody has a "pure and full" copy of posts necessarily.

But overall I wonder how all the various sysadmins hosting these lemmy instances will deal with the expotential growth they're going to see, or if smaller instances will start defederating to save on hardware costs (no reason for my tiny instance that only talks about blue shiny rocks to federate with lemmy.world and store all that content)

Information about post changes on the originating instance come in pretty much in real time, and get saved in the local database.

If the local instance is configured with pictrs support images are also cached locally.

Why do these communities need long-term persistence? You could use a separate archive based on plain web server mirrors for anything worth preserving. Maybe it's good that communities disappear and coalesce elsewhere, maybe it's evolution. Maybe being forced to pick and choose what to archive and what to let go is a good thing.

AP is a very chatty protocol and to handle large world-scale groups requires additions like compressed digest distribution, mirrors and sharding. Threads are already fragmented by design so in the end it may be unworkable to follow large group threads.

I wish I could tell where this came from.

Isn't that what this colourful icon in Lemmy is for? It appears to link to the original source of the post or comment:

@Nymphioxetine posted from mastodon (because Lemmy is slow right now😊)

it may be worth putting a bug request on the activitypub github, because I agree that could become a huge problem, but its also alot of work to implement because most instances will need to update to the newest activitypub standard once they approve a new version of the standard.

Definitely a problem that needs solved sooner rather than later, but I assume with a lot more eyes on ActivityPub now, people much smarter than I will have a solution.

What does hosed mean, technically?

Lots of traffic, lots of posts, lots of comments, ... That's going to need more storage, more bandwidth, more CPU power, higher running costs. The original instance hosting the community bears a higher load than the instances that duplicate it.

Ideally, there would be a way to more evenly distribute this load across instances according to their resources, but from my (currently limited) knowledge, I don't think Lemmy/ActivityPub is really geared for that kind of distributed computing, and currently I don't believe that there's a way to move subs between instances to offload them (although I believe some people may be working on that).

Perhaps the Lemmy back-end could use a distributed architecture for serving requests and storage, such that anyone could run a backend server to donate resources without necessarily hosting an instance.

For example, I currently have access to a fairly powerful spare server. I'm reluctant to host a Lemmy instance on it as I can't guarantee its availability in the long term (so any communities/user accounts would be lost when it goes down), but while it's available I'd happily donate CPU/storage/bandwidth to a Lemmy cloud, if such a thing existed.

There are pros and cons to this approach, but it might be worth considering as Lemmy grows in popularity.

I don’t think it’s a problem. If you weren’t using activity pub and just something like reddit then if you were reddit (the sysadmin) you’d also deal with having to scale if your community gets really popular

Stuff that gets linked to also has the same problem

https://www.jwz.org/blog/2022/11/mastodon-stampede/

(Btw I don’t like jwz but he mentions it here)

Funny how you say it's not a problem, then go on to describe the problem that needs to be dealt with. Dealing with scaling is a problem, and it's a problem that costs money.

Posts like this: https://lemm.ee/post/58472 suggest it is a problem. The rise in traffic seen by Lemmy in the last few days is absolutely tiny compared to a site like reddit, and already instances are struggling to cope. The recent growth in user registrations represents only about 0.007% of reddit's active user base. (~60K new Lemmy users vs 861,000,000 active monthly reddit users). A site like reddit costs millions to run.

There are 190+ Lemmy instances last time I checked, yet almost all the brunt of this load has been borne by a handful of servers, which see an inordinate amount of traffic while 100+ other servers sit around idle. Why should a handful of "lucky" servers have to pay all the hosting costs? What if a volunteer-run instance explodes to reddit-like levels of popularity? It will simply fold, unless the volunteer has serious money to throw at the problem.

I think they meant like "overloaded", like a hose spraying water, but the water being users from all around the fediverse

I’d love to see feedback from admins on the scaling problems they are having. Hopefully that scales per server and not per user per server.

So there is no way to horizontally scale?

The network can actually scale quite well thanks to the fact that other instances will act as mirrors of communities!

But what happens when the instance hosting the community goes down? Are all external instances still able to participate in that community? I get that they are mirrored but will everyone still be connected?

No. The "single source of truth" is the instance hosting the community. If it goes down the community itself goes down with the ship. The only way to prevent it is to have a IT infrastructure that can provide redundancy

Yeah, that isn't good.

having a redundant system is feasible (I'm just a dev, not an architect so don't take my words for granted) but it have to be designed and putted together ... and prices are gonna skyrocket

Lemmy / the fediverse isn't designed this way, but it could be. There are certainly systems that share diskspace and are multimaster and keep stuff as long as someone is interested in it(i.e. accessing the data). I really start to think added to the lemmy / fediverse servers should be something like what freenet used to do in terms of hosting content.

If it's just a temporary outage, whatever the mirror has received prior to the outage will be shown to users on that other instance but only local interactions for that instance will update it, when it comes back up, things like votes and comments will be synchronized again across all of the instances.

For permanent outages, the community will just need to be started again on a new instance.

But they could pick up where the now defunct community left off, right? Like, the cached copy from another server could be imported on a new server elsewhere?

That functionality doesn't currently exist, but migration of communities is something that's being actively talked about for development.

Reading this and trying to visualize the big picture, I think this is where kbin's magazine is going to win out in the end

Out of curiosity, how is kbin's magazine system designed to avoid this problem?

Ok, from what I understand now, a magazine can follow tags or keywords, which will populate the magazine. So no matter where in the fediverse something is posted, it will show up in the magazine.

But then if the instance hosting the magazine goes down YEAH OK I GET IT NOW

From what I understand... wait I understand nothing

It’s not