I made a blog post on my biggest issue in Lemmy and the proposed solutions for it. Any thoughts on this would be appreciated.
As someone used to Old Internet: how is having multiple communities for similar topics a ‘problem’? If you like Overwatch, do you demand that Activision, Steam, and GameFAQs all combine their forums about it? If you like baking, do you demand that all of the hundreds of sites dedicated to it all blob into one? This seems like a very wierd idea to be so definite about.
I just wish threads using the same link and threads that are crossposted shared comments with a link on top of the comment that said the title of the original post.
It sucks when an article is posted to 5 communities and i have to go to each one to read all the comments. I want to read all the comments about the article in one place. If the thread is about something specific and uses the same link I would still understand the context because the comment would include the link/title of the original thread it was posted to.
That’s exactly what the third proposal in the article would do. See the proposal its based on for more detail.
Why couldn’t this be solved at the client level? Whenever you go to a thread, the client could check the submission URL and inline comments from matching posts from other subscribed communities.
Reddit already does that with their “related diacussions” tab. It would be a lot more elegant, requires no extensions in the spec, no changes in the server side and easily prototyped/tested.
requires no extensions in the spec
That proposal doesnt require an extension to the spec. It requires a group to follow another group, which is definitively within the ActivityPub spec. The proposal above is written as a FEP (Fediverse Enhancement Proposal) which is the agreed upon way to propose new behavior in an interoperable way.
no changes in the server side
But it takes changes on the client side. One is not inherently better than the other. Also, doing it client side means you have to duplicate the work for every client. Doing it server side means it works for everyone.
easily prototyped/tested
Every fediverse platform already supports following
Actors. That’s part of the spec. Handling follows for groups is just as easy as for users.Also, doing it client side means you have to duplicate the work for every client.
Only if you want to force everyone to adopt this behavior. There are tons of people here that are telling you that this is a non-issue to them, why do you think that all clients need that?
One is not inherently better than the other.
When it comes to decentralized technologies and systems, it absolutely is better to delegate behavior to the leaf nodes as much as possible. The less things are mandated on the server, the easier it is to build a robust system. Pushing as much functionality as possible to the client is such a good way to follow Postel’s Law that is basically second nature to those developing distributed systems.
Only if you want to force everyone to adopt this behavior
Did you read the proposal? No one is forcing anyone to do anything. The proposal would allow one community to follow another. Communities don’t have to send a follow request and the other community doesn’t have to follow back. This works just like users following users/communities. It’s all optional.
There are tons of people here that are telling you that this is a non-issue to them, why do you think that all clients need that?
There are tons of ppl telling you it is an issue for them. If its not an issue for you, then you lose nothing if this is implemented, but ppl who care have one of their pain points solved.
it absolutely is better to delegate behavior to the nodes as much as possible… Pushing as much functionality to the client is such a good way to follow Postel’s Law that is basically second nature to those developing distributed systems.
The nodes are the servers not the clients. Your argument is the exact opposite of what every fediverse developer says. The reason most of the fediverse uses the MastoAPI (or lemmy api for the threadiverse) instead of the ActivityPub Client to Server API is because the C2S expects a more client focused ecosystem but all the developers find it easier to handle logic on the server.
The proposal would allow one community to follow another
Who determines when a community should follow another? The admin? The user?
If its not an issue for you, then you lose nothing if this is implemented,
My point is that it a lot easier to implement something that solves the problem that you are describing than asking for a whole change in the implementation of the server.
The nodes are the servers not the clients. (…) The reason most of the fediverse uses the MastoAPI (…) is because the C2S expects a more client focused ecosystem but all the developers find it easier to handle logic on the server.
It’s a trade-off between speed to deliver the base case vs the lack of flexibility to deliver a more flexible version of it. And the more that we push to the server, the slower it will be to be able to extend it. Case in point: People have been complaining about the lack of algoritmic timelines on Mastodon. The Mastodon developers will find all sorts of excuses to not have to implement it… “Algorithms are bad for people”, “People are just too used with how things in Big Tech”, “we rather working on moderation and safety”… etc. All of those are bad rationalizations for them to avoid doing work they don’t want to do. Which is fine, the devs are not forced to develop anything. The interesting things is that this problem was solved a lot faster by flipping it around and pushing to the client. And it works so well that that people now can even choose what type of algorithm they want to run.
Your argument is the exact opposite of what every fediverse developer says.
I don’t think I would ever be in favor of activity that leads to further centralization. I don’t disagree that fragmentation can make things somewhat confusing for new users, but there are some advantages as well. I like to post to smaller communities for the most part rather than the larger ml and world domains. The responses are more focused on the topic at hand, the communities are usually less hostile and hive-minded, and having all discussions on a just a few big servers leads to a the problem of having all of your eggs in one basket (ie. discussions and accounts disappearing when these servers can’t maintain server costs, the admins move on to other projects, or just poor maintenance practices.) To me it is worth the effort to cross-post and seek out other communities to find interesting content.
Indeed, if these places are able to survive, they’ll survive. No need to force it.
This kind of worship at the altar of efficiency is a big part of why we are losing our third places in society. Half the reason I’m here is to build. Not consolidate.
This kind of worship at the altar of efficiency is a big part of why we are losing our third places in society.
This is a brilliant and eloquent observation. My only concern is that younger people (and more specifically younger people from North America, the dominant demographic here and on reddit) never even had a third-place to begin with, so they wouldn’t know what they are missing.
I’m personally of the mind that we should be imagining a world where all 3 of these solutions are at play. 1 is absolutely the most important, and Admins should be taking an active role here where possible (particularly as it relates to dead community cleanup). I personally think they are the missing element needed to negotiate these sorts of consolidations. 2 and 3 on the other hand are pretty simple features and even if Lemmy never takes it on, I think it’s reasonable that any one of the new fediverse link aggregators could take this up. The only other thing I’ll say is multi-communities absolutely must be sharable. Ideally, it should even be possible to link multi-communities with the “!” syntax or similar.
1 is absolutely the most important,
1 is literally the worst of the three, opening the Fediverse to a death at the hands of corporate. And I’ve already explained its other issues.
I’ve already went on on why merging communities is Bad for the Fediverse (and only really helps the big corpos that get into the Fediverse), so it’s good that the badness of that “solution” is acknowledged.
As for #2: multicommunities: I seem to recall Kbin already does that, so it should work. As for sub-issue 1, "To create a multi-community, you would have to know where each community is and add it to your list. ", well that’s what webrings are for! Let’s bring them back from the '90s. Basically get’s give the power of “static search” back to the users.
Numero 3 Electric Boogaloo: Making communities follow communities, is not much of a bad idea, but I’m wary fo the issues already mentioned in it. I’m mostly concerned also about it making it harder to maintain smaller Lemmy instances due to the extra communication overhead.
The third solution wouldn’t cause extra communication. If you’re subbed to a community that follows other communities, you receive all the posts once. That’s the same as if you followed all of those communities yourself.
If your server hosts communities that follow others, that would still be the same as having users on your server follow those servers. It’s the same amount of communication.
I’m assuming you were talking about this comment. That doesn’t explain why merging communities is bad, only why you may not want to do it. Which would always be an option. Having the option to merge duplicate communities doesn’t mean you can’t maintain similar communities without merging them.
I appreciate the effort, but what is happening is option 1, aka merging of communities, naturally.
About knowing where to post, you can usually have a look at https://lemmyverse.net/communities, search the community name, and have a good idea of which one is the most active.
Sometimes different communities can coexist, and that’s fine. !science@mander.xyz and !science@lemmy.world have different audiences, and that’s okay.
I’m aware that people are slowly grouping up to one specific community per topic but I don’t think this means there isn’t an issue with communities being fractured. Using a third party tool to gauge which communities are popular also isn’t a great solution. Just searching Linux shows:
I don’t think each one of these communities has a different audience. It’s the same audience, but there isn’t an obvious answer for which one to visit or post in.
Id say that the obvious answer is the Linux community with the most members. !linux@lemmy.ml has more than double the number of subscribers of the next most active Linux community.
But then you’re on .ml
.ml is okay to discuss Linux, the overlap between the two communities makes sense
The overlap between authoritarians and Linux?
Well I suppose North Korea does run the closed source RedStarOS.
what makes you think they are authoritarian?
Because we all know how tankies are, so stop acting coy.
Maybe you should go conquer some bread instead of trying to defend maoists and stalinists.
There are multiple communities?! So what?? “Oh my God, I don’t know which one to write!” So what?
This is the type of nerd-sniping “problem” that should be way low in the priority queue for developers. In practice, people can figure this out and navigate the system. Go for the most active one and it will naturally become the canonical one. The people on the other, smaller, communities will find out about the main hub and subscribe to it as well.
It seems like people have grown so used to centralized systems and walled gardens that they lost the capacity to exercise their independence. Decentralized systems are capable of self-organization, and we should be glad we have the autonomy to choose and to move freely.
Right? Who gives a shit about user experience anyways? When someone has an issue, you just tell them to man up and figure it out.
No, it’s not always obvious which is the “main” community and there are many communities that died due to lack of traction, often because there are duplicate communities that also lacked traction. Community following would not only help unify communities and unify comments in crossposts, it also encourages decentralization by making 5 useful communities instead of 4 dead and 1 active.
It’s not insane or narcissistic to want to reach a big audience. The same audience, across multiple instances, without effort. It’s social media 101. Saying who cares to that is a great way to see a dwindling userbase. Maybe you can’t feel it because it doesn’t directly affect your usage, but it does many others, and providing an optional solution is not a bad thing to consider.
I’d also like to take this moment to show that this is the most popular issue in Lemmy’s github, getting over twice as many likes as the 2nd most liked issue. Everyone convincing eachother in the comments that nobody cares about this is clearly wrong, and are being so in an insanely toxic and dismissive manner. Thanks.
Go for the most active one
There isn’t one “most active one” because federation isn’t perfect and every instance sees a different number of users/posts.
The people on the other, smaller, communities will find out about the main hub and subscribe to it as well.
You can’t guarantee that. If they are on a smaller instance, their instance may not be aware of the larger community/instance.
I think decentralized systems are much better than centralized systems, but they’re inherently more difficult. Also, your solution (everyone eventually just uses the same community) isn’t decentralized. My proposal, which the third solution in the article is based on, enhances decentralization by allowing duplicate communities to exist but consolidate the userbase and discussion.
federation isn’t perfect
Again: so what? It’s reasonably easy to see how different is your view from a given community compared to another instance.
You can’t guarantee that.
You are right. There is no guarantee. That doesn’t bother me, and I truly don’t understand why it should bother others. I am not going to write only if I am optimizing reach or I know a priori if the people are going to approve.
Also, your solution (everyone eventually just uses the same community) isn’t decentralized.
Sorry, your argument is falling to the fallacy that Taleb calls “Thinking in Words”. If the system does not depend on a central authority and if the agents are free to talk with each other even when not in the same namespace, then yes, it is decentralized. In practice, there is no actual problem in having large communities belonging to one server. The people are not tied to it, and if the instance controlling the community starts acting malicious or against the interest of the majority, it’s easy to coordinate a move away.
If the system does not depend on a central authority
In your example of coalescing on a single community, the mods of that community are the central authority.
it’s easy to coordinate a move away.
It’s not even easy to coordinate everyone moving to a single community. This issue has been discussed in various forms for more than 3 years and we haven’t seen this supposed consolidation of communities. Coordinating anything in a decentralized way is never easy.
That doesn’t bother me, and I truly don’t understand why it should bother others. I am not going to write only if I am optimizing reach or I know a priori if the people are going to approve.
Cool. It doesn’t bother you. Then just keep doing what you’re doing. If we ever get a solution to it implemented, you won’t care but the rest of us will be happy for it. If you don’t care, why are you all over this thread arguing about this?
This isn’t about maximizing reach of our posts. It’s about consolidating discussion so that communities (especially those with more niche appeal) can have a sustainable userbase and not die out from lack of activity.
It’s about consolidating discussion so that communities (especially those with more niche appeal) can have a sustainable userbase
Great, so let’s talk about how we can increase the overall userbase instead of worrying about whether we can optimize the system for the small number of people that happen to be here already. There is no point in designing that tries to help, e.g, 5 people that like Yu-Gi-oh!, when in reality the most likely thing to happen is that they will just leave it here and go to /r/yugioh which has 500 thousand subscribers.
But if you increase the userbase, you’ll end up with more ppl who like yugioh and want a community which leads to duplicate communities. But for niche topics, the duplicate communities are likely to end up with userbases too small to sustain enough activity. A way to combine communities makes it more likely that users find other users who want to discuss niche topics with them. That helps to grow the userbase.
There is no point
Yes, there is. If we can keep those 5 users here, its better than them being on reddit. There’s no reason not to work on this. We have multiple projects, each with multiple contributors, so we can do multiple things at one time.
It’s a huge problem with the platform which you choose to ignore by saying “so what”. It’s impossible to refute someone who digs in their heels and says “so what” to everything and not seeing the problem.
There is a difference between “not seeing the problem” and “asking yourself what are the implications of it”. I’m running 15+ instances and I’m running a website that is devoted to help people find the “canonical” community in the fediverse. I can point to dozens of other issues that are a lot more “painful” to me as an user and an instance admin, none of them are related with the “pain of having to choose which community to join or focus”.
I’m again going to ask: is there any actual, practical example of this being such a “huge issue”?
And yet people want a better solution and are asking for it. And the only response you, an owned of 15+ instances, and an admin of a website that helps people find instances, can make is “deal with it it’s meant to be hard”. It’s a huge usability problem, it’s funny that you don’t see it. Consider this my last reply to you.
It’s the Linux mindset, the pain is the point.
No. We tried having it centralized and it sucks.
You didn’t read the post. The suggestion is to make the platform more decentralized not centralized. I’m not even going to reply to most comments in this thread that also, clearly, did not read the post and is making stuff up.
