I think it’s not really on your side, most likely either just something wrong on kbin.social itself, OR a side-effect of the measures lemmy.world implemented against kbin.social recently.

They are basically local-only communities on lemmy.world at this point, unfortunately. There is no federation to any other instance for any lemmy.world user posts on those communities.

That’s true, it will only show content which has been federated to lemm.ee, so indeed if you want to search for more content than is available on your instance, you would need some additional tools for that.

I’m a simple man:

“What day is it?” asked Pooh.

“It’s today,” squeaked Piglet.

“My favorite day,” said Pooh.

Should work just fine for posts and comments as well, for example, here’s a search result containing your comment

The built-in search feature is actually quite decent I find, is it not working well for you?

For context I use all of these daily: Linux (servers + handheld gaming), Windows (gaming), Mac OS (work & general purpose). I used one of the first iPhones around 2008, then exclusively Android for 10 years, and then back to iPhones.

Iphone users of Lemmy, people say not to trust you on tech insights.

IMO, these “people” with such takes are the only ones who shouldn’t be trusted on tech insights here :P

Awesome work!

Do you have an idea yet for the timeline of the 0.19.4 release?

IMO, in practical terms, 3 key things should imapct instance choice:

1. Basic instance rules (including things like community creation policy, nsfw allowed, etc)
2. Federation policy
3. Instance infrastructure (hardware & how it’s managed)

Content specialization really shouldn’t matter IMO, because as long as the federation policy is OK for you, then you can participate in any communities, regardless of what instance they are on. In other words, even if you’re super interested in french cinema, there is no need to centralize all users interested in this topic on a single french cinema instance. Thanks to federation, users from all instances (accounting for federation policy) should be able to become fully fledged participants in any french cinema communities.

Of the points I listed above, #1 and #2 are easier to include in an instance introduction, I’m not sure how to properly and reliably reflect #3 in any kind of overview. At the end of the day, I think most users tend to figure out their long-term home instance a while after they first join Lemmy, and quite often, it’s not their original instance, so maybe it’s not that important to emphasize the initial instance choice too much?

I am very sad about the situation with Beehaw specifically.

I think it’s a very unfortunate case where all parties have the best intentions of building something great with Lemmy, but through different circumstances, relations have soured and involved people no longer think they have a shared vision (which in my opinion is actually not true - I believe that Beehaws vision fits in very well with the direction Lemmy is going, especially with private communities being planned soon).

I am still hopeful that things can be improved, but we will see.

I think something is being lost in communication here. Nothing is being destroyed.

I keep seeing this disconnect, I think it needs to be emphasized: Lemmy maintainers have been focusing (and continue to focus on) safety and moderation improvements. Anybody can verify this by looking through PRs/commits/RFCs on GitHub.

I think I understand where the disconnect is coming from - there have been a few responses in some of these threads by Lemmy devs where they tell people to be less rude and demanding, and to contribute if they desperately want some feature. Perhaps as an observer, this sounds like “we do not care about mod tools” or whatever, but reality is just different.

Perhaps it would be useful to do a more in-depth post about all the stuff Lemmy devs have worked on and are currently working on? I mean things like:

• When purging a federated user, federate local community removals. (#4505)
• Mods and admins can comment in locked posts (fixes #4116) (#4488)
• When site banning a federated user, also remove their content from our local communities. (#4464)
• Store password reset token after email successfully sent (fixes #3757) (#4489)
• Require verified email to reset password (#4482)
• Correctly synchronize collection of community featured posts (fixes #3867) (#4475)
• Ignore expired bans in CommentReportView::read, just like in CommentReportQuery::list (#4457)
• Auto resolve reports on removing a comment or post. Fixes #4390 (#4402)
• … the list goes on and on and on, these are just a very small and incomplete list of examples of already merged PRs which took me 30 seconds to quickly find on GitHub

I feel like there is this meme developing in Lemmy that maintainers are putting out a message of not caring about mod tools, which anybody with context will know is completely false, but I think most Lemmy users (and even many admins!) just don’t have this context.

The core issue here is that there are too many things to do, and too few developers to do them. By the way, for a huge number of these things that need to be done, there is most likely at least one person who thinks it’s the absolute highest priority for Lemmy. Forking would not help fix this issue, it would only make it worse.

In other words: if you’re a Rust dev, you can just fix it in Lemmy anyway, so there is no benefit from forking. If you’re not a Rust dev, then after forking, you will have a new repo to create issues on, except you’ll have 0 devs to actually fix them.

I think separate report inboxes are needed for the report reasons approach as well. This RFC doesn’t prevent having report reasons, rather I think it brings us closer to that goal.

Thanks for the thoughts!

Why not take this approach to simplify it then?

Yeah, the wording can be changed, I’m adding a note about it to the RFC

But I should be able to mark a report complete if I have dealt with it. Otherwise I’m just going to go to the post and sort it out anyway, so its just adding complexity. Barriers/extra steps to administration is not the way forward here.

I think in this particular case, some barriers are crucial. At the very least, I think we need to have warnings/extra confirmations when an admin wants to resolve a mod report.

I mean, if an admin handles it to the point where mods can’t take any further actions anyway (ban + content removal), then the report is automatically resolved already, so there is no need to manually resolve. OTOH, if an admin handles it in a way that a mod might still want to take additional action (for example, the admin just removes a comment), a mod might still want to take further action (for example, ban the offending user from their community), but if the admin marks the mod report as resolved, the mod will most likely end up never seeing it.

I am legally on the hook for content on my instance, not the moderators, and proposing changes that make it harder to be an admin is a touch annoying.

Btw, I don’t think any admin actions should be made harder, I am only talking about adding barriers to resolving reports which are in mod inboxes, and when I say “resolving reports”, I am literally just talking about marking the report as resolved (this shouldn’t really be a common action for admins - it’s akin to marking DMs as read for other users IMO). I don’t want to limit admins in any way from banning/removing content/anything like that.

No. This is a step backwards in transparency and moderation efforts. Granularity and more options is not always a good thing. If you’ve ever had the misfortune of using Meta’s report functionality you’ll know how overly complex and frustrating their report system is to use with all their “granularity”.

Agreed, I think that’s in line with why I proposed not going that path in the RFC as well.

To add: I would suggest thinking about expanding this to notify the user a report has been dealt with/resolved, optionally including rationale, because that feedback element can sometimes be lacking.

I think that would a good additional feature, but orthogonal to this particular RFC (I mean, neither feature depends on each other)

That particular instance was very recently the source of a lot of CSAM and spam, so that’d be why. A lot of instances recently upped their security to combat that.

Just to add some more context, there was an attacker recently who created accounts on several Lemmy instances and used those accounts to spread CSAM. On lemm.ee, this attacker created 4 accounts over a 24h period, but was not able to upload any CSAM to our servers due to our stricter upload rules (we require 4 week old accounts to upload any images at all), and all of the 4 accounts were removed very shortly after creation (most of them within an hour of signing up). The attacker gave up trying to use lemm.ee very quickly, and moved on to other instances.

I just wanted to share this context to illustrate that while indeed the different measures we implement to protect the instance can have a negative impact on legitimate users, I really believe that overall, they have a net positive effect. In addition to Cloudflare DDoS protection and image upload restrictions, we also have a separate content-based alerting layer on top of Lemmy, which allows our admins to quickly notice when something suspicious is going on. As another example, this alerting has allowed us to extremely efficiently deal with a current ongoing spam attack on the Fediverse, and I bet many lemm.ee users aren’t even aware of this attack due to the quick content removal. We will continue to improve our defenses, and hopefully try to limit the impact on real users as much as possible, but some trade-offs are necessary here in order to protect the overall userbase.

The nice thing about Lemmy is that you can always host your own instance, even if it’s only for your own individual use. You can basically use your own instance as a proxy - other instances will not see how or from where you are connecting to your instance.

Large instances are being attacked almost constantly at this point in smaller and bigger ways. Almost all measures we implement to combat these attacks come with some trade-offs for the rest of the userbase.

Or do you mean reports on content now go to the user’s home instance as well?

Yes, exactly.

Also, there’s no way to report a user to their home instance so long as they don’t post anything in a community on their home instance.

This has been fixed in 0.19 thankfully. But for instances running older versions, what you said is still true.

Good luck with the update! One great thing about 0.19 is that it allows users to check federation status between instances, will be awesome to get that for lemmy.world as well.

I kind of get where you’re coming from, but to me it sounds like you’re looking for a different experience than what Lemmy is designed for. It seems you are more interested in aggergating all posts about specific topics (like “books”), and strongly limiting the effect of moderation (as nobody would have final say about how to moderate an entire topic). If I correctly understood the experience you’re interested in, then for sure the design of Lemmy will not match that.

I don’t think it’s fair to describe this as a fatal flaw, though. Lemmy is not built around the idea of generic, “ownerless” topics, instead, it’s built around communities with clear owners. We have decentralization at the admin and infrastructure level (as in, a single admin does not control the entire network), but this does not really mean we also need to have it at individual community level.

IMO it’s totally fine that different people create different communities with extremely similar purposes. The entire internet as a whole also works like this - the internet itself is decentralized, but at the same time people can create different websites with very similar purposes (and even domains!), and it works out fine. For example, it’s totally possible for there to exist a news.com, news.co.uk, news.ee, news.fi, etc. Imagine if whenever you navigated to news.fi with your browser, it would also automatically insert content from all the other news websites of all possible domains - it doesn’t really seem like a useful feature, but that’s kind of analogous to what you’re suggesting for Lemmy at the moment.