This site is currently struggling to handle the amount of new users. I have already upgraded the server, but it will go down regardless if half of Reddit tries to join.
However Lemmy is federated software, meaning you can interact seamlessly with communities on other instances like beehaw.org or lemmy.one. The documentation explains in more detail how this works. Use the instance list to find one where you can register. Then use the Community Browser to find interesting communities. Paste the community url into the search field to follow it.
You can help other Reddit refugees by inviting them to the same Lemmy instance where you joined. This way we can spread the load across many different servers. And users with similar interests will end up together on the same instances. Others on the same instance can also automatically see posts from all the communities that you follow.
Edit: If you moderate a large subreddit, do not link your users directly to lemmy.ml in your announcements. That way the server will only go down sooner.
That however would be a different problem. A horizontally scaled instance would be able to cope with more users, but if it shuts down for monetary, personal, or whatever reason, it's still down.
Protecting a community from this is what the decentralized part is for. That is already in place.
(Although there is a middle ground where you could design the system in a way that one instance is mirrored and load-balanced across different hosters. That would actually also be quite interesting to have. But that's another layer of complexity on top.)
What? How is it solved exactly? If say lemmy.ml is down, what's the point of other servers existing, if most of the content and users are here? Like, I created a few new communities on lemmy.ml, which don't exist on say Beehaw because for some strange reason, the Beehaw admins don't allow users to create communities. So how is going to Beehaw help me, if lemmy.ml is unavailable? Okay, so you tell me I should go to a different server then. Maybe even make a new server. Done and done. But there's very few to zero users on that server, so those new communities and content created there might as well not exist. Also, even though Lemmy is federated, the homepage defaults to "local", so all the new users coming in may miss out on all the other federated communities, and, if I'm reading this correctly, the federation isn't even a fully automatic process, and some admins may even choose to put there server in a whitelist mode. All of it makes the whole "advantage" of federation, or at least Lemmy's version of it, seem kind of pointless.
It's like saying, "Hey, Gmail is down so you should just use Hotmail instead." Okay, so I can still send and receive emails, but I can't access any of my old emails for context, and none of my contacts can reach me using my Gmail address, and none of my filters, address book and other content is available so I may not even be able to reach out to my contacts and let them know what my new email is.
IMO the way the way the federation should've been designed is to use something like blockchain technology, so every instance basically has all the content and there's only one source of truth for user accounts and data (distributed ledger), or maybe even just implement the whole thing as a plain old high-availability cluster with load balancing.
Unless I'm missing something fundamental, I don't see how this decentralization is of any use if the content isn't there.
There is no replication and failover so the problem is not solved.
Urgh, no way. Replication and some basic message signing would be enough.
Because you want to rely on someone else's instance. The idiomatic solution would be for a community to host their own lemmy/activitypub instance and join the federation. Then the community has control over their own data. In every sense. If they want to delete something (for breaching law, protocol, or whatever), they are free to do so and don't have to ask anyone else.
Please no. I mean there is IPFS out there that somewhat works like that, but I don't really like that. First, the ever-growing amount of data means that every instance has to keep up with it. If they wouldn't replicate it, the deletion of a single instance would still eliminate the data, even if there were references in a block-chain.
Also: the ability to "forget" is important. Not everything needs to live on forever. That it currently does, can already be a big problem. Look how peoples lives got almost ruined because someone dug up tweets from 10 years ago that were stupid. Solving the issue of data ownership is IMO one of the bigger things we need to keep in mind when designing a better web. Federation with the ability to "just" bring your own instance along where you are the owner is one of these options.
Fair point, but my original point/issue still stands. The admin here is saying "lemmy.ml is overloaded, use other instances instead" and that advice isn't really helpful, at least in the present state of things. Right now, we have an influx of novice users coming in from Reddit, and other servers either not accepting applications at the moment, or they are tooniche/specific (or inflexible, like Beehaw); finally at the moment, majority of the content is on lemmy.ml. So the end result is that lemmy.ml is one of the main viable servers.
If people join some random server which doesn't have the content they're after, they'll either lose interest, OR they may continue to consume the content on emmy.ml via federation, but then that's not really going to solve the load issue since the content on lemmy.ml isn't distributed/replicated.
I understand your point of ever growing data and how it may be better if that data is transient and not there forever, but for a news aggregator and forum type social network like Reddit (and now Lemmy), data is everything. If that data isn't available, or not going to available in the future, or will not be visible to audiences due to it being on some random server, it's going to give content creators much incentive to create content, and no content == no users. This sort of model/thinking will be doomed to failure, or be forever relegated to niche/enthusiast status, where only niche communities will thrive on specific servers targeting that niche. Which I guess is the ultimate goal of federation where every topic/community has its own server? But to get there, you'll need interested users, and to get users to be interested you need a stable, singular place you can point them to, where they can post content knowing. And maybe, as that server grows, the admin could start splitting off the larger communities into their own individual instances?
This is how I am understanding it. Please correct me if I am wrong.
I'm going to use Reddit as an example, since we all understand that...
So the way I understand this is that backbone is now the whole of the internet instead of just reddit.com.
Each instance would be somewhat akin to a self-hosted subreddit. We can reach any sub from any other sub, since the backbone is now spread across the whole internet instead of just reddit.com.
These subs (instances) are also like old style BB forums in that there can be different categories (communities) hosted by that instance, but those are also still visible across other instances.
So basically people who are making communities here are making a sub in a sub (in Reddit terms).
Do I have that correct?
Mostly. I try to think of instance as not a subreddit but a loose collection of them, like a multireddit.
What is kind of nice, in my understanding, is that text content is replicated across federated instances when a user is using both. So if you're on beehaw and comment on lemmy.ml, both of these servers will have your comments. That's already providing slightly more redundancy than reddit.
I still don’t quite understand how the community is replicated…
Are you saying that if Lemmy.ml/tiki exists and someone creates Beehaw.org/tiki that they are the same community? They would show the same posts and comments?
Or are they completely separate communities that would just have the same name… users could subscribe to both if they wanted, but the posts and comments would be stuck on their respective instances?
Or - Is it the case that Lemmy.ml’s tiki community and posts and comments are also stored on Beehaw.org somehow?
If I deleted the tiki community on Lemmy.ml, would users from both communities lose their posts and comments from the Lemmy.ml instance of that community?
The current state is that they are separate communities, but I believe the person you're replying to is proposing something like the other option, where some communities would be the same across instances so that the community and its post history would survive if one of the instances went down (not currently the case).
Currently, if you deleted the tiki community on lemmy.ml, only the lemmy.ml tiki community posts/comments would be gone. Any other tiki communities on other instances would remain.
Ok, say there was an established /tiki community on lemmy.ml, and some new server started up and started its own /tiki community. Would the posts from the lemmy.ml tiki community show up in NewLemmyServer.com/tiki... but only if NewLemmyServer was connected to lemmy.ml? Right?
From how I understand it, they would be different communities. Example: you have lemmy server A, B, and C. Your account is on C, and all 3 servers have tiki comunities. To access tiki on C you would go to tiki (since it's local), to access tiki on A you would go to tiki@A, b would be tiki@B.
If there's a community serverA/tiki, you can search on serverB for serverA/tiki and join the community serverA/tiki from serverB. Content ist replicated to serverB and back.
serverB/tiki@serverA is the replica you can fully use on serverB. This can exist beside serverB/tiki, which is a different community.
If someone writes a posting or comment on serverA/tiki, you can see it in serverB/tiki@serverA.
If someone writes a posting or comment on serverB/tiki@serverA, you can see it in serverA/tiki. (And even on serverC/tiki@serverA)
The Tiki community should simply run a Tiki server, no? Problem solved.
Great idea, but then I'd have to get into the whole hosting thing and all of that which I don't want to do.
There may be someone in the community that's interested and/or willing.
But i agree, it's not as simple as it sounds.