this post was submitted on 15 Jul 2023
342 points (100.0% liked)

Fediverse

17688 readers
3 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
you are viewing a single comment's thread
view the rest of the comments
[–] 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.