I don’t understand how Lemmy intends to do it when the different instances are federated, if several instances create the same community for example…is that possible?
Honestly we wont know until federation is actually implemented to some degree. I dont think it makes sense to automatically merge communities with the same name on different servers, as some other commenters mentioned. That would cause a lot more problems than it solves.
I don’t really have a firm opinion on this, there would be positive and negative aspects. The goal of my post was to talk about it with you to try to better understand how it works.
Let’s imagine that there are hundreds of federated servers and therefore potentially hundreds of times the same community names. It might be complicated for users to choose. And it also risks diluting the strength of the communities, so potentially little activity per community… In addition, if different communities are moderated or administered by different people and each has its own moderation or content rules, this can make things complex for the user.
One can also imagine other solutions, for example instead of following communities, the user could follow hashtags. When he publishes content, he is obliged to put tags on his content. Other users then follow the tags that would replace the communities.
That might solve some problems, but it might create others that I haven’t thought of yet.
The advantage is that I can follow hashtags throughout the federation, and keep the power of the federated network without fragmenting communities. There would be no need to worry about squatting community name
Dessalines already wrote a post on why he dislikes the hashtag idea, and I tend to agree with it.
https://github.com/dessalines/lemmy/issues/317#issuecomment-574272305
Thanks for the link, I didn’t know there was already a discussion about this. It’s not a simple issue to solve, i think there are positive and negative aspects to both solutions.
The community solution:
- (+) Moderation of communities by creators
- (+) Sense of belonging to a community
- (-) Fragments content and interactions
What scares me about this solution is the problems associated with fragmentation. If users who are interested in design, for example, will do a search and find 36 communities on the federation with the name “/design@server.tld”. I imagine that the first reaction will be to choose the community that has the most members, therefore the most content and interaction. I don’t think they will have fun reading all the descriptions, all the rules of the 36 communities, but I could be wrong. One way to limit fragmentation a little bit would perhaps be, when creating communities, to show a list of all the existing communities with the same name. I’m also a little afraid that this fragmentation will result in less interaction between users and that we will end up with many dying communities with no interaction.
The hashtag solution:
- (+) eliminates the problems of redundancy or fragmentation of content and interactions.
- (+) simplifies the user experience
- (-) no moderation (unless a system is invented to elect moderators democratically)
What can be problematic with this solution is that we’re going into the unknown, we don’t really have a model to follow. Which from a certain point of view can be a good thing because it also allows you to stand out from Reddit and create a unique differentiation. There is also the aspect related to moderation that remains unresolved, we could perhaps invent an effective or democratic way to elect or remove moderators for each hashtag. In any case, I think we should at least give users the possibility to block/hide certain users or instances.
Tbh this discussion doesn’t seem very important at the moment, because it relies on federation already working. In reality there is a ton of work needed just to get the basic federation working, so that’s what we should focus on.
Okay, I understand. Thanks, I’ll follow the progress with interest then. _
deleted by creator
deleted by creator
But this means that there can be dozens of different “#opensource@server.tld” rooms, so it would mean that a user who is interested in the topic “opensource” would have to subscribe to all the different rooms?
#opensource@one.tld #opensource@two.tld #opensource@three.tld …
I thought that if instance A had a room named “#opensource” instance B couldn’t open one to avoid duplication.
It’d be pretty easy to have a “subscribe to community on all supported instances” to auto-subscribe to all the communities with the same name on instances your root instance federates with or doesn’t block, and you can then go in and refine your subscription options by selecting and unselecting individual communities.
A bigger problem is what we should do with communities that are dedicated to the same topic but have different names. Like /c/foss and /c/freesoftware.
deleted by creator
I think Prismo doesn’t even have communities. Their model is one instance per topic.
You can tag communities with # and users with @ on Lemmy, so they would be the logical choices. But if we’re going with the Mastodon model it should be
@user@lemmy.mland either#community@lemmy.mlor#community#lemmy.ml.
Actually something that just came to mind: Maybe communities on one instance are the same communities on every other instance, but mods can be appointed per-instance and remove content on that instance only? I don’t know how practical that is, but it’s an idea.
Interesting idea!
/u/dessalines, would you like to comment?
An issue I just thought of is how initial instance mods would be appointed (for new instances etc.), but that could be done by instance admins or community vote? Or it could be the first user to subscribe from that instance.
/u/AgreeableLandscape The communities on different instances will be totally different, with its own posts, mods, etc. So
instance1/c/newswill be totally different frominstance2/c/news.Unrelated thought, you think it would be a good idea to send notifications about new comments to everyone above in the comment tree? So in this case, notify you, /u/muirrum and /u/AgreeableLandscape about my post?
I thought about it, because I think that’s the way twitter does it. But IMO for reddit-style it shouldn’t, there are some reddit threads that have dozens of nested comments, where the original parent commenters aren’t even a part of it anymore. I’d personally want mentions to be explicit if they aren’t in a direct response.
Totally agree but could it be better to have this setting as an option? In small communities, it could be useful, in large ones could be not. Let’s have a choice.
We could have an option to follow a particular point in the comment tree, but by default I don’t think that would be a good idea since discussion tends to evolve as thread depth increases, and notifying users about every comment can cause problems with most of them being out of context.
I feel like that would needlessly complicate federation, as described in other places on this thread (https://lemmy.ml/post/31114/comment/2943 etc).
Having different servers, many of whom aren’t connected, having different “versions” of the same community, that share some data, but not all, would be infinitely more complicated.
I see your point, however I think community fragmentation is an issue that will need to be resolved, and having separate communities for each instance won’t help with that.
What if instance A wants to make a
/c/news, and have control over it, but that name is already taken?Fragmentation means community owners actually get full control over anything they want to create.
Just an idea to think about it. It will definitely require A LOT of work to implement.
A community can be either on a particular server only or merged/distributed if, say, the mods of the comminuty1@server1 and community1@server2 will decide to merge their efforts and make a merged community. In the latter case, this will be a single community with master-master (or any other type) replication, set up explicitly by its admins.
After the merge, all the userbase is merged, all posts ratings are also merged somehow. Both mods will decide who will have which rights after the merge.
A merged community may include more than two servers, the replication is set in whichever way the mods want.
So, the above may solve somehow the fragmentation problem but depends heavily on collaboration.
