this post was submitted on 15 Jul 2023
341 points (99.4% liked)

Fediverse

17734 readers
43 users here now

A community dedicated to fediverse news and discussion.

Fediverse is a portmanteau of "federation" and "universe".

Getting started on Fediverse;

founded 5 years ago
MODERATORS
deadsuperhero@lemmy.ml
wakest@lemmy.ml
341
Lemmy.world is down because of a DDOS attack (lemmy-world.statuspage.io)
submitted 1 year ago by DaEagle@lemmy.ml to c/fediverse@lemmy.ml
111 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] indigomirage@lemmy.ca 69 points 1 year ago* (last edited 1 year ago) (13 children)

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?

[–] bastion@lemmy.fmhy.ml 7 points 1 year ago* (last edited 1 year ago) (1 children)

I think this might be interesting:

  • 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.
[–] Calcipher@lemmy.ml 5 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] bastion@lemmy.fmhy.ml 3 points 1 year ago

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.

load more comments (11 replies)