this post was submitted on 21 Jul 2023
51 points (96.4% liked)

Selfhosted

40006 readers
946 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
 

Basically, I have read several statements addressing this topic. For example:

"If my server gets too big I will just close registrations"

"Server X got too big, so they closed registrations to manage the load"

While I do understand that this can help for small servers which don't have a big number of external users. How does this help with big and popular servers? Don't they have to serve requests from external users using their resources? For example, I might self host a server just for my account but I read all my content from lemmy.world. Am I not using their bandwidth and their resources anyway?

Bonus question: Does federating with other servers increase the resource usage of my server? What kind of metadata/data do I have to store from each server I federate with?

Thanks!

you are viewing a single comment's thread
view the rest of the comments
[–] Max_P@lemmy.max-p.me 3 points 1 year ago* (last edited 1 year ago)

It's eternal yes, unless the admin manually purges it.

I also said cache for the sake of simplicity, it's technically not a cache. Every instance gets activity pushed to them pretty much in realtime, and stores a copy of everything. Posts, comments, votes, even moderation actions. So it's more like a massively distributed multi-primary eventually-maybe-consistent database than a cache.

Apart from the initial preview that fetches the last 20 posts and no comments, everything is populated purely through ActivityPub messages being pushed to every subscribed instance, in mostly realtime.

So user 1&2 never request A to go get a post from B. They simply request a post that's already on A that's a copy that's been pushed by B and may have been published by C. B is only involved if a user from A comments on the post, then A will push that comment to B which will then push it to C and D and others.

So 10,000 users viewing a post on A is entirely handled by A, and 20,000 users on C viewing the same post is entirely handled by C. B could have zero users and it would still work perfectly. Similarly, A could have zero communities and rely entirely on B to manage the communities. B would have very little work to do despite having a total of 30,000 users viewing its posts. In fact, B could even go down and A and C would still serve the post and even take comments and votes, they just will be synchronized back when B comes back up and A&C would temporarily have a slightly different view of the same post.

So the more instances, the more distributed everything is. And that's why instances that becomes too large can simply shut down registrations or even kick its users out. It could become B in this example.