this post was submitted on 17 Jun 2023
214 points (100.0% liked)
Technology
37801 readers
351 users here now
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Subcommunities on Beehaw:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
know very little about the programming but it feels like there would be some sort of SSO multi-instance user account syncing solution.
Make an account on one instance, say Lemmy.World, and from that account request access to the other instances that you would like to join. Your account would get cloned and synced to the other instances that you get accepted to and posts/comments in that instance would be stored on that instance account as a secondary instance.
Posts could be cloned to all federated clone accounts or you could designate a secondary backup acount in case the primary server goes down. Maybe there could be a limit of instances you join like 3-5 cloned accounts to reduce duplication of data and maybe only clone messages, not media or something unless specifically requested. It would also allow for folks to continue posting and browsing even if their primary instance is overloaded or down which would improve the end user experience.
Again I only have an approximate idea how this works so this may all be dumb...
I am also not a programmer, but I have been thinking about the above idea as key to simplifying the adoption of lemmy to the broader public. I think that this idea is good, but the fact that the host instance must locally store all the data of another instance it's federated with seems resources intensive (but I bet storage is cheaper than processing calls). Wouldn't it make more sense to have a shared API-like protocol to allow instances and users to migrate freely using a SSO?
I think that the problem I had was "but which instance should I join?" and the answer that I understood when I saw someone commenting from mastadon in lemmy.ml or something was "it doesn't matter."
Then it became "but which one do I want to join and be associated with?" and after a day or two, I found feddit.uk, which appealed to me very much as a concept. I've been happy with my choice.
I occasionally worry that I'll need to create other accounts on other instances, but thankfully I'm not (yet!) blocked from the communities I subscribed to on beehaw, beehaw being the place that I most nearly made an account.
I'm not sure that an auto-copy of accounts is simple in practice or secure in principle, and I worry that it would make experiencing the fediverse even more complicated, eg I'm commenting on beehaw, but should I use my feddit.uk or my usenet.revisited.digg.lemmy account?
I worry that it would also fail to solve your moderation quandries - the beehaw mods would want to block exactly the auto-copied accounts from other instances that are the only duplicate accounts you would need because you can already access content from outside the blocked instances without creating other accounts.
Yes, I joined Feddit.uk too - there was a recent post saying that they were going to keep the number of defederated instances small, which is good to know. Major stuff shouldn't disappear suddenly.
Yes, so way to merge some accounts (like elsewhere you can sign up with your Google, Facebook, etc accounts under one login) and/or being able to easily switch accounts/instances as easily as you can in Reddit. I am using the Jerboa for Lemmy app, so this may all be possible in other apps or web interfaces.
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.
That probably is the best solution because it keeps the moderation burden off of the individual sites.