sunaurus @ sunaurus @lemm.ee

Not active on Lemmy any longer. If you send me a DM, I won't see it. Sorry!

---

Read more

Posts

49

Comments

331

Joined

2 yr. ago

Sorry, I guess the post came out maybe more technical than I originally intended..

In a nutshell, there is a new look and feel for lemm.ee on the way (but the current one will remain available as an option as well!)

https://github.com/sunaurus/lemmy-ui-next

I am personally super used to the non-centered UI from over a decade of using Reddit. I mean, I can understand where you're coming from, but it just feels natural to me at this point 😃I will consider adding another centered layout at some point as well

The community logos getting cut off will definitely be fixed.

I am working on inline expanding images next!

I'm working on this feature next!

Wow, seems the text is totally messed up for light-mode users 😅 The issue is that there is some default light-mode styling applied to any Markdown text, but I don't have light mode colors defined for any other element. I will fix it in a moment, thanks for letting me know.

For now, I am just starting with a single dark theme, but once I have all initial features in place, I could consider additional themes as well!

Edit: should be fixed now, thanks again for letting me know!

I love the idea of Matrix, but I'm so done with Element on my phone telling me it is "Syncing..." for two minutes, only to end up with 1 new message in 1 channel... 😅

Interesting project! Can you explain the vision a bit more - I understand that every instance can have their own version of an article, but how would a user know which version of an article is most relevant to them to read (and maybe even contribute to)?

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.

Nice post, I enjoyed the storytelling. Glad it's all sorted now 😁

Btw, regarding this point:

All in all, this has been a fairly frustrating experience and I can’t imagine anyone who’s not doing IT Infrastructure as their day job being able to solve this. As helpful as the other lemmy admins were, they were relying a lot on me knowing my shit around Linux, networking, docker and postgresql at the same time. I had to do extended DB analysis, fork repositories, compile docker containers from scratch and deploy them ad-hoc etc. Someone who just wants to host a lemmy server would give up way earlier than this.

I think you're totally right, but at the same time, I think the collaborative troubleshooting that happened on Matrix (and has happened many times in the past for other issues) is pretty healthy, and not something that is always possible for other open source software.

Sorry if you were just making a joke, my sarcasm detector is not really working anymore (/s at the end would help). But if not, this comment really perfectly captures the entitlement in open source.

Now imagine you spend months (or even years) of your free time to build something for people to use freely, and the result is that you get endless comments from random strangers, telling you that you work for them and that you need to respect and be grateful to them. I honestly am impressed that open source still exists at all at this point.

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 just want to add a counter-point to the argument that Lemmy devs are somehow opposed to contributions. In my experience, there has been no resistance to contributing any type of change (I have personally added niche features for running Lemmy in a distributed manner, optimizations, bug fixes, etc). In fact I would claim the complete opposite - I have received plenty of support and good code reviews from maintainers whenever I have wanted to contribute anything.

I think there is truth to the claim that Lemmy maintainers don’t have a lot of patience for people making demands and snarky comments, but that is very different from being opposed to contributions. Also, after running a big instance for a while now, I completely understand this lack of patience - when some of your users just keep being rude to you, it wears down your patience. It’s easy to patiently and kindly respond to the first 100 rude users, but at some point after that, it just becomes gradually more mentally exhausting, to the point where it’s basically impossible.

Even the example provided in the blog post: I don’t think snowe had bad intentions, but I do think they had clearly misinterpreted the situation with that issue, and their comments were needlessly condescending.

They had this thread about it: https://hexbear.net/post/1712067

The decision on lemm.ee was much harder as the average user did express desire to remain federated however the admin team decided that a temporary removal from our allow-list was the best option.

as expressed by users belonging to marginalized groups, comments from .ee users are often lib-shit and in some cases outright hostile. While many on hexbear love dunking on these lost libs the duty to protect marginalized users is much more important.

I think the main issue is that for most of the time we were federated, lemm.ee admins were not getting reports about lemm.ee user activity on Hexbear communities (Lemmy didn't have this feature until 0.19), so if anybody used a lemm.ee account to harass users on Hexbear (and I understand this did happen), there was no way for lemm.ee admins to even find out about it. In general we have a very aggressive zero tolerance policy for bigotry (and that includes transphobia), but if we don't receive reports, then it's hard for us to take any kind of action.

They turned off federation from their side, so their instance is not federating stuff to us directly at the moment, but other instances still occasionally federate things Hexbear users have posted there, so that's probably why you are seeing them around every now and then.

It's not immediately clear from the title, so let me point out that they are talking about routers which are using default credentials and no automatic updates.

They specifically called it "child abuse content", not "child abuse". This seems perfectly valid, no?

By the way, just because these are digital renderings does not mean that there is no harm. Seeing such content can still be harmful to past victims. Just try to put yourself in this situation: imagine just playing some video game online, and suddenly being exposed to people recreating traumatic experiences from your past. Not only that - you also discover that the creators of the video game are involved & actively enabling such content. Seems completely messed up to me.

Good luck with the upgrade!

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)