of all the scrapers we see, the requests identified as originating from Meta seem to be well behaved overall. they appear to (mostly) be respecting robots.txt where present and their request volume to Lemmy.World is only averaging slightly above 5 requests per minute over the last 2 weeks. they also don't spoof their user agents to pretend to be web browsers, or at least I have not seen credible accusations of this happening.
based on your other post, which has since been removed by moderators of that community, it seems that you are looking for the !perchance@lemmy.world community instead of this one.
you're not going to have much luck here, as here people won't even understand what you're talking about.
that's because SJW is still on 0.19.11. 0.19.12 fixes this by forcing new posts in NSFW communities to be NSFW. see #5649. the UI change made it in 0.19.11 already but the backend change was broken and not backported.
please remove the phishing link from this post immediately. you can defuse it e.g. by putting it in a code snippet and replacing the dots with [.], e.g. netprocesse[.]com.
if you're talking about the image issue from this post, I have no plans to work on that as we don't use the image proxy but if anyone wants to PR that they're more than welcome to do so.
we're currently looking into some performance issues, we're looking into updating to the latest version this weekend, which fixes a few potential deadlocks. lately we've been getting DB deadlocks rather frequently, which results in significantly worse performance until we restart one of the services.
mods can remove other mods if they are below them in the moderator list. for moderators higher up admin intervention is required.
as the default lemmy ui doesn't exactly make it easy to manage moderators in a community if they haven't posted or commented there recently i recommend using tesseract for this, where you can easily do this and much more in the community settings.
i see. for PWAs that's expected, for the native app i would've expected a consistent UA for all requests.
our current blocks/challenges are explicitly targeting things that pretend to be browsers while not actually being browsers. we try to exclude requests that are expected to be accessed by browser based clients that aren't directly on the main site. appending to browser user agents still matches our browser user agent detection.
i'm not sure why this was causing issues here though, especially with the login, as that should just be 100% api stuff and therefore use VoyagerApp/1.0 from the native app?
this was possibly an unintended side-effect of our increasingly aggressive AI crawler DDoS blocking. When increasing the scope of issuing Cloudflare challenges we missed excluding API endpoints from the rule, that should be fixed now.
This should only have affected clients with browser user agents though, and I see requests with user agent VoyagerApp/1.0. @aeharding@vger.social do you know if Voyager can send browser-like user agents when installed from App Store?
check if your piefed account has pms from other instances enabled. afaik piefed.social had this disabled by default for some time during the nicole spamwave.
lemmy currently doesn't have granular federation controls. the only option right now is to defederate from mbin instances, but other instances might still announce your users' votes to mbin instances. the more hacky way would be to also block federation related http requests from mbin instances to prevent them from retrieving user profiles, which is probably the most effective method that could be used.
piefeds non-federated votes are a user setting for the default value and users have the option for each vote whether it should be federated. see also https://piefed.social/post/982478
as explained in this post, the original implementation of "private voting" has already been replaced with non-federated voting, which addresses the abuse concerns, as it's then limited to just the instance the votes are cast on.
can you describe your problems in more detail?