or maybe at least the posts wouldn’t be replicated, but there would only be one community, and when you visit it, posts for the community are downloaded from your primary instance, as well as other instances based on some configuration that makes sense.
Dang, I didn’t realize we had passed !asklemmy@lemmy.ml in subscribers.
What have I done…
I think this is going to be the main bottleneck in the end. The principle of it might be great, but too many people won’t like this hurdle i’m afraid.
I don’t understand how this is a hurdle or a problem when it’s brought up. I subscribe to both in this situation (already am with these two).
I do think it would be cool if communities across instances could essentially link their feeds. But I don’t think that should be forced. Or maybe implement a user feature to group communities so you can click to see their combined feeds.
communities across instances could essentially link their feeds
yes, that’s pretty much what i’m saying. in the background, that is what would be happening, but on the frontend, the user just sees “communityname” and a bunch of posts that are pulled from all instances that have a community matching that name.
Because they’re all technically different communities sharing the same name.
Not unlike how on Reddit you had r/gaming, r/games, r/videogames, etc. Only this time they can share the exact same name.
correct. so let’s have a way to “connect” communities, a way for any 2 communities on 2 different instances (or the same instance) to “merge” their content, even if they have different names (e.g. “games” “gaming”). now maybe this could be user-defined, a per client thing, like multireddits, but with a recommendation on each community page that shows the most frequent “client community-merge-configurations”
The idea behind a decentralized network is that is decentralized. Each of those “ask lemmy” communities is independently run from each other and can impose different rules and moderation. If you don’t like how one community is being run, you can easily block it without missing much. With federation you can also easily subscribe to all of those communities to make them all seem bigger than what they really are.
What would be nice though is being able to make a custom feed of only your “ask lemmy” communities. That way you get a pseudo “centralized” feed of ask-lemmy-ness. Right now you’d need to jump from one to the next which is kind of a pain.
So the two solutions I’m seeing are either the Lemmy version of a “multireddit”, or another bot that reposts things across instances lol
I feel like if you’re okay with limiting it to communities with the exact same name, that this could be handled on the front end by app or web developers. I have seen some of the arguments about how it would be a lot of work for fairly little benefit on the back-end and I’m sympathetic, but “faking it” from a UI perspective shouldn’t be too terribly difficult (said the non-coder).
Because those are all different communities with different moderators. Think of the “subreddit” name as the full name of the community AND server.
Likely what will happen is one of them will “win out” with amount of activity. But here is the good news. If the moderators get on a power trip or things go south, everyone just switches to another one.
good point with being able to switch to another if a mod goes haywire. but i think that there just shouldn’t be any mods – or rather, the community members should moderate themselves via some algorithm that uses votes, discussion, etc. to hide/remove posts. you could choose to view a hidden post that has been downvoted a lot if you want.
Since email is the common analogy, I would extend that to say that you could be John.Smith@gmail. You might also have John.Smith@outlook. Someone else has John.Smith@yahoo. If you wanted, you could setup a new account John.smith@protonmail, or start your own server and be me@JohnSmith.com
Communities are the same way.
