sunaurus

I think community discovery can (and should) be improved for sure!

Currently it's true that you can use topic-centered instances for this, I do this myself as well, but I do think it has quite significant downsides in terms of creating pockets of centralization. For example, if you're a user who is ONLY interested in french cinema (or any specific topic) on Lemmy, and all of the related communities and other invested users are on a single instance, then for you, the experience is absolutely no different from any centralized platform - the french cinema instance admins have 100% control over your Lemmy experience.

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?

If I have several backends that more or less depend on each other anyway (for example: Lemmy + pict-rs), then I will create separate databases for them within a single postgres - reason being, if something bad happens to the database for one of them, then it affects the other one as well anyway, so there isn't much to gain from isolating the databases.

Conversely, for completely unrelated services, I will always set up separate postgres instances, for full isolation.

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.

What exactly is the issue with our admins? If you feel you've received some unjustified moderation, feel free to contact me and I can have a look.

0.19.2 was a simple upgrade, did not even require downtime, so I'm not surprised it wasn't noticed :P

Based on the description, I am thinking this was related to some general issues we were having after the 0.19 upgrade (which have been solved now). Thanks for the info!

lemm.ee started having a weird bug for logging in

Hey, can you share some more about this login bug? I'm not aware of any login issues currently. Could it be related to an app you were using not supporting 0.19 yet?