This is a shame. Hosting a high visibility server is no joke, and I don’t envy the admins and the very difficult work they do.
It’s simultaneously an argument for and against decentralization.
For - a single instance can get knocked out without talking out the whole fediverse.
Against - it seems as though high visibility communities are potentially fairly easy to target and take down.
I think that decentralization wins out here in the end, but it does feel like there may be a need for some sort of fallback mechanism to be in place at an instance/community level. I suspect this might evolve somehow over time. It would require some way to expand trust between instances and or portability of communities (which could be fraught with user trust/data integrity issues).
If things don’t evolve it could grow into a whack-a-mole game for bad actors, or there might need to be more investment into server infrastructure (which could work against decentralization if only because of economies of scale).
Or maybe there’s no issue after all? I’m just imagining potential implications of a scaling fediverse - it’s fascinating and exciting stuff!
This is the primary reason why I’m ok for my instance to not grow massively. We got 10K people and we have pretty good traffic ,without overloading us or making too much of a target. We still get new users since we allow registrations, but the application requirements retain the quality
I’m realizing that I signed up for a probably-at-risk instance (lemmy.ml). I’m quite left but not necessarily an anarchist so it would seem applying to lemmy.dbzer0.com wouldn’t be a good move. (But I did enjoy reading your application requirements!) Recs on other small but reliable instances?
Absolutely makes sense. If lemmy is going to have any truly large communities though, investment in infrastructure/ops as well as function/moderation will be absolutely needed. (It’s an ‘if’, of course)
Time will tell how the community will want to lead it.
You don’t need to necessarily centralize to defend against DDos or similar attacks. You can add things like Cloudflare for DDos mitigations, CDN and maybe something like Kubernetes for horizontal scaling of servers (spin up more servers to handle extended load) transparently behind the scenes. This can also get you the benefits of low geographical latency, so a load-balancer fetches you data from the closest replica of a database geographically, etc.
Of course, all this adds up in terms of cost, but I think this might be worth it for the largest instances. I suppose that can still be considered centralization.
If we wanted to encourage small many small instances instead, perhaps there could be a transparent load-balancer layer for the fediverse that instances could sign up for, that is managed by a devops group. Alternatively, lemmy could have built-in load-balancing, caching, etc. as part of its codebase that instance operators can set up with their own accounts at Cloudflare, etc.
Agreed. Ultimately, that’s the point. There are solutions (with ongoing vigilance required) but it comes with an ongoing cost, be it server infrastructure or human resources).
I think the federated load balancer might be interesting but I expect there are many pitfalls that need to be considered and addressed wrt security, trust and integrity of data.
Anyway, it’s amazing to see this all grow and evolve.
permit separate, low-traffic, highly rate-limited, auth-only servers. They would be strictly rate-limited and only accept connections from whitelisted partner servers, because they only handle auth.
any partner server can authenticate a user and handle content for the server/auth-server pair, but only does so under certain conditions (determined by the partner - all the time, when ping api call > n seconds, or manually, for example)
user@lemmy.world can’t log in, so the client tries the list of partnered servers. user succeeds at lemmy.partner.net.
user@lemmy.world@partner.net says… ‘…something’ and all other servers accept it as being from user@lemmy.world
lemmy.world recovers, and claims all of the @lemmy.world@partner.net posts. Partners then forget the extra stuff they’ve been hosting.
The problem with these types of redundancy schemes is that it simply takes a Internet backbone hiccough (or AWS fuck up) to cause there to be multiple primaries (i.e. lemmy.world is online still, but some portion of the internet can’t see it, so a replica promotes itself to primary, people use both, how do you reconcile it).
This is not even beginning to talk about the nightmare scenarios possible if someone hacks a replica.
Edit: Still, this is a good thought and similar to how some actual software packages do things.
A lot of those issues of ‘multiple primaries’ can be resolved with intelligent data types and actions. That is, if we have a notion of how the data is organized, a lot of decisions can be made a priori. Ones that can’t can be read-only during a split.
Comment groups are mergeable sets. Any unique comment is a valid comment.
For any individual comment, any tombstone causes a comment to be unseeable (and ideally be deleted). Any edits are latest-wins.
A lot can be sorted out that way - enough to be usable. Some databases even support that on a db level.
This is a shame. Hosting a high visibility server is no joke, and I don’t envy the admins and the very difficult work they do. It’s simultaneously an argument for and against decentralization. For - a single instance can get knocked out without talking out the whole fediverse. Against - it seems as though high visibility communities are potentially fairly easy to target and take down.
I think that decentralization wins out here in the end, but it does feel like there may be a need for some sort of fallback mechanism to be in place at an instance/community level. I suspect this might evolve somehow over time. It would require some way to expand trust between instances and or portability of communities (which could be fraught with user trust/data integrity issues).
If things don’t evolve it could grow into a whack-a-mole game for bad actors, or there might need to be more investment into server infrastructure (which could work against decentralization if only because of economies of scale).
Or maybe there’s no issue after all? I’m just imagining potential implications of a scaling fediverse - it’s fascinating and exciting stuff!
Thoughts?
This is the primary reason why I’m ok for my instance to not grow massively. We got 10K people and we have pretty good traffic ,without overloading us or making too much of a target. We still get new users since we allow registrations, but the application requirements retain the quality
I’m realizing that I signed up for a probably-at-risk instance (lemmy.ml). I’m quite left but not necessarily an anarchist so it would seem applying to lemmy.dbzer0.com wouldn’t be a good move. (But I did enjoy reading your application requirements!) Recs on other small but reliable instances?
You don’t need to be an anarchist to apply to lemmy.dbzer0.com. Just follow the rules.
Absolutely makes sense. If lemmy is going to have any truly large communities though, investment in infrastructure/ops as well as function/moderation will be absolutely needed. (It’s an ‘if’, of course)
Time will tell how the community will want to lead it.
You don’t need to necessarily centralize to defend against DDos or similar attacks. You can add things like Cloudflare for DDos mitigations, CDN and maybe something like Kubernetes for horizontal scaling of servers (spin up more servers to handle extended load) transparently behind the scenes. This can also get you the benefits of low geographical latency, so a load-balancer fetches you data from the closest replica of a database geographically, etc.
Of course, all this adds up in terms of cost, but I think this might be worth it for the largest instances. I suppose that can still be considered centralization.
If we wanted to encourage small many small instances instead, perhaps there could be a transparent load-balancer layer for the fediverse that instances could sign up for, that is managed by a devops group. Alternatively, lemmy could have built-in load-balancing, caching, etc. as part of its codebase that instance operators can set up with their own accounts at Cloudflare, etc.
Agreed. Ultimately, that’s the point. There are solutions (with ongoing vigilance required) but it comes with an ongoing cost, be it server infrastructure or human resources).
I think the federated load balancer might be interesting but I expect there are many pitfalls that need to be considered and addressed wrt security, trust and integrity of data.
Anyway, it’s amazing to see this all grow and evolve.
Definitely, very exciting times!
I think this might be interesting:
The problem with these types of redundancy schemes is that it simply takes a Internet backbone hiccough (or AWS fuck up) to cause there to be multiple primaries (i.e. lemmy.world is online still, but some portion of the internet can’t see it, so a replica promotes itself to primary, people use both, how do you reconcile it).
This is not even beginning to talk about the nightmare scenarios possible if someone hacks a replica.
Edit: Still, this is a good thought and similar to how some actual software packages do things.
A lot of those issues of ‘multiple primaries’ can be resolved with intelligent data types and actions. That is, if we have a notion of how the data is organized, a lot of decisions can be made a priori. Ones that can’t can be read-only during a split.
Comment groups are mergeable sets. Any unique comment is a valid comment.
For any individual comment, any tombstone causes a comment to be unseeable (and ideally be deleted). Any edits are latest-wins.
A lot can be sorted out that way - enough to be usable. Some databases even support that on a db level.
Can’t post to op… But… Somebody just s scared.