this post was submitted on 29 Jul 2023
65 points (91.1% liked)

Selfhosted

39435 readers
8 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
65
Is it detrimental to the Fediverse network to self host, for only oneself, a Federated service? (lemmy.world)
submitted 1 year ago by [email protected] to c/[email protected]
27 comments fedilink hide all child comments
 

cross-posted from: https://lemmy.world/post/2357075

It seems that self hosting, for oneself, a federated service, like Lemmy, would only serve to increase the traffic in the network, and not actually serve the purpose of load balancing between servers.

As far as I understand it, the way federation is supposed to work is that the servers cache all the content locally to then serve to the people that are registered to that server. In doing so, the servers only have to transmit a minimal amount of data between themselves which lowers the overhead for small servers -- this then means that a small server doesn't get overwhelmed by a ton of people requesting from it. Now, if, instead, you have everyone self hosting their own server, you go right back to having everyone sending a ton of requests to small servers, thereby overwhelming them. It seems that it's really only beneficial to the network if you have, say, hundreds of medium sized servers instead of, say, thousands, of very small servers. While there is the resilience factor, the overhead of the network would be rather overwhelming.

Perhaps one possibility of fixing this is to use some form of load balancer like IPFS to distribute the requests more evenly, but I am no where even remotely close to being knowledgeable enough in that to say anything definitively.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 11 points 1 year ago (2 children)

I think it depends a lot on the federated service.

For mastodon, you follow individual users, so if there's a million users or ten million or a hundred million, their instances will only be contacting other intances they're federating with so it's quite scalable.

For Lemmy, you follow communities, so every server pulls all the posts and comments the common community. This means that for an instance like lemmy.world hosting lots of different big communities, every new server hammers the one central instance.

A strategy for improving the situation I think would be to spread the load. Instead of everyone piling into megacommunities, if people spread out into smaller more tight knit communities over many different instances. Of course, this isn't really compatible with the purpose of having communities like that.

It does seem to suggest that ActivityPub isn't necessarily the most appropriate protocol for this purpose, even though it's what was used because it's the de facto standard on the fediverse.

[–] [email protected] 11 points 1 year ago (1 children)

A big issue with Lemmy right now is how picture storage works. All photos are cached as they enter the instance and there isn’t much to do to turn it off. It’s ridiculous, especially for server scaling. The database in of itself is small, it’s really the pictures that are an issue and grow rapidly.

[–] [email protected] 6 points 1 year ago (2 children)

That's why it's stated in the Lemmy docs to use an image host instead of uploading directly. Unfortunately, most users don't do that.

[–] [email protected] 2 points 1 year ago (1 children)

You can also configure pict-rs to run on object storage so that all your users' images are stored on S3 rather than your local disk.

[–] [email protected] 2 points 1 year ago (1 children)

I was looking at that earlier and grabbing an S3 bucket or setting up MinIO does not appeal to me. I think I'm just burned out from IRL work.

[–] [email protected] 1 points 1 year ago (1 children)

Now if we had a federated image service that would be used by default to upload images, this would mitigate having the images on the lemmy servers :)

[–] [email protected] 1 points 1 year ago

and instead of the fediverse protocol, it could be more like i2p, everyone help caching images, even the apps could implement that

[–] [email protected] 5 points 1 year ago (1 children)

Right now federation traffics only have minimal impacts to Lemmy. They mostly consume network resource (to send out activitypub messages already waiting in the queue), unlike actual user traffics that consume a lot more CPU resources and database access.

When federation traffics finally become large enough to cause issues on popular instances, I think it should be easy enough for the devs to address (e.g. offloading activitypub subscription to relay servers). Actual user traffics are much harder to scale.

[–] [email protected] 3 points 1 year ago

Federation traffic killed most servers just about a month ago. The problem is not some type of traffic, the problem is that Lemmy software is very bad.