Hi, there is no free speech policy on lemm.ee, we have very strict moderation when it comes to our rules. We regularly permaban users for breaking our instance rules. We simply don’t use defederation as a moderation tool, preferring other tools like user bans, for reasons outlined here: https://lemm.ee/post/35472386

Interesting! We’ve had quite a noticeable spike of sign-ups on lemm.ee as well

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.

I think there are two separate things I want to address here:

First, agile isn’t a project management methodology, it’s just a set of 4 abstract priorities and 12 abstract principles. It’s very short, you can check it out here:

https://agilemanifesto.org/

Nothing here says that you’re not allowed to write documentation, write down requirements, etc. In fact, the principles encourage you yourself as a software team to create the exact processes and documentation that you need in order to meet your goals.

“Working software over comprehensive documentation” does not mean you aren’t allowed to have documentation, it just means that you should only write documentation if it helps you build working software, rather than writing documentation for the sake of bureaucracy.

“Individuals and interactions over processes and tools” does not mean that you should have no processes, it just means that the individuals in your team should be empowered to collaboratively create whatever processes you need to deliver good software.

Secondly, in terms of practical advice:

1. Talk about this problem with your team. Is it hard for others to figure out where requirements came from? Maybe they already have a good method and can share it with you. If it’s hard for everybody, then propose improvements to your process, for example, propose some type of design document process as part of building any new features
2. There are no perfect answers to the question of “how do I safely make non-trivial changes to systems”, but the general approach is to ensure that:

a. You have metrics about how your system is used.

b. You have automated tests covering any requirements, so that you can feel confident when making changes to one part of the system that it isn’t violating any unrelated requirements.

c. You actually document any confusing parts in the code itself using comments. The most important thing to cover in comments is “why is this logic necessary?” - whenever something is confusing, you need to answer this question with a comment. Otherwise, the system becomes very annoying to change later on.

If you are missing any of the above, then propose to your team that you start doing it ASAP

3. At the end of the day, somebody is responsible for making product decisions. Is it your team? Or maybe some separate product owner? Sometimes, you just need to communicate with whoever is responsible to figure out if any requirements are still relevant, or if they are now safe to change.

It’s not really a bug, it’s just a case where app developers need to update their code to support a small change in the Lemmy API. More details here: https://lemm.ee/post/34259050/12479585

It’s a full new game that you need to purchase separately, but all the marketplace stuff you’ve bought for 2020 will also come with you to 2024

We finally have a release date for Microsoft Flight Simulator 2024!

Regarding your question:

Lemmy federation basically works by copying stuff from their source instance to all other federated instances. So if I write a comment on lemm.ee, other federated instances will get their own copy of my comment. They will also all know that the “authority” for this comment is lemm.ee.

If an admin on another instance decides to delete their local copy of my comment on lemm.ee, then they are always free to do so (for example, some instances might want to moderate more strictly), but any actions they take like this are limited to their own instance - for the rest of Lemmy, lemm.ee remains the authority for this comment, so individual remote instance admins taking actions won’t have any effect on any other instances.

As for the original topic of modlog federation, basically it just boils down to this: just like with the comment example above, Lemmy instances also save a local copy of incoming federated mod logs. The Lemmy software does not yet have 100% coverage in terms of federating mod logs (for example, there are no federated logs yet for instance admins banning remote users), but this coverage has been increasing, and I expect this will eventually get to 100% (just needs more dev time really).

Also, if some instance admins try to tamper with their mod logs, then other instances can still see the real history, because there is no way for an instance admin to delete copies of their mod log from other instances.

Banning a local user from a local community does actually federate already

Most actions federate, any exceptions which aren’t federated yet are generally just there because the federation logic has not been implemented (but improvements are constantly being worked on).

Generally federating the modlog is mostly just there for informative purposes. As in, we can check what mod actions were taken on instance A through the modlog on instance B (and there is no mechanism in Lemmy for other instances to retroactively remove or hide federated modlog items, btw).

incorporated into the UI, rather than a piece of text in the post.

How would other instances (or other ActivityPub software) know about it if it’s not a piece of text in the post?

I think nearly all big Lemmy instances have in fact defederated, you can check this list: https://fedipact.veganism.social (filter by software: Lemmy)

Just a hunch, but is it possible you missed the --recursive flag when cloning the repo?

This “ads as posts” thing was one of my two biggest concerns with Threads federation. I really hoped I would turn out to be wrong about it, but at the end of the day, both Facebook itself, as well as big social media influencers, rely on advertising for their profits. For anybody looking to avoid ads on Lemmy, it seems like direct federation with Threads is not a good idea currently. On lemm.ee, “no advertising” has been one of our 4 core instance rules from the start.

My other major concern was Threads having the ability to enforce their feed algorithms on federated instances through sheer number of votes on things they show in their feeds, but judging by what you’re saying about the engagement, at least that concern has not materialized (at least yet).

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.