cross-posted from: https://programming.dev/post/8955176
I made a blog post on my biggest issue in Lemmy and the proposed solutions for it. Any thoughts on this would be appreciated.
I think a variation on the multi community might be a good idea but implemented differently.
Community’s could opt into a meta community (somethings that are the same name arn’t the same thing).
Then on the user client side when you subscribe you can choose to subscribe to the meta community. When your feed is constructed it doesn’t include de-federated etc. when you post it is via your instance to the meta community and a shortcut is posted to all the meta community members, and replies go to your meta post in your instance.
You people just need accept the fact, that it is not “THE xyz community on Lemmy” but just “one of the xyz communities using Lemmy”.
moves to Lemmy to avoid centralization
Y NO CENTRALIZATION?!
But it’s still kinda centralized. If the instance hosting your community goes down, you won’t get comments and posts from users from other instances, so the community dies.
Yeah, one instance going down doesn’t kill the entire network, but it mostly kills the community.
The community belongs to a website, yes. You’re just subscribing to it remotely.
Lemmy is decentealized in the same way the web is decentealized. You can’t get articles from Blog 13705 if blog13795.net goes offline. That doesn’t make the web not decentealized.
At the end of the day, the whole fediverse is a bunch of independent websites hosting copies of other websites’ content. They’re not cloud communities, they’re mirrors.
That’s not what being centralized is
I really like solution 3, I hope that get’s implemented at some time. Though one potential problem is; what if pancakes@a.com is subscribed to pancaked@b.com and a user from e.com, who is defederated from b.com but not to a.com, tries to browse pancakes@a.com? Would they see the posts from pancakes@b.com?
If yes, that seems like a way to go around defederation, which I think is not a good thing always.
If no, how do you prevent the user from accidentally reposting something that they could have no way of knowing was already posted?