Well that explains why a couple threads I posted weren't gaining any traction. I hope the issue gets figured out soon, otherwise I'll have to use my Mbin alt for anything lemmy.world related.
Is there a way to leverage down votes to limit content, at the magazine or instance level? I think I know the answer, but it would be dandy to put in place
I said that already, mbin might be good but I didn't like the advertisement.
I'm not quite sure what your position is. I am by no means an mbin booster. In fact I find some of the people pushing mbin over kbin (in lieu addition too) jerks about it.
This whole thread has been about the similarities I noticed between comments people made about/to Ernest previously and the sort of comments we later learned led to the xz backdoor.
When I started to read breakdowns about the social engineering behind the xz backdoor I was like, "Waaaaitaminute, I've seen that sort of talk before." I found it notable to point out the similarity and maybe poke around at it.
People decided to use the thread (to my excessive chagrin) to talk shit about kbin and rehash the exact same pressures I was attempting to analyze.
When I started to read breakdowns about the social engineering behind the xz backdoor I was like, "Waaaaitaminute, I've seen that sort of talk before." I found it notable to point out the similarity and maybe poke around at it.
People decided to use the thread (to my excessive chagrin) to talk shit about kbin and rehash the exact same pressures I was attempting to analyze.
It's a shame, because I noticed similar patterns was looking forward to some good discussion about it here. Alas...
However, it's much more likely to be due to the common experience of solo devs whose projects blow up than it is about bad actors on kbin.
If you're so inclined, you can always check the profiles of those who were pushing for it and particularly those who were volunteering; the boehs.org link should supply some helpful red flags to look for. Ernest would be wise to check IP activity and even ask for IRL credentials of those he would consider giving any real level of access to. Beyond that, it's firmly in the realm of "mildly interesting."
I just need a little more time. There will likely be a technical break announced tomorrow or the day after tomorrow. Along with the migration to new servers, we will be introducing new moderation tools that I am currently working on and testing (I had it planned for a bit later in my roadmap). Then, I will address your reports and handle them very seriously. I try my best to delete sensitive content, but with the current workload and ongoing relocation, it takes a lot of time. I am being extra cautious now. The regulations are quite general, and I would like to refine them together with you and do everything properly. For now, please make use of the option to block the magazine/author.
Multipile Things I noticed as a creater of this thread:
can I close comments ?
can I hide comments ?
can I pin a response?
can I quickly see from what server peope are interacting?
I am no coder but would love to support you with all the work that is done.
At least some of the costs can be taken of your shoulders:
All the things you mentioned are in the roadmap. However, we can either do it quickly and potentially encounter issues in a few weeks or months, or take a bit more time for a more thorough approach. I've decided to move away from playful prototyping. From now on, every change will be tested before it's approved for kbin.social - it's no longer just my code (https://lab2.kbin.pub/). I'd like to close this thread for you... but can we just agree not to respond in it anymore? ;p
I don't think closing threads is a great idea or in keeping with how this all works. I think it'd be nice to be able to mute a thread as an individual, but by its nature these discussions are open and shared with many instances. If we close it on kbin.social, other kbin instances, lemmy instances, and even places like mastodon and pixelfed could keep discussing, if I understand activity pub correctly.
In such important tasks, I would like to engage in community-driven development. When I start planning these tasks, I will come to you with my whiteboard and sketch out the individual stages. Together, we will look for the advantages and disadvantages of such a solution, the weak and strong points. This is to jointly make a decision on whether the change makes sense on kbin.social but also in the perspective of the entire federation. It can be a great fun ;)
Let’s all agree that of its many issues, locking/deleting open threats to targeted minority groups and pro supremacist propaganda meant to hurt or influence vulnerable people was NOT a drawback of the Reddit experience.
Yes, it’s a difficult thing to enforce a subjective line of a basic standard of decency, but it’s also what a society is and one of the main reasons we gather as people. The quality of a group is shown in how they accommodate the weakest and most vulnerable among them.
If we aren’t prioritizing a way to send this CHUD and people liked them to the hypothetical edge of town, to be sure they can’t bombard the young person struggling with their gender identity with targeted hate at their weakest moment, then what are we doing here?
Could you clarify what you would do in cases like this? Censor based on misinterpretation of the clickbait headline, even if it does not contain hate content at all?
A friendly reminder; Please don't forget to take your time and step away from Kbin whenever you need a break. Your mental health is just as important, if not most important, for the project to succeed.
Everyone appreciates your effort here, ernest. Spez hasn't gotten 92 upvotes on a comment in years lmao despite Reddit having millions of users, it really shows how the difference.
I joined kbin recently and I'm kind of concerned about the implications of this. I don't support those posts at all, but who gets to say what's worth banning and what not? Wouldn't that go against the decentralized nature of the site? Or is it the specific instance that magazine is on that has the authority to ban what's inside? How does all of this work?
Edit: my bad, I got kbin and kbin.social mixed up. Noob mistake.
kbin.social administration controls only what is published on kbin.social, and what content from elsewhere kbin.social users can see. An user banned from kbin.social can make another account, on another site and start recreate there his banned community. kbin.social will be able to ban this remote user and remote community, but this restricts only what kbin.social users can see.
Exactly the same for another /kbin or lemmy site - just replace the domain name accordingly.
While I kind of agree with you in being concerned about who gets to control what we see and don't see and the censorship aspect, there is also "the paradox of tolerance" to be considered and maybe in that light it is correct to not tolerate that subs intolerance.
Wouldn't that go against the decentralized nature of the site?
No, it's exactly the opposite. The entire point of a decentralized federation is that while yes, the admin is in complete control of what content is allowed on his or her own instance, users who don't like what the admin is doing can just spin up their own new instances.
Ernest can ban this type of content if he likes. Others can take the kbin software and make a new instance where it's welcome. Ernest can choose not to federate with that instance if they continue to push content that's against his rules, but Ernest doesn't have the power to dictate the direction for hundreds of millions of users' experience like a certain centralized site's mad CEO or admin board does.
What would be against the nature of ActivityPub is if Ernest built something into the software to prevent it being used for types of content he doesn't like, even on other instances.
The regulations are quite general, and I would like to refine them together with you and do everything properly.
I have been wondering how instance-wide moderation will end up looking on kbin, once you've had a chance to get a team in place for that. While it is (I assume) a "generalist" instance, it's important to keep in mind that you can't please everyone. Trying to have too broad of an audience will just result in retaining those with a high tolerance for toxicity (usually highly toxic themselves), while everyone else leaves in favor of better-managed spaces.
Communities in general, and particularly on the internet, need to understand what their purpose is, and be proactive about filtering out those that are incompatible with that purpose. This doesn't mean judging those people as wrong, or "bad people", it just means recognizing that not everyone is going to get along, and that some level of group cohesion needs to be maintained.
Agreed, that's part of my problem with generalist instances. They're so broad that they serve multiple communities with differing expectations, and it forces admins to take sides.
I think there is value in having both generalist and specialized instances, and the big landing spots for new users should probably strive to be more generalist. As you point out though, there are limits to how broad of an audience one can practically cater to.
Many of us are getting banned from other instances because there is a bug where kbin is sending way too much traffic per interaction. I know that was affecting federation (according to other instance admins) so It might have something to do with that. The content on kbin does seem to me like it's not in sync at all, but I haven't measured it.
All we can really do for now is hope for a fix and not interact with posts from other instances.
This post made it over to reddthat, so your posts are federating out.
Checking over on my kbin account as well, I can see content in /newest from multiple sources. /sub returns 404 but I think that’s just a caching bug (adding ?p=1 to the end of the URL lets me workaround it).
It took about a minute for my comment from reddthat to show up here, but it looks like it made it through ok, so inbound comments are working. (Note: replying to myself from my kbin account)
thanks. I actually was seeing something similar at the start of the weekend but it sorta reveresed on me where sub works and newest gives me the 404. I have been looking through my sub and I am seeing lemmy mags. Thanks for the feedback.
I just gave this a try and I think there's a potentially worrisome problem, it silently failed on a lot of community subscriptions. The ones that returned HTTP 500 errors were listed in the "fail" list that the importer script generated, but a whole bunch of others returned 404 errors and weren't listed in either the success or fail lists.
So I advise those running this to pay attention to the error log to avoid losing track of those communities rather than trusting the "fail" list.
I'll try to reproduce this and look into tightening the error handling. A 404 error should imply that the magazine is not available at the remote. Are those magazines available at the target instance? Agree that those should at least be added to the log--perhaps should add a third category for "Unavailable." Remember that it will also navigate you to the magazines list at the end for visual confirmation.
When you said community subscription, were you referring to something in particular, or just using this term generically to refer to magazines?
I haven't tried all of them, but the ones I did check were ones that had not had posts on them at their source instance for quite a while. A few random examples:
I had 43 failures and 111 successes, so visual inspection wouldn't really help. I kept copies of the error log and the script output in a text file to figure it out later.
I assume that this means these communities haven't had activity since fedia.io opened, and so fedia.io doesn't know they exist? I've always wondered how the first person to subscribe to a community on an instance is able to do that.
And yeah, I'm using "community" to refer to "magazine".
Hmm, this is a good finding. Just on a cursory review, I had a look at the magazines list on fedia, and it does list magazines with zero threads, comments, posts, or subscribers on them (on other instances other than kbin.social). So maybe you've discovered a problem with kbin.social's federation? I don't know too much about this issue, so this is just my initial reaction before looking into it further.
Addressing your issue, I have bumped the version number to 0.1.3 and made a change to the async method handling so that instances not available at the remote get added to the fail log correctly.
This doesn't explicitly address the fact that some instances are unfederated, but it will make the log results clean.
As for the federation issue, what I've initially found is that a user on an instance has to visit the remote instance for the home instance to be aware of this remote instance, and a user (could be a different user) has to subscribe to that instance for the posts to start federating. What is unclear is how a user on an instance visits a remote instance from the home instance, as this is implementation-specific and could vary from instanc to instance.
Ok to be fair their politics doesn’t affect lemmy and as for the feature requesting people were entitled assholes and somw guy acted like he was their work slave which pissed the devs of which is complety understandable . apart from that i find the devs fairly pleasant and this is just blatant misinformation spread about them by people who don’t like their political stand . Also no i don’t like russia or china either but i fail to see how it matters on an open source project.
@SharkAttak in the link you provided it says stuff like:
There's threads denyng the oppression of Uyghur muslims (...)
Other posts deny that North Korea is oppressive.
I don't understand how these posts are a proof that lemmy has a bunch of devs that are tankies, since there is no link to the problematic threads they mention. If somehow I missed them could you point those out to me?
Also not too sure I understand how this is a topic related to devs and not mods?
kbinMeta
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.