I’ve been on Lemmy for some time now and it’s time for me to finally understand how Federation works. I have general idea and I have accounts on three federated instances, but I need some details.
Let Alpha, Beta, Gamma and Delta be four federated instances. I have an account on Alpha and create a post in a community on Beta. A persoson from Gamma comments on it and a person from Delta upvotes the post and the comment.
The question: On which instances are the post, the comment and the upvotes stored?
Federated content is stored in the balls.
I can confirm this to be true
As already noted, on all of them.
The easy way to grasp how it works:
When you, on instance.alpha, view a community on instance.beta, you aren’t actually on community@instance.beta. You’re actually on an entirely separate copy - community@instance.beta@instance.alpha. That’s the community you’re reading and posting to and upvoting/downvoting in. Meanwhile, people on other instances are each on their own locally hosted copies of the same community.
The lemmy software (or kbin or mastodon or whatever) then periodically syncs up all the local copies of community@instance.beta, so you all end up looking at (more or less) the same content, even though it’s actually a bunch of technically separate communities.
deleted by creator
It’s less efficient than a centralized forum would be, but efficiency isn’t the only or even the highest priority. Decentralization is the explicit point of the fediverse, and to the degree that that requires sacrificing some measure of efficiency, that’s just the way it goes.
The goal was to build a system that would be robust and relatively seamless while remaining decentralized. That’s more or less what they’ve done. There’s a fair amount of fine tuning and tweaking left to be done, and actively being done, but the basic system is what it is because it best balances all of the goals.
that’s possibly the best explanation of the difference between a corporate social or other media and a decentralised open source one.
It depends what you mean by inefficient. It’s very efficient if you’re optimizing for robustness and control of data.
It’s also very efficient if you’re optimizing for having an actual fucking conversation without algorithms or ads.
Control or redundancy of data?
If there is a federated delete, I get the impression there is no actual way to ensure that data is deleted?
I don’t mean control from the perspective of someone posting data. I mean from the perspective of the server owner.
Sorry, what do you mean?
It’s stored on all 4.
Regardless of which on you create the content on, assuming they all federated with each other correctly, every instance hosts its own copy of your posts.
So, data is not normalized. Isn’t it a waste of storage? Same data on all instances.
It isn’t a waste if it provides redundancy and prevents one server from being in control of all data.
What do you mean by “normalized?”
I see your point.
I used the term “normalized” in the context of databases. One piece of data should exists only once. But, this contradicts your points of redundancy and control.
That isn’t what normalized means in the context of databases.
Also databases store the same data many times over often. For redundancy and load-balancing purposes. Really, federation just takes care of replication somewhat.
That’s not what “normalized” normalisation means in the context of databases.
Ok, I come from the signal processing world where that means something very different.
The only objection I have with that is redundancy is useless because if the main server who “host” the community goes down then all the other copies will die too as content can’t be added anymore.
There’s no mechanic for orphan communities
It’s mostly intended for caching content to speed up load times afaik
Nice try, Spez! Get outta here! Go on, get!
deleted by creator