On Digg there’s some drama because someone registered the community “/wallstreetbets,” and the admins took it from him and gave it to one mod of the subreddit “r/wallstreetbets.”
One day later I see this discussion about how Reddit registered trademarks for some high-profile subreddits.
This could be relevant for the Threadiverse.
Your source is 3 months old and doesn’t back up your claims.
If lemmy.ml chooses not to federate with an instance, then those communities would not be in the listing, hence a veto power?
In full fairness, it is fairly easy to add a new community after the new instance is spun up, which is why I said “what communities are allowed to be acknowledged as existing to new instances”, i.e. using that built-in source without additional efforts to go against that trend.
This change increases the level of “centralization” towards using “lemmy.ml as the source of truth for that”. Trends towards centralization go against the spirit of a decentralized system, imho. Federation takes on a whole new meaning when it is interpreted not as individual rights but as a means to propagate the content authorized to exist in a central source… exactly as the OP topic covers, where community names must adhere to Reddit’s mandates.
Comment from Nutomic as it seems you might have blocked him
https://github.com/LemmyNet/lemmy/pull/6276
Nutomic is not in my blocklists - I may not agree with the devs philosophies but I do highly respect them nonetheless (I realize that may not always come across well), for offering their software as FOSS rather than keeping it private. I did block all users from lemmy.ml though, as the VAST majority of the time those comments just waste my time so while that throws out good replies sometimes, I find the balance highly worthwhile, personally. If it were possible to make an exemption to that, I would have done so specifically for Nutomic.
Anyway this is excellent news!! Sorta. It now being configurable, I will stop spreading this as misinformation, particularly against the lemmy.ml instance being authoritarian, and I thank you both for your correction in this matter.
That said, at a quick glance it does still look like the way to replace it is to use a different instance’s community listing? (lemmy.world, lemmy.zip, whatever) Which is still a trend towards “centralization” - even if configurable now as to which source of bias the instance admins chooses?
I agree that it is entirely fair that Lemmy sourcecode development is slow (possibly the constraints of language choice, and/or funding concerns, etc.), and so Lemmy instance admins must make do with things that can be changed more readily while awaiting more difficult solutions to be implemented, with lower prioritization.
So overall still not an ideal situation, but I thank Nutomic and you for pointing out that it is a LOT better now than the earlier choice to hard-code lemmy.ml specifically into the codebase.
I dislike centralization as much as the next person and have my issues with lemmy.ml being allowed to control anything outside its own instance, but I think the way you phrased it is misleading.
That suggests .ml has the ability to prevent communities from being acknowledged at all by other instances, while the anti-feature is actually about them being the sole source of truth for what counts as a “popular” community.
They can censor and curate that list to their authoritarian-apologist desires—which is a problem—but it only affects discoverability when browsing for popular communities, and instance admins can (and should) turn that off.
I don’t know if there is an English language issue here (understandable if there were), but that is literally not what I said. I added “to new instances”, which precludes the possibility of interpreting what my words here to somehow mean “communities from being acknowledged at all by other instances” - the latter wording itself seemingly implying existing instances, which runs completely counter to new ones.
Anyway, it is not a blocker as you are saying (that I said), but a discovery impediment, wherein lemmy.ml acts as the central authoritarian decider for what listing of communities is presented to new instance admins upon first starting up a lemmy instance.
And while you can turn that feature off, then Lemmy has to limp along without that leg to stand upon. Yes you could replace it entirely too, but once you start replacing code are you really running “Lemmy” anymore, or like a de-authoritarianized version of it? Basically a decentralized fork? At which point such an action would go along with my latter wording “unless we fight against it”.
So my point was basically that there are centralization trends going on inside the Lemmy code, which I pointed out. A similar event occurred several years ago where lemmy.ml decided that certain swear words were inappropriate, and hard-coded those filters. When asked to remove them, they said:
- Nutomic
But then later recanted after a huge outcry. It makes sense that lemmy.ml makes the Lemmy codebase to suit their own needs, and only considers the desires & needs of the wider world outside of that as secondary. My point though is that that is what is going on… “unless we fight against it”.
I agree with your overall opinion, but I just don’t agree with how the problem was presented. Your statement, with more of the surrounding context:
The key words here are “allowed to be acknowledged as existing”. Not acknowledging a community’s existence means not federating it. .world does that with db0’s piracy community because of EU laws, and it’s basically an instance-imposed community ban. Pyfed has/had a hard-coded denylist of community names in the source code that stopped them from being federated, and the result was none of the instances running unmodified Piefed were able to access them.
I wouldn’t have an issue with if you said a change in Lemmy “gives lemmy.ml exclusive control over promoting what communities show up as popular in other instances”. They don’t have the ability to censor the existence of communities that go against their views just the ability to censor their promotion. That’s a big problem, but it’s not as catastrophically bad as them having the power to censor the actual content on other instances.
Begging your pardon, but that is not what I said. You included my actual phrase in your quote even:
(emphasis now added) I am not sure why you think we are disagreeing here, when it seems we are in perfect accord. e.g. in your words, it:
Yes, that, exactly. It only affects new instances, not existing ones, it is only discoverability, not acting as a blocker to actually bring in those communities, and yet it is something that admins need to be aware of now and turn off. Almost like the instance admins cannot trust that the code will run according to their principles, without some modifications.
I concede that my phrasing sounds entirely different when you leave out the “to new instances”… but that is precisely why I put that wording in there?
Anyway, getting back to the - ahem - central point (pun intended), the aspect under discussion here is that centralization gives admins & mods too much power, whereas defederation places that power into the hands of the people.
Lemmy.ml is extremely famous on the Threadiverse - dare I say, infamous? - for doing precisely this. And now those same developers are increasing the trend towards centralization by baking right into the code something that will increase the trend towards centralization even further. Not by an enormous leap of course, but step by little step is precisely how such things have always gone? I never said the word “catastrophically”, just that it was a step that I felt like was in the wrong direction.
i.e. “The Fediverse doesn’t work like that” is a statement that encourages complacency, as if it never happens here. It does, albeit to a MUCH smaller degree than on Reddit or Digg. If the statement had said “The Fediverse does not do that to nearly the same degree”, then I would agreed, but I took issue with the binary logic of exclusively only yes vs. no, and pointed to where the answer is not quite “entirely no / never” here on the Fediverse too. “we all can easily fall prey to authoritarianism, unless we fight against it.”
No, that’s just relevant to the mass community lookup tool. Piracy communities can still be federated individually on the Piefedverse (so to speak), and I believe that Rimu has removed that term from that.
It’s also a hypothetical, not the actual reality.
If it ever becomes a problem then it requires editing a single line of code (which could easily be setup to read a user-specified location if the complainer wants to change things). It takes 45 seconds to locate the changes: https://github.com/LemmyNet/lemmy/commit/8c2303a1e7b784689471a6670a28354b7dff82ad#diff-8a74e1aa82158c28d9695f1f124a49078129391eee455cc691aa330ad11664d5 in build.rs
Complaing about Lemmy while not doing anything to contribute to fixing the problem shows that some people are mentally stuck in Reddit and don’t understand open source processes.
There’s no product manager being paid to scan social media looking for complaints to relay to development.
If someone notices a problem or has a problem with the design then the answer is to create an issue on the issue tracker for the project. It’s even better if you edit the code how you think it should be and include a pull request.
The answer isn’t to misrepresent changes or discussion from the issue tracker in order to stir up anger and outrage.
In the FOSS world, if you want things to change then go change them.
Being aware of the practices going on inside of the codebase seems like something that we agree on. As for an actual solution… go ahead and make a fork if you want then, or perhaps provide a fully-coded solution and see if they will replace their code with yours - for me I’ve switched to PieFed.
Yeah, for sure. Be aware, make your point known and offer alternatives… in the project that you want to change.
Stirring shit on social media isn’t contributing.
Create an issue in the issue tracker is free and takes as much time as writing a post on social media.
This specific issue is something that is 1. Not an issue because the hypothesized ‘attack’ that’s available to lemmy.ml using this system is not being done and, if it was, would be easily detectable. 2. Trivial to change for any instance owner who wants to make another instance the source of their initial community grab. This code is ran once, when the instance first stands up, in order to receive a list of communities to populate the ‘Communities’ tab at the top and after that uses the exact same system as every other instance for adding and removing items from that list based on the local user’s subscriptions. It has no impact on existing servers or communities.
The impact of this issue is currently non-existent and relies on a hypothetical situation that isn’t occurring. If the bar is that low for someone so that they will crash out on social media and swap projects, well that someone is going to be very busy swapping projects… because the FOSS world has an endless source of technical quibbles like this.
You can do whatever you please? I already included a link to a conversation between the Lemmy developers, who are also the instance admins of lemmy.ml, and the admins of another instance, where the Lemmy developers responded so they are already aware.
I would like to do as I please too, therefore I shared some knowledge in response to the wording of “The Fediverse doesn’t work like that”, pointing to an occasion that I know where the Fediverse very much does work like that, sometimes. After that… somehow the goalposts kept getting shifted.
The goalposts didn’t shift, you started talking to a different person.
This person says that this issue is small, the impact of exploiting this system would be minor (if it ever happened), and the hypothetical attack on this subsystem is also demonstrably not occurring.
Therefore, treating this issue as if it were some sort of red-line issue or, really, even worth discussing outside of the context of the project itself (where changes can actually be implemented) is misrepresenting reality.
As to your direct point, it wasn’t my point but I do agree with it so I’m happy to directly address your argument.
The quote you seem to take issue with was :
Or, more plainly:
The Fediverse doesn’t allow a single user to scoop up all of the similarly named/themed communities and use that power to dominate those topics of conversation.
Your reply:
Your reply references code affecting the Lemmy server instance, that runs once on server instantiation, which uses lemmy.ml as the source to populate the list of communities that users of the new instance will see when they click the ‘Communities’ link at the top. This is true.
Your inference that lemmy.ml has the ability to veto what communities are allowed to be acknowledged as existing to new instances is a bit of hyperbole. Lemmy.ml is the source of the initial list, true.
But new instances acknowledge communities existing regardless of those community’s status with lemmy.ml. The moment that a single user reads a single comment in a community that isn’t on the initially seeded list, then it appears in the new instance’s community list regardless of the status of that community on lemmy.ml.
If we were a security researcher and were analyzing the scope of this problem we would consider that
This only affects new instances, so the vast population of Lemmy as it stands now, is not affected by this code at all. Only a hypothetical future population.
The list on lemmy.ml is not treated as authoritative. Outside of the initial values, lemmy.ml is not checked for any other functions related to adding or displaying communities
Any attempts by lemmy.ml to game this system are both not happening and also easily detectable as the list is public and can be compared to other instances.
So, this veto power isn’t being used. If lemmy.ml were attempting to leverage this power, it would be detectable. In the worst case, if were actively being exploited then it would affect very few people(none of the current Lemmy community), and the people that it did affect are impacted only until a user reads a comment or post from a ‘vetoed’ community.
Also, this is an open source project so saying things like:
Simply make no sense at all.
You can change it. Any admin who thinks it may be a problem can change it. I linked to the exact section of code where you can just change the URL and compile the .rs file again to use a different instance.
You could change it so that the URL is read from the options file that the administrator sets prior to launching the instance. You could also submit that as a PR so that future administrators could just apply your patch (independent of it being accepted by Lemmy) because that’s how open source development works. That’s what the quote that you provided means:
It sounds dismissive, because it is. This isn’t a product, you’re not a consumer. You’re going to people who donate their time and telling them to do work in a way that you want it done. They may agree, and you may be able to make good arguments to convince them but if they don’t, then brigading social media or spamming their issue tracker with requests isn’t going to get it done.
If you don’t like it fork it and fix it. It is a fundamental concept in open source software that you can always fix problems that you see and other people can use your fixes regardless of what the project thinks. If you think the project is going in the wrong direction then you are perfectly within your rights to take a copy of the code and develop it in your own way and if you can find other people who believe like you do then they can use your changes as they see fit.
But going online and misrepresenting the risk of some code update that you disagree with by exaggerating the scope of the problem isn’t how you get anything done except creating needless drama.
The original point here was that:
The sentence prior to that was:
And I pointed to an area in the (planned future release of the) sourcecode that did in fact centralize information. You even agreed:
I never said that this is the death knell or whatever of the entire project, just that it is a step towards, rather than away from, centralization. Which again, you agreed on.
And imho it is not a good step, i.e. the direction that it is aiming towards is not a good goal to have for the Fediverse. Feel free to prove us all wrong by fixing the code and then getting the devs to agree to use your fix rather than continue to use lemmy.ml as the singular source aka central authority. They might agree actually, though it still did not make the step that I am talking about now a “good” one. Any step towards centralization is a bad one imho, especially when that centralization is put right into the sourcecode (as opposed to e.g. an external, 3rd-party website run by people who could be trusted to be more unbiased, and by unbiased I mean that lemmy.ml is VERY biased towards certain viewpoints, so NOT that, or another alternative could be to gather community listings from all federated instances and then combine them together, rather than have one “master” list to rule them all).
This is an unreleased feature to federate some popular communities when a new Lemmy instance is created. It was hardcoded to lemmy.ml for a while, but I already changed this and made it configurable. Obviously the entire development code for Lemmy is not ready for production now, and needs a lot of fine-tuning. Its not an argument against the stable release version of Lemmy.
That’s good news, thank you for this.
FYI @openstars@piefed.social
They seem to have blocked Nutomic, so won’t see this.
I’ll comment higher