Like many, when the recent defederation went down, I decided to create a couple other logins and see what the wider fediverse has had to say about it.
I’ve been, honestly, a bit surprised by the response. A huge portion of people seem to be misidentifying communities as belonging to “lemmy” as opposed to the instances that host them. I think a big portion of this seems to be a fundamental misunderstanding of what this software is, and how it works.
For example, lemmy.world users are pissed at being de-federated because it excludes them from Beehaw communities. This outrage seems wholly placed in the concept that Beehaw’s communities are “owned” by the wider fediverse. This is blatantly not how lemmy works. Each instance hosts a copy of federated instances’ content for their users to peruse. The host (Beehaw in this example) remains being the source of truth for these communities. As the source of truth, Beehaw “owns” the affected communities, and it seems people have not realized that.
This also has wider implications for why one might want to de-federate with a wider array of instances. Lets say I have a server in a location that legally prohibits a certain type of pornography. If my users subscribe to other instances/communities that allow that illegal pornography, I (the server admin) may find myself in legal jeopardy because my instance now holds a copy of that content for my users.
Please keep this in mind as you enjoy your time using Lemmy. The decisions that you make affect the wider instance. As you travel the fediverse, please do so with the understanding that your interactions reflect this instance. More than anything, how can we spread this knowledge to a wider audience? How can we make the fediverse and how it works less confusing to people who aren’t going to read technical documentation?
In practice this would be difficult to implement because each instance has its own take on how to shape the code for their site. There’s no obligation to create an instance so that it will be compatible with everyone else’s instance, and in fact I would guess that would be effectively impossible.
Let’s say Instance A allows porn, and a user on A wants to create an account on Instance B, but Instance B doesn’t want any porn on their server. At minimum, a way to keep any porn on that user’s account from syncing to B’s server would have to be implemented.
This is only a single case. There will be plenty more small issues like that to have to work around, so it will take a lot of time to get all that logic designed, implemented and tested.
The cloning of an account might also involve a not-insignificant amount of data being transferred. What if the receiving server wants to limit the amount of data storage for a new account so that they’re not burdened with storing tons of data for new, unknown users? How do you then determine what subset of that user’s data to import?
Maybe these things will happen with enough time, but for now I think it’s best for now at least if everyone thinks of each instance as its own separate website that can communicate with other similar sites rather than a set of cloned sites where which one you pick doesn’t matter.
Please don’t take this as argumentative, as we need people to share ideas like yours! I just keep seeing messages that give me the impression that people have expectations for the Threadiverse that aren’t currently realistic given what the state of the software is now.
Yeah I figured there would be technical challenges. I imagine the data load would be fairly large, but since its a growing platform data growth is going to be an issue either way.
Maybe the better solution is an app that you can log into multiple accounts with anditt merges your feeds.