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 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.
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.
deleted by creator
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.
deleted by creator
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.
deleted by creator
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.